Cisco.press.troubleshooting.ip.Routing.protocols.may.2002

TroubleshootingIPRoutingProtocols

FarazShamim,CCIE#4131,ZaheerAziz,CCIE#4127,JohnsonLiu,CCIE#2637,

andAbeMartey,CCIE#2373

CiscoPress201West103rdStreet

Indianapolis,IN46290USA

TroubleshootingIPRoutingProtocolsFarazShamim,ZaheerAziz,JohnsonLiu,AbeMarteyCopyright©2002CiscoSystems,Inc.Publishedby:CiscoPress201West103rdStreetIndianapolis,IN46290USAAllrightsreserved.Nopartofthisbookmaybereproducedortransmittedinanyformorbyanymeans,electronicormechanical,includingphotocopying,recording,orbyanyinformationstorageandretrievalsystem,withoutwrittenpermissionfromthepublisher,exceptfortheinclusionofbriefquotationsinareview.PrintedintheUnitedStatesofAmerica1234567890FirstPrintingMay2002LibraryofCongressCataloging-in-PublicationNumber:2001086619ISBN:1-58705-019-6

WarningandDisclaimerThisbookisdesignedtoprovideinformationabouttroubleshootingIProutingprotocols,includingRIP,IGRP,EIGRP,OSPF,IS-IS,PIM,andBGP.Everyefforthasbeenmadetomakethisbookascompleteandasaccurateaspossible,butnowarrantyorfitnessisimplied.Theinformationisprovidedonan“asis”basis.Theauthors,CiscoPress,andCiscoSystems,Inc.shallhaveneitherliabilitynorresponsibilitytoanypersonorentitywithrespecttoanylossordamagesarisingfromtheinformationcontainedinthisbookorfromtheuseofthediscsorprogramsthatmayaccompanyit.TheopinionsexpressedinthisbookbelongtotheauthorandarenotnecessarilythoseofCiscoSystems,Inc.

TrademarkAcknowledgmentsAlltermsmentionedinthisbookthatareknowntobetrademarksorservicemarkshavebeenappropriatelycapitalized.CiscoPressandCiscoSystems,Inc.cannotattesttotheaccuracyofthisinformation.Useofaterminthisbookshouldnotberegardedasaffectingthevalidityofanytrademarkorservicemark.

FeedbackInformationAtCiscoPress,ourgoalistocreatein-depthtechnicalbooksofthehighestqualityandvalue.Eachbookiscraftedwithcareandprecision,undergoingrigorousdevelopmentthatinvolvestheuniqueexpertiseofmembersfromtheprofessionaltechnicalcommunity.Readers’feedbackisanaturalcontinuationofthisprocess.Ifyouhaveanycommentsregardinghowwecouldimprovethequalityofthisbookorotherwisealterittobettersuityourneeds,youcancontactusthroughe-mailatfeedback@ciscopress.com.PleasebesuretoincludethebooktitleandISBNinyourmessage.Wegreatlyappreciateyourassistance.

PublisherJohnWait

mailto:[email protected]

Editor-in-ChiefJohnKane

CiscoSystemsManagementMichaelHakkertTomGeitnerWilliamWarren

ProductionManagerPatrickKanouse

ExecutiveEditorBrettBartow

AcquisitionsEditorAmyLewis

DevelopmentEditorChristopherCleveland

ProjectEditorSanDeePhillips

CopyEditorKristaHansing

TechnicalEditorsBrianMorgan,HaroldRitter,JohnTiso

TeamCoordinatorTammiRoss

BookDesignerGinaRexrode

CoverDesignerLouisaKlucznik

CompositionPublicationServices,Inc.

IndexerTimWright

CorporateHeadquarters

CiscoSystems,Inc.170WestTasmanDriveSanJose,CA95134-1706USAhttp://www.cisco.comTel:408526-4000800553-NETS(6387)Fax:408526-4100EuropeanHeadquartersCiscoSystemsEurope11RueCamilleDesmoulins92782Issy-les-MoulineauxCedex9Francehttp://wwweurope.cisco.comTel:33158046000Fax:33158046100AmericasHeadquartersCiscoSystems,Inc.170WestTasmanDriveSanJose,CA95134-1706USAhttp://www.cisco.comTel:408526-7660Fax:408527-0883AsiaPacificHeadquartersCiscoSystemsAustralia,Pty.,LtdLevel17,99WalkerStreetNorthSydneyNSW2059Australiahttp://www.cisco.comTel:+61284487100Fax:+61299574350

CiscoSystemshasmorethan200officesinthefollowingcountries.Addresses,phonenumbers,andfaxnumbersarelistedontheCiscoWebsiteatwww.cisco.com/go/offices

Argentina•Australia•Austria•Belgium•Brazil•Bulgaria•Canada•Chile•China•Colombia•CostaRica•Croatia•CzechRepublic•Denmark•Dubai,UAE•Finland•France•Germany•Greece•HongKong•Hungary•India•Indonesia•Ireland•Israel•Italy•Japan•Korea•Luxembourg•Malaysia•Mexico•TheNetherlands•NewZealand•Norway•Peru•Philippines•Poland•Portugal•PuertoRico•Romania•Russia•SaudiArabia•Scotland•Singapore•Slovakia•Slovenia•SouthAfrica•Spain•Sweden•Switzerland•Taiwan•Thailand•Turkey•Ukraine•UnitedKingdom•UnitedStates•Venezuela•Vietnam

http://www.cisco.com

http://wwweurope.cisco.com



http://www.cisco.com/go/offices

•Zimbabwe

Copyright©2000,CiscoSystems,Inc.Allrightsreserved.AccessRegistrar,AccessPath,AreYouReady,ATMDirector,BrowsewithMe,CCDA,CCDE,CCDP,CCIE,CCNA,CCNP,CCSI,CD-PAC,CiscoLink,theCiscoNetWorkslogo,theCiscoPoweredNetworklogo,CiscoSystemsNetworkingAcademy,FastStep,FireRunner,FollowMeBrowsing,FormShare,GigaStack,IGX,IntelligenceintheOpticalCore,InternetQuotient,IP/VC,iQBreakthrough,iQExpertise,iQFastTrack,iQuickStudy,iQReadinessScorecard,TheiQLogo,KernelProxy,MGX,NaturalNetworkViewer,NetworkRegistrar,theNetworkerslogo,Packet,PIX,PointandClickInternetworking,PolicyBuilder,RateMUX,ReyMaster,ReyView,ScriptShare,SecureScript,ShopwithMe,SlideCast,SMARTnet,SVX,TrafficDirector,TransPath,VlanDirector,VoiceLAN,WavelengthRouter,WorkgroupDirector,andWorkgroupStackaretrademarksofCiscoSystems,Inc.;ChangingtheWayWeWork,Live,Play,andLearn,EmpoweringtheInternetGeneration,areservicemarksofCiscoSystems,Inc.;andAironet,ASIST,BPX,Catalyst,Cisco,theCiscoCertifiedInternetworkExpertLogo,CiscoIOS,theCiscoIOSlogo,CiscoPress,CiscoSystems,CiscoSystemsCapital,theCiscoSystemslogo,CollisionFree,Enterprise/Solver,EtherChannel,EtherSwitch,FastHub,FastLink,FastPAD,IOS,IP/TV,IPX,LightStream,LightSwitch,MICA,NetRanger,Post-Routing,Pre-Routing,Registrar,StrataViewPlus,Stratm,SwitchProbe,TeleRouter,areregisteredtrademarksofCiscoSystems,Inc.oritsaffiliatesintheU.S.andcertainothercountries.Allotherbrands,names,ortrademarksmentionedinthisdocumentorWebsitearethepropertyoftheirrespectiveowners.TheuseofthewordpartnerdoesnotimplyapartnershiprelationshipbetweenCiscoandanyothercompany.(0010R)

AbouttheAuthors

FarazShamim,CCIE#4131,isanetworkconsultingengineerwiththeAdvanceNetworkServicesTeamfortheServiceProvider(ANS-SP)forCiscoSystems,Inc.HeprovidesconsultingservicestohisdedicatedInternetserviceproviders.Farazwroteseveraldocuments,whitepapers,andtechnicaltipsforODR,OSPF,RIP,IGRP,EIGRP,andBGPonCiscoConnectionOnline(CCO),(www.cisco.com).FarazhasalsobeenengagedindevelopingandteachingtheCiscoInternetworkingBasicandAdvanceBootcampTrainingforCisconew-hireengineers.HehasalsotaughttheCiscoInternetworkingBootcampCoursetoMSstudentsattheUniversityofColoradoatBoulder(BU)andSirSyedUniversityofEngineering&Technology(SSUET),Karachi,Pakistan.FarazhasbeenavisitingfacultymemberforSSUETandalsogavealectureonOSPFtoLahoreUniversityofManagement&Sciences(LUMS),Lahore,Pakistan.FarazhasbeenengagedindevelopingCCIElabtestsandproctoringtheCCIElab.FarazactivelyspeaksattheNetworkersconferenceonthesubjectofOSPF.Likeotherauthorsofthisbook,healsostartedhiscareerattheCiscoTechnicalAssistantCenter(TAC)providingsupportforcustomersinIProutingprotocols.FarazhasbeenwithCiscoSystemsforfiveyears.ZaheerAziz,CCIE#4127,isanetworkconsultingengineerintheInternetInfrastructureServicesgroupforCiscoSystems,Inc.ZaheerprovidesconsultingservicestomajorISPsintheMPLSandIProutingprotocolsarea.InhislastfiveyearsatCisco,ZaheerhasbeenactivelyinvolvedinspeakingatCiscoNetworkersconferencesandatseveralCiscoevents.ZaheeroccasionallywritesforCiscoPacketmagazineandforSpiderInternetmagazine,PakistanontopicsofMPLSandBGP.Heholdsamaster’sdegreeinelectricalengineeringfromWichitaStateUniversity,Wichita,KSandenjoysreadingandplayingcricketandPing-Pong.Zaheerismarriedandhasalovingfive-year-oldboy,TahaAziz.JohnsonLiu,CCIE#2637,isaseniorcustomernetworkengineerwiththeAdvanceNetworkServicesTeamfortheenterpriseinCiscoSystems.HeobtainedhisMSEEdegreesattheUniversityofSouthernCaliforniaandhasbeenwithCiscoSystemsformorethanfiveyears.HeisthetechnicaleditorforotherCiscoPressbooks,includingInternetRoutingArchitecturesandLarge-ScaleIPNetworkSolutions.Johnsonhasbeeninvolvedinmanylarge-scaleIPnetworkdesignprojectsinvolvingEIGRP,OSPF,andBGPforlargeenterpriseandserviceprovidercustomers.JohnsonisalsoaregularspeakerfordeployingandtroubleshootingEIGRPattheNetworkersconference.AbeMartey,CCIE#2373,isaproductmanageroftheCisco12000InternetRouterSeries.Abespecializesinhigh-speedIProutingtechnologiesandsystems.Priortothisposition,AbeworkedasasupportengineerintheCiscoTechnicalAssistanceCenter(TAC),specializinginIProutingprotocolsandlaterontheISPTeam(nowInfrastructureEngineeringServicesTeam),whereheworkedcloselywithtieroneInternetserviceproviders.Abeholdsamaster’sdegreeinelectricalengineeringandhasbeenwithCiscoSystemsforoversixyears.AbeisalsotheauthorofIS-ISDesignSolutionsfromCiscoPress.

AbouttheTechnicalReviewersBrianMorgan,CCIE#4865,CCSI,istheDirectorofDataNetworkEngineeringatAllegianceTelecom,Inc.Hehasbeeninthenetworkingindustryformorethan12years.BeforegoingtoAllegiance,Morganwasaninstructor/consultantteachingICND,BSCN,BSCI,CATM,CVOICE,andBCRAN.Heisaco-authoroftheCiscoCCNPRemoteAccessExamCertificationGuideandatechnicaleditorofnumerousCiscoPresstitles.HaroldRitter,CCIE#4168,isanetworkconsultingengineerforCiscoAdvancedNetworkServices.HeisresponsibleforhelpingCiscotop-tiercustomerstodesign,implement,andtroubleshootroutingprotocolsintheirenvironment.Hehasbeenworkingasanetworkengineerformorethaneightyears.


JohnTiso,CCIE#5162,isoneoftheseniortechnologistsofNIS,aCiscoSystemsSilverpartner.HehasabachelorofsciencedegreefromAdelphiUniversity.TisoalsoholdstheCCDPcertification,CiscoSecurityandVoiceAccessSpecializations,andSunMicrosystems,Microsoft,andNovellcertifications.Hehasbeenpublishedinseveralindustrypublications.Hecanbereachedthroughe-mailatjohn@jtiso.com.

mailto:[email protected]

Dedications

ZaheerAziz:Iwouldliketodedicatethisbooktomylatefather(mayGodblesshissoul)forhisstrugglinglifeforbettermentofourlife,toapersonwhoseself-made,hardworking,andnot-so-easylifehistorybecameacatalystfortherelativelylittlehardworkIhaveputinmylife.Undoubtedly,hewouldhavetremendouslyenjoyedseeingthisbook,butheisnothere.Truly,hisAirForcebloodwouldhaverushedfastseeingthisbook,butheisnothere.Verily,hewouldhaveimmenselyapplaudedmeinseeingthisbook,butheisnothere.Therefore,Iwantmymother,whohasputinequalhardworkinourlife,toenjoythisaccomplishmentandsuccess.Shedeservesequalcreditinthesuccessofourfamily,andIwishheraverylongandhappylife.JohnsonLiu:Idedicatethisbookwithmydeepestloveandaffectiontomywife,CiscoLiu,whohasgivenmetheinspirationandsupporttowritethisbook.AbeMartey:I’dliketodedicatethisbooktoallpreviousandcurrentengineersoftheCiscoWorldwideTACfortheirremarkableenthusiasm,dedication,andexcellenceinprovidingtechnicalandtroubleshootingassistancetonetworkoperatorsineverycornerofourplanetandinspace.FarazShamim:Iwouldliketodedicatethisbooktomyparents,whosefavorsIcanneverreturnandwhoseprayersIwillalwaysneed.Tomywife,whoencouragedmewhenIfelttoolazytowrite,andtomysons,AyaanandAmeel,whowaitedpatientlyformyattentiononmanyoccasions.

Acknowledgments

FarazShamim:Alhamdulillah!IthankGodforgivingmetheopportunitytowritethisbook,whichIhopewillhelpmanypeopleinresolvingtheirroutingissues.Iwouldliketothankmymanager,SrinivasVegesna,andmypreviousmanagerandmentor,AndrewMaximov,forsupportingmeinthisbookproject.SpecialthanksgoestoBobVigil,wholetmeusesomeofhispresentationmaterialintheRIPandIGRPchapter.IwouldalsoliketothankAlexZininforclearingsomeofmyOSPFconceptsthatIusedinthisbook.Iwouldliketothankmyco-authors,ZaheerAziz,AbeMartey,andJohnsonLiu,whoputupwithmyhabitofremindingthemoftheirchapterdeadlines.IwouldalsoliketothankChrisClevelandandAmyLewisofCiscoPressfortheirunderstandingwheneverwewerelateinsubmittingourchapters.ZaheerAziz:AllthankstoGodforgivingmestrengthtoworkonthisbook.Iheartilythankmywifeforhersupport,patience,andunderstandingthathelpedmeputinmanyhoursonthisbook.Iappreciatetheflexibilityofmyemployer,CiscoSystems,Inc.(inparticular,mymanager,SrinivasVegesna)forallowingmetoworkonthisbookwhilekeepingmydayjob.ManythankstoSyedFarazShamim(leadauthorofthisbook),whoinvitedmethroughacell-phonecallfromSanJosetoWashington,D.C.,whereIwasattendingIETF46in1999,toco-authorthisbook.ThankstoMoizMoizuddinforindependentlyreviewingthetechnicalcontentofmychapters.Iwouldliketocreditmymentor,SyedKhalidRaza,forhiscontinuousguidanceandforshowingmetheworldofBGP.Finally,IwishtothankCiscoPress,whomadethisbookpossible—inparticular,ChristopherClevelandandBrianMorgan,whosesuggestionsgreatlyimprovedthequalityofthisbookandmadethisprocessgosmoothly.JohnsonLiu:IwouldliketothankmyfriendsandcolleaguesatCiscoSystems,withwhomIspentmanylatehourswithtryingtotroubleshootP1routingprotocolproblems.Theirprofessionalismandknowledgearesimplyunparalleled.Specialthankstomymanagers,AndrewMaximowandRajaSundaram,whohavegivenmealltheirsupportthroughoutmycareeratCiscoSystems.Finally,Iwouldliketothankmytechnicaleditorsfortheirinvaluableinputandsuggestionstoimprovethisbook.AbeMartey:Firstofall,I’dliketoexpresssincerethankstotheco-authorsandcolleaguesatwork,Faraz,Johnson,andZaheerfordreamingupthistitleandinvitingmetoparticipateinitsmaterialization.WeallworkedontheCiscoTechnicalAssistanceCenter(TAC)RoutingProtocolTeam,givingusquiteabitofexperiencetroubleshootingIProutingproblems.ThisworkisourattempttogenerouslysharethatexperiencewithalargeraudiencebeyondtheCiscoSystemsworkenvironment.Ireceivedalotofsupport,mentorship,andtrainingfrommanyCiscoTACanddevelopmentengineers,aswellasmanydirectandnondirectmanagersasaTACEngineer.Hatsofftothisuniquebreedoftalentedindividuals,womenandmen,whohavecommittedtheirlivestokeeptheInternetrunning.I’dalsoliketothankthesefolks(toomanyofthemtonamehere)foreverybitofknowledgeandwisdomthatthey’vesharedwithmeovertheyears.Overtime,I’vedevelopedgreatpersonalrelationshipswithvariousnetworkingprofessionalsworldwide,allofwhomImetascustomersorthroughIETF,NANOG,IEEE,andotherprofessionalconferencesandmeetings.I’dliketosincerelythankthemforsharingwithmetheirknowledgeand

expertise,aswellastheirprofessionalinsightsandvisionsintothefutureofnetworkingtechnology.I’dalsoliketoexpressmysincerestgratitudetoAmyLewisandChrisCleveland,bothofCiscoPress,andthetechnicaleditorsfortheirrolesinhelpingbringthisbooktofruition.Manythankstoseveralcloserelativesfortheirsupportandencouragementallthroughthisproject.

ContentsataGlance

Introduction

Chapter1UnderstandingIPRouting

Chapter2UnderstandingRoutingInformationProtocol(RIP)

Chapter3TroubleshootingRIP

Chapter4UnderstandingInteriorGatewayRoutingProtocol(IGRP)

Chapter5TroubleshootingIGRP

Chapter6UnderstandingEnhancedInteriorGatewayRoutingProtocol(EIGRP)

Chapter7TroubleshootingEIGRP

Chapter8UnderstandingOpenShortestPathFirst(OSPF)

Chapter9TroubleshootingOSPF

Chapter10UnderstandingIntermediateSystem-to-IntermediateSystem(IS-IS)

Chapter11TroubleshootingIS-IS

Chapter12UnderstandingProtocolIndependentMulticast(PIM)

Chapter13TroubleshootingPIM

Chapter14UnderstandingBorderGatewayProtocolVersion4(BGP-4)

Chapter15TroubleshootingBGP

AppendixAnswerstoReviewQuestionsIndex

TableofContents

Introduction

Chapter1UnderstandingIPRouting

IPAddressingConceptsIPv4AddressClassesIPv4PrivateAddressSpaceSubnettingandVariable-LengthSubnetMasksClasslessInterdomainRouting

StaticandDynamicRoutesDynamicRouting

UnicastVersusMulticastIPRoutingClasslessVersusClassfulIPRoutingProtocolsInteriorGatewayProtocolsVersusExteriorGatewayProtocolsDistanceVectorVersusLink-StateProtocols

DistanceVectorRoutingConceptsLink-StateProtocols

RoutingProtocolAdministrativeDistance

FastForwardinginRoutersSummaryReviewQuestions

References

Chapter2UnderstandingRoutingInformationProtocol(RIP)

Metric

TimersSplitHorizonSplitHorizonwithPoisonReverse

RIP-1PacketFormatRIPBehavior

RIPRulesforSendingUpdatesRIPRulesforReceivingUpdatesExampleofSendingUpdatesExampleofReceivingUpdates

WhyRIPDoesn’tSupportDiscontiguousNetworksWhyRIPDoesn’tSupportVariable-LengthSubnetMasking

DefaultRoutesandRIPProtocolExtensiontoRIP

RouteTagSubnetMaskNextHopMulticastCapabilityAuthentication

CompatibilityIssues

SummaryReviewQuestionsFurtherReading

Chapter3TroubleshootingRIP

FlowchartstoSolveCommonRIPProblemsTroubleshootingRIPRoutesInstallation

Problem:RIPRoutesNotintheRoutingTableRIPRoutesNotintheRoutingTable—Cause:MissingorIncorrectnetworkStatement

DebugsandVerificationSolution

RIPRoutesNotintheRoutingTable—Cause:Layer1/2IsDownDebugsandVerificationSolution

RIPRoutesNotintheRoutingTable—Cause:distribute-listinIsBlockingtheRouteDebugsandVerificationSolution

RIPRoutesNotintheRoutingTable—Cause:AccessListBlockingRIPSourceAddressDebugsandVerificationSolution

RIPRoutesNotintheRoutingTable—Cause:AccessListBlockingRIPBroadcastorMulticast(inCaseofRIP-2)


RIPRoutesNotintheRoutingTable—Cause:IncompatibleRIPVersionTypeDebugsandVerificationSolution

RIPRoutesNotintheRoutingTable—Cause:MismatchAuthenticationKey(RIP-2)DebugsandVerificationSolution

RIPRoutesNotintheRoutingTable—Cause:DiscontiguousNetworkDebugsandVerificationSolution

RIPRoutesNotintheRoutingTable—Cause:InvalidSourceDebugsandVerificationSolution

RIPRoutesNotintheRoutingTable—Cause:Layer2Problem(Switch,FrameRelay,OtherLayer2Media)


RIPRoutesNotintheRoutingTable—Cause:OffsetListHasaLargeMetricDefinedDebugsandVerificationSolution

RIPRoutesNotintheRoutingTable—Cause:RoutesReachedRIPHopCountLimitDebugsandVerificationSolution

Problem:RIPIsNotInstallingAllPossibleEqual-CostPaths—Cause:maximumpathCommandRestrictsRIPfromInstallingMoreThanOnePath


TroubleshootingRIPRoutesAdvertisementProblem:SenderIsNotAdvertisingRIPRoutes

SenderIsNotAdvertisingRIPRoutes—Cause:MissingorIncorrectnetworkStatementDebugsandVerificationsSolution

SenderIsNotAdvertisingRIPRoutes—Cause:OutgoingInterfaceIsDownDebugsandVerificationSolution

SenderIsNotAdvertisingRIPRoutes—Cause:distribute-listoutIsBlockingtheRouteDebugsandVerificationSolution

SenderIsNotAdvertisingRIPRoutes—Cause:AdvertisedNetworkInterfaceIsDownDebugsandVerificationSolution

SenderIsNotAdvertisingRIPRoutes—Cause:OutgoingInterfaceIsDefinedPassiveDebugsandVerificationSolution

SenderIsNotAdvertisingRIPRoutes—Cause:BrokenMulticastCapability(FrameRelay)


SenderIsNotAdvertisingRIPRoutes—Cause:MisconfiguredneighborStatementDebugsandVerificationSolution

SenderIsNotAdvertisingRIPRoutes—Cause:AdvertisedSubnetIsVLSMDebugsandVerificationSolution

SenderIsNotAdvertisingRIPRoutes—Cause:SplitHorizonIsEnabledDebugsandVerificationSolution

Problem:SubnettedRoutesMissingfromtheRoutingTableofR2—Cause:AutosummarizationFeatureIsEnabled


TroubleshootingRoutesSummarizationinRIPProblem:RIP-2RoutingTableIsHuge—Cause:AutosummarizationIsOff


Problem:RIP-2RoutingTableIsHuge—Cause:ipsummary-addressIsNotUsedDebugsandVerificationSolution

TroubleshootingRIPRedistributionProblemsDebugsandVerificationSolution

TroubleshootingDial-on-DemandRoutingIssuesinRIPProblem:RIPBroadcastIsKeepingtheISDNLinkUp—Cause:RIPBroadcastsHaveNotBeen

DeniedintheInterestingTrafficDefinitionDebugsandVerificationSolution

Problem:RIPUpdatesAreNotGoingAcrosstheDialerInterface—Cause:MissingbroadcastKeywordinadialermapStatement


TroubleshootingRoutesFlappingProbleminRIPDebugsandVerificationSolution

Chapter4UnderstandingInteriorGatewayRoutingProtocol(IGRP)

Metrics

TimersSplitHorizonSplitHorizonwithPoisonReverse

IGRPPacketFormatIGRPBehaviorDefaultRouteandIGRP

Unequal-CostLoadBalancinginIGRPSummaryReviewQuestions

Chapter5TroubleshootingIGRP

FlowchartstoSolveCommonIGRPProblemsTroubleshootingIGRPRouteInstallation

Problem:IGRPRoutesNotintheRoutingTableIGRPRoutesNotintheRoutingTable—Cause:MissingorIncorrectnetworkStatement


IGRPRoutesNotintheRoutingTable—Cause:Layer1/2IsDownDebugsandVerificationSolution

IGRPRoutesNotintheRoutingTable—Cause:distribute-listinIsBlockingtheRouteDebugsandVerificationSolution

IGRPRoutesNotintheRoutingTable—Cause:AccessListBlockingIGRPSourceAddressDebugsandVerificationSolution

IGRPRoutesNotintheRoutingTable—Cause:AccessListBlockingIGRPBroadcastDebugsandVerificationSolution

IGRPRoutesNotintheRoutingTable—Cause:DiscontiguousNetworkDebugsandVerificationSolution

IGRPRoutesNotintheRoutingTable—Cause:InvalidSourceDebugsandVerificationSolution

IGRPRoutesNotintheRoutingTable—Cause:Layer2Problem(Switch,FrameRelay,OtherLayer2Media)


IGRPRoutesNotintheRoutingTable—Cause:Sender’sASMismatchDebugsandVerificationSolution

Problem:IGRPIsNotInstallingAllPossibleEqual-CostPaths—Cause:maximumpathsRestrictsIGRPtoaMaximumofFourPathsbyDefault


TroubleshootingIGRPRoutesAdvertisementProblem:SenderIsNotAdvertisingIGRPRoutes

SenderIsNotAdvertisingIGRPRoutes—Cause:MissingorIncorrectnetworkStatementDebugsandVerificationSolution

SenderIsNotAdvertisingIGRPRoutes—Cause:OutgoingInterfaceIsDownDebugsandVerificationSolution

SenderIsNotAdvertisingIGRPRoutes—Cause:distribute-listoutIsBlockingtheRouteDebugsandVerificationSolution

SenderIsNotAdvertisingIGRPRoutes—Cause:AdvertisedNetworkInterfaceIsDownDebugsandVerificationSolution

SenderIsNotAdvertisingIGRPRoutes—Cause:OutgoingInterfaceIsDefinedasPassiveDebugsandVerificationSolution

SenderIsNotAdvertisingIGRPRoutes—Cause:BrokenBroadcastCapability(EncapsulationFailureinLayer2)


SenderIsNotAdvertisingIGRPRoutes—Cause:MisconfiguredneighborStatementDebugsandVerificationSolution

SenderIsNotAdvertisingIGRPRoutes—Cause:AdvertisedSubnetIsVLSMDebugsandVerificationSolution

SenderIsNotAdvertisingIGRPRoutes—Cause:SplitHorizonIsEnabledDebugsandVerificationSolution

Problem:CandidateDefaultIsNotBeingAdvertised—Cause:ipdefault-networkCommandIsMissing


TroubleshootingIGRPRedistributionProblemsProblem:RedistributedRoutesAreNotGettingInstalledintheRoutingTable—Cause:MetricIs

NotDefinedDuringRedistributionintoIGRPDebugsandVerificationSolution

TroubleshootingDial-on-DemandRouting(DDR)IssuesinIGRP

Problem:IGRPBroadcastIsKeepingtheISDNLinkUp—Cause:IGRPBroadcastsHaveNotBeenDeniedintheInterestingTrafficDefinition


Problem:IGRPUpdatesAreNotGoingAcrosstheDialerInterface—Cause:MissingBroadcastKeywordinadialermapStatement


TroubleshootingRouteFlappingProbleminIGRPProblem:IGRPRoutesAreFlapping—Cause:PacketDropsonSender’sorReceiver’sInterface


TroubleshootingVarianceProblemProblem:IGRPNotUsingUnequal-CostPathforLoadBalancing—Cause:varianceCommandIs

MissingorMisconfiguredDebugsandVerificationSolution

Chapter6UnderstandingEnhancedInteriorGatewayRoutingProtocol(EIGRP)

MetricsEIGRPNeighborRelationshipsTheDiffusingUpdateAlgorithm

DUALFinite-StateMachineEIGRPReliableTransportProtocol

EIGRPPacketFormatEIGRPBehavior

EIGRPSummarizationEIGRPQueryProcessDefaultRoutesandEIGRP

Unequal-CostLoadBalancinginEIGRPSummaryReviewQuestions

Chapter7TroubleshootingEIGRP

TroubleshootingEIGRPNeighborRelationshipsConsultingtheEIGRPLogforNeighborChangesEIGRPNeighborProblem—Cause:UnidirectionalLinkEIGRPNeighborProblem—Cause:UncommonSubnet

MisconfigurationoftheIPAddressontheInterfacesPrimaryandSecondaryIPAddressesoftheNeighboringInterfaceDon’tMatchSwitchorHubBetweenEIGRPNeighborConnectionIsMisconfiguredorIsLeaking

MulticastPacketstoOtherPortsEIGRPNeighborProblem—Cause:MismatchedMasksEIGRPNeighborProblem—Cause:MismatchedKValuesEIGRPNeighborProblem—Cause:MismatchedASNumberEIGRPNeighborProblem—Cause:StuckinActive

ReviewingtheEIGRPDUALProcessDeterminingActive/StuckinActiveRouteswithshowipeigrptopologyactiveMethodologyforTroubleshootingtheStuckinActiveProblem

TroubleshootingEIGRPRouteAdvertisementEIGRPIsNotAdvertisingRoutestoNeighborsWhentheNetworkAdministratorsThinkThat

ItShouldEIGRPIsNotAdvertisingRoutestoItsNeighbors—Cause:DistributeListEIGRPIsNotAdvertisingRoutestoItsNeighbors—Cause:DiscontiguousNetworksEIGRPIsNotAdvertisingRoutestoNeighbors—Cause:Split-HorizonIssues

EIGRPIsAdvertisingRoutestoNeighborsWhentheNetworkAdministratorsThinkThatItShouldn’t

EIGRPIsAdvertisingRouteswithUnexpectedMetricTroubleshootingEIGRPRouteInstallation

EIGRPIsNotInstallingRoutes—Cause:AutoorManualSummarizationEIGRPIsNotInstallingRoutes—Cause:HigherAdministrativeDistanceEIGRPIsNotInstallingRoutes—Cause:DuplicateRouterIDs

TroubleshootingEIGRPRouteFlappingTroubleshootingEIGRPRouteSummarization

EIGRPSummarizationRouteProblem—Cause:SubnetworksofSummaryRouteDon’tExistinRoutingTable

EIGRPSummarizationRouteProblem—Cause:TooMuchSummarizationTroubleshootingEIGRPRedistributionProblems

TroubleshootingEIGRPDialBackupProblemEIGRPErrorMessagesSummary

Chapter8UnderstandingOpenShortestPathFirst(OSPF)

OSPFPacketDetailsHelloPacketsDatabaseDescriptionPacketsLink-StateRequestPacketsLink-StateUpdatePacketsLink-StateAcknowledgmentPacket

OSPFLSADetailsRouterLSA

RouterLSAExampleNetworkLSA

NetworkLSAExampleSummaryLSA

SummaryLSAExampleExternalLSA

ExternalLSAExampleOSPFAreas

NormalAreasStubAreasTotallyStubbyAreasNot-So-StubbyAreas

Type7LSAsNSSALSAExampleNSSAConfigurationExampleTotallyNot-So-StubbyAreasFilteringinNSSADefaultRoutesinNSSA

OSPFMediaTypes

MultiaccessMediaPoint-to-PointMediaNonbroadcastMultiaccessMedia

BroadcastModelPoint-to-PointModelPoint-to-MultipointModel

DemandCircuitsOSPFMediaTypeSummary

OSPFAdjacenciesOSPFDownStateOSPFAttemptStateOSPFInitStateOSPF2-WayStateOSPFExstartStateOSPFExchangeStateOSPFLoadingStateOSPFFullState

SummaryReviewQuestions

Chapter9TroubleshootingOSPF

FlowchartstoSolveCommonOSPFProblemsTroubleshootingOSPFNeighborRelationshipsProblem:OSPFNeighborListIsEmpty

OSPFNeighborListIsEmpty—Cause:OSPFNotEnabledontheInterfaceDebugsandVerificationSolution

OSPFNeighborListIsEmpty—Cause:Layer1/2IsDownDebugsandVerificationSolution

OSPFNeighborListIsEmpty—Cause:InterfaceIsDefinedasPassiveUnderOSPFDebugsandVerificationSolution

OSPFNeighborListIsEmpty—Cause:AccessListBlockingOSPFHellosonBothSidesDebugsandVerificationSolution

OSPFNeighborListIsEmpty—Cause:MismatchedSubnetNumber/MaskoveraBroadcastLink


OSPFNeighborListIsEmpty—Cause:MismatchedHello/DeadIntervalsDebugsandVerificationSolution

OSPFNeighborListIsEmpty—Cause:MismatchedAuthenticationTypeDebugsandVerificationSolution

OSPFNeighborListIsEmpty—Cause:MismatchedAuthenticationKeyDebugsandVerificationSolution

OSPFNeighborListIsEmpty—Cause:MismatchedAreaIDDebugsandVerificationSolution

OSPFNeighborListIsEmpty—Cause:MismatchedStub/Transit/NSSAAreaOptionsDebugsandVerificationSolution

OSPFNeighborListIsEmpty—Cause:OSPFAdjacencyOverSecondaryIPAddressDebugsandVerificationSolution

OSPFNeighborListIsEmpty—Cause:OSPFAdjacencyoverAsynchronousInterfaceDebugsandVerificationSolution

OSPFNeighborListIsEmpty—Cause:NoNetworkTypeorNeighborDefinedoverNBMADebugsandVerificationSolution

OSPFNeighborListIsEmpty—Cause:FrameRelay/DialerInterfaceMissingthebroadcastKeywordonBothSides


Problem:OSPFNeighborStuckinATTEMPTOSPFNeighborStuckinATTEMPT—Cause:MisconfiguredneighborStatement


OSPFNeighborStuckinATTEMPT—Cause:UnicastConnectivityIsBrokenonNBMADebugsandVerificationSolution

Problem:OSPFNeighborStuckinINIT

OSPFNeighborStuckinINIT—Cause:AccessListonOneSideIsBlockingOSPFHellosDebugsandVerificationSolution

OSPFNeighborStuckinINIT—Cause:MulticastCapabilitiesAreBrokenonOneSide(6500SwitchProblem)


OSPFNeighborStuckinINIT—Cause:Cause:AuthenticationIsEnabledOnlyonOneSideDebugsandVerificationSolution

OSPFNeighborStuckinINIT—Cause:Theframe-relaymap/dialer-mapStatementonOneSideIsMissingthebroadcastKeyword


OSPFNeighborStuckinINIT—Cause:HellosAreGettingLostonOneSideatLayer2DebugsandVerificationSolution

Problem:OSPFNeighborStuckin2-WAY—Cause:Priority0IsConfiguredonAllRoutersDebugsandVerificationSolution

Problem:OSPFNeighborStuckinEXSTART/EXCHANGEOSPFNeighborStuckinEXSTART/EXCHANGE—Cause:MismatchedInterfaceMTU

DebugsandVerificationSolutions

OSPFNeighborStuckinEXSTART/EXCHANGE—Cause:DuplicateRouterIDsonNeighbors


OSPFNeighborStuckinEXSTART/EXCHANGE—Cause:Can’tPingAcrosswithMoreThanCertainMTUSize


OSPFNeighborStuckinEXSTART/EXCHANGE—Cause:UnicastConnectivityIsBrokenDebugsandVerificationSolutions

OSPFNeighborStuckinEXSTART/EXCHANGE—Cause:NetworkTypeIsPoint-to-PointBetweenPRIandBRI/Dialer


Problem:OSPFNeighborStuckinLOADINGOSPFNeighborStuckinLOADING—Cause:MismatchedMTUSize


OSPFNeighborStuckinLOADING—Cause:Link-StateRequestPacketIsCorruptedDebugsandVerificationSolution

TroubleshootingOSPFRouteAdvertisement

Problem:OSPFNeighborIsNotAdvertisingRoutesOSPFNeighborIsNotAdvertisingRoutes—Cause:OSPFNotEnabledontheInterfaceThat

IsSupposedtoBeAdvertisedDebugsandVerificationSolution

OSPFNeighborIsNotAdvertisingRoutes—Cause:AdvertisingInterfaceIsDownDebugsandVerificationSolution

OSPFNeighborIsNotAdvertisingRoutes—Cause:SecondaryInterfaceIsinaDifferentAreaThanthePrimaryInterface


Problem:OSPFNeighbor(ABR)NotAdvertisingtheSummaryRouteOSPFNeighbor(ABR)NotAdvertisingtheSummaryRoute—Cause:AreaIsConfiguredas

TotallyStubbyAreaDebugsandVerificationSolution

OSPFNeighbor(ABR)NotAdvertisingtheSummaryRoute—Cause:ABRIsNotConnectedtoArea0


OSPFNeighbor(ABR)NotAdvertisingtheSummaryRoute—Cause:DiscontiguousArea0DebugsandVerificationSolution

Problem:OSPFNeighborIsNotAdvertisingExternalRoutesOSPFNeighborIsNotAdvertisingExternalRoutes—Cause:AreaIsConfiguredasaStub

AreaorNSSADebugsandVerificationSolution

OSPFNeighborIsNotAdvertisingExternalRoutes—Cause:NSSAABRNotTranslatingType7LSAsintoType5LSAs


Problem:OSPFNeighborNotAdvertisingDefaultRoutesOSPFNeighborNotAdvertisingDefaultRoutes—Cause:Missingdefaultinformation

originateCommandsDebugsandVerificationSolution

OSPFNeighborNotAdvertisingDefaultRoutes—Cause:DefaultRouteMissingfromtheNeighbor’sRoutingTable


OSPFNeighborNotAdvertisingDefaultRoutes—Cause:NeighborTryingtoInjectaDefaultintoaStubArea


OSPFNeighborNotAdvertisingDefaultRoutes—Cause:NSSAABR/ASBRNotOriginatingType7Default


TroubleshootingOSPFRouteInstallationProblem:OSPFNotInstallingAnyRoutesintheRoutingTable

OSPFNotInstallingAnyRoutesintheRoutingTable—Cause:NetworkTypeMismatchDebugsandVerificationSolution

OSPFNotInstallingAnyRoutesintheRoutingTable—Cause:IPAddressesAreFlippedinDualSerial-ConnectedRouters


OSPFNotInstallingAnyRoutesintheRoutingTable—Cause:OneSideIsaNumberedandtheOtherSideIsanUnnumberedPoint-to-PointLink


OSPFNotInstallingAnyRoutesintheRoutingTable—Cause:DistributeListIsBlockingtheRouteInstallation


OSPFNotInstallingAnyRoutesintheRoutingTable—Cause:BrokenPVCinaFullyMeshedFrameRelayNetworkwithBroadcastNetworkType

DebugsandVerification

SolutionProblem:OSPFNotInstallingExternalRoutesintheRoutingTable

OSPFNotInstallingExternalRoutesintheRoutingTable—Cause:ForwardingAddressIsNotKnownThroughtheIntra-AreaorInterareaRoute


OSPFNotInstallingExternalRoutesintheRoutingTable—Cause:ABRNotGeneratingType4SummaryLSA


TroubleshootingRedistributionProblemsinOSPFProblem:OSPFNeighborIsNotAdvertisingExternalRoutes

OSPFNeighborIsNotAdvertisingExternalRoutes—Cause:SubnetsKeywordMissingfromtheASBRConfiguration


OSPFNeighborIsNotAdvertisingExternalRoutes—Cause:distribute-listoutIsBlockingtheRoutes


TroubleshootingRouteSummarizationinOSPF

Problem:RouterIsNotSummarizingInterareaRoutes—Cause:arearangeCommandIsNotConfiguredonABR


Problem:RouterIsNotSummarizingExternalRoutes—Cause:summary-addressCommandIsNotConfiguredonASBR


TroubleshootingCPUHOGProblemsProblem:CPUHOGMessagesDuringAdjacencyFormation—Cause:RouterIsNotRunning

Packet-PacingCodeDebugsandVerificationSolution

Problem:CPUHOGMessagesDuringLSARefreshPeriod—Cause:RouterIsNotRunningLSAGroup-PacingCode


TroubleshootingDial-on-DemandRoutingIssuesinOSPFProblem:OSPFHellosAreBringingUptheLink—Cause:OSPFHellosArePermittedas

InterestingTrafficDebugsandVerificationSolution

Problem:DemandCircuitKeepsBringingUptheLinkDemandCircuitKeepsBringingUptheLink—Cause:ALinkFlapintheNetwork


DemandCircuitKeepsBringingUptheLink—Cause:NetworkTypeDefinedasBroadcastDebugsandVerificationSolution

DemandCircuitKeepsBringingUptheLink—Cause:PPPHostRoutesAreGettingRedistributedintotheOSPFDatabase


DemandCircuitKeepsBringingUptheLink—Cause:OneoftheRoutersIsNotDemandCircuit–Capable


TroubleshootingSPFCalculationandRouteFlappingSPFRunningConstantly—Cause:InterfaceFlapWithintheNetwork


SPFRunningConstantly—Cause:NeighborFlapWithintheNetworkDebugsandVerificationSolution

SPFRunningConstantly—Cause:DuplicateRouterIDDebugsandVerificationSolution

CommonOSPFErrorMessages“Unknownroutingprotocol”ErrorMessage

OSPF:“Couldnotallocaterouterid”ErrorMessage“%OSPF-4-BADLSATYPE:Invalidlsa:BadLSAtype”Type6ErrorMessage“OSPF-4-ERRRCV”ErrorMessage

MismatchedAreaIDBadChecksum

OSPFNotEnabledontheReceivingInterface

Chapter10UnderstandingIntermediateSystem-to-IntermediateSystem(IS-IS)

IS-ISProtocolOverviewIS-ISRoutingProtocol

IS-ISProtocolConceptsIS-ISNodes,Links,andAreasAdjacencies

ES-ISAdjacenciesIS-ISAdjacencies

HierarchicalRoutingIS-ISPackets

GenericIS-ISPacketFormatIS-ISMetricsIS-ISAuthenticationISOCLNPAddressing

NSAPFormatNSAPExamplesGuidelinesforDefiningNSAPAddresses

IS-ISLink-StateDatabaseOverviewoftheIS-ISLink-StateDatabaseFloodingandDatabaseSynchronizationShortestPathFirst(SPF)AlgorithmandIS-ISRouteCalculation

ConfiguringIS-ISforIPRoutingConfiguringIS-ISonPoint-to-PointSerialLinks

showclnsprotocolCommandshowclnsneighborsdetailCommandshowclnsinterfaceCommandshowisistopologyCommandshowisisdatabaseCommand

ATMConfigurationExamplesIPDefaultRouteAdvertisementRouteRedistributionIPRouteSummarization

SummaryAdditionalIS-ISPacketInformation

IS-ISPacketFields(AlphabeticalOrder)HelloPackets

Link-StatePacketsSequenceNumberPackets

ReviewQuestionsFurtherReading

Chapter11TroubleshootingIS-IS

TroubleshootingIS-ISAdjacencyProblemsProblem1:SomeorAlloftheAdjacenciesAreNotComingUp

Step1:CheckingforLinkFailuresStep2:VerifyingBasicConfigurationStep3:CheckingforMismatchedLevel1andLevel2InterfacesStep4:CheckingforAreaMisconfigurationStep5:CheckingforMisconfiguredIPSubnetsStep6:CheckforDuplicateSystemIDs

Problem2:AdjacencyinINITStateMismatchedMTUIS-ISHelloPaddingMisconfiguredAuthentication

Problem3:OnlyES-ISAdjacencyInsteadofIS-ISAdjacencyFormedTroubleshootingIS-ISRoutingUpdateProblems

RouteAdvertisementProblemsLocalRoutesNotBeingAdvertisedtoRemoteSolutionSummary

RouteRedistributionandLevel2–to–Level1Route-LeakingProblemsRoute-FlappingProblem

SolutionSummaryIS-ISErrors

CLNSpingandtracerouteCaseStudy:ISDNConfigurationProblemIS-ISTroubleshootingCommandSummary

Summary

Chapter12UnderstandingProtocolIndependentMulticast(PIM)

FundamentalsofIGMPVersion1,IGMPVersion2,andReversePathForwardingIGMPVersion1IGMPVersion2MulticastForwarding(ReversePathForwarding)

PIMDenseMode

PIMSparseModeIGMPandPIMPacketFormat

IGMPPacketFormatPIMPacket/MessageFormats

Summary

ReviewQuestions

Chapter13TroubleshootingPIM

TroubleshootingIGMPJoinsSolutiontoIGMPJoinProblem

TroubleshootingPIMDenseModeSolutiontoPIMDenseModeProblem

TroubleshootingPIMSparseModeSolutiontoPIMSparseModeProblem

Summary

Chapter14UnderstandingBorderGatewayProtocolVersion4(BGP-4)

BGP-4ProtocolSpecificationandFunctionalityNeighborRelationships

ExternalBGPNeighborRelationshipsInternalBGPNeighborRelationships

AdvertisingRoutesSynchronizationRule

ReceivingRoutesPolicyControl

PolicyControlUsingBGPAttributesLOCAL_PREFAttributeMULTI_EXIT_DISC(MED)AttributeAS_PATHAttributeNEXT_HOPAttributeORIGINAttributeWEIGHT:CiscoSystems,Inc.ProprietaryAttributeReadingBGPAttributesfromCiscoIOSSoftwareOutput

UseofRouteMapsinPolicyControlUsingthematchipaddressCommandinaRouteMapUsingthematchcommunityCommandinaRouteMapUsingthematchas-pathCommandinaRouteMapUsingthesetas-pathprependCommandinaRouteMap

UsingthesetcommunityCommandinaRouteMapUsingthesetlocal-preferenceCommandinaRouteMapUsingthesetmetricCommandinaRouteMapUsingthesetweightCommandinaRouteMap

PolicyControlUsingfilter-list,distribute-list,prefix-list,Communities,andOutboundRouteFiltering(ORF)

UseofFilterListsinPolicyControlUseofDistributeListsinPolicyControlUseofPrefixListsinPolicyControlUseofCommunitiesinPolicyControlUseofOutboundRouteFilteringinPolicyControl

RouteDampening

ScalingIBGPinLargeNetworks—RouteReflectorsandConfederationsRouteReflectionASConfederations

Best-PathCalculationSummaryReviewQuestions

Chapter15TroubleshootingBGP

FlowchartstoSolveCommonBGPProblemsshowanddebugCommandsforBGP-RelatedTroubleshooting

showipbgpprefixCommandshowipbgpsummaryCommandshowipbgpneighbor[address]Commandshowipbgpneighbors[address][advertised-routes]Commandshowipbgpneighbors[routes]Commanddebugipbgpupdate[access-list]Command

StandardAccessListUsageExtendedAccessListUsage

debugipbgpneighbor-ip-addressupdates[access-list]Command

TroubleshootingBGPNeighborRelationshipsProblem:DirectlyConnectedExternalBGPNeighborsNotInitializing

DirectlyConnectedExternalBGPNeighborsNotComingUp—Cause:Layer2IsDown,PreventingCommunicationwithDirectlyConnectedBGPNeighbor


DirectlyConnectedExternalBGPNeighborsNotComingUp—Cause:IncorrectNeighborIP

AddressinBGPConfigurationDebugsandVerificationSolution

Problem:NondirectlyConnectedExternalBGPNeighborsNotComingUpNondirectlyConnectedExternalBGPNeighborsNotComingUp—Cause:Routetothe

NondirectlyConnectedPeerAddressIsMissingfromtheRoutingTableDebugsandVerificationSolution

NondirectlyConnectedExternalBGPNeighborsNotComingUp—Cause:ebgpmultihopCommandIsMissinginBGPConfiguration


NondirectlyConnectedExternalBGPNeighborsNotComingUp—Cause:updatesourceinterfaceCommandIsMissing


Problem:InternalBGPNeighborsNotComingUp

Problem:BGPNeighbors(ExternalandInternal)NotComingUp—Cause:InterfaceAccessListBlockingBGPPackets


TroubleshootingBGPRouteAdvertisement/OriginationandReceivingProblem:BGPRouteNotGettingOriginated

BGPRouteNotGettingOriginated—Cause:IPRoutingTableDoesNotHaveaMatchingRoute


BGPRouteNotGettingOriginated—Cause:ConfigurationErrorDebugsandVerificationSolution

BGPRouteNotGettingOriginated—Cause:BGPIsAutosummarizingtoClassful/NetworkBoundary


ProbleminPropagating/OriginatingBGPRoutetoIBGP/EBGPNeighbors—Cause:MisconfiguredFilters


ProbleminPropagatingBGPRoutetoIBGPNeighborbutNottoEBGPNeighbor—Cause:BGPRouteWasfromAnotherIBGPSpeaker


IBGPFullMeshDesigningaRoute-ReflectorModelDesigningaConfederationModel

ProbleminPropagatingIBGPRoutetoIBGP/EBGPNeighbor—Cause:IBGPRouteWasNotSynchronized


TroubleshootingBGPRouteNotInstallinginRoutingTableProblem:IBGP-LearnedRouteNotGettingInstalledinIPRoutingTable

IBGP-LearnedRouteNotGettingInstalledinIPRoutingTable—Cause:IBGPRoutesAreNotSynchronized


IBGP-LearnedRouteNotGettingInstalledinIPRoutingTable—Cause:IBGPNextHopNotReachable


AnnouncetheEBGPNextHopThroughanIGPUsingaStaticRouteorRedistributionChangetheNextHoptoanInternalPeeringAddress

Problem:EBGP-LearnedRouteNotGettingInstalledinIPRoutingTableEBGP-LearnedRouteNotGettingInstalledinIPRoutingTable—Cause:BGPRoutesAre

DampenedDebugsandVerificationSolution

EBGP-LearnedRouteNotGettingInstalledinIPRoutingTable—Cause:BGPNextHopNotReachableinCaseofMultihopEBGP


EBGP-LearnedRouteNotGettingInstalledintheRoutingTable—Cause:MultiexitDiscriminator(MED)ValueIsInfinite

DebugsandVerificationTroubleshootingBGPRoute-ReflectionIssues

Problem:ConfigurationMistakes—Cause:FailedtoConfigureIBGPNeighborasaRoute-ReflectorClient


SolutionProblem:Route-ReflectorClientStoresanExtraBGPUpdate—Cause:Client-to-Client

ReflectionDebugsandVerificationSolution

Problem:ConvergenceTimeImprovementforRRandClients—Cause:UseofPeerGroupsDebugsandVerificationSolution

Problem:LossofRedundancyBetweenRouteReflectorsandRoute-ReflectorClient—Cause:ClusterListCheckinRRDropsRedundantRoutefromOtherRR


TroubleshootingOutboundIPTrafficFlowIssuesBecauseofBGPPolicies

Problem:MultipleExitPointsExistbutTrafficGoesOutThroughOneorFewExitRouters—Cause:BGPPolicyDefinitionCausesTraffictoExitfromOnePlace

SolutionProblem:TrafficTakesaDifferentInterfacefromWhatShowsinRoutingTable—Cause:Next

HopoftheRouteIsReachableThroughAnotherPathDebugsandVerificationSolution

Problem:MultipleBGPConnectionstotheSameBGPNeighborAS,butTrafficGoesOutThroughOnlyOneConnection—Cause:BGPNeighborIsInfluencingOutboundTrafficbySendingMEDorPrependedAS_PATH

SolutionRequestAS110toSendtheProperMEDforEachPrefixDon’tAcceptMEDfromAS110ManuallyChangeLOCAL_PREFERENCEforP1,P2,andP3atAlltheExitPointsX,Y,

andZProblem:AsymmetricalRoutingOccursandCausesaProblemEspeciallyWhenNATandTime-

SensitiveApplicationsAreUsed—Cause:OutboundandInboundAdvertisementDebugsandVerificationSolution

TroubleshootingLoad-BalancingScenariosinSmallBGPNetworksProblem:LoadBalancingandManagingOutboundTrafficfromaSingleRouterWhen

DualhomedtoSameISP—Cause:BGPInstallsOnlyOneBestPathintheRoutingTableDebugsVerificationSolutionProblem:LoadBalancingandManagingOutboundTrafficinanIBGPNetwork—Cause:By

Default,IBGPinCiscoIOSSoftwareAllowsOnlyaSinglePathtoGetInstalledintheRouting

TableEvenThoughMultipleEqualBGPPathsExistDebugsandVerificationSolution

TroubleshootingInboundIPTrafficFlowIssuesBecauseofBGPPoliciesProblem:MultipleConnectionsExisttoanAS,butAlltheTrafficComesinThroughOneBGP

Neighbor,X,inthesameAS—Cause:EitherBGPNeighboratXHasaBGPPolicyConfiguredtoMakeItselfPreferredovertheOtherPeeringPoints,ortheNetworksAreAdvertisedtoAttractTrafficfromOnlyX

DebugsandVerificationCase1Case2

SolutionProblem:MultipleConnectionsExisttoSeveralBGPNeighbors,butMostoftheTrafficfrom

Internetto100.100.100.0/24AlwaysComesinThroughOneBGPNeighborfromAS110—Cause:RouteAdvertisementsfor100.100.100.0/24inAS109AttractInternetTrafficThroughThatBGPNeighborinAS110

Solution

TroubleshootingBGPBest-PathCalculationIssuesProblem:PathwithLowestRIDIsNotChosenasBest


Problem:LowestMEDNotSelectedasBestPathDebugsandVerificationSolution

TroubleshootingBGPFilteringProblem:StandardAccessListFailstoCaptureSubnets


Problem:ExtendedAccessListsFailstoCapturetheCorrectMaskedRouteDebugsandVerificationSolution

ExtendedAccessListSolution

Problem:AS_PATHFilteringUsingRegularExpressionsSummary

AppendixAnswerstoReviewQuestionsIndex

Preface

SittinginmyofficeatCiscoonthethirdfloorofbuildingK,Ireadane-mailfromKathyTracefromCiscoPressaskingifIwasinterestedinwritingabook.ShehadreadmytechnicaltipsthatIhadwrittenforCiscoConnectionOnlineandsaidthatshewantedmeasanauthorforCiscoPress.Iwasveryenthusiasticaboutitandsaidtomyself,“Yeah!It’sagreatidea!Let’swriteabook!”Butonwhatsubject?OneofthetopicsthatIhadinmindwasOSPF.Johnsonusedtositrightinfrontofmyofficeatthattime.Iaskedhim,“Hey,Johnson!Youwanttowriteabookwithme?”Hescreamed,“Abook!”Isaid,“Yeah,abook!Whatdoyouthink?”Hethoughtforaminuteandsaid,“Well,whatisleftforustowriteabookon?CiscoPressauthorshavewrittenbooksonalmosteveryroutingtopic....Butthereisonesubjectthathasnotbeencoveredinonesinglebook—troubleshootingIProutingprotocols.”Apparently,Johnsongottheideatowriteatroubleshootingbookfromhiswife.WheneverJohnson’swifecallshimatwork,hehastoputheronholdbecauseheisbusytroubleshootingacustomer’sproblem.Hiswife,whosenameisalsoCisco,thengavehimtheideaofwritingatroubleshootingbooksothatcustomerswouldhaveatroubleshootingguideonroutingprotocolsthattheycanrefertosothattheycansuccessfullysolvetheirproblemsbeforeopeningacase.Theideawasindeedgreat.Nobookshadbeenwrittenonthisparticularsubjectbefore.IthencalledZaheer,whowasattendingIETF46inWashington,D.C.,andtoldhimaboutthis;healsoagreedthattheideawasagoodone.SonowwehadateamofthreeTACengineerswhohadspentthelastthreetofouryearsinTACdealingwithroutingproblems—andeachoneofuswasanexpertinoneortwoprotocols.Ourmanager,RajaSundaram,usedtosay,“Iwantyoutopickupaprotocolandbecomeanexpertinit.”MyareaofexpertisewasOSPF,JohnsonwasaguruofEIGRPandmulticasting,andZaheershonewithhisBGPknowledge.Verysoon,werealizedthatweweremissingoneimportantprotocol,IS-IS.OurexposurewithIS-ISwasnotatalevelthatwecouldwriteawholechapterontroubleshootingIS-IS,soZaheersuggestedAbeMarteyforthisjob.AbewasalreadyengagedinwritingabookonIS-ISwithCiscoPress,butafterseeingourenthusiasmaboutthisbook,heagreedtobecomeamemberofourauthorteam.Whenwestartedworkingonthesechapters,werealizedthatwewereworkingonsomethingthataroutingnetworkadministratorhadalwaysdreamedof—atroubleshootingbookthatcontainssolutionsforalltheIProutingprotocolproblems.Thedatathatwecollectedforthisbookcamefromtheactualproblemswehaveseenincustomernetworksinourcombined20yearsofexperienceintroubleshootingIPnetworks.Wewantedtomakeitaone-stopshopfortroubleshootingguidanceandreference.So,weprovidedthe“understandingprotocols”chaptersalongwithtroubleshootingtohelpyou,thereader,gobacktoaspecificprotocolandrefreshyourmemory.ThisbookisalsoanexcellentresourceforpreparationfortheCCIEcertification.ThisbookshouldteachyouhowtotackleanyIProutingproblemthatpopsupinyournetwork.Allpossiblecasesmightnotbediscussed,butgeneralguidelinesandtechniquesteachalogicalapproachforsolvingtypicalproblemsthatyoumightface.

SyedFarazShamim

Introduction

AstheInternetcontinuestogrowexponentially,theneedfornetworkengineerstobuild,maintain,andtroubleshootthegrowingnumberofcomponentnetworksalsohasincreasedsignificantly.Becausenetworktroubleshootingisapracticalskillthatrequireson-the-jobexperience,ithasbecomecriticalthatthelearningcurvenecessarytogainexpertiseininternetworkingtechnologiesbereducedtoquicklyfillthevoidofskillednetworkengineersneededtosupportthefast-growingInternet.IProutingisatthecoreofInternettechnology,andexpedienttroubleshootingofIProutingfailuresiskeytoreducingnetworkdowntime.Reducingnetworkdowntimeiscrucialasthelevelofmission-criticalapplicationscarriedovertheInternetincreases.Thisbookgivesyouthedetailedknowledgetotroubleshootnetworkfailuresandmaintaintheintegrityoftheirnetworks.TroubleshootingIPRoutingProtocolsprovidesauniqueapproachtotroubleshootingIProutingprotocolsbyfocusingonstep-by-stepguidelinesforsolvingaparticularroutingfailurescenario.TheculminationofyearsofexperiencewithCisco’sTACgroup,thisbookofferssoundmethodologyandsolutionsforresolvingroutingproblemsrelatedtoBGP,OSPF,IGRP,EIGRP,IS-IS,RIP,andPIMbyfirstprovidinganoverviewtoroutingandthenconcentratingonthetroubleshootingstepsthatanengineerwouldtakeinresolvingvariousroutingprotocolissuesthatariseinanetwork.Thisbookoffersyouafullunderstandingoftroubleshootingtechniquesandreal-worldexamplestohelpyouhonetheskillsneededtosuccessfullycompletetheCCIEexam,aswellasperformthedutiesexpectedofaCCIE-levelcandidate.

WhoShouldReadThisBook?Thisisanintermediate-levelbookthatassumesthatyouhaveageneralunderstandingofIProutingtechnologiesandotherrelatedprotocolsandtechnologiesusedinbuildingIPnetworks.Theprimaryaudienceforthisbookconsistsofnetworkadministratorsandnetworkoperationengineersresponsibleforthehighavailabilityoftheirnetworks,orthosewhoplantobecomeCiscoCertifiedInternetworkExperts.

HowThisBookIsOrganizedAlthoughthisbookcouldbereadcovertocover,itisdesignedtobeflexibleandtoallowyoutoeasilymovebetweenchaptersandsectionsofchapterstocoverjustthematerialthatyouneedmoreworkwith.•Chapter1,“UnderstandingIPRouting”—ThischapterprovidesanoverviewofIProutingprotocolswithfocusonthefollowingtopics:

—IPaddressingconcepts—Staticanddynamicroutes—Dynamicrouting—Routingprotocoladministrativedistance—Fastforwardinginrouters

Theremainingchaptersalternatebetweenchaptersthatprovidescoverageofkeyaspectsofaspecificroutingprotocolandchaptersdevotedtopractical,real-worldtroubleshootingmethodsforthatroutingprotocol.Thelistthatfollowsprovidesmoredetailedinformation:•Chapter2,“UnderstandingRoutingInformationProtocol(RIP)”—ThischapterfocusesonthekeyaspectsofRIPneededtoconfidentlytroubleshootRIPproblems.Topicsincludethefollowing:

—Metrics—Timers—Splithorizon—Splithorizonwithpoisonreverse—RIP-1packetformat—RIPbehavior—WhyRIPdoesn’tsupportdiscontiguousnetworks—WhyRIPdoesn’tsupportvariable-lengthsubnetmasking(VLSM)—DefaultroutesandRIP—ProtocolextensiontoRIP—Compatibilityissues

•Chapter3,“TroubleshootingRIP”—ThischapterprovidesamethodicalapproachtoresolvingcommonRIPproblems,whichincludethefollowing:

—TroubleshootingRIProuteinstallation—TroubleshootingRIProuteadvertisement—TroubleshootingroutessummarizationinRIP—TroubleshootingRIPredistributionproblems—Troubleshootingdial-on-demandrouting(DDR)issuesinRIP—Troubleshootingtheroute-flappingprobleminRIP

•Chapter4,“UnderstandingInteriorGatewayRoutingProtocol(IGRP)”—ThischapterfocusesonthekeyaspectsofIGRPneededtoconfidentlytroubleshootIGRPproblems.Topicsincludethefollowing:

—Metrics—Timers—Splithorizon—Splithorizonandpoisonreverse—IGRPpacketformat—IGRPbehavior—DefaultrouteandIGRP—Unequal-costloadbalancinginIGRP

•Chapter5,“TroubleshootingIGRP”—ThischapterprovidesamethodicalapproachtoresolvingcommonIGRPproblems,whichincludethefollowing:

—TroubleshootingIGRProuteinstallation—TroubleshootingIGRProuteadvertisement—TroubleshootingIGRPredistributionproblems—Troubleshootingdial-on-demandrouting(DDR)issuesinIGRP—TroubleshootingrouteflappinginIGRP—Troubleshootingvarianceproblem

•Chapter6,“UnderstandingEnhancedInteriorGatewayRoutingProtocol(EIGRP)”—This

chapterfocusesonthekeyaspectsofEIGRPneededtoconfidentlytroubleshootEIGRPproblems.Topicsincludethefollowing:

—Metrics—EIGRPneighborrelationships—TheDiffusingUpdateAlgorithm(DUAL)—DUALfinitestatemachine—EIGRPreliabletransportprotocol—EIGRPpacketformat—EIGRPbehavior—EIGRPsummarization—EIGRPqueryprocess—DefaultrouteandEIGRP—Unequal-costloadbalancinginEIGRP

•Chapter7,“TroubleshootingEIGRP”—ThischapterprovidesamethodicalapproachtoresolvingcommonEIGRPproblems,whichincludethefollowing:

—TroubleshootingEIGRPneighborrelationships—TroubleshootingEIGRProuteadvertisement—TroubleshootingEIGRProuteinstallation—TroubleshootingEIGRProuteflapping—TroubleshootingEIGRProutesummarization—TroubleshootingEIGRProuteredistribution—TroubleshootingEIGRPdialbackup—EIGRPerrormessages

•Chapter8,“UnderstandingOpenShortestPathFirst(OSPF)”—ThischapterfocusesonthekeyaspectsofOSPFneededtoconfidentlytroubleshootOSPFproblems.Topicsincludethefollowing:

—OSPFpacketdetails—OSPFLSAdetails—OSPFareas—OSPFmediatypes—OSPFadjacencies

•Chapter9,“TroubleshootingOSPF”—ThischapterprovidesamethodicalapproachtoresolvingcommonOSPFproblems,whichincludethefollowing:

—TroubleshootingOSPFneighborrelationships—TroubleshootingOSPFrouteadvertisement—TroubleshootingOSPFrouteinstallation—TroubleshootingredistributionproblemsinOSPF—TroubleshootingroutesummarizationinOSPF—TroubleshootingCPUHOGproblems—Troubleshootingdial-on-demandrouting(DDR)issuesinOSPF

—TroubleshootingSPFcalculationandrouteflapping—CommonOSPFerrormessages

•Chapter10,“UnderstandingIntermediateSystem-to-IntermediateSystem(IS-IS)”—ThischapterfocusesonthekeyaspectsofIS-ISneededtoconfidentlytroubleshootIS-ISproblems.Topicsincludethefollowing:

—IS-ISprotocoloverview—IS-ISprotocolconcepts—IS-ISlink-statedatabase—ConfiguringIS-ISforIProuting

•Chapter11,“TroubleshootingIS-IS”—ThischapterprovidesamethodicalapproachtoresolvingcommonIS-ISproblems,whichincludethefollowing:

—TroubleshootingIS-ISadjacencyproblems—TroubleshootingIS-ISroutingupdateproblems—IS-ISerrors—CLNSpingandtraceroute—Casestudy:ISDNconfigurationproblem

•Chapter12,“UnderstandingProtocolIndependentMulticast(PIM)”—ThischapterfocusesonthekeyaspectsofPIMneededtoconfidentlytroubleshootPIMproblems.Topicsincludethefollowing:

—FundamentalsofIGMPVersion1,IGMPVersion2,andreversepathforwarding(RPF)—PIMdensemode—PIMsparsemode—IGMPandPIMpacketformat

•Chapter13,“TroubleshootingPIM”—ThischapterprovidesamethodicalapproachtoresolvingcommonPIMproblems,whichincludethefollowing:

—IGMPjoinsissues—PIMdensemodeissues—PIMsparsemodeissues

•Chapter14,“UnderstandingBorderGatewayProtocolVersion4(BGP-4)”—ThischapterfocusesonthekeyaspectsofBGPneededtoconfidentlytroubleshootBGPproblems.Topicsincludethefollowing:

—BGP-4protocolspecificationandfunctionality—Neighborrelationships—Advertisingroutes—Synchronization—Receivingroutes—Policycontrol—ScalingIBGPnetworks(routereflectorsandconfederations)—Best-pathcalculation

•Chapter15,“TroubleshootingBGP”—Thischapterprovidesamethodicalapproachtoresolving

commonBGPproblems,whichincludethefollowing:—TroubleshootingBGPneighborrelationships—TroubleshootingBGProuteadvertisement/originationandreceiving—TroubleshootingaBGProutenotinstallinginaroutingtable—TroubleshootingBGPwhenroutereflectorsareused—TroubleshootingoutboundtrafficflowissuesbecauseofBGPpolicies—Troubleshootingload-balancingscenariosinsmallBGPnetworks—TroubleshootinginboundtrafficflowissuesbecauseofBGPpolicies—TroubleshootingBGPbest-pathcalculationissues—TroubleshootingBGPfiltering

IconsUsedinThisBook

CommandSyntaxConventionsTheconventionsusedtopresentcommandsyntaxinthisbookarethesameconventionsusedintheIOSCommandReference.TheCommandReferencedescribestheseconventionsasfollows:•Verticalbars(|)separatealternative,mutuallyexclusiveelements.•Squarebrackets[]indicateoptionalelements.•Braces{}indicatearequiredchoice.•Braceswithinbrackets[{}]indicatearequiredchoicewithinanoptionalelement.•Boldfaceindicatescommandsandkeywordsthatareenteredliterallyasshown.Inactualconfigurationexamplesandoutput(notgeneralcommandsyntax),boldfaceindicatescommandsthataremanuallyinputbytheuser(suchasashowcommand).•Italicsindicateargumentsforwhichyousupplyactualvalues.

Chapter1.UnderstandingIPRouting

TheprimaryobjectiveofthisbookistoprovideelaborateguidancefortroubleshootingInternetProtocol(IP)routingproblemsonCiscorouters.Inthisregard,thesubsequenttextcoverswell-knownroutingprotocolssuchasthefollowing:•OpenShortestPathFirstProtocol(OSPF)•IntegratedIntermediateSystem-to-IntermediateSystemProtocol(IS-IS)•BorderGatewayProtocol(BGP)•ProtocolIndependentMulticast(PIM)formulticastrouting

ThischapterpresentsanintroductiontoIProutingandprovidesinsightstorelatedconcepts,suchasIPaddressingandvariousclassificationsofIProutingprotocols.Thechapteralsoprovidesahigh-leveloverviewofimplementationandconfigurationconcepts,suchasroutefilteringandredistribution.TheTransmissionControlProtocol/InternetProtocol(TCP/IP)suiteofprotocolsistheunderlyingtechnologyforinformationexchangeontheInternet.TCP/IPusesalayeringapproachforcomputercommunicationssimilartotheOpenSystemInterconnection(OSI)referencemodel,butwithfewerthansevenlayers.Figure1-1showstheOSIreferencemodelandtheTCP/IPstacksidebyside.Relatedlayersbetweenthetwostacksareindicatedinthefigure.

Figure1-1OSIReferenceModelandTCP/IPStack

IPoperatesattheInternetlayeroftheTCP/IPsuite,whichcorrespondstothenetworklayeroftheOSIreferencemodel.IPprovidesconnectionlessdata-deliveryservices,whichinvolvetransmissionofinformationfromonepartofanetworktoanotherinunitsofdataknownaspacketsordatagrams.Theessenceofthedatagramdeliveryservicemodelisthatapermanentpre-establishedend-to-endpathisnotrequiredfordatatransferbetweentwopointsinanetwork.Inapacket-basednetwork,eachrouterinthetransmissionpathmakesindependentlocaldecisionsregardingtheoptimalforwardingpathtowardthe

destinationforanytransitpacket.Thedecision-makingisbasedonforwardingintelligencegatheredeitherdynamicallybymeansofaroutingprotocolormanuallyprogrammedstaticroutes.Addressingisanimportantaspectofthedata-forwardingprocess.Foranydirectedcommunication,thereisasourceandadestination.Addressingallowsthetargetdestinationtobespecifiedbythesourceandallowsthedestinationnodetoalsoidentifythesource.Addressingisevenmoreimportantinthedatagramdeliverymodeofoperationbecause,asinIPforwarding,thedatapathforanytransmissionisnotnailedthroughtheintermediatenodesbetweenthesourceanddestination.Asmentionedpreviously,withintheIPdatagramservicesinfrastructure,informationthatistobetransmittedfromonedevicetoanotherfirstisbrokendownintopackets.EachpackethasanIPheader,atransportlayer(TCPorUDP)header,andapayload,whichisapieceoftheoriginalinformation.EachIPpacketisself-containedandindependentlyisforwardedtothedestinationthroughthechainofintermediatedevicesthatmightbealongthepathoftransmission.Theroutersinthenetworkdependonaroutingprotocolorstaticconfigurationtoforwardthedatagramsinastreamtotheirintendeddestination.Foranydestinationaddress,eachnodeinthedatapathworriesaboutonlytheoutgoinginterfaceorlinkalongalocallydeterminedoptimalpathtothedestination(orasspecifiedbyaspecialforwardingpolicy).TheIPforwardingprocessfrequentlyisdescribedasahop-by-hopdestination-basedforwardingmechanism.Thismeansthatroutersateachhopalongthedatapathnormallyforwardpacketsbasedonthedestinationaddress.However,modernroutersalsocanusepolicy-basedcriteria,suchasthesourceaddressinapackettodirecttheforwarding.Atthedestination,packetsbelongingtothesamestreamarereassembledintotheoriginalinformation.IPaddressingisdiscussedinthenextsection,“IPAddressingConcepts.”ThisprocessofforwardingapacketfromonenodetotheotherinaconnectionlessnetworkbasedontheLayer3address(IPaddress,inthiscase)alsoisreferredtoasrouting.Routersarespecializednetworkdeviceswithacquiredroutingintelligence.Sohowdoroutersreallydecidewhereandhowtoforwardpacketstraversingtheinternetwork?Well,thisisdoneinacoupleofways.Asalludedtopreviously,routerscanbemanuallypreprogrammedwithpredeterminedpathinformationknownasstaticroutes,ortheycanrunapplicationsthatfacilitatethelearningandsharingofroutinginformationautomatically.Obtainingandpropagatingroutinginformationbythelattermethodisreferredtoasdynamicrouting.

IPAddressingConceptsIPaddressingiscentraltotheoperationoftheIPprotocol.TheTCP/IPstackshowninFigure1-1featuresanetworkinterfacetotheunderlyingphysicalanddata-linklayers,whichallowtheIPprotocoltobemediaindependent.MediaindependenceisprobablyoneofthecriticaladvantagesoftheIPprotocolthathaspromoteditswideacceptanceandubiquity.IPusesanativeaddressingscheme,inlinewithitsmedia-independentarchitecture,thathasnobearingontheunderlyinglocal-areanetwork(LAN)orwide-areanetwork(WAN)mediainterconnectIPdevices.Therefore,IPsuccessfullyoperatesoverheterogeneousnetworkinfrastructuresconsistingofseveralkindsofdifferentmediatechnology.Thisflexibility,togetherwithasimpleprotocolstack,isthemostcriticalinstigatorofitspopularity.IPaddressingassignsaddressestoindividualnetworkinterfacesofadevice(link-basedapproach)insteadofusingasingleaddressforthewholedevice(host-basedapproach).Thevariousinterfacesofadeviceareconnectedtonetworklinksthataredesignatedassubnetworks(orsubnets)andareassignedsubnetaddresses.Aninterface’sIPaddressisassignedfromthesubnetaddressspaceoftheconnectinglink.Theadvantageofthislink-basedaddressingapproachisthatitallowsrouterstosummarizeroutinginformationbykeepingtrackofonlyIPsubnetsintheroutingtablesinsteadofeveryhostonthenetwork.

ThisisadvantageousespeciallyforbroadcastlinkssuchasEthernetthatmighthavemanydevicesconnectedatthesametime.TheAddressResolutionProtocol(ARP)isusedinIPnetworkingforresolvingtheIPaddressesofdirectlyconnectedhoststothecorrespondingdata-linkaddresses.Currently,twotypesofIPaddressesexist:IPVersion4addresses(IPv4)andIPVersion6addresses(IPv6).IPv4addressing,whichwasinplacebeforeIPv6wasadopted,uses32bitstorepresenteachIPaddress.This32-bitaddressingschemeprovidesupto232(4,294,967,295)uniquehostaddresses,mathematicallyspeaking.WiththeeverincreasingsizeoftheglobalInternet,the32-bitIPv4addressingschemehasturnedouttobeinsufficientfortheforeseeablefuture,promptingtheintroductionofthe128-bitIPv6addressingscheme.ThisbookcoverspracticaltroubleshootingofIProutingprotocolsdeployedinIPv4environments.Therefore,theensuingtextdiscussesonlytheIPv4addressingstructureandrelatedconcepts,mostofwhichareapplicabletoIPv6.ThefollowingIPv4addressingtopicsarecoveredinthesubsequentsections:•IPv4addressclasses•PrivateIPv4addressspace•IPv4subnettingandvariable-lengthsubnetmasking•Classlessinterdomainrouting

IPv4AddressClassesAsexplainedintheprevioussection,the32-bitIPv4addressingschemeallowsalargenumberofhostaddressestobedefined.However,thelink-basedaddressingschemeadoptedbyIPrequiresnetworklinkstobeassociatedwithgroupsofaddressesfromwhichtheconnectedhostsareassignedspecificaddresses.Theseaddressgroups,describedalsoasaddressprefixes,arereferredtoinclassicalIPterminologyasIPnetworknumbers.Originally,IPnetworknumbersweredefinedwithrigidboundariesandgroupedintoaddressclasses.TheideabehindIPaddressclasseswastoenableefficientassignmentoftheIPaddressspacebycreatingaddressgroupsthatwouldsupportavaryingnumberofhosts.Networklinkswithfewerhoststhenwouldbeassignedanaddressfromaclassthatsupportsanappropriatenumberofattachedhosts.Anotherbenefitofaddressclasseswasthattheyhelpedstreamlinetheaddress-allocationprocess,makingitmoremanageable.Fiveaddressclasses—A,B,C,D,andE—weredefinedanddistinguishedbythesettingofthemostsignificantbitsofthemostsignificantbyteintheIPaddress.EachaddressclassembracedasetofIPv4addresssubnets,eachofwhichsupportedacertainnumberofhosts.Table1-1showsthefiveIPv4classes.

Table1-1IPAddressClassesandRepresentation

AsTable1-1shows,aspecificbitpatterninthefirstbyteofanIPaddresscorrespondstoarangeofaddressesandmapstoaspecificaddressclass.

Ofthefiveaddressclasses,three—ClassA,B,andC—weredesignatedforunicastsinglesource–to–singledestinationcommunication.AddressesinClassDwerereservedforIPMulticastapplications,whichallowsone-to-manycommunication.ClassEaddresseswerereservedforexperimentalpurposes.Tomaketheaddressesineachoftheunicastaddressclasses(A,B,andC)supportaspecificmaximumnumberofhosts,the32-bitaddressfieldwasdelineatedintonetworkidentifier(networkID)bitsandhostidentifierbits(hostID)asfollows:•ClassA—8-bitnetworkID,24-bithostID•ClassB—16-bitnetworkID,16-bithostID•ClassC—24-bitnetworkID,8-bithostID

Figure1-2showstheassignmentofthe32bitsinaClassAaddress.Thehighest-orderbithasafixedvalueof0,andthewholeofthefirstbyteisthenetworkID.Thelast3bytesaredesignatedashostbits.

Figure1-2AssignmentofClassAAddressBits

ThisnotionofcategorizingIPaddressesintoclasseswithrigidboundariesisalsoknownasclassfuladdressing.IPaddressesusemaskstodelineatehostbitsfromthenetworknumberbits.IPaddressstructuringhasevolvedthroughvariousinnovations,allgearedtowardmakingaddressallocationandactualassignmentinrealnetworksmoreefficient.Youfindoutmoreaboutthisinthesection“SubnettingandVariable-LengthSubnetMasks.”TomakeiteasierforhumanstoworkwithIPaddresses,theseaddressesarerepresentedinaformatknownasdotted-decimalnotation.Inthedotted-decimalrepresentation,thebitsaregroupedintooctetsandareseparatedbydots.Eachoctetofbinarybitsthenisconvertedintothedecimalequivalent.ThelastcolumnofTable1-1showsthedotted-decimalnotationsfortherangeofaddressesineachoftheaddressclasses.EventhoughclassfuladdressingwasintroducedtofacilitateefficientuseoftheIPv4addressspace,therigidclassfulboundariesleftalotmoretobedesired.Becauseofitsrigidityandinefficiency,classfuladdressinghasbeenabandonedforthemoreefficientandflexiblenotionofclasslessaddressing.Inclasslessaddressing,anyIPnetworknumberisinterpretedasaprefixofacertainlength.ThisinterpretationprovidesmoreflexibilityandresultsinamoreefficientuseoftheIPv4addressspace.AlargeclassfulblockofaddressessuchasaClassAaddresscanbesplitintomultiplesmallerblocksforallocationtomultipleorganizationsinsteadofbeingallocatedtoasingleorganizationundertheclassfulnotions.Conversely,classlessaddressingallowsmultipleClassCaddressestobeaggregatedandadvertisedasasinglelargerblockinsteadofbeingtreatedasseparateaddresses.AggregatingaddressesinthismannerforthepurposesofconservingresourceinroutersconnectedtotheInternetisreferredtoasclasslessinterdomainrouting(CIDR),whichisfurtherdiscussedinalatersection,“ClasslessInterdomainRouting(CIDR).”

IPv4PrivateAddressSpaceSomeaddressblocksintheunicastspaceweresetasideanddesignatedasprivateaddresses.TheprivateaddressspacewasintendedfornetworksthatarenotconnectedtothepublicInternet.ThefollowingaddressesarespecificinRFC1918aspartoftheIPv4privateaddressspace:

•10.0.0.0to10.255.255.255•172.16.0.0to172.31.255.255•192.168.0.0to192.168.255.255

RFC1700providesgeneralinformationonreservedorallocatedparameters,includingreservedaddresses.PrivateinternetsthathavedeployedaddressesfromtheprivateIPv4spacestillcanconnecttothepublicInternetbyusingaddressNetworkAddressTranslation(NAT).

SubnettingandVariable-LengthSubnetMasksBeforeCIDR,eachclassfulnetworknumbercouldbeallocatedforuseinonlyasingleorganization.However,withinanorganization,itwaspossibletousesubnettingtobreakupaclassfuladdressintomultiplesmalleraddressgroupsthatcouldbeappliedtodifferentsegmentsofthesamenetworkdomain.IPsubnettingintroducesanotherlevelofhierarchyintothestructureofIPaddressclassesbymovingsomeofthehostbitsinaclassfulnetworknumberintothenetworkIDfield.TheextendednetworkIDisreferredtoasasubnetworknumberorsimplyasanIPsubnet.Forexample,oneoctetofthe2octethostbitsofaClassBaddresscanbeusedtocreate255subnets,eachwithonlyanoctetofhostbits.ThisisillustratedinFigure1-3.

Figure1-3ClassBSubnetExample

WhenanIPaddressissubnetted,theaddressmaskisadjustedtoreflectthenewdemarcationbetweenthenetworkandhostbits.Figure1-4showsthenewmaskandthecorrespondingsubnetsthatarecreatedfromaClassBaddress.Astringofonesinthemaskrepresentthenetworkbits,andthezerosrepresentthehostbits.AcommonwayofrepresentinganIPaddressistoindicateitsprefixlength,whichisthenumberof1bitsinthemask.Thisalsorepresentsthenumberofnetworkbitsintheaddress.Forexample,172.16.1.0255.255.255.0canberepresentedas172.16.1.0/24.

Figure1-4SubnetMaskExample

Eventhoughclassfuladdressingallowssubnettingformoreefficientassignmentofaddressesfromablock,inaclassfulnetworkenvironmentonlyaconsistentmaskisallowed.VLSMextendsthenotionofsubnettingtoallowdifferentmaskstobeappliedtoonenetworknumber,providingmoreflexibilityincarvingupanaddressintodifferentblocksizesforapplicationtodifferentsegmentsinanetworkdomain.Thisallowsmoreefficientuseofanallocatedaddressblock.Forexample,byusingVLSM,theClassBaddress,172.16.0.0/16,canbecarvedintosmallersubnetswith24-bitsubnetmasksbyusing8hostbitsassubnetbits.Youthencanfurthersubnetoneofthefirstgenerationsubnets—forexample,172.16.1.0/24—byusinganother4oftheremaininghostbits.Thiswillresultinmuchsmallerblockssuchas172.16.1.0/28,172.16.1.16/28,172.16.1.32/28,andsoon.VLSMcanbeusedonlyinclasslessnetworkenvironmentsinwhichtheroutingprotocolsandrelatedroutingsoftwaresupportclasslessaddressing.Figure1-5illustratessubnettingwithVLSMs.

Figure1-5VLSMExample

ClasslessInterdomainRoutingVLSMhelpsimprovetheefficiencyofIPaddressusageforanassignedaddressblock;however,itdoesnotsolvechallengeswithinefficientallocationofaddressestoorganizations.TheimminentdepletionofIPaddressesastheresultofinefficientuseofclassfulblocksandthegrowingnumberofclassfuladdressesintheglobalInternetroutingtablesasorganizationswereallocatedmultiplesofaClassCaddressinsteadofasingleClassBaddressledtotheintroductionofclasslessinterdomainrouting(CIDR).CIDRallowsanIPnetworknumbertobeanylength,abandoningcompletelythefixedboundariesassociatedwithclassfulconcepts.ThetwobenefitsofCIDRareillustratedintheexamplesprovidedinFigure1-6.Byeliminatingthenotionsofaddressclasses,ablockofaddressessuchas192.168.0.0to192.168.255.0consistingofanindividualClassCaddresscanbeconsideredauniformblockthatcanbeconvenientlyrepresentedas192.168.0.0/16.Thisessentiallyimpliesaggregationof256“oldnotion”ClassCaddressesintoasingleaddressblock,referredtoasaCIDRblockorasupernet.

Figure1-6ExamplesofCIDRAggregationandSubnetting

CIDRalsoallowsnetworknumberstobeflexiblysubnettedandallocatedtodifferentorganizationsforinterdomainroutingexchange.Forexample,131.108.0.0/16canbedividedintofoursubblocks(131.108.0.0/18,131.108.64.0/18,131.108.128.0/18,and131.108.192.0/18)andallocatedtofourdifferentorganizationsinsteadofone.

StaticandDynamicRoutesStaticpathinformationcanbemanuallyprogrammedintotherouterandsimplyforcetheroutertoutilizea

particularinterfaceornext-hopIPaddressforforwardingpacketswithmatchingdestinationaddresses.Staticroutespotentiallycouldmatchabroadrangeofnetworkaddresses.Yetanotherwaytoobtainroutinginformationistousedistributedapplicationsenabledonroutersthatallowautomaticcollectionandsharingofroutinginformation.Theseroutingapplicationsfrequentlyarereferredtoasdynamicroutingprotocolsbecausetheyarenotonlyautomatedroute-gatheringtools;theyalsoworkinalmostrealtime,trackingthestateofconnectivityinthenetworktoprovideroutinginformationthatisascurrentandasvalidaspossible.Contrastthisbehaviorwithstaticroutes,whicharemanualrouteentriesandrequiremanualinterventiontoreprogramthenetworkroutersincaseofanypathchanges.Obviously,dynamicroutingprotocolsprovidemoreconveniencetothenetworkoperatorthanstaticroutesinmanagingroutinginformation.Thepriceforthisconvenience,however,isconfigurationandtroubleshootingcomplexity.Operationofdynamicroutingprotocolsalsocanberesource-intensive,requiringlargeamountsofmemoryandprocessingresources.Hence,workingwithdynamicroutingprotocolsfrequentlyrequiresadvancedknowledgeandsophisticatedexpertiseforhandlingrelatednetworkdesign,routerconfiguration,tuning,andtroubleshootingchores.Eventhoughstaticroutingislessdemandingonsystemresourcesandrequiresalowerleveloftechnicalskilltoconfigureandtroubleshoot,thesheereffortofmanuallyenteringroutesforasizeablenetworkmakesitalessattractiveoption.Obviously,staticroutingisnotagoodcandidatefortoday’slargeenterpriseandInternetserviceprovider(ISP)IP-basednetworks.Anotherdrawbacktostaticroutingisthatitislessflexibleforimplementationofcomplicatedroutingpolicies.Whenitcomestoroutingpolicyimplementation,thereisnobettersubstitutefortheintelligenceandflexibilityprovidedbydynamicroutingprotocols,suchasBGP,OSPF,andIS-IS.Thenextsectionfurtherdiscussesdynamicroutingprotocols.

DynamicRoutingThelastsectiondiscussestheessenceofIProutingandindicatesthatdynamicautomaticroutingisverynecessaryforlargenetworkdeployments.ThissectiondiscussesthecharacteristicsandclassificationofvariousIProutingprotocols.Althoughallroutingprotocolshaveacommongoalofgatheringroutinginformationtosupportpacket-forwardingdecisions,theycanbeclassifiedintotwobroadcategories,unicastandmulticast,basedonthetypeofdatatraffictheyaredesignedtoprovideforwardinginformationfor.TheprevioussectionindicatesthatIPprovidesanaddressingschemeforidentifyingvariouslocationsorsubnetsinthenetwork.ThedestinationIPaddressinanIPpacketindicatesthetargetaddressofthepacket.Thesender’saddressisstoredinthesourceaddressfield.AnimportantconcepttounderstandaboutIPaddressingisIPsubnetworks.IPsubnetworks—orsubnets,forshort—arementionedearlierinthesectiononIPaddressingconcepts.Physically,anIPsubnetisacollectionofinterconnectednetworkdeviceswhoseIPinterfaceaddressessharethesamenetworkIDandhaveacommonmask.Theearliersection“IPv4AddressClasses”discussesunicastandmulticastaddresses.Theunicastaddressspaceisusedforaddressingnetworkdevices,whereasaddressesfromthemulticastspaceareusedforspecifyinggroupsoruserstunedintoreceiveinformationfromthesamemulticastapplication.ForanyIPunicastsubnet,thelastaddress,suchasin192.168.1.255/24,isknownasthebroadcastaddress.Thisaddresscanbeusedtotargetallnodesonthesubnetatthesametimeinwhatisreferredtoasadirectedbroadcast.AunicastroutingprotocolisoptimizedforprocessingunicastnetworkinformationandprovidesroutingintelligenceforforwardingIPpacketstounicastdestinationaddresses.Multicastforwardingis

conceptuallydifferentandrequiresspecialroutingapplicationstosupportforwardingofmulticastpackets.

UnicastVersusMulticastIPRoutingTwodevicesinanIPnetworknormallycommunicatebysendingunicasttraffictoeachother’sIPaddress.AnIPnodemighthavemanyactiveinterfaces,eachofwhichneedstobeconfiguredwithanIPaddressfromtheunicastspace.Theaddressonaninterfaceuniquelydefinesthedeviceonthesubnetdirectlyconnectedtothatinterface.Ciscoroutersalsosupporttheconceptofsecondarylogicalsubnets,manyofwhichcanbeconfiguredonarouter’sinterfaceinadditiontotheprimaryaddressonthatinterface.Additionally,youcanenabletunnelandloopbackinterfacesonaCiscorouter,bothofwhichprovideitwithunicastIPreachability.PacketswithunicastaddressesintheirdestinationfieldareforwardedbasedoninformationintheIProutingtable.TheIProutingtableonaCiscorouterisdisplayedwiththeshowiproutecommand.Iftheaddressinthedestinationfieldofapacketisfromthemulticastaddressspace(ClassD),thepacketisdirectedtoamulticastgroupwithpotentiallymanyreceivers.Multicastforwardingusesspecialmechanismsthatenableefficientutilizationofnetworkresources.Ifanapplicationisdesignedformultidestinationdelivery,usingunicastroutingtoforwardpacketsoftheapplication’sdatastreamwouldrequireunnecessaryreplicationatthesource,resultinginawasteofnetworkresources.Thiscanbeavoidedbyusingmulticastpropagation,whichreplicatesmulticastpacketsonlywhennecessaryatbranchesinthenetworktowardthelocationofreceivers.Figure1-7illustratesasituationinwhichapacketisforwardedfromSRC1totwoseparatedestinations,RCV1andRCV2,byunicastforwarding.

Figure1-7MultidestinationUnicastForwarding

Inthiscase,SRC1generatestwoidenticalstreamsofpacketswithdestinationaddresses10.1.1.1and10.1.1.2,respectively.PacketsbelongingtoeachstreamarehandledindependentlyandaredeliveredthroughRT1andRT2totheirrespectivedestinations,consumingnetworkresources(bandwidthandprocessingtime)alongthepathsthattheytraverse.ContrastthisscenariowiththatshowninFigure1-8,

whereIPMulticastforwardingmechanismsareemployed.

Figure1-8MulticastForwarding

Multicastforwardingprovidesamoreefficientwaytodeliverinformationbyreplicatingpacketsonlyatforkpointsofthenetworkwherepathstoreceiversfollowdivergentdirections.Therefore,asshownintheFigure1-8,SRC1originatesonlyasinglestream,andpacketsinthisstreamareforwardedthroughRT1toRT2.TheyarethenreplicatedatRT2andfannedouttoRCV1andRCV2.Multicastroutingprotocolsarefunctionallydifferentfromunicastroutingprotocols,inthattheybuildmulticastforwardingstateinthemulticast-enabledroutersbyusingaconceptknownasreversepathforwarding(RPF).RPFisusedtoensurethatamulticastpacketisreceivedfromtheinterfaceleadingtotheexpectedlocationofthemulticastsource,asdictatedbytheroutingtableinplace.RPFisdiscussedfurtherinChapter12,“UnderstandingProtocolIndependentMulticast(PIM),”whichcoversIPMulticastrouting.Table1-2showsatableofpopularmulticastandunicastroutingprotocols.

Table1-2UnicastandMulticastRoutingProtocols

AllthelistedunicastroutingprotocolsaresupportedinCiscoIOSSoftware;however,fromthelistedmulticastroutingprotocols,onlyProtocolIndependentMulticast(PIM)sparsemode/densemode(SM/DM),MulticastSourceDiscoveryProtocol(MSDP),andMultiprotocolBGParesupported.

MulticastroutingenvironmentsalsoneedanadditionalprotocolcalledtheInternetGatewayMulticastProtocol(IGMP).MulticastOSPR(MOSPF)isnotsupportedatall,butIOSprovidesspecialcapabilitiesforinteroperabilitywiththeDistanceVectorMulticastRoutingProtocol(DVMRP).Asofthiswriting,multicastroutingprotocolsarenotwidelydeployedontheInternet.However,thissituationobviouslywillchangeinthenearfutureasmoremulticast-orientedapplications,suchasradiobroadcasting,videostreaming,remotetraining,videoconferencing,andgaming,becomemorepopularontheInternet.

ClasslessVersusClassfulIPRoutingProtocolsTheconceptsofclasslessandclassfulIProutingprotocolshaverootsinthemannerinwhichIPaddressesoriginallyweredefined.Underclassfuladdressingrules,anetworknumberwasassumedtoretainitsnaturalmaskunlessexplicitlyspecifiedwhensubnettedintosmallerblocks.However,earlier-generationroutingprotocols,suchastheRoutingInformationProtocol(RIP),couldhandleonlyasinglemaskforanyaddressthroughoutanetworkdomain—thenaturalmaskorasingleconsistentsubnetmask.RoutingprotocolssuchasRIPthatcannothandlemorethanonetypeofmask,asinthecaseofVLSMs,arereferredtoasclassfulprotocols(seeTable1-3).ThereasonthatclassfulprotocolsdonotsupportVLSMsisthat,bydesign,theydonotadvertiseorcarrytheassociatedsubnetmaskwithroutesand,therefore,usesimpleintuitivemechanismstodeterminethemaskassociatedwithalearnedroute.

Table1-3ClassfulandClasslessIPRoutingProtocols

ThesignificantgrowthoftheInternettoglobaldimensionscalledformoreefficientuseofthelimitedIPv4addressspace.AvailableaddressesintheIPaddressspacethereforeattainedthestatusofascarcecommodity.TheclasslessnotionsofVLSMandCIDR,discussedearlier,wereinventedtomakeaddressallocationandusemoreefficient.Routingprotocolsalsowereenhancedtosupportclasslessaddressingenvironments.RoutingprotocolsthataredesignedforoperationinclasslessenvironmentsandthatcanhandleVLSMaddressandCIDRarereferredtoasclasslessroutingprotocols.Table1-3featuresalistofroutingprotocolscategorizedasclassfulandclassless.RIP-1andIGRParegroupedunderclassfulprotocols,whereasthemorerecentlydevelopedRIP-2,EIGRP,OSPF,IS-IS,andBGPfallintheclasslesscategory.TheExteriorGatewayProtocol(EGP),thepredecessoroftheBorderGatewayProtocol(BGP),whichcurrentlyisconsideredobsolete,isalsoaclassfulprotocol.

InteriorGatewayProtocolsVersusExteriorGatewayProtocolsEventhoughmanyunicastroutingprotocolsweredevelopedintheearlydaysoftheARPANET(thepredecessortotheInternet),RoutingInformationProtocol(RIP)emergedasthemostpopular.ManyindependentnetworksthatwerecreatedatgovernmentresearchinstitutionsanduniversitiesasaresultoftheremarkablesuccessoftheARPANETalsoadoptedRIPfordynamicroutingoperations.TheevolutionoftheARPANETintotheInternetrequiredthenumerousislandnetworkstobeinterconnectedusingamorerobustroutingprotocol.TheExteriorGatewayProtocol(EGP)wasselectedforthispurpose.EGP

providedanefficientmechanismforroutingamongthevariousRIPdomains.Therefore,RIPandEGPwereoptimizedfordistinctfunctionsinthenetworkbasedontheircapabilities.RIPwasusedforintradomainrouting,andEGPwasusedforinterdomainrouting.EGPlatermorphedintotheBorderGatewayProtocol(BGP),andothermorerobustprotocolsoptimizedforintradomainroutingemergedinplaceofRIP.Inparticular,theOpenShortestPathFirst(OSPF)ProtocolwasdevelopedintheInternetEngineeringTaskForcetoprovidecapabilitiesthatRIPlacked,suchasmoreintelligentroutingmetrics,fasterconvergence,andoperationinclasslessenvironments.So,hereweareagainwithyetanotherclassificationofroutingprotocols:interiorgatewayroutingprotocols(forintradomainrouting)andexteriorgatewayprotocols(forinterdomainrouting).Figure1-9showstworoutingdomains,AS65001andAS65002,andanoverlapping(shaded)regiondepictingtheinterconnectionbetweenborderroutersfromeachdomain.Inmorecurrentroutingterminology,aroutingdomainalsoisreferredtoasanautonomoussystem.Anautonomoussystemisanindependentroutingdomainunderthecontrolofasingleadministrativeauthority.

Figure1-9IntradomainandInterdomainRouting

Asnotedbefore,anexteriorgatewayprotocolprovidesthecapabilityforsharingroutinginformationbetweenthetwodomains.Currentlyatversion4,BGPistheonlyIPinterdomainprotocolthatisusedforinterconnectingthenumerousautonomoussystemsintheglobalInternet.Aninteriorgatewayprotocolprovidesroutingintelligencewithinanautonomoussystem.EachoftheautonomoussystemsintheInternetcanrunanysuitableIGP.WiththeexceptionofEGP(theobsoleteroutingprotocol)andBGP,alltheotherunicastprotocolsmentionedsofar—IGRP,EIGRP,RIP,OSPF,andIS-IS—areIGPs(seeTable1-4).

Table1-4IGPandEGPClassification

TheInteriorGatewayRoutingProtocol(IGRP)wasinventedbyCiscoSystemstoofferbettermetricsthanthesimplehopcountsupportedbyRIP.IGRPintroducedacompositemetricthatconsistsofseveralparameters:•Bandwidth•Delay•Reliability•Load•Maximumtransmissionunit(MTU)

CiscoevolvedIGRPintotheEnhancedInteriorGatewayRoutingProtocol(EIGRP).EIGRPprovidesfasterconvergencerelativetoIGRPbyusingbackuproutes,referredtoasfeasiblesuccessorroutes,thatarereadilyinstalledintheroutingtablewhenapreferredrouteislost.UnlikeIGRP,EIGRPsupportsVLSM.OSPFandIS-ISarebothpopularIGPsusedinverylargeIPnetworks.IS-ISoriginallywasdesignedasaroutingprotocolfortheConnectionlessNetworkProtocol(CLNP)butlaterwasadaptedtorouteIPaboutthesametimethattheOpenShortestPathFirst(OSPF)protocolwasbeingstandardizedintheInternetEngineeringTaskForce(IETF).OSPFandIS-ISarebothlink-stateprotocols,whereasRIP,IGRP,andEIGRParedistancevectorprotocols.Also,OSPFandIS-ISarelink-stateprotocolsthatusetheshortestpathfirst(SPF)algorithm(namedafterDijkstra)forroutecomputation,makingthemconvergerelativelyfastinresponsetonetworkchanges.Bothprotocolsalsosupportatwo-levelhierarchicalroutingarchitecture.OSPFandIS-ISareverysimilarprotocolswithalmostidenticalcapabilities.However,theyhavesomearchitecturaldifferencesthatarebeyondthescopeofthisbook.Aninterestingpointtonote,however,isthatOSPFwasdesignedentirelyforIPonly,andOSPFpacketsareencapsulatedinIPpackets.Incontrast,IS-ISwasdesignedforCLNPandwasadaptedtosupportIPadditionally.IS-ISpacketsarenotencapsulatedinIPpacketsbutratherdirectlybythedatalinkprotocol.Thenextsectionofthischapterlooksatyetanotherroutingprotocolclassification:distancevectorandlink-stateprotocols.

DistanceVectorVersusLink-StateProtocolsThissectiontakesalookatroutingprotocolfromadifferentperspective.Intheprevioussections,weconsideredgeneralclassificationsuchasclassfulversusclasslessandalsoIGPversusEGP.Thissectiondiscussesclassificationbasedondesignandoperation.ThesecondrowinTable1-4placestheprotocolsdiscussedsofarintofourdifferentcategories,twoofwhichstandout—distancevectorandlink-state.ThesetwobroadcategoriesactuallyapplytoIGPasshowninthetable.EIGRPisessentiallyadistancevectorprotocoljustlikeIGRP,exceptthatitisrightfullyconsideredinitsownclassasanadvanceddistancevectorprotocolbecauseithasmoremoderncharacteristics,suchassupportofclasslessroutingandfastconvergence.BGPisalsoinitsowncategory,pathvectorprotocolbecause,asaninterdomainroutingprotocol,itusestheASpathattribute,whichismadeupofthelistofautonomoussystemsthataroutehastraversedasakeymeasureforroutecomparisonandselection.Versions1and2ofRIP(RIP-1andRIP-2)andIGRPareclassifiedasdistancevectorprotocolsbecausetheyuseroute-computationalgorithmsbasedontheBellman-Fordalgorithm.TheBellman-Fordalgorithmisusedingraphtheoryforcalculatingtheshortestdistancebetweentwoverticesinadirectedgraph.Adirectedgraphisacollectionofpoints,interconnectedwithdirectionallinks,suchasthenodesandlinks

inaninternetwork.RoutersrunningdistancevectorroutingprotocolsusetheBellman-Fordalgorithmfordeterminingtheshortestpathstoallknownlocationsinthenetwork.OSPFandIntegratedIS-ISarebothlink-stateprotocolsandusetheshortestpathfirstalgorithm(Dijkstra)forroutecomputation.JustliketheBellman-Fordalgorithm,theDijkstraalgorithmprovidesanalternatemethodforcomputingtheshortestdistancebetweentwopointsinadirectedgraph.EIGRPusesaCiscoSystems–patentedalgorithmknownastheDiffusingUpdateAlgorithm(DUAL)tooptimizeroutecalculation,breakingawayfromitspredecessor,IGRP,whichisbasedontheBellman-Fordalgorithm.Thetypeofalgorithmusedbyaprotocolforroutecomputationgoesalongwaytowardaffectingtheefficiencyoftheprotocolandhowfastitconverges.Thefollowingsectionsexaminetheconceptsandoperationalprinciplesbehinddistancevectorprotocolsandlink-stateprotocols.DistanceVectorRoutingConcepts

Thissectionreviewskeyconceptsthatunderlietheoperationofdistancevectorroutingprotocols,suchasmetrics,counttoinfinity,splithorizon,holddowns,andtriggeredupdates.Theseconceptsareevaluatedintermsofgeneralroutingfunctionality,suchasstabilityandspeedofconvergenceandloopavoidance.DistanceVectorMetrics

IntheBellman-Fordalgorithm,eachrouteradvertisesthebestpathstoallknowndestinations,fromitsperspective,toallneighbors.Thelinksbetweenroutersareassignedameasureknownascostormetric.Themetriccanbedeterminedfromcharacteristicsofthelinks,suchashopcount,bandwidth,delay,reliability,monetaryvalue,andsoon.Thehopcountassociatedwithalinkbetweentwodirectlyconnectednodesisusually1,eventhougharbitraryvaluescanbeadministrativelyassigned.Themetricassociatedwithaspecificpathtoaknowndestinationfromanyrouteristhesumofallthemetricsoflinksalongthatpath.Usually,thepathwiththelowestmetricisthebest.Aroutermighthavemanyneighborsand,therefore,mightreceivemultiplepathsforthesamedestination.Itthencomputesthemetricassociatedwitheachofthesepathsandselectsthebestpathbyacriterionsuchasthelowestmetric.RIPuseshopcountformetric,withthemaximumpossiblenumberofhopstoanyreachabledestinationsbeing15.Ametricof16hopsormoreisconsideredtobeinfinity.Hence,ahopcountof15definesthemaximumwidthofreachabilityinaRIPnetwork.ThisimposesalimitonthesizeofRIP-basednetworks,whichalsoimpliesthatRIPissuitableforonlysmall,flatnetworks.Hopcountactuallypertainstothenodecountfromaspecificsourcetoadestinationandhasnoconsiderationforactualnetworkcharacteristics,suchasbandwidth,delay,ormonetarycosts.IGRP,whichisalsoadistancevectorprotocol,usesametricsystemthattakesintoconsiderationrelevantcharacteristicsofthenetwork,suchasbandwidth,associatedmaximumtransmissionunit,reliabilityoflinks,andalsopathdelay.Themetricassignedtoeachlinkintheoutgoingdirectioniscalculatedfromaformulathattakesintoconsiderationallthesecharacteristics.Thissortofmultifacetedmetriciscalledacompositemetric.TheBellman-Fordalgorithmusesavector(distancevector),consistingofcost(metric)andnext-hopinformationforeachknownroutetodeterminebestpathsinthenetworkfromanystandpoint.Aniterativeprocedurecalculatesthecostofallpathsforanyreceivedrouteandselectsthevectorwiththebestcostforeachroute.Hence,routingprotocolsthatarebasedontheBellman-Fordalgorithmcommonlyarereferredtoasdistancevectorprotocols(seeTable1-4).RoutingConvergence

Whenthereisatopologychange,aroutermightinvalidatesomeofthepreviouslyknownbestpaths.Therouterthenusesneworexistinginformationtodetermineanalternatebestpathforeachaffected

destination.Recalculatingroutestorediscoveralternateroutesasaresultofnetworktopologychangesisreferredtoasroutingconvergence.Routingconvergencemaybetriggeredbyeventssuchasrouterfailures,linkfailures,orevenadministrativemetricadjustments.DistancevectorprotocolssuchasRIPandIGRParerelativelysimplecomparedtotheirlink-statecounterparts.However,thissimplicitycomeswithaprice.Becauseeachrouterbasesitsbest-pathdeterminationonthebestpathsadvertisedbyneighbors,suchprotocolsareverypronetoroutingloops.Aroutingloopoccurswhentwonodespointtoeachotherasthenexthopalongthepathtothesamedestination.Themostobviouseffectofroutingloopsisthattheyprolongthetimeittakesforaroutertodeterminearouteisnolongeravailableortoselectanalternatepath.Routingloopsadverselyimpactconvergencetimes.Therefore,itisdesirablethatunusableroutesberemovedfromthenetworkassoonaspossible.Thefollowingsectionsdiscussvariousmethodsemployedbydistancevectorprotocolstopreventorlimittheeffectofroutingloopsandimproveconvergence.Thefollowingisdiscussed:•Countingtoinfinity•Usingholddown•Usingsplithorizonandpoisonreverse•Usingtriggeredupdates

LoopAvoidance

Routersrunningdistancevectorprotocolsdeterminebestpathsforroutesrelativetoneighborsthathaveadvertisedthoseroutestothem.Themechanicsofoperationofdistancevectorprotocols,specificallythewayroutesareadvertisedbydistancevectorprotocols,makessuchenvironmentsverysusceptibletoroutingloops—forexample,whenarouterrunningadistancevectorprotocolbroadcastsroutingupdatesoverallinterfacesactivatedfortheprotocol.Whenarouterbroadcastsallknownroutesinthismanner,itmayadvertisearoutebacktothesourceitwasheardfrom.Consequently,whenthereisafailure,itispossiblefortwoneighboringnodestothinkthattheotheristhenexthopalongthebestpathtoaspecificdestination.Thissituation,whichresultsinaroutingloop,iselaboratedinFigure1-10.

Figure1-10RoutingLoopsinDistanceVectorEnvironments

InFigure1-10,RT1,RT2,RT3areconnectedserially,andhopcountisusedasthemeasureformetric.Arouteassociatedwiththedestinationlink(Dest3)isadvertisedbyRT3toRT2,withahopcountof1.RT2assignsDest3ahopcountof2andthenadvertisesittoRT1.RT1storesDest3withahopcountof3andwithRT2asthenexthop.RT1thenmightadvertiseDest3backtoRT2.ThisrouteisnotusedbyRT2becauseithasaworsemetric(fourhops)thantheoriginalthatcamefromRT3(twohops).However,iftheconnectionbetweenRT2andRT3isbroken,RT2willremovetheoriginalrouteandinstallanalternateroutetoDest3withametricof4andRT1asthenexthop.Meanwhile,RT1hasthesameroutepointingbacktoRT2asthenexthop.Thus,aloopsituationiscreatedandanypacketsfromRT1orRT2toDest3willbecaughtupina“pingpong”betweenthetworoutersforsometimeuntiltheirTimeToLive(TTL)countersinthepacketsexpire.Routingloopsdisruptrouting,anditisdesirabletocurtail

themasquicklyastheyappear.Tolimittheeffectofroutingloops,distancevectorprotocolsuseamethodknownascountingtoinfinity.Thisprincipleiselaboratedinthenextsection.CountingtoInfinity

Topreventroutingloopsofindefiniteduration,distancevectorprotocolsenforcelimitsonroutemetricsthatallowsrouterstodeclareroutesasunreachableaftertheassociatedmetricsreachacertainvalue.IntheloopsituationdescribedinFigure1-10,RT1andRT4mightadvertiseDest3toeachother,eachtimeincreasingtheassociatedhopcountreceivedfromtheotherby1andbeforereadvertisingtheroute.Consequently,themetricassociatedwithDest3willcontinuetoincrease.Countingtoinfinityplacesanupperboundonthemetricbeyondwhichitisconsideredinfinityandtherouteisdeclaredunusable.ForRIP,thisupperboundis15.Holddown

Holddownisusedtodampenaroute’sresponseactiontofindinganalternateroutewhenaprimaryrouteisnolongerusable.Whenarouterdeterminesthatarouteisnolongeravailable,itplacestherouteinholddownstateforadurationcalledtheholddowntime,duringwhichitdoesn’tselectanalternateroute,evenifavailable.Therouteinholddownstateisadvertisedwithametricorvalueofinfinityinanattempttopurgeitfromthenetwork.Purgingunusablerouteshelpsreducetheincidenceofroutingloops.ToillustratethisusingFigure1-10,RT2placesDest3inholddownwhenitinvalidatesroutesheardfromRT3becauseofthefailureoftheconnectionbetweenthem.WithDest3inholddownstate,RT2doesnotusethealternateroutefromRT1;instead,itadvertisesDest3toRT1againwithametric.ThisallowsRT1towithdrawDest3fromitstables.Bytheexpirationoftheholddowntime,bothRT1andRT2areexpectedtohaveremovedDest3fromtheirroutingtables,thusavoidingapotentialroutingloop.Anotherbenefittousingholddownsisthatitpreventsunnecessaryreactionstoequipment-relatedglitchesthatcausethelinktoflap.Thedownsideisthatitcontributessignificantlytothehigherconvergencetimesassociatedwithdistancevectorroutingprotocols.SplitHorizonandPoisonReverse

Routingloopsareprimarilytheresultofroutesbeingleakedbacktotheirsources.Forexample,inFigure1-10,theloopbetweenRT1andRT2iscausedbyfeedbackofDest3backtoRT2byRT1,misleadingRT2tothinkthatRT1isthenexthoponanalternatepathtoDest3.Splithorizonpreventsarouterfromadvertisingaroutebackouttheinterfacethroughwhichitwasreceived.Withsplithorizonineffect,RT1cannotadvertiseDest3backtoRT3overthelinkbetweenthem(seeFigure1-10).Poisonreverseissimilarinprincipletosplithorizon,exceptthatitallowsroutestobeadvertisedbackouttheinterfacesonwhichtheywerereceivedasunreachable(metricofinfinityassigned).Thatis,routesare“poisoned”inthereversedirection.ReferringtoFigure1-10,withpoisonreverseenabled,RT1advertisesDest3backtoRT2,butwithametricvalueofinfinity(16hops,inthecaseofRIP).Theapproachadoptedbypoisonreversecanresultinunduewasteofbandwidthifmanypoisonedroutersmustbeadvertisedbackout.However,thisapproachspeedsuprouteconvergencebyeliminatingtheneedforholddowns.Inthiscase,thealternateroutewouldhaveanobviousinfinitemetricwhenfedbacktothesource,hencesimplifyingthesearchforanalternativepath,whentheprimaryrouteislost.PeriodicandTriggeredUpdates

Routersrunningdistancevectorroutingprotocols,suchasRIPandIGRP,advertiseallthecontentsoftheirroutingtablesatregularintervals.Periodicbroadcastsoflargeroutingtablesareamajorconcerninlargenetworks.Forexample,RIPbroadcastsallknownroutesoutofeveryactiveinterfaceevery30

seconds,bydefault,eveniftherearenochanges.IGRPusesadefaultupdateintervalof90seconds.Ifupdatesareadvertisedonlyperiodically,changesinthenetworkmightnotbecommunicatedfastenough,impactingconvergencetimes.Also,theholddowntimetypicallyistiedtotheupdateinterval.Soalargerintervalmightresultinlessbandwidthconsumptionbyroutingupdatesyetmightintroducehigherconvergencetimes.Triggered(orflash)updatesremovedelaysinconvergencecausedbyperiodicupdatesbysendingupdatesimmediatelyfollowinganetworkchangeinsteadofwaitingfortheperiodicupdatetimer.Flashupdatestricklethroughthenetworkfromonenodetotheother,resultinginanoveralltimegaininnetwork-wideconvergence,evenifnotverysignificant.Complicitybetweenperiodicallyscheduledupdatesandtriggeredchangescanresultinunpredictablebehavior.Link-StateProtocols

Link-stateprotocolsarerelativelymoremodernand,therefore,incorporatecapabilitiesintotheirdesigntoovercomesomeoftheshortcomingsofdistancevectorprotocolsdiscussedpreviously.Hence,theyaremoresophisticatedandrequiremorememoryandprocessingresourcestooperateeffectively.Byvirtueofcharacteristicssuchasfasterconvergence,incrementalupdates,andahierarchicalarchitecture,link-stateprotocolsaremoresuitablefordeploymentinlargeinternetworks.Twopopularlink-stateprotocolsusedinIPnetworksareOSPFandIS-IS.Unlikedistancevectorprotocols,whichsharebest-knownroutinginformation,link-stateprotocolsallowrouterstoexchangetopology(link-state)informationthatallowsthemtodrawoutthelayoutoftheinternetwork’stopology.Routersinalink-statenetworkconvergerelativelyfasterthantheirdistancevectorcounterpartsbyrespondingimmediatelytochangesinthetopology,withouttheneedforloopavoidingorlimitingholddownsandcountingtoinfinity.Forexample,RIPandIGRPtypicallyfeatureconvergencetimesinminutes,whereasOSPFandIS-ISconvergeintheorderofsecondsforcomparablenetworkchanges.Link-stateprotocolssupporthierarchyforscalingpurposesbycarvingoutanetworkintoareas(seeFigure1-11).Routingwithinareasfallinthefirstleveloftheroutinghierarchy.Theareasareinterconnectedoverabackbonearea,androutingwithinthebackboneconstitutesthesecondlevelofthehierarchy.

Figure1-11AreasandHierarchyinLink-StateProtocols

Routersinthesameareaorthebackbonesharelink-stateinformationthatisassembledintoalink-statedatabase.Thetopologyoftheareaorthebackboneisdiscernedbyrunningtheshortestpathfirstalgorithmovertherespectivedatabases.Thisprocedurealsogeneratesthebestroutesthatareusedinthe

IProutingandforwardingtables.Chapter8,“UnderstandingOpenShortestPathFirst(OSPF),”andChapter10,“UnderstandingIntermediateSystem-to-IntermediateSystem(IS-IS),”describetheoperationofthelink-stateroutingprotocolsandtheirrespectiveprotocolsinmoredetail.MetricsinLink-StateProtocols

BothOSPFandIS-ISusemetrics,whicharemeasuresoflinkbandwidth.OSPFgoesastepfurther,toprovideautoconversionofthebandwidthoninterfacetoalinkcost.IS-ISmetricsare10,bydefault,onallinterfaces.Inbothcases,themetricorcostassociatedwithalinkcanbemanuallyconfigured.Themetricassociatedwitharouteisthesumofallthemetricsontheoutgoinglinkstotheassociateddestination.Chapters8and10providemoreinformationonmetricsinOSPFandIS-IS,respectively.

RoutingProtocolAdministrativeDistanceTheprevioussectionsinthischapterprovideahigh-leveloverviewofIProutingprotocolsfromtheperspectivesofdesign,architecture,andoperation.Thesectiondiscussesbrieflygenericimplementation-relatedissuesthatimpactoperationoftheseprotocolsonCiscorouters.Detailsofoperationandconfigurationofeachprotocolarecoveredintheprotocol-specificchapters.CiscoIOSSoftwareprovidescommoncommandresourcesforconfiguringandenablingthecapabilitiesofIProutingprotocols.Commandssuchasdistance,distribute-list,redistribute,route-map,policy-map,access-list,prefix-list,offset-list,andsoforthfrequentlyarereferredtoasprotocol-independentcommandsbecausetheycanbeusedindiversewaystoenablemanyfeaturesinCiscoIOSSoftware,includingroutingprotocolcapabilities.Intheirapplicationtoroutingprotocols,protocol-independentcommandsareusedforfilteringroutes,enablingredistribution,configuringdefaultroutes,andimplementingvariousroutingpolicies.Youcanfindmoredetailonthesecommandsonlineatwww.cisco.com;however,thissectiondiscussesthedistancecommandandthefeaturethatitsupports—administrativedistance.AlltheIProutingprotocolsdiscussedsofarcanoperateconcurrentlyandyetindependentlyonCiscoroutersifenabledtogether.Usually,onlyoneIGP(OSPForIS-IS)isrequiredtorunalongsideBGPinanIPnetwork.However,dependingonthesituationandthehistoryofanetwork,morethanoneIGPmightbeoperationtosupportroutingrequirements.AdministrativedistanceisaCisco-specificmethodofdistinguishingbetweenroutesobtainedfromdifferentroutingsourcesinthesamenetwork.Itprovidesasimplemechanismtodifferentiatebelievabilityofroutinginformationsources.CiscoIOSSoftwareassignsnumericvaluestoroutingsourcesthatallowroutesfromoneroutingsourcetobepreferredoversimilarroutesfromanothersource.Sourceswithloweradministrativedistancevaluesarepreferred.Whenmultipleprotocolssupplythesameroute,onlytheroutefromthesourcewiththeloweradministrativedistancewillmakeitintotheroutingtable.Table1-5liststhedefaultadministrativedistancesofIProutingsources.Thedistancecommandcanbeusedtomodifyanyofthedefaults.

Table1-5AdministrativeDistancesofIPRoutingProtocols


FastForwardinginRoutersEventhoughthisbookisaboutroutingprotocolsandhowtotroubleshootrouting-relatedproblems,wewouldliketobrieflymentioninthisintroductorychapterthatthehigh-speedforwardingrequirementsintoday’snetworkshaveledtoingeniouswaysofpacketprocessingonroutersthatextendbeyondbasicdecision-makingbasedontheIProutingtable.Theroutingtableremainscriticalforroutingguidance,butinsteadofusingthecontentsoftheroutingtabledirectly,routerstransformtheroutinginformationintheroutingtableforstorageindatastructures,optimizedforhigh-speedpacketforwarding.Ciscoprovidesvarioushigh-speedforwardingmechanisms,suchasfastswitching,optimumswitching,andCiscoExpressForwarding(CEF).Frequently,troubleshootingroutingproblemsrequiresinvestigationintothefast-forwardingtables,suchastheCEFForwardingInformationBase(FIB)andtheAdjacencyDatabase.Detaileddiscussionsofthesefast-forwardingmechanismsareoutsidethescopeofthisbook.MoreinformationonthissubjectmatterisavailableattheCiscosite,www.cisco.com.

SummaryThisintroductorychapterreviewstheconceptsunderlyingIProutingandexplainswhyroutingisrelevantforinformationtransferinaconnectionlessnetworkingenvironment.YoulearnedthatprotocolssuchasIP,whichprovideconnectionlessdeliveryofinformation,allowdatatobetransmittedinchunksofinformation,knownasdatagrams.IPdatagramsalsoarereferredtoaspackets.Packetsconsistofapayloadandaheader.TheheadersinIPpacketscontaintargetaddressesthatallowthemtobeindependentlyroutedoveroptimalpathsinthenetworktowardtheirdestinations.IPisanetworklayerprotocol;routers,whichprocessandforwardpackets,runroutingprotocolsthatautomatethegatheringofroutinginformationininternetworks.ClassfulandclasslessnotionsofIPaddressingarecovered,leadingtoadiscussiononVLSMsandCIDR.TherelevanceofCIDRandVLSMsasvehiclesforefficientaddressallocationanduseiscoveredaswell.


Thesubsequenttextofthechapterdiscussesvariousclassificationsofdynamicroutingprotocols,categorizingthemintounicastversusmulticast,classlessversusclassful,IGPversusEGP,and,finally,distancevectorversuslink-state.Keycharacteristicsofdistancevectorandlink-stateprotocolsarediscussedandcompared.BriefcoverageofCiscoIOSSoftwareprotocol-independentcommandsledtothediscussionofadministrativedistancesassociatedwithroutingprotocols.AdministrativedistanceisdefinedasamechanismfordistinguishingbetweenroutingprotocolsourcesandassociatinganIOSdefaulttrustfactorwithvariousroutingprotocols.Thefinalsectionbrieflytouchesonhowtheroutinginformationgatheredbyroutingprotocolsactuallyisusedinforwarding.ItispointedoutthatCiscoroutersconverttheinformationinaroutingtableintooptimizeddatastructuresforhigh-speedpacketforwarding.

ReviewQuestions1Whatisconnectionlessdatanetworking?2Whyisroutingneededinaconnectionlessnetworkingenvironment?Listtwomeansbywhichroutersobtaininformationforroutingpacketstowardtheirdestinations.

3WhatisthedifferencebetweenfunctionalitiesofInteriorGatewayProtocols(IGPs)versusexteriorgatewayprotocols(EGPs)?

4ListthetwomaingroupsofIProutingprotocolsbasedonthemethodofoperationandroutingalgorithm.Also,listtwoexamplesofeachtype.

5Brieflydescribetheoperationoflink-stateroutingprotocols.6Whatisthekeydifferencebetweenclasslessandclassfulroutingprotocols?Giveanexampleofeach.7WhatistheuseofroutingprotocoladministrativedistancesonCiscorouters?8WhatarethevaluesofadministrativedistanceofIS-ISandOSPF,respectively?9IfarouterisrunningbothOSPFandIS-ISprotocolsandhasthesameroutefromeachofthem,whichprotocol’sinformationwillbeusedintheIProutingtable?

ReferencesBates,T.,R.Chandra,Y.Rekhter,andD.Katz.“Multi-ProtocolExtensionsforBGP4.”RFC2858,2000.Bennett,Geoff.DesigningTCP/IPInternetworks.NewYork,NY:JohnWiley&Sons;1997.Callon,R.“UseofOSIIS-ISforRoutinginTCP/IPandDualEnvironments.”RFC1195.IETF1990.Fuller,V.,T.Li,J.Yu,andK.Varadhan.“ClasslessInterdomainRouting(CIDR):AnAddressAssignmentandAggregationStrategy.”RFC1519.IETF1992.Hall,EricA.InternetCoreProtocols:TheDefinitiveGuide.Sebastopol,CA:O’ReillyandAssociates,2000.Hedrick,C.“RoutingInformationProtocol.”STD34,RFC1058,1988.http://www.6bone.net/http://www.cisco.com/warp/customer/701/3.html.“UnderstandingIPAddresses.”http://www.cisco.com/warp/public/103/index.shtmlHuitema,Christian.RoutingintheInternet,2ndEdition.UpperSaddleRiver,NJ:PrenticeHall,2000.

http://www.6bone.net/

http://www.cisco.com/warp/customer/701/3.html

http://www.cisco.com/warp/public/103/index.shtml

ISO10589.“IntermediateSystem-to-IntermediateSystemIntradomainRoutingInformationExchangeProtocolforUseinConjunctionwiththeProtocolforProvidingtheConnectionless-modeNetworkService.”(ISO8473.)Li,Rekhter.“BorderGatewayProtocolVersion4(BGP4).”RFC1771,1995.Maufer,Thomas.DeployingIPMulticastintheInternet.UpperSaddleRiver,NJ:PrenticeHall,1997.Miller,Philip.TCP/IPExplained.Woburn,MA:DigitalPress,1997.Naugle,Mathew.NetworkProtocolHandbook.NewYork,NY:McGrawHill,1994.Perlman,Radia.Interconnections2ndEdition.Reading,MA:AddisonWesley,1999.Reynolds,J.andPostel,J.“AssignedNumbers.”RFC1700.IETF1994.Rekhter,Y.,B.Moskowitz,D.Karrenberg,G.J.deGroot,andE.Lear.“AddressAllocationforPrivateInternets.”RFC1918.IETF1996.

Chapter2.UnderstandingRoutingInformationProtocol(RIP)

ThischaptercoversthefollowingkeytopicsaboutRoutingInformationProtocol(RIP):•Metric•Timers•Splithorizon•Splithorizonwithpoisonreverse•RIP-1packetformat•RIPbehavior•WhyRIPdoesn’tsupportdiscontiguousnetworks•WhyRIPdoesn’tsupportvariable-lengthsubnetmasking(VLSM)•DefaultroutesandRIP•ProtocolextensiontoRIP•Compatibilityissues

RIPisadistancevectorprotocolthatuseshopcountasitsmetric.Thisprotocolisverysimpleandwasintendedforsmallnetworks.RIPissimilartogated,whichwasdistributedbytheFreeBSDversionofUNIX.BeforetheRFCforRIPVersion1(RIP-1)waswritten,severalversionsofRIPwerefloatingaround.

NoteHopcountreferstothenumberofroutersbeingtraversed.Forexample,ahopcountof2meansthatthedestinationistworoutersaway.

RIPisaclassfulprotocol,whichmeansthatitdoesn’tcarrysubnetmaskinformationinitsroutingupdate.Becauseitdoesn’tcarryanysubnetmaskinformation,itisincapableofsupportingvariable-lengthsubnetmasking(VLSM)anddiscontiguousnetworks.RIPenablesdevicestoexchangeinformationaboutnetworksthattheyaredirectlyconnectedto,aswellasanyothernetworksthattheyhavelearnedfromotherRIPdevices.RIPsendsitsroutinginformationevery30seconds,whichisthedefaultupdatetimer.Thistimerisconfigurable.Theholddowntimerdetermineshowlongaroutershouldwaitbeforeflushingtheinformationfromtheroutingtable.RFC1058waswrittentoprovideastandardforRIP,whichusestheBellman-Fordalgorithmtocomputeitsmetric.

MetricTheRIPmetricisbasedonhopcountandcanbebetween1and15.Themetric16isusedforinfinity,whichmeansthatiftherouteisunreachable,ametricof16isdisplayed.Thequestionis,whywasthemetricchosenas16?Whynot17or18?ThemetricfiledinRIP-1packetformatclearlyshowsthatitis32bitslong.Thismeansthat,theoretically,RIPcansupport232hops.Althoughthisisalargenumber,themetricof15waschosentoavoidacounttoinfinityproblem.(Thisisalsoreferredtoasaroutingloop.)Inalargenetworkwithafewhundredrouters,aroutingloopresultsinalongtimeforconvergenceifthemetricforinfinityhasalargevalue.Thenumber16waschosentogetashorterconvergencetime.

The15-hoplimitwaschosenalsobecauseRIPwasintentionallydesignedforsmallnetworks.Itwasnotintendedforthelargenetworksthatpotentiallycanhavemorethan15hops.

TimersLikeanydistancevectorprotocol,RIPperiodicallysendsanupdateevery30seconds.Thisupdateconsistsofabroadcastoftheentireroutingtable.Theupdatetimercontrolsthis30-secondperiod.RIPusesthefollowingtimers:•Update—Thetimebetweeneachupdateinterval.Thisvalueissetto30seconds,bydefault,andisconfigurable.•Invalid—Thetimeafterwhichasuspectroutebecomesinvalid.Thisissetto180seconds,bydefault.•Holddown—Thetimeusedtosuppressthepossibilityofdefectiveroutesbeinginstalledintheroutingtable.Thedefaulttimeis180seconds.•Flush—Thetimeafterwhicharouteisremovedfromtheroutingtable.Thisissetto240seconds,bydefault.

SplitHorizonSplithorizonisatechniqueusedtoavoidroutingloops.Withsplithorizon,whenarouteislearnedonaninterface,thatrouteisnotadvertisedbackoutonthesameinterface.Forexample,inFigure2-1,Router1receivesanupdateaboutNetworkXwithametricof1fromtheneighboringRouter2.Router1willnotadvertiseNetworkXbacktoRouter2ifsplithorizonisenabled.Ifsplithorizonisdisabled,however,Router1willadvertiseNetworkXwithametricof2toRouter2.IfNetworkXfails,Router2willthinkthatRouter1hasabetterwaytogettoX,soitwillsendthepacketdestinedtoNetworkXtowardRouter1,creatingablackhole.

Figure2-1AnExampleofSplitHorizon

SplitHorizonwithPoisonReverseAnothertechniqueusedtoavoidroutingloopsissplithorizonwithpoisonreverse.Withthistechnique,routeslearnedonaninterfaceareadvertisedbackonthesameinterface,buttheyarepoisoned,whichmeansthattheyhaveametricof16(unreachable).InFigure2-1,Router1receivesanupdateaboutNetworkXwithametricof1fromneighboringRouter2.Inthecaseofsplithorizonwithpoisonreverse,Router1willadvertiseNetworkXbacktoRouter2,butwithametricof16,whichindicatesinfinity.Splithorizonwithpoisonreverseisusedonlywhenalinkfailureoccurs.Italsocanbeusedinanormalsituation,butitisdiscouragedbecauseitcanpotentiallyincreasethesizeoftheroutingtable.

RIP-1PacketFormatThemaximumdatagramsizeinRIPis512octets.Thefirstbyteisusedforcommandssuchasripupdaterequestandripupdateresponse.ThenextbyteisusedfortheVersionfield,whichissetto1forRIP-1.Thenext2bytesmustbe0.The2-bytefieldafterthisisusedfortheaddressfamilyidentifier;thenext14

bytesareallocatedforthenetworkaddress,asshowninFigure2-2.InthecaseofIP,only4bytesofthose14areusedfortheIPaddress.Theremaining10bytesareunusedinRIP-1,althoughtheyareusedintheRIPVersion2(RIP-2)packetformat.Thenext4bytesareusedfortheRIPmetric,whichcanbeupto16.TheportionfromtheaddressfamilyidentifieruptotheMetricfieldcanberepeated25times,toyieldthemaximumRIPpacketsizeof512bytes.

Figure2-2RIP-1PacketFormat

RIPBehaviorRIPfollowscertainruleswhenitsendsandreceivesupdates.Thissectioncoverstherulesforsendingandreceivingupdates.

RIPRulesforSendingUpdatesWhenRIPsendsanupdate,itperformsseveralchecks.InFigure2-3,tworoutersarerunningRIPtogether.Router1isconnectedtotwomajornets,131.108.0.0/16and137.99.0.0/16.Themajornet131.108.0.0isfurtherdividedintotwosubnets:131.108.5.0/24and131.108.2.0/24,whichisactuallyconnectedtoRouter2.

Figure2-3ExampleofRIPBehavior

BeforeRouter1sendsaRIPupdatetoRouter2,itperformsthecheckasshowninFigure2-4.

Figure2-4FlowchartThatExplainsRIPRulesWhenSendingUpdates

WhenRIPsendstheupdate,itcheckstoseewhethertheadvertisednetworkorsubnetisonthesamemajornetworkastheinterfacethatissourcingtheRIPpacket.IftheadvertisednetworkorsubnetisonadifferentmajornetworkfromtheinterfacesourcingtheRIPpacket,thenetworkisautosummarized.Inotherwords,RIPsendsonlythemajornetinformationinitsroutingupdate.Forexample,inFigure2-3,whenRouter1sendstheRIPupdatetoRouter2,itautosummarizesthesubnet137.99.88.0into137.99.0.0.Iftheadvertisednetworkorsubnetisonthesamemajornetworkastherouter’sinterfacesourcingtheRIPpacket,RIPdetermineswhethertheadvertisedsubnethasthesamemaskastheinterfacethatissourcingtheRIPupdate.Ifithasthesamemask,RIPadvertisesthatnetwork;otherwise,RIPdropsthatnetwork.

RIPRulesforReceivingUpdatesWhenthereceivingsidegetsanupdatefromRIP,theupdatecancontaineitherasubnetnumber,ahostaddress,anetworknumber,orall0s(indicatingthedefaultroute):•Subnetnumber(suchas131.108.1.0)•Hostaddress(suchas131.108.1.1)•Networknumber(suchas131.108.0.0)•Defaultroute(suchas0.0.0.0)

Figure2-5illustratesthechecksperformedbyRIPonthereceivingside.

Figure2-5FlowchartThatExplainsRIPRulesWhenReceivingUpdates

WhenRIPreceivestheupdate,itdetermineswhetherthesubnetreceivedintheupdatebelongstothesamemajornetworkasthereceivinginterface.Ifso,Router2appliesthemaskofthereceivinginterface.IfthehostbitsaresetinthehostportionoftheRIPupdate,thereceivingrouterappliesthehostmask.Ifthatsubnetbelongstoadifferentmajornetwork,RIPcheckswhetheranysubnetsofthismajornetworkalreadyexistintheroutingtableanddetermineswhethertheyareknownfrominterfacesotherthantheonethatreceivedtheupdate.Notethatthenetworkinthisupdateshouldbeamajornetwork.Iftheansweris“yes,”Router2ignorestheupdate.Iftheansweris“no,”Router2appliesaclassfulmask.Iftheupdatecameacrossanunnumberedlink,itmightcontainsubnetinformation(bitsinthesubnetportionofthenetworkaddressareset).Router2thenappliesahostmask.Iftheupdatecarriessubnetbroadcast—forexample,131.108.5.127/25orClassDorE—theRIPupdatemustbeignored.

ExampleofSendingUpdatesThissectionshowsanexampleexplainingRIPbehaviorwhenitsendsanupdate.InFigure2-6,tworoutersarerunningRIP.ThelinkbetweenRouter1andRouter2isin131.108.0.0.TheEthernetinterfaceonRouter1isin131.108.0.0aswell.Router1isalsoconnectedtoanothermajornetwork,whichis137.99.0.0.

Figure2-6AnExampleofRIPBehaviorWhenSendingandReceivingUpdates

InFigure2-6,whenRouter1sendsanupdatetoRouter2,itperformsthesechecks:1Is131.108.5.0/24partofthesamemajornetworkas131.108.2.0/24,whichissourcingtheupdate?2Yes.Does131.108.5.0/24havethesamesubnetmask131.108.2.0/24,whichissourcingtheupdate?3Yes.Router1advertisesthenetwork.4Is137.99.88.0/24partofthesamemajornetworkas131.108.2.0/24,whichissourcingtheupdate?5No.Router1summarizes137.99.88.0/24atthemajornetworkboundaryandadvertisestherouteas137.99.0.0.

ThisprocessresultsinRouter1including131.108.5.0and137.99.0.0initsupdatetoRouter2.YoucanseethisintheoutputdisplayedusingthedebugipripcommandonRouter1,asdemonstratedinExample2-1.Example2-1debugipripCommandOutputRevealsRIPUpdateInformationSent

Router1#debugipripRIP:sendingv1updateto255.255.255.255viaSerial0(131.108.2.2)subnet131.108.5.0,metric1network137.99.0.0,metric1

ExampleofReceivingUpdatesExample2-2providesoutputfromthedebugipripcommandtodisplaytheroutingupdatereceivedonRouter2fromRouter1.Example2-2debugipripCommandOutputRevealsRIPUpdateInformationReceived

Router2#debugipripRIP:receivedv1updatefrom131.108.2.2onSerial0131.108.5.0in1hops137.99.0.0in1hops

Router2inFigure2-6performsthefollowingcheckstodeterminewhatmasktoapplyonareceivednetwork:1Isthereceivedmajornetwork137.99.0.0thesameas131.108.2.0,whichistheaddressassignedtotheinterfacethatreceivedtheupdate?

2No.Doanysubnetsofthismajornetworkalreadyexistintheroutingtableknownfromotherinterfaces?

3No.Router2appliesthenaturalmask(/16)because137.99.0.0isaClassBaddress.

4Doessubnet131.108.5.0belongtothesamemajornetworkassubnet131.108.2.0,whichistheinterfacethatreceivedtheupdate?

5Yes.Router2appliesthemask/24,whichisthemaskoftheinterfacethatreceivedtheupdate.ThisprocessresultsinthenetworksandmasksinRouter2’sroutingtable,displayedusingtheshowiproutecommand(seeExample2-3).Example2-3showiprouteCommandOutputRevealstheNetworksandMasksinRouter2’sRoutingTable

Router2#showiprouteR137.99.0.0/16[120/1]via131.108.2.2,00:00:07,Serial0131.108.0.0/24issubnetted,3subnetsR131.108.5.0[120/1]via131.108.2.2,00:00:08,Serial0C131.108.2.0isdirectlyconnected,Serial0C131.108.3.0isdirectlyconnected,Ethernet0

WhyRIPDoesn’tSupportDiscontiguousNetworksAdiscontiguousnetworkiscomprisedofamajornetworkseparatedbyanothermajornetwork.InFigure2-7,network131.108.0.0isseparatedbyasubnetofnetwork137.99.0.0;here,131.108.0.0isadiscontiguousnetwork.

Figure2-7AnExampleofaDiscontiguousNetwork

RIPisaclassfulprotocol.WheneverRIPadvertisesanetworkacrossadifferentmajornetworkboundary,RIPsummarizestheadvertisednetworkatthemajornetworkboundary.InFigure2-7,whenRouter1sendsanupdatecontaining131.108.5.0toRouter2across137.99.88.0,itconverts131.108.5.0/24into131.108.0.0/16.Thisprocessiscalledautosummarization.Router1takesthefollowingstepsbeforesendinganupdatetoRouter2:1Is131.108.5.0/24partofthesamemajornetworkas137.99.88.0/24,whichisthesubnetassignedtotheinterfacethat’ssourcingtheupdate?

2No.Router1summarizes131.108.5.0/24andadvertisestheroute131.108.0.0/16.ThedebugipripcommandoutputonRouter1showstheupdatesentbyRouter1,asdemonstratedinExample2-4.Example2-4debugipripCommandOutputRevealsRIPUpdateInformationSentbyRouter1inFigure2-7

Router1#debugipripRIP:sendingv1updateto255.255.255.255viaSerial0(137.99.88.2)network131.108.0.0,metric1

Router2goesthroughthefollowingstepsbeforeacceptingtheupdatefromRouter1:1Isthemajornetworkreceived(131.108.0.0)thesameasthemajornetworkof137.99.88.0/24,whichisthesubnetassignedtotheinterfacethatreceivedtheupdate?

2No.Doanysubnetsofthismajornetworkalreadyexistintheroutingtableknownfrominterfacesotherthanthatwhichreceivedtheupdate?

3Yes.Router2ignorestheupdate.Again,debugipripcommandoutputonRouter2showstheupdatereceivedbyRouter2,asdemonstratedinExample2-5.Example2-5debugipripCommandOutputRevealsRIPUpdateInformationReceivedbyRouter2inFigure2-7

Router2#debugipripRIP:receivedv1updatefrom137.99.88.1onSerial0131.108.0.0in1hops

TheroutingtableofRouter2,asdemonstratedintheshowiproutecommandoutputinExample2-6,showsthattheupdatewasignored.Theonlyentryforanysubnetworkornetworkon131.108.0.0istheonedirectlyconnectedtoEthernet0.Example2-6showiprouteCommandOutputRevealsThattheRoutingTableforRouter2inFigure2-7DoesNotReflecttheAdvertisedRouteSentbyRouter1

137.99.0.0/24issubnetted,1subnetsC137.99.88.0isdirectlyconnected,Serial0131.108.0.0/24issubnetted,3subnetsC131.108.2.0isdirectlyconnected,Ethernet0

Toavoidhavingupdatesignored,configureastaticrouteonbothroutersthatpointstowardthespecificsubnets.Forexample,onRouter1,configurethefollowing:

Router1(config)#iproute131.108.2.0255.255.255.0137.99.88.1

OnRouter2,configurethefollowing:Router2(config)#iproute131.108.5.0255.255.255.0137.99.88.2

WhyRIPDoesn’tSupportVariable-LengthSubnetMaskingThecapabilitytospecifyadifferentsubnetmaskforthesamenetworknumberiscalledvariable-lengthsubnetmasking(VLSM).RIPandIGRPareclassfulprotocolsandareincapableofcarryingsubnetmaskinformationintheirupdates.BeforeRIPorIGRPsendsanupdate,itperformsacheckagainstthesubnetmaskofthenetworkthatisabouttobeadvertised,withthesubnetmaskoftheinterfacesourcingtheupdate.Ifthetwosubnetmasksdon’tmatch,theupdategetsdropped.Thefollowingexampledemonstratesthisconcept.InFigure2-8,Router1hasthreesubnetswithtwodifferentmasks(/24and/30).

Figure2-8AnExampleofaVLSMNetwork

Router1goesthroughthefollowingstepsbeforesendinganupdatetoRouter2:1Router1checkstoseeif131.108.5.0/24ispartofthesamemajornetworkas131.108.6.0/30,whichisthenetworkassignedtotheinterfacethatissourcingtheupdate.

2Itispartofthesamemajornetwork,soRouter1determineswhether131.108.5.0/24hasthesamesubnetmaskas131.108.6.0/30.

3Becausethesubnetmasksarenotthesame,Router1dropsthenetworkanddoesn’tadvertisetheroute.

4Router1nowdetermineswhether131.108.7.0/30ispartofthesamemajornetworkas131.108.6.0/30,whichisthenetworkassignedtotheinterfacethatissourcingtheupdate.

5Itispartofthesamemajornetwork,soRouter1nextdetermineswhether131.108.7.0/30hasthesamesubnetmaskas131.108.6.0/30.

6Becausethetwosubnetmasksarethesame,Router1advertisesthenetwork.TheprecedingproceduredeterminedthatRouter1includesonly131.108.7.0initsupdatethatissenttoRouter2.ThedebugipripcommandinExample2-7actuallyshowstheupdatesentbyRouter1.Example2-7debugipripCommandOutputRevealsRIPUpdateInformationSentbyRouter1toRouter2,asIllustratedinFigure2-8

RIP:sendingv1updateto255.255.255.255viaSerial0(131.108.6.2)subnet131.108.7.0,metric1

NoticeintheoutputinExample2-7thattheonlysubnetincludedintheupdateis131.108.7.0.Thesubnet131.108.5.0isnotincludedbecauseithasadifferentsubnetmask.ThisresultsinthefollowingentryinRouter2’sroutingtabledisplayedbytheshowiproutecommand(seeExample2-8).Example2-8showiprouteCommandOutputRevealsThattheSubnet131.108.5.0/25IsMissingfromRouter2’sRoutingTable

Router2#showiproute131.108.0.0/30issubnetted,3subnetsR131.108.7.0[120/1]via131.108.2.2,00:00:08,Serial0C131.108.6.0isdirectlyconnected,Serial0C131.108.2.0isdirectlyconnected,Ethernet0

Toavoideliminatingsubnetsfromroutingupdates,eitherusethesamesubnetmaskovertheentireRIPnetworkorusestaticroutesfornetworkswithdifferentsubnetmasks.

DefaultRoutesandRIPCisco’sRIPimplementationsupportsthepropagationofadefaultroute,alsoknownas0.0.0.0/0.WhenRIPfindsadefaultrouteinitsroutingtable,itautomaticallyadvertisesthisintheRIPupdate.Oneimportantthingtorememberhereisthatthedefaultroutemusthaveavalidmetric.Forexample,ifthedefaultrouteislearnedthroughOSPFandthemetricis20,RIPwilladvertisethisrouterwithametricofinfinity(16).So,forthissituation,thedefault-metriccommandmustbeusedundertherouterripcommandtoensurethatthepropermetricisassignedtotheupdate.ClasslessandclassfulIProutingconceptsplayanimportantrole,especiallywithdefaultroutes.WithclassfulIProuting,iftherouterreceivesapacketdestinedforasubnetthatitdoesnotrecognizeandthenetworkdefaultrouteismissingintheroutingtable,therouterdiscardsthepacket.Figure2-9explainsthisbehavior.

Figure2-9ClassfulIPRouting

Here,HostXissendingtraffictothe131.108.3.0/24subnet.RouterR1willdiscardthesepacketsbecauseitdoesnothavearoutefor131.108.3.0/24.Trafficwillnotbesendtothedefaultroutebecauseoftheclassfulnatureofrouting.IfR1enablesIPclasslessrouting,R1willforwardtraffictothedefaultroute.EnablingIPclasslessroutingisrecommendedwhendefaultnetworkordefaultroutesareused.

ProtocolExtensiontoRIPRIPVersion2(RIP-2)madesomeimprovementsandenhancementstoRIP-1.RIP-2supportsVLSManddiscontiguousnetworks,anditoffersthefollowingenhancements:•Routetag•Subnetmask•Next-hopmetric•Multicastcapability•Authentication

Figure2-10showstheRIP-2packetformat.Thesectionsthatfollowdiscusseachoftheenhancements

andnewpacketfieldsingreaterdetail.


RouteTagTheRouteTagfieldisa2-bytefieldthatallowsRIProutestobeassignedwithauniqueintegervalue.TheroutingtabledisplayshowstheroutetagforeachRIProute,ifassigned.ThisroutetagplaysanimportantroleduringredistributionwithRIP.AnyroutethatisredistributedintoRIPgetstagged,todistinguishbetweeninternalRIPinformationandexternalRIPinformation.WhenredistributedroutesinRIPareassignedwithroutetags,itbecomeseasiertocontrolredistributionoftaggedroutesintootherprotocols.Insteadofmatchingagainsteachroutewhenredistributingintootherprotocols,RIProutescansimplybematchedagainstthetagthattheywereassigned.Forexample,considerthat10staticroutesinarouterareredistributedinRIPandareassignedatagof20.ThesestaticrouteswillbeadvertisedinRIPasexternalrouteswithatagof20.IfinsomeotherrouterRIPisbeingredistributedintoOSPFandOSPFwantsonlythose10staticroutestoberedistributed,OSPFcansimplymatchthetaginformationinsteadoflistingeachstaticrouteinitsredistributioncommands.Inaddition,ifOSPFisbeingredistributedbackintoRIPatsomeotherrouter,RIPshoulddenyanyroutesthataretaggedwith20.MatchingagainsttagsthusavoidsIProutingloopsaswell.

SubnetMaskUnlikeRIP-1,RIP-2carriessubnetmaskinformationalongwiththeIPnetworknumber.IfanIPnetworkisvariablysubnetted,RIP-2picksthesubnetmaskofeachsubnetandadvertisestoRIP-2neighbors.RIP-2routersinthenetworkinstallrouteswiththeirrespectivesubnetsthoughavariablelengthof,say,8,15/,/24,andsoon.SupportofVLSMalsoenablesRIP-2tounderstanddiscontiguousnetworks.Inadiscontiguousnetwork,theIPsupernetisdividedbyanotherIPblock.BecauseRIP-2cancarrysubnetmaskinformation,eachRIP-2routerhasaroutewiththeactualmaskandrouterscanforwardtrafficproperly.

NextHopTheNextHopfieldwasaddedtoavoidanextrahopduringpacketforwarding.ForthosefamiliarwithOSPF,theNextHopfieldholdsnearlythesameroleastheforwardingaddressforOSPFexternalroutes.

InFigure2-11,OSPFisenabledbetweenRouter2andRouter5.RIPisenabledonRouter2,Router3,andalltheotherroutersbehindRouter2andRouter3.Router2isdoingredistributionbetweenOSPFandRIP.NowwhenapacketfromRouter1isdestinedforOSPFnetworksandarrivesatRouter2,itisforwardedtoRouter5.


WhenapacketfromRouter4destinedtotheOSPFnetworkarrivesatRouter3,ifthereisnonext-hopinformation(incaseofRIP-1),Router3forwardsthepackettotheoriginator,Router2.ThenRouter2forwardsittoRouter5.ThisisanextrahopthatRouter3musttaketogettotheOSPFnetwork.WiththeNextHopfieldintheRIPpacket,whenapacketdestinedtotheOSPFnetworkarrivesatRouter3,theRIProuteforthedestinationnetworkhasitsnexthopsettoRouter5insteadofRouter2.Asaresult,Router3doesnotforwardthepackettoRouter2—instead,itforwardsthepacketstraighttoRouter5.

MulticastCapabilityRIP-2usesmulticastwhensendinganupdatetoallitsneighbors.Thisreducesunnecessarybroadcastfloodingonthewire.ThemulticastaddressthatRIP-2usesis224.0.0.9.AlldevicesonthewirerunningRIP-2listenforRIP-2multicastpacketson224.0.0.9atamulticastMACaddress(01-00-5E-00-00-09).DevicesnotrunningRIP-2simplydiscardRIP-2messagesonthewire,reducingunnecessaryload.

AuthenticationRIP-2supportssimplepasswordauthentication,tovalidatetrustedRIP-2neighbors.RIP-2speakersdeterminewhetherauthenticationisusedbylookingattheaddressfamilyidentifier(AFI)inRIP-2packet.AFIinRIP-2headerindicateswhatkindofaddressesarepresentintherestofthepacket.IftheAFIvalueis0xFFFF,thismeansthattheremainderoftheentireRIPpacketcontainsauthenticationinformation.Figure2-12showsthepacketformatwhenauthenticationisused.

Figure2-12RIP-2PacketFormatforAuthentication

CompatibilityIssuesRIP-1andRIP-2canberuntogetherinanetwork.Youshouldbeawareofafewthingswhenrunningbothprotocolsinyournetwork:•Autosummarization—RIP-1andRIP-2canberuntogetherinanetwork.RFC1723forRIP-2recommendsdisablingtheautosummarizationfeaturewhenusingbothRIP-1andRIP-2.•Subnetadvertisement—IfamorespecificsubnetisadvertisedtoaRIP-1router,theroutermightmistakenlytakeitasahostrouteupdate.•Queries—WhenaRIP-2routerreceivesaqueryrequestfromaRIP-1router,itrespondswithaRIP-1message.IftherouterisconfiguredtosendonlyRIP-2messages,suchaqueryrequestmustbeignored.•Versionfield—TheVersionfieldintheRIPpacketdetermineshowtohandleRIP-1andRIP-2packets:—Ifversion=0intheRIPpacket,thepacketisdiscarded,regardlessofwhatversionthereceivingrouterisrunning.

—Ifversion=1intheRIPpacket,allthe“mustbezerofields”arechecked(refertoFigure2-9).Iftheversionisnonzero,thepacketisdiscarded,regardlessofwhatversionthereceivingrouterisrunning.

—Ifversion=2intheRIPpacketandthereceivingrouterisrunningRIP-1,thereceivingroutershouldlookatonlytherelatedinformationinthepacket.Allthe“mustbezerofields”areignored.

SummaryRIPisadistancevectorprotocolthatusestheBellman-FordalgorithmtocomputeIProutesdynamically.RIPissuitabletoruninsmallIPnetworksbecauseofitshopcountlimitof15.RIPwasdesignedasasimpleIProutingprotocolthatexchangesacompleteroutingtableatafixedinterval(30seconds)withotherroutersrunningRIP.InlargernetworkswithalargenumberofIProutes,sendingacompleteroutingtableevery30secondsisnotpractical.Thisresultsinextraworkforthesenderandreceiver,anditconsumesunnecessarybandwidthandprocessingtime.Therefore,RIPisusedinsmallernetworkswitha

hopcountoflessthan15andasmallnumberofroutesaswell.RIPoffersadescentalgorithmforloopavoidancebyusingsplithorizonandpoisonreverse.Splithorizontakescareoftheloopsbynotadvertisinganyroutesbacktotheinterfacewhereitlearnedtheroutes.PoisonreversecausesroutestobeadvertisedwiththeinfiniteRIPmetric(16),thusremovingRIProutesthatmightbeloopedordown.Becauseanychangeinthenetworktakesatleast30secondstopropagate,theconceptofholddowncausestheRIProutingtabletowaitforthreetimestheadvertisementinterval.ThisimplementationisdesignedforwhenaRIProuteisnotadvertisedbecauseitmighthavebeendownforalittleover30seconds.Thereceivingroutersshouldwaitfor90secondstoremovetheroutefromtheroutingtable.Ifaroutescomesbackbefore90seconds,itisreinstalledandisadvertisedthroughoutthenetwork.IntheearlydaysofIPnetworking,RIPwastheprotocolofchoiceinsmallerIPnetworks.Sincethen,alotofnewIPprotocolshavebeendevelopedtobemorerobustanddynamicthanRIP;theycanscaleuptoamuchlargernumberofroutersthan15.Theadventofthesenewprotocols,suchasOSPF,IS-IS,andEIGRP,resultedinalmostcompletephaseoutofRIPfromlargernetworkstoday.ThesenewprotocolshaveimproveduponthelimitationsofRIPintermsofconvergenceandscalability,andtheyofferthesupportforVLSManddiscontiguousnetworksthatRIP-1lacked.AlthoughRIP-2improvedRIPwithnewfeatures,suchasroutetags,queries,subnetmasks,nexthops,multicasting,andauthentication,largernetworksstillpreferOSPF,IS-IS,andEIGRPasIProutingprotocols.

ReviewQuestions1WhatisthemaximummetricinRIP?2Whydoesn’tRIPsupportdiscontiguousnetworks?3Whydoesn’tRIPsupportVLSM?4WhatisthedefaultupdateintervalforRIP?5WhattransportprotocolandportnumberdoRIPuseforsendingupdates?6Whatisthepurposeofthesplit-horizontechnique?7DoesRIPVersion2solvethediscontiguousnetworkproblembydefault?8DoesRIPVersion2alsousebroadcastforsendingupdates?9DoesRIPsupportauthentication?

FurtherReadingRefertothefollowingRFCsformoreinformationaboutRIP.YoucanaccessallRFCsonlineatwww.isi.edu/in-notes/rfcxxxx.txt,wherexxxxisthenumberoftheRFCthatyouwanttoread.

RFC1058,“RoutingInformationProtocol”RFC1723,“RIPVersion2”RFC2453,“RIPVersion2”RFC1582,“ExtensionstoRIPtoSupportDemandCircuits”RFC2091,“TriggeredExtensionstoRIPtoSupportDemandCircuits”RFC2082,“RIP-2MD5Authentication”

Chapter3.TroubleshootingRIP

Thischaptercoversthefollowingkeytopics:•TroubleshootingRIProutesinstallation•TroubleshootingRIProutesadvertisement•TroubleshootingroutessummarizationinRIP•TroubleshootingRIPredistributionproblems•Troubleshootingdial-on-demand(DDR)routingissuesinRIP•TroubleshootingrouteflappingprobleminRIP

ThischapterdiscussessomeofthecommonproblemsinRIPandtellshowtoresolvethoseproblems.Atthistime,noRIPerrormessageswillhelptroubleshootingRIPproblems.Asaresult,youwillneedtorelyondebugs,configurations,andusefulshowcommands,whichwe’llprovidewherenecessaryinthischapter.TheflowchartsthatfollowdocumenthowtoaddresscommonproblemswithRIPwiththemethodologyusedinthischapter.DebugssometimescanbeveryCPU-intensiveandcancausecongestiononyournetwork.Therefore,wedonotrecommendturningonthesedebugsifyouhavealargenetwork(thatis,morethan100networksorsubnetsinRIP).Sometimes,therecouldbemultiplecausesforthesameproblem—forexample,Layer2isdown,thenetworkstatementiswrong,andthesenderismissingthenetworkstatement.BringingupLayer2andfixingthenetworkstatementmightnotfixthenetworkproblembecausethesenderisstillmissingthenetworkstatement.Therefore,ifonescenariodoesn’tfixthenetworkproblem,checkintootherscenarios.ThewordRIP,ingeneral,referstobothRIPVersion1(RIP-1)andRIPVersion2(RIP-2).TheproblemsdiscussedinthischapteraremostlyrelatedtoRIP-1,unlessspecifiedasRIP-2.

FlowchartstoSolveCommonRIPProblems

TroubleshootingRIPRoutesInstallationThissectiondiscussesseveralpossiblescenariosthatcanpreventRIProutesfromgettinginstalledintheroutingtable.ThissectionisselectedfirstinthetroubleshootinglistbecausethemostcommonprobleminRIPisthatroutesarenotinstalledintheroutingtable.Iftheroutesarenotinstalledintheroutingtable,therouterwillnotforwardthepacketstodestinationsthatarenotintheroutingtable.Whenthishappens,itcreatesreachabilityproblems.Usersstartcomplainingthattheycannotreachaserveroraprinter.Whenyouinvestigatethisproblem,thefirstthingtoaskis,“DoIhavearouteforthisdestinationthatusersarecomplainingabout?”

Threepossibilitiesexistforroutesnotgettinginstalledintheroutingtable:•Receiver’sproblem—TherouterisreceivingRIPupdatesbutisnotinstallingtheRIProutes.•Intermediatemediaproblem(Layer2)—MostlyrelatedtoLayer2,thesenderhassenttheRIPupdates,buttheygotlostinthemiddleandthereceiverdidn’treceivethem.•Sender’sproblem—ThesenderisnotevenadvertisingRIProutes,sothereceivingsideisnotseeinganyRIProutesintheroutingtable.

Thesender’sproblemwillbediscussedinthesection“TroubleshootingRIPRouteAdvertisement.”TwoproblemsarerelatedtoRIPinstallation:•RIProutesarenotintheroutingtable.•RIPisnotinstallingallequal-costpathroutes.

Inthefirstproblem,RIPisnotinstallinganypathtoaspecificnetwork.Inthesecondproblem,RIPisnotinstallingallpathstothenetwork.Notethat,inthesecondproblem,thedestinationdeviceisstillreachable,butit’snotlistingallpossiblepaths.

Problem:RIPRoutesNotintheRoutingTableTheroutingtablemusthaveanetworkentrytosendthepacketstothedesireddestination.Ifthereisnoentryforthespecificdestination,therouterwilldiscardallthepacketsforthisdestination.Example3-1showsthattheroutingtableofR2doesn’tholdanentryfornetwork131.108.2.0.Example3-1RoutingTableforR2ShowsNoRIPRoutesforSubnet131.108.2.0

R2#showiproute131.108.2.0%SubnetnotintableR2#

Thepossiblecausesforthisproblemareasfollows:•Missingorincorrectnetworkstatement•Layer2down•Distributelistblockingtheroute•AccesslistblockingRIPsourceaddress•AccesslistblockingRIPbroadcast/multicast•Incompatibleversiontype•Mismatchauthenticationkey(RIP-2)•Discontiguousnetwork•Invalidsource•Layer2problem(switch,FrameRelay,otherLayer2media)•Offsetlistwithalargemetricdefined•RoutesthatreachedRIPhop-countlimit•Senderproblem(discussedinthenextchapter)

Figure3-1providesanetworkscenariothatwillbeusedasthebasisfortroubleshootingamajorityoftheaforementionedcausesoftheproblemofRIProutesnotintheroutingtable.Thesectionsthatfollowcarefullydissecthowtotroubleshootthisproblembasedonspecificcauses.

Figure3-1ExampleTopologyfortheProblemofRIPRoutesNotintheRoutingTable

Figure3-1showsasetupinwhichRouter1andRouter2arerunningRIPbetweenthem.RIPRoutesNotintheRoutingTable—Cause:MissingorIncorrectnetworkStatement

Whenyouconfirmthattherouteismissingfromtheroutingtable,thenextstepistofindoutwhy.Aroutecanbemissingfromtheroutingtableformanyreasons.Theflowchartsatthebeginningofthischaptercanhelpisolatethecausethatseemstofitmostinyoursituation.Theobviousthingtocheckafterdiscoveringthattheroutesarenotintheroutingtableistherouter’sconfigurations.Alsochecktoseewhetherthenetworkstatementunderrouterripisproperlyconfigured.Whenthenetworkstatementisconfigured,itdoestwothings:•EnablesRIPontheinterfaceandactivatesthecapabilitytosendandreceiveRIPupdates•AdvertisesthatnetworkinaRIPupdatepacket

Ifthenetworkstatementunderrouterripcommandisnotconfiguredormisconfigured,itcancausethisproblem.Figure3-2showstheflowcharttofollowtosolvethisproblembasedonthiscause.

Figure3-2ProblemResolutionFlowchartDebugsandVerification

Example3-2showstheconfigurationforRouterR2(asillustratedinFigure3-1).Theloopbackinterfaceisusedinthisexampleandmanyotherexamplesthroughoutthechapter.Iftheloopbackinterfaceisreplacedwithanyotherinterface,itwillnotchangethemeaning.WesuggestthatyoutreattheloopbackasanyinterfacethatisupandfunctionalandthathasavalidIPaddress.Example3-2ConfigurationforRouterR2fromFigure3-1

interfaceLoopback0ipaddress131.108.3.2255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0!routerripnetwork131.107.0.0!

ReferbacktoFigure3-1andcompareittotheconfigurationforR2inExample3-2.Younoticethatnetwork131.108.0.0ismissingfromR2’sconfigurations.Example3-3showstheoutputoftheshowipprotocolscommandonR2.Thisoutputshowsthattheroutinginformationsourceisalsonotdisplaying131.108.1.1asagateway.Example3-3showipprotocolsMissingGatewayInformationforRoutingInformationSource

R2#showipprotocols

RoutingProtocolis"rip"Sendingupdatesevery30seconds,nextduein11secondsInvalidafter180seconds,holddown180,flushedafter240OutgoingupdatefilterlistforallinterfacesisIncomingupdatefilterlistforallinterfacesisRedistributing:ripDefaultversioncontrol:sendversion1,receiveanyversionAutomaticnetworksummarizationisineffectRoutingforNetworks:131.107.0.0RoutingInformationSources:GatewayDistanceLastUpdateDistance:(defaultis120)

DebugCommands

Example3-4showsthedebugipripoutput.Inthisdebug,R2isignoringtheRIPupdatescomingfromR1becauseRIPisnotenabledonEthernet0.Thisisbecauseofthelackofanetworkstatementfor131.108.0.0underrouterripintherouterconfigurationmode.Example3-4debugipripCommandOutputDisplaysThatRIPUpdatesfromRouterR1AreBeingIgnored

R2#debugipripRIPprotocoldebuggingisonR2#RIP:ignoredv1packetfrom131.108.1.1(notenabledonEthernet0)R2#

Solution

BecausethenetworkstatementismissingonRouter2,asshowninExample3-2,itignoresRIPupdatesarrivingonitsEthernet0interface,asseeninthedebugoutputinExample3-4.Thisproblemcanalsohappenifincorrectnetworkstatementsareconfigured.TakeaClassCaddress,forexample.Insteadofconfiguring209.1.1.0,youconfigure209.1.0.0,assumingthat0willcoveranythinginthethirdoctet.RIP-1isaclassfulprotocol,anditassumestheclassfulnetworkstatements.Ifacidrstatementisconfiguredinstead,RIPwillnotfunctionproperly.

Tocorrectthisproblem,youmustaddthenetworkstatementintheconfigurations.Example3-5showsthenewconfigurationforRouterR2thatsolvesthisproblem.Example3-5NewConfigurationofR2ThatSolvestheProblem

interfaceLoopback0ipaddress131.108.3.2255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0!routerripnetwork131.107.0.0network131.108.0.0

Example3-6showstheoutputofshowipprotocolsonR2.Thisoutputdisplaysthegatewayinformationnow.Example3-6showipprotocolsShowingGatewaySettotheR1’sInterfaceIPAddress

R2#showipprotocols

RoutingProtocolis"rip"Sendingupdatesevery30seconds,nextduein12secondsInvalidafter180seconds,holddown180,flushedafter240OutgoingupdatefilterlistforallinterfacesisIncomingupdatefilterlistforallinterfacesisRedistributing:ripDefaultversioncontrol:sendversion1,receiveanyversionInterfaceSendRecvTriggeredRIPKey-chainEthernet0112Loopback0112AutomaticnetworksummarizationisineffectRoutingforNetworks:131.108.0.0RoutingInformationSources:GatewayDistanceLastUpdate131.108.1.112000:00:09Distance:(defaultis120)

Example3-7showstheoutputofshowiproute,whichshowsthatRouterR2islearningtheRIProuteaftertheconfigurationchange.Example3-7showiprouteDisplaystheRouteBeingLearnedAfterFixingtheProblem

R2#showiproute131.108.2.0Routingentryfor131.108.2.0/24Knownvia"rip",distance120,metric1RedistributingviaripLastupdatefrom131.108.1.1onEthernet0,00:00:11agoRoutingDescriptorBlocks:*131.108.1.1,from131.108.1.1,00:00:11ago,viaEthernet0Routemetricis1,trafficsharecountis1

RIPRoutesNotintheRoutingTable—Cause:Layer1/2IsDown

OnecauseforroutesnotintheroutingtableisLayers1or2beingdown.IfLayers1or2aredown,it’snotaRIPproblem.Thefollowingisalistofthemostcommonthingstocheckiftheinterfaceorlineprotocolisdown:

•Unpluggedcable•Loosecable•Badcable•Badtransceiver•Badport•Badinterfacecard•Layer2problemattelco,incaseofaWANlink•Missingclockstatement,incaseofback-to-backserialconnection

Figure3-3showstheflowcharttofollowtosolvethisproblembasedonthiscause.

Figure3-3FlowcharttoSolveWhyRIPRoutesDon’tShowUpinaRoutingTableDebugsandVerification

Example3-8showsthattheEthernetinterface’slineprotocolisdown,indicatingthatsomethingiswrongatLayer1orLayer2.Example3-8showinterfaceoutputDisplaysThattheLineProtocolIsDown

R2#showinterfaceethernet0Ethernet0isup,lineprotocolisdownHardwareisLance,addressis0000.0c70.d41e(bia0000.0c70.d41e)Internetaddressis131.108.1.2/24

Debugs

Example3-9showstheoutputofdebugiprip.Inthisdebug,R2isnotsendingorreceivinganyRIPupdatesbecauseLayer2isdown.Example3-9debugipripCommandOutputShowsNothingIsBeingSent

R2#debugiprip

RIPprotocoldebuggingisonR2#

Solution

RIPrunsaboveLayer2.RIPcannotsendorreceiveanyroutesifLayer2isdown.TheLayer2problemmustbefixed.Sometimes,theproblemcouldbeassimpleasloosecables,oritcouldbeascomplexasbadhardware;inwhichcase,thehardwaremustbereplaced.Example3-10showstheoutputofshowinterfaceEthernet0onR2aftertheLayer2problemisfixed.Theoutputshowsthatthelineprotocolisnowup.Example3-10showinterfaceOutputAfterFixingtheLayer1/2ProblemShowstheInterfaceEthernet0IsNowUp

R2#showinterfaceEthernet0Ethernet0isup,lineprotocolisupHardwareisLance,addressis0000.0c70.d41e(bia0000.0c70.d41e)Internetaddressis131.108.1.2/24

Example3-11showstheoutputofshowiproute,whichillustratesthattheRIProuteisbeinglearnedafterfixingtheLayer1/2problem.Example3-11RoutingTableEntryAfterFixingtheLayer1/2Problem


RIPRoutesNotintheRoutingTable—Cause:distribute-listinIsBlockingtheRoute

Adistributelistisafilteringmechanismforroutingupdates.Thedistributelistcallsanaccesslistandcheckstoseewhichnetworksaresupposedtobepermitted.Iftheaccesslistdoesn’tcontainanynetwork,theroutingupdatewillbeautomaticallydenied.Adistributelistcanbeappliedoneitherincomingroutingupdatesoroutgoingroutingupdates.Inthisexample,thedistribute-listinisconfigured;however,theaccesslistdoesn’tcontainthepermitstatementfor131.108.0.0,soR2isnotinstallingtheseroutesintheroutingtable.Figure3-4showstheflowcharttofollowtosolvethisproblembasedonthiscause.


Example3-12showsthecurrentconfigurationofRouterR2.Inthisconfiguration,access-list1isusedtopermitnetwork131.107.0.0;however,thereisanimplicitdenyattheendofeveryaccesslist,so131.108.0.0willalsobedenied.Intheaccesslistconfiguration,network131.108.0.0isnotpermitted,sotherouterisnotinstallinganysubnetsofthe131.108.0.0network.Example3-12R2’sConfigurationShowsThatNetwork131.108.0.0IsBeingBlockedwithanImplicitdenyUnderaccess-list1

interfaceLoopback0ipaddress131.108.3.2255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0!routerripnetwork131.108.0.0distribute-list1in!access-list1permit131.107.0.00.0.255.255

Solution

Whenadistributelistisused,youshouldalwaysdouble-checkyouraccesslisttomakesurethatthenetworksthataresupposedtobepermittedactuallyarepermittedintheaccesslist.TheaccesslistinExample3-12permitsonly131.107.0.0anddenieseverythingelsebecausethereisanimplicitdenyattheendofeachaccesslist.Tofixthisproblem,permit131.108.0.0inaccess-list1.Example3-13showsthenewconfigurationofRouterR2withtheaccesslisttopermit131.108.0.0.Example3-13CorrectingtheConfigurationonR2toFixtheProblem

interfaceLoopback0

ipaddress131.108.3.2255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0!routerripnetwork131.108.0.0distribute-list1in!access-list1permit131.107.0.00.0.255.255access-list1permit131.108.0.00.0.255.255

Example3-14showsthatRouterR2islearningRIProutesaftertheconfigurationchange.Example3-14R2RoutingTableIsLearningtheRIPRoutesAftertheCorrection


RIPRoutesNotintheRoutingTable—Cause:AccessListBlockingRIPSourceAddress

Accesslistsareusedtofilterthetrafficbasedonthesourceaddress.Extendedaccesslistsareusedtofilterthetrafficbasedonthesourceordestinationaddress,T-2.Tofiltertheincomingandoutgoingtraffic,theseaccesslistsmaybeappliedontheinterfacewiththisinterface-levelcommand:

ipaccess-groupaccess-listnumber{in|out}

WhentheaccesslistisappliedinaRIPenvironment,alwaysmakesurethatitdoesn’tblockthesourceaddressoftheRIPupdate.Inthisexample,R2isnotinstallingRIProutesintheroutingtablebecauseaccess-list1isnotpermittingthesourceaddressofRIPupdatesfromR1.Figure3-5showstheflowcharttofollowtosolvetheproblembasedonthiscause.


Example3-15showsthecurrentconfigurationofrouterR2.TheaccesslistinR2isnotpermittingthesourceaddressofRIPupdates,thatis,131.108.1.1.InFigure3-1,131.108.1.1isthesourceaddressofR1RIPupdates.Becausethereisanimplicitdenyattheendofeachaccesslist,131.108.1.1willbeautomaticallydenied.Example3-15access-list1IsNotPermittingtheSourceAddress

R2#interfaceLoopback0ipaddress131.108.3.2255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0ipaccess-group1in!routerripnetwork131.108.0.0!access-list1permit131.107.0.00.0.255.255

Debugs

TheoutputofdebugipripinExample3-16showsthatRIPisonlysendingtheupdates,notreceivinganything,becausethesourceaddress131.108.1.1isnotpermittedintheinputaccesslistofR2.Example3-16debugipripOutputRevealsThatR2IsNotReceivingAnyRIPUpdates

R2#debugipripRIP:sendingv1updateto255.255.255.255viaEthernet0(131.108.1.2)RIP:buildupdateentriessubnet131.108.3.0metric1RIP:sendingv1updateto255.255.255.255viaLoopback0(131.108.3.1)

RIP:buildupdateentriessubnet131.108.1.0metric1RIP:sendingv1updateto255.255.255.255viaEthernet0(131.108.1.2)RIP:buildupdateentriessubnet131.108.3.0metric1RIP:sendingv1updateto255.255.255.255viaLoopback0(131.108.3.1)RIP:buildupdateentriessubnet131.108.1.0metric1R2#

Solution

Thestandardaccesslistspecifiesthesourceaddress.Inthiscase,thesourceaddressis131.108.1.1,whichisthesendinginterfaceaddressofR1.ThissourceaddressisnotpermittedinthestandardaccesslistofR2,soRIProuteswillnotgetinstalledintheroutingtableofR2.Tosolvethisproblem,permitthesourceaddressinaccesslist1.Example3-17showsthenewconfigurationchangetofixthisproblem.Example3-17TheModifiedAccessListPermitstheSourceAddress

R2#interfaceLoopback0ipaddress131.108.3.2255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0ipaccess-group1in!routerripnetwork131.108.0.0!access-list1permit131.107.0.00.0.255.255access-list1permit131.108.1.10.0.0.0

ThisproblemcanalsohappenwhenusingextendedaccesslistsiftheRIPsourceaddressisnotpermittedintheaccesslist.Thissolutionalsocanbeusedinthecaseofanextendedaccesslist.TheideahereistopermitthesourceaddressofRIPupdate.Example3-18showstheconfigurationwithanextendedaccesslist.Example3-18TheCorrectExtendedAccessListConfiguration,ifUsed

R2#interfaceLoopback0ipaddress131.108.3.2255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0ipaccess-group100in!routerripnetwork131.108.0.0!access-list100permitip131.107.0.00.0.255.255anyaccess-list100permitiphost131.108.1.1any

Example3-19showstheroutingtableofRouterR2,whichshowsthatithaslearningRIProutesaftertheconfigurationchange.

Example3-19R2IsReceivingRIPRoutesAfterFixingtheAccessListConfiguration


RIPRoutesNotintheRoutingTable—Cause:AccessListBlockingRIPBroadcastorMulticast(inCaseofRIP-2)

Accesslistsareusedtofiltercertaintypesofpackets.Whenusingaccesslistsontheinterfaceinbound,alwaysmakesurethattheyarenotblockingtheRIPbroadcastorUDPport520,whichisusedbyRIP-1andRIP-2(ortheRIPmulticastaddress,incasesofRIP-2).Iftheseaddressesarenotpermittedintheaccesslistthatisappliedontheinterfaceinbound,RIPwillnotinstallanyroutesintheroutingtablelearnedonthatinterface.Figure3-6showstheflowcharttofollowtosolvethisproblembasedonthiscause.


Example3-20showsthecurrentconfigurationofR2.Inthisconfiguration,RIP’sdestinationaddressof255.255.255.255isnotbeingpermitted.ThiswillresultinnoRIProutesbeinginstalledinR2’sroutingtable.TheRIPupdatessentfromR1tothedestinationof255.255.255.255willbeblockedbyR2.Example3-20R2ConfigurationDoesNotPermitRIP-1BroadcastAddresses

R2#interfaceLoopback0ipaddress131.108.3.2255.255.255.0!

interfaceEthernet0ipaddress131.108.1.2255.255.255.0ipaccess-group100in!routerripnetwork131.108.0.0!access-list100permitip131.107.0.00.0.255.255anyaccess-list100permitiphost131.108.1.1host131.108.1.2

Solution

RIP-1broadcastsitsroutingupdateson255.255.255.255.ThisaddressmustbepermittedintheinputaccesslistofthereceivingroutersothatitcanreceivetheRIPupdates.Example3-21showsthenewconfigurationforRouterR2.access-list100ismodifiedsothatitcanpermittheRIPbroadcastaddressthatwasbeingblockedbefore.Example3-21ConfiguringRouterR2’sInputAccessListtoAcceptRIP-1Broadcasts

interfaceLoopback0ipaddress131.108.3.2255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0ipaccess-group100in!routerripnetwork131.108.0.0!access-list100permitip131.107.0.00.0.255.255anyaccess-list100permitiphost131.108.1.1host131.108.1.2access-list100permitiphost131.108.1.1host255.255.255.255

IncasesofRIP-2,theconfigurationwillchangeslightly.Themulticastaddressneedstobepermittedinsteadofthebroadcastaddress,asshowninExample3-22.Example3-22ConfiguringRouterR2’sInputAccessListtoAcceptRIP-2Multicast

interfaceLoopback0ipaddress131.108.3.2255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0ipaccess-group100in!routerripversion2network131.108.0.0!access-list100permitip131.107.0.00.0.255.255anyaccess-list100permitiphost131.108.1.1host131.108.1.2access-list100permitiphost131.108.1.1host224.0.0.9

Example3-23showstheroutingtableofR2aftercorrectingtheproblem.Example3-23R2RoutingTableAfterCorrectingtheAccessListShowsThattheRIPRoutesAreBeingLearned

R2#showiproute131.108.2.0

Routingentryfor131.108.2.0/24Knownvia"rip",distance120,metric1RedistributingviaripLastupdatefrom131.108.1.1onEthernet0,00:00:07agoRoutingDescriptorBlocks:*131.108.1.1,from131.108.1.1,00:00:07ago,viaEthernet0Routemetricis1,trafficsharecountis1

RIPRoutesNotintheRoutingTable—Cause:IncompatibleRIPVersionType

WhenRIPisconfiguredonarouter,itisrunbydefaultasVersion1,whichmeansthatallitsinterfaceswillsendandreceiveRIP-1packetsonly.TorunVersion2ofRIP,youmustaddtheversion2lineunderrouterrip.WhenarouterrunningVersion1receivesaRIPupdatefromarouterrunningVersion2,itignorestheupdatesanddoesnotinstallanyroutesintheroutingtable.ForaroutertoacceptaVersion2packet,theinterfacemustbeconfiguredtoaccepttheRIP-2updates.Figure3-7showstheflowcharttofollowtosolvethisproblembasedonthiscause.


Example3-24showstheconfigurationofRouterR2.Inthisconfiguration,RIPisconfiguredtosendandreceiveVersion1packetsonly.Example3-24R2ConfigurationShowsThatItIsConfiguredforRIP-1,WhichIstheDefault

R2#interfaceLoopback0ipaddress131.108.3.2255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0!routerripnetwork131.108.0.0!

Example3-25showstheoutputofthedebugipripcommand.ThiscommandrevealsthatR2isreceivingaRIPpacketfromR1,whichisconfiguredtosendVersion2updates.Example3-25debugipripCommandOutputShowstheVersionIncompatibleMessageonR2

R2#debugipripRIPprotocoldebuggingisonRIP:ignoredv2packetfrom131.108.1.1(illegalversion)

Example3-26showstheoutputoftheshowipprotocolscommand,whichindicatesthattheEthernet0interfaceissendingandreceivingRIP-1packets.ThismeansthatifaVersion2packetisreceivedonEthernet0ofR2,itwillbeignoredbecausetheinterfacecansendandreceiveonlyVersion1packets.Example3-26showipprotocolsCommandOutputRevealstheRIPSendsOutandReceivesOnlyRIPVersion1PacketsonEthernet0

R2#showipprotocols

RoutingProtocolis"rip"Sendingupdatesevery30seconds,nextduein9secondsInvalidafter180seconds,holddown180,flushedafter240OutgoingupdatefilterlistforallinterfacesisIncomingupdatefilterlistforallinterfacesisRedistributing:ripDefaultversioncontrol:sendversion1,receiveversion1InterfaceSendRecvKey-chainEthernet011Loopback011RoutingforNetworks:131.108.0.0RoutingInformationSources:GatewayDistanceLastUpdate131.108.1.112000:01:34Distance:(defaultis120)R2#

Example3-27showstheconfigurationofR1.ThisshowsthatsenderR1isconfiguredtosendVersion2packets.Thecommandversion2enablesaroutertosendandacceptonlyRIP-2packets.Example3-27R1’sConfigurationRevealsThatItIsConfiguredforRIPVersion2Packets

R1#routerripversion2network131.108.0.0

Example3-28showstheoutputoftheshowipprotocolscommand,whichshowsthatthesenderR1issendingandreceivingonlyVersion2packets.Thisisbecauseoftheversion2commandthatisconfiguredunderrouterrip.Example3-28showipprotocolsCommandOutputRevealsThatR1IsSendingandReceivingOnlyRIPVersion2Packets

R1#showipprotocolsRoutingProtocolis"rip"Sendingupdatesevery30seconds,nextduein13secondsInvalidafter180seconds,holddown180,flushedafter240

OutgoingupdatefilterlistforallinterfacesisIncomingupdatefilterlistforallinterfacesisRedistributing:ripDefaultversioncontrol:sendversion2,receiveversion2InterfaceSendRecvKey-chainEthernet0/122Loopback122RoutingforNetworks:131.108.0.0RoutingInformationSources:GatewayDistanceLastUpdate131.108.1.212000:04:09Distance:(defaultis120)

Solution

IfthereceiverR2isconfiguredtoreceiveonlyRIPVersion1packets,itwillignoretheRIPVersion2updates.YoumustconfigureRouterR1onthesender’ssidesothatitwillsendbothVersion1andVersion2packets.WhenR2receivestheVersion1packet,itwillinstalltheroutesintheroutingtable.R2willignoreRIP-2packetsbecauseitisconfiguredforRIP-1.Example3-29showsthenewconfigurationforR1.Inthisconfiguration,thesender(R1’sEthernetinterface)isconfiguredtosendandreceivebothRIP-1andRIP-2packets.Example3-29NewConfigurationofR1toSendandReceiveVersion1andVersion2Packets

R1#interfaceLoopback0ipaddress131.108.2.1255.255.255.0!interfaceEthernet0ipaddress131.108.1.1255.255.255.0ipripsendversion12ipripreceiveversion12!routerripversion2network131.108.0.0

Example3-30showstheoutputofshowipprotocols,whichindicatesthattheEthernet0interfaceissendingandreceivingVersion1andVersion2packets.TheadvantageofsendingbothVersion1andVersion2updatesisthat,ifanydevicesonthisEthernetsegmentarerunningVersion1onlyorVersion2only,thosedeviceswillbecapableofcommunicatingwithR1onEthernet.Example3-30showipprotocolsCommandOutputRevealstheRIPVersion1and2PacketsBeingSentandReceivedbyR1’sEthernet0Interface

R1#showipprotocolsRoutingProtocolis"rip"Sendingupdatesevery30seconds,nextduein4secondsInvalidafter180seconds,holddown180,flushedafter240OutgoingupdatefilterlistforallinterfacesisIncomingupdatefilterlistforallinterfacesisRedistributing:ripDefaultversioncontrol:sendversion2,receiveversion2InterfaceSendRecvKey-chainEthernet01212Loopback022RoutingforNetworks:131.108.0.0

RoutingInformationSources:GatewayDistanceLastUpdate131.108.1.212000:00:07Distance:(defaultis120)R1#

Example3-31showsR2’sroutingtableaftertheconfigurationchange.Example3-31R2RoutingTableAfterR1IsConfiguredtoSendandReceiveRIP-1andRIP-2Packets


RIPRoutesNotintheRoutingTable—Cause:MismatchAuthenticationKey(RIP-2)

OneoftheoptionsinRIP-2isthattheRIP-2updatescanbeauthenticatedforincreasedsecurity.Whenauthenticationisused,apasswordmustbeconfiguredonbothsides.Thispasswordiscalledtheauthenticationkey.Ifthiskeydoesnotmatchwiththekeyontheotherside,theRIP-2updateswillbeignoredonbothsides.Figure3-8showstheflowcharttofollowtosolvethisproblembasedonthiscause.


Example3-32showstheconfigurationsofroutersR1andR2whenthisproblemhappens.Inthisconfiguration,adifferentRIPauthenticationkeyisconfiguredonR1andR2.TheR2Ethernetinterfaceis

configuredwiththekeycisco1,whereasR1isconfiguredwiththekeyCisco.Thesetwokeysdonotmatch,sotheyignoreeachother’supdateandrouteswillnotbeinstalledintheroutingtable.Example3-32ConfigurationsforR1andR2ShowThatDifferentAuthenticationKeysAreConfiguredonEachSide

R2#interfaceLoopback0ipaddress131.108.3.2255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0ipripauthenticationkey-chaincisco1!routerripversion2network131.108.0.0!R1#interfaceLoopback0ipaddress131.108.2.1255.255.255.0!interfaceEthernet0ipaddress131.108.1.1255.255.255.0ipripauthenticationkey-chaincisco!routerripversion2network131.108.0.0!

Example3-33showstheoutputfromthedebugipripcommandonR2thatindicatesthatR2isreceivingaRIPpacketthathasinvalidauthentication.Thismeansthattheauthenticationkeybetweensenderandreceiverdoesn’tmatch.Example3-33debugipripCommandOutputRevealsInvalidAuthenticationforaRIP-2PacketReceivedonR2

R2#debugipripRIPprotocoldebuggingisonRIP:ignoredv2packetfrom131.108.1.1(invalidauthentication)

Solution

WhenusingauthenticationinRIP,makesurethatthesenderandthereceiverareconfiguredwiththesameauthenticationkey.Sometimes,addingaspaceattheendofthekeycancausetheinvalidauthenticationproblembecauseaspacewillbetakenasaliteralkeyentry.Asaresult,thiscausesaproblemthatcannotbecorrectedjustbylookingattheconfigurations.Debugswillshowthatthereisaproblemwiththeauthenticationkey.Tosolvethisproblem,configurethesamekeysonbothsenderandreceiver,orretypetheauthenticationkey,makingsurethatnospaceisbeingaddedattheend.Example3-34showsthenewconfigurationtocorrectthisproblem.TheauthenticationkeyisreconfiguredonRouterR2tomatchRouterthekeyonR1.Example3-34R2ConfigurationwiththeCorrectedAuthenticationKey

R2#interfaceLoopback0ipaddress131.108.3.2255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0ipripauthenticationkey-chaincisco

!routerripversion2network131.108.0.0!

Example3-35showstheroutingtableofR2aftertheconfigurationchange.Example3-35R2RoutingTableAfterReconfiguringtheAuthenticationKeyonR2


RIPRoutesNotintheRoutingTable—Cause:DiscontiguousNetwork

Whenamajornetworkisseparatedbyanothermajornetworkinthemiddle,thisiscalledadiscontiguousnetwork.Chapter2,“UnderstandingRoutingInformationProtocol(RIP),”providesadetailedexplanationofwhyRIPdoesnotsupportdiscontiguousnetworks.EnablingRIPwiththistopologycausesproblems.Figure3-9showsanexampleofadiscontiguousnetworkthatexistswhenamajornetworkisseparatedbyanothermajornetwork.

Figure3-9AnExampleofaDiscontiguousNetwork



Example3-36showstheconfigurationofRouterR1andRouterR2.RIPisenabledontheEthernetinterfacesofR1andR2withthecorrectnetworkstatement.Example3-36ConfigurationofR1andR2inaDiscontiguousNetworkEnvironment

R2#interfaceLoopback0ipaddress137.99.3.2255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0!routerripnetwork131.108.0.0network137.99.0.0!

R1#interfaceLoopback0ipaddress137.99.2.1255.255.255.0!interfaceEthernet0ipaddress131.108.1.1255.255.255.0!routerripnetwork131.108.0.0network137.99.0.0!

Example3-37showsthedebugipripoutputforroutersR1andR2.Bothdebugsshowsthatthenetwork137.99.0.0isbeingsentacross.Example3-37debugipripOutputShowingThatBothRoutersAreSendingSummarizedMajorNetworkAddressesAcross

R2#debugipripRIPprotocoldebuggingisonRIP:receivedv1updatefrom131.108.1.1onEthernet0137.99.0.0in1hopsRIP:sendingv1updateto255.255.255.255viaEthernet0(131.108.1.2)RIP:buildupdateentriesnetwork137.99.0.0metric1R2#

R1#debugipripRIPprotocoldebuggingisonR1#RIP:receivedv1updatefrom131.108.1.2onEthernet0137.99.0.0in1hopsRIP:sendingv1updateto255.255.255.255viaEthernet0(131.108.1.1)RIP:buildupdateentriesnetwork137.99.0.0metric1

Asaresult,bothrouterswillignorethe137.99.0.0updatefromeachother.BecauseR1andR2arealreadyconnectedtothismajornetwork,theywillignoretheupdate.Solution

RIPisnotinstallingtheroute137.99.0.0intheroutingtablebecauseRIPdoesn’tsupportdiscontiguousnetworks,asdiscussedinthebeginningofthechapter.Severalsolutionstothisproblemexist.Thequicksolutionistoconfigureastaticroutetothemorespecificsubnetsof137.99.0.0oneachrouter.ThesecondsolutionistoenableVersion2ofRIP.AnothersolutionistoreplaceRIPwithanotherIProutingprotocol,suchasOSPF,IS-IS,EIGRP,andsoon,thatsupportsdiscontiguousnetworks.Example3-38showstheconfigurationchangethatisrequiredforbothRouterR1andRouterR2tofixtheproblem.Thisconfigurationaddsthestaticrouteforthediscontiguoussubnets.BecauseyoucannotpassthesubnetinformationacrossincaseofdiscontiguousnetworksinRIP-1,theonlysolutionistopatchitwithstaticroutes.Example3-38StaticRouteConfigurationShouldSolveThisProblem

R1#interfaceLoopback0ipaddress137.99.2.1255.255.255.0!interfaceEthernet0ipaddress131.108.1.1255.255.255.0!routerripnetwork131.108.0.0network137.99.0.0!iproute137.99.3.0255.255.255.0131.108.1.2


interfaceEthernet0ipaddress131.108.1.2255.255.255.0!routerripnetwork131.108.0.0network137.99.0.0!iproute137.99.2.0255.255.255.0131.108.1.1

Example3-39showsthealternatesolutiontofixthisproblem,inthecaseofRIP-2.ThesolutionistorunRIP-2withnoautosummaryconfigured.Withtheno-autosummarycommandadded,RIP-2willnotautosummarizewhencrossingamajornetworkboundary.Thespecificsubnetinformationwillbesentacross.Example3-39ConfigurationThatWorksUnderRIP-2inaDiscontiguousNetworkEnvironment

routerripversion2network131.108.0.0network137.99.0.0noautosummary

Example3-40showstheroutingtableofR2afterfixingthisproblem.Example3-40R2RoutingTableShowsThat137.99.2.0/24IsLearnedThroughRIP-2AfterConfiguringtheno-autosummaryCommand

R2#showiproute137.99.2.0Routingentryfor13799.2.0/24Knownvia"rip",distance120,metric1RedistributingviaripLastupdatefrom131.108.1.1onEthernet0,00:00:07agoRoutingDescriptorBlocks:*131.108.1.1,from131.108.1.1,00:00:07ago,viaEthernet0Routemetricis1,trafficsharecountis1

RIPRoutesNotintheRoutingTable—Cause:InvalidSource

WhenRIPtellstheroutingtabletoinstalltheroute,itperformsasource-validitycheck.Ifthesourceisnotonthesamesubnetasthelocalinterface,RIPignorestheupdateanddoesnotinstallroutesintheroutingtablecomingfromthissourceaddress.Figure3-11showsthenetworkdiagramforinvalidsourceproblem.

Figure3-11NetworkDiagramforInvalidRouteSource

InFigure3-11,Router1’sSerial0interfaceisunnumberedtoLoopback0.Router2’sserialinterfaceisnumbered.WhenRouter2receivesaRIPupdatefromRouter1,itcomplainsaboutthesourcevaliditybecausethesourceaddressisnotonthesamesubnetasRouter2’sSerial0interface.Figure3-12showstheflowcharttofollowtosolvethisproblembasedonthiscause.


Example3-41showstheconfigurationofbothRouterR2andRouterR1.Inthisconfiguration,R1’sSerial0interfaceisunnumberedtoLoopback0.R2’sSerial0interfaceisnumbered.Example3-41ConfigurationofR2andR1ShowingThatR1’sSerial0InterfaceIsUnnumberedandR2’sIsn’t

R2#interfaceLoopback0ipaddress131.108.3.2255.255.255.0!interfaceSerial0ipaddress131.108.1.2255.255.255.0!routerripnetwork131.108.0.0!

R1#interfaceLoopback0ipaddress131.108.2.1255.255.255.0!interfaceSerial0ipunnumberedLoopback0!routerripnetwork131.108.0.0!

ThedebugipripoutputinExample3-42showsthatR2isignoringtheRIPupdatefromR1becauseofasourcevaliditycheck.TheRIPupdatecomingfromR1isnotonthesamesubnet,soR2willnotinstall

anyroutesintheroutingtable.Example3-42debugipripMessageShowsThatR2IsReceivingRIPUpdatesfromaDifferentSourceAddressThanItsOwnInterface

R2#debugipripRIPprotocoldebuggingisonRIP:ignoredv1updatefrombadsource131.108.2.1onSerial0R2#

Solution

Whenonesideisnumberedandtheothersideisunnumbered,thischeckmustbeturnedoff.Thisisusuallythecaseinadialupsituationwhenremotesaredialingintoanaccessrouter.Theaccessrouter’sdialupinterfaceisunnumbered,andallremoteroutersgetanIPaddressassignedontheirdialupinterfaces.Example3-43showsthenewconfigurationchangeonRouterR2tofixthisproblem.Example3-43ConfigurationofR2toTurnOfftheSourceValidityCheck

R2#interfaceLoopback0ipaddress131.108.3.2255.255.255.0!interfaceSerial0ipaddress131.108.1.2255.255.255.0!routerripnovalidate-update-sourcenetwork131.108.0.0!

Example3-44showsthatafterchangingtheconfigurationsofR2,theroutegetsinstalledintheroutingtable.Example3-44R2RoutingTableAfterTurningOffSourceValidityCheck

R2#showiproute131.108.2.0Routingentryfor131.108.2.0/24Knownvia"rip",distance120,metric1RedistributingviaripLastupdatefrom131.108.1.100:00:01agoRoutingDescriptorBlocks:*131.108.1.1,from131.108.1.1,00:00:07agoRoutemetricis1,trafficsharecountis1

RIPRoutesNotintheRoutingTable—Cause:Layer2Problem(Switch,FrameRelay,OtherLayer2Media)

Sometimes,multicast/broadcastcapabilityisbrokenatLayer2,whichfurtheraffectsLayer3multicast.Asaresult,RIPfailstoworkproperly.TheLayer3broadcast/multicastisfurtherconvertedintoLayer2broadcast/multicast.IfLayer2hasproblemsinhandlingLayer2multicast/broadcast,theRIPupdateswillnotbepropagated.Thedebugsshowthatbroadcastormulticastisbeingoriginatedatoneendbutisnotgettingacross.Figure3-13showsthenetworkdiagramforFrameRelayproblemswhilerunningRIP.

Figure3-13TwoRoutersRunningRIPinaFrameRelayEnvironment

InFigure3-13,Router1andRouter2areconnectedthroughanyLayer2media—forexample,FrameRelay,X.25,Ethernet,FDDI,andsoon.Figure3-14showstheflowcharttofollowtosolvethisproblembasedonthiscause.


Example3-45showstheoutputofthedebugipripcommand,whichshowsthatR1issendingandreceivingRIPupdateswithoutanyproblem.OnR2,RIPupdatesarebeingsentbutnotreceived.ThismeansthattheRIPupdateisbeinglostatLayer2.Example3-45debugippacketAgainstaccess-list100ShowsThatR1IsSendingRIPUpdatesontheWire,andR2IsNotReceivingIt

R1#debugippacket100detailIPpacketdebuggingison(detailed)foraccesslist100R1#IP:s=131.108.1.1(Ethernet0),d=255.255.255.255,len132,sendingbroadcast/multicastUDPsrc=520,dst=520IP:s=131.108.1.1(Ethernet0),d=255.255.255.255,len132,rcvd2UDPsrc=520,dst=520R2#debugippacket100detailIPpacketdebuggingison(detailed)foraccesslist100R2#

IP:s=131.108.1.2(Ethernet0),d=255.255.255.255,len132,sendingbroadcast/multicastUDPsrc=520,dst=520IP:s=131.108.1.2(Ethernet0),d=255.255.255.255,len132,sendingbroadcast/multicastUDPsrc=520,dst=520

Example3-46showsaccess-list100,whichisusedagainstthedebugtolookattheRIPbroadcast/multicastspecifically.Example3-46access-list100IsUsedAgainsttheDebugstoMinimizetheTraffic

access-list100permitipanyhost255.255.255.255access-list100permitipanyhost224.0.0.9

Example3-47showsawaytofindoutifthisistheproblemwhenrunningRIP-2.Pingthemulticastaddressof224.0.0.9—iftheneighbordoesn’treply,thiscanmeanthatmulticastisbrokenatLayer2.Example3-47MulticastPingsAreFailing,WhichMeansThatR2’sMulticastIsGettingLostatLayer2

R2#ping224.0.0.9

Typeescapesequencetoabort.Sending1,100-byteICMPEchosto224.0.0.9,timeoutis2seconds:.....R2#

Solution

RIP-1sendsanupdateonabroadcastaddressof255.255.255.255.InthecaseofRIP-2,theupdateissentonamulticastaddressof224.0.0.9.IfthesetwoaddressesgetblockedatLayer2orarenotbeingpropagatedatLayer2,RIPwillnotfunctionproperly.Layer2couldbeasimpleEthernetswitch,aFrameRelaycloud,abridgingcloud,andsoon.FixingtheLayer2problemisbeyondthescopeofthisbook.Example3-48showsthatafterfixingtheLayer2problem,RIProutesgetinstalledintheroutingtable.Example3-48R2IsInstallingRIPRoutesAfterFixingtheLayer2Problems

R2#showiproute131.108.2.0Routingentryfor131.108.2.0/24Knownvia"rip",distance120,metric1RedistributingviaripLastupdatefrom131.108.1.100:00:01agoRoutingDescriptorBlocks:*131.108.1.1,from131.108.1.1,00:00:07agoRoutemetricis1,trafficsharecountis1

RIPRoutesNotintheRoutingTable—Cause:OffsetListHasaLargeMetricDefined

OffsetlistsareusedtoincreasethemetricvalueofRIPupdatescominginorgoingout.Theuseofanoffsetlistcandirectlyinfluencetheroutingtable.Thislistcanbeappliedonselectednetworksthatcanbedefinedinanaccesslist.Iftheoffsetvalueisalargenumber,suchas14or15,theRIPmetricwillreachinfinitywhenitcrossesacoupleofrouters.That’swhytheoffsetlistvalueshouldbekepttoaminimumvalue.Figure3-15showsanetworksetupthatcanproduceaprobleminthecaseofamisconfiguredoffsetlist.

Figure3-15NetworkTopologyUsedforMisconfiguredOffsetListsProblemReproduction

Example3-49showsthatthespecificrouter131.108.6.0isnotintheroutingtableofR2.Example3-49R2’sRoutingTableMissingtheSubnetThatIsOffR3

R2#showiproute131.108.6.0%Subnetnotintable



TroubleshootingshouldbedonetoinvestigateRIP’snormalbehavior.Example3-50showsthatR2isreceivingotherRIProutes,butnot131.108.6.0/24.Example3-50R2IsMissing131.108.6.0/24fromItsRoutingTable

R2#showiprouteRIP

131.108.0.0/24issubnetted,4subnetsR131.108.5.0[120/1]via131.108.1.1,00:00:06,Ethernet1R131.108.3.0[120/1]via131.108.1.1,00:00:06,Ethernet1

Thisshowsthatproblemiswith131.108.6.0/24,notwithRIPingeneral.ThereasonisthatR3isreceivingotherRIProutesfromR1,sotheRIPupdatethatiscomingfromR1isworkingfine.

Example3-51showstheroutingtableofR1,where131.108.6.0/24ispresentintheroutingtable.Example3-51R1Sees131.108.6.0/24inItsRoutingTable

R1#showiproute131.108.6.0Routingentryfor131.108.6.0/24Knownvia"rip",distance120,metric1

SowhyisR2notinstalling131.108.6.0/24?Thiscouldbebecauseofoneofthefollowingreasons:•R1isnotadvertisingtoR2.•R1isadvertising,butR2isnotreceiving.•R2isreceivingbutisdiscardingitbecauseofaninfinitemetric.

Thesimplestwaytotroubleshootsuchproblemsisquickconfigurationexamination.Example3-52showstheconfigurationofRouterR1.Example3-52TheOffsetListHasaLargeValueConfiguredonR1for131.108.6.0/24

R1#routerripversion2offset-list1out15Ethernet0/1network131.108.0.0!access-list1permit131.108.6.0

Theadministratorhasconfiguredanoffsetlistwithaverylargemetric.TheoffsetlistisusedtochangethemetricofRIPupdate.Fromtheconfiguration,youcansurmisethatanyupdatethatpassesaccess-list1willhave15addedinthemetric.InExample3-52,access-list1permits131.108.6.0.Thismeansthatthemetricof131.108.6.0is16,which,toRIP,isaninfinitemetric;uponreceivingit,R2willrejectit.Toverifythis,runthedebugipripcommand,asdemonstratedinExample3-53.Example3-53debugipriponR2ShowsThat131.108.6.0IsReceivedwithanInfiniteMetric

R2#debugipRIP

RIP:receivedv2updatefrom131.108.1.1onEthernet1131.108.6.0/24->0.0.0.0in16hops(inaccessible)

Because16istheinfinitemetricforRIP,R2willreject131.108.6.0/24fromgoingintheroutingtable.Solution

Typically,offsetlistsarenotusedinRIPnetworks.Whenthenetworkhasredundantequal-hop(cost)pathsandtheadministratorwantsoneroutepreferredoveranother,anoffsetlistcanbeused.Forexample,supposethattwolinksexistbetweenR1andR2.Oneofthelinkscouldbeeithercongestedorexperiencingdelay.TheadministratormightwanttoshifttheIPtrafficforcertaindestinationsubnetstoanoncongestedlinkforashorttime,togetbetterthroughputandtoalleviatesomeofthecongestion.AnoffsetlistisaneasywaytoachievethisbymakingtheRIPmetrichigherforthesubnetsonthecongestedinterface.Example3-54showsthenewconfigurationofRouterR1.

Tofixtheproblem,configureanoffsetvaluesothatthehopcountwon’treachitslimit.Example3-54NewConfigurationonR1withAppropriateOffsetListValue

R1#routerripversion2offset-list1out1Ethernet0/1network131.108.0.0!access-list1permit131.108.6.0

Example3-55showstheroutingtableofRouterR2afterfixingtheproblem.Example3-55R2’sRoutingTableShowstheEntryfor131.108.6.0/24AfterConfiguringtheProperOffsetList


RIPRoutesNotintheRoutingTable—Cause:RoutesReachedRIPHopCountLimit

TheRIPmetriccangouptoamaximumof15hops.Ifanetworkhasmorethan15hops,RIPisnotasuitableprotocolforit.Figure3-17showsanetworksetupthatproducesaRIPhop-countlimitproblem.

Figure3-17NetworkSetupThatCanProduceaRIPHop-CountLimitProblem

R2isreceivinganupdateforaRIProute,whichisseveral(morethan15)hopsaway.R2doesn’tinstallthatrouteintheroutingtable,asdemonstratedintheoutputinExample3-56.Example3-56R2’sRoutingTableIsMissingtheRoutefor131.108.6.0


Figure3-18showstheflowcharttosolvethisproblem.


ThemostlogicalwaytostarttroubleshootingthisproblemistolookatR1anddeterminewhetherR1isreceiving131.108.6.0/24.Example3-57showsthatRouterR1isreceivingRIProutesfor131.108.6.0/24.Example3-57R1’sRoutingTableHas131.108.6.0/24withaMetricof15(MaximumRIPMetric)


R1isreceivingtherouteinquestion,butwithametricof15.R1willadd1moreto15whenadvertisedtoR2,whichwillresultinaninfinitemetric,consequentlypreventingtheroutefrombeingplacedintheroutingtable.Toprovethis,inR1,youcanrunthedebugipripcommandtoviewtheprocessinrealtime.Example3-58showstheoutputofdebugipriponRouterR1.Example3-58debugipripOutputShowsThatR1IsAdvertising131.108.6.0withaMetricof16(Infinity)

R1#debugipripRIPprotocoldebuggingisonRIP:sendingv2updateto224.0.0.9viaEthernet1(131.108.1.1)131.108.6.0/24->0.0.0.0,metric16,tag0

Example3-59showstheoutputofdebugipriponRouterR2.RouterR2receivesthisupdateanddiscardsitbecausethemetricshowsthatthisnetworkisinfinitelyfarawayand,therefore,unreachable.

Example3-59debugipripOutputonR2ShowsThatR2IsReceivingRouteswithanInfiniteMetric

R2#debugipripRIPprotocoldebuggingisonRIP:receivedv2updatefrom131.108.1.1onEthernet1131.108.6.0/24->0.0.0.0in16hops(inaccessible)

Solution

ThisisaclassicalRIPprobleminwhicharoutepassesthroughmorethan15devices.IPnetworksthesedaysusuallyhavemorethan15routers.Thereisnowaytoovercomethisbehaviorotherthantopickaroutingprotocolthatdoesnothavea15-hoplimitation.YoushoulduseOSPF,EIGRP,orIS-ISinstead.

Problem:RIPIsNotInstallingAllPossibleEqual-CostPaths—Cause:maximum-pathCommandRestrictsRIPfromInstallingMoreThanOnePathBydefault,Ciscorouterssupportonlyfourequalpathsforthepurposeofloadbalancing.Themaximum-pathcommandcanbeusedforuptosixequal-costpaths.Ifthecommandisnotconfiguredproperly,itcancauseaproblem,asdiscussedinthissection.Whenconfiguredimproperly,themaximum-pathcommandallowsonlyonepathtothedestination,eventhoughmorethanonepathexists.Configuringthecommandasmaximum-path1shouldbedoneonlywhenloadbalancingisnotdesired.Figure3-19andExample3-60provideanetworkscenariothatwillbeusedasthebasisfortroubleshootingwhenthemaximum-pathcommandrestrictsRIPfrominstallingmorethanonepath,resultingintheomissionofallpossibleequal-costpaths.Thesectionsthatfollowcarefullydissecthowtotroubleshootthisproblem.

Figure3-19RIPNetworkVulnerabletoanEqual-CostPathProblem

Figure3-19showsthenetworksetupthatproducestheproblemofRIPnotinstallingallpossibleequal-costpaths.Example3-60showstheroutingtableofRouterR1.Onlyonerouteisbeinginstalledintheroutingtable.Bydefault,anyroutingprotocolsupportsequal-costmultipaths(loadbalancing).Ifmorethanoneequalpathexists,itmustbeinstalledintheroutingtable.Example3-60R1InstallsOnlyOnePathfor131.108.2.0/24

R1#showiprouterip131.108.0.0/24issubnetted,1subnetsR131.108.2.0[120/1]via131.108.5.3,00:00:09,Ethernet2



Example3-61showstheoutputofdebugipriponRouterR1.TheoutputshowsthatRouterR1isreceivingtwoequal-costroutes.Example3-61debugipripOutputonR1ShowsR1ReceivingTwoUpdatesforthe131.108.2.0Network

R1#debugipripRIPprotocoldebuggingisonR1#RIP:receivedv2updatefrom131.108.5.3onEthernet2131.108.2.0/24->0.0.0.0in1hopsRIP:receivedv2updatefrom131.108.1.2onEthernet1131.108.2.0/24->0.0.0.0in1hops

Onlyonerouteisinstalledintheroutingtable.Youseeonlyonerouteintheroutingtableinsteadoftwobecauseoperatorhasconfiguredmaximum-paths1intheconfiguration.Example3-62showsthecurrentconfigurationforRouterR1.Example3-62R1IsConfiguredwithmaximum-path1

R1#routerripversion2network131.108.0.0maximum-paths1

Solution

Bydefault,CiscoIOSSoftwareallowsuptofourequal-costroutestobeinstalledintheroutingtable.

ThiscouldbeincreaseduptosixroutesifconfiguredasinExample3-63.Example3-63showstheconfigurationthatinstallssixequal-costpathroutesintheroutingtable.Example3-63AllowingtheMaximumofSixPathsintheRoutingTable

R1#routerripmaximum-paths6

Thisexamplemakesmoresensewhenyouhavemorethanfourpathsandonlyfouraregettinginstalledintheroutingtable.Becausefourequal-costroutesisadefault,maximum-pathsneedstobeincreasedtoaccommodatethefifthandpossiblysixthroute.

TroubleshootingRIPRoutesAdvertisementAlltheproblemsdiscussedsofardealwiththeproblemonthereceivingendortheprobleminthemiddle(Layer2).Athirdpossiblecauseexistswhenroutesarenotbeinginstalledintheroutingtable.ThesendercouldbehavingaproblemsendingRIPupdatesforsomereason.Asaresult,thereceivercannotinstalltheRIProutesintheroutingtable.Thissectiontalksaboutthethingsthatcangowrongonthesender’sside.ThissectiondiscussessomeofthepossiblescenariosthatcanpreventRIProutesfrombeingadvertised.Somecasesoverlapwithrouterinstallationproblems—forexample,missingnetworkstatement(s)oraninterfacethatisdown.Thissectionassumesthat,aftertroubleshootingtheproblemspreviouslyaddressedinthe“TroubleshootingRIPRoutesInstallation”section,theproblemspersist.Thissectionpresentsrecommendationsonwheretogonexttoresolvethoseissues.Twoofthemostprevalentproblemsthatcangowrongonthesender’senddealwithRIProuteadvertisement:•ThesenderisnotadvertisingRIProutes.•Subnettedroutesaremissing.

Problem:SenderIsNotAdvertisingRIPRoutesTypically,anIPnetworkrunningRIPhasroutersthathaveaconsistentviewoftheroutingtable.Inotherwords,allroutershaveroutingtablesthatcontainreachabilityinformationforalltheIPsubnetsofthenetwork.Thismightdifferincaseswhenfilteringofcertainsubnetsisdoneatsomeroutersandnotatothers.Ideally,allRIProutershaveroutesofthecompletenetwork.Whentheroutinginformationdiffersfromoneroutertotheother,oneoftwopossibilitiescouldexist:•SomeroutersarenotadvertisingtheRIProutes.•SomeroutersarenotreceivingtheRIProutes.

ThissectiondealswithproblemsinsendingRIProutes.Figure3-21providesanetworkscenariothatwillbeusedasthebasisfortroubleshootingamajorityoffollowingcausesoftheproblemofthesendernotadvertisingRIProutes:•Missingorincorrectnetworkstatement•Outgoinginterfacethatisdown•distribute-listoutblockingtheroutes•Advertisednetworkinterfacethatisdown

•Outgoinginterfacedefinedaspassive•Brokenmulticastcapability(encapsulationfailureinFrameRelay)•Misconfiguredneighborstatement•AdvertisedsubnetisVLSM•Splithorizonenabled

Figure3-21NetworkSetupinWhichRouterR1IsNotSendingRIPRoutesTowardR2

Figure3-21showsthenetworksetupinwhichRouterR1isnotsendingRIProutestowardR2.Thesectionsthatfollowcarefullydissecthowtotroubleshootthisproblembasedonspecificcauses.SenderIsNotAdvertisingRIPRoutes—Cause:MissingorIncorrectnetworkStatement

OneoftherequirementsforenablingRIPonarouter’sinterfaceistoaddthenetworkstatementundertherouterripcommand.ThenetworkstatementdecideswhichinterfaceRIPshouldbeenabledon.Ifthenetworkstatementismisconfiguredornotconfigured,RIPwillnotbeenabledonthatinterfaceandRIProuteswillnotbeadvertisedoutthatinterface.Figure3-22showstheflowcharttofollowtofixthisproblem.

Figure3-22FlowcharttoSolveWhytheSenderIsNotAdvertisingRIPRoutesDebugsandVerifications

Example3-64showsthecurrentconfigurationforR1.Example3-64R1ConfigurationShowstheMisconfigurednetworkStatement

R1#

interfaceLoopback0ipaddress131.108.2.1255.255.255.0!interfaceEthernet0ipaddress131.108.1.1255.255.255.0!routerripnetwork131.107.0.0

ThenetworkstatementisincorrectlyconfiguredunderrouterripinExample3-64.Insteadof131.108.0.0,131.107.0.0isconfigured.ThiswillnotenableRIPontheinterface,andnoupdateswillbesent.Solution

Sometimes,aclasslessstatementisconfiguredunderrouterrip,assumingthatitwillcoverallthenetworks—forexample:

routerripnetwork131.0.0.0

Thenetworkstatementwillnotcover131.0.0.0through131.255.255.255because131.0.0.0isaclasslessnetworkandRIPisaclassfulprotocol.Similarly,ifyouhavemultipleClassCaddresses,youcannotuseonenetworkstatementtocoveralltheaddressesthatyouown.Forexample,supposethatyouown200.1.1.0through200.1.4.0.Thisdoesn’tmeanthatyoucanusethefollowingcommandsyntax:


ThenetworkstatementhereismeaninglessforRIP-1becauseRIP-1isaclassfulprotocol.ThecorrectwaytoadvertiseallfournetworksinRIPisasfollows:

routerripnetwork200.1.1.0network200.1.2.0network200.1.3.0network200.1.4.0

Example3-65showsthecorrectedconfigurationforR1.Example3-65CorrectingthenetworkStatementintheR1Configuration

R1#interfaceLoopback0ipaddress131.108.2.1255.255.255.0!interfaceEthernet0ipaddress131.108.1.1255.255.255.0!routerripnetwork131.108.0.0

Example3-66showstheroutingtableofRouterR2,showingthelearnedRIProute.Example3-66R2RoutingTableShowsThattheRIPRoutesAreLearnedAfterCorrectingthenetworkStatement

R2#showiproute131.108.2.0Routingentryfor131.108.2.0/24Knownvia"rip",distance120,metric1RedistributingviaripLastupdatefrom131.108.1.1onEthernet0,00:00:11ago

RoutingDescriptorBlocks:*131.108.1.1,from131.108.1.1,00:00:11ago,viaEthernet0Routemetricis1,trafficsharecountis1

SenderIsNotAdvertisingRIPRoutes—Cause:OutgoingInterfaceIsDown

RIPistheroutingprotocolthatrunsonLayer3.RIPcannotsendupdatesacrossaninterfaceiftheoutgoinginterfaceisdown.Therecanbeavarietyofpossiblecausesfortheoutgoinginterfacebeingdown:•Interfaceisup,lineprotocolisdown•Interfaceisdown,lineprotocolisdown•Interfaceisadministrativelydown,lineprotocolisdown

Iftheoutgoinginterfaceshowsanyofthesesymptoms,RIPwillnotbecapableofsendinganyupdatesacrossthenetwork.Themainthingtonotehereisthat,withanyofthesepotentialcauses,thelineprotocolwillalwaysshowdown.ThisisthemostimportantinformationtodetermineLayer2connectivity.Figure3-23showstheflowcharttofollowtosolvethisproblembasedonthiscause.

Figure3-23FlowcharttoSolveWhytheSenderIsNotAdvertisingRIPRoutesDebugsandVerification

Example3-67showsthattheinterfaceEthernet0isdown.Example3-67OutgoingInterfaceEthernet0ofR1ShowsThattheLineProtocolIsDown


Example3-68showsthedebugipripoutput.Inthisdebug,R1isnotsendingorreceivinganyRIP

updatesbecauseLayer2isdown.Example3-68debugipripOutputRevealsThatNothingIsBeingSentorReceivedonR1’sEthernet0Interface

R1#debugipripRIPprotocoldebuggingisonR1#

Inthedebug,therearenooutputsbecauseofthisproblem.Solution

RIPrunsaboveLayer2.RIPcannotsendorreceiveanyroutesifLayer2isdown.Tocorrectthisproblem,Layer2orLayer1mustbecorrected.Sometimes,theproblemcouldbeassimpleasloosecablesorabadcablethatmustbereplaced,oritcouldbeascomplexasbadhardware,inwhichcasehardwaremustbereplaced.Example3-69showstheinterfaceEthernet0afterfixingtheLayer2problem.Example3-69R1’sOutgoingInterfaceEthernet0IsUpAfterFixingtheLayer2Issue

R1#Ethernet0isup,lineprotocolisupHardwareisLance,addressis0000.0c70.d31e(bia0000.0c70.d31e)Internetaddressis131.108.1.1/24

Example3-70showstheroutingtableofR2.Example3-701’sEthernet0InterfaceIsUp,SoRIPIsSendingUpdatesandR2HasRIPRoutesinItsRoutingTable


SenderIsNotAdvertisingRIPRoutes—Cause:distribute-listoutIsBlockingtheRoute

distribute-listoutisusedtofilteranyroutesthatwillbesentoutaninterface.Ifareceiveriscomplainingaboutmissingroutesthatshouldbereceived,makesurethattheroutesarenotbeingfilteredthroughdistribute-listout.Ifthisisthecase,youmustmodifytheaccesslist.Figure3-24showstheflowcharttofollowtofixthisproblem.


Example3-71showstheconfigurationofRouterR1.Inthisconfiguration,access-list1doesnotexplicitlypermitthe131.108.0.0network,soR1willnotbeallowedtoadvertiseany131.108.X.Xnetwork,including131.108.2.0/24.Example3-71access-list1DoesNotPermitthe131.108.0.0Network

R1#interfaceLoopback0ipaddress131.108.2.1255.255.255.0!interfaceEthernet0ipaddress131.108.1.1255.255.255.0!routerripnetwork131.108.0.0distribute-list1out!access-list1permit131.107.0.00.0.255.255

Solution

Whenusingadistributelist,youshouldalwaysdouble-checkyouraccesslisttomakesurethatthenetworksthataresupposedtobepermittedareexplicitlypermittedintheaccesslist.Ifnot,theywillbedenied.IntheconfigurationexampleinExample3-72,theaccesslistispermittingonly131.107.0.0.Animplicitdenyanyattheendofeachaccesslistcausesthe131.108.0.0networktobedenied.Tofixthisproblem,permit131.108.0.0inaccess-list1,asshowninExample3-72.Example3-72Reconfiguringaccess-list1toPermitNetwork131.108.0.0

interfaceLoopback0ipaddress131.108.2.1255.255.255.0!

interfaceEthernet0ipaddress131.108.1.1255.255.255.0!routerripnetwork131.108.0.0distribute-list1out!access-list1permit131.108.0.00.0.255.255

Example3-73showstheroutingtableofRouterR2.Example3-73R2RoutingTableShowstheEntryforthe131.108.2.0NetworkAfterPermittingItinaccess-list1


SenderIsNotAdvertisingRIPRoutes—Cause:AdvertisedNetworkInterfaceIsDown

Thenetworkthatisbeingadvertisedmightbedown,andtheconnectedroutehasbeenremovedfromtheroutingtable.Inthissituation,RIPwillstartadvertisingthatnetworkwithaninfinitemetricof16;aftertheholddowntimerhasexpired,itwillnolongeradvertisethisnetwork.Assoonastheadvertisednetworkcomesup,RIPwillstartadvertisingitagaininitsupdates.Figure3-25showstheflowcharttofollowtofixthisproblem.


Example3-74showsthatthelineprotocolofR1’sEthernet1interfaceisdown,indicatingthatthereissomethingwrongatLayer2.Thisistheinterfacethatisdirectlyattachedtothenetworkthatneedstobeadvertised.Therefore,thatnetworkcannotbeadvertisedtoneighboringrouters.Example3-74showinterfaceOutputDisplaysThattheLineProtocoloftheAdvertisedNetworkIsDown

R1#showinterfaceEthernet1Ethernet1isup,lineprotocolisdownHardwareisLance,addressis0000.0c70.d51e(bia0000.0c70.d51e)Internetaddressis131.108.2.1/24

Whentheadvertisednetwork’sinterfacegoesdown,RIPwilldetectthedowncondition.RIPwillnolongeradvertisethatnetworkintheRIPupdate.InExample3-74,interfaceEthernet1isdown,soRIPwillnolongeradvertise131.108.2.0/24initsupdate.Solution

YoumustcorrectthisproblematLayer2orLayer1.Sometimes,theproblemcouldbeassimpleasloosecables,oritcouldbeascomplexasbadhardware,inwhichcasethehardwaremustbereplaced.AfterfixingtheLayer2problem,reissuetheshowinterfacecommandtoviewthecurrentstatus,toverifythatithaschangedstatetoup.Example3-75showsthattheadvertisednetworkinterfacelineprotocolisup.Example3-75showinterfaceOutputDisplaysThattheLineProtocolofEthernet1IsUpAfterFixingtheLayer2Issue

R1#showinterfaceEthernet1Ethernet1isup,lineprotocolisupHardwareisLance,addressis0000.0c70.d51e(bia0000.0c70.d51e)Internetaddressis131.108.2.1/24

Whentheinterfaceisactiveagain,RIPwillbegintoadvertisethatnetworkinitsperiodicupdates.Example3-76showsthattheroutethatwasdownisbackintheroutingtableofR2.Example3-76showiprouteOutputDisplaysThatR2’sRoutingTableIndicatestheNetworkAgainAftertheLayer2IssueIsResolved


SenderIsNotAdvertisingRIPRoutes—Cause:OutgoingInterfaceIsDefinedPassive

AsituationmightariseinwhicharouterhasacompleteRIProutingtable,butitisnotadvertisingtootherroutersrunningRIP.ThisoccurswhennotallroutersinaRIPnetworkhavecompleteroutingtables,resultinginlackingIPconnectivityfromonepartofthenetworktotheother.Iftheoutgoinginterfaceisdefinedaspassive,itwillnotadvertiseanyRIPupdatesonthatinterface.Figure3-26showstheflowcharttofollowtofixthisproblem.


Example3-77showstheoutputofshowipprotocols,whichshowsthattheoutgoinginterfaceisdefinedasapassiveinterface.Example3-77showipprotocolsOutputRevealsThattheOutgoingInterfaceonR1IsPassive

R1#showipprotocolsRoutingProtocolis"rip"Sendingupdatesevery30seconds,nextduein26secondsInvalidafter180seconds,holddown180,flushedafter240OutgoingupdatefilterlistforallinterfacesisIncomingupdatefilterlistforallinterfacesisRedistributing:ripDefaultversioncontrol:sendversion1,receiveanyversionInterfaceSendRecvKey-chainLoopback0112RoutingforNetworks:131.108.0.0PassiveInterface(s)Ethernet0RoutingInformationSources:GatewayDistanceLastUpdate131.108.1.212000:00:26Distance:(defaultis120)

Example3-78showstheconfigurationofRouterR1,whichshowsthattheoutgoinginterfaceisdefinedaspassive.Example3-78ConfiguringthepassiveinterfaceCommandinRIP

routerrippassive-interfaceEthernet0network131.108.0.0

Solution

WhenaninterfaceisdefinedasapassiveinterfaceunderRIP,RIPwillreceiveupdatesonthatinterfacebutwillnotsendanyupdates.InExample3-78,theinterfaceEthernet0isdefinedaspassive,soR1isnotsendinganyupdatesonEthernet0.Sometimes,somenetworksshouldbeadvertisedandothersshouldbefiltered.Inthistypeofsituation,passiveinterfacesshouldnotbeused.Distributelists,usedtoselectivelyfilterupdates,areabettersolutioninthatcase.Assumethatpassive-interfacewasconfiguredbymistake.Takethiscommandoutoftheconfigurationtosolvethisproblemusingthenoformofthecommand.Example3-79showsthenewconfigurationtosolvethisproblem.Example3-79Correctingthepassive-interfaceProblem


Example3-80showstheroutingtableofR2afterfixingtheproblem.Example3-80R2RoutingTableAfterRemovingthepassive-interfaceCommand

R2#showiproute131.108.2.0Routingentryfor131.108.2.0/24Knownvia"rip",distance120,metric1RedistributingviaripLastupdatefrom131.108.1.1onSerial0,00:00:07agoRoutingDescriptorBlocks:*131.108.1.1,from131.108.1.1,00:00:07ago,viaSerial0Routemetricis1,trafficsharecountis1

SenderIsNotAdvertisingRIPRoutes—Cause:BrokenMulticastCapability(FrameRelay)

Insomenetworkingscenarios,routerinterfacesdonotautomaticallypropagatemulticastandbroadcasttrafficunlessconfiguredtodoso.ThiscouldbeamajorproblembecauseRIP-1updatesaresentatabroadcastaddressandRIP-2usesmulticasttoexchangeroutes.Noroutinginformationwillpropagateacrossthenetworkunlessbroadcastandmulticastfeaturesareenabledonsuchinterfaces.Nonbroadcastmultiaccess(NBMA)FrameRelayisaprimeexampleofanetworkingenvironmentinwhichinterfacesexhibitthisbehavior.Figure3-27showsanetworksetupthatisdeliberatelyconfiguredwithbrokenmulticasttoillustratetheexampleofhowFrameRelayRIPupdateswillnotgoacrossR1.

Figure3-27NBMAFrameRelayNetworkVulnerabletoBrokenMulticastCapabilityProblems

InFigure3-27,Router1andRouter2areconnectedthroughFrameRelay.Router1isnotadvertisingRIProutestowardRouter2.Figure3-28showstheflowcharttofollowtosolvethisproblembasedonthiscause.


Example3-81showstheconfigurationofRouterR1.Inthisexample,FrameRelayprovidestheLayer2encapsulation.Inthisconfiguration,theframe-relaymapstatementdoesn’thavethekeywordbroadcastattheend.Asaresult,allbroadcast/multicasttrafficwillbeprohibitedfromcrossingtheNBMAnetwork.Thebroadcastkeywordtellstheroutertoreplicatethenecessarybroadcastsandsendthemacrossthespecifiedcircuits.Example3-81R1’sframe-relaymapStatementLacksthebroadcastKeyword

R1#interfaceSerial3ipaddress131.108.1.1255.255.255.0encapsulationframe-relayframe-relaymapip131.108.1.216!

Example3-83showsoutputfromdebugippacket.ThisdebugincludesonlythebroadcasttrafficsourcefromR1.AsshowninExample3-82,R1isconfiguredwithaccess-list100.Example3-82ConfigurationinR1ofaccess-list100toLimitdebugOutput

R1#:access-list100permitiphost131.108.1.1host255.255.255.255

R1isconfiguredwithaccess-list100,whichpermitsallpacketsfromsource131.108.1.1destinedtothebroadcastaddressof255.255.255.255.InExample3-83,R1runsdebugippacketdetailwithaccess-list100tolimittrafficdestinedto255.255.255.255withR1asthesource.ThedebugoutputinExample3-83showsthatthereareencapsulationfailures,indicatingthattheycannotbeplacedintheappropriateLayer2frame.

Example3-83debugippacketOutputonR1RevealsEncapsulationFailureforRIPUpdates

R1#debugippacket100detailIPpacketdebuggingison(detailed)foraccesslist100R1#IP:s=131.108.1.1(local),d=255.255.255.255(Serial3),len112,sendingbroad/multicastUDPsrc=520,dst=520IP:s=131.108.1.1(local),d=255.255.255.255(Serial3),len112,encapsulationfailedUDPsrc=520,dst=520

Solution

WhenRIPisrunninginaFrameRelay(NBMA)environment,Layer2mustbeconfiguredtosupportbroadcasttraffic;otherwise,RIPupdateswillnotgetacross.Whenstaticmap-pingisused,makesuretoaddthebroadcastkeywordattheendofaframe-relaymapstatement.Example3-84showsthenewconfigurationofRouterR1withthecorrectedframe-relaymapstatement.Example3-84CorrectedConfigurationtoEnableBroadcastTraffictoGoAcrossanNBMAEnvironment

R1#:interfaceSerial3ipaddress131.108.1.1255.255.255.0encapsulationframe-relayframe-relaymapip131.108.1.216broadcast!

Example3-85showstheroutingtableofR2withRIProutes.Example3-85R2RoutingTablewithRIPRoutesAftertheCorrectedframe-relaymapStatementforRouterR1

R2#showiproute131.108.2.0Routingentryfor131.108.2.0/24Knownvia"rip",distance120,metric1RedistributingviaripLastupdatefrom131.108.1.1onSerial0,00:00:07agoRoutingDescriptorBlocks:*131.108.1.1,from131.108.1.1,00:00:07ago,viaSerial0Routemetricis1,trafficsharecountis1

SenderIsNotAdvertisingRIPRoutes—Cause:MisconfiguredneighborStatement

Inanonbroadcastenvironment,RIPutilizesaunicastmethodtosendRIPupdates.TosendunicastRIPupdates,neighborstatementsmustbeconfiguredcarefully.Iftheneighboraddressisconfiguredincorrectlyintheneighborstatement,RIPwillnotsendtheunicastupdatetotheneighbor.Figure3-29showstheflowcharttofollowtosolvethisproblembasedonthiscause.


Example3-86showstheRIPconfigurationinRouterR1.Theconfigurationshowsthattheneighborstatementisconfiguredincorrectly.Insteadof131.108.1.2,it’spointingto131.108.1.3,whichdoesn’texist.Example3-86RouterR1RIPConfigurationwithIncorrectlyConfiguredneighborStatement

routerripnetwork131.108.0.0neighbor131.108.1.3

Solution

InExample3-86,RIPissendingaunicastupdatetoaneighboraddressof131.108.1.3,whichdoesn’texist.Tosolvetheproblem,theneighborstatementmustbeconfiguredproperly.Example3-87showsthecorrectedconfigurationofRouterR1.Example3-87RouterR1ConfigurationwiththeCorrectneighborStatement

R1#routerripnetwork131.108.0.0neighbor131.108.1.2

Example3-88showstheRIProutesinstalledinR2’sroutingtable.Example3-88R2RoutingTableShowstheRIPEntryAfterCorrectingtheRIPneighborStatement


RedistributingviaripLastupdatefrom131.108.1.1onSerial0,00:00:07agoRoutingDescriptorBlocks:*131.108.1.1,from131.108.1.1,00:00:07ago,viaSerial0Routemetricis1,trafficsharecountis1

SenderIsNotAdvertisingRIPRoutes—Cause:AdvertisedSubnetIsVLSM

InalmostallIPnetworks,IPaddressesareefficientlyutilizedbydoingvariable-lengthsubnetmasking(VLSM)oftheoriginalIPblock.BecauseRIP-1doesnotsupportVLSMrouting,routingVLSMroutesbecomesacommonissuewithRIPrunningnetworks.Figure3-30showsthenetworksetup,whichproducesproblemsbecauseoftheexistenceofaVLSM.ThefigureshowsthatRouter1hasaninterfacewhosemaskis25.Notethat131.108.0.0isvariablysubnettedtotwodifferentmasks,131.108.1.024and131.108.2.0/25.

Figure3-30VLSMNetworkExampleProducingProblemswithRIP

RIP-1cannotadvertisethemaskofasubnet,soitcannotsupportVLSMandcannotadvertise25toanRIPinterfacewhosemaskis24.Figure3-31showstheflowcharttofollowtocorrectthisproblem.


Example3-89showsthataloopbackinterfaceonR1isconfiguredfora25(255.255.255.128)subnetmask;theinterfacethatwillbesourcingRIPupdatehasa24(255.255.255.0)mask.Example3-89ConfigurationtoShowVLSMSubnets

R1#:interfaceLoopback0ipaddress131.108.2.1255.255.255.128!interfaceEthernet0ipaddress131.108.1.1255.255.255.0!routerripnetwork131.108.0.0

Solution

RIP-1isnotdesignedtocarrysubnetmaskinformation.Therefore,anysubnetthatisusingadifferentmaskthantheinterfacethatwillbesourcingtheRIPupdatewillnotbeadvertisedbyRIP.RIPactuallyperformsacheckbeforesendinganupdate,tomakesurethatthesubnetthatwillbeadvertisedbyRIPhasthesamesubnetmaskastheinterfacethatwillbesourcingtheRIPupdate.Ifthemaskisdifferent,RIPactuallydropstheupdateandwillnotadvertiseit.Tosolvetheproblem,eitherchangethesubnetmasksothatitmatchestheinterfacethatwillbesourcingtheRIPupdateorchangetheprotocoltoRIP-2,whichdoessupportVLSM.Example3-90showstheconfigurationchangesthatcorrecttheproblem.Example3-90ConfiguringRIPtoAdvertiseVLSMRoutes

R1#:interfaceLoopback0ipaddress131.108.2.1255.255.255.0!interfaceEthernet0ipaddress131.108.1.1255.255.255.0!

routerripversion2network131.108.0.0

Example3-91showstheroutingtableofRouterR2aftercorrectingtheproblem.Example3-91RouterR2RoutingTableAfterResolvingtheVLMSSupportProblem


SenderIsNotAdvertisingRIPRoutes—Cause:SplitHorizonIsEnabled

SplithorizonisafeatureinRIPtocontrolroutingloops.Insomesituations,itisnecessarytoenablesplithorizontoavoidloops.Forexample,splithorizonisnecessaryinanormalsituationwhenaRIPupdateisreceivedonaninterfaceandisnotsentoutonthesameinterface.Splithorizonmustbedisabledinotherenvironments,suchasahub-and-spokeFrameRelayenvironmentinwhichspokeshavenocircuitbetweenthemandtheygothroughthehubrouter,asshowninFigure3-32.

Figure3-32Hub-and-SpokeFrameRelayNetworkRequiringDisablingSplitHorizon

Anotheruniquesituationworthmentioningisoneinwhicharouterhasanexternalroutethathasanext-hopaddressalsoknownthroughsomeinterfacewhereotherRIProutersaresitting.WhenthoseexternalroutesareredistributedintoRIP,therouterdoesn’tadvertisethatrouteoutthesameinterfacebecausesplithorizonisenabled.Also,ifasecondaryaddressisconfiguredunderaninterface,splithorizonmustbeturnedoffonthatinterface;otherwise,thatsecondaryaddresswillnotbeadvertisedoutthatinterfacetootherrouters.Figure3-33showsthenetworksetupthatproducesproblemswhensplithorizonisenabled.Router1isnotadvertisingallRIProutestoRouter3.

Figure3-33SplitHorizon–EnabledNetworkVulnerabletoRIPProblems

Figure3-34showstheflowcharttofollowtofixthisproblem.


Example3-92showsthecurrentconfigurationofR1.

Example3-92166.166.166.0/24IsBeingRedistributedintoRIPonR1

R1#routerripredistributestaticnetwork131.108.0.0!iproute155.155.0.0255.255.0.010.10.10.4iproute166.166.166.0255.255.255.0131.108.1.3

Example3-93showsthattheroute166.166.166.0/24isnotintheroutingtableofRouterR2;however,155.155.155.0/24doesshowupintheroutingtable.Example3-93R2RoutingTableDoesNotShowRoute166.166.166.0/24

R2#showiprouteripR155.155.0.0/16[120/1]via131.108.1.1,00:00:07,Ethernet0

Example3-94showsthedebugipripoutputonRouterR1.R1isadvertisingonly155.155.0.0/16,not166.166.166.0/24.InR2’sroutingtable,norouteexistsfor166.166.166.0/24.Example3-94debugipripOutputDisplays166.166.166.0IsNotBeingAdvertisedbyR1

R1#debugipripRIPprotocoldebuggingison

RIP:sendingv1updateto255.255.255.255viaEthernet0(131.108.1.1)RIP:buildupdateentriesnetwork155.155.0.0metric1

Solution

Thisproblemoccursbecausethenexthopof166.166.166.0/24is131.108.1.2.Withsplithorizon,RIPwillsuppressthisupdatefromgoingoutthesameinterfacethat166.166.166.0/24islearned.Noticethattheroute155.155.155.0/24wasadvertisedbyR1becausethenext-hopaddressofthatroutewas10.10.10.4,whichisadifferentinterfaceonR1.ThesolutionliesinturningoffsplithorizonontheEthernet0interfaceofR1.Asimilarsituationwouldariseif166.166.166.0/24wasdefinedasasecondaryinterfaceaddressonR1,whichwillnotadvertisethissecondaryinterfaceaddressinitsRIPupdateunlesssplithorizonisturnedoff.Example3-95showsthenewconfigurationonRouterR1tosolvethisproblem.Example3-95DisablingSplit-HorizononR1’sEthernet0Interface

R1#interfaceEthernet0ipaddress131.108.1.1255.255.255.0noipsplit-horizon

Example3-96showsthataftermakingtheconfigurationchanges,R2isreceiving166.166.166.0/24intheRIPupdates.Example3-96R2RoutingTableAfterSplitHorizonHasBeenDisabledConfirmsThatRIPUpdatesReflectthe166.166.166.0/24Route

R2#showiprouteripR155.155.0.0/16[120/1]via131.108.1.1,00:00:08,Ethernet0R166.166.0.0/16[120/1]via131.108.1.1,00:00:08,Ethernet0

ThisproblemcanalsobeseenwheninterfacesareconfiguredwithsecondaryIPaddresses.Example3-97showstheinterfaceconfigurationwithsecondaryIPaddress.Example3-97InterfaceConfigurationwithSecondaryAddresses

R1#interfaceEthernet0ipaddress131.108.2.1255.255.255.0secondaryipaddress131.108.1.1255.255.255.0

Ifsplithorizonisenabled,thissecondaryaddresswillnotbeadvertisedonEthernet0.Similarly,imagineasituationinwhichtherearethreerouters—R1,R2,andR3—onthesameEthernet,asshowninFigure3-35.

Figure3-35AnotherSplitHorizon–EnabledNetworkVulnerabletoRIPProblems

R1andR3arerunningOSPF.R1andR2arerunningRIP,asintheprecedingexample.Now,R3advertisescertainroutesthroughOSPFtoR1thatR1mustredistributeinRIP.R1willnotadvertisethoseOSPFroutestoR2becauseofsplithorizon.Thesolutionisagaintodisablesplithorizon.Basically,thesearethethreemainreasonsforturningoffsplithorizon.Anyothersituationmightcreatearoutingloopifsplithorizonisturnedoff.

Problem:SubnettedRoutesMissingfromtheRoutingTableofR2—Cause:AutosummarizationFeatureIsEnabled

Insomesituations,subnettedroutesarenotadvertisedinRIP.WheneverRIPsendsanupdateacrossamajornetworkboundary,theupdatewillbeautosummarized.Thisisnotreallyaproblem;thisisdonetoreducethesizeoftheroutingtable.Figure3-36showsanetworksetupinwhichR1hassubnetsof155.155.0.0,butR2showsnoneofthesesubnetsinitsroutingtable.EitherR1isnotadvertisingthemtoR2,orR2isnotreceivingthem.ThechancesofR1notadvertisingmorespecificsubnetsof155.155.0.0/16ismorefavorable.

Figure3-36RIPNetworkVulnerabletoAutosummarizationProblems

Example3-98showsthatthesubnettedrouteof155.155.0.0/16ismissingfromtheroutingtableofR2,butthemajornetworkrouteispresent.ThismeansthatR1isadvertisingtheroutesbutissomehowsummarizingthesubnetstogoas15.155.0.0/16.Example3-98R2’sRoutingTableReflectsThattheSubnettedRouteIsMissing

R2#showiproute155.155.155.0255.255.255.0%Subnetnotintable

R2#showiproute155.155.0.0Routingentryfor155.155.0.0/16Knownvia"rip",distance120,metric1RedistributingviaripAdvertisedbyrip(selforiginated)Lastupdatefrom131.108.1.1onEthernet0,00:00:01agoRoutingDescriptorBlocks:*131.108.1.1,from131.108.1.1,00:00:01ago,viaEthernet0Routemetricis1,trafficsharecountis1

Figure3-37showstheflowcharttofixthisproblembasedontheautosummarizationfeaturebeingenabled.


Example3-99showstheconfigurationofR1inthecaseofRIP-1.RIP-1isaclassfulprotocolandalwayssummarizestoclassfulboundariesfornondirectlyconnectedmajornetworks.Example3-99R1ConfigurationwithRIPVersion1

R1#interfaceLoopback1ipaddress131.108.2.1255.255.255.0!interfaceLoopback3ipaddress155.155.155.1255.255.255.0!interfaceEthernet0ipaddress131.108.1.1255.255.255.0!routerripnetwork131.108.0.0network155.155.0.0

Example3-100showstheroutingtableinRouterR2.NoticethatR2isreceiving155.155.0.0/16,not155.155.155.0/24,asconfiguredonR1.AlsonotethatR2isreceivinga/24routeof131.108.2.0,therouteofthesamemajornetworkasthatofinterfaceEthernet0,whichconnectsR1toR2.Example3-100R2RoutingDisplaytoShowHowSubnettedRoutesAreSummarizedtoClassfulBoundaries

R2#showiprouteRIPR155.155.0.0/16[120/1]via131.108.1.1,00:00:22,Ethernet0131.108.0.0/24issubnetted,3subnetsR131.108.2.0[120/1]via131.108.1.1,00:00:22,Ethernet0

Solution

InRIP-1,thereisnoworkaroundforthisproblembecauseRIP-1isaclassfulroutingprotocol.RIP-1automaticallysummarizesanyupdatetoanaturalclassboundarywhenthatupdategoesoveraninterfaceconfiguredwithadifferentmajornetwork.AsindicatedbyR2’sroutingtableinExample3-100,155.155.155.0/24isadvertisedoveraninterfaceconfiguredwith131.108.0.0.Thissummarizes155.155.155.0/24toaClassBboundaryas155.155.0.0/16.InRIP-1,thisisnotaproblembecauseRIP-1isaclassfulprotocolandthenetworkshouldbedesignedwiththisunderstanding.WithRIP-2,however,Ciscorouterscanbeconfiguredtostoptheautosummarizationprocess.Forexample,R1’sconfigurationscanbechangedtorunaRIP-2processratherthanaRIP-1process.Example3-101showstheconfigurationthatsolvesthisproblemforRIP-2.Example3-101DisablingAutosummarizationinRIP-2

routerripversion2network131.108.0.0network155.155.0.0noautosummary

Example3-102showstheroutingtableofRouterR2,whichindicatesthatitisnowreceivingdesiredsubnettedroute155.155.155.0/24.Example3-102RouterR2’sRoutingTableShowsThatItIsReceivingtheSubnettedRoute155.155.155.0/24

R2#showiproute155.155.0.0155.155.0.0/24issubnetted,1subnetsR155.155.155.0[120/1]via131.108.1.1,00:00:21,Ethernet0131.108.0.0/24issubnetted,3subnetsR131.108.2.0[120/1]via131.108.1.1,00:00:21,Ethernet0

TroubleshootingRoutesSummarizationinRIPRoutesummarizationreferstosummarizingorreducingthenumberofroutesinaroutingtable.Forexample,131.108.1.0/24,131.108.2.0/24and131.108.3.0/24canbereducedtoonerouteentry(thatis,131.108.0.0/16or131.108.0.0/22),thelatterofwhichwillcoveronlythesethreesubnets.Routesummarization(autosummarizationandmanualsummarization,bothofwhichareaddressedinthissection)isusedtoreducethesizeoftheroutingtable.Thissectiondiscussesthemostsignificantproblemrelatedtotheroutesummarization—theRIP-2routingtableishuge.Twoofthemostcommoncausesforthisareasfollows:•Autosummarizationisoff.•ipsummary-addressisnotused.

Figure3-38showsanetworksetupthatcouldproducealargeroutingtable.

Figure3-38NetworkSetupThatCouldGenerateaLargeRoutingTable

Problem:RIP-2RoutingTableIsHuge—Cause:AutosummarizationIsOffWhenaRIPupdatecrossesamajornetwork,itsummarizestotheclassfulboundary.Forexample,131.108.1.0,131.108.2.0,and131.108.3.0willbeautosummarizedto131.108.0.0/16whenadvertisedtoarouterwithno131.108.X.Xaddressesonitsinterfaces.Disablingtheautosummarizationfeatureincreasesthesizeoftheroutingtable.Insomesituations,thisfeaturemustbeturnedoff(forexample,ifdiscontiguousnetworksexist,asdiscussedearlier).Figure3-39showstheflowcharttofollowtosolvethisproblembasedonthiscause.

Figure3-39FlowcharttoResolveaLargeRIP-2RoutingTableDebugsandVerification

Example3-103showstheconfigurationonR2thatproducesthisproblem.Inthisconfiguration,R2hasautosummaryturnedoff.Example3-103DisablingAutosummarizationUnderRIPforR2

R2#routerripversion2network132.108.0.0

network131.108.0.0noautosummary

Example3-104showsR1’sroutingtable.Thisroutingtablehasonlyfourroutes,butinarealnetworkwiththeconfigurationinExample3-103,therecouldbeseveralhundredroutes.R1isreceivingeverysubnetof131.108.0.0/16.Inthisexample,theseareonlythree,butitcanbemuch,muchworse.Example3-104RouterR1RoutingTableShowsSubnettedRoutesintheRoutingTable

R1#showiprouterip131.108.0.0/24issubnetted,3subnetsR131.108.3.0[120/1]via132.108.1.2,00:00:24,Serial3R131.108.2.0[120/1]via132.108.1.2,00:00:24,Serial3R131.108.1.0[120/1]via132.108.1.2,00:00:24,Serial3R1#

Solution

BecausetheautosummarizationfeatureisdisabledundertheRIPconfigurationofR2,R1seesthesubnettedroutesintheroutingtable.Whenthisfeatureisenabled,allthesubnettedrouteswillgoaway.Example3-105showsthealteredconfigurationofR2.Inthisconfiguration,autosummarizationison,toreducethesizeoftheroutingtable.Becausethisisthedefault,youwillnotseeitintheconfiguration.Thecommandtoenableautosummarizationisautosummaryunderrouterrip.Example3-105R2UsesAutosummarizationtoReduceRoutingTableSize

R2#routerripversion2network132.108.0.0network131.108.0.0

Example3-106showsthereducedsizeoftheroutingtable.Example3-106AutosummaryReducestheRoutingTableSizeforRouterR1

R1#showiprouteripR131.108.0.0/16[120/1]via132.108.1.2,00:00:01,Serial3R1#

Problem:RIP-2RoutingTableIsHuge—Cause:ipsummary-addressIsNotUsedFigure3-40showsthenetworksetupthatcouldproducealargeroutingtable.

Figure3-40NetworkSetupThatCouldGenerateaLargeRoutingTable

Figure3-40showsthatR2isannouncingseveralsubnetsof131.108.0.0network.NoticethatthelinkbetweenR1andR2isalsopartofthe131.108.0.0network,soautosummarizationcannotplayanyroletosolvetheproblemofreceivingasubnetroutethatcouldbesummarized.Theautosummarizationfeature

couldhaveworkedonlyiftheR1,R2linkwasinadifferentmajornetwork.Figure3-41showstheflowcharttofollowtosolvethisproblembasedonthiscause.

Figure3-41FlowcharttoResolveaLargeRIP-2RoutingTableDebugsandVerification

Example3-107showsthatintheconfigurationofR2,theipsummary-addresscommandisnotusedundertheSerial1interfacetosummarizetheroutes.Example3-107R2’sSerialInterfaceIsNotConfiguredtoSummarizeRoutes

R2#interfaceSerial1ipaddress131.108.4.2255.255.255.0!routerripversion2network131.108.0.0

Example3-108showstheroutingtableofR1.Inthisexample,thereareonlythreeroutes.Inarealnetwork,however,thenumbercouldbeworsebasedontheconfigurationinExample3-107.Example3-108R1RoutingTableShowsSubnettedRoutes

R1#showiprouterip131.108.0.0/24issubnetted,3subnetsR131.108.3.0[120/1]via131.108.4.2,00:00:04,Serial3R131.108.2.0[120/1]via131.108.4.2,00:00:04,Serial3R131.108.1.0[120/1]via131.108.4.2,00:00:04,Serial3

R1#

Solution

Inthesituationdescribedintheprecedingsection,autosummaryisonbutisnothelpfulbecausethewholenetworkiswithinonemajornetwork.ImagineanetworkwithClassBaddressspacewiththousandsofsubnets.Autosummarycannotplayanyroleherebecausenomajornetworkboundaryiscrossed.AnewfeatureofsummarizationwasintroducedinRIPstartingwithCiscoIOSSoftwareRelease12.0.7T.ThisfeatureissimilartoEIGRPmanualsummarization.Example3-109showsthenewconfigurationthatsolvesthisproblem.Thisconfigurationreducesthesizeoftheroutingtable.Thiscommandcanbeusedwithdifferentmaskssothat,ifanetworkhascontiguousblocksofasubnet,theroutercouldbeconfiguredtosummarizesubnetsintosmallerblocks.ThisthenwouldreducetheroutesadvertisedtotheRIPnetwork.Example3-109ManualSummarizationwithRIP

R2#:interfaceSerial1ipaddress131.108.4.2255.255.255.0ipsummary-addressrip131.108.0.0255.255.252.0!routerripversion2network131.108.0.0

Basedontheprecedingconfiguration,R2willsummarizetheRIProuteontheSerial1interface.Anynetworksubnetthatfallsinthe131.108.0.0networkwillbesummarizedtoone131.108.0.0majornetwork,anditsmaskwillbe255.255.252.0.ThismeansthatR2willannounceonlyasinglesummarizerouteof131.108.0.0/22andwillsuppressthesubnetsof131.108.0.0.Example3-110showstheroutingtableofRouterR1withareducednumberofentriesasaresultofsummarization.Example3-110R1’sRoutingTableIsReducedasaResultofSummarization

R1#showiprouteripR131.108.0.0/22[120/1]via131.108.4.2,00:00:01,Serial3R1#

TroubleshootingRIPRedistributionProblemsThissectiontalksaboutproblemsthatcanhappenduringredistributioninRIP.RedistributionreferstothecasewhenanotherroutingprotocolorastaticrouteorconnectedrouteisbeinginjectedintoRIP.Specialcareisrequiredduringthisprocesstoavoidanyroutingloops.Inaddition,metric(hopcount)shouldbedefinedduringthisprocess,toavoidproblems.ThemostprevalentproblemencounteredwithRIPredistributionisthatredistributedroutesarenotbeinginstalledintheroutingtableoftheRIProutersreceivingtheseroutes.Whendestinationroutesarenotpresentinaroutingtable,nodatacanreachthosedestinations.ThemostcommoncauseofthisisametricthatisnotdefinedduringredistributionintoRIP.InRIP,themetricforarouteistreatedasahopcountthatshowsthenumberofroutersthatexistalongthisroute.AsdiscussedinChapter2,15isthemaximumhopcountthatRIPsupports;anythinggreaterthan15istreatedastheinfinitemetricand,uponreceipt,isdropped.Figure3-42showsthenetworksetupthatcouldproducetheprobleminwhichredistributedroutesdonotgetinstalledintheroutingtableofthereceiver.

Figure3-42NetworkVulnerabletoRedistributedRouteProblems

R1andR3arerunningOSPFinArea0,whereasR1andR2arerunningRIP.R3isannouncing131.108.6.0/24throughOSPFtoR1.InR1,OSPFroutesarebeingredistributedintoRIP,butR2isnotreceiving131.108.6.0/24throughRIP.Figure3-43showstheflowcharttofollowtosolvethisproblembasedonthiscause.

Figure3-43FlowcharttoResolveRedistributedRouteProblems

DebugsandVerificationTotroubleshootthisproblem,youneedtoinvestigatewhetherR1isreceiving131.108.6.0/24.

Example3-111showsthatR3isadvertising131.108.6.0/24throughOSPFtoR1.Example3-111showiprouteOutputConfirmsThatOSPFIsWorkingFineandThatR1IsReceiving131.108.6.0/24

R1#showiproute131.108.6.0Routingentryfor131.108.6.0/24Knownvia"ospf1",distance110,metric20,typeintraarea

R1mustbeconfiguredtoredistributeOSPFroutesinRIP.Example3-112showsthatR1isredistributingOSPFinRIP.Example3-112ConfiguringR1SoThatOSPFIsRedistributedinRIP

R1#routerripversion2redistributeospf1network131.108.0.0

Now,youmustfirstinvestigateR2whether131.108.6.0/24iscoming.Example3-113showsthat,inR2,131.108.6.0/24isnotpresentintheRIProutingtable.Example3-113R2RoutingTableDoesNotReflectThat131.108.6.0/24IsPresent


Therearetwobasicwaystoviewthisissue.ThefirstisasimpleshowrunonR1.ThesecondistorunthedebugipriponR2commandtowatchtheprocess.Example3-114showstheoutputofdebugiprip.Example3-114debugipripOutputShowsThat131.108.6.0/24IsInaccessible

R2#debugiprip

RIP:receivedv2updatefrom131.108.1.1onEthernet1131.108.6.0/24->0.0.0.0in16hops(inaccessible)

SolutionInRIP-1orRIP-2,16isconsideredtobeaninfinitemetric.Anyupdatewithametricgreaterthan15willnotbeconsideredforentryintotheroutingtable.Inthisexample,theOSPFrouteinR1for131.108.6.0/24hasametricof20.WhenOSPFisredistributedintoRIPinR1,OSPFadvertised131.108.6.0/24withametricof20,whichexceedsthemaximummetricallowedinRIP.OSPFknowsonlycostasametric,whereasRIPutilizeshopcount.Nometrictranslationfacilityexists,sotheadministratormustconfigureametrictobeassignedtoredistributedroutes.WithoutthedefaultmetricconfigurationinR1,R2,uponreceivingthisupdate,complainsabouttheexcessivemetricandmarksitas(inaccessible),asshowninExample3-114.Tocorrectthisproblem,R1needstoassignavalidmetricthroughconfigurationwhendoingtheredistribution,asdoneforR1inExample3-115.Example3-115AssigningaValidMetricforSuccessfulRedistribution

R1#routerripversion2redistributeospf1metric1network131.108.0.0

IntheconfigurationofExample3-155,allredistributedroutesfromOSPFinRIPgetametricof1.ThismetricistreatedashopcountbyR2.Example3-116showsthatR2isreceivingthecorrectroutewithametricof1.Example3-116debugipripRevealsThattheNewConfigurationforR1WorksandThatR2IsReceivingtheCorrectRoute

R2#debugiprip

RIP:receivedv2updatefrom131.108.1.1onEthernet1131.108.6.0/24->0.0.0.0in1hops

Example3-117showsthattheroutegetsinstalledintheroutingtableofR2.Example3-117R2RoutingTableReflectsThattheRedistributionforRoute131.108.6.0/24IsSuccessful


TroubleshootingDial-on-DemandRoutingIssuesinRIPDial-on-demandrouting(DDR)iscommoninscenariosinwhichtheISDNorsimilardialuplinksareusedasabackuplink.Whentheprimarylinkgoesdown,thisbackuplinkcomesup.RIPbeginssendingandreceivingupdatesonthislinkaslongastheprimarylinkisdown.Thedialuplinkscanbeusedasabackupfortheprimarylinkintwoways:•Usethebackupinterfacecommand.•Useafloatingstaticroutewithadialerlistthatdefinesinterestingtraffic.

Thefirstmethodisverysimple:Thecommandistypedunderthedialinterface,indicatingthatit’sabackupforaprimaryinterface.ThesecondmethodrequiresafloatingstaticroutewithahigheradministrativedistancethanRIP(forexample,130orabove).Italsorequiresdefininginterestingtrafficthatshouldbringupthelink.TheRIPbroadcastaddressof255.255.255.255mustbedeniedinthedialerlist,soitshouldn’tbringupthelinkunnecessarily.WhenrunningRIPunderDDRsituations,thereareanumberofissuestoconsider.SomeproblemsarerelatedtotheISDNlineoranasynclineinwhichRIPupdateskeepbouncing.Someproblemsarerelatedtotheconfiguration.Thissectiontalksaboutthetwomostcommondialupproblems:•ARIPbroadcastiskeepingthelinkup.•RIPupdatesarenotgoingacrossthedialerinterface.

Problem:RIPBroadcastIsKeepingtheISDNLinkUp—Cause:RIPBroadcastsHaveNotBeenDeniedintheInterestingTrafficDefinition

ISDNlinksaretypicallyusedasbackuplinkswhenprimarylinksgodown.CiscoIOSSoftwarerequiresthatarouterbeinstructedonwhichkindoftrafficcanbringuptheISDNlinkandkeepitup.Suchtrafficisreferredtoasinterestingtraffic.NetworkoperatorstypicallywantdatatraffictobeconsideredasinterestingtraffictobringandkeeptheISDNlinkup.RIPorotherroutingprotocolupdatesshouldnotbedefinedasinterestingtraffic.Ifthisisnotdone,whentheISDNlinkcomesup,itstaysupaslongasroutingupdates(RIP,inthiscase)aresentonaregularbasis.ThatisnotbethedesiredbehaviorbecauseISDNprovideslow-speedconnectivity,andsomedataactuallymightgoovertheslowlinkeventhoughtheprimaryfasterlinkisavailable.Figure3-44showsthenetworksetupthatproducestheseparticularDDRissues.

Figure3-44NetworkSetupVulnerabletoDDRProblems


Figure3-45FlowcharttoSolvetheRIPBroadcastKeepingtheISDNLinkUpProblemDebugsandVerification

Example3-118showstheconfigurationonRouterR1thatproducesthisproblem.Inthisconfiguration,onlyTCPtrafficisdenied.Inotherwords,TCPtrafficwillnotbringupandsustainthelink.RIPbroadcastsutilizeUDPport520.BecausethepermitipanyanycommandallowsUDPport520togothrough,RIPtrafficisconsideredinterestingtraffic.

InExample3-118,interfaceBRI3/0isconfiguredtodialviathedialer-mapcommandtotherouterwithanIPaddressof192.168.254.14(R2).Thenumberofdialis57654.Thedialer-groupcommanddefinesdialer-list1,whichreliesonaccess-list100todefinetheinterestingtraffic.Inthisexample,access-list100deniesallTCPtrafficandpermitsallIPtraffic.Inotherwords,TCPtrafficwillnotbringupandkeepuptheISDNlink,whereasothertraffic,includingRIP,candoso.Example3-118ConfiguringtheISDNInterfacewithdialer-grouptoDefineInterestingTraffic

R1#interfaceBRI3/0ipaddress192.168.254.13255.255.255.252encapsulationpppdialermapip192.168.254.14nameR2broadcast57654dialer-group1isdnswitch-typebasic-net3pppauthenticationchap

access-list100denytcpanyanyaccess-list100permitipanyanydialer-list1protocoliplist100

Example3-119showstheoutputofshowdialer,whichshowsthatthereasonforthelinkcomingupisaRIPbroadcast.Example3-119showdialerOutputRevealsThataRIPBroadcastIsKeepingtheISDNLinkUp

R1#showdialerBRI1/1:1-dialertype=ISDNIdletimer(120secs),Fastidletimer(20secs)Waitforcarrier(30secs),Re-enable(2secs)DialerstateisdatalinklayerupDialreason:ip(s=192.168.254.13,d=255.255.255.255)Currentcallconnected00:00:08Connectedto57654(R2)

InExample3-119,Dialreasonsection255.255.255.255isthedestinationIPaddress,whichistheaddresswhereRIP-1advertisementswillgoonBRI1/1:1.DialreasonindicatesthattheinterestingtrafficisRIP,whichhascausedthisISDNtodialinthefirstplace.Solution

WhenrunningRIPandDDR,defineanaccesslistforinterestingtraffic.InExample3-118,theaccesslistisdenyingonlytheTCPtrafficandpermittingalltheIPtraffic.RIPusesanIPbroadcastaddressof255.255.255.255tosendtheroutingupdates.ThisaddressmustbedeniedintheaccesslistsothatRIPdoesn’tbringupthelinkevery30seconds.Denying255.255.255.255asadestinationwillblockallbroadcasttrafficfrombringingupthelink.BlockingUDPport520willblockRIP-1andRIP-2updatesspecifically.Whenthelinkisup,RIPcanflowfreelyacrossthelink.However,itwillnotkeepthelinkupbecauseit’snotpartoftheinterestingtrafficdefinition.Example3-120showsthecorrectconfigurationchangeinRouterR1.Inthisconfiguration,alltrafficdestinedto255.255.255.255addressisdenied.Thiscoversallbroadcasttraffic,soRIP-1willnotbringupthelinkafterthisconfigurationchange.Example3-120CorrectConfigurationforRouterR1inaccess-list100toDenyTrafficfromtheRIP-1BroadcastIPAddress

R1#access-list100denyipany255.255.255.255access-list100permitipanyanydialer-list1protocoliplist100

OneimportantthingtoknowhereisthatRIP-1usesthe255.255.255.255addressforsendingRIPupdates.RIP-2,ontheotherhand,uses224.0.0.9.So,whendealingwithRIP-2,youneedtodenytrafficfromthemulticastaddressof224.0.0.9asinterestingtraffic,asdemonstratedinExample1-21.Example3-121ConfigurationforRouterR1inaccess-list100toDenyTrafficfromtheRIP-2BroadcastIPAddress

R1#access-list100denyipany224.0.0.9access-list100permitipanyany

Also,inasituationinwhichbothRIP-1andRIP-2arerunning,bothofthesebroadcastaddressesshouldbedeniedintheaccesslist,asdemonstratedinExample3-122.Example3-122ConfigurationforRouterR1inaccess-list100toDenyTrafficfromtheRIP-1andRIP-2BroadcastIPAddresses

access-list100denyipany255.255.255.255access-list100denyipany224.0.0.9access-list100permitipanyany

BecausebothRIP-1andRIP-2useUDPport520,itwouldbemostefficienttodenythisportifRIP-1andRIP-2arenotconsideredinterestingtraffic.Example3-123demonstratesthis.Example3-123Configuringaccess-list100forR1toDenyTrafficfromtheRIP-1andRIP-2UDPPort

R1#access-list100denyudpanyanyeq520access-list100permitipanyany

ThefinalconfigurationofR1wouldlikeExample3-124.Example3-124EfficientConfigurationofR1whenRIP-1andRIP-2AreBothDeniedasInterestingTraffic

R1#interfaceBRI3/0ipaddress192.168.254.13255.255.255.252encapsulationpppdialermapip192.168.254.14nameR2broadcast57654dialer-group1isdnswitch-typebasic-net3pppauthenticationchap!access-list100denyudpanyanyeq520access-list100permitipanyany!dialer-list1protocoliplist100

Problem:RIPUpdatesAreNotGoingAcrosstheDialerInterface—Cause:Missingbroadcast

KeywordinadialermapStatementWhenadialerinterface(ISDN,forexample)comesup,youmightwanttorunaroutingprotocoloverthislink.Staticroutesmightdothejob,butinnetworkswithalargenumberofroutes,staticroutesmightnotscale.Therefore,runningadynamicroutingprotocolsuchasRIPisnecessary.Insomesituations,theISDNlinkmightbeup,butnoroutinginformationisgoingacross.Withoutaroutingprotocol,nodestinationaddressescanbelearnedandnotrafficcanbesenttothosedestinations.ThisproblemmustbefixedbecausetheISDNinterfaceisofnousewhenitisnotcarryinganytraffic.Figure3-46showstheflowcharttofollowtosolvethisproblembasedonthiscause.

Figure3-46FlowcharttoSolvetheRIPUpdatesNotGoingAcrosstheDialerInterfaceProblemDebugsandVerification

Example3-125showstheconfigurationonR1thatproducesthisproblem.Example3-125ConfiguringR1WhenNoRoutingUpdatesWillGoontheISDNLink

R1#interfaceBRI3/0ipaddress192.168.254.13255.255.255.252encapsulationpppdialermapip192.168.254.14nameR257654dialer-group1isdnswitch-typebasic-net3pppauthenticationchap

Example3-126showsthatRIPissendingthebroadcastupdatetowardR2.Youcanseethatit’sfailingbecauseoftheencapsulationfailedmessage.AlsoinExample3-126,R1isrunningadebugippacketcommandwithaccess-list100todisplayonlytheUDPport520output.RIP-1andRIP-2useUDPport520toexchangeupdateswithotherRIPrunningrouters.Example3-126DiscoveringWhyRIPRoutesAreNotGoingAcrossanISDNInterface

R1#access-list100permitudpanyanyeq520access-list100denyipanyany

R1#debugippacket100detailIP:s=192.168.254.13(local),d=255.255.255.255(BRI3/0),len46,sendingbroad/multicastUDPsrc=520,dst=520IP:s=192.168.254.13(local),d=255.255.255.255(BRI3/0),len72,encapsulationfailedUDPsrc=520,dst=520

Solution

TherootoftheissueisRIP’suseofbroadcaststosenditsroutingupdates.InDDR,dialermapstatementsarenecessarytoassociatethenext-hopprotocoladdresstothephonenumberdialedtogettothedestination.Thebroadcastkeywordmustbeusedinthedialermapstatements;otherwise,thebroadcastwillencountertheencapsulationfailuremessagedemonstratedbyExample3-126.Tocorrectthisproblem,addthebroadcastkeywordinthedialermapstatement,asdemonstratedinExample3-127forRouterR1.Example3-127CorrectedConfigurationofR1toEnableRIPUpdatestoGoAcrosstheISDNInterface

interfaceBRI3/0ipaddress192.168.254.13255.255.255.252encapsulationpppdialermapip192.168.254.14nameR2broadcast57654dialer-group1isdnswitch-typebasic-net3pppauthenticationchap

TroubleshootingRoutesFlappingProbleminRIPRunningRIPinacomplexenvironmentcansometimescauseflappingofroutes.Routeflappingreferstoroutescomingintoandgoingoutoftheroutingtable.Tocheckwhethertheroutesareindeedflapping,checktheroutingtableandlookattheageoftheroutes.Iftheagesareconstantlygettingresetto00:00:00,thismeansthattheroutesareflapping.Severalreasonsexistforthiscondition.Thissectiondiscussesoneofthecommonreasons—packetlossbecausethepacketisdroppingonthesender’sorreceiver’sinterface.TheexampleinthissectionconsidersFrameRelaybecauseitisthemostcommonmediuminwhichthisproblemoccurs.Thepacketlosscanbeverifiedthroughtheinterfacestatisticsbylookingatthenumberofpacketdropsanddeterminingwhetherthatnumberisconstantlyincrementing.Figure3-47showsthenetworksetupthatcanproduceRIProuteflapping.

Figure3-47NetworkVulnerabletoRIPRouteFlapping

Figure3-48showstheflowcharttofollowtosolvethisproblem.

Figure3-48FlowcharttoSolvingtheRIPRouteFlappingProblem

DebugsandVerificationInalargeRIPnetwork,especially,inaFrameRelayenvironment,thereisahighpossibilitythatRIPupdatesarelostintheFrameRelaycloudorthattheRIPinterfacedroppedtheupdate.Again,thesymptomscanbepresentinanyLayer2media,butFrameRelayisthefocushere.ThissituationcausesRIPtolosearouteforawhile.IfRIPdoesnotreceivearoutefor180seconds,therouteisputinaholddownfor240secondsandthenispurged.Thissituationiscorrectedbyitself(andtime),but,insomecases,configurationchangescanberequired.Forexample,considertheoutputinExample3-128,wherenoRIPupdatehasbeenreceivedfor2minutesand8seconds.ThismeansthatfourRIPupdateshavebeenmissed,andweare8secondsintothefifthupdate.Example3-128RoutingTableoftheHubRouterShowingThattheLastRIPUpdateWasReceived2:08MinutesAgo

Hub#showiprouteripR155.155.0.0/16[120/1]via131.108.1.1,00:02:08,Serial0R166.166.0.0/16[120/1]via131.108.1.1,00:02:08,Serial0

Example3-129showsthattherearealargenumberofbroadcastdropsontheinterface.Example3-129showinterfacesserial0OutputRevealsaLargeNumberofBroadcastDrops

Hub#showinterfacesserial0Serial0isup,lineprotocolisupHardwareisMK5025Description:CharlotteFrameRelayPortDLCI100MTU1500bytes,BW1024Kbit,DLY20000usec,rely255/255,load44/255EncapsulationFRAME-RELAY,loopbacknotset,keepaliveset(10sec)LMIenqsent7940,LMIstatrecvd7937,LMIupdrecvd0,DTELMIupLMIenqrecvd0,LMIstatsent0,LMIupdsent0LMIDLCI1023LMItypeisCISCOframerelayDTEBroadcastqueue64/64,broadcastssent/dropped1769202/1849660,interfacebroadcasts3579215

SolutionTheshowinterfacesserial0commandfurtherprovesthatthereissomeproblemattheinterfacelevel.Toomanydropsareoccurringattheinterfacelevel.Thisisthecauseoftherouteflapping.InthecaseofFrameRelay,theFrameRelaybroadcastqueuemustbetuned.TuningtheFrameRelaybroadcastqueueisoutofthescopeofthisbook;severalpapersatCisco’sWebsitediscusshowtotunetheFrameRelaybroadcastqueue.Inanon-FrameRelaysituation,theinputoroutputholdqueuemightneedtobeincreased.Example3-130showsthatafterfixingtheinterfacedropproblem,routeflappingdisappears.Example3-130SerialInterfaceOutputAfterAdjustingtheBroadcastQueue

Hub#showinterfacesserial0Serial0isup,lineprotocolisupHardwareisMK5025Description:CharlotteFrameRelayPortDLCI100MTU1500bytes,BW1024Kbit,DLY20000usec,rely255/255,load44/255EncapsulationFRAME-RELAY,loopbacknotset,keepaliveset(10sec)LMIenqsent7940,LMIstatrecvd7937,LMIupdrecvd0,DTELMIupLMIenqrecvd0,LMIstatsent0,LMIupdsent0LMIDLCI1023LMItypeisCISCOframerelayDTEBroadcastqueue0/256,broadcastssent/dropped1769202/0,interfacebroadcasts

3579215

InExample3-131,theshowiproutesoutputdisplaysthattheroutesarestableintheroutingtableandthatthetimersareatavaluelowerthan30seconds.Example3-131showiproutesOutputRevealsStableRIPRoutes

Hub#showiprouteripR155.155.0.0/16[120/1]via131.108.1.1,00:00:07,Serial0R166.166.0.0/16[120/1]via131.108.1.1,00:00:07,Serial0

Chapter4.UnderstandingInteriorGatewayRoutingProtocol(IGRP)

ThischaptercoversthefollowingkeytopicsaboutInteriorGatewayRoutingProtocol(IGRP):•Metrics•Timers•Splithorizon•Splithorizonwithpoisonreverse•IGRPpacketformat•IGRPbehavior•DefaultrouteandIGRP•Unequal-costloadbalancinginIGRP

Inthemid-1980s,Ciscodevelopeditsownproprietaryroutingprotocol,InteriorGatewayRoutingProtocol(IGRP),asasolutiontosomeoftheshortcomingsofRIP,suchasthehop-countlimitationof15.LikeRIP,IGRPisadistancevectorprotocol.However,IGRPcalculatesitscompositemetricfromavarietyofvariables,suchasbandwidthanddelay,andhopcountisnotconsideredintheroutingdecision.IGRPusesvariablessuchasinterfacebandwidthanddelay,whichreflectabetterpictureofthenetworktopology.Thisresultsinamoreefficientmethodofroutingpackets.OtheradvantagesofIGRPoverRIPincludeunequal-costloadsharing;alongerupdateperiodthanRIP,forbetterbandwidthusage;andamoreefficientpacket-updateformat.

MetricsIGRPusesanequationtocalculateitsmetrics.Metricsthenareusedbytheroutertofavoraparticularroute.InIGRP,thelowerthevalueofthemetricis,themorefavorabletherouteis.TheIGRPmetricequationtakesintoconsiderationthevariablesofbandwidth,delay,load,andreliabilityofthelinktocalculateitsmetric.Equation4-1showstheIGRPmetricequation.

Equation4-132IGRPMetricEquation

K1,K2,K3,K4,K5=ConstantsDefaultvalues:K1=K3=1,K2=K4=K5=0BW=107/(minbandwidthalongpathsinkilobitspersecond)Delay=(Sumofdelaysalongpathsinmilliseconds)/10Load=LoadofinterfaceReli=Reliabilityoftheinterface

Fromtheequation,theloadvariableisavaluefrom1to255,inwhich255indicates100percentsaturationofthelinkand1indicatesvirtuallynotraffic.Therelivariableisalsoavaluefrom1to255,inwhich1indicatesanunreliablelinkand255indicatesa100percentreliablelink.ReferringtoEquation4-1,thetermK5(Reli+K4)isusedonlyifK5isnotequalto0.IfK5isequalto0(asthedefault),thetermK5(Reli+K4)isignoredintheequation.VariablesK1throughK5areconstantnumbersusedintheequation.ThedefaultvalueoftheKvaluesare:K1=K3=1,K2=K4=K5=0.TheIGRPmetricequationthenreducestothis:

IGRPMetric=BW+Delay

Therefore,bydefault,IGRPconsidersonlythebandwidthandthedelayofthelinktocalculateitsmetrics.ThenetworkadministratorcanchangethedefaultKvaluetoothernumberssothatothercomponentsofthemetricequation,suchasloadandreliability,canbeused.Forexample,ifthenetworkadministratorwantstoconsiderinterfacereliabilityasonefactorinroutingthepacket,thevalueofK5wouldhavetobeanonzeronumber;however,suchachangeishighlynotrecommended.Thebandwidthvariableistheminimumbandwidthalongthepathfromthelocalroutertothedestination,inkilobitspersecond,scaledby107.Thebandwidthassociatedwithaninterfaceisastaticvalueassignedbytherouteroranetworkadministrator;itisnotadynamicvaluethatchangeswiththroughput.Theminimumbandwidthisobtainedbycomparingtheinterfacesalongthepathstothedestinationnetwork.Forexample,anetworkthatneedstotraverseaT1linkandanEthernetlinkwillhaveaminimumbandwidthof1544kbps.NoticethatthebandwidthonaregularserialinterfaceisassumedtobeT1withaspeedof1544kbps.Thedelayvariableisthesumofalldelaysalongtheinterfacescrossedinthepathtothedestination,inmicroseconds,dividedby10.Therefore,thedelayvariableusedinIGRPmetricequationhastheunitoftensofmicroseconds.Likethebandwidthvariable,thedelayassociatedwitheachinterfaceisastaticvalueassignedbytherouteroranetworkadministrator;itisnotadynamicvaluethatchangeswithdifferenttrafficpattern.Table4-1listsrouterdefaultbandwidthanddelayvaluesforsomecommoninterfaces.

Table4-1RouterDefaultBandwidthandDelayValuesforCommonInterfaces

IGRPmetriccalculationisillustratedinthefollowingexample.ConsiderthenetworkinFigure4-1.

Figure4-1IGRPMetricCalculationExample

NowcalculatetheIGRPmetrictoNetworkXfromRouter3’sperspective.ThelowestbandwidthtoNetworkXistheT1linkwithatotaldelayof21,100microseconds(100microseconds+20,000microseconds+1000microseconds).AssumethatalltheKconstantvaluesaredefaultvalues.Therefore,onlythebandwidthanddelayvaluesareconsideredincalculatingtheIGRPmetric.BW=107/1544=6476andDelay=21,100/10=2110.ThisyieldsIGRPmetric=BW+Delay=6476+2110=8586.Therefore,fromRouter3’sperspective,theIGRPmetrictoNetworkXis8586.

TimersBecauseIGRPisadistancevectorprotocolinwhichroutingupdatesaresentperiodically,thedifferenttimersareespeciallyimportantbecausetheycontrolhowfasttheroutesarelearnedanddeleted.Ultimately,thesetimersdeterminethenetworkconvergencetime,whichisthetimethatittakesforalltheroutersinthenetworktorealizethatacertainnetworkhasbeenaddedordeleted.TheIGRPtimersarethesameasRIP;theyarediscussedinthislist:•Update—IGRPsendsupdatesoverthebroadcastaddressof255.255.255.255,withIPprotocolnumber9.Theupdatetimeristheperiodictimerinwhichroutingupdatesaresent;itisthetimebetweeneachroutingupdateinterval.Thisvalueissetto90seconds,bydefault,andisconfigurable.Inotherwords,theroutersendsitsentireroutingupdatesevery90seconds,bydefault.•Invalid—Whentherouterstopsreceivingroutingupdateswithintheinvalidtimer,theroutesbecomeinvalid.Thisissetto270seconds,bydefault.•Holddown—Thisisthetimeusedtosuppressthedefectiveroutestobeinstalledintheroutingtable.Thedefaulttimeis280seconds.•Flush—Thisisthetimewhentherouteisremovedfromtheroutingtable.Thisissetto630seconds,bydefault.

ThedefaultvaluefortheIGRPupdatetimeris90seconds,comparedtothedefaultof30secondsfortheRIPupdatetimer.ThisallowsIGRPtouselessbandwidthforperiodicupdates;however,thetrade-offisthatIGRPhasaslowerconvergencetimethanRIP.Allthetimersmentionedhereareconfigurable.The

commandtochangethetimeristimersbasicupdateinvalidholddownflush.However,changingthetimerononlyonerouterinthenetworkcouldresultinanetworkconvergenceproblem.Changingthetimersisnotrecommended.Ifthenetworkchanges,suchasafterdeletingoraddinganetwork,IGRPandRIPuseFlashupdates.Inotherwords,IGRPandRIPsendinstantupdatestoalltheirneighborsassoonasanetworkchangeisdetected.Forexample,ifarouter’sEthernetinterfacegoesdown,therouterimmediatelysendsaFlashupdatetoitsneighborsthatitsEthernetnetworkisnolongeravailable.AfterreceivingtheFlashupdate,theneighborsimmediatelyputtheEthernetnetworkintoholddownstate.

SplitHorizonSplithorizonisatechniqueusedtoavoidroutingloops.Withsplithorizon,therouterdoesnotadvertisearouteovertheinterfaceinwhichtherouteislearnedfrom.Forexample,inFigure4-1,Router1receivesanupdateaboutNetworkXfromRouter2overtheserialinterface.Ifsplithorizonisenabled,Router2willnotadvertisetheNetworkXroutebacktoRouter1overthesameserialinterface.Ifsplithorizonisdisabled,Router2willadvertiseNetworkXbacktoRouter1.WhenNetworkXbecomesunavailableinRouter2,Router2believesthatRouter1stillhasavalidroutetoNetworkXandsendsthepacketdestinedtoNetworkXtowardRouter1,whichwillbedropped.

SplitHorizonwithPoisonReverseAnothertechniquetoavoidroutingloopissplithorizonwithpoisonreverse.Usingthistechnique,routeslearnedonaninterfaceareadvertisedbackonthesameinterfacewithanIGRPmetricofinfinity.Thisiscalledpoisonupdate.Whentherouterreceivesthepoisonupdate,itconsiderstherouteasinvalid.Forexample,inFigure4-2,Router1receivesanupdateforNetworkXfromRouter2.Withpoisonreverse,thisspecificrouteisadvertisedbacktoRouter2,butwithanIGRPmetricof4,294,967,295,whichindicatesinfinity.BecauseRouter2receivesthepoisonupdatefromRouter1,Router2doesnotconsiderRouter1asavalidpathtoreachNetworkX,thuspreventingthepossibilityofaroutingloop.

Figure4-2AnExampleoftheSplitHorizonTechnique

IGRPPacketFormatFigure4-3showstheIGRPpacketformat.Inthisfigure,youcanseethatIGRPupdatesprovidemoreinformationthanRIPand,atthesametime,aremoreefficient.NoneofthefieldsinanIGRPpacketisleftunused;afterthe12-octetheader,eachroutingentryisfilledoneafteranother.Therefore,IGRPdoesnotpadtheupdatepackettoforcea32-bitwordboundary.Withthisefficientdesign,IGRPcancarryamaximumof104fourteen-octetentries.Therefore,withitsMTUsizeof1500bytes,IGRPcancarrymoreroutesperpacketthanRIPcan.

Figure4-3IGRPPacketFormat

IGRPBehaviorDistancevectorprotocolsareprotocolsthatsolelydependonneighborroutingadvertisementstodeterminethebestpathtoadestination.Theadvantageofthedistancevectorprotocolsistheirsimplicitytoimplement.However,becauseofthelongconvergencetime,IGRPisnotsuitableforlargenetworks.IGRPandRIParebothclassicaldistancevectorprotocols.AlthoughIGRPandRIPdifferinmetriccalculationupdatetimers,theyexhibitthesamebehaviorwhenitcomestosendingandreceivingupdates.IGRPsendsitsentireroutingupdateoverthebroadcastaddressof255.255.255.255,withtheIPProtocolfieldsetto9.IGRPhandlesdiscontiguousnetworkandvariable-lengthsubnetmasking(VLSM)inexactlythesamewaythatRIPdoes.IGRPdoesnotsupportdiscontiguousnetworks;inthesenetworks,IGRPautosummarizesoveramajornetworkboundary.Therefore,thesubnetinformationisnotadvertisedtotheremotesite,causingroutingproblems.BecauseIGRPdoesnotsendsubnetmaskinformationaspartoftheroutingupdate,IGRPdoesnotsupportVLSM.

DefaultRouteandIGRPInCiscorouters,IGRPdoesnotrecognizethe0.0.0.0/0routeasthedefaultroute.Itusesitsownmethodofpropagatingdefaultroutewiththeipdefault-networkcommand.Theipdefault-networkcommandspecifiesamajornetworkaddressandflagsitasadefaultnetwork.Thismajornetworkcouldbedirectlyconnected,definedbyastaticroute,ordiscoveredbyadynamicroutingprotocol.Thenetworkspecifiedbytheipdefault-networkcommandmustbeintheroutingtablebeforethecommandtakeseffect.Iftheroutespecifiedisnotintheroutingtable,nodefaultroutewillbepropagated.Figure4-4demonstrateshowtheipdefault-networkcommandworks.

Figure4-4PropagatingaDefaultRouteforIGRP

InFigure4-4,Router1isconnectedtotheremotesitethroughaDS-3link.Router1nowwantstosendadefaultroutetoRouter2andtoalltheroutersintheremotesitenetwork.InIGRP,therouteto0.0.0.0isnotrecognizedasadefaultroute;instead,Router1mustconfigureipdefault-network192.168.1.0toflagtheroute192.168.1.0asthedefaultroute.Router1willsendaroutingupdateof192.168.1.0andwillflagitasadefaultroute.Whentheroutersintheremotesitenetworkreceivetheupdatefor192.168.1.0,theywillmarkitasdefaultrouteandwillinstalltherouteto192.168.1.0asthegatewayoflastresort.

Unequal-CostLoadBalancinginIGRPIGRPandRIPprovidethecapabilitytoinstalluptosixparallelequal-costpathsforloadbalancing.IGRPhasanaddedfeaturethatRIPdoesnothave—thecapabilitytodounequal-costloadbalancing,thecapabilitytoload-balancetrafficovermultiplepathsthatdonothavethesamemetrictothedestination.Theadvantageofthisfeatureisthatitofferstheflexibilityofloadbalancing,thusmakingmoreefficientuseofthelink.IGRPusesthevariancecommandtoperformunequal-costloadbalancing.Beforeunequal-costloadbalancingcantakeplace,however,tworulesmustapply:10Theneighboringrouterutilizedasanalternatepathwaymustbeclosertothedestination.(Thatis,theneighboringrouter’smetrictothedestinationmustbeasmallermetricthanthatofthelocalrouterforagivendestination.)

11Themetricadvertisedbytheneighboringroutermustbelessthanthevarianceofthelocalrouter’smetrictothedestination.

Variance=VarianceFactor×LocalMetric

ConsiderthenetworkinFigure4-5.

Figure4-5Unequal-CostLoadBalancingExample

WhenRouter1calculatesitsIGRPmetricstoRouter3,themetricgoingthroughthe1544kbpslinkisasfollows:

IGRPmetric=6476+2100=8576

Themetricgoingthroughthe256kbpslinkisasfollows:

IGRPmetric=3902(3902)+2100=41,162

Withoutunequal-costloadbalancing,IGRPwillsimplyselectthe1544kbpslinktoforwardpacketstoRouter3,asshownintheoutputinExample4-1.Example4-1OutputofRoutingTableinRouter1WithoutUnequal-CostLoadBalancing

Router_1#showiproute133.33.0.0Routingentryfor133.33.0.0/16Knownvia"igrp1",distance100,metric8576Redistributingviaigrp1Advertisedbyigrp1(selforiginated)Lastupdatefrom192.168.6.2onSerial0,00:00:20agoRoutingDescriptorBlocks:*192.168.6.2,from192.168.6.2,00:00:20ago,viaSerial0Routemetricis8576,trafficsharecountis1Totaldelayis21000microseconds,minimumbandwidthis1544KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops0

Tousetheunequal-costloadbalancingfeatureofIGRP,youusethevariancecommand.Varianceisamultiplierinwhichametricmightbedifferentfromthelowestmetrictoaroute.Thevariancevaluemustbeofintegervalue;thedefaultvariancevalueis1,meaningthatthemetricsofmultipleroutesmustbeequaltoload-balance.InExample4-1,themetricthroughthe256kbpslinkis4.8timeslargerthanthemetricthroughthe1544kbpslink.Therefore,forthe256kbpslinktobeconsideredintheroutingtable,avarianceof5mustbeconfiguredinRouter1.TheconfigurationinRouter1issimplyvariance5undertheigrpcommand.TheoutputfromtheshowiproutecommandinExample4-2displaysthatRouter1isinstallingbothlinksinitsroutingtable.Example4-2OutputofshowiprouteinRouter1AfterImplementingUnequal-CostLoadBalancingbyAddingthevarianceCommand

Router_1#showiproute133.33.0.0Routingentryfor133.33.0.0/16Knownvia"igrp1",distance100,metric8576

Redistributingviaigrp1Advertisedbyigrp1(selforiginated)Lastupdatefrom10.1.1.2onSerial1,00:01:02agoRoutingDescriptorBlocks:*192.168.6.2,from192.168.6.2,00:01:02ago,viaSerial0Routemetricis8576,trafficsharecountis5Totaldelayis21000microseconds,minimumbandwidthis1544KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops010.1.1.2,from10.1.1.2,00:01:02ago,viaSerial1Routemetricis41162,trafficsharecountis1Totaldelayis21000microseconds,minimumbandwidthis256KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops0

NoticeinExample4-2thattheroutethroughSerial0hasatrafficsharecountof5,comparedtoatrafficsharecountof1throughSerial1.ThisindicatesthattherouterwillsendfivepacketsoverSerial0foreverypacketsentoverSerial1.

SummaryIGRPisadistancevectorroutingprotocol,likeRIP.ItwasdevelopedasasolutiontosomeofthedisadvantagesofRIP,suchasitshop-countlimitationandfrequentupdatetimer.UnlikeRIP,IGRPusesbandwidthanddelayastheprimaryvariablesincalculatingitsmetrics.BecauseIGRPandRIPareconsideredclassicaldistancevectorroutingprotocols,someoftheirbehaviorisexactlythesame.Asaresult,neitherIGRPnorRIPcansupportdiscontiguousnetworksandVLSM.However,oneofthebiggestadvantagesofIGRPoverRIPisthecapabilitytodounequal-costloadbalancing.

ReviewQuestions1WhatisthedefaultupdatetimerperiodforIGRP?2WhatvariablesdoesIGRPusetocalculateitsmetricsbydefault?3WhataretheKvaluesintheIGRPmetricequation?4WhatcommandisusedinIGRPtoperformunequal-costloadbalancing?5Whatissplithorizon?DoesIGRPsupportthisfeature?6DoesIGRPsupportVLSM?

Chapter5.TroubleshootingIGRP

Thischaptercoversthefollowingkeytopics:•TroubleshootingIGRProuteinstallation•TroubleshootingIGRProuteadvertisement•TroubleshootingIGRPredistributionproblems•Troubleshootingdial-on-demand(DDR)routingissuesinIGRP•TroubleshootingrouteflappinginIGRP•Troubleshootingvarianceproblem

ThischapterdiscussescommonproblemsinIGRPnetworksandhowtosolvethoseproblems.IGRPisaCiscoproprietaryprotocol.IGRPfixessomeoftheproblemswithRIP,butstillithassimilarcharacteristicsasRIP.IGRPalsodoesnotsupportdiscontiguousnetworksorVLSM;however,itdoeshavegoodfeatures,suchasvariance,anditsmetricisbasedonbandwidthanddelayinsteadofhopcount.MostoftheissuesinIGRPareverysimilartoRIP,sothoseissuesarerepeatedhereagaininthischapterfromanIGRPperspective.AsmentionedinChapter3,“TroubleshootingRIP,”youmustbecarefulwiththedebugswhendealingwithlargenetworks(forexample,morethan100subnetsinanetwork)becausedebuggingsometimescanhaveanadversarialeffectonarouter.TheflowchartsthatfollowdocumenthowtoaddresscommonproblemswithIGRPwiththemethodologyusedinthischapter.

FlowchartstoSolveCommonIGRPProblems

TroubleshootingIGRPRouteInstallationThissectiondiscussesthemostcommonscenariosthatcanpreventIGRProutesfromgettinginstalledintheroutingtable.ThisisthemostusefulsectioninthischapterbecausethemostcommonprobleminIGRPisthatroutesarenotintheroutingtable.Ifaspecificdestinationisnotintheroutingtable,thepacketdestinedforthataddresswillbedropped.Theeasiestwaytofindoutwhetheraspecificrouteisintheroutingtableiswiththeshowiproutex.x.x.xcommand,wherex.x.x.xisthespecificdestination(thatis,anIPaddressofahostoraserver).Threepossiblesourcesexistforproblemswhenroutesdonottogetinstalledintheroutingtable:•Receiverproblem•Intermediatemediaproblem(Layer2)•Senderproblem

Receiverproblemsrefertowhentheroutingupdatewassentbythesender.Becauseofsomeproblemsatthereceiver’send,thereceivingroutercannotinstalltheroutesintheroutingtable.Intermediatemediaproblemsactuallyrefertoanymediumthatisinthemiddleoftworoutersexchangingroutingupdates.Inthiscase,thesenderalreadyhassenttheroutingupdate,butthereceivingrouterneverreceiveditbecausethemediuminthemiddleisexperiencingsomekindofproblem.Therecouldbevariousformsofmedia,fromasimplehubtoacomplexswitch.Thesender’sproblemreferstoaninstanceinwhichtheroutingupdatesareneversentbythesender,sothereceivingrouterneverreceivestheroutingupdates.Thesender’sproblemisdiscussedinthesection“TroubleshootingIGRPRoutesAdvertisement.”TwoproblemsexistinIGRProutesinstallation:•IGRProutesarenotintheroutingtable.•IGRPisnotinstallingallequal-cost-pathroutes.

Inthefirstcase,IGRPisnotinstallingaparticularrouteorisnotinstallinganyroutesintheroutingtable.However,inthesecondcase,therearesomeroutesintheroutingtableforaparticulardestination,butsomeoftheroutesarenotbeinginstalled.Thesetwoproblemsarediscussedindetailinthesectionsthatfollow.

Problem:IGRPRoutesNotintheRoutingTableForaroutertosendthepacketstoaparticulardestination,theroutermusthavearoutingentryforthatdestinationsubnetintheroutingtable.Iftherearenoentriesintheroutingtable,thepacketwillbedropped.

Example5-1showsthattheroutingtableentryofR2doesnotproduceanyIGRProutesforaparticulardestinationof131.108.2.0.Example5-1R2RoutingTableShowsNoIGRPRoutefor131.108.2.0

R2#showiproute131.108.2.0%SubnetnotintableR2#

Themostcommonpossiblecausesofthisproblemareasfollows:•networkstatementismissingorincorrect.•Layer2isdown.•Thedistributelistisblockingtheroute.•TheaccesslistisblockingtheIGRPsourceaddress.•TheaccesslistisblockingtheIGRPbroadcast.•Thisisadiscontiguousnetwork.•Thesourceisinvalid.•ALayer2problem(switch,FrameRelay,orotherLayer2medium)hasoccurred.•AsenderASmismatchhasoccurred.•Asender’sproblemhasoccurred(discussedinthe“TroubleshootingIGRPRoutesAdvertisement”section).

Figure5-1showsthesetupinwhichRouter1andRouter2arerunningIGRPinbetween.

Figure5-1ExampleTopologyforthe“IGRPRoutesNotintheRoutingTable”ProblemIGRPRoutesNotintheRoutingTable—Cause:MissingorIncorrectnetworkStatement

SeveralreasonsexistforIGRProutesnotbeingintheroutingtable.Theonediscussedhereisamissingorincorrectnetworkstatementintherouter’sconfiguration.Othercausesarementionedatthebeginningofthissection.Justglancingthroughtheflowchartmighttellyouthecausethatfitsyourproblemthemost.Inthecaseofawrongormissingnetworkstatement,IGRPwillnotbecapableofreceivinganyupdatesonaparticularinterface.RecallfromChapter3thatanetworkstatementhastwopurposes:•ToenableIGRPontheinterfaceforsendingandreceivingIGRProutes•ToadvertisethatnetworkinIGRPupdates


Figure5-2Problem-ResolutionFlowchartDebugsandVerification

Example5-2showstheconfigurationforRouterR2.Pleasenotethattheloopbackinterfaceisusedinthisexampleandmanyotherexamplesthroughoutthischapter.Iftheloopbackinterfaceisreplacedwithanyotherinterface,itwillnotchangethemeaning.YoushouldtreattheloopbackasanyinterfacethatisupandfunctionalandthathasavalidIPaddress.Example5-2R2Configuration

interfaceLoopback0ipaddress131.108.3.1255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0!routerIGRP1network131.107.0.0

Thenetwork131.108.0.0statementismissingfromR2’sconfiguration.Example5-3showstheoutputoftheshowipprotocolscommand,whichindicatesthattheroutinginformationsourcealsoisnotdisplaying131.108.1.1asagateway.Agatewayisanext-hopaddressfromwhichroutingupdatesarereceived.Ifthereisnoentryunderthegateway,eithernothingisbeingreceivedornothingisbeinginstalledfromthatneighbor.Example5-3showipprotocolsCommandOutputonR2

R2#showipprotocolRoutingProtocolis"IGRP1"Sendingupdatesevery30seconds,nextduein82secondsInvalidafter270seconds,holddown280,flushedafter630OutgoingupdatefilterlistforallinterfacesisIncomingupdatefilterlistforallinterfacesis

DefaultnetworksflaggedinoutgoingupdatesDefaultnetworksacceptedfromincomingupdatesIGRPmetricweightK1=1,K2=0,K3=1,K4=0,K5=0IGRPmaximumhopcount100IGRPmaximummetricvariance1Redistributing:igrp1RoutingforNetworks:131.107.0.0RoutingInformationSources:GatewayDistanceLastUpdateDistance:(defaultis100)

Example5-4showsthedebugippacket100detailoutput.Inthisdebug,R2isreceivingtheIGRPpacketsbutisignoringthembecauseIGRPisnotenabledonE0interface.Notethatprotocol9isreservedforIGRP.Thisisbecausenonetworkstatementfor131.108.0.0existsunderrouterigrp1.Example5-4debugippacket100detailCommandOutputonR2

R2#debugippacket100detailIP:s=131.108.1.1(Ethernet0),d=255.255.255.255,len32,rcvd2,proto=9

R2#showdebugGenericIP:IPpacketdebuggingison(detailed)foraccesslist100IProuting:IGRPprotocoldebuggingisonIGRPeventdebuggingison

R2#showaccess-list100ExtendedIPaccesslist100permitipanyhost255.255.255.255(3matches)

Solution

Whenconfigured,thenetworkstatementdoestwothings:•EnablesIGRPontheinterfacetosendandreceiveIGRPupdates•AdvertisesthatnetworkinIGRPupdatepackets

BecausethenetworkstatementismissingonRouter2,therouterignoresIGRPupdatesarrivingontheEthernet0interface,asseeninthedebugoutput.Thisproblemalsocanhappenifyouincorrectlyconfigurethenetworkstatement.Forexample,insteadofconfiguring209.1.1.0,youconfigure209.1.0.0assumingthat0willcoveranythinginthethirdoctet.IGRPisaclassfulprotocolandassumesthatthenetworkstatementsareclassfulaswell.Ifaclasslessstatementisconfiguredinstead,IGRPwillnotfunctionproperly.Tocorrectthisproblem,youmustaddaproperlyconfigurednetworkstatementintheconfiguration.Example5-5showsthenewconfigurationforRouterR2thatsolvesthisproblem.Example5-5AddinganetworkStatementtoR2toPopulatetheRoutingTablewithIGRPRoutes

interfaceLoopback0ipaddress131.108.3.2255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0!routerigrp1nonetwork131.107.0.0

network131.108.0.0

Example5-6showstheoutputofshowipprotocolsonR2,whichdisplaysthegatewayinformationafterinsertingthepropernetworkstatement.Example5-6showipprotocolsCommandOutputonR2AfterCorrectednetworkStatement

R2#showipprotocolsRoutingProtocolis"IGRP1"Sendingupdatesevery30seconds,nextduein82secondsInvalidafter270seconds,holddown280,flushedafter630OutgoingupdatefilterlistforallinterfacesisIncomingupdatefilterlistforallinterfacesisDefaultnetworksflaggedinoutgoingupdatesDefaultnetworksacceptedfromincomingupdatesIGRPmetricweightK1=1,K2=0,K3=1,K4=0,K5=0IGRPmaximumhopcount100IGRPmaximummetricvariance1Redistributing:igrp1RoutingforNetworks:131.108.0.0RoutingInformationSources:GatewayDistanceLastUpdate131.108.1.110000:00:09Distance:(defaultis100)

Example5-7showstheoutputofshowiproute,whichshowsthatRouterR2islearningtheIGRProuteaftertheconfigurationchange.Example5-7showiprouteCommandOutputConfirmsThatR2IsLearningtheIGRPRoute

R2#showiproute131.108.2.0Routingentryfor131.108.2.0/24Knownvia"igrp1",distance100,metric8976Redistributingviaigrp1Advertisedbyigrp1(selforiginated)Lastupdatefrom131.108.1.1onEthernet0,00:00:12agoRoutingDescriptorBlocks:*131.108.1.1,from131.108.1.1,00:00:12ago,viaEthernet0Routemetricis8976,trafficsharecountis1Totaldelayis25000microseconds,minimumbandwidthis1544KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops0

IGRPRoutesNotintheRoutingTable—Cause:Layer1/2IsDown

OneofthecausesforroutesnotbeinginstalledintheroutingtableisthatLayer1orLayer2isdown.Ifthisisthecase,itisnotaRIPproblem.Layer1or2couldbedownforseveralreasons.Thefollowingisthelistofmostcommonthingtocheckifaninterfaceorlineprotocolisdown:•Unpluggedcable•Loosecable•Badcable•Badtransceiver•Badport•Badinterfacecard

•Layer2problematthetelcoincaseofaWANlink•Missingclockstatementincaseofback-to-backserialconnection


Figure5-3ProblemResolutionFlowchartDebugsandVerification

TheoutputinExample5-8indicatesthattheEthernetinterface’slineprotocolisdown,whichisasignthatthereissomethingwrongatLayer2.Example5-8showinterfacesCommandOutputRevealsThattheLineProtocolIsDown

R2#showinterfacesethernet0Ethernet0isup,lineprotocolisdownHardwareisLance,addressis0000.0c70.d41e(bia0000.0c70.d41e)Internetaddressis131.108.1.2/24

Example5-9showstheoutputofdebugipigrpeventsanddebugipigrptransaction.TheoutputshowsthatR2isnotsendingorreceivinganyIGRPupdatesbecauseLayer2isdown.Example5-9debugipigrpeventsanddebugipigrptransactionCommandOutputRevealsThatR2IsNotSendingorReceivingIGRPUpdates

R2#debugipigrpeventsIGRPeventdebuggingisonR2#debugipigrptransactionIGRPprotocoldebuggingison

R2#showdebugIProuting:IGRPprotocoldebuggingisonIGRPeventdebuggingison

Solution

IGRPrunsaboveLayer2.IGRPcannotsendorreceiveanyroutesifLayer2isdown.Tocorrectthisproblem,youmustfixtheLayer2problem.Theproblemcouldbeassimpleasloosecables,oritcouldbeascomplexasbadhardware,inwhichcasethehardwaremustbereplaced.Example5-10showstheoutputofshowinterfacesethernet0afterfixingtheLayer2problem.Example5-10showinterfacesethernet0CommandOutputAfterRestoringLayer2Connectivity

R2#showinterfacesethernet0Ethernet0isup,lineprotocolisupHardwareisLance,addressis0000.0c70.d41e(bia0000.0c70.d41e)Internetaddressis131.108.1.2/24

Example5-11showstheoutputofshowipprotocols,whichalsoshowsthattheproblemisfixed.Example5-11showipprotocolsCommandOutputVerifiesThattheGatewayIsRestoredAfterFixingLayer2Connectivity

R2#showipprotocolsRoutingProtocolis"IGRP1"Sendingupdatesevery30seconds,nextduein82secondsInvalidafter270seconds,holddown280,flushedafter630OutgoingupdatefilterlistforallinterfacesisIncomingupdatefilterlistforallinterfacesisDefaultnetworksflaggedinoutgoingupdatesDefaultnetworksacceptedfromincomingupdatesIGRPmetricweightK1=1,K2=0,K3=1,K4=0,K5=0IGRPmaximumhopcount100IGRPmaximummetricvariance1Redistributing:igrp1RoutingforNetworks:131.108.0.0RoutingInformationSources:GatewayDistanceLastUpdate131.108.1.110000:00:09Distance:(defaultis100)

Example5-12showstheoutputofshowiproute,whichshowsthattheIGRProuteisbeinglearned.Example5-12showiprouteCommandOutputVerifiesThattheIGRPRouteIsBeingLearned


IGRPRoutesNotintheRoutingTable—Cause:distribute-listinIsBlockingtheRoute

Adistributelistisafilteringmechanismforroutingupdates.Adistributelistcallsanaccesslistandcheckswhichnetworksaresupposedtobepermitted.Iftheaccesslistdoesnotcontainanynetwork,it

willbeautomaticallydenied.Adistributelistcanbeappliedonincomingroutingupdatesoroutgoingroutingupdates.Inthisexample,distribute-listinisconfigured,butbecausetheaccesslistdoesnotcontainthepermitstatementfor131.108.0.0,R2isnotinstallingthisrouteintheroutingtable.Figure5-4showstheflowcharttofollowtosolvethisproblem.


Example5-13showsthecurrentconfigurationofRouterR2.Intheaccesslistconfiguration,thenetwork131.108.0.0isnotexplicitlypermitted(and,therefore,isdenied),sotherouterisnotinstallinganysubnetsofthe131.108.0.0network.Example5-13R2AccessListConfigurationDoesNotPermitRoutesfromthe131.108.0.0Network

interfaceLoopback0ipaddress131.108.3.2255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0!routerigrp1network131.108.0.0distribute-list1in!access-list1permit131.107.0.00.0.255.255

Solution

Whenusingadistributelist,youshouldalwaysdouble-checkyouraccesslisttomakesurethatthenetworksthataresupposedtobepermittedactuallyarepermittedintheaccesslistdefinition.InExample5-13,theaccesslistispermittingonlyroutesfrom131.107.0.0.Allotherroutesaredeniedbytheimplicitdenyattheendofeachaccesslist.Tofixthisproblem,explicitlypermit131.108.0.0inaccess-list1.

Example5-14showsthenewconfigurationofRouterR2withthecorrectaccesslist.Example5-14Reconfiguringaccess-list1toPermitRoutesfromNetwork131.108.0.0

interfaceLoopback0ipaddress131.108.3.2255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0!routerigrp1network131.108.0.0distribute-list1in!noaccess-list1permit131.107.0.00.0.255.255access-list1permit131.108.0.00.0.255.255

Example5-15showsthatRouterR2islearningIGRProutesaftertheconfigurationchange.Example5-15showiprouteCommandOutputRevealsThattheChangetoaccess-list1WasSuccessful

R2#showiproute131.108.2.0Routingentryfor131.108.2.0/24Knownvia"igrp1",distance100,metric8976Redistributingviaigrp1Advertisedbyigrp1(selforiginated)Lastupdatefrom131.108.1.1onEthernet0,00:00:12agoRoutingDescriptorBlocks:131.108.1.1,from131.108.1.1,00:00:12ago,viaEthernet0Routemetricis8976,trafficsharecountis1Totaldelayis25000microseconds,minimumbandwidthis1544KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops0

IGRPRoutesNotintheRoutingTable—Cause:AccessListBlockingIGRPSourceAddress

Accesslistsareusedtofilterthetrafficbasedonthesourceaddress.Extendedaccesslistsareusedtofilterthetrafficbasedonsourceordestinationaddress.Theseaccesslistscanbeappliedontheinterfacewiththeinterface-levelcommandipaccess-group{access-listnumber}{in|out}tofiltertheincomingandoutgoingtraffic.WhentheaccesslistisappliedinanIGRPenvironment,alwaysmakesurethatitdoesnotblockthesourceaddressoftheIGRPupdate.Inthisexample,R2isnotinstallingIGRProutesintheroutingtablebecauseaccess-list1isnotpermittingthesourceaddressofIGRPupdatesfromR1.Figure5-5showstheflowcharttofollowtosolvethisproblem.


Example5-16showsthecurrentconfigurationofRouterR2.Thesourceaddressof131.108.1.1isnotbeingpermittedintheaccesslist.Becausetheonlypermitstatementintheaccesslistis131.107.0.0,thesourceaddressofRIP,131.108.0.0,willbeimplicitlydenied.Example5-16CurrentConfigurationofRouterR2

R2#interfaceLoopback0ipaddress131.108.3.2255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0ipaccess-group1in!routerigrp1network131.108.0.0!access-list1permit131.107.0.00.0.255.255

Example5-17showstheoutputofdebugipigrpeventsanddebugipigrptransaction.Inthisdebug,IGRPisonlysendingtheupdatesandisnotreceivinganythingbecausethesourceaddress,131.108.1.1,isnotpermittedintheinputaccesslistofR2.Thisisalsoshowninthedebugippacket100detailoutput,whereaccess-list100specificallylooksatthesourceaddressof131.108.1.1Example5-17debugCommandOutputShowingThatIGRPUpdatesAreSentandNotReceived

R2#debugippacket100detailIP:s=131.108.1.1(Ethernet0),d=255.255.255.255,len46,accessdenied,proto=9R2#

R2#showdebug

GenericIP:IPpacketdebuggingison(detailed)foraccesslist100IProuting:IGRPprotocoldebuggingisonIGRPeventdebuggingison

IGRP:sendingupdateto255.255.255.255viaEthernet0(131.108.1.2)subnet131.108.3.0,metric=501IGRP:Updatecontains1interior,0system,and0exteriorroutes.IGRP:Totalroutesinupdate:1R2#showaccess-list100ExtendedIPaccesslist100permitiphost131.108.1.1host255.255.255.255R2#

Solution

Thestandardaccesslistspecifiesthesourceaddress.Inthiscase,thesourceaddressis131.108.1.1.Thissourceaddressisnotpermittedinthestandardaccesslist,soIGRProuteswillnotgetinstalledintheroutingtableofR2.Tosolvethisproblem,permitthesourceaddressinaccess-list1.Example5-18showsthenecessaryconfigurationchangestofixthisproblem.Example5-18FixingtheAccessListtoPermittheIGRPUpdateSourceAddress

R2#interfaceLoopback0ipaddress131.108.3.2255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0ipaccess-group1in!routerigrp1network131.108.0.0!noaccess-list1permit131.107.0.00.0.255.255access-list1permit131.108.1.1

Example5-19showstheconfigurationsincaseofanextendedaccesslist.ThisproblemalsocanhappenwhenusingextendedaccesslistsandwhentheIGRPsourceaddressisnotpermittedintheaccesslist.Thissolutionalsocanbeusedincaseofextendedaccesslist.TheideahereistopermitthesourceaddressoftheIGRPupdate.Example5-19FixingtheExtendedAccessListtoPermittheIGRPUpdateSourceAddress

access-list100permitip131.107.0.00.0.255.255anyaccess-list100permitiphost131.108.1.1any

Afterchangingtheaccesslist,standardorextended,andpermittingthesourceaddressoftheneighborthatissendingtheIGRProutingupdates,R2willstartacceptingandinstallingtheIGRPupdates.Example5-20showstheroutingtableentryofRouterR2,whichshowsthatitislearningIGRProutesaftertheconfigurationchangeoftheaccesslist.Example5-20R2’sRoutingTableVerifiesThatR2ReceivesIGRPRoutesAfterFixingtheAccessLists


IGRPRoutesNotintheRoutingTable—Cause:AccessListBlockingIGRPBroadcast

Accesslistsareusedforthefilteringpurpose.Whenusedontheinboundinterface,alwaysmakesurethatitisnotblockingIGRPbroadcast,whichisusedforIGRProutingupdates.Ifthisbroadcastaddressisnotpermittedintheaccesslistthatisappliedontheinterfaceinbound,IGRPwillnotinstallanyroutesintheroutingtablelearnedonthatinterface.Figure5-6showstheflowcharttofollowtosolvethisproblem.


Example5-21showsthecurrentconfigurationofR2.Inthisconfiguration,theIGRPdestinationaddressof255.255.255.255isnotbeingpermitted;asaresult,noIGRProutesarebeinginstalledinR2.Theaccess-group100incommandisconfiguredundertheEthernet0interfaceofR2.Thisfilteractuallyiscallingaccess-list100.Ifyoulookataccess-list100,itisactuallydenyingtheincomingbroadcastaccessonEthernet0interfacebecausethereisanimplicitdenyattheendofeachaccesslist.ThisblockstheIGRPupdates,andR2willnotinstallanyIGRProutes.Example5-21R2’sConfigurationDoesNotPermittheIGRPBroadcastAddressof255.255.255.255

R2#interfaceLoopback0ipaddress131.108.3.2255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0ipaccess-group100in!routerigrp1network131.108.0.0!access-list100permitip131.107.0.00.0.255.255anyaccess-list100permitiphost131.108.1.1host131.108.1.2

Solution

IGRPbroadcastsitsroutingupdateson255.255.255.255.Thisaddressmustbepermittedintheinputaccesslistofthereceivingrouter.Example5-22showsthenewconfigurationforRouterR2.Example5-22ReconfiguringRouterR2toPermittheIGRPBroadcastAddress

interfaceLoopback0ipaddress131.108.3.2255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0ipaccess-group1in!routerigrp1network131.108.0.0!access-list100permitip131.107.0.00.0.255.255anyaccess-list100permitiphost131.108.1.1host131.108.1.2access-list100permitiphost131.108.1.1host255.255.255.255

Example5-23showstheroutingtableentryofR2aftercorrectingtheproblem.Example5-23R2’sRoutingTableShowsThattheIGRPBroadcastAddressIsNowPermitted


IGRPRoutesNotintheRoutingTable—Cause:DiscontiguousNetwork

Thedefinitionofadiscontiguousnetworkisoneinwhichtwosubnetsbelongingtothesamemajornetworkareseparatedbyanetworkorasubnetworkbelongingtoanothermajornetwork.Chapter4,“UnderstandingInteriorGatewayRoutingProtocol(IGRP),”providesadetaileddescriptionofwhydiscontiguousnetworksarenotsupportedinIGRP.

Figure5-7showsanexampleofadiscontiguousnetworkinwhich137.99.0.0isamajornetwork.Thesubnetsofthismajornetworkareseparatedbyanothermajornetwork,131.108.0.0.Thissituationproducesadiscontiguousnetworkproblem.

Figure5-7SampleDiscontiguousNetwork



Example5-24showstheconfigurationofRoutersR1andR2.IGRPisenabledontheEthernetinterfacesofR1andR2withthecorrectnetworkstatements.Example5-24R1andR2ConfigurationsIndicateThatIGRPIsEnabledontheEthernetInterfaces

R2#interfaceLoopback0ipaddress137.99.3.2255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0!routerigrp1network131.108.0.0network137.99.0.0!

R1#interfaceLoopback0

ipaddress137.99.2.1255.255.255.0!interfaceEthernet0ipaddress131.108.1.1255.255.255.0!routerigrp1network131.108.0.0network137.99.0.0!

Example5-25showsthedebugipigrptransactionoutputforRoutersR1andR2.Bothdebugsshowthatthenetwork137.99.0.0isbeingsentacross.Example5-25debugipigrptransactionCommandOutputforR1andR2IndicatesThatUpdatesforNetwork137.99.0.0AreBeingSent

R2#debugipigrptransactionIGRPprotocoldebuggingisonR2#IGRP:sendingupdateto255.255.255.255viaLoopback0(137.99.3.2)network131.108.0.0,metric=8476IGRP:sendingupdateto255.255.255.255viaEthernet0(131.108.1.2)network137.99.0.0,metric=501IGRP:receivedupdatefrom131.108.1.1onEthernet0network137.99.0.0,metric8976(neighbor501)R2#

R1#debugipigrptransactionIGRPprotocoldebuggingisonR1#IGRP:sendingupdateto255.255.255.255viaLoopback0(137.99.2.1)network131.108.0.0,metric=8476IGRP:sendingupdateto255.255.255.255viaEthernet0(131.108.1.1)network137.99.0.0,metric=501R1#IGRP:receivedupdatefrom131.108.1.2onEthernet0network137.99.0.0,metric8976(neighbor501)R1#

Solution

IGRPisnotinstallingtheroute137.99.0.0intheroutingtablebecauseIGRPdoesnotsupportdiscontiguousnetworks.AsdiscussedinChapter4,thereareseveralsolutionstothisproblem.Thequicksolutionistoconfigureastaticroutetothemorespecificsubnetsof137.99.0.0oneachrouter.Thisprovideseachroutertheroutesaboutthespecificsubnetsofadiscontiguousmajornet.Othersolutionsareasfollows:•ChangetheaddressonthelinkbetweenR1andR2tobeapartof137.99.0.0.Inotherwords,assignanothersubnetonthislink,whichisapartof137.99.0.0.•Iftheaddresscannotbechanged,runaGREtunnelbetweenR1andR2,andputaseparatesubnetaddresswiththesamemaskonthetunnelinterface,asdemonstrated:

R1#interfacetunnel0ipaddress137.99.1.1255.255.255.0tunnelsourceEthernet0tunneldestination131.108.1.2

R2#

interfacetunnel0ipaddress137.99.1.2255.255.255.0tunnelsourceEthernet0tunneldestination131.108.1.1

•ReplaceIGRPwithanyotherIProutingprotocolthatsupportsdiscontiguousnetworks—forexampleOSPF,ISIS,EIGRP,RIP-2,andsoon.

Discontiguoussubnetsarediscouragedandshouldbeavoidedevenifaprotocolsupportsit.Theydestroythesummarizationcapabilities.Example5-26showstheconfigurationchangethatisrequiredforbothRoutersR1andR2tofixtheproblem.Intheconfigurations,astaticroutehasbeenaddedforthediscontiguoussubnets.Example5-26AddingaStaticRouteasaSolutionforDiscontiguousSubnets

R1#interfaceLoopback0ipaddress137.99.3.2255.255.255.0!interfaceEthernet0ipaddress131.108.1.1255.255.255.0!routerigrp1network131.108.0.0network137.99.0.0!iproute137.99.3.0255.255.255.0131.108.1.2

R2#interfaceLoopback0ipaddress137.99.2.1255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0!routerigrp1network131.108.0.0network137.99.0.0!iproute137.99.2.0255.255.255.0131.108.1.1

Example5-27showstheroutingtableentryofR2afterfixingthisproblem.Example5-27VerifyingThattheIGRPRoutingUpdateProblemCausedbyDiscontiguousNetworksHasBeenResolved


IGRPRoutesNotintheRoutingTable—Cause:InvalidSource

WhenRIPtellstheroutingtabletoinstalltheroute,itperformsasourcevaliditycheck.Thischeckmakessurethatthesourcewheretheupdateiscomingfromisalsoonthesamesubnetofthelocalreceivinginterface.Ifthesourceisnotonthesamesubnetasthelocalinterface,RIPignorestheupdateandwillnotinstallroutesintheroutingtablecomingfromthissourceaddress.Figure5-9showsthenetworkdiagramfortheinvalidsourceproblem.

Figure5-9NetworkwithanInvalidSource

AsFigure5-9illustrates,Router1’sSerial0interfaceisunnumberedtoLoopback0.Router2’sserialinterfaceisnumbered.WhenRouter2receivesanIGRPupdatefromRouter1,itcomplainsaboutthesourcevalidity.Figure5-10showstheflowcharttofollowtosolvethisproblem.


Example5-28showstheconfigurationofbothRoutersR2andR1,whereR1’sSerial0interfaceisunnumberedtoLoopback0andR2’sSerial0interfaceisnumbered.Example5-28R1/R2ConfigurationwithMismatchedNumbered/UnnumberedSerialInterfaces

R2#interfaceLoopback0ipaddress131.108.3.2255.255.255.0!interfaceSerial0ipaddress131.108.1.2255.255.255.0

!routerigrp1network131.108.0.0!

R1#interfaceLoopback0ipaddress131.108.2.1255.255.255.0!interfaceSerial0ipunnumberedLoopback0!routerigrp1network131.108.0.0!

Example5-29showsthedebugipigrptransactionoutput,whichrevealsthatR2isignoringIGRPupdatesfromR1becauseofthesourcevaliditycheckfailure.Example5-29debugipigrptransactionCommandOutputRevealsThatR2IsIgnoringIGRPUpdatefromR1

R2#debugipigrptransactionIGRPprotocoldebuggingisonIGRP:receivedupdatefrominvalidsource131.108.2.1onSerial0R2#

Solution

WhenIGRPtellstheroutingtabletoinstalltheroute,itperformsasourcevaliditycheck.Ifthesourceisnotonthesamesubnetonwhichitreceivedtheupdate,itignorestheupdate.Incaseswhenonesideisnumberedandtheothersideisunnumbered,thischeckmustbeturnedoff.Thisisusuallythecaseindialbackupsituationsinwhichremoteroutersdialintoanaccessrouter.Theaccessrouter’sdialupinterfaceisunnumbered,andallremoteroutersgetanIPaddressassignedontheirdialupinterfaces.Example5-30showsthenewconfigurationchangeonRouterR2tofixthisproblem.Example5-30DisablingtheSourceValidityCheckonR2

R2#interfaceLoopback0ipaddress131.108.3.2255.255.255.0!interfaceSerial0ipaddress131.108.1.2255.255.255.0!routerigrp1novalidate-update-sourcenetwork131.108.0.0!

Example5-31showsthatafterchangingtheconfigurationsofR2,theroutegetsinstalledintheroutingtable.Example5-31showiprouteCommandOutputVerifiesThatR2IsNowReceivingtheIGRPUpdatefromR1’sUnnumberedInterface

R2#showiproute131.108.2.0Routingentryfor131.108.2.0/24

Knownvia"igrp1",distance100,metric8976Redistributingviaigrp1Advertisedbyigrp1(selforiginated)Lastupdatefrom131.108.1.1onSerial0,00:00:12agoRoutingDescriptorBlocks:*131.108.1.1,from131.108.1.1,00:00:12ago,viaSerial0Routemetricis8976,trafficsharecountis1Totaldelayis25000microseconds,minimumbandwidthis1544KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops0

IGRPRoutesNotintheRoutingTable—Cause:Layer2Problem(Switch,FrameRelay,OtherLayer2Media)

Sometimes,broadcastcapabilityisbrokenatLayer2,whichfurtheraffectsLayer3broadcast,andIGRPfailstoworkproperly.TheLayer3broadcastisfurtherconvertedintoaLayer2broadcast.IfLayer2hasproblemsinhandlingLayer2broadcasts,theIGRPupdateswillnotbepropagatedacross.Thedebugshowsthatthebroadcastisbeingoriginatedatoneendbutisnotgettingacross.Figure5-11showsthenetworkdiagramforaFrameRelayproblemwhilerunningIGRP.

Figure5-11TwoRoutersRunningIGRPinaFrameRelayNetwork

InFigure5-11,Router1andRouter2areconnectedbyFrameRelay.(Although,thiscouldbeanyLayer2medium—X.25,Ethernet,FDDI,andsoforth.)Figure5-12showstheflowcharttofollowtosolvethisproblem.


Example5-32showstheoutputofdebugippacketdetail100,whichverifiesthatR1issendingandreceivingIGRPupdateswithoutanyproblem.OnR2,updatesarebeingsentbutarenotreceived.ThismeansthattheIGRPupdateisbeinglostatLayer2.Example5-32debugippacketdetail100CommandOutputShowsThatR1IsSuccessfullySendingIGRPUpdates

R1#showaccess-list100access-list100permitipanyhost255.255.255.255

R1#debugippacket100detailIPpacketdebuggingison(detailed)foraccesslist100R1#IP:s=131.108.1.1(local),d=255.255.255.255(Ethernet0),len46,rcvd2,proto=9IP:s=131.108.1.2(Ethernet),d=255.255.255.255,len46,rcvd2,proto=9

R2#debugippacket100detailIPpacketdebuggingison(detailed)foraccesslist100R2#IP:s=131.108.1.2(local),d=255.255.255.255(Ethernet0),len46,rcvd2,proto=9IP:s=131.108.1.2(local),d=255.255.255.255(Ethernet0),len46,rcvd2,proto=9

Solution

IGRPsendsupdatesonabroadcastaddressof255.255.255.255.IfthisaddressgetsblockedatLayer2,IGRPwillnotfunctionproperly.TherootoftheLayer2problemcouldresultfromasimpleEthernetswitch,FrameRelaycloud,bridgingcloud,andsoon.FixingtheLayer2problemisbeyondthescopeofthisbook.Wewillleavethisuptoyou,butherearesometips:•IncasesofFrameRelay

—Checkforthebroadcastkeywordmissingintheframe-relaymapstatement.—Callyourtelcoandmakesurethatitispropagatingbroadcasttrafficacross.

•Incasesofabridgingcloud—Makesurethatanybridgeinthemiddleisnotdroppingthebroadcastpackets.—IfthemiddlemediumisTokenRingtoEthernet,makesurethatthetranslationalbridgingisworkingproperly.

Example5-33showsthatafterfixingtheLayer2problem,IGRProutesgetinstalledintheroutingtable.Example5-33VerifyingIGRPRoutesShowUpintheRoutingTableAfterResolvingtheLayer2Problem


IGRPRoutesNotintheRoutingTable—Cause:Sender’sASMismatch

IGRPupdatescarrytheASnumber.WhenareceiverreceivesanIGRPupdateandtheASnumberofthesenderdoesnotmatchwithitsownASnumber,IGRPignoresthatupdate.Asaresult,noIGRProutesareinstalledintheroutingtable.MultipleIGRPprocessescanberununderdifferentASnumbers.Theseprocessesareindependentofeachother.Figure5-13showstheflowcharttofollowtosolvethisproblem.


Example5-34showstheconfigurationofbothR1andR2.R1isrunningIGRPAS1,andR2isrunningIGRPAS2.Example5-34R1andR2ConfigurationsShowThatTheyAreinDifferentAutonomousSystems

R2#interfaceLoopback0ipaddress131.108.3.2255.255.255.0!interfaceSerial0ipaddress131.108.1.2255.255.255.0!routerigrp2network131.108.0.0!

R1#interfaceLoopback0ipaddress131.108.2.1255.255.255.0!interfaceSerial0ipaddress131.108.1.1255.255.255.0!routerigrp1network131.108.0.0

!

Example5-35showstheoutputofdebugipigrptransactionanddebugippacket100detailonR1andR2.BothroutersaresendingtheIGRPupdate,buttheupdateneverreachestheotherside.BothroutersshowthattheIGRPpacketsarebeingreceived,butIGRPisignoringtheseupdatesbecauseoftheASnumbermismatch.Unfortunately,thedebugdoesnotshowthemismatchmessage;however,itdoesshowthatIGRPisnotdisplayingtheupdatereceivedmessageinthedebugs.Example5-35debugipigrptransactionCommandOutputonR1andR2RevealstheStatusofIGRPUpdates

R1#showdebugGenericIP:IPpacketdebuggingison(detailed)IProuting:IGRPprotocoldebuggingisonIGRPeventdebuggingisonR1#R1#showaccess-list100access-list100permitipanyhost255.255.255.255

R1#debugippacket100detailIPpacketdebuggingison(detailed)foraccesslist100R1#R1#debugipigrptransactionIGRPprotocoldebuggingisonIGRP:sendingupdateto255.255.255.255viaSerial0(131.108.1.1)subnet131.108.3.0,metric=501IP:s=131.108.1.2(Serial0),d=255.255.255.255,len64,rcvd2,proto=9

R2#debugippacket100detailIPpacketdebuggingison(detailed)foraccesslist100R2#R2#debugipigrptransactionIGRPprotocoldebuggingisonIGRP:sendingupdateto255.255.255.255viaSerial0(131.108.1.2)subnet131.108.2.0,metric=501IP:s=131.108.1.1(Serial0),d=255.255.255.255,len64,rcvd2,proto=9

Solution

Inthisexample,thesenderissendingAS1intheupdate.WhenR2receivesit,itignoresthisupdatebecauseR2isrunningIGRPunderAS2.Tofixthisproblem,changetheIGRPconfigurationssothatR1andR2bothagreeononeASnumber.Example5-36showsthenewconfigurationonR2thatfixesthisproblem.Example5-36ConfiguringR2toHavetheSameASNumberasR1

R2#interfaceLoopback0ipaddress131.108.3.2255.255.255.0!interfaceSerial0ipaddress131.108.1.2255.255.255.0!norouterigrp2!routerigrp1

network131.108.0.0!

Example5-37showsthatafterfixingtheASproblem,IGRProutesgetinstalledintheroutingtable.Example5-37showiprouteCommandOutputRevealsThattheASProblemPreventingIGRPRouteInstallationIsResolved

R2#showiproute131.108.2.0Routingentryfor131.108.2.0/24Knownvia"igrp1",distance100,metric8976Redistributingviaigrp1Advertisedbyigrp1(selforiginated)Lastupdatefrom131.108.1.1onSerial0,00:00:12agoRoutingDescriptorBlocks:*131.108.1.1,from131.108.1.1,00:00:12ago,viaSerial0Routemetricis8976,trafficsharecountis1Totaldelayis25000microseconds,minimumbandwidthis1544KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops0

Problem:IGRPIsNotInstallingAllPossibleEqual-CostPaths—Cause:maximum-pathsRestrictsIGRPtoaMaximumofFourPathsbyDefaultBydefault,Ciscorouterssupportonlyfourequalpaths,forload-balancingpurposes.Thecommandmaximum-pathcanbeusedforuptosixequal-costpaths.Ifthecommandisnotconfiguredproperly,itcancauseproblems,asdiscussedinthissection.Thecommandmaximum-pathisincorrectlyused,soitallowsonlyonepathtothedestinationeventhoughmorethanonepathexists.Themaximum-path1commandshouldbeusedonlywhenloadbalancingisnotdesired.Figure5-14showsthenetworksetupthatproducestheproblemofIGRPnotinstallingallpossibleequal-costpaths.

Figure5-14NetworkSetupVulnerabletoEqual-Cost-PathRoutesNotBeingInstalledbyIGRP

Example5-38showstheroutingtableentryofRouterR1.Onlyonerouteisbeinginstalledintheroutingtable.Example5-38RoutingTableforR1inFigure5-14

R1#showiprouteigrp131.108.0.0/24issubnetted,1subnetsI131.108.2.0[100/8976]via131.108.5.3,00:00:09,Ethernet2



Example5-39showstheoutputofthedebugipigrptransactioncommandonRouterR1,revealingthatRouterR1isreceivingtwoequal-costroutepaths.Example5-39debugipigrptransactionCommandOutputRevealstheNumberofEqual-CostPathsReceived

R1#debugipigrptransactionIGRPprotocoldebuggingisonIGRP:receivedupdatefrom131.108.5.3onEthernet2network137.99.0.0,metric8976(neighbor501)IGRP:receivedupdatefrom131.108.1.2onEthernet1network137.99.0.0,metric8976(neighbor501)

Onlyonerouteisinstalledintheroutingtable.Youseeonlyonerouteintheroutingtableinsteadoftwobecausetheoperatorhasconfiguredmaximum-paths1intheconfiguration.Example5-40showsthecurrentconfigurationforRouterR1.Themaximum-pathsettingissetto1,whichpreventsIGRPfrominstallingmorethanonepathintheroutingtable.Bydefault,maximum-pathissetto4.Example5-40CurrentR1Configuration

routerigrp1network131.108.0.0maximum-paths1

Solution

Bydefault,CiscoIOSSoftwareallowsuptofourequal-costroutestobeinstalledintotheroutingtable.Thiscanbeincreaseduptosixroutesifconfiguredproperly.Ifthereisadesiretodoaloadbalancing

oversixlinks,usethiscommand.Example5-41showstheconfigurationthatinstallssixequal-costroutepathsintheroutingtable.Example5-41ConfiguringR1toAcceptUptoSixEqual-CostRoutePathsintheRoutingTable

R1#routerigrp1maximum-paths6

Thisexamplemakesmoresensewhenyouhavemorethanfourpathsandonlyfouraregettinginstalledintheroutingtable.Becausefourequal-costroutesisadefault,youmustconfiguremaximum-pathstoaccommodatethefifthand(possiblysixth)route.

TroubleshootingIGRPRoutesAdvertisementAlltheseproblemsdiscussedsofardealwithaproblemonthereceivingendoraprobleminthemiddle(Layer2).Thereisathirdpossibilityforwhytherouteisnotbeinginstalledintheroutingtable—theproblemisoccurringonthesender’send.ThesendermightbehavingaproblemsendingIGRPupdates,sothereceiverisnotinstallingtheIGRProutesintheroutingtable.Thisnextsectiontalksaboutthethingsthatcangowrongonthesender’sside.ThissectiondiscussesthemostcommonscenariosthatcanpreventIGRProutesfrombeingadvertisedout.SomecasesoverlapwithIGRProuteinstallationproblems—forexample,missingnetworkstatementsanddownedinterfaces.Thissectionassumesthatyoudidtroubleshootallthepossiblescenariosdiscussedintheprevioussectionandthattheproblemsstillexist.Inthiscase,thelastplacetolookatisthesender.ThischaptercoverstwoproblemsrelatedtoIGRProuteadvertisementoriginatingfromthesender’sside:•ThesenderisnotadvertisingIGRProutes.•Thecandidatedefaultisnotbeingadvertised.

Problem:SenderIsNotAdvertisingIGRPRoutesTypically,anIPnetworkrunningIGRPhasroutersthathaveaconsistentviewoftheroutingtable.Inotherwords,allroutershaveroutingtablesthatcontainreachabilityinformationforalltheIPsubnetsofthenetwork.Thismightdifferwhenfilteringofcertainsubnetsisdoneatsomeroutersandnotatothers.Ideally,allIGRProutersareawareofallroutesofthecompletenetwork.Whentheroutinginformationdiffersfromoneroutertotheother,oneoftwopossibilitiescouldexist:•Somerouter(s)isnotadvertisingtheIGRProutes.•Somerouter(s)isnotreceivingtheIGRProutes.

ThissectiondealswitharouternotadvertisingIGRProutes.Figure5-16providesanetworkscenariothatwillbeusedasthebasisfortroubleshootingamajorityofthefollowingcausesofthe“senderisnotadvertisingIGRProutes”problem:•networkstatementismissingorincorrect.•Theoutgoinginterfaceisdown.•distribute-listoutisblockingtheroutes.•Theadvertisednetworkinterfaceisdown.•Theoutgoinginterfaceisdefinedaspassive.

•Broadcastcapabilityhasbeenbroken(encapsulationfailureinFrameRelay).•neighborstatementismisconfigured.•TheadvertisedsubnetisVLSM.•Splithorizonisenabled.

Figure5-16NetworkSetuptoIllustrateIGRPRoutesNotBeingAdvertised

InFigure5-16,Router1(thesender)isnotadvertisingroutestoRouter2.IfanetworkstatementismissingfromRouter1’sconfigurations,itwillnotadvertiseanyIGRProutes.SenderIsNotAdvertisingIGRPRoutes—Cause:MissingorIncorrectnetworkStatement

OneoftherequirementsforenablingIGRPonarouter’sinterfaceistomentionthenetworkstatementundertherouterigrpcommand.ThenetworkstatementdecideswhichinterfaceuponwhichIGRPshouldbeenabled.Ifthenetworkstatementismisconfiguredorisnotconfigured,IGRPwillnotbeenabledonthatinterfaceandIGRProuteswillnotbeadvertisedoutonthatinterface.Figure5-17showstheflowcharttofollowtofixthisproblem.


Example5-42showsthecurrentconfigurationforR1.Example5-42CurrentConfigurationforR1inFigure5-16


interfaceEthernet0ipaddress131.108.1.1255.255.255.0!routerigrp1network131.107.0.0

Solution

Thenetworkstatementisincorrectlyconfiguredunderrouterigrp1.Insteadof131.108.0.0,131.107.0.0isconfigured.ThiswillnotenableIGRPontheinterface,andnoupdateswillbesent.Sometimes,aclasslessnetworkstatementisconfiguredunderrouterIGRP,assumingthatitwillcoverallthenetworks—forexample:

routerigrp1network131.0.0.0

Thisnetworkstatementwillnotcover131.0.0.0–131.255.255.255because131.0.0.0isaclasslessnetworkandIGRPisaclassfulroutingprotocol.Similarly,ifyouhavemultipleClassCaddresses,youcannotuseoneClassCaddresstocoveralltheClassCaddressesthatyouown,suchas200.1.1.0–200.1.4.0.Thisdoesnotmeanyoucandothis:

routerigrp1network200.1.0.0

ThisnetworkstatementismeaninglessforIGRPbecauseIGRPisaclassfulprotocol.ThecorrectwaytoadvertiseallfournetworksinIGRPisthis:

routerigrp1network200.1.1.0network200.1.2.0network200.1.3.0network200.1.4.0

Example5-43showsthecorrectconfigurationforR1.Example5-43R1ConfigurationwiththeCorrectnetworkStatement

R1#interfaceLoopback0ipaddress131.108.2.1255.255.255.0!interfaceEthernet0ipaddress131.108.1.1255.255.255.0!routerigrp1nonetwork131.107.0.0network131.108.0.0

Example5-44showstheroutingtableentryofRouterR2,withthelearnedIGRProute.Example5-44R1RoutingTableShowsThatRoutesWereProperlyAdvertisedbyR2AfterCorrectingtheConfiguration

R2#showiproute131.108.2.0Routingentryfor131.108.2.0/24Knownvia"igrp1",distance100,metric8976Redistributingviaigrp1Advertisedbyigrp1(selforiginated)Lastupdatefrom131.108.1.1onSerial0,00:00:12agoRoutingDescriptorBlocks:*131.108.1.1,from131.108.1.1,00:00:12ago,viaSerial0Routemetricis8976,trafficsharecountis1Totaldelayis25000microseconds,minimumbandwidthis1544Kbit

Reliability255/255,minimumMTU1500bytesLoading1/255,Hops0

SenderIsNotAdvertisingIGRPRoutes—Cause:OutgoingInterfaceIsDown

IGRPistheroutingprotocolthatrunsonLayer3.IGRPcannotsendupdatesacrosstheinterfaceiftheoutgoinginterfaceisdown.Avarietyofpossiblecausesexistsfortheoutgoinginterfacebeingdown:•Interfaceisup,lineprotocolisdown.•Interfaceisdown,lineprotocolisdown.•Interfaceisadministrativelydown,lineprotocolisdown.

Iftheoutgoinginterfaceshowsanyofthesesymptoms,IGRPwillnotbecapableofsendinganyupdatesacross.Themainthingtonotehereisthatinallofthesepossibilities,thelineprotocolwillalwaysappeartobedown.ThisisthemostimportantinformationindeterminingtheLayer2connectivity.Figure5-18showstheflowcharttofollowtosolvethisproblem.


Example5-45verifiesthattheinterfaceEthernet0isdown.Example5-45showinterfaceCommandOutputRevealsThattheInterfaceIsDown


Solution

IGRPrunsaboveLayer2.IGRPcannotsendorreceiveanyroutesifLayer2isdown.Tocorrectthisproblem,youmustfixtheLayer2problem.Theproblemmightbeassimpleasloose

cablesorabadcable;inwhichcase,thecablemustbereplaced.Alter-natively,theproblemcouldbeascomplexasbadhardware;inwhichcase,thehardwaremustbereplaced.SomeofthetipsonresolvingtheLayer2issuealreadywereaddressedinthe“TroubleshootingIGRPRouteInstallation”section,wherethecauseisLayer1/2beingdown.Example5-46showstheinterfaceEthernet0afterfixingtheLayer2problem.Example5-46VerifyingThattheLayer2ProblemHasBeenResolved

R1#showinterfaceethernet0Ethernet0isup,lineprotocolisupHardwareisLance,addressis0000.0c70.d31e(bia0000.0c70.d31e)Internetaddressis131.108.1.1/24

Example5-47showstheroutingtableentryofR2afterfixingtheproblem.Example5-47VerifyingThatR2IsReceivingtheRoutesAfterFixingtheLayer2Problem


SenderIsNotAdvertisingIGRPRoutes—Cause:distribute-listoutIsBlockingtheRoute

distribute-listoutisusedtofilteranyroutesthataregoingtobesentoutonaninterface.Ifareceiveriscomplainingaboutamissingroutethatshouldhavebeenreceived,makesurethatitisnotbeingfilteredthroughdistribute-listout.Ifitis,theassociatedaccesslistmustbemodified.Figure5-19showstheflowcharttofollowtofixthisproblem.


Example5-48showstheconfigurationofRouterR1.Inthisconfiguration,theaccesslistdoesnotpermitthe131.108.0.0network,soR1willnotadvertiseany131.108network,including131.108.2.0/24.Example5-48AccessListConfigurationonR1DoesNotPermitthe131.108.0.0Network

R1#interfaceLoopback0ipaddress131.108.2.1255.255.255.0!interfaceEthernet0ipaddress131.108.1.1255.255.255.0!routerigrp1network131.108.0.0distribute-list1out!access-list1permit131.107.0.00.0.255.255

Solution

Whenusingadistributelist,youshouldalwaysdouble-checkyouraccesslisttomakesurethatthenetworksthataresupposedtobepermittedactuallyareexplicitlypermittedintheaccesslist.TheaccesslistconfigurationinExample5-48ispermittingonly131.107.0.0andisdenyingeverythingelsebecausethereisanimplicitdenyattheendofeachaccesslist.Tofixthisproblem,addapermitstatementallowing131.108.0.0inaccess-list1.Example5-49showsthenewconfigurationchangeonRouterR1.Example5-49AccessListConfigurationonR1toPermitthe131.108.0.0Network


interfaceEthernet0ipaddress131.108.1.1255.255.255.0!routerigrp1network131.108.0.0distribute-list1out!noaccess-list1permit131.107.0.00.0.255.255access-list1permit131.108.0.00.0.255.255

Example5-50showstheroutingtableentryofRouterR2afterfixingtheproblem.Example5-50R2RoutingTableVerifiesThatR2ReceivesIGRPRoutesAfterFixingtheAccessListinR2


SenderIsNotAdvertisingIGRPRoutes—Cause:AdvertisedNetworkInterfaceIsDown

Asituationcouldariseinwhichthenetworkthatisbeingadvertisedisdownandtheconnectedroutehasbeenremovedfromtheroutingtable.Inthissituation,IGRPwillstartadvertisingthatnetworkwithaninfinitemetricandaftertheholddowntimerexpires,itwillnolongeradvertisethisnetwork.Assoonastheadvertisednetworkcomesup,IGRPwillstartadvertisingitagaininitsupdates.Figure5-20showstheflowcharttofollowtofixthisproblem.


Example5-51showsthatthelineprotocoloftheadvertisednetworkinterfaceisdown,indicatingthatsomethingiswrongatLayer2.FortipsonfixingLayer1/2,refertothe“TroubleshootingIGRPRouteInstallation”section.Example5-51showinterfaceCommandOutputRevealsThattheAdvertisedNetworkInterfaceIsDown

R1#showinterfaceEthernet1Ethernet1isup,lineprotocolisdownHardwareisLance,addressis0000.0c70.d51e(bia0000.0c70.d51e)Internetaddressis131.108.2.1/24

Solution

Whentheadvertisednetwork’sinterfacegoesdown,IGRPwilldetectthatbecauseLayer2notifiestheupperlayerthattheinterfaceorthesubnetisdown.IGRPwillnolongeradvertisethatnetworkintheIGRPupdates.AsExample5-52shows,Ethernet1isdown,soIGRPnolongeradvertise131.108.2.0/24initsupdate.Tocorrectthisproblem,youmustfixtheLayer1/2problem.Theproblemcouldbeassimpleasloosecables,oritcouldbeascomplexasbadhardware,inwhichcasethehardwaremustbereplaced.Referbacktothe“TroubleshootingIGRPRouteInstallation”sectionfortipsonfixingLayer1/2issues.Example5-52showsthattheadvertisednetworkinterfaceisupafterfixingtheLayer2problem.Example5-52VerifyingThattheAdvertisedNetworkInterfaceIsUp

Ethernet1isup,lineprotocolisupHardwareisLance,addressis0000.0c70.d51e(bia0000.0c70.d51e)Internetaddressis131.108.2.1/24

Example5-53showsthattheroutethatwasdownisbackintheroutingtableofR2.Example5-53R2RoutingTableVerifiesThatR2StartsReceivingIGRPRoutesAfterFixingtheLayer1/2Issue


SenderIsNotAdvertisingIGRPRoutes—Cause:OutgoingInterfaceIsDefinedasPassive

WhenaninterfaceisdefinedaspassiveunderIGRP,IGRPwillreceiveupdatesonthatinterfacebutwillnotsendanyupdates.Thepassive-interfacecommandisusedtoavoidsendingunnecessaryupdatestoaneighborthatdoesnotneedtoreceiveanyIGRPupdates,suchasasmallroutethatisattheedge.Asimpledefaultgatewayisenoughinformationforthatroutertotalktotheoutsideworld.Besuretousethepassive-interfacecommandwhereneeded;otherwise,undesiredresultsmightoccur.Figure5-21showstheflowcharttofollowtofixthisproblem.


Example5-54showstheoutputofshowipprotocols,whichshowsthattheoutgoinginterfaceisdefinedaspassive.Example5-54VerifyingThattheOutgoingInterfaceIsPassive

R1#showipprotocolsRoutingProtocolis"IGRP1"Sendingupdatesevery30seconds,nextduein82secondsInvalidafter270seconds,holddown280,flushedafter630OutgoingupdatefilterlistforallinterfacesisIncomingupdatefilterlistforallinterfacesisDefaultnetworksflaggedinoutgoingupdatesDefaultnetworksacceptedfromincomingupdatesIGRPmetricweightK1=1,K2=0,K3=1,K4=0,K5=0IGRPmaximumhopcount100IGRPmaximummetricvariance1Redistributing:igrp1RoutingforNetworks:131.108.0.0PassiveInterface(s):Ethernet0RoutingInformationSources:GatewayDistanceLastUpdate131.108.1.210000:00:09Distance:(defaultis100)

Example5-55showstheconfigurationofRouterR1,whichshowsthattheoutgoinginterfaceisdefinedaspassive.Example5-55R1ConfigurationShowsaPassiveInterface

R1#routerigrp1passive-interfaceEthernet0network131.108.0.0

Solution

Example5-54and5-55confirmthattheinterfaceEthernet0isdefinedaspassive,soR1isnotsendinganyupdatesonEthernet0.Sometimes,itisdesirableforsomenetworkstobeadvertisedoutandotherstobefiltered.Inthissituation,youshouldnotusepassiveinterfaces—distribute-listoutisabettersolution.Assumingthatpassive-interfacewasconfiguredbymistake,takethiscommandoutoftheconfigurationtosolvethisproblem.Example5-56showsthenewconfigurationtosolvethisproblem.Example5-56RemovingthePassiveInterface

R1#routerigrp1network131.108.0.0nopassive-interfaceEthernet0

Example5-57showstheroutingtableentryofR2afterfixingtheproblem.Example5-57R2’sRoutingTableVerifiesThatRemovalofthePassiveInterfaceFixedRoutesAdvertisementProblemonR1

R2#showiproute131.108.2.0Routingentryfor131.108.2.0/24Knownvia"igrp1",distance100,metric8976Redistributingviaigrp1Advertisedbyigrp1(selforiginated)Lastupdatefrom131.108.1.1onEthernet0,00:00:12agoRoutingDescriptorBlocks:

*131.108.1.1,from131.108.1.1,00:00:12ago,viaEthernet0Routemetricis8976,trafficsharecountis1Totaldelayis25000microseconds,minimumbandwidthis1544KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops0

SenderIsNotAdvertisingIGRPRoutes—Cause:BrokenBroadcastCapability(EncapsulationFailureinLayer2)

WhenIGRPisrunninginaFrameRelayenvironment,Layer2mustsupportbroadcast;otherwise,IGRPupdateswillnotgetacross.Whenusingstaticmapping,besuretoaddthebroadcastkeywordattheendofamapstatement.ThisproblemalsocanbeseenwithX.25,ISDN,andotherLayer2media.Wheneverthereisastaticmapping,thebroadcastkeywordmustbeincludedintheconfiguration.Figure5-22showsthenetworksetupthatisusedtoproduceabrokenbroadcastcapabilityinFrameRelay.Figure5-22showsthatRouter1andRouter2areconnectedbyFrameRelay.Router1isnotadvertisingIGRProutestowardRouter2.

Figure5-22NetworkSetupIncompatiblewithFrameRelayBroadcastingWithoutbroadcastKeywordinmapStatement



Example5-58showstheconfigurationofRouterR1.Inthisconfiguration,theframe-relaymapstatementdoesnotincludethebroadcastkeyword.

Example5-58R1ConfigurationLacksthebroadcastKeyword

R1#interfaceSerial3ipaddress131.108.1.1255.255.255.0noipdirected-broadcastencapsulationframe-relaynokeepalive

frame-relaymapip131.108.1.216!

Example5-59showsoutputfromthedebugippacketcommand,whichincludesthebroadcasttrafficsourcefromR1.Thedebugshowsthatthereareencapsulationfailures.Example5-59debugippacketCommandOutputIndicatesEncapsulationFailures

R1#showaccess-list100ExtendedIPaccesslist100permitiphost131.108.1.1host255.255.255.255(8matches)R1#debugippacket100detailIPpacketdebuggingison(detailed)foraccesslist100R1#IP:s=131.108.1.1(local),d=255.255.255.255(Serial3),len88,sendingbroad/multicast,proto=9IP:s=131.108.1.1(local),d=255.255.255.255(Serial3),len88,encapsulationfailed,proto=9

Solution

Tosolvethisproblem,addthebroadcastkeywordintheframe-relaymapstatement.Example5-60showsthenewconfigurationofRouterR1withthecorrectframe-relaymapstatement.Example5-60ConfiguringR1withtheframe-relaymapStatement,IncludingthebroadcastKeyword

interfaceSerial3ipaddress131.108.1.1255.255.255.0noipdirected-broadcastencapsulationframe-relaynokeepaliveframe-relaymapip131.108.1.216broadcast!

Example5-61showstheroutingtableentryofR2withIGRProutes.Example5-61R2RoutingTableVerifiesThatR2IsReceivingIGRPRoutesAfterBroadcastingIsEnabledonR2’sframe-relaymapStatement


SenderIsNotAdvertisingIGRPRoutes—Cause:MisconfiguredneighborStatement

Inanonbroadcastenvironment,IGRPprovidesaunicastmethodofsendingIGRPupdates.TosendunicastIGRPupdates,youmustconfiguretheneighborstatementcarefully.Iftheneighboraddressismisconfiguredintheneighborstatement,IGRPwillnotsendtheunicastupdatetothewrongneighbororanonexistentneighbor.Figure5-24showstheflowcharttofollowtosolvethisproblem.


Example5-62showstheIGRPconfigurationforRouterR1.Theconfigurationshowsthattheneighborstatementisconfiguredwrong.Insteadof131.108.1.2,asshowninFigure5-22,theneighborstatementpointsto131.108.1.3,whichdoesnotexist.Example5-62MisconfiguredneighborStatementPreventingUnicastIGRPUpdates

R1#routerigrp1network131.108.0.0neighbor131.108.1.3

Solution

InExample5-62,IGRPissendingaunicastupdateto131.108.1.3,abogusneighborthatdoesnotexist.Toresolvethisproblem,youmustproperlyconfiguretheneighborstatement.Example5-63showsthecorrectconfigurationofRouterR1.Example5-63ConfiguringR1withtheProperneighborStatement

R1#routerigrp1network131.108.0.0noneighbor131.108.1.3

neighbor131.108.1.2

Example5-64showstheIGRProutesinstalledinR2’sroutingtable.Example5-64R2’sRoutingTableVerifiesThattheneighborStatementHasBeenProperlyConfiguredonR1,soR2StartsReceivingIGRPRoutes


SenderIsNotAdvertisingIGRPRoutes—Cause:AdvertisedSubnetIsVLSM

IGRPisnotdesignedtocarrysubnetmaskinformation;therefore,anysubnetthatisusingadifferentmaskotherthantheinterfacethatwillbesourcingtheIGRPupdatewillnotbeadvertisedbyIGRP,whichactuallyperformsacheckbeforesendinganupdate.ThischeckmakessurethatthesubnetthatwillbeadvertisedbyIGRPhasthesamesubnetmaskastheinterfacethatwillbesourcingtheIGRPupdate.Ifthemaskisdifferent,IGRPactuallydropstheupdateandwillnotadvertiseit.Therefore,inIGRP,thesubnetmaskshouldbeconsistent;otherwise,itcancausethisproblem.ThisisalsoexplainedindetailinChapter4.Figure5-25showsanetworksetupthatproducesproblemsbecauseofVLSM.ThefigureshowsthatRouter1hasaVLSMsubnetthatis131.108.2.0/25.ThissubnetwillnotgoacrosstowardRouter2.

Figure5-25NetworkSetupConducivetoAdvertisedSubnetProblemsBecauseofVLSM



Example5-65showsthattheloopbackinterfaceofR1isconfiguredfora25subnetmaskandalsoshowsthattheinterfacethatwillbesourcingtheIGRPupdatehasa24mask.Example5-65R1’sLoopbackInterfaceConfiguredwithaSubnetMaskIncompatiblewiththeInterfaceSourcingtheIGRPUpdate

R1#interfaceLoopback0ipaddress131.108.2.1255.255.255.128!interfaceEthernet0ipaddress131.108.1.1255.255.255.0!routerigrp1network131.108.0.0

Solution

Tosolvetheproblem,youneedtoeitherchangethesubnetmasksothatitmatchestheinterfacethatwillbesourcingtheIGRPupdateorchangetheprotocoltoEIGRPthatdoessupportVLSM.ChangingtheprotocoltoEIGRPmeansthateveryrouterinthenetworkmustbechangedtoEIGRP,sothisisalong-termsolution.Example5-66showstheconfigurationchangesthatcorrecttheproblem.Example5-66CorrectingtheMismatchedSubnetMaskProblem


interfaceEthernet0ipaddress131.108.1.1255.255.255.0!routerigrp1network131.108.0.0

Example5-67showstheroutingtableentryofRouterR2aftercorrectingtheproblem.Example5-67R2’sRoutingTableVerifiesThattheMismatchedSubnetMaskProblemHasBeenResolved


SenderIsNotAdvertisingIGRPRoutes—Cause:SplitHorizonIsEnabled

SplithorizonisafeatureinIGRPthatcontrolstheroutingloops.Insomesituations,itisnecessarytoenablesplithorizontoavoidloops—forexample,inanormalsituation,anIGRPupdateisreceivedonaninterfaceandisnotsentoutonthesameinterface.Inothersituations,itmustbedisabled,suchasinahub-and-spokeFrameRelaysituationwhenspokeshavenocircuitbetweenthemandtheygothroughthehubrouter(seeFigure5-27).

Figure5-27Hub-and-SpokeTopologyinWhichSpokesDoNotHaveAnyCircuitsBetweenThem

Anotheruniquesituationinthisexampleisarouterwithanexternalroutethathasanext-hopaddressalsoknownthroughthesameinterfacewhereotherIGRProutersaresitting(seeFigure5-28).WhenthoseexternalroutesareredistributedintoIGRP,therouterdoesnotadvertisethatrouteoutthesameinterfacebecausesplithorizonisenabled.Also,ifasecondaryaddressisconfiguredunderaninterface,splithorizonmustbeturnedoffonthatinterface;otherwise,thatsecondaryaddresswillnotbeadvertisedout

thatinterfacetootherrouters.InFigure5-28,somesecondaryaddressesaredefinedunderR1’sEthernet.Forthisreason,youmustconfigurenoipsplit-horizonunderR1’sEthernetinterface.

Figure5-28NetworkSetupConducivetoRouteAdvertisementProblemsBecauseofSplitHorizon

Figure5-28showsthenetworksetupthatproducesproblemswhensplithorizonisenabled.Router1isnotadvertisingallIGRProutestoRouter2.Figure5-29showstheflowcharttofollowtofixthisproblem.


Example5-68showsthecurrentconfigurationofR1.Notethat166.166.166.0/24isknownthrough

131.108.1.3.R2alsoresidesonthissubnet,soR1willnotsendoutanyupdateonthisinterfacebecauseofsplithorizon.Example5-68R1ConfigurationinWhichaStaticRoute’sNext-HopAddressFallsUnderItsConnectedSubnetWhereRIPIsEnabled

R1#routerigrp1redistributestaticnetwork131.108.0.0!iproute155.155.0.0255.255.0.0Null0iproute166.166.166.0255.255.255.0131.108.1.3

Example5-69showsthattheroute166.166.166.0/24isnotintheroutingtableofRouterR2.Example5-69R2’sRouteTableIndicatesThatthe166.166.166.0/24RouteIsMissing

R2#showiprouteigrpI155.155.0.0/16[100/8496]via131.108.1.1,00:00:07,Ethernet0

Example5-70showsthedebugipigrptransactionoutputonRouterR1,whichisadvertising155.155.0.0/16butnot166.166.166.0/24.InR2’sroutingtable,norouteexistsfor166.166.166.0/24.Example5-70debugipigrptransactionCommandOutputShowsThat166.166.166.0/24IsNotBeingAdvertised

R1#debugipigrptransactionIGRPprotocoldebuggingisonIGRP:sendingupdateto255.255.255.255viaEthernet0(131.108.1.1)network155.155.0.0,metric=501

Solution

Thisproblemhappensbecausethenexthopof166.166.166.0/24is131.108.1.3.Undersplithorizon,IGRPwillsuppressthisupdateontheinterfacewhere166.166.166.0/24islearned.Becauseofthis,IGRPwillnotadvertise166.166.166/24outthesameinterfacewhereitislearned.ThesolutionliesinturningoffsplithorizononR1’sEthernet0interface.Example5-71showsthecorrectedconfigurationonRouterR1tosolvethisproblem.Example5-71DisablingSplitHorizononR1Ethernet0Interface

interfaceEthernet0ipaddress131.108.1.1255.255.255.0noipsplit-horizon

Example5-72showsthat,aftermakingtheconfigurationchanges,R2isreceiving166.166.0.0/16intheIGRPupdates.Notethat,becauseitiscrossingthemajornetworkboundary,R1willautosummarizeitandsend166.166.0.0.Thisiswhytheroutingtableshows166.166.0.0insteadof166.166.166.0.Example5-72R2’sRoutingTableIndicatesThatDisablingSplitHorizononR1HasEnabledtheAdvertisementof166.166.166.0/24

R2#showiprouteigrpI155.155.0.0/16[100/8496]via131.108.1.1,00:00:08,Ethernet0

I166.166.0.0/16[100/8496]via131.108.1.1,00:00:08,Ethernet0

ThisproblemalsocanoccurwheninterfacesareconfiguredwithsecondaryIPaddresses.Example5-73showstheinterfaceconfigurationwithasecondaryIPaddress.Example5-73R1’sEthernet0InterfaceConfiguredwithaSecondaryIPAddress

R1#interfaceEthernet0ipaddress131.108.2.1255.255.255.0secondaryipaddress131.108.1.1255.255.255.0

Ifsplithorizonisenabled,thissecondaryaddresswillnotbeadvertisedonEthernet0.Similarly,imagineasituationinwhichtherearethreerouters—R1,R2,andR3—onthesameEthernet,asshowninFigure5-30.

Figure5-30NetworkwithThreeRoutersontheSameEthernetNetwork

R1andR3arerunningOSPF.R1andR2arerunningIGRP.NowR3advertisescertainroutesthroughOSPFtoR1thatR1hastoredistributeintoIGRP.R1willnotadvertisethoseOSPFroutestoR2becauseofsplithorizon.Again,thesolutionistodisablesplithorizon.Basically,thesearethethreemainreasonsforturningoffthesplithorizon.Anyothersituationmightcreatearoutingloopifsplithorizonisturnedoff.

Problem:CandidateDefaultIsNotBeingAdvertised—Cause:ipdefault-networkCommandIsMissingInaclasslessenvironment,whenarouterneedstosendapackettoaparticulardestination,itperformsthefollowingcheckinthisorder:1Isthedestinationaddressoneofmyconnectedinterfaceaddresses?Ifyes,useARPfortheaddress

andthenencapsulatethepacketinanEthernetframeandsendittothedestination.2Ifno,doIhavearouteinmyroutingtableforthisdestinationaddress?Ifyes,usethatroutefromtheroutingtableandsendthepacket.

3Ifno,checkwhetherthegatewayoflastresortisset.Ifitisset,sendthepackettotheaddressmentionedinthegatewayoflastresort.(InExample5-74,thepacketswillbesentto131.108.1.1.Ifthereisnogatewayoflastresort,thepacketisdropped.)

Example5-74showsthatthegatewayoflastresortissetto131.108.1.1.Thismeansthatifarouterdoesnothaveanentryintheroutingtable,itwillsendthepacketto131.108.1.1.Example5-74VerifyingThataGatewayofLastResortIsSet

R1#showiprouteGatewayoflastresortis131.108.1.1tonetwork0.0.0.0

InanyroutingprotocolexceptIGRP,thewaytosetthegatewayoflastresortistodefineastaticroute0.0.0.0withthemaskof0.0.0.0andanext-hopaddress,asshowninExample5-75;however,IGRPcannotunderstand0.0.0.0,sothereisaseparatewaytosetthegatewayoflastresortinIGRP.Example5-75ConfiguringaDefaultRoutetoSettheGatewayofLastResort

R1(config-term)#iproute0.0.0.000.0.0.0131.108.1.1



Example5-76showstheconfigurationofR1.Nodefault-networkstatementisconfigured.Example5-76R1’sConfigurationRevealsThataCandidateDefaultRouteHasNotBeenConfigured

R1#interfaceLoopback1ipaddress131.108.2.1255.255.255.0!interfaceLoopback3ipaddress155.155.155.1255.255.255.0!

interfaceEthernet0ipaddress131.108.1.1255.255.255.0!routerigrp1network131.108.0.0network155.155.0.0

Example5-77showstheroutingtableinRouterR2,whichR2isreceiving155.155.155.0/24,butitisnotacandidatefordefaultbecauseitisnotconfiguredasacandidatefordefaultroute.Example5-77R2’sRoutingTable

R2#showiprouteigrpI155.155.0.0/24[100/8976]via131.108.1.1,00:00:22,Serial0131.108.0.0/24issubnetted,3subnetsI131.108.2.0[100/8976]via131.108.1.1,00:00:22,Serial0

Solution

IGRPisincapableofcarryingthe0.0.0.0/0(alsoknownasdefaultroute),asexplainedintheproblemsection.Instead,itfollowsthedefault-networkcommandtomarkanetworkasacandidatefordefault.Inthisexample,R1issending155.155.155.0/24,anditisdesirabletomakeR1acandidatefordefault.Todothat,changetheconfigurationonR1andestablishthe155.155.0.0networkasthedefaultnetwork.Upondoingthis,IGRPwillautomaticallystarttreating155.155.155.0/24asthecandidatefordefaultandwillsetthegatewayoflastresortonR2.Example5-78showstheconfigurationfordefault-networkonR1.Thisdefault-networkstatementmustalwayspointtowardamajornetwork,notasubnet;otherwise,itwillnotsetthegatewayoflastresort.Example5-78Configuring155.155.0.0astheDefaultNetwork

R1(config-term)#ipdefault-network155.155.0.0

Example5-79illustratesthataftertheconfigurationchangeonR1,thedebugipigrptransactionoutputshowsIGRPtreating155.155.155.0/24routeasanexteriorroutebecauseitismarkedasacandidatefordefaultroute.Example5-79IGRPTreats155.155.0.0asanExteriorRoute

IGRP:receivedupdatefrom131.108.1.1onSerial1subnet131.108.3.0,metric8976(neighbor501)subnet131.108.1.0,metric10476(neighbor8476)exteriornetwork155.155.0.0,metric8976(neighbor501)

Example5-80nowshowsthatthegatewayoflastresortissetandthat155.155.155.0/24ismarkedasacandidatefordefault.Also,the*nexttotheIintheroutingtableentrymeansthatthisentryisacandidateforadefaultroute.Example5-80R2’sRoutingTableIndicatestheCandidateforDefaultandShowsThattheGatewayof

LastResortIsSetto155.155.0.0

R2#showiproute

Gatewayoflastresortis131.108.1.1tonetwork155.155.0.0

137.99.0.0/24issubnetted,1subnetsC137.99.3.0isdirectlyconnected,Loopback0I*155.155.0.0/16[100/8976]via131.108.1.1,00:01:17,Serial1

TroubleshootingIGRPRedistributionProblemsThissectioncoversacommonproblemthatcanhappenduringredistributioninIGRP.Redistributionoccurswhenanotherroutingprotocol,staticroute,orconnectedrouteisbeinginjectedintoIGRP.Specialcareisrequiredduringthisprocesstoavoidanyroutingloops.Metricsalsoshouldbedefinedduringthisprocess,toavoidproblems.ThemostprevalentproblemencounteredwithIGRPredistributionisthatredistributedroutesarenotgettinginstalledintheroutingtableoftheIGRProutersreceivingtheseroutes.Whendestinationroutesarenotpresentintheroutingtable,nodatacanreachthosedestinations.

Problem:RedistributedRoutesAreNotGettingInstalledintheRoutingTable—Cause:MetricIsNotDefinedDuringRedistributionintoIGRPIGRPhasacompositemetricmadeupofbandwidth,delay,reliability,load,andMTU;however,bydefault,itutilizesonlybandwidthanddelay.OSPF’smetricisbasedoninterfacecost.Costisderivedfromthebandwidthofthelink.Ciscouses100,000,000/bandwidthtogetthecost.IGRPdoesnotunderstandthemetricsofotherprotocols(exceptEIGRP)soitisnecessarytoinputadefaultmetricwhendoingredistribution.Figure5-32showsthenetworksetupsusceptibletotheprobleminwhichredistributedroutesdonotgetinstalledintheroutingtable.

Figure5-32NetworkSetupConducivetoRedistributedRoutesNotBeingInstalledintheRoutingTable

OSPFisredistributedintoIGRPatR1,butR2isnotreceivingIGRProutesthatareOSPFroutesinR1.Figure5-33showstheflowcharttofollowtosolvethisproblem.


Example5-81showsthatR3isadvertising131.108.6.0/24throughOSPFtoR1.Example5-81R1’sRoutingTableShowsThatR3IsAdvertising131.108.6.0/24ThroughOSPF

R1#showiproute131.108.6.0Routingentryfor131.108.6.0/24Knownvia"ospf1",distance110,metric20,typeintraarea

Example5-82showsthatR1isredistributingOSPFinIGRP.Example5-82R1ConfigurationtoRedistributeOSPFintoIGRP

R1#routerigrpredistributeospf1network131.108.0.0

Example5-83showsthatinR2,131.108.6.0/24isnotpresentintheIGRProutingtable.Example5-83R2’sRoutingTableIsMissingtheRedistributedRoute


Solution

Tosolvethisproblem,R1needstoputametriccommandundertherouterigrpstatementsothatitcancalculatetheOSPFmetricproperly.Example5-84showsthenewconfigurationforR1.OSPFisredistributedintoIGRPwithmetricvaluesofbandwidth,delay,load,reliability,andMTU.Settinglowbandwidthandhighdelayyieldstoahighmetricforredistributedroutes.Example5-84ConfiguringR1toCalculateOSPFMetrics

R1#routerigrp1redistributeospf1metric11000025511500network131.108.0.0

Anotherwaytofixthisproblemistodefineadefaultmetricundertherouterigrpstatement.ThedifferencebetweenusingadefaultmetricanddefiningametricasshowninExample5-84isthatadefaultmetricwillbeusedforalltheredistribution.Forexample,iftherouterigrpstatementhasmultipleredistributioncommands,alltheredistributedrouteswillhaveadefaultmetricvaluedefinedundertherouterigrpcommand.Example5-85showsthesyntaxfordefault-metriccommandundertherouterigrpstatementwhenredistributingintoIGRP.Themetricvaluesarebasedonbandwidth,delay,load,reliability,andMTU.So,inthiscase,allthestaticandOSPFrouteswillberedistributedwiththedefaultmetricconfiguredhere.Example5-85ConfiguringaDefaultMetric

R1#routerigrp1redistributeospf1redistributestaticdefault-metric11000025511500network131.108.0.0

Example5-86showsthattheroutegetsinstalledintheroutingtable.Example5-86R2’sRoutingTableVerifiesThattheNewConfigurationforR1HasCorrectedtheProblem

R2#showiproute131.108.6.0Routingentryfor131.108.6.0/24Knownvia"igrp",distance100,metric8976

TroubleshootingDial-on-DemandRouting(DDR)IssuesinIGRPDial-on-demandroutingisverycommonwhentheISDNorsimilardialuplinksareusedasabackuplink.Whentheprimarylinkgoesdown,thisbackuplinkcomesup.IGRPstartssendingandreceivingupdatesonthislinkaslongastheprimarylinkisdown.Twowaysexistforusingthedialuplinksasabackupfortheprimarylink:•Usingthebackupinterfacecommand•Usingfloatingstaticrouteswithadialerlistthatdefinesinterestingtraffic

Thefirstmethodissimple:Thecommandistypedunderthedialinterfaceindicatingthatitisabackupforaprimaryinterface.

ThesecondmethodrequiresafloatingstaticroutewithahigheradministrativedistancethanIGRP—forexample,110orabove.Italsorequiresdefininginterestingtrafficthatshouldbringupthelink.TheIGRPbroadcastaddressof255.255.255.255mustbedeniedinthedialerlist,soitshouldnotbringupthelinkunnecessarily.WhenrunningIGRPunderdialbackupsituations,alotofissuesmustbeconsidered.SomeproblemsarerelatedtotheISDNlineorasynclinethatkeepscomingup.Someproblemsarerelatedtotheconfiguration.Thissectiontalksaboutthetwomostcommondialbackupproblems:•IGRPbroadcastiskeepingthelinkup.•IGRPupdatesarenotgoingacrossdialerinterface.

Problem:IGRPBroadcastIsKeepingtheISDNLinkUp—Cause:IGRPBroadcastsHaveNotBeenDeniedintheInterestingTrafficDefinitionISDNlinkstypicallyareusedasbackuplinkswhenprimarylinksgodown.CiscoIOSSoftwarerequiresthatroutersareinstructedonthekindoftrafficthatcanbringuptheISDNlinkandkeepitup.Suchtrafficiscalledinterestingtraffic.Networkoperatorstypicallywantdatatraffictobeconsideredasinterestingtraffic,tobringupandkeepuptheISDNlink.IGRPorotherroutingprotocolupdatesshouldnotbedefinedasinterestingtraffic.Ifthisisnotdone,theISDNlinkcomesupandstaysupaslongasroutingupdates(IGRP,inthiscase)aretakingplaceonaregularbasis.ThatisnotthedesiredbehaviorbecauseISDNprovideslow-speedconnectivityandbecausesomedataactuallycouldgoovertheslowlinkeventhoughtheprimaryfasterlinkisavailable.Figure5-34showsthenetworksetupsusceptibletodialbackupissues.

Figure5-34NetworkSetupConducivetoDialBackupProblems



Example5-87showstheconfigurationonRouterR1thatproducesthisproblem.Inthisconfiguration,onlyTCPtrafficisdenied.Inotherwords,TCPtrafficwillnotbringupandkeepupthelink.IGRPbroadcastsareIPpackets;becausethepermitipanyanycommandallowsanyIPtraffictogothroughbesidesTCP,IGRPbroadcasttrafficwillbeconsideredinterestingtraffic.Example5-87R1ConfigurationinWhichIGRPBroadcastsAreNotDenied

R1#interfaceBRI3/0ipaddress192.168.254.13255.255.255.252encapsulationpppdialermapip192.168.254.14nameR2broadcast57654dialer-group1isdnswitch-typebasic-net3pppauthenticationchap


Example5-88showstheoutputofshowdialer,whichindicatesthatthereasonforthelinkcomingupisIGRPbroadcast.Example5-88showdialerOutputIndicatestheLastTimetheLinkWasUpWasBecauseofIGRPBroadcast

R1#showdialerBRI1/1:1-dialertype=ISDN

Idletimer(120secs),Fastidletimer(20secs)Waitforcarrier(30secs),Re-enable(2secs)DialerstateisdatalinklayerupDialreason:ip(s=192.168.254.13,d=255.255.255.255)Currentcallconnected00:00:08Connectedto57654(R2)

Solution

WhenrunningIGRPandDDR,definetheaccesslisttodefinetheinterestingtraffic.InExample5-87,theaccesslistisdenyingonlytheTCPtrafficandispermittingalltheIPtraffic.IGRPusesanIPbroadcastaddressof255.255.255.255tosendtheroutingupdates.ThisaddressmustbedeniedintheaccesslistsothatIGRPdoesnotbringupthelinkevery90seconds.Example5-89showsthecorrectconfigurationchangeinRouterR1.Inthisconfiguration,alltrafficdestinedtothe255.255.255.255addressisdenied.ThiscoversIGRPbroadcast,soIGRPwillnotbringupthelinkafterthisconfigurationchange.Example5-89ConfiguringR1’sAccessListtoDenyIGRPBroadcastTraffic

R1#access-list100denytcpanyanyaccess-list100denyipany255.255.255.255access-list100permitipanyanydialer-list1protocoliplist100

Problem:IGRPUpdatesAreNotGoingAcrosstheDialerInterface—Cause:MissingBroadcastKeywordinadialermapStatementWhenadialerinterface—say,ISDN—comesup,itcouldbedesirabletorunaroutingprotocoloverthislink.Staticroutesmightdothejob,butinnetworkswithalargenumberofroutes,staticroutesmightnotscalewell.Therefore,runningadynamicroutingprotocolisnecessary.Insomesituations,theISDNlinkisupbutnoroutinginformationisgoingacross.Withoutaroutingprotocol,nodestinationaddressescanbelearnedandnotrafficcanbesenttothosedestinations.ThisproblemneedstobefixedbecauseISDNinterfacesareofnousewhennotcarryinganytraffic.Figure5-36showstheflowcharttofollowtosolvethisproblem.


Example5-90showstheconfigurationonR1thatproducesthisproblem.ThedialermapisusedtomaptheneighborIPaddresswithastring,whichisnormallyanISDNnumber.Thisiscalledastaticmappingfordialer.Whenusingstaticmapping,thekeywordbroadcastmustbeincludedattheend;otherwise,itwillnotpropagatethebroadcasttrafficacrossthelink.Example5-90R1ConfigurationPreventingIGRPUpdatesAcrossDialerInterface

R1#interfaceBRI3/0ipaddress192.168.254.13255.255.255.252encapsulationpppdialermapip192.168.254.14nameR257654dialer-group1isdnswitch-typebasic-net3pppauthenticationchap

Example5-91showsthatIGRPissendingthebroadcastupdatetowardR2,butbecauseofanencapsulationfailure,itisnotgettingontheotherside.Example5-91ConfirminganEncapsulationFailure

R1#showaccess-list100access-list100permitipanyhost255.255.255.255R1#debugippacket100detailIP:s=192.168.254.13(local),d=255.255.255.255(BRI3/0),len46,sendingbroad/multicast,proto=9IP:s=192.168.254.13(local),d=255.255.255.255(BRI3/0),len72,encapsulationfailed,proto=9

Solution

ThisproblemoccursbecauseIGRPusesbroadcaststosenditsroutingupdates.Whenusingdialermapstatements,youmustincludethebroadcastkeyword;otherwise,thebroadcastwillnotbeallowedtocrossthecircuitandtheencapsulationfailuresoccur.Tocorrectthisproblem,addthebroadcastkeywordinthedialermapstatement.Example5-92showsthenewconfigurationchangeonRouterR1.Example5-92ConfiguringR1toAllowBroadcastsAcrosstheDialerInterface

interfaceBRI3/0ipaddress192.168.254.13255.255.255.252encapsulationpppdialermapip192.168.254.14nameR2broadcast57654dialer-group1isdnswitch-typebasic-net3pppauthenticationchap

TroubleshootingRouteFlappingProbleminIGRPRunningIGRPinacomplexenvironmentsometimescancauseflappingofroutes.Routeflappingmeansthattherouteskeepcomingandgoingfromtheroutingtable.Toseewhethertheroutesareindeedflapping,checktheroutingtableandlookattheageoftheroutes.Iftheagesareconstantlygettingresetto00:00:00,theroutesareflapping.Therecouldbeseveralreasonsforthis.Thissectiondiscussesoneofthemostcommonreasons—packetloss.PacketlosspreventsanIGRPupdatefromreachingtheotherside.TheexampleinthissectionconsidersFrameRelaybecauseitisthemostcommonmediuminwhichthisproblemoccurs.Thepacketlosscanbeverifiedthroughtheinterfacestatisticsbylookingatthenumberofpacketdropsandseeingifitisconstantlyincrementing.

Problem:IGRPRoutesAreFlapping—Cause:PacketDropsonSender’sorReceiver’sInterfaceWhenIGRPisusedinalargeFrameRelayenvironmentwherethereareseveralneighborsononeFrameRelayinterface,thereisapossibilityofapacketloss.ThepacketlossinIGRPmeansthatthewholeupdateislost.IfasenderorreceiverdropsanIGRPupdate,ithastowaitforanotherupdatebecausetheIGRPupdatesarenotretransmittedafteritislost.ThemostcommonreasonforpacketdropsonFrameRelayinterfacesisaresultofbroadcastdropsinthebroadcastqueueofFrameRelay.BroadcastqueuesinFrameRelayaredesignedtocarryallthebroadcasttraffic.Ifthereisalotofbroadcasttraffic,thebroadcastqueueneedstobetuned.Figure5-37showsthenetworksetupsusceptibletoaIGRProute-flappingproblem.

Figure5-37NetworkSetupConducivetoRouteFlapping



TheshowiprouteoutputinExample5-93showsthattheroutesare3:08old,soithasmissedtwoupdates.IfIGRPdoesnotreceivearoutefor270seconds,theroutewillbeputintoholddown.Thissituationgetscorrectedbyitself,but,insomecases,changestotheconfigurationarerequired.Forexample,considertheoutputinExample5-93.Example5-93showiprouteigrpCommandOutputIndicatesThatIGRPDidNotReceiveUpdatesfor3Minutesand8Seconds

Hub#showiprouteigrpI155.155.0.0/16[100/8242]via131.108.1.1,00:03:08,Serial0I166.166.0.0/16[100/8242]via131.108.1.1,00:03:08,Serial0

TheoutputinExample5-93showsthatnoIGRPupdatehasbeenreceivedsince3minutesand8seconds.ThismeansthattwoIGRPupdateshavebeenmissed.Example5-94showsthattherearealargenumberofbroadcastdropsontheinterface.Thebroadcastqueuesizealsois64,whichisthedefault,anditmustbeincreased.Example5-94SerialInterfaceShowsThattheBroadcastQueueIsDroppingaLargeNumberofPackets

Hub#showinterfaceserial0Serial0isup,lineprotocolisupHardwareisMK5025Description:CharlotteFrameRelayPortDLCI100MTU1500bytes,BW1024Kbit,DLY20000usec,rely255/255,load44/255EncapsulationFRAME-RELAY,loopbacknotset,keepaliveset(10sec)LMIenqsent7940,LMIstatrecvd7937,LMIupdrecvd0,DTELMIupLMIenqrecvd0,LMIstatsent0,LMIupdsent0LMIDLCI1023LMItypeisCISCOframerelayDTE

Broadcastqueue64/64,broadcastssent/dropped1769202/1849660,interfacebroadcasts3579215

Solution

TheoutputinExample5-94furtherprovesthatthereissomeproblemattheinterfacelevel.Toomanydropsareoccurringattheinterfacelevel.Thisiscausingtherouteflapping.Tocorrectthisproblem,youmusttunetheFrameRelaybroadcastqueueaccordingly.TuningtheFrameRelaybroadcastqueueisbeyondthescopeofthisbook.SeveralpapersontheCiscowebsitediscusshowtotunetheFrameRelaybroadcastqueue:

www.cisco.com/warp/partner/synchronicd/cc/techno/media/wan/frame/prodlit/256_pb.htmwww.cisco.com/warp/public/125/20.html

Example5-95showsthatafterfixingtheinterfacedropproblem,routeflappingdisappears.Thebroadcastqueuesizeischangedfrom64to256.ThecorrectnumbercanbedeterminedafterreadingtheURLmentionedearlierfortuningthebroadcastqueue.Example5-95VerifyingThattheSerialInterfaceIsNotDroppingAnyBroadcastTrafficintheBroadcastQueue

Hub#showinterfaceserial0Serial0isup,lineprotocolisupHardwareisMK5025Description:CharlotteFrameRelayPortDLCI100

http://www.cisco.com/warp/partner/synchronicd/cc/techno/media/wan/frame/prodlit/256_pb.htm

http://www.cisco.com/warp/public/125/20.html

MTU1500bytes,BW1024Kbit,DLY20000usec,rely255/255,load44/255EncapsulationFRAME-RELAY,loopbacknotset,keepaliveset(10sec)LMIenqsent7940,LMIstatrecvd7937,LMIupdrecvd0,DTELMIupLMIenqrecvd0,LMIstatsent0,LMIupdsent0LMIDLCI1023LMItypeisCISCOframerelayDTEBroadcastqueue0/256,broadcastssent/dropped1769202/0,interfacebroadcasts3579215

Example5-96showsthattheshowiproutesoutputverifiesthattheroutesarestableintheroutingtable.Example5-96VerifyingStableRoutes

Hub#showiprouteigrpI155.155.0.0/16[100/8242]via131.108.1.1,00:00:07,Serial0I166.166.0.0/16[100/8242]via131.108.1.1,00:00:07,Serial0

TroubleshootingVarianceProblemVarianceisauniquefeatureofIGRP(andEIGRP)thatdistinguishesitfromRIP.Varianceisbasicallyawaytoload-balancethetrafficonunequal-costpaths.Allroutingprotocolssupportequal-cost-pathloadbalancing,butonlyIGRPandEIGRPsupportunequal-cost-pathloadbalancing,whichisconfiguredusingavariancecommand.Configurationofvarianceiseasy,aslongasyouknowtheconceptbehindit.Thevariancecommandinstructstheroutertoincluderouteswithametricsmallerthanntimestheminimummetricrouteforthatdestination,wherenisthenumberspecifiedbythevariancecommand.

Problem:IGRPNotUsingUnequal-CostPathforLoadBalancing—Cause:varianceCommandIsMissingorMisconfiguredTousethevariancefeature(unequal-cost-pathloadbalancing),itmustbeconfiguredundertherouterigrpcommand.Bydefault,IGRPdoesnotdounequal-cost-pathloadbalancing.Also,whenthevariancefactorismultipliedbythecurrentbestmetric,theresultingnumberiscomparedwithotheravailablepathmetrics.Anyavailablepathmetricthatisunderthisresultingnumberwillbeusedforunequal-pathloadbalancing.Figure5-39showsthenetworksetupsusceptibletothisproblem.Thenetwork155.155.0.0/16isknownthroughtwopaths,butonlyoneisintheroutingtable.

Figure5-39NetworkSetupConducivetoLoad-BalancingProblems



Example5-97showstheroutingtableentryonR1showingthatR1isusingonlyonepathtoreach155.155.0.0/16.Example5-97R1RoutingTableEntryShowsThatOnlyaSinglePathIsUsedtoReachtheDestinationNetwork


Example5-98showstheinterfaceconfigurationonbothSerial2andSerial3.Bandwidthsareequalinthisexample,buttheycouldhavedifferentvaluesindifferentscenarios.Example5-98R1’sSerial2andSerial3InterfaceConfigurations

R1#showinterfaceserial2Serial2isup,lineprotocolisupHardwareisHD64570Internetaddressis131.108.6.1/24MTU1500bytes,BW1544Kbit,DLY400000usec,rely255/255,load1/255

R1#showinterfaceserial3Serial3isup,lineprotocolisupHardwareisHD64570Internetaddressis131.108.7.1/24MTU1500bytes,BW1544Kbit,DLY20000usec,rely255/255,load1/255

Example5-99showstheIGRPconfigurationonR1.Thevariancecommandisconfigured,butthe

multiplierhasthewrongvalue.ThemetricfromSerial3ismorethanfivetimeslarger,whichiswhythevarianceisnotworking.IfyoumultiplythemetricvalueofSerial2(whichis8976)by5,youget44,880,whichisstillnotenoughbecausethemetricforSerial3is46,976.Example5-99ImproperlyConfiguredVarianceValue

R1#!routerigrp1variance5network131.108.0.0

Solution

Tosolvethisproblem,chooseavariancefactorthatyieldsametricthatishigherthentheonebeingusedbyanotherunequal-costpath.Forexample,whenyoumultiplythecurrentmetricof8796by6insteadof5,yougetavalueof52,776.So,anylinkthathasametricvalueoflessthan52,776willbeusedinthisunequal-cost-pathloadbalancing.Inthisexample,Serial3hasametricvalueof46,976.Becausethisnumberislessthan52,776,itisusedforloadbalancing.InExample5-99,thesecondlinkmetricismorethanfivetimeslargerthanthecurrentmetric.Example5-100showsthatbychangingthevariancevalueto6,IGRPstartsincludingthesecondpath.Example5-100CorrectingtheVarianceSoThatIGRPUsesBothPaths

R1#!routerigrp1variance6network131.108.0.0

Example5-101showsthatR1isinstallingbothpathsintheroutingtable,butwiththetrafficsharecountratioequalto5.Example5-101R1RoutingTableShowstheTrafficShareCountRatio

R1#showiproute155.155.0.0Routingentryfor155.155.0.0/16Knownvia"igrp1",distance100,metric8976Redistributingviaigrp1Advertisedbyigrp1(selforiginated)Lastupdatefrom131.108.7.2onSerial3,00:00:07agoRoutingDescriptorBlocks:*131.108.6.2,from131.108.6.2,00:00:07ago,viaSerial2Routemetricis8976,trafficsharecountis5Totaldelayis25000microseconds,minimumbandwidthis1544KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops0131.108.7.2,from131.108.7.2,00:00:07ago,viaSerial3Routemetricis46976,trafficsharecountis1Totaldelayis405000microseconds,minimumbandwidthis1544KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops0

Thetrafficsharecountratioiscalculatedbydividingtheworstmetricbythemetricofapath.Inthiscase,thepathfromSerial3isworseandhasavalueof46,976.

46,976/46,976=1forSerial346,976/8976=5forSerial2(Theresultisalwaysroundedofftothelowestinteger.)

So,inthisexample,theratiois5:1.AftereveryfivepacketsforwardedonSerial2,Serial3willbeusedforonepacket.

Chapter6.UnderstandingEnhancedInteriorGatewayRoutingProtocol(EIGRP)

ThischaptercoversthefollowingkeytopicsaboutEnhancedIGRP(EIGRP):•Metrics•EIGRPneighborrelationships•TheDiffusingUpdateAlgorithm(DUAL)•DUALfinite-statemachine•EIGRPreliabletransportprotocol•EIGRPpacketformat•EIGRPbehavior•EIGRPsummarization•EIGRPqueryprocess•DefaultroutesandEIGRP•Unequal-costloadbalancinginEIGRP

Asthesizeofnetworkgrowslarger,youcanseethattheclassicaldistancevectorroutingprotocolssuchasIGRPandRIPwon’tscaletotheneedsofthenetwork.SomeofthebiggestscalabilityproblemsofIGRPandRIPareasfollows:•Fullperiodicroutingupdatesthatconsumebandwidth—RIPsendsoutitsentireroutingtableevery30seconds;IGRPsendsoutitsentireroutingtableevery90seconds.Thisconsumessignificantbandwidth.•RIPhop-countlimitationof15hops—ThislimitationmakesRIPprotocolanon-scalableroutingprotocolintoday’snetworksbecausemostmedium-sizednetworkshavemorethan15routers.•NosupportofVLSManddiscontiguousnetworks—ThisalsohindersthecapabilitytoscalelargenetworksforRIPandIGRP.Becauseofthisfactor,routersummarizationisnotsupported.•Slowconvergencetime—BecauseRIPandIGRPsendperiodicroutingupdates,anetworkthatisnotavailableinonepartofthenetworkcouldtakeminutesfortheotherpartofthenetworktodiscoverthatit’snolongeravailable.•Not100percentloop-free—RIPandIGRPdonotkeeptopologytables,sothereisnomechanismforthemtoensurea100percentloop-freeroutingtable.

BecauseoftheseshortcomingsofIGRPandRIP,CiscodevelopedanenhancedversionofIGRPthatnotonlyfixedalltheproblemsofIGRPandRIPbutalsodevelopedaroutingprotocolrobustenoughtoscaletotoday’snetworkgrowth.ThisenhancedversioniscalledEnhancedInteriorGatewayRoutingProtocol(EIGRP).EIGRPisneitheraclassicdistancevectorroutingprotocolnoralink-stateprotocol—itisahybridofthesetwoclassesofroutingprotocol.Likeadistancevectorprotocol,EIGRPgetsitsupdatefromitsneighbors.Likealink-stateprotocol,itkeepsatopologytableoftheadvertisedroutesandusestheDiffusingUpdateAlgorithm(DUAL)toselectaloop-freepath.Theconvergencetimeinanetworkisthetimethatittakesforalltheroutersinthenetworktoagreeonanetworkchange.Theshortertheconvergencetimeis,thequickeraroutercanadapttoanetworktopologychange.Unlikeatraditionaldistancevectorprotocol,EIGRPhasfastconvergencetimeanddoesnotsendfullperiodicrouting

updates.Unlikealink-stateprotocol,EIGRPdoesnotknowwhattheentirenetworklookslike;itdependsonlyonitsneighbor’sadvertisement.BecauseEIGRPhascharacteristicsofbothdistancevectorandlink-stateprotocols,CiscohasclassifiedEIGRPasanadvanceddistancevectorroutingprotocol.AdvantagesofEIGRPincludethefollowing:•100%loop-free—EIGRPisguaranteedtohavea100percentloop-freeforwardingtableifallthenetworksarecontainedwithinoneautonomoussystem.•Easyconfiguration—ConfigurationofEIGRPisextremelyeasyandisthesameasIGRPandRIPatthebasiclevel.•Fastconvergence—ConvergencetimeforEIGRPismuchfasterthanthatforRIPandIGRP.•Incrementalupdate—InanEIGRPnetwork,noroutingupdateisexchangedexceptforanetworkchange.Also,onlythechangeisupdated,nottheentireroutingtable.ThissavesCPUpowerandismoreefficient.•Useofmulticastaddress—IGRPandRIPusethebroadcastaddressof255.255.255.255tosendtheirpackets.Thismeansthateverydeviceonthesamenetworksegmentreceivestheupdates.EIGRPsendsitspacketoverthemulticastaddressof224.0.0.10,whichensuresthatonlytheEIGRP-enableddevicesreceivetheEIGRPpackets.•Betterutilizationofbandwidth—EIGRPobtainsthebandwidthparameterfromtheinterfaceinwhichEIGRPpacketswillbesentout.Itisaparameterinwhichitsvaluesareassignedtoaparticularinterface.Forexample,bydefault,allserialinterfaceshaveabandwidthof1544kbps;however,thisbandwidthparameterisconfigurable.EIGRPcanuseupto50percentoftheinterfacebandwidthtocarryEIGRPpackets.ThisensuresthatEIGRPpacketswillnotstarvetherouteddatapacketduringamajornetworkconvergenceevent.RIPandIGRPdonothavethisfeature,sopotentiallylargeamountsofRIPorIGRPupdateswouldpreventregulardatapacketsfromgoingthrough.•SupportforVLSManddiscontiguousnetworks—UnlikeRIPandIGRP,EIGRPsupportsVLSManddiscontiguousnetworks.ThisenablesEIGRPtobeimplementedinthemodernnetworkandlendsitselftobetternetworkscalability.

MetricsEIGRPandIGRPusethesameequationtocalculatetheirmetrics;however,theEIGRPmetricisobtainedbymultiplyingtheIGRPmetricby256.Inotherwords:

EIGRPMetric=IGRPMetric×256wheretheIGRPmetricisshowninEquation6-1.Bydefault,theKvaluesofK1andK3are0;therefore,theEIGRPmetricsimplifiestothis:

EIGRPMetric=[(107/lesserbandwidthonpath)+(sumofalldelays)]×256

Equation6-1IGRPMetric

K1,K2,K3,K4,K5=ConstantsDefaultvalues:K1=K3=1,K2=K4=K5=0BW=107/(minbandwidthalongpathsinkilobitspersecond)Delay=(Sumofdelaysalongpathsinmilliseconds)/10

Load=LoadofinterfaceReli=Reliabilityoftheinterface

EIGRPisdifferentthanIGRPmetricbyafactorof256becauseoftheMetricfield:IGRPusesonly24bitsinitsupdatepacketfortheMetricfield,whereasEIGRPuses32bitsinitsupdatepacketfortheMetricfield.Thedifferenceof8bitsrequirestheIGRPmetrictobemultipliedby256toobtaintheEIGRPmetric.Forexample,iftheIGRPmetrictoadestinationnetworkis8586,theEIGRPmetricwouldbe8586×256=2,198,016.

EIGRPNeighborRelationshipsUnlikeIGRP,EIGRPmustestablishneighborrelationshipsbeforeupdatesaresentout.WhenanEIGRPprocessisconfiguredontherouter,therouterbeginstoexchangeEIGRPhellopacketsoverthemulticastaddressof224.0.0.10.Neighborrelationshipsformbetweenrouterswhentheyreceiveeachother’shellopacket.OverLANbroadcastmediasuchasEthernet,TokenRing,orFDDI,thehellopacketsaresentevery5seconds.OverWANmultipointinterfaceswithabandwidthofT1orgreater,andoverpoint-to-pointsub-interfaces,thehellopacketsarealsosentoutevery5seconds.WANmultipointinterfaceswithabandwidthofT1orlowerareconsideredtobelow-bandwidthinterfaces,andthehellopacketsaresentoutevery60seconds.Asidefromthehellotime,thereisalsoanotionofaholdtime.Theholdtimetellstherouterthemaximumtimethatitwillwaittoresetaneighborifhellopacketsarenotreceived.Inotherwords,iftheholdtimeexpiresbeforeahellopacketisreceived,theneighborrelationshipwillbereset.Thedefaultvalueoftheholdtimeisthreetimesthehellotime.ThismeansthatintheLANbroadcastmediawherethehellotimeis5seconds,theholdtimewillbe15seconds,andtheslowWANinterfaceswithahellotimeof60secondswillhaveadefaultholdtimeof180seconds.Keepinmindthatyoucanconfigurethehelloandholdtimes.CertainconditionsmustbemetbeforeEIGRProutersconsiderestablishinganeighborrelationship:•ThereceivingroutercomparesthesourceaddressofthehellopacketwiththeIPaddressoftheinterfacewherethepacketwasreceived,toensurethattheybelongtothesamesubnet.•ThereceivingroutercomparestheKconstantvaluesofthesourceroutertoitsown,tomakesurethattheymatch.•Thereceivingroutermustbewithinthesameautonomoussystemnumberasthesourcerouter.

Example6-1showstheoutputoftheshowipeigrpneighborcommandwhentheneighborrelationshipisfullyestablished.Example6-1showipeigrpneighborCommandOutput

Router_1#showipeigrpneighborIP-EIGRPneighborsforprocess1HAddressInterfaceHoldUptimeSRTTRTOQSeq(sec)(ms)CntNum15.5.5.4Et01100:00:2214500030192.168.9.5Et11000:00:23372223202

Theexplanationsoftheheadingoftheoutputareasfollows:•H—Thelistoftheneighborsintheorderinwhichtheyarelearned.•Address—TheIPaddressoftheneighbors.•Interface—Theinterfacefromwhichtheneighborsarelearned.

•Hold—Theholdtimerfortheneighbor.Ifthistimerreaches0,theneighborrelationshipistorndown.•Uptime—Thetimerthattrackshowlongthisneighborhasbeenestablished.•SRTT(SmoothRoundTripTime)—TheaveragetimeinwhichareliableEIGRPpacketissentandreceived.•RTO(RoundTripTimeout)—HowlongtherouterwillwaittoretransmittheEIGRPreliablepacketifacknowledgmentisnotreceived.•QCount—ThenumberofEIGRPpacketswaitingtobesenttotheneighbor.•SequenceNumber—ThesequencenumberofthelastEIGRPreliablepacketsbeingreceivedfromtheneighbor.Thisistoensurethatpacketsreceivedfromtheneighborareinorder.

TheDiffusingUpdateAlgorithmTheDiffusingUpdateAlgorithm(DUAL)isthebrainbehindtheoperationofEIGRP.Itisanalgorithmthattracksalltheroutesadvertisedfromaneighborandthenselectsaloop-freepathtothedestination.BeforediscussingthedetailsofDUAL,youmustunderstandseveraltermsandconcepts:•Feasibledistance(FD)—Feasibledistanceistheminimummetricalongthepathtoadestination.Figure6-1showsthefeasibledistancecalculationtoreachNetwork7foreachofRouterA’sneighbors,fromRouterA’sperspective.

Figure6-1FeasibleDistanceCalculation

•Reporteddistance(RD)—Reporteddistance,sometimesalsoknownasadvertiseddistance,isthemetrictowardthedestination,asadvertisedbytheupstreamneighbor.Inotherwords,thereporteddistanceistheneighbor’smetricgoingtothedestination.Figure6-2showsthereporteddistancecalculationtoreachNetwork7foreachofRouterA’sneighbors.

Figure6-2ReportedDistanceCalculation

•Feasibilitycondition(FC)—Thefeasibilitycondition(FC)isaconditioninwhichthereporteddistance(RD)islessthanthefeasibledistance(FD).Inotherwords,thefeasibilityconditionismetwhentheneighbor’smetrictoadestinationislessthanthelocalrouter’smetric.Thisconditionisimportanttoensurealoop-freepath.•EIGRPsuccessor—Asuccessorisaneighborthatmetthefeasibilitycondition(FC)andhasthelowestmetrictowardthedestination.Asuccessorisusedasthenexthoptoforwardthepacketgoingtothedestinationnetwork.•Feasiblesuccessor—Afeasiblesuccessorisaneighborthatsatisfiesthefeasibilitycondition(FC)butisnotselectedasthesuccessor.Thefeasiblesuccessorcanbethoughtofasapotentialbackuproutewhentheprimaryroutegoesaway.Figure6-3illustratestheconceptsofsuccessorandfeasiblesuccessor.

Figure6-3ExplanationofSuccessorandFeasibleSuccessor

RouterBischosenasthesuccessorbecauseRouterBhasthelowestfeasibledistance(metric=121)toNetwork7amongallofRouterA’sneighbors.Toselectafeasiblesuccessor,RouterAseeswhichneighborhasareporteddistance(RD)thatislessthanthefeasibledistanceofitssuccessor.Inthiscase,RouterHhasareporteddistanceof30,whichislessthanthefeasibledistanceofitssuccessor,whichis121.Therefore,RouterHischosenasthefeasiblesuccessor.RouterDisneitherasuccessornorafeasiblesuccessorbecauseitsreporteddistanceis140,whichislargerthan121andthusdoesnotsatisfiesthefeasibilitycondition.•Passiveroute—ApassiverouteinEIGRPindicatesthattherouterhasavalidsuccessortoadestinationandEIGRPhasnocomplaints.•Activeroute—AnactiverouteinEIGRPindicatesthattherouterhaslostitssuccessor,itdoesn’thaveanyfeasiblesuccessoravailable,andtherouteriscurrentlyactivelysearchingforalternateroutestoconverge.

DUALFinite-StateMachineWhenEIGRPlosesitssuccessororprimaryroute,EIGRPimmediatelytriestoreconvergebylookingatitstopologytabletoseeifanyfeasiblesuccessorsareavailable.Ifafeasiblesuccessorisavailable,EIGRPimmediatelypromotesthefeasiblesuccessortoasuccessorandinformsitsneighborsaboutthechange.ThefeasiblesuccessorthenbecomesthenexthopforEIGRPtoforwardthepacketstothedestination.TheprocessbywhichEIGRPconvergeslocallyanddoesnotinvolveotherroutersintheconvergenceprocessiscalledlocalcomputation.ThisalsosavesCPUpowerbecauseallthefeasiblesuccessorsarealreadychosenbeforetheprimaryroutefailures.(RefertoFigure6-3.)Iftheprimaryroute(RouterD)isnotavailableforsomereason,thepreselectedfeasiblesuccessorRouterHimmediatelytakesoverastheprimaryroute.

Now,iftheprimaryroutegoesawayandnofeasiblesuccessorsareavailable,theroutergoesintodiffusedcomputation.Indiffusedcomputation,theroutersendsquerypacketstoallitsneighborsaskingforthelostroute,andtheroutergoesintoActivestate.Ifneighboringroutershaveinformationaboutthelostroute,theyreplytothequeryingrouter.Ifneighboringroutersdonothaveinformationaboutthelostroute,theysendqueriestoalltheirneighbors.Iftheneighboringrouterdoesnothaveanalternaterouteanddoesn’thaveanyotherneighbors,itsendsareplypacketbacktotherouterwithametricsettoinfinity,indicatingthatit,too,doesn’thaveanalternaterouteavailable.Thequeryingrouterwaitsforalltherepliesfromallitsneighborsandthenchoosestheneighborwiththebestmetricinitsrepliesasthenexthoptoforwardpackets.ReferringtoFigure6-3,iftheprimarysuccessorRouterBisnotavailableanditsfeasiblesuccessorRouterHisalsonotavailable,RouterAsendsaquerytoRouterDaskingforNetwork7.Inthiscase,RouterDsimplyrepliestothequerywithavalidmetrictoNetwork7.RouterAthenconvergesusingRouterDasitsnexthoptoNetwork7.TosumuptheoperationofDUAL,DUALselectsasuccessorastheprimarypathandalsoselectsafeasiblesuccessorasitsbackuppathbasedonthefeasibilitycondition.Ifthesuccessorbecomesunavailable,thefeasiblesuccessorisusedastheprimaryroute.Ifthefeasiblesuccessorisnotpresent,therouterqueriesallitsneighborsandcomputesanewsuccessorbasedontherepliestothequeries.Therefore,inanEIGRPnetwork,thequerymechanismistheonlymeanstoachievefastconvergence.Chapter8oftheCiscoPressbookRoutingTCP/IP,Volume1,byJeffDoyle,providesanexcellent,detaileddescriptionoftheoperationoftheEIGRPDUALalgorithm.

EIGRPReliableTransportProtocolFivetypesofEIGRPpacketsexist,furthercategorizedasreliablepacketsandunreliablepackets.ThereliableEIGRPpacketsareasfollows:•Update—UpdatepacketscontainEIGRProutingupdatessenttoanEIGRPneighbor.•Query—Queriesaresenttoneighborswhenarouteisnotavailableandtherouterneedstoaskthestatusoftherouteforfastconvergence.•Reply—Replypacketstothequeriescontainthestatusoftheroutebeingqueriedfor.

TheunreliableEIGRPpacketsareasfollows:•Hello—HellopacketsareusedtoestablishEIGRPneighborrelationshipsacrossalink.•Acknowledgment—AcknowledgmentpacketsensurereliabledeliveryofEIGRPpackets.

AlltheEIGRPpacketsaresentthroughEIGRPmulticastaddress224.0.0.10.EveryEIGRP-enableddeviceautomaticallylistenstothe224.0.0.10address.BecausethisisamulticastaddressandmultipledevicesreceivetheEIGRPpacketsatonce,EIGRPneedsitsowntransportprotocoltoensurereliabledeliveryofEIGRPpackets.ThisprotocolistheEIGRPReliableTransportProtocol(RTP).Therouterkeepsatransmissionlistforeveryneighbor.WhenareliableEIGRPpacketissenttotheneighbor,thesendingrouterexpectsanacknowledgmenttobesentbackfromtheneighborindicatingthatthereliableEIGRPpackethasbeenreceived.EIGRPRTPmaintainsthetransportwindowsizeofonlyoneunacknowledgedpacket.Therefore,everysinglereliablepacketmustbeacknowledgedbeforethenextreliableEIGRPpacketcanbesentout.Therouterretransmitstheunacknowledgedpacketuntilanacknowledgmentisreceived.Ifnoacknowledgmentisreceived,EIGRPRTPretransmitsthesamepacketupto16times.Ifnoacknowledgmentisreceivedafter16retransmissions,EIGRPresetstheneighborrelationship.InamultiaccessLANnetwork,sendingamulticastupdatecouldposeaproblemifthetransportwindow

sizeis1.Asdiscussedpreviously,withreliablemulticasttraffic,thenextreliablemulticastpacketisnottransmitteduntilallpeershaveacknowledgedthepreviousmulticastpacket.IfoneormoreEIGRPneighborsinamultiaccessLANnetworkaresloworfailtoacknowledgetheEIGRPpacket,alltheotherneighborswillsufferfromthis.Forexample,iftherearethreeroutersonanEthernetsegmentandRouter1sendsamulticastEIGRPupdate,itwon’tsendanothermulticastEIGRPpacketontheEthernetuntilitreceivesanacknowledgmentfromtheothertworouters.NowassumethatRouter2successfullysendsanacknowledgmentpackettoRouter1,butRouter3hasaproblemsendingtheacknowledgmentpacket.Router1couldpotentiallystopsendinganymoreEIGRPpackets,andRouter2wouldbeaffectedeventhoughtheproblemliesonRouter3.EIGRPRTPavoidsthisproblembyretransmittingtheunacknowledgedEIGRPpacketasaunicastpackettotheneighborthathasnotacknowledgedthepreviousEIGRPpacket,anditcontinuestosendEIGRPmulticastpacketstotheneighborthathasalreadyacknowledgedtheEIGRPpacket.TherouterretransmitstheunacknowledgedEIGRPpacketasaunicast16timestoaneighbor.IftheneighborstillhasnotacknowledgedtheEIGRPpacketafter16retries,EIGRPresetstheneighborrelationshipandthewholeprocessstartsover.The16-retrytimeoutperiodusuallyrunsfrom50to80seconds.

EIGRPPacketFormatFigure6-4showstheEIGRPpacketheader.NoticethatfollowingtheautonomoussystemsnumberaretheType/Length/Value(TLV)triplets.TheTLVtripletscarryrouteentries,aswellasprovidethefieldsforDUALprocessmanagement.SomecommonTLVsaretheEIGRPparameterTLV,theIPinternalrouteTLV,andtheIPexternalrouteTLV.

Figure6-4EIGRPPacketHeader

TheEIGRPpacketparametersaredescribedasfollows:•Version—SpecifiesdifferentversionsofEIGRP.Version2ofEIGRPwasimplementedbeginningwithCiscoIOSSoftwareReleases10.3(11),11.0(8),and11.1(3).EIGRPVersion2isthemostrecentversionthatcontainsmanyenhancementstoimprovethestabilityandscalabilityofEIGRP.

•Opcode—SpecifiesthetypesofEIGRPpacketcontained.Opcode1istheupdatepacket,opcode3istheQuery,opcode4isthereply,andopcode5istheEIGRPhellopacket.•Checksum—UsedastheregularIPchecksum,calculatedbasedontheentireEIGRPpacket,excludingtheIPheader.•Flags—Involvesonlytwoflagsnow.TheflagindicateseitheraninitfornewneighborrelationshiportheconditionalreceiveforEIGRPRTP.•Sequence—SpecifiesthesequencenumberusedbytheEIGRPRTP.•Acknowledgment—UsedtoacknowledgethereceiptofanEIGRPreliablepacket.•AutonomousSystemNumber—SpecifiesthenumberfortheidentificationofEIGRPnetworkrange.

OneofthemostcommonEIGRPTLVsistheEIGRPparameterTLV,asshowninFigure6-5,whichcontainstheparameterneededtoestablishaneighborrelationship.TheconstantKvaluesareincludedinthisTLV,aswellastheholdtime.TheKvaluesbetweentworoutersmustagreebeforetheycanestablishaneighborrelationship.

Figure6-5EIGRPParametersTLV

Figure6-6andFigure6-7showtwoothercommonEIGRPTLVs—theIPinternalrouteTLVandtheIPexternalrouteTLV,respectively.TheEIGRPinternalroutesareroutesoriginatedfromthesameEIGRPautonomoussystemnumberasthereceivingrouter.TheEIGRPexternalroutesareroutesthatarebeingredistributedintotheEIGRPautonomoussystems.

Figure6-6EIGRPIPInternalRouteTLV

Figure6-7EIGRPIPExternalRouteTLV

TheEIGRPIPinternalrouteTLVcontainsthisinformation:•Nexthop—IPaddressofthenexthoptowhichpacketsshouldbeforwarded.•Delay—Delayparameteroftheroutemetric.Thedelayvalueisthesumofallthedelayparametersontheinterfaceacrossthepathtothedestinationnetwork.•Bandwidth—Bandwidthparameteroftheroutemetric.Thebandwidthisobtainedfromtheinterface,anditisthelowestbandwidthontheinterfaceacrossthepathtothedestinationnetwork.•MTU—TheinterfaceMTUparameteroftheroutemetric.•Hopcount—Numberofhopstothedestinationnetwork.•Reliability—Thereliabilityoftheinterface,outofapossiblerangeof1to255.Areliabilityof1indicatesthatthereliabilityis1/255,whereasareliabilityof255indicatesthattheinterfaceis100percentreliable.•Load—Theloadoftheinterface,outofapossiblerangeof1to255.Aloadvalueof1indicatesthattheinterfacehasaverylightload,whilealoadvalueof255indicatesthattheinterfaceishighlysaturated.

•Prefixlength—Thesubnetmaskofthedestinationnetwork.InEIGRPIPexternalrouteTLV,moreinformationoftherouteisincluded:•Originatingrouter—TherouterIDoftherouterthatoriginatestheexternalEIGRProutes.•Originatingautonomoussystemnumber—TheEIGRPautonomoussystemnumberoftheroutesbeforegettingredistributedintothisEIGRPautonomousnumber.•Externalprotocolmetric—ThemetricoftheroutesbeforegettingredistributedintoEIGRP.•ExternalprotocolID—ThetypeofroutingprotocolthatoriginatestheroutesthatwereredistributedintoEIGRP.TheroutingprotocoltypecanbeBGP,OSPF,RIP,IGRP,andsoforth.

EIGRPBehaviorUnlikeIGRP,EIGRPisanadvanceddistancevectorprotocolthatcarriesthesubnetmaskinformationwhenanupdateissentout.Therefore,EIGRPsupportsdiscontiguousnetworkandvariable-lengthsubnetmasking(VLSM).FormoreexplanationaboutdiscontiguousnetworksandVLSM,refertoChapter2,“UnderstandingRoutingInformationProtocol(RIP).”Figure6-8showsthenetworkdiagramthatillustratesEIGRP’ssupportfordiscontiguousnetworks.

Figure6-8ExampleofEIGRPSupportforDiscontiguousNetworks

Figure6-8showstworoutersconnectedthroughaserialport.RouterBhasthenetwork192.168.8.128/25thatneedstoadvertisetoRouterAacrossthenetwork10.1.1.0/24.Bydefault,EIGRPisaclassfulroutingprotocol;RouterBwillautosummarizetherouteacrossthemajornetworkboundary.Therefore,RouterBwilladvertise192.168.8.0/24toRouterA,whichwillignorethisrouteadvertisement.TomakeEIGRPsupportdiscontiguousnetworks,youmustconfigurethenoauto-summarycommandunderthecommandroutereigrp.Withthenoauto-summarycommandinplaceinRouterB,RouterBwilladvertisethe192.168.8.128/25routetoRouterA,andRouterAwillhavearoutingentryfortheroute.Theproblemwithdiscontiguousnetworkthenwillbesolved.

EIGRPSummarizationTwotypesofsummarizationtakeplaceinEIGRP—autosummarizationandmanualsummarization.AutosummarizationisthedefaultbehaviorforEIGRP,justasitisforRIPandIGRP.Basically,whentheroutersendsoutaroutingupdate,itautomaticallysummarizestheroutetoitsnaturalmajornetworkwhentherouteisadvertisedacrossamajornetworkboundary.Figure6-9showsanexampleofautosummarization.InFigure6-9,RouterR1needstosendanupdateaboutthenetwork132.168.1.0toR2acrossamajornetworkof192.168.2.0.R1thenautosummarizestheupdatetoitsclassfulnetworkof132.168.0.0andsendsittoR2.Theproblemofautosummarizationisthatthedesignofthenetworkcannotbediscontiguous.

Figure6-9ExampleofAutosummarization

ManualsummarizationinEIGRPisconfigurableonaper-interfacebasisinanyrouterwithinthenetwork.ThecommandforEIGRPmanualsummarizationisipsummary-addresseigrpautonomous-system-numberaddressmask.WithEIGRP,summarizationcanbedoneonanyinterfaceandanyrouterinthenetwork,comparedtoOSPF,whichcansummarizeonlyonanareaborderrouter(ABR)andanautonomoussystemborderrouter(ASBR).Whenmanualsummarizationisconfiguredontheinterface,therouterwillimmediatelycreatearoutetonull0withanadministrativedistanceof5.Thisistopreventroutingloopsofsummaryaddress.Finally,whenthelastspecificrouteofthesummarygoesaway,thesummaryrouteisdeleted.Example6-2showstheconfigurationforEIGRPmanualsummarizationforthenetworkinFigure6-10.

Figure6-10EIGRPManualSummarizationExample

Example6-2ConfiguringEIGRPManualSummarization

interfaces0ipaddress192.168.11.1255.255.255.252ipsummary-addresseigrp1192.168.8.0255.255.252.0

Example6-2demonstrateshowR1inFigure6-10issummarizingaddressesof192.168.8.0/24,192.168.9.0/24,and192.168.10.0/24intooneupdateof192.168.8.0/22.SummarizationinEIGRPreducesthesizeoftheroutingtableandthenumberofupdates.Italsolimitsthequeryrange,whichiscrucialintermsofmakingalargeEIGRPnetworkmorestableandmorescalable.

EIGRPQueryProcessAlthoughEIGRPisanadvanceddistancevectorroutingprotocolandconvergencetimeislow,anEIGRProuterstillreliesonitsneighbortoadvertiseroutinginformation.Toachievefastconvergence,EIGRPcan’trelyonaflushtimerlikeIGRP.EIGRPneedstoactivelysearchforthelostroutesforfastconvergence.Thisprocessiscalledthequeryprocess,anditwasbrieflydiscussedinthepreviousfewsections.Inthequeryprocess,queriesaresentwhentheprimaryrouteislostandnofeasiblesuccessorsareavailable.Atthisstage,therouteissaidtobeintheActivestate.

Queriesaresentouttoalltheneighborsandonallinterfacesexceptfortheinterfacetothesuccessor.Iftheneighboringroutersdonothavethelostrouteinformation,morequeriesaresenttotheneighboringrouters’neighborsuntilthequeryboundaryisreached.Queryboundaryconsistsofeithertheendofthenetwork,thedistributelistboundary,orthesummarizationboundary.Thedistributelistandsummarizationboundariesaredefinedbytherouterthathasthedistributelistorsummarizationconfigured.Whenthequeriesaresent,theroutermustwaitforalltherepliesfromtheneighborsbeforetheroutercalculatesthesuccessorinformation.Ifanyneighborfailstoreplyinthreeminutes,therouteissaidtobestuckinactive(SIA),andtheneighborrelationshipoftherouterthatdidn’treplytothequeryisreset.Chapter7,“TroubleshootingEIGRP,”addressestheSIAproblemandtellshowtotroubleshootitingreaterdetail.

DefaultRoutesandEIGRPUnlikeIGRP,EIGRPrecognizesthe0.0.0.0/0routeasthedefaultrouteandallowsittoberedistributedintoEIGRPdomainasthedefaultroute.EIGRPalsousesitsownmethodofpropagatingthedefaultroutewiththeipdefault-networkcommand,justasinIGRP.Theipdefault-networkcommandworksexactlythesameasitdoesinIGRP.Theipdefault-networkcommandspecifiesamajornetworkaddressandflagsitasadefaultnetwork.Thismajornetworkcouldbedirectlyconnected,definedbyastaticroute,ordiscoveredbyadynamicroutingprotocol.Figure6-11demonstrateshowtheipdefault-networkcommandworks.

Figure6-11PropagatingaDefaultRouteforIGRP

InFigure6-11,Router1isconnectedtotheremotesitethroughaDS-3link.Router1nowwantstosendadefaultroutetoRouter2andtoalltheroutersintheremotesitenetwork.InIGRP,therouteto0.0.0.0isnotrecognizedasadefaultroute;instead,Router1mustconfigureipdefault-network192.168.1.0toflagtheroute192.168.1.0asthedefaultroute.Router1willsendoutroutingupdateof192.168.1.0andwillflagitasadefaultroute.Whentheroutersintheremotesitenetworkreceivetheupdatefor192.168.1.0,theywillmarkitasdefaultrouteandwillinstalltherouteto192.168.1.0asthegatewayoflastresort.

Unequal-CostLoadBalancinginEIGRPEIGRPandIGRPusethesameequationtocalculatetheirmetrics,andtheysharethesamebehaviorwhenitcomestounequal-costloadbalancing.EIGRPalsocaninstalluptosixparallelequal-costpathsforloadbalancing,likeIGRPcan,andEIGRPalsousesthesamevariancecommandasIGRPtodounequal-costpathloadbalancing.ConsiderthenetworkinFigure6-12.

Figure6-12Unequal-CostLoadBalancingExample

Remembertherulesformultipathoperation:•Theneighboringrouterutilizedasanalternatepathwaymustbeclosertothedestination(thatis,itmustbeadvertisingasmallermetricthanthatofthelocalrouterforagivendestination).It’snotpossibletogobacktogoforward.•Themetricadvertisedbytheneighbormustbelessthanthevarianceofthelocalrouter’smetric.Variance=VarianceFactor×LocalMetric.

WhenRouter1calculatesitsEIGRPmetricstoRouter3,themetricgoingthroughthe1544kbpslinkisasfollows:

EIGRPmetric=256(6476+2100)=2,195,456

Themetricgoingthroughthe256kbpslinkisasfollows:

EIGRPmetric=256(39,062+2100)=10,537,472

Withoutunequal-costloadbalancing,EIGRPwillsimplyselectthe1544kbpslinktoforwardpacketstoRouter3,asshownintheoutputinExample6-3.Example6-3showiprouteOutputShowsRouter1ChoosingaSuboptimalRouteWithoutUnequal-CostLoadBalancing

Router_1#showiproute133.33.0.0Routingentryfor133.33.0.0/16Knownvia"eigrp1",distance90,metric2195456Redistributingviaeigrp1Advertisedbyeigrp1(selforiginated)Lastupdatefrom192.168.6.2onSerial0,00:00:20agoRoutingDescriptorBlocks:*192.168.6.2,from192.168.6.2,00:00:20ago,viaSerial0Routemetricis2195456,trafficsharecountis1Totaldelayis21000microseconds,minimumbandwidthis1544KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops0

Tousetheunequal-costload-balancingfeatureofEIGRP,youusethevariancecommand.Varianceisamultiplierinwhichametricmaybedifferentfromthelowestmetrictoaroute.Thevariancevaluemustbeofintegervalue;thedefaultvariancevalueis1,meaningthatthemetricsofmultipleroutesmustbeequaltoload-balance.InExample6-3,themetricthroughthe256kbpslinkis4.8timeslargerthanthemetricthroughthe1544kbpslink.Therefore,forthe256kbpslinktobeconsideredintheroutingtable,avarianceof5mustbeconfiguredinRouter1.TheconfigurationinRouter1issimplyvariance5undertheroutereigrp

command.TheoutputfromtheshowiproutecommandinExample6-4displaysthatRouter1isinstallingbothlinksinitsroutingtable.Example6-4ExampleOutputofUnequal-CostLoadBalancinginEIGRP

Router_1#showiproute133.33.0.0Routingentryfor133.33.0.0/16Knownvia"eigrp1",distance90,metric2195456Redistributingviaeigrp1Advertisedbyeigrp1(selforiginated)Lastupdatefrom10.1.1.2onSerial1,00:01:02agoRoutingDescriptorBlocks:*192.168.6.2,from192.168.6.2,00:01:02ago,viaSerial0Routemetricis2195456,trafficsharecountis5Totaldelayis21000microseconds,minimumbandwidthis1544KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops010.1.1.2,from10.1.1.2,00:01:02ago,viaSerial1Routemetricis10537472,trafficsharecountis1Totaldelayis21000microseconds,minimumbandwidthis256KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops0

InExample6-4,theroutethroughSerial0hasatrafficsharecountof5,comparedtoatrafficsharecountof1throughSerial1.ThisindicatesthattherouterwillsendfivepacketsoverSerial0foreverypacketsentoverSerial1.

SummaryEIGRPandIGRParesimilarinsomeways,buttheydifferinotherways.EIGRPandIGRPusethesameequationtocalculatemetricstothedestinationnetwork.EIGRPandIGRPalsousethesametechniqueindoingunequal-costloadbalancing.However,EIGRPkeepsatopologytableofthenetworkandusestheDUALalgorithmtoselectaloop-freepath.EIGRPusesthenotionsofsuccessorandfeasiblesuccessorandthequeryprocesstoachievefastconvergence.EIGRPalsocarriesthesubnetmaskinformationwhensendingoutroutingupdate.ThisenablesEIGRPtosupportdiscontiguousnetworksandVLSM,whichmakesEIGRPascalableroutingprotocolcapableoffittingtoday’snetworkrequirements.Table6-1showsthesummarycomparisonbetweenIGRPversusEIGRP.

Table6-1ComparisonTableofIGRPVersusEIGRP

ReviewQuestions1WhatisthedifferencebetweenmetriccalculationsinIGRPversusEIGRP?2WhatisanEIGRPquery,andwhatisitusedfor?3Whatisthemeaningofthetermactiveroute?4Whatisafeasiblesuccessor?5WhatisEIGRP’smulticastaddress?6Whatisthefeasiblecondition?7Whatisstuckinactive?

Chapter7.TroubleshootingEIGRP

ThischaptercoversthefollowingEIGRPtroubleshootingtopics:•TroubleshootingEIGRPneighborrelationships•TroubleshootingEIGRProuteadvertisement•TroubleshootingEIGRProuteinstallation•TroubleshootingEIGRProuteflap•TroubleshootingEIGRProutesummarization•TroubleshootingEIGRProuteredistribution•TroubleshootingEIGRPdialbackup•EIGRPerrormessages

ThischapterdiscussessomeofthecommonproblemsinEIGRPandhowtoresolvethoseproblems.Debugs,configurations,andusefulshowcommandsarealsogivenwherenecessary.

NoteDebugscanbeCPU-intensiveandcanadverselyaffectyournetwork.Therefore,debugsarenotrecommendedonaproductionnetworkunlessbeinginstructedbyCisco’sTechnicalAssistanceCenter(TAC).

Sometimes,theremightbemultiplecausesforthesameproblem.Therefore,ifonescenariodoesn’tfixthenetworkproblem,alwayscheckintootherscenarios.

TroubleshootingEIGRPNeighborRelationshipsThissectiondiscussesmethodsoftroubleshootingissuesregardingEIGRPneighborrelationships.ThefollowingarethemostcommoncausesofproblemswithEIGRPneighborrelationships:•Unidirectionallink•Uncommonsubnet,primary,andsecondaryaddressmismatch•Mismatchedmasks•Kvaluemismatches•MismatchedASnumbers•Stuckinactive•Layer2problem•Accesslistdenyingmulticastpackets•Manualchange(summaryrouter,metricchange,routefilter)

Figure7-1illustratesageneraltroubleshootingflowchartonEIGRPneighborrelationships.

Figure7-1GeneralFlowchartonTroubleshootingEIGRPNeighborRelationships

ConsultingtheEIGRPLogforNeighborChangesWheneverEIGRPresetsitsneighborrelationship,itisnotedinthelogwiththereasonforthereset.IntheearlierCiscoIOSSoftwarereleases,configurationtoenablethisfeatureisrequired.Thecommandeigrplog-neighbor-changeisconfiguredunderrouterEIGRP.InCiscoIOSSoftwareRelease12.1.3andlater,theeigrplog-neighbor-changecommandbecomesthedefaultsettingfortherouter.AnexampleoftheEIGRPneighborloglookssomethinglikethis:

%DUAL-5-NBRCHANGE:IP-EIGRPEIGRPASnumber:NeighborneighborIPaddressisdown:reasonforneighbordown.

Table7-1documentstheneighborchangesthatyoucanfindintheEIGRPlog,alongwiththemeaningandrequiredactiontofixtheproblembasedonthelogmessage.

Table7-1NeighborChangesDocumentedintheEIGRPLog

Figure7-2FlowchartforTroubleshootingEIGRPNeighborRelationshipWhenGettingNeighborLogMessageHOLDTIMEEXPIRED

EIGRPNeighborProblem—Cause:UnidirectionalLinkSometimes,aproblemwithaWANconnectioncausesEIGRPtohaveaone-wayneighborrelationship.Aone-wayneighborrelationshipusuallyiscausedbyaunidirectionalconnectionbetweentheneighbors.ThecauseforunidirectionalconnectionisusuallyaLayer2problem.Forexample,alinkmightbeexperiencingmanyCRCerrors,aswitchproblem,orapingtestfailurewithlargeorsmallpackets.Inthiscase,youneedacalltothegroupthatisresponsibleforthelinktochecktheintegrityofthelink.Sometimes,asimplemisconfiguredaccesslistcausesEIGRPtoformaone-wayneighborrelationship.Figure7-4illustratesanexampleofanEIGRPproblemasaresultofaunidirectionallink.

Figure7-3FlowchartforTroubleshootingEIGRPNeighborRelationshipWhenGettingNeighborLogRETRYLIMITEXCEEDED

Figure7-4NetworkTopologyVulnerabletoanEIGRPNeighborProblemBecauseofaUnidirectionalLink

InFigure7-4,RoutersRTRAandRTRBareconnectedbyaWANconnection.ThecircuitfromRTRAtoRTRBisfine,butthecircuitfromRTRBtoRTRAisbroken.TheresultsfromtheshowipeigrpneighborcommandonRTRAwillnotshowanythingbecauseRTRB’sEIGRPhellopacketcan’tmakeittoRTRA.Example7-1showstheoutputfromshowipeigrpneighboronRTRB.Example7-1showipeigrpneighborsCommandOutputonRTRB

RtrB#showipeigrpneighborsIP-EIGRPneighborsforprocess1HAddressInterfaceHoldUptimeSRTTRTOQSeq(sec)(ms)CntNum110.88.18.2S01400:00:150500040

RTRBshowsRTRAasaneighborbecauseRTRA’sEIGRPhellopackethasnoproblemreachingRTRB.Fromtheoutputoftheshowcommand,theSRTTisat0ms,theretransmissiontimeout(RTO)timerisat5000ms,andtheQcountisat4andisnotdecrementing.Thesethreenumbersgivethebiggestcluethatthisisaunidirectionallinkproblem.ThefollowingisthemeaningofSRTT,RTO,andQcount:•Smoothround-triptime(SRTT)—ThenumberofmillisecondsittakesforanEIGRPpackettobesenttothisneighborandforthelocalroutertoreceiveanacknowledgmentofthatpacket•Retransmissiontimeout(RTO),inmilliseconds—Theamountoftimethatthesoftwarewaitsbeforeretransmittingapacketfromtheretransmissionqueuetoaneighbor•Qcount—ThenumberofEIGRPpackets(Update,Query,andReply)thatthesoftwareiswaitingtosend

ReferringtoExample7-1,thefactthattheSRTTtimeris0indicatesthatnoacknowledgementpacketsarebeingreceived.TheQcountisnotdecrementing,whichindicatesthattherouteristryingtosendEIGRPpacketsbutnoacknowledgementisbeingreceived.RTRBwillretry16timestoresendthepacket;eventually,RTRBwillresettheneighborrelationshipwiththelogindicatingRETRYLIMITEXCEEDED,andtheprocessstartsagain.Also,keepinmindthatthe16timesretransmissionofthesamepacketisdoneusingunicast,notmulticast.Therefore,theRETRYLIMITEXCEEDEDmessageindicatesaproblemwithtransmittingunicastpacketsoverthelink,andthisismostlikelyaLayer1orLayer2problem.ThesolutiontothisproblemistotroubleshootfromaLayer2perspective.Inthisexample,acalltotheWANproviderisneededtofindoutwhythecircuitfromRTRBtoRTRAisbroken.AfterthelinkbetweenRTRBtoRTRAisfixed,theproblemwillberesolved.OutputfromshowipeigrpneighborsinExample7-2showsthattheneighborrelationshipaftertheWANlinkhasbeenfixed.Example7-2showipeigrpneighborsCommandOutputConfirmsProblemResolution

RtrB#showipeigrpneighborsIP-EIGRPneighborsforprocess1HAddressInterfaceHoldUptimeSRTTRTOQSeq(sec)(ms)CntNum110.88.18.2S01401:26:301498940291

NoticethattheQcountcolumnis0andthattheSRTTandRTOhavevalidvaluesnow.

EIGRPNeighborProblem—Cause:UncommonSubnetManytimes,EIGRPwon’testablishneighborrelationshipsbecausetheneighborsarenotinthesamesubnet.Usually,thecauseofthisproblemisroutermisconfiguration.WhenEIGRPhasproblemsestablishingneighborrelationshipsbecauseofanuncommonsubnet,thefollowingerrormessageappears:

IP-EIGRP:Neighboripaddressnotoncommonsubnetforinterface

Figure7-5showstheflowchartfortroubleshootingtheproblemwhenthe“Neighbornotoncommonsubnet”errorappearsontherouter.

Figure7-5Problem-ResolutionFlowchart

AccordingtothetroubleshootingflowchartinFigure7-5,thethreecausesofgettingthe“EIGRPneighbornotoncommonsubnet”errormessagearethefollowing:•TheIPaddresshasbeenmisconfiguredoninterfaces.•TheprimaryandsecondaryIPaddressesoftheneighboringinterfacedon’tmatch.•AswitchorhubbetweentheEIGRPneighborconnectionismisconfiguredorisleakingmulticastpackettootherports.

MisconfigurationoftheIPAddressontheInterfaces

Sometimes,anEIGRPneighborthatisnotonacommonsubnetwithotherEIGRPneighborsissimplytheresultofmisconfiguringtheIPaddressontheinterfaces.Forexample,thenetworkadministratormightmistypeIPaddress192.168.3.1255.255.255.252as192.168.3.11255.255.255.252,whichcausesEIGRPtocomplainabouttheneighbornotbeingonacommonsubnet.

PrimaryandSecondaryIPAddressesoftheNeighboringInterfaceDon’tMatch

AsmentionedinChapter6,“UnderstandingEnhancedInteriorGatewayRoutingProtocol(EIGRP),”EIGRPsourcesthehellopacketfromtheprimaryaddressoftheinterface.Iftheprimarynetworkaddressononerouterisusedasasecondarynetworkaddressonthesecondrouter,andviceversa,noneighborrelationshipwillbeformedandtherouterswillcomplainabouttheneighbornotbeingonacommonsubnet.Figure7-6illustratessuchascenario.

Figure7-6NetworkTopologyVulnerabletoEIGRPNeighborProblemsBecauseofPrimaryandSecondaryIPAddressMismatch

InFigure7-6,RouterAandRouterBhaveaprimaryaddressinthe10.1.1.0/24networkrange,whileRouterChasanaddressrangeof50.1.1.0/24configured.WhenRouterAorRouterBsendsouttheEIGRPhellopacket,thesourceofthehellopacketwillbeeither10.1.1.1or10.1.1.2,dependingonwhichroutersendsoutthehello.WhenRouterCreceivesthehellopacketfromRouterAorRouterB,itnoticesthatthesourceisfromthe10.1.1.0network.BecauseRouterChasanIPaddressof50.1.1.3configuredontheinterface,RouterCwillnotprocessthehellopacketfromRouterAorRouterBbecausetheyarefromadifferentnetwork.Therefore,noneighborrelationshipisformedfromRouterCtoeitherRouterAorRouterB.ThesolutionforthisexampleistomatchalltheIPaddressesonthesegmenttotheprimaryaddressspace.ForthenetworkinFigure7-6,youneedtoconfigureRouterCtobeintheprimaryaddressspaceof10.1.1.0/24.SwitchorHubBetweenEIGRPNeighborConnectionIsMisconfiguredorIsLeakingMulticastPacketstoOtherPorts

IftheIPaddressconfigurationiscorrectontheinterfacebetweenEIGRPneighbors,youmightwanttochecktheconfigurationontheswitchorthehubthatconnectstheEIGRPneighbors.IfasingleLANhubconnectstheEIGRPneighborsfordifferentLANsegment,thehubpassesbroadcastandmulticastpacketstootherportsbetweentwologicalLANsegments.So,themulticastEIGRPhellofromLANsegment1willbeseenontheneighborlocatedinLANsegment2ifasinglehubconnectsalltheLANdevicesondifferentLANsegments.ThesolutionistobreakupthebroadcastdomainbyusingaseparatehubforeachLANsegmentorsimplyconfiguringnoeigrplog-neighbor-warningsunderEIGRPconfigurationtostopseeingtheerrormessage.IfaLANswitchconnectstheLANdevices,youmightwanttochecktheconfigurationoftheswitch.MakesurethattheswitchisnotconfiguredsothatdifferentLANsegmentsresidewithinthesameVLAN.MakesurethattheswitchisconfiguredsothateachLANsegmenthasitsownbroadcastdomainanddoesnotshareitsbroadcastdomainwithotherLANsegments.

EIGRPNeighborProblem—Cause:MismatchedMasks

Sometimes,asimplemisconfigurationontheinterfacesubnetmaskcausesanEIGRPneighborproblem.Figure7-7illustratesanetworkdiagramforsuchascenario.

Figure7-7NetworkTopologyVulnerabletoEIGRPNeighborProblemsBecauseofMismatchedMasks

Example7-3showstheconfigurationforRoutersA,B,andC.Example7-3RouterA,B,andCConfigurationsfortheNetworkinFigure7-7

RouterA#interfaceserial0ipaddress10.1.1.2255.255.255.128interfaceserial1ipaddress10.1.3.1255.255.255.0

RouterB#interfaceserial0ipaddress10.1.1.1255.255.255.0interfaceethernet0ipaddress10.1.2.1255.255.255.0

RouterC#interfaceethernet0ipaddress10.1.2.2255.255.255.0interfaceserial0ipaddress10.1.3.2255.255.255.0

NoticethemismatchedmaskontheserialinterfaceofRouterAandRouterB.RouterAhasamaskof255.255.255.128,whileRouterBhasamaskof255.255.255.0onSerial0.Initially,EIGRPhasnoproblemformingtheneighborbetweenRouterAandRouterBbecause10.1.1.1and10.1.1.2areinthesamesubnet.TheproblemoccurswhenaneighborrelationshipisestablishedandRouterAandRouterBbegintoexchangeEIGRPtopologytablesandinstallroutesbasedontheEIGRPtopologytable,asdemonstratedinExample7-4.Example7-4RoutingTablesfromRouterBandRouterC

RouterB#showiprouteCodes:C-connected,S-static,I-IGRP,R-RIP,M-mobile,B-BGPD-EIGRP,EX-EIGRPexternal,O-OSPF,IA-OSPFinterareaN1-OSPFNSSAexternaltype1,N2-OSPFNSSAexternaltype2E1-OSPFexternaltype1,E2-OSPFexternaltype2,E-EGPi-IS-IS,L1-IS-ISlevel-1,L2-IS-ISlevel-2,ia-IS-ISinterarea*-candidatedefault,U-per-userstaticroute,o-ODRP-periodicdownloadedstaticroute

GatewayoflastresortisnotsetC10.1.1.0/24Serial0D10.1.1.0/2510.1.2.2

Routerc#showiprouteeigrpCodes:C-connected,S-static,I-IGRP,R-RIP,M-mobile,B-BGPD-EIGRP,EX-EIGRPexternal,O-OSPF,IA-OSPFinterareaN1-OSPFNSSAexternaltype1,N2-OSPFNSSAexternaltype2E1-OSPFexternaltype1,E2-OSPFexternaltype2,E-EGPi-IS-IS,L1-IS-ISlevel-1,L2-IS-ISlevel-2,ia-IS-ISinterarea*-candidatedefault,U-per-userstaticroute,o-ODRP-periodicdownloadedstaticrouteGatewayoflastresortisnotsetD10.1.1.0/2410.1.2.1D10.1.1.0/2510.1.3.1

WhenRouterBsendsRouterAanEIGRPupdate,RouterArespondstotheupdatewithanEIGRPacknowledgementpacketwithadestinationaddressof10.1.1.1toRouterB.WhenRouterBreceivesthepacket,itforwardstheACKpackettoRouterCinsteadofprocessingitbecauseRouterBhasamorespecificroutefromRouterC.RouterBhasamorespecificrouteof10.1.1.0/25withthenexthopto10.1.2.2.This25routeoverridesthe24routebecause25ismorespecificthan24.WhenRouterCreceivestheACKpacketfromRouterB,itlooksatitsroutingtableforthe10.1.1.1entry,andtheroutingtablepointstoRouterA.RouterCthenforwardstheACKpacketbacktoRouterA.Thiscreatesaroutingloop.Thepacketto10.1.1.1loopsfromRouterAtoRouterB,fromRouterBtoRouterC,andbackfromRouterCtoRouterA.Asaresult,RouterBwon’tprocesstheACKpacketfromRouterA;RouterBwillthinkthatRouterAneverACK’edtheupdatepacket,andRouterBwillresettheneighborafter16retries.Thesolutionforthisproblem:ConfiguretherightsubnetmaskonRouterA’sSerial0interfaceto255.255.255.0.

EIGRPNeighborProblem—Cause:MismatchedKValuesForEIGRPtoestablishitsneighbors,theKconstantvaluetomanipulatetheEIGRPmetricmustbethesame.RefertoChapter6foranexplanationoftheKvalues.InEIGRP’smetriccalculation,thedefaultfortheKvalueissetsothatonlythebandwidthandthedelayoftheinterfaceareusedtocalculatetheEIGRPmetric.Manytimes,thenetworkadministratormightwantotherinterfacefactors,suchasloadandreliability,todeterminetheEIGRPmetric.Therefore,theKvaluesarechanged.Becauseonlybandwidthanddelayareusedincalculations,theremainingKvaluesaresettoavalueof0bydefault.However,theKvaluesmustbethesameforalltherouters,orEIGRPwon’testablishaneighborrelationship.Figure7-8showsanexampleofthiscase.

Figure7-8NetworkVulnerabletoEIGRPNeighborProblemsBecauseofMismatchedKValues

ForthenetworkinFigure7-8,K1isbandwidthandK3isdelay.ThenetworkadministratorchangedtheKvaluesofRTRBtoall1sfromK1toK4,whileRTRAretainsthedefaultvalueofK1andK3tobe1.Inthisexample,RTRAandRTRBwillnotformEIGRPneighborrelationshipbecausetheKvaluesdon’tmatch.Example7-5showstheconfigurationforRTRB.Example7-5ConfigurationforRTRBinFigure7-8

RTRB#routereigrp1networkxxxxmetricweights011110

RTRB’sconfigurationincludestheextrametricweightscommand.Thefirstnumberisthetypeofservice(ToS)number,which,becauseit’snotsupported,getsavalueof0.ThefivenumbersaftertheToSaretheK1throughK5values.Troubleshootingthisproblemrequirescarefulscrutinyoftherouter’sconfiguration.ThesolutionforthisproblemistochangealltheKvaluestobethesameonalltheneighboringrouters.Inthisexample,inRouterA,changingtheKvaluestomatchtheKvalueofRouterBwillsolvetheproblem,asdemonstratedinExample7-6.Example7-6ConfiguringtheKValuesonRouterAtoMatchRouterB

RTRA#routereigrp1networkxxxxmetricweights011110

EIGRPNeighborProblem—Cause:MismatchedASNumberEIGRPwon’tformanyneighborrelationshipswithneighborsindifferentautonomoussystems.IftheASnumbersaremismatched,noadjacencyisformed.Thisproblemisusuallycausedbymisconfigurationontherouters.Figure7-9illustratessuchaproblem.

Figure7-9NetworkExperiencinganEIGRPNeighborProblemBecauseMismatchedASNumbers

InthenetworkshowninFigure7-9,RTRAandRTRBareintheEIGRPASnumberof1andthepropernetworknumbershavebeenconfigured;however,noEIGRPneighborrelationshipisformedbetweenRTRAandRTRB.BeginbycheckingtheconfigurationofRTRAandRTRBinExample7-7.Example7-7ConfigurationsforRTRAandRTRBinFigure7-9

RTRB#showrunning-configinterfaceserial0IPaddress10.1.1.1255.255.255.0routereigrp11network10.0.0.0

RTRA#showrunning-configInterfaceserial0IPaddress10.1.1.2255.255.255.0routereigrp1network10.0.0.0

Youshouldnoticethemisconfigurationimmediately.RTRB’sSerial0interfaceisconfiguredtobeinEIGRPASnumber11,whileRTRA’sSerial0isconfiguredtobeinEIGRPASnumber1.BecausetheASnumbersdon’tmatchacrossthelink,noEIGRPneighborrelationshipwillbeformed.Toresolvethisproblem,simplyconfigurebothrouterswiththesameEIGRPASnumber,asshowninExample7-8.Inthisexample,bothrouterswillbeconfiguredtobeinEIGRPAS1.Example7-8ConfiguringBothRouterswiththeSameEIGRPASNumbers

RTRA#routereigrp1network10.0.0.0

RTRB#routereigrp1network10.0.0.0

EIGRPNeighborProblem—Cause:StuckinActiveSometimes,EIGRPresetstheneighborrelationshipbecauseofa“stuckinactive”condition.Theerrormessageis

%DUAL-3-SIA:Routenetworkmaskstuck-in-activestateinIP-EIGRPAS.Cleaningup

ThissectiondiscussesthemethodoftroubleshootingtheEIGRPstuckinactiveerror.ReviewingtheEIGRPDUALProcess

ToresolveanEIGRPstuckinactiveerror,youneedtounderstandtheDUALprocessinEIGRP.RefertoChapter6forthoroughcoverageoftheDUALprocess,althoughitisreviewedhereaswell.EIGRPisanadvanceddistance-vectorprotocol;itdoesn’thaveLSAflooding,likeOSPF,oralink-stateprotocoltotelltheprotocoltheoverallviewofthenetwork.EIGRPreliesonlyonitsneighborsforinformationonnetworkreachabilityandavailability.EIGRPkeepsalistofbackuproutescalledfeasiblesuccessors.Whentheprimaryrouteisnotavailable,EIGRPimmediatelyusesthefeasiblesuccessorasthebackuproute.Thisshortensconvergencetime.Now,iftheprimaryrouteisgoneandnofeasiblesuccessorisavailable,therouteisinactivestate.TheonlywayforEIGRPtoconvergequicklyistoqueryitsneighborsabouttheunavailableroute.Iftheneighbordoesn’tknowthestatusoftheroute,theneighborasksitsneighbors,andsoon,untiltheedgeofthenetworkisreached.Thequerystopsifoneofthefollowingoccurs:•Allqueriesareansweredfromalltheneighbors.•Theendofnetworkisreached.•Thelostrouteisunknowntotheneighbors.

Theproblemisthat,iftherearenoqueryboundaries,EIGRPpotentiallycanaskeveryrouterinthenetworkforalostroute.WhenEIGRPfirstqueriesitsneighbor,astuckinactivetimerstarts.Bydefault,thetimeristhreeminutes.If,inthreeminutes,EIGRPdoesn’treceivethequeryresponsefromallitsneighbors,EIGRPdeclaresthattherouteisstuckinactivestateandresetstheneighborthathasnotrespondedtothequery.Figure7-10illustratesthequeryprocessofEIGRPwhenarouteislost.

Figure7-10IllustrationofEIGRPQueryProcessWhenaRouteIsLost

InFigure7-10,RouterAlostitsEthernetinterface.Becauseitdoesn’thaveafeasiblesuccessor,theroutebecomesactiveandRouterAqueriesitsneighbors,RouterBandRouterC.Now,RouterBdoesn’tknowhowtoreachthelostnetwork,soitasksitsneighbors,RouterDandRouterE.Similarly,RouterCasksitsneighbors,RouterFandRouterG.BecauseRoutersD,E,F,andGalsodon’tknowhowtoreachthelostnetwork,theyquerythedownstreamneighbors.Atthispoint,theedgeofthenetworkisreachedandtheedgerouterdoesn’thaveanymoreneighborstoquery.TheedgerouterthenrepliesbacktoRoutersD,E,F,andG.ThoseroutersreplybacktoRoutersBandC,andfinallytoRouterA.Thequeryprocessthenstops.Figure7-10showsthecascadeeffectoftheEIGRPqueryprocess,inwhichthequerytravelsfromtheoriginalroutertotheedgeofthenetworkandbacktotheoriginalrouter.

DeterminingActive/StuckinActiveRouteswithshowipeigrptopologyactive

YoumustanswertwoquestionstotroubleshoottheEIGRPstuckinactiveproblem:•Whyistherouteactive?•Whyistheroutestuck?

Determiningwhytherouteisactiveisnotadifficulttask.Sometimes,theroutethatconstantlyisgoingactivecouldbeduetoflappinglink.Or,iftherouteisahostroute(/32route),it’spossiblethatitisfromadial-inconnectionthatgetsdisconnected.However,tryingtodeterminewhytheactiveroutebecomes

stuckisamuchhardertask—andmoreimportanttolearn.Usually,anactiveroutegetsstuckforoneofthefollowingreasons:•Badorcongestedlinks•Lowrouterresources,suchaslowmemoryorhighCPUontherouter•Longqueryrange•Excessiveredundancy

Bydefault,thestuckinactivetimerisonlythreeminutes.Inotherwords,iftheEIGRPneighbordoesn’thearareplyforthequeryinthreeminutes,neighborsarereset.ThisaddsdifficultyintroubleshootingEIGRPstuckinactivebecauseeverytimeanactiverouteisstuck,youhaveonlythreeminutestotrackdowntheactiveroutequerypathandhopefullyfindthecause.ThetoolthatyouneedtotroubleshoottheEIGRPstuckinactiveerroristheshowipeigrptopologyactivecommand.Thiscommandshowswhatroutesarecurrentlyactive,howlongtherouteshavebeenactive,andwhichneighborshaveandhavenotrepliedtothequery.Fromtheoutput,youcandeterminewhichneighborshavenotrepliedtothequery,andyoucantrackthequerypathandfindoutthestatusofthequerybyhoppingtotheneighborsthathavenotreplied.Example7-9showssampleoutputfromtheshowipeigrptopologyactivecommand.Example7-9SampleOutputofshowipeigrptopologyactiveCommand

Router#showipeigrptopologyactiveIP-EIGRPTopologyTableforAS(1)/ID(10.1.4.2)A20.2.1.0/24,1successors,FDisInaccessible,Q1replies,active00:01:43,query-origin:SuccessorOriginvia10.1.3.1(Infinity/Infinity),Serial1/0via10.1.4.1(Infinity/Infinity),Serial1/1,serno146Remainingreplies:Via10.1.5.2,r,Serial1/2

AstheoutputinExample7-9indicates,theroutefor20.2.1.0isinactivestateandhasbeenactivefor1minuteand43seconds.query-originisSuccessorOrigin,whichmeansthatthisroute’ssuccessorsendsthequerytothisrouter.Atthispoint,ithasgottenrepliesfrom10.1.3.1and10.1.4.1;thereplyisinfinity,whichmeansthatthesetworoutersalsodon’tknowabouttheroute20.2.1.0.ThemostimportantoutputoftheshowipeigrptopologyactivecommandistheRemainingreplies:section.FromtheoutputofExample7-9,thisroutershowsthattheneighbor10.1.5.2frominterfaceSerial1/2hasnotrepliedtothequery.Toproceedfurtherwithtroubleshooting,youmustTelnettothe10.1.5.2routertoseethestatusofitsEIGRPactiveroutesusingthesamecommand,showipeigrptopologyactive.Sometimes,therouterdoesnotlisttheneighborsthathavenotrepliedtothequeriesundertheRemainingreplies:section.Example7-10showsanotheroutputofshowipeigrptopologyactive.Example7-10AnotherSampleOutputoftheshowipeigrptopologyactiveCommand

Router#showipeigrptopologyactiveIP-EIGRPTopologyTableforAS(110)/ID(175.62.8.1)A11.11.11.0/24,1successors,FDisInaccessible1replies,active00:02:06,query-origin:SuccessorOriginvia1.1.1.2(Infinity/Infinity),r,Serial1/0,serno171via10.1.1.2(Infinity/Infinity),Serial1/1,serno173

InExample7-10,theonlydifferenceinoutputfromExample7-9isthelistofneighborsthathavenot

repliedtotherouter.However,thisdoesn’tmeanthatalloftheneighborshaverepliedtothequeries.InExample7-10,neighbor1.1.1.2hasanrnexttotheaddressof1.1.1.2.Thisalsomeansthattheneighborhasnotrepliedtothequeries.Inotherwords,therouterhastwowaysofrepresentingneighborsthathavenotrepliedtothequeries.OneistohavethemlistedundertheRemainingreplies:section;theotheristohaveanrnexttotheneighborinterfaceIPaddress.Whenusingtheshowipeigrptopologyactivecommand,theroutercanuseanycombinationofthesemethodstorepresentneighborsthathavenotyetrepliedtothequeries,asdemonstratedinExample7-11.Example7-11OutputofshowipeigrptopologyactiveThatShowsaCombinationRepresentationofNeighborsThatHaveNotRepliedtotheQueries

Router#showipeigrptopologyactiveIP-EIGRPTopologyTableforAS(110)/ID(175.62.8.1)A11.11.11.0/24,1successors,FDisInaccessible1replies,active00:02:06,query-origin:SuccessorOriginvia1.1.1.2(Infinity/Infinity),r,Serial1/0,serno171via10.1.1.2(Infinity/Infinity),Serial1/1,serno173Remainingreplies:via10.1.5.2,r,Serial1/2

InExample7-11,theneighborsthathavenotrepliedtothequeriesare1.1.1.2and10.1.5.2.Onlyoneofthenonreplyingneighbors10.1.5.2islistedundertheRemainingreplies:section;theotherneighbor,1.1.1.2,thathasnotrepliedislistedwiththeotherreplyingneighbor.Tosummarize,whenissuingtheshowipeigrptopologyactivecommand,themostimportantparttolookforistheneighborsthathavenotrepliedtothequery.Tolookforsuchaneighbor,lookforneighborsthathavethernexttotheirinterfaceIPaddresses.MethodologyforTroubleshootingtheStuckinActiveProblem

ThemethodsfortroubleshootinganEIGRPstuckinactiveproblemandtheshowipeigrptopologyactivecommandareusefulonlywhentheproblemishappening.Whenthestuckinactiveeventisoverandthenetworkstabilizes,itisextremelydifficult,ifnotimpossible,tobacktracktheproblemandfindoutthecause.Figure7-11showstheflowchartfortroubleshootingtheEIGRPstuckinactiveproblem.

Figure7-11FlowchartforResolvingtheEIGRPStuckinActiveProblem

ConsiderthenetworkshowninFigure7-12foranexampleoftroubleshootingtheEIGRPstuckinactiveproblem.

Figure7-12NetworkTopologyforEIGRPStuckinActiveTroubleshootingExample

InFigure7-12,RouterAhasanEthernetinterfacewithnetwork20.2.1.0/24thatjustwentaway.RouterAdoesn’thaveafeasiblesuccessortogotoasabackuproute.RouterAhasnochoicebuttoputthe20.2.1.0/24routeintoactivestateandqueryitsneighbor,RouterB.NoticetheoutputofshowipeigrptopologyactiveinRouterA.The20.2.1.0/24routehasgoneactivefor1minuteand12seconds,andtheneighborthathasnotrespondedislistedas10.1.1.2fromSerial0,whichisRouterB.ThenextstepistoTelnettoRouterBtoseetheactiveroutestatusinRouterB.Figure7-13showstheactiveroutestatusinRouterBbyperformingthecommandshowipeigrptopologyactive.

Figure7-13ActiveRouteStatusonRouterBforTroubleshootingEIGRPStuckinActiveExample

InFigure7-13,thecommandshowipeigrptopologyactiveonRouterBshowsthattheroute20.2.1.0/24isalsoinactivestatusinRouterBandthatithasgoneactivefor1minuteand23seconds.Most

importantly,RouterBcan’treplytoRouterAaboutroute20.2.1.0/24becauseRouterBisstillwaitingfortheneighborwithIPaddressof10.1.3.2(RouterD)fromSerial1/2toreplytothequery.ThenextstepistogotoRouterDtoseethestatusoftheactiveroute20.2.1.0/24andseewhyRouterDhasnotrepliedtothequery.Figure7-14showstheoutputofshowipeigrptopologyactiveonRouterD.

Figure7-14ActiveRouteStatusonRouterDforTroubleshootingEIGRPStuckinActiveExample

RouterDalsoputtheroute20.2.1.0/24inactivestate,andithasbeeninactivestatefor1minuteand43seconds.RouterDcan’tanswerRouterB’squerybecauseRouterDiswaitingfortherouterwiththeIPaddressof10.1.5.2fromSerial1/2(RouterE)torespondtothequery.ThenextstepistogotoRouterEtoseethestatusoftheactiveroute20.2.1.0/24andtofindoutwhyRouterEisnotreplyingtothequery.Figure7-15showsthestatusoftheactiverouteonRouterE.

Figure7-15ActiveRouteStatusonRouterEfortheTroubleshootingEIGRPStuckinActiveExample

Theoutputforshowipeigrptopologyactivedidn’tshowanythingforRouterE.Thisindicatesthat,asfarasRouterEisconcerned,therearenoroutesinactivestate.NowyoushouldTelnetbacktoRouterDtodouble-checkwhethertherouterisstillintheactivestateforroute20.2.1.0/24.TelnettingbacktoRouterDshowsthatRouterDisstillinactivestateforroute20.2.1.0/24,butRouterEdoesn’thaveanyroutesinactivestate.What’sgoingon?Tosummarizewhathasbeengoingonsofar,thechainofeventisasfollows:1RouterAwentactiveforroute20.2.1.0/24andiswaitingforRouterBtoreplytothequery.2RouterBcan’treplybecauseitiswaitingforRouterD’squeryresponse.3RouterDcan’treplybecauseitiswaitingforRouterEtoreplytothequery.4Finally,theshowipeigrptopologyactivecommandinRouterEshowsthatRouterEdoesnotthinkthatanyroutesareactive,whilegoingbacktoRouterDshowsthattheroute20.2.1.0/24isstillinactivestate.

Fromthissequenceofevents,youcanseethatthereisclearlyadiscrepancybetweenRouterDandRouterE.Moreinvestigationisneededbetweentheserouters.AlookatRouterDandRouterE’srouterCPUutilizationandmemoryusagedoesn’tshowaproblem.Bothrouters’CPUutilizationandavailablememoryarenormal.YouneedtolookatRouterD’sneighborlisttoseeifthereisaproblemwiththeneighbors.Example7-12showsRouterD’sEIGRPneighborlist.Example7-12RouterD’sEIGRPNeighborList

RTRD#showipeigrpneighborsIP-EIGRPneighborsforprocess1HAddressInterfaceHoldUptimeSRTTRTOQSeq(sec)(ms)CntNum210.1.5.2Se1/21300:00:140500010110.1.3.1Se1/01301:22:5422713620385010.1.4.1Se1/11001:24:0818211400171

FromExample7-12,noticethatthereisaprobleminRouterDwithEIGRPsendingareliablepackettotheneighborwithIPaddressof10.1.5.2(RouterE).TheQcountis1,andperformingtheshowipeigrpneighborscommandafewtimesinsuccessionshowsthattheQcountisnotdecrementing.TheRTOcounterisatitsmaximumvalueof5000ms.ThisindicatesthatRouterDistryingtosendareliablepackettoRouterE,butRouterEneveracknowledgesthereliablepacketbacktoRouterD.BecauseRouterEdoesn’tappeartohaveahighCPUormemoryproblem,youshouldtestthelinkreliabilitybetweenRouterDandRouterE.NowsendfivepingpacketsfromRouterDtoIPaddress10.1.5.2(RouterE’sserialinterface)toseewhathappens.Example7-13showstheresultofthepingtest.Example7-13ResultofpingTestfromRouterDtoRouterE

RouterD#ping10.1.5.2

Typeescapesequencetoabort.Sending5,100-byteICMPEchosto10.1.5.2,timeoutis2seconds:.....Successrateis0percent(0/5)

ThepingtestinExample7-13showsthesuccessrateis0percent.ThistestshowsthatalinkproblemexistsbetweenRouterDandRouterE.ThelinkiscapableofpassingamulticastpackettoestablishanEIGRPneighborrelationship,butitishavingproblemstransmittingaunicastpacket.ThislinkproblemistherootcauseoftheEIGRPstuckinactiveprobleminthisexample.ThewaytotroubleshoottheEIGRPstuckinactiveproblemistochasehopbyhopthequerypathandfindoutthestatusofactiverouteateachhop.TheaforementionedprocessistypicaltroubleshootingmethodologyforcombattingtheEIGRPstuckinactiveproblem.Sometimes,chasingthequerypathhopbyhopleadstoaloop,ortherearesimplytoomanyneighborsthatdidn’treplytothequery.Inthiscase,simplifyandreducethecomplexityoftheEIGRPtopologybycuttingdowntheredundancy.ThesimplertheEIGRPtopologyis,thesimpleritistotroubleshootanEIGRPstuckinactiveproblem.TheultimatesolutionforpreventingtheEIGRPstuckinactiveproblemistomanuallysummarizetherouteswheneverpossibleandtohaveahierarchicalnetworkdesign.ThemorenetworkEIGRPsummarizes,thelessworkEIGRPhastodowhenamajorconvergencetakesplace.Therefore,thisreducesthenumberofqueriesbeingsentoutandultimatelyreducestheoccurrenceofanEIGRPstuckinactiveerror.Figure7-16showsanexampleofapoornetworkdesignthatwillnotscaleinalargeEIGRPnetwork.

Figure7-16ExampleofaNonscalableEIGRPNetwork

InFigure7-16,eachcorerouterrepresentsaregionoftheentirenetworkandshowsthatthereisnohierarchyinIPaddressingscheme.TheCore1routerisinjectingroutes1.1.1.0,3.3.4.0,1.1.2.0,and2.2.3.0intothecorenetwork.Theaddressesaresoscatteredthatnomanualsummarizationispossible.Theothercoreroutersareexperiencingthesameproblem.TheCore3andCore4routerscan’tsummarizeanyroutesintothecorenetwork.Asaresult,iftheEthernetlinkofthe3.3.3.0networkkeepsflapping,thequerywouldtraveltotheCore3routerandthenthequeryalsowouldbeseenintheCore1andCore4region.Ultimately,thequerywilltraversetoalltheroutersintheinternetwork;thiswoulddramaticallyincreasethelikelihoodofanEIGRPstuckinactiveproblem.ThebestpracticeistoreaddresstheIPaddressscheme.OneregionshouldtakeonlyablockofIPaddresses;thisway,thecorerouterswouldbecapableofsummarizingtheroutesintothecore,resultinginareducedroutingtableinthecore:Theroutersandthequerywouldbecontainedonlyinoneregion.Figure7-17showsanimprovedandmorescalableEIGRPnetworkdesign.

Figure7-17ScalableEIGRPNetworkDesignImprovementonNetworkinFigure7-16

ComparingFigures7-16and7-17,youcanseethatthenetworkpresentedinFigure7-17ismorestructured.TheCore1routerregiontakesonlythe1.0.0.0blockofIPaddresses,theCoreregion4takesonlythe2.0.0.0block,andCore3regiontakesonlythe3.0.0.0blockofIPaddresses.Thisenablesthethreecorerouterstosummarizetheirroutesintothecore.IftheEthernetnetworkof3.3.3.0flapsintheCore3region,thequerywouldbeboundedonlyintheCore3regionandwouldnottraveltheentirenetworktoaffectalltheroutersinthenetwork.Summarizationandhierarchyarethebestdesignpracticesforalarge-scaleEIGRPnetwork.

TroubleshootingEIGRPRouteAdvertisementSometimes,EIGRPhasissueswithrouteadvertisement.ThissectiondiscussesmethodsfortroubleshootingEIGRProuteadvertisementproblems,whichcanbecategorizedasfollows:•EIGRPisnotadvertisingroutestoneighborswhenthenetworkadministratorsthinkthatitshould.•EIGRPisadvertisingroutestoneighborswhenthenetworkadministratorsthinkthatitshouldn’t.•EIGRPisadvertisingrouteswithametricthatisnotunderstoodbythenetworkadministrators.

EIGRPIsNotAdvertisingRoutestoNeighborsWhentheNetworkAdministratorsThinkThatItShouldThissectiondiscussesmethodsfortroubleshootingissuesrelatedtoEIGRPnotadvertisingroutestotheneighbors.Figure7-18showsaflowchartdocumentinghowtotroubleshootthisissue.

Figure7-18TroubleshootingFlowchartforProblemsRelatedtoEIGRPNotAdvertisingRoutestoItsNeighbors

EIGRPIsNotAdvertisingRoutestoItsNeighbors—Cause:DistributeList

Figure7-19showsanetworkinwhichEIGRPisnotadvertisingroutestoitsneighborbecauseofadistributelistproblem.Example7-14showstheconfigurationsforRoutersAandBinthisnetwork.

Figure7-19EIGRPNetworkNotAdvertisingRoutestoItsNeighborsBecauseofaMisconfiguredDistributeList

Example7-14ConfigurationsforRoutersAandBinFigure7-19

RouterA#interfaceethernet0ipaddress172.16.3.1255.255.255.0interfaceserial0ipaddress10.1.1.1255.255.255.0routereigrp1network172.16.0.0network10.0.0.0

RouterB#interfaceethernet0ipaddress192.168.3.17255.255.255.240interfaceserial0ipaddress10.1.1.2255.255.255.0routereigrp1network192.168.3.0network10.0.0.0distribute-list1outaccess-list1permit192.168.3.1600.0.0.15

TheproblemisthatRouterAisnotreceivingtheroutesfromRouterBaboutnetwork192.168.3.16.Example7-15showsthedebugoutputonRouterB.Example7-15debugipeigrpCommandOutputonRouterB

Router_B#debugipeigrp

IP-EIGRP:192.168.3.16/28–deniedbydistributelist

AstheoutputinExample7-15reveals,RouterBwon’tadvertisethe192.168.3.16becauseofthedistributelistconfiguration.LookingagainattheconfigurationinExample7-14,youcanseethatthedistributelististiedtoaccess-list1,andaccess-list1hasthenetworknumbermisconfigured.access-list1shouldpermit192.168.3.16insteadof192.168.3.160.Because192.168.3.16isnotincludedinthepermitstatement,thereisanimplicitdenyintheaccesslistthatpreventsnetwork192.168.3.16beingadvertised.Thesolutiontothisproblemistochangeaccess-list1topermit192.168.3.16insteadof192.168.3.160.Changingtheaccesslisttopermit192.168.3.16fixestheproblem.EIGRPIsNotAdvertisingRoutestoItsNeighbors—Cause:DiscontiguousNetworks

UsingthenetworkdiagraminFigure7-19,anotherissuewithEIGRPnotadvertisingthenetworkcouldbemanualsummarizationconfiguredontheinterfaceorautosummarizationacrossamajornetworkboundary,asshowninExample7-16.Example7-16ConfigurationsforRoutersAandBinFigure7-19


RouterB#interfaceethernet0ipaddress192.168.3.21255.255.255.240interfaceserial0ipaddress10.1.1.2255.255.255.0routereigrp1network192.168.3.0network10.0.0.0

TheproblemisthatRouterAisnotreceivingroutesforthe192.168.3.16networkfromRouterB.Example7-17showsthedebugoutputonRouterB.Example7-17debugipeigrpCommandOutputonRouterB

RouterB#debugipeigrp

IP-EIGRP:192.168.3.16/28–don'tadvertiseoutSerial0IP-EIGRP:192.168.3.0/24–doadvertiseoutSerial0

Fromthedebug,RouterBshowsthatitisnotadvertisingthe192.168.3.16/28network;however,itisadvertisingonlythemajornetworkof192.168.3.0/24toRouterA.LookingattheconfigurationofRoutersAandBinExample7-16showsthatthetworoutershaveadiscontiguousnetwork.RouterAhasthenetworkof192.168.3.32/28initsEthernet,whileRouterBhasanothernetworkof192.168.3.16/28initsEthernet,separatedbyanetworkof10.1.1.0/24.Therefore,whenRouterBadvertisesthenetworkof192.168.3.16/28acrossamajornetworkboundaryof10.1.1.0,itadvertisesonlythemajornetworkof192.168.3.0/24toRouterAinsteadofadvertisingthenetworkof192.168.3.16/28.WhenRouterAreceivesthemajornetworkof192.168.3.0/24,itdoesnotinstallthenetworkinthetopologytablebecauseitalreadyhasthe192.168.3.0networkonitsEthernetinterface.Twosolutionstothediscontiguousnetworkproblemexist.Oneistoconfigurethecommandnoauto-summaryunderroutereigrp.ThiscommandtellsEIGRPnottoautosummarizetomajornetworkboundaries.Asaresult,RouterB’sconfigurationwilllooklikeExample7-18.Example7-18DisablingAutosummarizationonRouterBtoPreventDiscontiguousNetworks

RouterB#routerEIGRP1network192.168.3.0network10.0.0.0noauto-summary

ThesecondsolutionistochangetheIPaddressoftheserialinterfacesoneachsideofthelinktothe192.168.3.0subnet.Asanexample,theserialIPaddresscantake192.168.3.65/28and192.168.3.66/28.Thisway,RouterBwon’tautosummarizetheroutebecauseitisnotacrossamajornetworkboundary.EIGRPIsNotAdvertisingRoutestoNeighbors—Cause:Split-HorizonIssues

EIGRPhasitsownsplit-horizoncommand.Thiscommand,configuredundertheinterface,isshownhere:[no]ipsplit-horizoneigrpautonomous-system

TurningoffIPsplithorizondoesnotturnoffEIGRPsplithorizon.Figure7-20showsanEIGRPnetworkvulnerabletosplit-horizonissues.

Figure7-20EIGRPNetworkSusceptibletoEIGRPSplit-HorizonProblems

Example7-19showstheconfigurationsforRoutersA,B,andCinthehub-and-spokenetworkinFigure7-20.Example7-19ConfigurationsforRoutersA,B,andCinFigure7-20

RouterA#interfaceethernet0ipaddress172.16.1.1255.255.255.0interfaceserial0ipaddress172.16.2.1255.255.255.0routereigrp1network172.16.0.0

RouterB#interfaceethernet0ipaddress172.16.3.1255.255.255.0interfaceserial0ipaddress172.16.2.2255.255.255.0routereigrp1network172.16.0.0

RouterC#interfaceethernet0ipaddress172.16.4.1255.255.255.0interfaceserial0ipaddress172.16.2.3255.255.255.0routereigrp1network172.16.0.0

Acommonnetworkenvironment,showninFigure7-20istheFrameRelayhub-and-spokedesign,inwhichthehubrouter(RouterA)inFigure7-20doesn’thaveasubinterfaceconfiguredforeachremotespokesite.Asaresult,thehubrouterusesamaininterfacetoconnecttothetwospokesites.TheproblemisthatRouterBdoesn’treceivetheroutesforRouterC’sEthernetnetworkof172.16.4.0/24,andRouterCdoesn’treceivetheroutesforRouterB’sEthernetnetworkof172.16.3.0/24.Theproblemseemstobeatthehubsite.Thehubsiteseesalltheroutes,butthehubsiteisnotpassingtheroutesfromRouterBtoRouterC,andviceversa.Example7-20showsthedebugoutputonthehubrouter(RouterA).Example7-20debugipeigrpCommandOutputonRouterA

RouterA#debugipeigrpIP-EIGRP:172.16.1.0/24–doadvertiseoutSerial0IP-EIGRP:ProcessingincomingUPDATEpacketIP-EIGRP:Int172.16.3.0/24IP-EIGRP:Int172.16.4.0/24

Fromthedebug,youcanseethatthehubrouteradvertisesonlythe172.16.1.0/24routeonSerial0.Thehubrouterreceivesroutesforthe172.16.3.0/24and172.16.4.0/24interfacesfromRouterBandRouterC.TheproblemisthatthehubrouterisnotsendingalltheroutesonSerial0.ReferringtotheconfigurationsofRoutersA,B,andCinExample7-19,youcanseethattheirserialinterfacesareallinthesamesubnet,buttheyarenotphysicallyconnected.Therefore,thehubrouterreceivestheroutesfromSerial0fromRouterBandRouterCbutwon’treadvertisethoseroutesonSerial0.Thisfollowsthesplit-horizonrule(routeinformationmustnotexittherouterinterfacethroughwhichthatinformationwasreceived).Tosolvethesplit-horizonproblemforEIGRP,theeasiestfixistoturnoffsplithorizonforEIGRP.Example7-21showsthecorrectconfigurationchangetodisablesplithorizon.Example7-21DisablingSplitHorizonontheHubRouter

RouterA#interfaceethernet0ipaddress172.16.1.1255.255.255.0interfaceserial0ipaddress172.16.2.1255.255.255.0noIPsplit-horizonEIGRP1routerEIGRP1network172.16.0.0

Example7-22showsthedebugoutputonRouterAaftertheconfigurationchange.Example7-22VerifyingThatDisablingSplitHorizonCorrectedtheProblem

RouterA#debugipeigrpIP-EIGRP:172.16.1.0/24–doadvertiseoutSerial0IP-EIGRP:172.16.3.0/24–doadvertiseoutSerial0IP-EIGRP:172.16.4.0/24–doadvertiseoutSerial0IP-EIGRP:ProcessingincomingUPDATEpacketIP-EIGRP:Int172.16.3.0/24IP-EIGRP:Int172.16.4.0/24

NowthespokeRoutersBandCcanseetheroutes.Anotherfixforthesplit-horizonproblemistoconfiguresubinterfacesonthehubrouterandassigndifferentIPaddresssubnetsforeachsubinterface.KeepinmindthatthesupportofaserialsubinterfaceisvalidforonlytheWANPVCtypeofconnection,suchasATMorFrameRelay.Example7-23showstheconfigurationforsuchasetuptoavoidtheEIGRPsplit-horizonproblem.Example7-23ConfiguringSubinterfaceswithDifferentIPAddressSubnetstoCombatEIGRPSplit-HorizonProblems

RouterA#interfaceethernet0ipaddress172.16.1.1255.255.255.0interfaceserial0.1point-to-pointdescriptionconnectiontorouterBipaddress172.16.2.1255.255.255.0interfaceserial0.2point-to-pointdescriptionconnectiontorouterCipaddress172.l6.5.1255.255.255.0

routereigrp1network172.16.0.0

RouterB#interfaceethernet0ipaddress172.16.3.1255.255.255.0interfaceserial0ipaddress172.16.2.2255.255.255.0routereigrp1network172.16.0.0

RouterC#interfaceethernet0ipaddress172.16.4.1255.255.255.0interfaceserial0ipaddress172.16.5.2255.255.255.0routereigrp1network172.16.0.0

WhensubinterfacesareconfiguredinRouterA,thislogicallyseparatestheconnectiontoRouterBandRouterC.EachconnectiontoRouterBandRouterChasitsownnetwork.Forexample,theconnectionfromRouterAtoRouterBisnowthroughconnectionSerial0.1overthe172.16.2.0/24network,andtheconnectionfromRouterAtoRouterCisnowthroughconnectionSerial0.2overthe172.l6.5.0/24network.BecauseRouterAhastwologicalconnectiontoRoutersBandCovertwodifferentlogicalinterfaces,thesplithorizonruledoesn’tapplyandRouterAwilladvertisealltheroutestoroutersBandC,asshowninExample7-24.Example7-24VerifyingThatConfiguringtheSubinterfacewithDifferentSubnetsSolvestheSplit-HorizonProblem

RouterA#debugipeigrpIP-EIGRP:172.16.1.0/24–doadvertiseoutSerial0.1IP-EIGRP:172.16.4.0/24–doadvertiseoutSerial0.1IP-EIGRP:172.16.5.0/24–doadvertiseoutSerial0.1IP-EIGRP:172.16.1.0/24–doadvertiseoutSerial0.2IP-EIGRP:172.16.2.0/24–doadvertiseoutSerial0.2IP-EIGRP:172.16.3.0/24–doadvertiseoutSerial0.2

WithRouterAadvertisingalltheroutestotheremoteRouters,RoutersBandCnowcanreacheachother’sLANinterface.

EIGRPIsAdvertisingRoutestoNeighborsWhentheNetworkAdministratorsThinkThatItShouldn’tSometimes,EIGRPadvertisesunexpectedroutestoitsneighbors.SeeFigure7–21foraflowchartoftroubleshootingEIGRPunexpectedadvertisementofroutes.

Figure7-21FlowchartforTroubleshootingEIGRPUnexpectedAdvertisementofRoutes

RefertoFigure7-19forthenetworkdiagramonthisexample.Example7-25showstheconfigurationsforRoutersAandB.Example7-25ConfigurationofRouterAandRouterBfortheExampleShowninFigure7-19


RouterB#interfaceethernet0ipaddress192.168.130.1255.255.255.0interfaceserial0ipaddress10.1.1.2255.255.255.0routereigrp1network192.168.130.0network10.0.0.0iproute192.168.1.0255.255.255.0ethernet0iproute192.168.2.0255.255.255.0ethernet0iproute192.168.3.0255.255.255.0ethernet0iproute192.168.4.0255.255.255.0ethernet0.

.

.iproute192.168.127.0255.255.255.0ethernet0

Theproblemisthat,withoutinsertingtheredistributestaticcommandundertheroutereigrpcommandinRouterB,RouterBautomaticallyredistributesallthe127staticroutesconfiguredtoRouterA.Thiscancauseunnecessaryroutesbeingadvertisedinadvertentlythroughouttheentirenetwork.Thecauseoftheproblemisthatthestaticroutesareconfiguredwiththeoutboundinterface.Inthiscase,therouterthinksthatallthestaticroutesaredirectlyconnectedtotheEthernet0interface.TheseEthernetinterfacesalsoarecoveredundertherouterEIGRPprocessbythenetwork192.168.130.0command.BecauseEthernet0isconsideredtorunEIGRP,allthenetworksconnectedtoitbyastaticroutealsoareconsideredtobelongtotheEIGRPprocess.Therouterthenadvertisesallthesestaticrouteseventhoughredistributestaticisnotconfigured.Thesolutiontothisproblemiseithertoconfigureadistributelistthatpreventstherouterfromadvertisingallthosestaticroutesortochangethestaticroutestoreferencethenext-hopIPaddressesinsteadofaninterface.Thisway,therouterwillnotadvertiseallthesestaticroutesandfloodtheentirenetworkwithunnecessaryroutes.Example7-26showsthedistributelistconfiguredonRouterBtostopsendingtheunwantedredistributedstaticroutes.Example7-26ConfigurationonRouterBtoStopSendingUnwantedStaticRoutesbyConfiguringDistributeList

RouterB#interfaceethernet0ipaddress192.168.130.1255.255.255.0iinterfaceserial0ipaddress10.1.1.2255.255.255.0routereigrp1network192.168.130.0network10.0.0.0distribute-list1outiproute192.168.1.0255.255.255.0ethernet0iproute192.168.2.0255.255.255.0ethernet0iproute192.168.3.0255.255.255.0ethernet0iproute192.168.4.0255.255.255.0ethernet0...iproute192.168.127.0255.255.255.0ethernet0access-list1deny192.168.0.00.0.127.255access-list1permitany

Thedistributelististiedtoaccess-list1,andaccess-list1deniessendingoutanyroutesthatrangesfrom192.168.0.0/24through192.168.127.0/24andpermitssendinganyotherroutes.Suchadistributeliststopssendingouttheunwantedredistributedstaticroutesintheexample.ThedebugoutputonRouterB,showninExample7-27,showsthattherouterdoesnotsendthestaticroutestootherEIGRPneighborsbecausethedistributelistisconfigured.Example7-27VerificationonRouterBNotSendingOutStaticRoutesBecauseaDistributeListIsConfigured

RouterB#debugipeigrpIP-EIGRP:192.168.1.0/24–deniedbydistributelistIP-EIGRP:192.168.2.0/24–deniedbydistributelist

IP-EIGRP:192.168.3.0/24–deniedbydistributelistIP-EIGRP:192.168.4.0/24–deniedbydistributelistIP-EIGRP:192.168.5.0/24–deniedbydistributelistIP-EIGRP:192.168.6.0/24–deniedbydistributelist...IP-EIGRP:192.168.127.0/24–deniedbydistributelist

TheothersolutiontothisproblemistoredefinethestaticroutessothatthenexthopofthestaticrouteisanIPaddressinsteadofaninterface.Example7-28showsthechangeofstaticrouteconfigurationinRouterBtofixtheproblem.Example7-28ConfigurationonRouterBtoStopSendingUnwantedStaticRoutesbyReconfiguringStaticRouteswiththeNextHop—anIPAddressInsteadofanInterface

RouterB#interfaceethernet0ipaddress192.168.130.1255.255.255.0iinterfaceserial0ipaddress10.1.1.2255.255.255.0routereigrp1network192.168.130.0network10.0.0.0distribute-list1outiproute192.168.1.0255.255.255.0192.168.130.2iproute192.168.2.0255.255.255.0192.168.130.2iproute192.168.3.0255.255.255.0192.168.130.2iproute192.168.4.0255.255.255.0192.168.130.2...iproute192.168.127.0255.255.255.0192.168.130.2

EIGRPIsAdvertisingRouteswithUnexpectedMetricNotonlymightEIGRPadvertiseunexpectedroutestoitsneighbors,butitalsomightadvertiseanunexpectedmetrictoitsneighbors.TheEIGRPmetricisthebasisofrouteselectiondonebyEIGRP,whichselectstheroutewiththelowestEIGRPmetrictothedestinationnetwork.AnunexpectedEIGRPmetricbeingsentorreceivedontheroutermightalterrouteselectiontothedestinationnetwork.Theendresultmightbesuboptimalrouting.Figure7-22showstheflowchartfortroubleshootingsuchanissue.

Figure7-22FlowchartforTroubleshootingEIGRPAdvertisementofRouteswithUnexpectedMetricValue

Thecasestudythatfollowsisacaseofanoffsetlistthatiscreatedinadvertently,causingtheroutertoroutepacketsinasuboptimalfashion.Theoffset-listcommandaddsanoffsetvaluetotheroutingmetrics.It’sawaytomanipulatetheroutingmetricforcertainroutes,thereby,alteringtherouteselectionforaparticularroutingprotocol.Figure7-23illustratesthenetworksetupfortheunexpectedmetricvalueproblem.

Figure7-23EIGRPNetworkSusceptibletoEIGRPAdvertisementProblemsBecauseofUnexpectedMetricValues

Example7-29showstheconfigurationsfortheroutersintheEIGRPnetworkshowninFigure7-23.Example7-29ConfigurationsforRoutersA,B,andCinFigure7-23

RouterA#interfaceethernet0ipaddress172.16.1.1255.255.255.0interfaceserial0ipaddress172.16.2.1255.255.255.0interfaceserial1ipaddress172.16.3.1255.255.255.0routereigrp1network172.16.0.0

RouterB#interfaceethernet0ipaddress172.16.6.1255.255.255.0interfaceserial0ipaddress172.16.2.2255.255.255.0interfaceserial1ipaddress172.16.4.1255.255.255.0routereigrp1network172.16.0.0

RouterC#interfaceethernet0ipaddress172.16.5.1255.255.255.0interfaceserial0ipaddress172.16.4.2255.255.255.0interfaceserial1ipaddress172.16.3.2255.255.255.0routereigrp1network172.16.0.0offset-list1out600000serial1access-list1permit172.16.0.00.0.255.255

TheproblemisthatRouterAisnottakingthedirectpathstoRouterCtoreachRouterC’sEthernetnetworkof172.16.5.0/24.Instead,RouterAtakesthepathtoRouterBandthentoRouterC.Thistakesanextrahop.Example7-30showstheroutingtableandtheEIGRPtopologytablefor172.16.5.0255.255.255.0forRouterA.Example7-30showiprouteandshowipeigrptopologyCommandOutputRevealstheRoutesThatRouterAIsTakingtoReachRouterC’s172.16.5.0/24EthernetNetwork

Router_A#showiproute172.16.5.0Routingentryfor172.16.5.0/24Knownvia"eigrp1",distance90,metric2707456,typeinternalRedistributingviaeigrp1Lastupdatefrom172.16.2.2onSerial0,01:08:13agoRoutingDescriptorBlocks:*172.16.2.2,from172.16.2.2,01:08:13ago,viaSerial0Routemetricis2707456,trafficsharecountis1Totaldelayis41000microseconds,minimumbandwidthis1544KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops2

RouterA#showipeigrptopology172.16.5.0255.255.255.0IP-EIGRPtopologyentryfor172.16.5.0/24StateisPassive,Queryoriginflagis1,1Successor(s),FDis2707456RoutingDescriptorBlocks:172.16.2.2(Serial0),from172.16.2.2,Sendflagis0x0Compositemetricis(2707456/2195456),RouteisInternalVectormetric:

Minimumbandwidthis1544KbitTotaldelayis41000microsecondsReliabilityis255/255Loadis1/255MinimumMTUis1500Hopcountis2

172.16.3.2(Serial1),from172.16.3.2,Sendflagis0x0Compositemetricis(2795456/281600),RouteisInternalVectormetric:Minimumbandwidthis1544KbitTotaldelayis44437microsecondsReliabilityis255/255Loadis1/255MinimumMTUis1500Hopcountis1

Example7-30showsthatRouterAchoosesRouterBasthenexthoptoRouterCbecauseRouterBhasabettermetricthanRouterC.LookingindetailatthetopologytableshowsthatthepathtoRouterChasmoredelaythanthepathtoRouterB,butallthelinksareT1links.TheinterfaceconfigurationinRouterCdidn’tshowanymanuallyconfigureddelayvalue.LookingattheconfigurationinRouterCmoreindetailrevealstheoffset-listconfigurationunderroutereigrpinRouterC.TheoffsetlistinRouterCaddsametricof600,000tooutgoingroutesinSerial1.Thisisthecauseoftheproblem.TheoffsetvaluesaddedincreasethedelayvaluewhenRouterCsendstheroutestoRouterA,causingRouterAtopreferroutesfromRouterB.ThesolutionistoremovetheoffsetlistconfiguredonRouterC.Toremovetheoffsetlist,configureRouterCasinExample7-31.Example7-31RemovingtheOffsetListfromRouterC’sConfiguration

RouterC#configtermRouter_C(config)#routereigrp1Router_C(config-router)#nooffset-list1out600000serial1

Example7-32showstheroutingtableandthetopologytableinRouterAafterremovingtheoffsetlistconfiguredonRouterC.Example7-32showiprouteandshowipeigrptopologyCommandOutputVerifiesThatRouterAIsNowTakingtheOptimalRoutestoReachRouterC’s172.16.5.0/24EthernetNetwork

Router_A#showiproute172.16.5.0Routingentryfor172.16.5.0/24Knownvia"eigrp1",distance90,metric2195456,typeinternalRedistributingviaeigrp1Lastupdatefrom172.16.3.2onSerial1,00:08:23agoRoutingDescriptorBlocks:*172.16.3.2,from172.16.3.2,00:08:23ago,viaSerial1Routemetricis2195456,trafficsharecountis1Totaldelayis21000microseconds,minimumbandwidthis1544KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops1

RouterA#showipeigrptopology172.16.5.0255.255.255.0IP-EIGRPtopologyentryfor172.16.5.0/24StateisPassive,Queryoriginflagis1,1Successor(s),FDis2195456RoutingDescriptorBlocks:172.16.3.2(Serial1),from172.16.3.2,Sendflagis0x0

Compositemetricis(2195456/281600),RouteisInternalVectormetric:Minimumbandwidthis1544KbitTotaldelayis21000microsecondsReliabilityis255/255Loadis1/255MinimumMTUis1500Hopcountis1

172.16.2.2(Serial1),from172.16.2.2,Sendflagis0x0Compositemetricis(2707456/2195456),RouteisInternalVectormetric:Minimumbandwidthis1544KbitTotaldelayis41000microsecondsReliabilityis255/255Loadis1/255MinimumMTUis1500Hopcountis2

TheoutputinExample7-32nowshows172.16.3.2asthenexthoptoRouterC,whichistheoptimalpathtothe172.16.5.0/24network.Also,comparethetopologytableshowninExample7-30andExample7-32.TheEIGRPmetriccomingfromtheneighbor172.16.3.2hasbeenreducedfromthemetricof2,795,456to2,195,456.Thisreductionofmetricof600,000istheresultofremovingtheoffsetlist.Asthiscasestudydemonstrates,itisimportantthatyouscrutinizetheconfigurationwhenabnormalbehavioroccurs.WhenopeningacasewithCisco’sTAC,besuretoproviderouterconfigurationwheneverpossible.

TroubleshootingEIGRPRouteInstallationTheprevioussectiondiscussestheproblemsthatEIGRProutershavewhenadvertisingroutestoitsneighbors.ThissectiondiscussestroubleshootingproblemswhenEIGRPdoesn’tinstalltheroutesintheroutingtable.Themostcommoncausesofthisproblemareasfollows:•Autoormanualsummarizationconfigured•Higheradministrativedistance•DuplicaterouterIDs

Thefollowingsectionsdetailthecausesofthisproblemandhowtoresolvethem.Foroveralltroubleshootingmethods,Figure7-24showstheflowchartfortroubleshootingEIGRProute-installationproblems.

Figure7-24FlowchartforTroubleshootingEIGRPRoute-InstallationProblems

EIGRPIsNotInstallingRoutes—Cause:AutoorManualSummarizationWhenEIGRPfailstoinstallroutesintheroutingtable,thefirstthingtocheckisthetopologytable.Figure7-25showsthenetworksetupforthiscasestudy.

Figure7-25EIGRPNetworkSusceptibletoRoute-InstallationProblem

Example7-33showstheconfigurationforRouterB.Example7-33ConfigurationforRouterBinFigure7-25

RouterB#interfaceethernet0ipaddress172.16.2.1255.255.255.0interfaceserial0192.168.1.1255.255.255.0interfaceserial1192.168.2.1255.255.255.0routereigrp1network172.16.0.0network192.168.1.0network192.168.2.0

InsidenetworkcloudsXandYarenetworksinthe172.16.x.xspace.TheproblemisthatRouterCsummarizesallthe172.16.x.xnetworksintoonesummaryrouteof172.16.0.0/16andsendsittoRouterB.RouterBisnotinstallingtheroutesintheroutingtable,asshowninExample7-34.Example7-34RouterB’sRoutingTable

RouterB#showiproute172.16.0.0

Routingentryfor172.16.0.0/16RoutingDescriptorBlocks:*directlyconnected,viaNull0

RouterB’sroutingtableshowsthattherouteisdirectlyconnectedtoNull0insteadoflearnedfromRouterC.ThetopologytableinRouterBshowsthattherouterisgettingtheroutesfromRouterCbutisinstallingtherouteasconnectedbecausetheNull0routehasadistanceof5,whichisanEIGRPsummaryroute.TheconfigurationofRouterBshowsthatEIGRPsummarizesthe172.16.0.0/16routebecauseofautosummarization.Everytimeautosummarizationormanualsummarizationtakesplace,EIGRPinstallsthesummaryroutewiththenexthoptoNull0.Thisisaloop-preventionmechanismforEIGRP’ssummaryroutes.Inthiscasestudy,thisisexactlywhathappens—EIGRPdoesnotinstallaroutefromitsneighborthatfallswithinitssummaryrange.Thesolutiontothisproblem,basedonthiscause,ismoreofadesignissue.Twoplacesinthenetwork

mustnotsendthesamesummaryroutestooneanother.Inthisexample,youconfigurethenoauto-summarycommandonRouterBtoallowRouterBtoacceptthesummaryroutescomingfromRouterC.Example7-35showstheconfigurationinRouterBtofixtheproblem.Example7-35ConfigurationChangeonRouterBtoFixtheProblemShowninFigure7-25

RouterB#interfaceethernet0ipaddress172.16.2.1255.255.255.0interfaceserial0192.168.1.1255.255.255.0interfaceserial1192.168.2.1255.255.255.0routereigrp1network172.16.0.0network192.168.1.0network192.168.2.0noauto-summary

WiththeconfigurationchangeinRouterB,theroutingtableshowninExample7-36forRouterBnowshowsthesummaryrouteof172.16.0.0/16comingfromRouterC.Example7-36RoutingTableofRouterBNowShowingSummaryRouteComingfromRouterC

Router_B#showiproute172.16.0.0255.255.0.0Routingentryfor172.16.0.0/16Knownvia"eigrp1",distance90,metric2195456,typeinternalRedistributingviaeigrp1Lastupdatefrom192.168.1.2onSerial0,00:16:24agoRoutingDescriptorBlocks:*192.168.1.2,from192.168.1.2,00:16:24ago,viaSerial0Routemetricis2195456,trafficsharecountis1Totaldelayis21000microseconds,minimumbandwidthis1544KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops1

EIGRPIsNotInstallingRoutes—Cause:HigherAdministrativeDistanceRefertothenetworktopologyinFigure7-25.AnothervariationofasimilarproblemcanhappenifnetworkcloudYsendsexternalEIGRProutesof150.150.0.0/16toRouterB,andRouterBisrunningRIPandEIGRPbutisgettingthe150.150.0.0/16routesfromtheRIPdomainfromRouterA.BecauseRIPhasaloweradministrativedistance(120)thanexternalEIGRProutes(170),RouterBinstallsRIProutesfor150.150.0.0/16onlyfromRouterA.Example7-37showstheEIGRPtopologytableforRouterB.Example7-37RouterB’sEIGRPTopologyTablefor150.150.0.0/16

RouterB#showipeigrptopology150.150.0.0255.255.0.0

IP-EIGRPtopologyentryfor150.150.0.0/16StateisPassive,Queryoriginflagis1,0Successor(s),FDis4294967295RoutingDescriptorBlocks:192.168.1.2(Serial0),from192.168.1.2,Sendflagis0x0Compositemetricis(2707456/2195456),RouteisExternalVectormetric:Minimumbandwidthis1544KbitTotaldelayis41000microsecondsReliabilityis255/255Loadis1/255MinimumMTUis1500Hopcountis3

Externaldata:Originatingrouteris155.155.155.1ASnumberofroutesis0ExternalprotocolisOSPF,externalmetricis64Administratortagis0

TheEIGRPtopologytableshowsthatthefeasibledistance(FD)isinaccessible(4294967295);therouteisanexternalroutethathasbeenredistributedfromOSPF.ThismeansthatRouterBisreceivingthe150.150.0.0/16routesfromRouterCbutissettingtheFDasinaccessiblebecauseRouterBisnotusingtheEIGRProuteintheroutingtable.Asamatteroffact,theroutingtableentryinRouterBisaRIProutefor150.150.0.0/16,asshowninExample7-38.Inotherwords,whentheFDisinaccessibleintheEIGRPtopologytable,therouterisnotusingthatEIGRProuteinitsroutingtable.Usually,therouteisoverriddenbyanotherroutingprotocolthathasloweradministrativedistance.Example7-38RoutingTableofRouterBShowing150.150.0.0/16RouteasaRIPRoute

Router_B#showiproute150.150.0.0Routingentryfor150.150.0.0/16Knownvia"rip",distance120,metric5RedistributingviaripLastupdatefrom192.168.2.2onSerial1,00:00:24agoRoutingDescriptorBlocks:*192.168.2.2,from192.168.2.2,00:00:24ago,viaSerial1Routemetricis5,trafficsharecountis1

Tofixthisproblem,youmustchangetheadministrativedistanceoftheroutingprotocolssothatexternalEIGRProutesarepreferred.Todoso,usethedistancecommandtomanipulatetheadministrativedistanceofaroutingprotocol.TheconfigurationofRouterBtofixthisproblemisshowninExample7-39.Example7-39ConfigurationChangeonRouterBtoFixtheRoute-InstallationProblemBecauseofHigherAdministrativeDistance

RouterB#interfaceethernet0ipaddress172.16.2.1255.255.255.0interfaceserial0192.168.1.1255.255.255.0interfaceserial1192.168.2.1255.255.255.0routereigrp1network172.16.0.0network192.168.1.0network192.168.2.0routerripnetwork172.16.0.0network192.168.2.0distance180192.168.2.2255.255.255.255

ThedistancecommandshowninExample7-39setstheRIPadministrativedistanceto180foranyupdatescomingfrom192.168.2.2.ThisallowstheexternalEIGRProutes(administrativedistanceof170)comingfromRouterCtobepreferredoverRIProutes.Example7-40showstheresult.Example7-40RoutingTableofRouterBNowShowingSummaryRouteComingfromRouterC

Router_B#showiproute150.150.0.0Routingentryfor150.150.0.0/16Knownvia"eigrp1",distance90,metric2195456,typeinternal

Redistributingviaeigrp1Lastupdatefrom192.168.1.2onSerial0,00:26:14agoRoutingDescriptorBlocks:*192.168.1.2,from192.168.1.2,00:26:14ago,viaSerial0Routemetricis2195456,trafficsharecountis1Totaldelayis21000microseconds,minimumbandwidthis1544KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops1

EIGRPIsNotInstallingRoutes—Cause:DuplicateRouterIDsManytimes,EIGRPwillnotinstallroutesbecauseofaduplicaterouterIDproblem.EIGRPdoesnotuserouterIDasextensivelyasOSPF.EIGRPusesthenotionofrouterIDonlyonexternalroutestopreventloops.EIGRPchoosestherouterIDbasedonthehighestIPaddressoftheloopbackinterfacesontherouter.Iftherouterdoesn’thaveanyloopbackinterfaces,thehighestactiveIPaddressofalltheinterfacesischosenastherouterIDforEIGRP.Figure7-26showsthenetworksetupforsuchacasestudyonEIGRProuterIDs.

Figure7-26EIGRPNetworkSusceptibletoEIGRPNotInstallingRoutesBecauseofDuplicateRouterIDs

Example7-41showsthepertinentconfigurationsforthecauseofthisproblem.Example7-41ConfigurationsforRoutersA,B,C,andXinFigure7-26

RouterA#interfaceethernet0ipaddress192.168.1.1255.255.255.0interfaceserial0ipaddress10.1.1.1255.255.255.0

RouterB#interfaceserial0IPaddress10.1.1.2255.255.255.0interfaceserial1IPaddress10.1.2.1255.255.255.0

RouterC#interfaceserial0ipaddress10.1.2.2255.255.255.0

RouterX#interfaceloopback0ipaddress192.168.1.1255.255.255.255

RouterXisredistributingarouteof150.150.0.0/16fromOSPFintoEIGRPandissendingtherouteseveralhopstoRouterC.RouterCreceivestherouteandsendstherouteasEIGRPexternalroutestoRouterB.RouterBinstallstherouteintheroutingtableandsendsittoRouterA.Thedebugoutputin

Example7-42verifieshowRouterBsendstheroutetoRouterA.Example7-42debugipeigrpCommandOutputonRouterB

RouterB#debugipeigrp

IP-EIGRP:150.150.0.0/16–doadvertiseoutserial0

TheproblemisthatRouterAisnotinstallingthe150.150.0.0/16routeintheroutingtable.Asamatteroffact,RouterAisnotshowingthe150.150.0.0/16routeinitstopologytable.GoingbacktoRouterB,therouteisintheroutingtable,andthetopologytableappearsasshowninExample7-43.Example7-43EIGRPTopologyTablefor150.150.0.0/16onRouterB

RouterB#showipeigrptopology150.150.0.0255.255.0.0

IP-EIGRPtopologyentryfor150.150.0.0/16StateisPassive,Queryoriginflagis1,1Successor(s),FDis3757056RoutingDescriptorBlocks:10.1.2.2(Serial1),from10.1.2.2,Sendflagis0x0Compositemetricis(3757056/3245056),RouteisExternalVectormetric:Minimumbandwidthis1544KbitTotaldelayis82000microsecondsReliabilityis255/255Loadis1/255MinimumMTUis1500Hopcountis7Externaldata:Originatingrouteris192.168.1.1ASnumberofroutesis0ExternalprotocolisOSPF,externalmetricis64Administratortagis0

RouterBshowsthatitisgettingtheroutesfromRouterC.Bylookingattheexternaldatasection,noticethattheoriginatingrouteris192.168.1.1,whichissevenhopsaway.Theoriginalprotocolthatoriginatedtheroute150.150.0.0/16isOSPFwiththemetricof64.Noticethattheoriginatingrouteris192.168.1.1.LookingbackattheconfigurationofRouterAinExample7-41,noticethatRouterAalsohasanIPaddressof192.168.1.1configuredonEthernet0,anditisthehighestIPaddressontherouter.AllthisevidencepointstoaduplicaterouterIDprobleminEIGRPthatcausesRouterAnottoinstallroutes.BecauseRouterXandRouterAhavethesamerouterID(192.168.1.1),whenRouterAreceivestheroutefromRouterB,itlooksattheexternaldatasectionoftheroutetoseewhoistheoriginatingrouter.Inthiscase,RouterAseestheoriginatingrouteras192.168.1.1,whichisitsownrouterID.RouterAdoesnotputtherouteinitstopologytablebecauseitthinksthatitistheoriginatoroftherouteandthatbyreceivingtheroutebackfromotherneighbors,itmustbealoop.So,topreventaroutingloop,RouterAdoesnotputtherouteof150.150.0.0/16inthetopologytable.Consequently,theroutedoesnotappearintheroutingtable.RouterAwillnotinstallanyexternalroutesthatoriginatefromRouterXbecauseexternalroutescarrytherouterIDintheirEIGRPupdatepacket.RouterAwillinstallinternalEIGRProutesfromRouterXwithoutanyproblem.TheduplicaterouterIDproblemhappensonlyforexternalroutes.ThesolutiontotheduplicaterouterIDproblemistochangetheIPaddressoftheloopbackinterfaceofRouterXortochangetheIPaddressofEthernet0inRouterA.Theruleofthumb:NeverconfigurethesameIPaddressontwoplacesinthenetwork.ChangetheloopbackIPaddressofRouterXto

192.168.9.1/32tofixthisproblem(seeExample7-44).TheresultoftheIPaddresschangeinRouterXistheinstallmentofthe150.150.0.0/16routeinRouterA,asshowninExample7-45.Example7-44LoopbackIPAddressChangeinRouterXtoAvoidDuplicateRouterIDProblem

RouterX#interfaceLoopback0IPaddress192.168.9.1255.255.255.255

Example7-45RoutingTableandEIGRPTopologyTablefor150.150.0.0/16onRouterAtoVerifytheFix

Router_A#showiproute150.150.0.0Routingentryfor150.150.0.0/16Knownvia"eigrp1",distance170,metric4269056,typeexternalRedistributingviaeigrp1Lastupdatefrom10.1.1.2onSerial0,00:06:14agoRoutingDescriptorBlocks:*10.1.1.2,from10.1.1.2,00:06:14ago,viaSerial0Routemetricis4269056,trafficsharecountis1Totaldelayis102000microseconds,minimumbandwidthis1544KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops8

RouterA#showipeigrptopology150.150.0.0255.255.0.0IP-EIGRPtopologyentryfor150.150.0.0/16StateisPassive,Queryoriginflagis1,1Successor(s),FDis4269056RoutingDescriptorBlocks:10.1.1.2(Serial0),from10.1.1.2,Sendflagis0x0Compositemetricis(4269056/3757056),RouteisExternalVectormetric:Minimumbandwidthis1544KbitTotaldelayis102000microsecondsReliabilityis255/255Loadis1/255MinimumMTUis1500Hopcountis8Externaldata:Originatingrouteris192.168.9.1ASnumberofroutesis0ExternalprotocolisOSPF,externalmetricis64Administratortagis0

TroubleshootingEIGRPRouteFlappingThissectiondiscusseshowtotroubleshootconsistentEIGRProuteflapping.Themostimportanttoolfortroubleshootingthisproblemistheshowipeigrpeventcommand.Thiscommandrevealswhichneighborisupdatingandthemetricwithwhichit’supdating.SeeFigure7-27fortheflowchartfortroubleshootingtheEIGRProuteflappingproblem.

Figure7-27FlowchartforTroubleshootingEIGRPRouteFlapping

WhentroubleshootingEIGRProute-flapproblems,adifferenceexistsbetweentheroutedisappearingfromtheroutingtableandtheroutetimerintheroutingtableshowing00:00:00,ashighlightedinExample7-46.Example7-46ExampleofRoutingTableThatShowstheUpdateTimerAlwaysat00:00:00

RouterA#showiproute150.150.0.0

Routingentryfor150.150.0.0/16Knownvia"eigrp1",distance90,metric304128,typeinternalLastupdatefrom10.1.1.2onEthernet0,00:00:00ago

Whentheroutetimerintheroutingtablealwaysshows00:00:00,itdoesn’tnecessarilymeanthattherouterisconstantlytakingtherouteoutandreinstallingit.Itsimplymeansthatoneoftherouter’sneighborsisconstantlyupdatingtherouterwiththeroute.Theneighborupdatingtherouteisnotnecessarilythebestpathtotheroute,butitisonepossiblepath.Theroutersimplyrefreshesthetimerbecauseitgotanupdatefromoneoftheneighbors.Totrulyverifythattherouteristakingouttheroutefromtheroutingtableandreinstallingit,usethedebugiprouting.Example7-47demonstratestheoutputfromthiscommandonRouterB.Example7-47debugiproutingCommandOutputVerifiesWhetheraRouteIsBeingInstalled

RouterB#debugiprouting

RT:add150.150.0.0/16via10.1.1.2,eigrpmetric[90/304128]RT:deleterouteto150.150.0.0via10.1.1.2,eigrpmetric[90/304128]

Thisdebugshowsalltheroutesthattheroutingtabletakesoutandinstalls,althoughtheoutputofthedebugmightbeoverwhelmingtotherouters.Youcanalsouseanaccesslisttothedebugsothattheoutputshowsonlytheroutesinquestion.Forexample,ifyouwanttodothedebugonlyontheroute192.168.1.0/24intheroutingtable,useanaccesslist,asconfiguredinExample7-48.Example7-48UsingAccessListstoLimitdebugiproutingInformation

RouterB#debugiprouting1access-list1permit192.168.1.00.0.0.255access-list1denyany

Aspreviouslymentioned,yourbesttoolintroubleshootingEIGRProuteflapistheshowipeigrpeventcommand.Bydefault,therouterkeepsalogofallEIGRPevents.However,thelogsizeisonly500lines,whichcoversonlyafewhundredmillisecondsofEIGRPevents.TheshowipeigrpeventcommandprovidesyouwithaglimpseofEIGRPeventsthatincludestheneighborsthatareupdatingtherouterwiththerouteidentifiedandthemetricwithwhichtheneighborupdatestherouter.ConsiderthenetworkshowninFigure7–28.

Figure7-28EIGRPNetworkSusceptibletoEIGRPRouteFlap

InFigure7-28,arouteof150.150.0.0/16innetworkcloudXgetspassedtoRouterAfromRoutersB,C,andD.RouterAchoosesRouterCasthenexthoptonetwork150.150.0.0/16andputsRoutersBandDasthefeasiblesuccessorstothenetwork150.150.0.0/16.Example7-49showsthepertinentconfigurationforallfourrouters.Example7-49ConfigurationsforRoutersA,B,C,andDinFigure7-28

RouterA#interfaceethernet0ipaddress10.1.1.1255.255.255.0interfaceserial0ipaddress10.1.2.1255.255.255.0

RouterB#interfaceserial0ipaddress10.1.2.2255.255.255.0interfaceserial1ipaddress10.1.3.1255.255.255.0

RouterC#interfaceethernet0ipaddress10.1.1.2255.255.255.0interfaceserial0ipaddress10.1.4.1255.255.255.0

RouterD#interfaceethernet0ipaddress10.1.1.3255.255.255.0interfaceserial0ipaddress10.1.5.1255.255.255.0

TheproblemhappensinRouterAwheretheroutetimerfortheroute150.150.0.0/16intheroutingtableisconstantlyat00:00:00.BylookingatRouterC,thenexthoptotheroute,youcanseethattherouteisstableandisnotflapping.TheneighborrelationshipinRouterAisalsostable,andtheinterfacesonRouterAarestablewithnosignsofinterfaceflapping.ThenextstepistolookattheeventloginEIGRPandseewhichneighborisupdatingRouterAconstantlyabouttheroute150.150.0.0/16.Example7-50showstherelevantinformationintheEIGRPeventlogonRouterA.Example7-50showipeigrpeventCommandOutputonRouterA

RouterA#showipeigrpevent

20:47:13.2Rcvupdatedest/nh:150.150.0.0/1610.1.1.320:47:13.2Metricset:150.150.0.0/16487219820:47:13.2Rcvupdatedest/nh:150.150.0.0/1610.1.1.320:47:13.2Metricset:150.150.0.0/164872198

Otheroutputintheeventlogexists,butonlytheimportantlinesareshownhere.Tomakesurethattherouterisconstantlygettingupdates,theshowipeigrpeventcommandhastobedoneseveraltimesinsuccession.Checkwhetherthetimerontheleftsideoftheoutputisconstantlychanging.Ifthetimerisconstantlychanging,thisindicatesthattheEIGRPprocessisconstantlycalculating.TheEIGRPeventlogisreadupsidedown,withthemostrecenteventatthetopofthelistandtheoldesteventatthebottomofthelist.TheeventloginExample7-50showsthatRouterAisconstantlygettingupdatesfrom10.1.1.3(RouterD)fortheroute150.150.0.0/16.Noticethatthenext-hoprouterthatupdatesRouterAdoesnotresettheroutetimerinRouterA.Anyfeasiblesuccessorthatupdatesarouteraboutarouteresetstheroutetimerontherouter.Therefore,theroutetimersarereset,buttheroutestaysintheroutingtablesothattherouterwon’tdropanypackets.FromtheEIGRPeventlog,it’sRouterDthatconstantlysendsupdatestoRouterA.ThenextstepistogotoRouterDtoinvestigatewhyitisupdatingRouterAwithupdates.OnepossiblereasonthatthisupdateisconstantlyoccurringisthatthereisaroutingloopinRouterDfor150.150.0.0/16routewithotherroutersinnetworkX,causingtheroutestobesenttoeachother.Ifaroutingloopoccursinthenetwork,youneedacurrentnetworkdiagramtogohopbyhoptoeachroutertotracktheroutingloop.AnotherpossibilitymightbethattheLANswitchonRouterA’sEthernet0mighthaveaspanningtreeproblemthatkeepsloopingthepacketsfromRouterDtoRouterA.Ifnoroutingloopisinthenetworkandnospanningtreeproblemisontheswitch,theotherpossibilityisthatRouterDmightberunningintoanEIGRPbuginwhichitisconstantlysendingoutupdatestoRouterAfornoreason.OneofthepossiblebugsmightbeCSCdt15109,inwhichtherouterconstantlysendsout

updatesthatisnotchanging.CiscoIOSSoftwareRelease12.1.7andlaterwillhavethebugfixforthisissue;however,itisalwaysrecommendedtoconsultwithCiscoTACtodeterminewhethertheproblemiscausedbyasoftwarebug.Inthisexample,RouterDisrunningintothesoftwarebugpreviouslymentioned.NoticethattheproblemisnotonRouterA,butonRouterD.RouterDconstantlysendsoutupdatestoRouterA,andRouterAconstantlyrefreshesitstimer.RouterAissimplyaresultoftheproblemcausedbyRouterD.AfteraCiscoIOSSoftwareupgradeonRouterD,RouterAstopsrefreshingitsroutingtabletimer,asindicatedinExample7-51.Also,performingtheshowipeigrpeventseveraltimesinsuccessionshowsthatthetimersontheeventtablearenotchanging.ThisalsoverifiesthattheEIGRPprocessisstableandisnotreceivingunnecessaryupdatesfromitsneighbors.Example7-51OutputofRoutingTableonRouterAtoVerifytheFixoftheProblem

Router_A#showiproute150.150.0.0Routingentryfor150.150.0.0/16Knownvia"eigrp1",distance90,metric4269056,typeinternalRedistributingviaeigrp1Lastupdatefrom10.1.1.2onethernet0,00:03:18agoRoutingDescriptorBlocks:*10.1.1.2,from10.1.1.2,00:03:18ago,viaethernet0Routemetricis4269056,trafficsharecountis1Totaldelayis102000microseconds,minimumbandwidthis1544KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops4

TroubleshootingEIGRPRouteSummarizationSummarizationisextremelyimportantinawell-designedEIGRPnetwork.Summarizationisoneofthefewweaponstopreventstuckinactiveproblems.Mostsummarizationproblemsaretheresultofamisconfigurationoftherouter.Figure7-29showsaflowchartfortroubleshootinganEIGRPsummarizationproblem.

Figure7-29FlowchartforTroubleshootingEIGRPSummarizationRouteProblem

EIGRPSummarizationRouteProblem—Cause:SubnetworksofSummaryRouteDon’tExistinRoutingTableConsiderthecaseshowninFigure7-30,inwhichRouterAisconfiguredtosendoutasummaryrouteof172.16.80.0255.255.240.0onitsEthernet0interfacetoRouterB.Example7-52showstheconfigurationofRouterA.However,thenext-hoprouterisnotseeingtheroute,andthe172.16.80.0255.255.240.0routeisnotintherouter’stopologytable.Example7-53showsasnapshotoftherouter’sroutingtable.

Figure7-30NetworkDiagramforCaseStudyonEIGRPSummarizationRouteProblem

Example7-52ConfigurationofRouterAintheExampleShowninFigure7-30

Router_A#interfaceethernet0ipaddress192.168.3.1255.255.255.0ipsummary-addressEIGRP1172.16.80.0255.255.240.0interfaceSerial0ipaddress192.168.1.2255.255.255.0interfaceSerial1ipaddress192.168.2.2255.255.255.0routerEIGRP1network192.168.1.0network192.168.2.0network192.168.3.0

Example7-53RoutingTableSnapshot

RouterA#showiproute

C192.168.1.0/24isdirectlyconnected,Serial0C192.168.2.0/24isdirectlyconnected,Serial1C192.168.3.0/24isdirectlyconnected,Ethernet0D172.16.99.0/24[90/409600]via192.168.1.1,Serial0D172.16.97.0/24[90/409600]via192.168.1.1,Serial0D172.16.79.0/24[90/409600]via192.168.1.1,Serial0D172.16.70.0/24[90/409600]via192.168.1.1,Serial0D172.16.103.0/24[90/409600]via192.168.1.1,Serial0D172.16.76.0/24[90/409600]via192.168.1.1,Serial0D172.16.98.0/24[90/409600]via192.168.1.1,Serial0

IntheconfigurationshowninExample7-52,thesummaryrouteisconfiguredtobe172.16.80.0255.255.240.0byusingthecommandipsummary-addresseigrp1172.16.80.0255.255.240.0.Thissummaryroutecoversthenetworkaddressrangefrom172.16.80.0to172.16.95.255.FromtheroutingtableshowninExample7-53,noticethatnoroutesfitbetweentherangeof172.16.80.0to172.16.95.255.Therefore,ifnosubnetworksoftheconfiguredsummaryroutearepresentintheroutingtable,therouterdoesn’tgeneratethesummaryroute.Thesolutiontothisproblemistoconfigureaninterfacethatfallsinthe172.16.80.0255.255.240.0range.Youcanconfigurealoopbackinterfacewithaddress172.16.81.1255.255.255.0togeneratethesummaryrouteconfiguredonEthernet0.Example7-54showsthechangedconfigurationinRouterAthatwillfixthismanual-summarizationproblem.Example7-54ChangedConfigurationofRouterAtoFixtheManual-SummarizationProblem

Router_A#interfaceloopback0

ipaddress172.16.81.1255.255.255.0interfaceEthernet0ipaddress192.168.3.1255.255.255.0ipSummary-addressEIGRP1172.16.80.0255.255.240.0interfaceSerial0ipaddress192.168.1.2255.255.255.0InterfaceSerial1ipaddress192.168.2.2255.255.255.0routerEIGRP1network172.16.0.0network192.168.1.0network192.168.2.0network192.168.3.0

Aftertheconfigurationchange,theroutingtableonRouterAshowsthemanual-summarizationrouteof172.16.80.0255.255.240.0,asshowninExample7-55.Example7-55RoutingTableSnapshotofRouterAAftertheConfigurationChangetoVerifytheFix

RouterA#showiproute

C192.168.1.0/24isdirectlyconnected,Serial0C192.168.2.0/24isdirectlyconnected,Serial1C192.168.3.0/24isdirectlyconnected,Ethernet0C172.16.81.1/24isdirectlyconnected,Loopback0D172.16.99.0/24[90/409600]via192.168.1.1,Serial0D172.16.97.0/24[90/409600]via192.168.1.1,Serial0D172.16.79.0/24[90/409600]via192.168.1.1,Serial0D172.16.70.0/24[90/409600]via192.168.1.1,Serial0D172.16.103.0/24[90/409600]via192.168.1.1,Serial0D172.16.76.0/24[90/409600]via192.168.1.1,Serial0D172.16.80.0/20isasummary,00:03:24,Null0D172.16.98.0/24[90/409600]via192.168.1.1,Serial0

EIGRPSummarizationRouteProblem—Cause:TooMuchSummarizationAnotherEIGRPsummarizationrouteproblemstemsfromwhenthesummaryroutecoversmoresubnetworksthanexist.Figure7-31showsthenetworkdiagramtorefertoforthiscasestudy.

Figure7-31EIGRPNetworkDiagram—TooMuchIPAddressSummarization

AsshowninFigure7-31,RouterBisconnectedtothenetworkcloudwithnetworkof172.16.1.0/24through172.16.15.0/24.RouterBissummarizingthosenetworksintoonebigsummaryrouteof172.16.0.0/16andsendingittoRouterA.RouterAisconnectedtothecorenetwork,andRouterAissendingRouterBadefaultrouteof0.0.0.00.0.0.0.Theproblemariseswhenadeviceinthecorenetworktriestoreachanetworkof172.16.40.0/24,whichisnonexistentinthenetwork.Whenthedeviceinthecorenetworkistryingtopingortraceroutetothe172.16.40.0network,thepacketsareloopingbetweenRouterAandRouterB.Example7-56showsRouterA’sroutingtablefor172.16.40.0.Example7-56RouterARoutingTablefor172.16.40.0


Routingentryfor172.16.0.0/16Knownvia"EIGRP1",distance90,metric409600,typeinternalLastupdatefrom192.168.2.2onSerial0,00:20:25agoRoutingDescriptorBlocks:*192.168.2.2from192.168.2.2,00:20:25ago,viaSerial0Routemetricis409600,trafficsharecountis1Totaldelayis6000microseconds,minimumbandwidthis10000KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops1

TheroutingentryinRouterAshowsthesummaryrouteof172.16.0.0/16comingfromRouterB.Therefore,RouterAforwardsthepackettoRouterB.However,RouterBsendsthepacketrightbacktoRouterAbecauseRouterBdoesn’thavetheroutefor172.16.40.0;ithasonlythedefaultroutepointingbacktoRouterA.ThiscausestheroutingloopbetweenRouterAandRouterBforanynonexistentnetworkinthe172.16.0.0/16range.Thisproblemismoreofadesignissue.ThemainissueisthatRouterB’ssummaryrouteistoobroadandincludesnonexistentsubnets.Also,RouterAissendingamoregeneralsummaryroute(defaultroute)toRouterB.ThesolutionistohaveRouterBsendoutonlythesummaryroutethatcoversthe172.16.1.0through172.16.15.0networks.Inotherwords,insteadofsendingthe172.16.0.0/16summaryroute,RouterBcansendthe172.16.0.0255.255.240.0summaryroutetoRouterA.Therefore,whenRouterAtriestolookattheroutingtableforthe172.16.40.0/24entry,theroutingtablesimplyreturnswith%NetworknotintablemessageanddropsthepacketinsteadofsendingittoRouterB,whichendstheloop.

TroubleshootingEIGRPRedistributionProblemsInmanyinstances,aproblemoccurswhenredistributingfromanotherroutingprotocolintoEIGRP.Figure7-32showsaflowchartfortroubleshootingEIGRPredistributionproblem.

Figure7-32FlowchartforTroubleshootingEIGRPRedistributionProblem

ConsiderthenetworkdiagraminFigure7-33,inwhichtherouteristheborderrouterbetweenthreeroutingprotocols,RIP,OSPF,andEIGRP.

Figure7-33NetworkSusceptibletoEIGRPRedistributionProblems

Example7-57showstheconfigurationforRouterA.Example7-57ConfigurationforRouterAinFigure7-33

RouterA#interfaceethernet0ipaddress172.16.1.1255.255.255.0interfaceethernet1ipaddress172.16.2.1255.255.255.0interfaceserial0ipaddress172.16.3.1255.255.255.0routerospf1network172.16.0.00.0.255.255area0routerripnetwork172.16.0.0passive-interfaceethernet1

routereigrp1network172.16.0.0redistributeripdefault-metric1000010025511500

RouterAwantstoredistributealltheroutesintheRIPdomainintotheEIGRPdomain.Theproblemisthatthenetwork150.150.0.0/16isnotgettingredistributedintotheEIGRPdomain.ReferringtoFigure7-33,youcanseethatthe150.150.0.0/16networkispresentintheRIPdomainandtheOSPFdomain.BeforetherouteisgettingredistributedintoEIGRP,theroutemustbeintheEIGRPtopologytablefirst.LookattheEIGRPtopologytableonRouterAforthe150.150.0.0/16networkinExample7-58.Example7-58EIGRPTopologyTablefor150.150.0.0/16

RouterA#showipeigrptopology150.150.0.0255.255.0.0

%Routenotintopologytable

Asthisoutputshows,theroute150.150.0.0/16isnotevenintheEIGRPtopologytable.Example7-59showstheroutingtableforthe150.150.0.0/16network.Example7-59RoutingTablefor150.150.0.0/16

RouterA#showiproute150.150.0.0255.255.0.0

Routingentryfor150.150.0.0/16Knownvia"OSPF1",distance110,metric186RedistributingviaOSPF1Lastupdatefrom172.16.2.2onEthernet1RoutingDescriptorBlocks:*172.16.2.2,from172.16.2.2,00:10:23ago,viaEthernet1Routemetricis186,trafficsharecountis1

TheoutputinExample7-59showsthatthe150.150.0.0/16routeisshowingupasanOSPFroute,notaRIProute.ThisiswhytherouteisnotgettingredistributedintoEIGRP.BeforeRIProutesareredistributedintoEIGRP,therouterlooksattheroutingtableandredistributesalltheRIProutesintoEIGRP.AsExample7-59shows,therouterhearstheupdateforthe150.150.0.0/16routefrombothOSPFandRIP.TherouterinstallstheOSPFroutebecauseOSPFhasaloweradministrativedistancethanRIP.Therefore,iftherouteisshowingupasanOSPFroute,therouterwillnotredistributethisrouteintoEIGRP.Inotherwords,therouterwillredistributeonlyRIProutesthatareshowingintheroutingtableintotheEIGRPdomain.Theresolvethisproblem,youmustmakeRouterAinstalltheRIProuteinsteadoftheOSPFroute.OnewaytodothisistoconfigureadistributelistunderOSPFtonotinstallthe150.150.0.0/16route,asdemonstratedinExample7-60.Example7-60ConfiguringaDistributeListUnderOSPFtoNotInstallthe150.150.0.0/16Route

routerOSPF1network172.16.0.00.0.255.255area0distribute-list1outaccess-list1deny150.150.0.00.0.255.255access-list1permitany

Withthedistributelistinplace,RouterA’sroutingtableforthe150.150.0.0/16willnowshowtheresultsinExample7-61.Example7-61RoutingTablefor150.150.0.0/16AfterConfiguringtheDistributeListinExample7-60

RouterA#showiproute150.150.0.0255.255.0.0

Routingentryfor150.150.0.0/16Knownvia"RIP",distance120,metric4RedistributingviaRIPLastupdatefrom172.16.3.2onSerial0RoutingDescriptorBlocks:*172.16.3.2,from172.16.3.2,00:00:23ago,viaSerial0Routemetricis4,trafficsharecountis1

BecausetheroutingtableinRouterAshowsthe150.150.0.0/16routeasaRIProute,redistributionintoEIGRPtakesplaceandtheEIGRPtopologytableinRouterAnowshowstheresultsinExample7-62.Example7-62EIGRPTopologyTablefor150.150.0.0/16AfterConfiguringtheDistributeListinExample7-60

RouterA#showipeigrptopology150.150.0.0255.255.0.0

IP-EIGRPtopologyentryfor150.150.0.0/16StateisPassive,Queryoriginflagis1,1Successor(s),FDis281600RoutingDescriptorBlocks:0.0.0.0,fromRIP,Sendflagis0x0

Compositemetricis(281600/0),RouteisExternalVectormetric:Minimumbandwidthis10000KbitTotaldelayis1000microsecondsReliabilityis255/255Loadis1/255MinimumMTUis1500Hopcountis0Externaldata:Originatingrouteris172.16.3.1(thissystem)ASnumberofroutesis0ExternalprotocolisRIP,externalmetricis4Administratortagis0

Thetopologytableshowsthatroute150.150.0.0/16isgettingredistributedintoEIGRPwiththeexternalroutingprotocolbeingRIP.Theoriginatingrouteris172.16.3.1,whichisRouterA.ConsideranothercaseinwhichthenetworksetupisshowninFigure7-34.TheroutesintheOSPFdomainfailstoberedistributedintotheEIGRPdomain.

Figure7-34NetworkSetupofCaseStudyforOSPFtoEIGRPRouteRedistributionProblem

FromthesetupshowninFigure7-34,RouterBisredistributingfromOSPFtoEIGRP.The10.0.0.0/8networkcomesfromtheOSPFdomainandisbeingredistributedintoEIGRPdomainbyRouterB.However,RouterAneverseesthe10.0.0.0/8routeinitsroutingtable.Example7-63showstheconfigurationofRouterAandRouterB,andExample7-64showstheroutingtableof10.0.0.0/8routeinRouterAandRouterB.Example7-63ConfigurationsforRoutersAandBforNetworkSetupinFigure7-34

RouterA#interfaceethernet0ipaddress172.16.3.1255.255.255.0interfaceserial0ipaddress172.16.1.1255.255.255.0routereigrp1network172.16.0.0

RouterB#interfaceethernet0ipaddress172.16.2.1255.255.255.0interfaceserial0ipaddress172.16.1.2255.255.255.0routerospf1network172.16.0.00.0.255.255area0routereigrp1network172.16.0.0redistributeospf1

Example7-64RoutingTableandEIGRPTopologyTablefor10.0.0.0/8RouteinRoutersAandB

Router_A#showiproute10.0.0.0255.0.0.0%Networknotintable

Router_A#showipeigrptopology10.0.0.0255.0.0.0%Routenotintopologytable

Router_B#showiproute10.0.0.0255.0.0.0Routingentryfor10.0.0.0/8Knownvia"OSPF1",distance110,metric206RedistributingviaOSPF1Lastupdatefrom172.16.2.2onEthernet0RoutingDescriptorBlocks:*172.16.2.2,from172.16.2.2,00:18:13ago,viaEthernet0Routemetricis206,trafficsharecountis1

Router_B#showipeigrptopology10.0.0.0255.0.0.0%Routenotintopologytable

FromtheoutputofExample7-64,noticethatRouterBhasthe10.0.0.0/24routeinitsroutingtableasanOSPFroute,butRouterAdoesn’thavetheroutingentryfor10.0.0.0/8.Also,theEIGRPtopologytableonRouterBdoesn’tevenhavetheentryforthe10.0.0.0/8route.YoucanconcludefromthisthattheOSPFtoEIGRPredistributioninRouterBisnotworking.BylookingovertheconfigurationinRouterB,younoticethatalthoughtheredistributeospf1commandisconfiguredunderEIGRP,thereisnoconfigurationofthedefault-metriccommand.Whenredistributingbetweendifferentroutingprotocols,thedefault-metriccommandmustbeconfigured.Whenoneroutingprotocolisbeingredistributedintoanother,therouterdoesn’thaveawaytotranslatetheroutingmetricfromoneroutingprotocolintoanother.Thedefault-metriccommandisusedsothatthenetworkadministratorcanmanuallyinitializetheroutingmetricduringrouteredistribution.Thefixforthisproblem:ConfigureadefaultmetricunderEIGRPinRouterB.Example7-65showsthecorrectedconfigurationofRouterB.Example7-65CorrectedConfigurationsofRouterBtoFixtheRedistributionProblemShowninFigure7-34

RouterB#interfaceethernet0ipaddress172.16.2.1255.255.255.0interfaceserial0ipaddress172.16.1.2255.255.255.0routerospf1network172.16.0.00.0.255.255area0routereigrp1network172.16.0.0redistributeospf1default-metric1000010025511500

FromExample7-65,thedefaultmetricconfiguredisdefault-metric1000010025511500.10000isthebandwidthinkilobitspersecond.100istheinterfacedelayinunitof10microseconds.255isinterfacereliability,where255represents100percentreliable.1isinterfaceload,where255represents100percentload.Thelastnumber,1500,istheMTUoftheinterface.Becausethe10.0.0.0/8routecomesfromtheEthernetinterfaceofRouterB,wearesettingthedefaultmetricsthatmatchestheEthernetinterface—namely,bandwidthof10,000kbps,delayof1000ms,100percentreliability,1/255ofinterfaceload,andanMTUof1500bytes.Keepinmindthattherouterwillacceptanyvaluesforthe

defaultmetricsetting.Therouterwillevenacceptdefaultmetricvalueof11111.However,usingthedefaultmetricvaluethatbestmatchesthenetworktopologywillallowtheroutertomakeabetterroutingdecision.NowwiththecorrectconfigurationinplaceinRouterB,Example7-66showstheroutingtableinRouterAforthe10.0.0.0/8route.Example7-66RoutingTableonRouterAandEIGRPTopologyTableinRouterBforthe10.0.0.0/8RoutetoVerifytheFix

Router_A#showiproute10.0.0.0Routingentryfor10.0.0.0/8Knownvia"eigrp1",distance170,metric2195456,typeexternalRedistributingviaeigrp1Lastupdatefrom172.16.1.2onSerial0,00:16:37agoRoutingDescriptorBlocks:*172.16.1.2,from172.16.1.2,00:16:37ago,viaSerial0Routemetricis2195456,trafficsharecountis1Totaldelayis21000microseconds,minimumbandwidthis1544KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops1

RouterB#showipeigrptopology10.0.0.0255.0.0.0IP-EIGRPtopologyentryfor10.0.0.0/8StateisPassive,Queryoriginflagis1,1Successor(s),FDis281600RoutingDescriptorBlocks:0.0.0.0,fromRedistributed,Sendflagis0x0Compositemetricis(281600/0),RouteisExternalVectormetric:Minimumbandwidthis10000KbitTotaldelayis1000microsecondsReliabilityis255/255Loadis1/255MinimumMTUis1500Hopcountis0Externaldata:Originatingrouteris172.16.2.1(thissystem)ASnumberofroutesis1ExternalprotocolisOSPF,externalmetricis206Administratortagis0

FromExample7-66,youcanseethatRouterAhasthe10.0.0.0/8routeasEIGRPexternalroute,whereasRouterBhastheEIGRPtopologyentryforthe10.0.0.0/8route.The10.0.0.0/8routenowhasbeensuccessfullybeingredistributedfromOSPFintoEIGRP.

TroubleshootingEIGRPDialBackupProblemDialbackupisacommonsetupontheremoteaccessrouters.Whentheprimarylinkfails,dialbackupprovidesanothermeansofnetworkconnection.ThissectiondiscussesEIGRPdialbackupissues,inwhichtherouterdoesn’tdisconnectthedialerinterfacewhentheprimarylinkcomesback.SeetheflowchartinFigure7-35fortroubleshootingEIGRPdial-backupproblems.

Figure7-35FlowchartforTroubleshootingEIGRPDial-BackupProblems

Figure7-36showsthenetworksetupforthecasestudyontheEIGRPdialbackupproblem.

Figure7-36NetworkSusceptibletoEIGRPDial-BackupProblems

AsFigure7-36illustrates,RouterAandRouterBareconnectedbyaT1lineastheprimarylink.TheISDNbackupservesasthebackuplinkiftheprimarylinkfails.Example7-67showstheconfigurationsforRoutersAandB.Example7-67ConfigurationsforRoutersAandBinFigure7-36

RouterA#isdnswitch-typebasic-5essinterfaceethernet0ipaddress172.16.1.1255.255.255.128interfaceserial0ipaddress172.16.2.1255.255.255.0

interfacebri0ipaddress172.16.3.1255.255.255.0encapsulationpppdialermapip172.16.3.2nameRouterBbroadcast1234567pppauthenticationchapdialer-group1routerEIGRP1network172.16.0.0access-list101denyeigrpanyanyaccess-list101permitipanyanydialer-list1protocoliplist101iproute172.16.4.0255.255.255.128172.16.3.2200

RouterB#isdnswitch-typebasic-5essinterfaceethernet0ipaddress172.16.4.1255.255.255.128interfaceserial0ipaddress172.16.2.2255.255.255.0interfacebri0ipaddress172.16.3.2255.255.255.0encapsulationpppdialermapIP172.16.3.1nameRouter_Abroadcast3456789pppauthenticationchapdialer-group1routereigrp1network172.16.0.0access-list101denyeigrpanyanyaccess-list101permitipanyanydialer-list1protocoliplist101iproute172.16.1.0255.255.255.128172.16.3.1200

Fromtheconfiguration,thebackupisdonethroughthefloatingstaticrouteattheendoftheconfiguration.Whentheprimaryinterface(Serial0)isdown,theprimaryEIGRProutegoesawayandthefloatingstaticrouteisinstalledintheroutingtablethatusestheBRIport.Thedialerlististiedwithaccess-list101,whichinitiatesthedialwithanyIPpacketexceptforEIGRPhellos.ThiswillnotcausetheBRIlinktocontinuouslydialbecauseofEIGRPhellopackets.Inthisscenario,whentheprimarylinkgoesdown,theBRIlinkcomesupandpassestrafficbecauseofthefloatingstaticroute.Thenetworkadministratoristryingtofixthelinkproblem;indoingso,thenetworkadministratorreloadedRouterB.WhenRouterBcamebackup,theprimarylinkalsocameup.Theproblemisthatnowevenwhentheprimarylinkcamebackup,theBRIlinkisstillupandthetrafficstillispassingthroughBRIport.OnRouterA,youmustverifythattheroutingtableentryfortheinterestingtrafficiscorrect.Example7-68showstheoutputofshowiproute172.16.4.0onRouterA.Example7-68RoutingTablefor172.16.4.0


Routingentryfor172.16.4.0/25Knownvia"static",distance200,metric0RoutingDescriptorBlocks:*172.16.3.2

Routemetricis0,trafficsharecountis1

TheoutputinExample7-68showsthatRouterAstillisinstallingthefloatingstaticroutetoRouterB’sEthernetnetwork.ThenextstepistomakesurethatEIGRPneighborsareproperlyestablishedbetweenRouterAandRouterBovertheprimaryinterface.Youcanverifythiswiththeshowipeigrpneighborcommand,asdemonstratedonbothRouterAandRouterBinExample7-69.Example7-69VerifyinganEIGRPNeighborRelationshipBetweenRoutersAandB

RouterA#showipeigrpneighbor

IP-EIGRPneighborsforprocess1HAddressInterfaceHoldUptimeSRTTRTOQSeq(sec)(ms)CntNum0172.16.2.2S01200:10:23212000231172.16.3.2BRI01200:10:2340240050

RouterB#showipeigrpneighbor

IP-EIGRPneighborsforprocess1HAddressInterfaceHoldUptimeSRTTRTOQSeq(sec)(ms)CntNum0172.16.2.1S01200:10:30212000241172.16.3.1BRI01200:10:3040240051

Theneighborrelationshiplooksfinefrombothrouters.BothRoutersAandBshowthattheneighborsareestablishedwithoutaproblem.ThenextstepistolookattheconfigurationonRouterBtomakesurethateverythingisconfiguredproperly.Example7-70showsRouterB’sconfigurationafterreload.Example7-70RouterBConfigurationAfterReload

RouterB#interfaceethernet0ipaddress172.16.4.1255.255.255.0interfaceserial0ipaddress172.16.2.2255.255.255.0interfacebri0ipaddress172.16.3.2255.255.255.0encapsulationPPPdialermapIP172.16.3.1nameRouterAbroadcastxxxpppauthenticationchapdialer-group1routereigrp1network172.16.0.0access-list101denyeigrpanyanyaccess-list101permitIPanyanydialer-list1protocolIPlist101iproute172.16.1.0255.255.255.128172.16.3.1200

Noticethatnow,inEthernet0’sconfigurationinRouterB,theIPaddressis172.16.4.1255.255.255.0;themaskhaschangedfrom25to24.Thisisthecauseoftheproblem.WhenRouterBadvertisesitsEthernet0routetoRouterA,itadvertisesthe172.16.4.0/24routetoRouterA,andRouterAstillinstallsthefloatingstaticrouteof172.16.4.0/25.Theroutingtableshowsthe/25routebecauseithasalongersubnetmask.ThewrongmaskappearsbecausewhenthenetworkadministratorreloadedRouterB,RouterBusedtheoldconfigurationthatithadstored,andEthernet0’soldsubnetmaska/24beforethenetworkadministratorchangeditto/25.Whenthechangeismade,thenetworkadministratordidn’tsavetheconfiguration.

ThesolutiontothisproblemistochangetheIPaddresssubnetmaskinRouterBtothe/25subnetmask.Example7-71showstheconfigurationforRouterB’sEthernet0interface.Example7-71ProperlyConfiguringtheSubnetMaskforRouterB’sEthernet0Interface

RouterB#interfaceethernet0ipaddress172.16.4.1255.255.255.128

ThischangenowcausesRouterBtosendanEIGRPupdateof172.16.4.0/25toRouterA,whichcausesRouterAtousetheEIGRProuteinsteadofthefloatingstaticroute.Example7-72showswhatRouterA’sroutingtablenowlookslike.Example7-72RoutingTablefor172.16.4.0onRouterAAftertheConfigurationChangeinExample7-71


Routingentryfor172.16.4.0/25Knownvia"EIGRP1",distance90,metric2195456,typeinternalRedistributingviaeigrp1Lastupdatefrom172.16.2.2onSerial0,00:10:30agoRoutingDescriptorBlocks:*172.16.2.2,from172.16.2.2,00:10:30ago,viaSerial0Routemetricis2195456,trafficsharecountis1Totaldelayis21000microseconds,minimumbandwidthis1544KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops1

ThetrafficstopsflowingtotheBRI0interfaceandstartstoflowtotheprimarylink.TheBRIinterfacethengoesdownandmovestobackupmodeagain.

EIGRPErrorMessagesSomeEIGRPerrormessagesthatoccurintheloghavemystifiedmanynetworkadministrators.ThissectiondiscussessomeofthemostcommonEIGRPerrorsthatappearandthemeaningsbehindtheseEIGRPerrormessages:•DUAL-3-SIA—Thismessagemeansthattheprimaryrouteisgoneandnofeasiblesuccessorisavailable.Therouterhassentoutthequeriestoitsneighborandhasnotheardthereplyfromaparticularneighborformorethanthreeminutes.Theroutestateisnowstuckinactivestate.Amoredetaileddiscussionaboutthiserrorisinthe“TroubleshootingEIGRPNeighborRelationships”section.•Neighbornotoncommonsubnet—Thismessagemeansthattherouterhasheardahellopacketfromaneighborthatisnotonthesamesubnetastherouter.Amoredetaileddiscussionaboutthiserroralsocanbefoundinthe“TroubleshootingEIGRPNeighborRelationships”section.•DUAL-3-BADCOUNT—BadcountmeansthatEIGRPbelievesthatitknowsofmoreroutesforagivennetworkthanactuallyexist.It’stypically(notalways)seeninconjunctionwithDUAL-3-SIAs,butitisnotbelievedtocauseanyproblemsbyitself.•Unequal,<route>,dndb=<metric>,query=<metric>—Thismessageisinformationalonly.Itsaysthatthemetrictherouterhadatthetimeofthequerydoesnotmatchthemetricthatithadwhenitreceivedthereply.•DUAL-3-INTERNAL:IP-EIGRPInternalError—ThismessageindicatesthatthereisanEIGRP

internalerror.However,therouteriscodedtofullyrecoverfromthisinternalerror.TheEIGRPinternalerroriscausedbysoftwareproblemandshouldnotaffecttheoperationoftherouter.TheplanofactionistoreportthiserrortotheTACandhavetheexpertsdecodethetracebackmessage.HavethemidentifythebugnumberandupgradeCiscoIOSSoftwareaccordingly.•IP-EIGRP:Callback:callbackup_routes—Atsomepoint,EIGRPattemptedtoinstallroutestothedestinationsandfailed,mostcommonlybecauseoftheexistenceofaroutewithabetteradministrativedistance.Whenthisoccurs,EIGRPregistersitsrouteasabackuproute.Whenthebetterroutedisappearsfromtheroutingtable,EIGRPiscalledbackthroughcallbackup_routessothatitcanattempttoreinstalltheroutesthatitisholdinginthetopologytable.•ErrorEIGRP:DDBnotconfiguredoninterface—Thismeansthatwhentherouter’sinterfacereceivesanEIGRPhellopacketandtheroutergoestoassociatethepacketwithaDDB(DUALdescriptorblock)forthatinterface,itdoesnotfindonethatmatches.Thismeansthattherouterisreceivingahellopacketontheinterfaceinwhichdoesn’thaveEIGRPconfigured.•Poisonsquashed—Therouterthreadsatopologytableentryasapoisoninreplytoanupdate(theroutersetupforpoisonreverse).Whiletherouterisbuildingthepacketthatcontainsthepoisonreverse,therouterrealizesthatitdoesn’tneedtosendit.Forexample,iftherouterreceivesaqueryforthatroutefromtheneighbor,itiscurrentlythreadedtopoison.

SummaryThischapterdiscussesmethodsfortroubleshootingvariousEIGRPproblems.Theflowchartspresentedforeachcategoryofproblemsgiveyougooddirectiononthetroubleshootingpath.Whendoingadebugontherouter,keepinmindthatanydebughasthepotentialtooverwhelmtherouter,andthedebugmustbedonewhentherouterhaslowCPUutilizationandpreferablyduringamaintenancewindow.Agreatdealofthetroubleshootingcanbedonebyjustdoingtheshowcommands,aspointedoutinthischapter.Takethetimetounderstandthedetailsoftheoutputofthevariousshowcommandsintroduced.Thisway,whentheproblemhappens,youcanquicklyandswiftlyidentifytheproblemandfixit.

Chapter8.UnderstandingOpenShortestPathFirst(OSPF)

ThischaptercoversthefollowingkeytopicsabouttheOpenShortestPathFirst(OSPF)protocol:•OSPFpacketdetails•OSPFLSAdetails•OSPFareas•OSPFmediatypes•OSPFadjacencies

OSPFisalink-stateinteriorgatewayprotocoldesignedforalargecomplexnetwork.AnIETFstandard,OSPFiswidelydeployedinmanylargenetworks.Developmentbeganin1987,andOSPFVersion2wasestablishedin1991withRFC1247.Thegoalwastohavealink-stateprotocolthatismoreefficientandscalablethanRIP.RFC2328(April1998)isthelatestrevisiontoOSPFVersion2.OSPFrunsontopofIPandusesprotocolnumber89,justasTCPrunsontopofIPandusesprotocolnumber6.OSPFdoesn’tuseanytransportprotocol,suchasTCP,forreliability.Theprotocolitselfhasareliablemechanismoftransportation.OSPFisaclasslessroutingprotocolthatsupportsvariable-lengthsubnetmasking(VLSM)anddiscontiguousnetworks.OSPFemploysmulticastaddresses224.0.0.5(allSPFrouters)and224.0.0.6(designatedrouters[DR]andbackupdesignatedrouters[BDR])tosendHellosandupdates.OSPFalsoprovidestwotypesofauthentication—plaintextandmessagedigestalgorithm5(MD5).OSPFusestheDijkstraalgorithmasapartoftheroutingtablecalculationprocess.TheDijkstraalgorithmproducestheshortest-pathtree(SPT).Eachrouterrepresentsitselfanditslinkstotheneighborsinanunderstandableform—link-stateadvertisements(LSAs).Basedoninformationfromtheshortestpathtree,OSPFcandrawthenetworktopology.EachrouterinOSPFexchangesinformationaboutitscost,typeoflink,andnetworkinformationwiththeotherrouters.Discussedlaterinthechapter,thismultistepprocessiscalledlink-stateadvertisement(LSA)exchange.

OSPFPacketDetailsOSPFhasfivetypesofpacketsusedforvariousreasons.Table8-1documentsthedifferentOSPFpackettypesanddescribestheirfunctionality.

Table8-1OSPFPacketTypes

AlltheOSPFpackettypesshareacommon20-byteOSPFprotocolheader.Figure8-1showsthecommonOSPFprotocolheaderformat.

Figure8-1CommonOSPFProtocolHeaderFormat

ThelistthatfollowsdescribesthefieldsintheOSPFprotocolheader:•VersionNumber—ThisfieldrepresentsthecurrentversionnumberofOSPF.Thelatestversionis2.Version1isnotcompatiblewithVersion2.•Type—ThisfieldindicateswhichofthefivetypesofOSPFpacketsisappendedattheendofthisheader.•PacketLength—ThisfieldcontainsthelengthoftheentireOSPFpacket,includingtheOSPFheader.•RouterID—Thisfieldcontainsthe4-byteIPaddress.TherouterIDisusedtouniquelyidentifytherouterthroughouttheautonomoussystem.ForaCiscobox,thisfieldcontainsthehighestIPaddressonthebox.Ifloopbacksareconfigured,thehighestloopbackbecomestherouterID.AftertherouterIDischosen,itwillnotchangeunlesstherouterisrestarted,theinterfacethatis

selectedasarouterIDisshutdown,ortheIPaddresshasbeenremovedorreplacedonthatinterface.•AreaID—Thisfielddesignatestheareanumbertowhichthispacketbelongs.Thisisalsoa4-bytenumber.Thevaluemustbethesameonbothsidestoformneighborrelationships.Therearetwowaystowritethis:Area1orArea0.0.0.1.Thereisnodifferencebetweenthetwo.•Checksum—ThisfieldincludesthechecksumfortheentireOSPFpacket,excludingtheauthenticationfordatacorruption.•AuType—Thisfieldcontainsthetypecodefortheauthentication:

—0meansthatthereisanullauthentication.—1meansthattheauthenticationtypeisplaintext.—2meansthattheauthenticationtypeisMD5.

•Authentication—This64-bitfieldcontainstheauthenticationkeyincaseofplain-textauthentication.Incaseofmessagedigest,the64-bitAuthenticationfieldisredefinedintoseveralotherparameters.SeeAppendixDofRFC2328formoredetailontheMD5authenticationscheme.

HelloPacketsHellopacketsarethefirsttypeofpacketsinOSPF.Figure8-2illustratestheHellopacketformat.Hellopacketsareusedtoformaneighborrelationshipbetweentworouters.Inenvironmentsthatincludebroadcast/nonbroadcastmedia,Hellopacketsareusedtoelectthedesignated(DR)andbackupdesignated(BDR)routers.Onbroadcastmedia,thedestinationaddressoftheHellopacketsis224.0.0.5.Onnonbroadcastmedia,thedestinationaddressisunicast.

Figure8-2HelloPacketFormat

ThelistthatfollowsdescribesthefieldsintheHellopacket:•NetworkMask—RepresentsthenetworkmaskoftheinterfaceonwhichOSPFisrunning.Thenetworkmaskischeckedonlyonbroadcastmedia.•HelloInterval—RepresentsthenumberofsecondsbetweentwoHellopackets.Thisintervalmustbethesameforthetworoutersthataretryingtoformanadjacency.TheHellointervalis10secondsonbroadcastandpoint-to-pointmedia,and30secondsonallothermedia.•Options—Representstheoptionalcapabilitiessupportedbytherouter.TheOptionsfieldhasthefollowingformat:

—ObitisusedforopaqueLSAs,mentionedinRFC2370—DCisusedfordemandcircuitcapabilities,mentionedinRFC1793—EAistheexternalattribute—N/Pisusedfornot-so-stubbyarea(NSSA)option,mentionedinRFC1587—MCdesignatesmulticastOSPF—E,whenset,meansthatexternalLSAareallowedinthisarea—TbitisusedforToScapability(normallysetto0)

ThefirstbitintheOptionsfieldisreservedforfutureuse.CiscoroutersalsodonotuseEAandMCbits.•RtrPri—Usedforarouter’spriority.Bydefault,thisvalueissetto1.ThisfieldplaysanimportantroleinelectingtheDRandtheBDR.AhigherpriorityincreasesthechancesthattherouterwillbecometheDR.Apriorityof0meansthatthisrouterwillnottakepartinDRelection.•RouterDeadInterval—Representsthenumber,inseconds,beforeaneighborisdeclareddead.Bydefault,thedeadintervalisfourtimestheHellointerval.•DesignatedRouter—ListstheIPaddressofthedesignatedrouter.IfthereisnoDR,thisfieldhasavalueof0.0.0.0.TheDRiselectedthroughtheHelloprotocol.TherouterwiththehighestprioritybecomestheDR.Iftheprioritiesareequal,therouterwiththehighestrouterIDbecomestheDR.ThepurposeoftheDRistoreducetheamountoffloodingonmultiaccessmedia.TheDRusesmulticastingtoreducetheamountofflooding.Allroutersfloodtheirlink-statedatabasetotheDR,andtheDRthenfloodsthatinformationbacktootherroutersonthatsegment.NoDRs/BDRsexistonpoint-to-pointorpoint-to-multipointsegments.•BackupDesignatedRouter—IdentifiestheBDRandliststheinterfaceIPaddressoftheBDR.IfnoBDRexists,thisfieldhasavalueof0.0.0.0.TheBDRisalsoelectedthroughtheHelloprotocol.ThepurposeoftheBDRistoserveasthebackupoftheDR,forasmoothertransitionincasetheDRdies.BDRremainspassiveduringflooding.•Neighbor—ContainstherouterIDofeachneighborfromwhichaHelloisseen.

DatabaseDescriptionPacketsThesecondtypeofOSPFpacket,thedatabasedescription(DBD)packet,isusedmostlyduringthedatabaseexchange.ThefirstDBDpacketisusedtoelectthemasterandslaverelationshipandtosettheinitialsequencenumberelectedbythemaster.TherouterwiththehighestrouterIDbecomesthemasterandinitiatesthedatabasesynchronization.Themastersendsthesequencenumber,andtheslaveacknowledgesit.Afterthemasterandtheslaveareelected,thedatabasesynchronizationstarts;inthisprocess,theheadersofalltheLSAsareexchangedwithneighbors.Figure8-3illustratestheDBDpacketformat.

Figure8-3DatabaseDescriptionPacketFormat

ThelistthatfollowsdescribesthefieldsintheDBDpacket:•InterfaceMTU—Thisfieldcontainsthelargestdatasize,inbytes,thatcanbesendthroughtheassociatedinterface.ThisoptionhasbeenaddedstartingfromRFC2178.Thisfieldmustbesetto0whensendingthepacketoveravirtuallink.•Options—OptionsforthisfieldwerediscussedintheprevioussectionontheHellopacketformat.•IBit—Whensetto1,thismeansthatthisisthefirstpacketinDBDexchange.•MBit—Whensetto1,thismeansthatmorepacketswillfollow.•MSBit—Usethisformasterandslave.Whenthisbitisset,itmeansthattherouterisamasterintheDBDexchangeprocess.Ifthisbitissetto0,itmeansthattherouteristheslave.•DBDSequenceNumber—Thisfieldcontainsauniquevaluesetbythemaster.Thissequencenumberisusedduringdatabaseexchange.Onlyamastercanincrementthesequencenumber.•LSAHeader—Thisfieldconsistsofalistofthelink-statedatabaseheaders.

Link-StateRequestPacketsTheType3OSPFpacket,alink-staterequestpacket,issentifpartofthedatabaseismissingorout-of-date.Thelink-staterequestpacketisusedtoretrievethatprecisepieceofdatabaseinformationthatismissing.Link-statepacketsarealsousedaftertheDBDexchangeisfinishedtorequesttheLSAsthathavebeenseenduringtheDBDexchange.Figure8-4illustratesthelink-staterequestpacketformat.

Figure8-4Link-StateRequestPacketFormat

Thelistthatfollowsdescribesthefieldsinthelink-staterequestpacket:•LSType—IdentifieswhattypeofLSAisbeingrequested.•Link-StateID—Representsthelink-stateIDofthatspecificLSA.Link-stateIDisdiscussedlaterinthischapter.•AdvertisingRouter—ContainstherouterIDoftherouterthatisoriginatingthisLSA.

Link-StateUpdatePacketsOSPFpacketType4,thelink-stateupdatepacket,implementsflooding.SeveralLSAsareincludedinasinglepacket.Link-stateupdatepacketsarealsosentinresponsetolink-staterequestpackets.FloodedLSAsareacknowledgedintheLSAacknowledgmentpacket.IfanLSAisnotacknowledged,itisretransmittedeveryretransmitinterval(5seconds,bydefault).Figure8-5illustratesthelink-stateupdatepacketformat.

Figure8-5Link-StateUpdatePacketFormat

AsFigure8-5shows,thispacketcontainsthenumberofLSAs(forexample,10or20LSAs),followedbytheLSAitself.

Link-StateAcknowledgmentPacketThelasttypeofOSPFpacket,thelink-stateacknowledgmentpacket,isusedtoacknowledgeeachLSA.Thispacketissentinresponsetolink-stateupdatepackets.MultipleLSAscanbeacknowledgedinasinglelink-stateacknowledgmentpacket.Thispacketisresponsibleforthereliabledeliveryoflink-stateupdatepackets.Figure8-6illustratesthelink-stateacknowledgmentpacketformat.

Figure8-6Link-StateAcknowledgmentPacketFormat

Link-stateacknowledgmentpacketsaresentasmulticasts.IfthestateoftherouterisDRorBDR,theacknowledgmentissenttotheOSPFroutermulticastaddressof224.0.0.5.IfthestateoftherouterisnotDRorBDR,theacknowledgmentissenttotheallDRroutermulticastaddressof224.0.0.6.

OSPFLSADetailsSeveraltypesofLSAsexist.ThissectiondiscussestheninetypesofLSAsdocumentedinTable8-2.

Table8-2TypesofLSA

EachLSAhasa20-bytecommonLSAheader,theformatforwhichisillustratedinFigure8-7.

Figure8-7CommonLSAHeaderFormat

ThelistthatfollowsdescribesthefieldsintheLSAheader:•LSAge—Givesthetime,inseconds,sincetheLSAoriginated.ThemaximumageoftheLSAis3600seconds;therefreshtimeis1800seconds.IftheLSagereaches3600seconds,theLSAmustberemovedfromthedatabase.•Options—Discussedearlierinthesection“HelloPackets.”•LSType—RepresentsthetypesofLSA,severalofwhicharedocumentedinTable8-2.•Link-StateID—IdentifiestheportionofthenetworkthatisbeingdescribedbytheLSA.ThisfieldchangesaccordingtotheLStype.•AdvertisingRouter—RepresentstherouterIDoftherouteroriginatingtheLSA.•LSSequenceNumber—DetectsoldorduplicateLSAs.Eachsuccessiveinstanceisgivenasuccessivesequencenumber.Themaximumsequencenumberisrepresentedby0x7FFFFFFF.Thefirstsequencenumberisalways0x80000001.Thesequencenumber0x80000000isreserved.•LSChecksum—PerformschecksumontheLSA,notincludingLSage.AnLSAcanbecorruptedduringfloodingorwhilekeptinthememory,sothischecksumisnecessary.Thisfieldcannothaveavalueof0because0meansthatthechecksumhasnotbeenperformed.ThechecksumisperformedatthetimeofLSAgenerationorwhentheLSAisreceived.ItisalsoperformedeveryCheckAgeinterval,which,bydefault,is10minutes.•Length—IncludesthelengthoftheLSA,includingthe20-byteheader.

RouterLSARouterLSAsaregeneratedbyeachrouterforeachareatowhichtherouterbelongs.Thesepacketsdescribethestatesoftherouter’slinktotheareaandarefloodedonlywithinaparticulararea.Alltherouter’slinksinanareamustbedescribedinasingleLSA.TherouterLSAfloodsthroughouttheparticulararea;however,thefloodingofthisLSAislimitedwithinanarea.TherouterLSAofaroutercannotexistoutsidethearea;otherwise,everysinglerouterinOSPFwouldhavetocarryhugeamountsofdetailedinformation.Thosedetailsremainwithinanarea.Therouterindicateswhetherit’sanABR,ASBR,oranendpointofavirtuallink.Figure8-8showsthepacketformatfortherouterLSA.

Figure8-8RouterLSAPacketFormat

ThelistthatfollowsdescribesthefieldswithintherouterLSApacket:•BitV—Thisbitisusedtodeterminewhetherit’sanendpointofavirtuallink.•BitE—ThisbitisusedtodeterminewhetherthisrouterisanAutonomousSystemBoundaryRouter(ASBR).•BitB—ThisbitisusedtodeterminewhetherthisrouterisanAreaBorderRouter(ABR).•NumberofLinks—Thisincludesthenumberofrouterlinks.NotethattherouterLSAincludesalltherouterlinksinasingleLSAforanarea.•LinkID,LinkData,andType—TheTypefieldrepresentsthefourtypesofrouterlinks.Theothertwofields,LinkIDandLinkData,representthe4-byteIPaddressvalue,dependingonthenetworktype.Onethingtonotehereisthattherecanbetwotypesofpoint-to-pointlinks,numberedandunnumbered.Incaseofnumberedpoint-to-pointlinks,theLinkDatafieldcontainstheinterfaceaddressthatconnectstotheneighbor.Inthecaseofunnumberedlinks,theLinkDatafieldcontainstheMIBIIIfindexvalue,auniquevaluethatisassociatedwitheveryinterface.Itnormallyhasvaluesstartingfrom0,asin0.0.0.17.Table8-3listsallpossiblevaluesfortheLinkIDandLinkDatafields.•ToSandToSMetric—Thesefieldsrepresentsthetypeofserviceandarenormallysetto0.•Metric—ThisfieldcontainstheOSPFcostofaspecificlink.TheformulatocalculateOSPFcostis108/Linkbandwidth.Forexample,themetricofaFastEthernetinterfacewouldbe1.Metricisdetermineddirectlyfromtheinterfacebandwidth,whichisconfigurable.Thisformulaformetriccalculationcanbeoverriddenbytwomethods.Thefirstmethodusestheipospfcostcostcommandundertheinterface.Thesecondmethodusestheauto-costreference-bandwidthreference-bandwidthcommandunderrouterospfconfiguration.Thereferencebandwidthactuallychangesthe108valueinmetriccalculationformula.

RouterLSAExample

Example8-1showstheoutputofarouterLSAfromaCiscorouter.Example8-1RouterLSAOutput

RouterB#showipospfdatabaserouter141.108.1.21LSage:1362Options:(NoTOS-capability,DC)LSType:RouterLinksLinkStateID:141.108.1.21AdvertisingRouter:141.108.1.21LSSeqNumber:80000085Checksum:0xE914Length:60AreaBorderRouterNumberofLinks:3

Linkconnectedto:anotherRouter(point-to-point)(LinkID)NeighboringRouterID:141.108.1.3(LinkData)RouterInterfaceaddress:141.108.1.2NumberofTOSmetrics:0TOS0Metrics:64


Linkconnectedto:aStubNetwork(LinkID)Network/subnetnumber:141.108.1.2(LinkData)NetworkMask:255.255.255.255NumberofTOSmetrics:0TOS0Metrics:0

TheoutputinExample8-1showsthreelinks.Afewimportantthingstonoteinthisoutput(ashighlighted)areasfollows:•Innormalsituations,theLSAgefieldshouldbelessthan1800.•InthecaseofarouterLSA,theLink-StateIDfieldandadvertisingroutershouldhavethesamevalueastheydoinExample8-1.•ThisrouterisanABRandhasthreerouterlinks.

Witheverypoint-to-pointlink,thereisastublinktoprovidethesubnetmaskofthelink.Inthisexample,twopoint-to-pointlinksandonestublinkareassociatedwiththesetwopoint-to-pointlinksbecausethenetworktypeispoint-to-multipoint.So,ifthereare300point-to-pointlinks,therouterwillgenerate300point-to-pointlinksaswellas300stublinkstoaddressthesubnetassociatedwitheachpoint-to-pointlink.Thepoint-to-multipointnetworktypeisabetterchoiceinthiscase,fortworeasons:•Onlyonesubnetisrequiredperpoint-to-multipointnetwork.•ThesizeoftherouterLSAiscutinhalfbecausetherewillbeonlyonestublinktoaddressthesubnetonapoint-to-multipointnetwork.Thislinkisusuallyahostaddress.

Ifyoudrewanetworktopologyoutofthisinformation,youwouldactuallyseeasmallpartofOSPFnetwork,asshowninFigure8-9.

Figure8-9NetworkTopologyDrawnfromtheInformationContainedintheRouterLSA

NetworkLSATheDRgeneratesthenetworkLSA.IfnoDRexist(forexample,inpoint-to-pointorpoint-to-multipointnetworks),therewillbenonetworkLSA.ThenetworkLSAdescribesalltheroutersattachedtothenetwork.ThisLSAisfloodedintheareathatcontainsthenetwork,justliketherouterLSA.Figure8-10showsthepacketformatforthenetworkLSA.

Figure8-10NetworkLSAPacketFormat

ThenetworkLSAhastwoimportantcomponents:•NetworkMask—Thisfieldindicatesthenetworkmaskassociatedwiththetransitlink.•AttachedRouter—ThisfieldincludestherouterIDofeachrouterassociatedwiththistransitlink.Thedesignatedrouteralsolistsitselfinattachedrouters.

NetworkLSAExample

Example8-2showstheoutputofanetworkLSAfromaCiscorouter.Example8-2NetworkLSAOutput

RouterA#showipospfdatabasenetwork141.108.1.1RoutingBitSetonthisLSALSage:1169

Options:(NoTOS-capability,DC)LSType:NetworkLinksLinkStateID:141.108.1.1(addressofDesignatedRouter)AdvertisingRouter:141.108.3.1LSSeqNumber:80000002Checksum:0xC76ELength:36NetworkMask:/29AttachedRouter:141.108.3.1AttachedRouter:141.108.1.21AttachedRouter:141.108.1.3

ThelastthreelinesofoutputinExample8-2showthatthreeroutersareattachedtothistransitlink.Also,thenetworkmaskonthistransitlinkis/29.Therearetwoimportantthingstorememberhere:•TheLink-StateIDfieldalwayscontainstheIPaddressoftheDR.•TheadvertisingrouterfieldalwayscontainstherouterIDoftheDR.

YoucansimilarlydrawanetworktopologyfromtheinformationcontainedinthenetworkLSAshowingthenumberofattachedroutersandthenetworkmaskonthelink.Figure8-11showsthenetworktopologydrawnfromtheinformationinthenetworkLSA.

Figure8-11NetworkTopologyDrawnfromtheInformationContainedintheRouterLSA

SummaryLSAThesummaryLSAdescribesthedestinationoutsidethearea,butstillwithintheAS.SummaryLSAsaregeneratedwhenthereismorethanoneareaprovidedandArea0isconfigured.ThepurposeofthesummaryLSAistosendthereducedtopologicalinformationoutsidethearea.Withoutanareahierarchy,itwillbedifficulttoscalethehugetopologicalinformationinasinglearea.ThisLSAdoesnotcarryanytopologicalinformation;itcarriesonlyanIPprefix.ThisLSAisoriginatedbytheABR,asfollows:•Fromanonbackbonetoabackbonearea,summaryLSAsaregeneratedfor:

—Connectedroutes—Intra-arearoutes

NoteOnlyintra-arearoutesareadvertisedintothebackbonetoavoidloops.Ifthereareanyinterarearoutescomingfromnonbackboneareaitmeansthatthebackboneisdiscontiguous.AdiscontiguousbackboneisnotallowedinOSPFnetworks.

•Fromabackbonetoanonbackbonearea,summaryLSAsaregeneratedforthefollowing:—Connectedroutes—Intra-arearoutes—Interarearoutes

TwotypesofsummaryLSAsexist:•Type3—Usedfortheinformationaboutthenetwork•Type4—UsedfortheinformationabouttheASBR

Figure8-12showsthepacketformatforthesummaryLSA.

Figure8-12SummaryLSAPacketFormat

ThelistthatfollowsdescribesthefieldswithinthesummaryLSApacket:•NetworkMask—FortheType3summaryLSA,thisfieldcontainsthenetworkmaskassociatedwiththenetwork.FortheType4summaryLSA,thisfieldmustbe0.•Metric—Thisfieldrepresentsthecostofthenetwork.•ToSandToSMetric—Thesefieldsarenormallysetto0.

BoththeType3andType4summaryLSAsusethesamepacketformat.TheimportantthingstorememberaboutsummaryLSATypes3and4areasfollows:•ThenetworkmaskinType3containsthesubnetmaskvalueofthenetwork.•Thenetworkmaskfieldmustbe0.0.0.0inType4LSAs.•InType3LSAs,theLink-StateIDfieldshouldhavethenetworknumber.•InType4LSAs,theLink-StateIDfieldshouldhavetherouterIDoftheASBR.•TheadvertisingrouterfieldmustcontaintherouterIDoftheABRgeneratingthesummaryLSA.ThisistrueforbothType3and4LSAs.

ThereisonespecialcaseofsummaryLSAs—incaseswhenastub-areaABRgeneratesasummarydefaultroute.Inthiscase,theLink-StateIDfieldaswellasthenetworkmaskmustbe0.0.0.0.

SummaryLSAExample

Example8-3showstheoutputofasummaryLSAfromaCiscorouter.Example8-3SummaryNetworkLSAOutput

RouterB#showipospfdatabasesummary9.9.9.0LSage:1261Options:(NoTOS-capability,DC)LSType:SummaryLinks(Network)LinkStateID:9.9.9.0(summaryNetworkNumber)AdvertisingRouter:141.108.1.21LSSeqNumber:80000001Checksum:0xC542Length:28NetworkMask:/24TOS:0Metric:10

TheLink-StateIDfieldhereisthenetwork9.9.9.0,andthenetworkmaskis/24.TheLink-StateIDfieldinsummaryLSAsType3willalwayscontainthenetworknumberthatthesummaryLSAisgeneratedfor,alongwiththenetworkmask.ThesummaryLSAhereisgeneratedfor9.9.9.0/24,asshowninFigure8-13.

Figure8-13NetworkDiagramWhereABRRouterGeneratestheSummaryLSA

Example8-4showssummaryASBRLSAoutput.Example8-4SummaryASBRLSAOutput

RouterB#showipospfdatabaseasbr-summary141.108.1.21LSage:1183Options:(NoTOS-capability,NoDC)LSType:SummaryLinks(ASBoundaryRouter)LinkStateID:141.108.1.21(ASBoundaryRouteraddress)AdvertisingRouter:141.108.1.1LSSeqNumber:80000001Checksum:0x57E4Length:28

NetworkMask:/0TOS:0Metric:14

TheoutputfromExample8-4showsthatthisissummaryLSAType4.Thenetworkmaskis0,andtheLink-StateIDistherouterIDoftheASBR.IncaseofType4,theLink-StateIDisalwaystherouterIDoftheASBR.TheNetworkMaskfieldmustalwaysbe0becausethisistheinformationaboutarouter(ASBR),notanetwork.Figure8-14showsthenetworkdiagrambasedontheoutputshowninExample8-4.

Figure8-14NetworkDiagramWhereABRsGeneratestheType4SummaryLSA

Example8-5showsthedefaultsummaryASBRLSAoutput.Example8-5DefaultSummaryLSAOutput

RouterB#showipospfdatabasesummary0.0.0.0LSage:6Options:(NoTOS-capability,DC)LSType:SummaryLinks(Network)LinkStateID:0.0.0.0(summaryNetworkNumber)AdvertisingRouter:141.108.1.21LSSeqNumber:80000001Checksum:0xCE5FLength:28NetworkMask:/0TOS:0Metric:1

TheoutputinExample8-5showsthattheLink-StateIDandnetworkmaskare0.0.0.0.Becausethisistheinformationaboutadefaultroute,itmusthave0.0.0.0intheLink-StateID,andthenetworkmaskmustbe0.0.0.0.Thesetwopiecesofinformationthenrepresentthedefaultrouteas0.0.0.0/0.Thissummarydefaultwillbepresentinastubbyareasituation,asshowninFigure8-15.

Figure8-15NetworkDiagramWhereABRGeneratesaSummaryDefaultLSA

ExternalLSATheexternalLSAdefinesroutestodestinationsexternaltotheautonomoussystem.Domain-wide,thedefaultroutecanalsobeinjectedasanexternalroute.ExternalLSAsarefloodedthroughouttheOSPFdomain,excepttostubbyareas.ToinstallanexternalLSAintheroutingtable,twoessentialthingsmusttakeplace:•ThecalculatingroutermustseetheASBRthroughtheintra-areaorinterarearoute.ThismeansthatitshouldhaveeitherarouterLSAfortheASBRoraType4LSAfortheASBR,incaseofmultipleareas.•Theforwardingaddressmustbeknownthroughanintra-orinterarearoute.

Figure8-16showsthepacketformatfortheexternalLSA.

Figure8-16ExternalLSAPacketFormat

ThelistthatfollowsdescribesthefieldswithintheexternalLSApacket:•NetworkMask—Specifiesthenetworkmaskoftheexternalnetwork.•BitE—Specifiestheexternaltype.Ifset,itisanexternalType2;otherwise,itisType1.ThedifferencebetweentypeandtypeexternalisthattheType1metricissimilartotheOSPFmetricandthecostgetschangedeveryhop;inType2,however,theexternalmetricdoesn’tchange.ThemetricremainsthesamethroughouttheOSPFdomain.•ForwardingAddress—Indicatestheaddresstowhichdatatraffictotheadvertisednetworkshouldbeforwarded.Ifthevalueissetto0.0.0.0,thismeansthatthetrafficshouldbeforwardedtotheASBR.Insomesituations,theforwardingaddresswillbenonzero,toavoidsuboptimalrouting.Thefollowinglistdescribeseventsthatwillproduceanonzeroforwardingaddress:—OSPFisenabledontheASBR’snext-hopinterface.—TheASBR’snext-hopinterfaceisnonpassivetoOSPF.—TheASBR’snext-hopinterfacenetworktypeisnotpoint-to-pointorpoint-to-multipoint.—TheASBR’snext-hopinterfaceaddressfallsintotheOSPFnetworkrange.

•ExternalRouteTag—NotusedbyOSPF.TheToSandToSMetricfieldsnormallyarenotusedbyanyvendor.ExternalLSAExample

Example8-6showstheoutputoftheexternalLSAfromtheCiscorouter.Example8-6ExternalLSAOutput

RouterE#showipospfdatabaseexternal10.10.10.0LSage:954Options:(NoTOS-capability,DC)LSType:ASExternalLink

LinkStateID:10.10.10.0(ExternalNetworkNumber)AdvertisingRouter:141.108.1.21LSSeqNumber:80000003Checksum:0x97D8Length:36NetworkMask:/24MetricType:2(Largerthananylinkstatepath)TOS:0Metric:20ForwardAddress:0.0.0.0ExternalRouteTag:0

TheoutputinExample8-6showsanexternalLSAfornetwork10.10.10.0/24.ThisisaType2externalLSA.Thereareafewimportantthingstorememberhere:•TheLink-StateIDfieldrepresentstheexternalnetworknumber.•TheadvertisingrouterfieldcontainstherouterIDoftheASBR.•MetricType:2meansthatthemetric—20,inthiscase—remainsthesamethroughouttheOSPFdomain.•Aforwardingaddressof0.0.0.0meansthatthetrafficshouldbeforwardeddirectlytotheASBR.•Theroutetothenonzeroforwardingaddressmustbeknownthroughanintra-areaorinterarearoute;otherwise,theexternalroutewillnotgetinstalledintheroutingtable.

Figure8-17showsanetworkinwhichaType5LSAisoriginatedbyRouterE(ASBR).RIPisgettingredistributedintoRouterE,soRouterEoriginatesaType5LSAforeveryRIPsubnet.ThoseType5LSAsarepropagatedthroughouttheOSPFdomain.

Figure8-17NetworkDiagramWhereASBROriginatesType5LSAsforaRIPLearnedRoute

OSPFAreasOSPFprovidestwolevelsofhierarchythroughoutanarea.Anareaisa32-bitnumberthatcanbedefinedeitherinanIPaddressformatof“Area0.0.0.0”orasadecimalnumberformat,suchas“Area0.”Area0isabackbonearea,whichisrequiredifmorethanoneareaisconfigured.AllareasmustbeconnectedtoArea0;otherwise,virtuallinksareneeded,asshowninFigure8-18.

Figure8-18UsingaVirtualLinkWhereanAreaIsNotAttachedtotheBackbone

Example8-7showstheconfigurationrequiredforavirtuallinkbetweenRouterEandRouterB.Area2isthetransitareabetweenRoutersEandB.RouterEwillformavirtuallinkwithRouterB’srouterID,andviceversa.ItisrecommendedthatyouusealoopbackIPaddressasarouterIDbecauseloopbacklinksalwaysstayup;therefore,thevirtuallinkwillstayup.Example8-7ConfiguringtheVirtualLinkBetweenRoutersEandB

RouterE#routerospf1area2virtual-link141.108.1.1

RouterB#routerospfarea2virtual-link141.108.1.21area2virtual-link141.108.1.21

Avirtuallinkitselfisnotabadthing.ThebaddesignwouldincludeanareathatisnotconnectedtoArea0,asshowninFigure8-18,andthenpatchingitupwithavirtuallink.Virtuallinkscanbeveryusefulinseveralscenarios.Figure8-19showsanexampleinwhichavirtuallinkcanbeusedasabackupandforredundancy—incasethelinkbetweenroutersAandBgoesdown,theArea3connectivitywillnotbebroken.Also,ifthelinkbetweenRoutersCandDgoesdown,thebackboneremainscontiguousthroughthevirtuallink.

Figure8-19UsingaVirtualLinkasaBackup

Example8-8showstheconfigurationofRoutersA,B,C,andD.RoutersAandDformavirtuallinkbetweeneachotherwithtransitArea2,andRouterCandDformavirtuallinkwithtransitArea1betweenthem.ThevirtuallinkbetweenRoutersAandBistobackupArea3connectivity;thevirtuallinkbetweenroutersCandDistobackupArea0ifthelinkbetweenRoutersEandFfails.Example8-8ConfiguringtheVirtualLinkBetweenRoutersA,B,C,andD

RouterA#routerospf1area2virtual-link141.108.1.2

RouterB#routerospf1area2virtual-link141.108.1.1

RouterC#routerospf1area1virtual-link141.108.1.4

RouterD#routerospf1area1virtual-link141.108.1.3

Figure8-20showsanotherexampleinwhichavirtuallinkcanbeusefulforoptimalrouting.IfthelinkbetweenRoutersBandCisputinArea1,Area0willsufferfromsuboptimalrouting.IfthatlinkisputintoArea0,area1willsufferfromsuboptimalrouting.So,thesolutionistoputthatlinkinArea1andthenconfigureavirtuallinkbetweenRoutersBandC.Thisway,itwillcarryboththebackboneandArea1traffic.

Figure8-20UsingaVirtualLinkforPathOptimization

Example8-9showstheconfigurationthatisrequiredtoformavirtuallinkbetweenRoutersBandC.Thisvirtuallinkisneededforpathoptimization.Example8-9ConfiguringRoutersBandCtoFormaVirtualLinkforPathOptimization

RouterB#routerospf1area1virtual-link141.108.1.3

RouterC#routerospf1area1virtual-link141.108.1.2

OSPFhasseveraltypesofareas,whichcanbedefinedaccordingtotheneedsofanetwork:•Normalarea•Stubarea•Totallystubbyarea•Not-so-stubbyarea(NSSA)•Totallynot-so-stubbyarea

ThesectionsthatfollowcoverthedifferentOSPFareasingreaterdetail.

NormalAreasWhentheareaisdefinedbydefault,itisconsideredanormalorregulararea.Normalareashavethefollowingcharacteristics:•SummaryLSAsfromotherareasareinjected.•ExternalLSAsareinjected.•ExternaldefaultLSAscanbeinjected.

InFigure8-21,Area1andArea2arenormalareas.IGRProutesareredistributedintoArea1,andRIProutesareredistributedintoArea2.

Figure8-21OSPFNormalAreaExample

StubAreasInstubareas,noexternalLSAsareallowed.RecalltheOptionsfieldinOSPFHellopacket.OneofthebitsinthatoptionfieldistheEbit.Incasesofstubareas,theEbitisclear,indicatingthattheareaisincapableofimportinganyexternalLSAs.Stubareashavethefollowingcharacteristics:•SummaryLSAsfromotherareasareinjected.•Thedefaultrouteisinjectedasasummaryroute.•ExternalLSAsarenotinjected.

InFigure8-22,Area1isdefinedasastubarea.NoredistributioncantakeplaceatRoutersI,H,orGbecausenoType5LSAsareallowedbystubareas.Also,RIProutesthatareinjectedatRouterEasOSPFexternalsareblockedatRouterF;however,Area1stillreceivesthesummaryroutecreatedforArea2byRouterF(ABR).AdefaultsummaryLSAalsowillbeinjectedbytheABR(RouterF)intoArea1.ThismeansthatifRoutersI,H,orGneedtosendapackettoexternaldestination,theywillalwaysforwardthepackettothenearestABR,whichisRouterFinthiscase.

Figure8-22StubAreaExample

Example8-10showstheconfigurationrequiredtomakeArea1astubarea.ThisstubconfigurationmustbedoneonalltheroutersinArea1.Example8-10ConfiguringArea1asaStubArea

RouterF#routerospf1area1stub

TotallyStubbyAreasTotallystubbyareasarethemostrestrictedformofarea.RoutersinthistypeofarearelyononlytheinjectionofadefaultsummaryroutefromtheABR.Nootherexternalorsummaryinformationisincludedintheroutingtable.Thisisanextensiontothestubarea,soallthecharacteristicsarestilltrueforthisarea.Thisareahasthefollowingcharacteristics:•NosummaryLSAsareallowed.•NoexternalLSAsareallowed.•Thedefaultrouteisinjectedasasummaryroute.

InFigure8-13,Area1willnotreceiveanysummaryrouteoranyexternalroutes.TheonlyroutesthatArea1willhavearetheintra-area(markedwithOintheroutingtable)routesforArea1andthedefaultrouteinjectedbytheABR,whichismarkedwithOIA.Example8-11showstheconfigurationrequiredontheABRtomakeArea1atotallystubbyarea.NotethatthedifferencebetweenthestubbyareaandthetotallystubbyareaisthatnosummaryLSAisgeneratedintoatotallystubbyarea.BecausesummaryLSAgenerationtakesplaceonlyattheABR,theconfigurationchangeneedstohappenonlyattheABR.Allotherroutersthatareconfiguredwithastuboptiondonotrequireanychangeintheconfiguration.Thekeywordno-summaryheremeanstoavoid

sendinganysummaryLSAsinArea1.Example8-11ConfiguringtheABR(RouterF)toMakeArea1TotallyStubby

RouterF#routerospf1area1stubno-summary

Not-So-StubbyAreasThisisalsoanextensionofthestubarea.SupposeinFigure8-12thatArea1isdefinedasastubareaandthereisarequirementofredistributionofanIGRProuteintothatarea.IfArea1weredefinedasstub,thiswouldnotbepossible.ToredistributeanIGRProuteintoArea1,Area1mustbechangedintoanNSSA.WhenArea1ischangedintoanNSSA,itwillallowredistributionandthenIGRProutescanberedistributedintotheNSSAareaasType7LSAs.NSSAswerecreatedtoinjectexternalroutesfromstubareasintotheOSPFdomain.IntheNSSA,whentheASBRinjectsarouteintotheAS,itgeneratesaType7LSA.TheABRtranslatesthisLSAtoaType5LSA,whichispropagatedtotherestoftheautonomoussystem.TheType7LSAfloodingscopeiswithintheNSSAarea.NSSAissupportedstartinginCiscoIOSSoftwareRelease11.2.NSSAshavethefollowingcharacteristics:•Type7LSAscarryexternalinformationwithinanNSSA.•Type7LSAsareconvertedintoType5LSAsattheNSSAABR.•NoexternalLSAareallowed.•SummaryLSAsareinjected.

Becausethisisanextensionofastubarea,RIProutesarenotinjectedintoArea1asOSPFexternalroutes;IGRProutes,however,getconvertedintoType7LSAs.Example8-12showstheconfigurationexampleforanNSSAarea.ThekeywordnssamustbetypedonalltheroutersthatarepartofArea1,asshownFigure8-21.Example8-12ConfiguringanNSSAonAlltheRoutersintheNSSAArea

RouterF#routerospf1area1nssa

Type7LSAs

ThepacketformatforType7LSAisverysimilartothatofType5.Thethreemaindifferencesareasfollows:•TheTypefieldcontainsthevalueof7insteadof5,indicatingitsType7LSA.•Theforwardingaddressiscalculatedasfollows:Iftheroutehasanext-hopaddress(nottrueforconnectedroutes),trytouseit.ThisispossibleonlyiftherouteisanOSPFinternalroute.EverythingthatwasexplainedintheType5forwardingaddressselectionalsoholdstrueforType7LSAs.IfanyoftheconditionsexplainedintheType5forwardingaddressselectioncriteriaisnottrue,thenexthopwillnotbeusedasaforwardingaddress.Thefollowingtworulesapplyinthatcase:—Useoneoftheloopbackaddresses(ifit’supandOSPFisrunning)intheareathatisannouncing

LSAs.—Ifnoloopbackaddressesareconfigured,usetheaddressofthefirstinterfaceinthatarea.

•ThePbitisexplainedinthefollowingexample.NSSALSAExample

Example8-13showstheoutputoftheNSSALSAfromFigure8-23.RouterIistheNSSAASBRdoingredistributionofIGRPintoOSPF.

Figure8-23NetworkDiagramWhereType7LSAsAreOriginated

Type7LSAsaregeneratedintoArea1andthenaretranslatedintoType5LSAsbytheNSSAABR,whichisRouterF.

Example8-13NSSALSAOutput

RouterI#showipospfdatabasenssa-external10.10.10.0LSage:36Options:(NoTOS-capability,Type7/5translation,DC)LSType:ASExternalLinkLinkStateID:10.10.10.0(ExternalNetworkNumber)AdvertisingRouter:141.108.1.21LSSeqNumber:80000001Checksum:0x4309Length:36NetworkMask:/24MetricType:2(Largerthananylinkstatepath)TOS:0Metric:20ForwardAddress:141.108.1.21ExternalRouteTag:0

TheoutputoftheNSSALSAresemblesthatoftheexternalLSAoutput,exceptthatthereareafewimportantthingstorememberregardingthePbitinthisoutput:•ThePbitisusedtotelltheNSSAABRwhethertotranslateType7LSAsintoType5LSAs.ThisbitwasalreadymentionedintheOptionfieldthatwasdiscussedinthe“HelloPackets”sectionearlier.•NoType7/5translationmeansbitP=0.•Type7/5translationmeansbitP=1.•IfbitP=0,theNSSAABRmustnottranslatethisLSAintoaType5LSA.ThishappenswhentheNSSAASBRisalsoanNSSAABR.•IfbitP=1,theNSSAABR(ifmultipleNSSAABRsexist,theonewiththelowestrouterID)musttranslatethisType7LSAintoaType5LSA.

Pstandsforpropagation.Basically,thisbitisusedforpropagationcontrol.TheABRmakesthedecisionbasedonthevalueofthisbit.NSSAConfigurationExample

Example8-14showsaconfigurationexamplefordefininganNSSAarea.ThisconfigurationmustbepresentonallroutersthatareinArea1,asshowninFigure8-23.Example8-14ConfiguringanNSSA

RouterF#routerospf1area1nssa

AfterdefiningArea1asanNSSAinFigure8-23,itwillhavethefollowingcharacteristics:•NoType5LSAsareallowedinArea1.ThismeansthatnoRIProutesareallowedinArea1.•AllIGRProutesareredistributedasType7routes.ThisType7routecanexistonlywithinNSSA.•AllType7LSAsaretranslatedintoType5LSAsbytheNSSAABRandareleakedintotheOSPFdomainasType5LSAs.

TotallyNot-So-StubbyAreas

ThistypeofareaisanextensiontotheNSSA.Ifonlyoneexitpointexists,thisisthemostrecommendedformofNSSAareatype.InFigure8-23,ifArea1isdefinedasatotallyNSSA,thefollowingistrue:

•NoRIProuteswillbeinjectedintoArea1becausethoseareexternalroutes.•NosummaryLSAfromotherareaswillbeinjectedintoArea1becauseofthedefinitionofatotallyNSSA.•ThedefaultsummaryLSAwillbegeneratedbytheABR,RouterF.

TotallyNSSAshavethefollowingcharacteristics:•NosummaryLSAsareallowed.•NoexternalLSAsareallowed.•Thedefaultrouteisinjectedasasummaryroute.•Type7LSAsareconvertedintoType5LSAsattheNSSAABR.

Example8-15showstheconfigurationrequiredontheNSSAABR.Asincaseoftotallystubbyareas,theno-summarycommandisneededonlyontheABRbecausethesummaryLSAgenerationisdoneontheABR.Example8-15ConfigurationontheNSSAABR,RouterF,forTotallyNSSAArea

RouterF#routerospf1area1nssano-summary

FilteringinNSSA

Insomesituations,thereisnoneedtoinjectexternalroutesintotheNSSAasType7routes.ThissituationusuallyoccurswhenanASBRisalsoanNSSAABR.Whenredistributiontakesplaceinthisscenario,theroutergeneratesType5LSAsaswellasType7LSAs.InFigure8-24,Area1isconfiguredusingtheno-redistributionoption.

Figure8-24ScenariosWhereNSSAFilteringCanBeUsed

ThismeansthatallIGRProutesareredistributedintoArea0,butnoType7LSAswillbegeneratedforArea1.Example8-16showstheconfigurationthatpreventsNSSAABRRouterAfromgeneratingType7LSAsforIGRProutes.

Example8-16ConfigurationtoFilterType7inNSSA

RouterA#routerospf1area1nssano-redistribution

Configuretheno-redistributioncommandonanNSSAABRthat’salsoanASBR.AnothercaseoffilteringoccurswhenyouneedtopreventtheType7LSAsfrombeingtranslatedoutsidetheNSSA.Inotherwords,youwanttocontrolwhichType7LSAsgettranslatedintoType5LSAs.Forexample,Figure8-24showsaRIP-learnedroute141.108.10.0/24that’sbeinginjectedintotheOSPFNSSAArea1.Youdon’twantthisroutetobeleakedintotherestoftheOSPFareas.Example8-17showstheconfigurationthatwillpreventRIProutesfrombeingtranslatedintoType5LSAs.ThisconfigurationcanbeusedoneitherRouterAorRouterB.Example8-17ConfigurationtoControlType7toType5Conversion

RouterA#routerospf1summary-address141.108.10.0255.255.255.0not-advertise

Thissummary-addressconfigurationgeneratesaType7LSAthatwon’tbetranslatedintoaType5LSAbytheNSSAABR.DefaultRoutesinNSSA

TherearetwowaystohaveadefaultrouteinanNSSA:•WhenyouconfigureanareaasanNSSA,theNSSAABRdoesn’tgenerateadefaultsummaryroute,bydefault.•InthecaseofastubareaoranNSSA,totallystubbyarea,theNSSAABRgeneratesadefaultsummaryroute.

DefaultSummaryRoute

BydefininganareaasanNSSA,totallystubbyarea,theNSSAABRgeneratesadefaultsummaryroute.Asmentionedearlier,iftheNSSAareawerenotdefinedasatotallystubbyarea,adefaultsummaryroutewouldnotbegeneratedbytheNSSAABR.Example8-18showshowtosendadefaultsummaryrouteinanNSSAbyconfiguringanNSSA,totallystubbyarea.Thisisdonebyapplyingtheno-summaryoptionontheNSSAABR.Example8-18ConfigurationtoGeneratetheDefaultSummaryRouteintoanNSSAArea

RouterA#routerospf1area1nssano-summary

DefaultType7

Example8-19showstheconfigurationthatgeneratesaType7defaultroute.YoucanconfigurethiscommandonanyNSSAASBRorNSSAABR,withthefollowingrules:•NSSAASBRcangenerateadefaultonlywhenithasadefaultrouteinitsroutingtable.•NSSAABRcangenerateadefaultroutewithorwithoutadefaultrouteinitsownroutingtable.

Example8-19ConfigurationforOriginatingType7DefaultintoanNSSAArea

RouterA#routerospf1area1nssadefault-information-originate

OSPFMediaTypesOSPFrunsonseveralmediatypes.Onsomemedia,suchasmultiaccessandpoint-to-pointmedia,theOSPFdefaultnetworktypeisused.Therefore,thereisnoneedtoconfigureanynetworktypeonthosemedia.ThissectiongoesintodetailoneachmediumtypeinOSPFandwhatnetworktypetouseforeachmedium.ForOSPF,mediacanbedividedintofourcategories:•Multiaccessmedia•Point-to-pointmedia•Nonbroadcastmultiaccessmedia•Demandcircuits

MultiaccessMediaMultiaccessmediaincludesEthernet,FastEthernet,GigabitEthernet,FDDI,TokenRing,andsimilarmultiaccessmedia.OSPFrunsasabroadcastnetworktypeoverthesemedia.TheOSPFnetworktypeofbroadcastisonbydefaultoverthesemedia.Inthisnetworktype,theDRandtheBDRareelectedtoreducethefloodingonthesegment.ThemulticastcapabilitiesofOSPFareusedtoformadjacenciesandtoefficientlydistributetheinformationtootherroutersonthesegment.Inbroadcastnetworktypes,theinterfacesubnetmaskischeckedintheHellopacket.Ifthemasksofthetworoutersaredifferent,anadjacencywillnotbeformed.Becausethisnetworktypeisonbydefault,nospecificconfigurationisrequiredforthismedia.Figure8-25showsanexampleofOSPFrunovermultiaccessmedia.RouterAiselectedasaDRbecauseithasthehighestpriority.RouterBiselectedastheBDR.TheprioritiesofbothRoutersBandCareequal;therefore,theBDRelectionisbasedonthehighestrouterID.AlltherouterswillformanadjacencywiththeDRandtheBDR.TheDRandtheBDRwilllistenspecificallytothemulticastaddressof224.0.0.6(allDRrouters),whileallotherrouterswilllistentothemulticastaddressof224.0.0.5(allSPFrouters).

Figure8-25MultiaccessMediaExample

Point-to-PointMedia

Point-to-pointmediaincludesHDLCandPPPencapsulationlinks,FrameRelay/ATMpoint-to-pointsubinterfaces,andsimilarpoint-to-pointinterfaces.TheOSPFnetworktypeofpoint-to-pointisonbydefaultonthesemedia.NoDRorBDRelectiontakesplaceonthismediumtype.AlltheOSPFpacketsaremulticast-based.ThereasonforsendingallOSPFpacketsasmulticastisthat,insomecasesofunnumberedlinks,thedestinationaddressisnotknown.Figure8-26showsanexampleofpoint-to-pointmedia.RouterAisattachedtothreeotherroutersthroughpoint-to-pointlinks.RouterAwillformafulladjacencywithRoutersB,C,andD.

Figure8-26Point-to-PointMediaExample

NonbroadcastMultiaccessMediaManymediafallunderthiscategoryofnonbroadcastmultiaccess(NBMA),includingFrameRelay,X.25,SMDS,andATM.Additionalconfigurationisrequiredforthistypeofmedium.TheOSPFnetworktypeonthesemediaisnonbroadcast,bydefault.Severalnetworktypeoptionscanbedefinedinthisscenario.ThismediumcanberuninseveralmodesunderOSPF:•Broadcastmodel•Point-to-pointmodel•Point-to-multipointmodel

BroadcastModel

Inthebroadcastmodel,thebroadcastnetworkissimulated.DRsandBDRsareelected.Thebroadcastmodelcanbesimulatedintwoways:•Configurethenetwork-typebroadcast.•Configuretheneighborstatement.

Figure8-27showstheNBMAnetworkmodel.ThemediumisFrameRelaybetweenrouters.RouterAhasconnectivitytoallotherrouters;however,RoutersB,C,D,andEareconnectedonlytoRouterA,nottoeachother,throughFrameRelayPVCs.Theonlytimethebroadcastmodelworkshereiswhenallroutersarefullymeshed.Inapartiallymeshedsituation,asshowninFigure8-27,runningabroadcastmodelisnotrecommended.

Figure8-27NBMAMediaExample

AssumingthatthereisfullymeshedFrameRelayconnectivity,Example8-20showstheconfigurationthatisrequiredonalltherouters.Thisconfigurationchangesthenetworktypeoftherouter’sFrameRelayinterfacetobroadcast.Oneimportantthingtonotehereisthat,incaseofastaticFrameRelaymapping,thekeywordbroadcastmustbeusedattheend;otherwise,theOSPFmulticastHellowillnotgoacrosstheFrameRelayconnection.Example8-20ConfiguretheNetworkTypeasBroadcast

RouterA#interfaceserial0encapsualtionframe-relayipospfnetwork-typebroadcast

Thecommandipospfnetwork-typebroadcastmustbeconfiguredonalltherouters’FrameRelayinterfaces.Anotherwaytosimulatethebroadcastmodelisthroughtheneighborstatement,asshowninExample8-21.Theneighborstatementmustbeconfiguredmanuallyinthehubrouter,whichisRouterAinthiscase.RouterAmustbeconfiguredwithahigherprioritysothatitcanalwaysbetheDR.Example8-21ConfiguringtheneighborStatementontheHubRouter

RouterA#interfaceserial0encapsulationframe-relayipaddress141.108.1.1255.255.255.0ipospfpriority10!routerospf1neighbor141.108.1.2

neighbor141.108.1.3neighbor141.108.1.4neighbor141.108.1.5

Point-to-PointModel

Ifthepoint-to-pointmodelisused,eachPVCmustbedefinedasaseparatepoint-to-pointsubinterface;therefore,aseparatesubnetforeachpoint-to-pointsubinterfaceisneeded.Example8-22showstheconfigurationrequiredatthehubRouterAtocreatepoint-to-pointsubinterfaces.Nonetworktypeisneededunderthesubinterfacebecause,bydefault,allsubinterfaceshaveapoint-to-pointnetworktype.ThephysicaltopologyremainsthesameasthatshowninFigure8-27.Theadvantageofthismodelisthatvirtualcircuit(VC)costcanbeconfiguredonaper-interfacebasis.Thedisadvantageisthatalotofaddressspaceiswastedoneverypoint-to-pointsubinterface.Inaddition,thesizeoftherouterLSAcreatedbyRouterAwillbefairlylargebecauseitmustincludeaType3stublinkforeverypoint-to-pointlink.Example8-22ConfiguringPoint-to-PointSubinterfaces

RouterA#InterfaceSerial0.1point-to-pointipaddress141.108.1.1255.255.255.252!InterfaceSerial0.2point-to-pointipaddress141.108.1.5255.255.255.252

Similarly,othersubinterfacescanbecreated.Point-to-MultipointModel

Inapoint-to-multipointmodel,eachrouterthathasconnectivitywithanotherrouterformsanadjacencywiththatrouter.NoDRorBDRiselectedinthisnetworktype.MuticastHellosaresenttodiscoverneighbors,soitisessentialthatLayer2mustsupportmulticast/broadcastcapability.Also,onlyonesubnetisrequiredforthewholeNBMAcloud,asshowninFigure8-27.Example8-23showstheconfigurationrequiredforthepoint-to-multipointnetworktype.RouterA’sSerial0isconfiguredforpoint-to-multipointnetworktype.ThisnetworktypemustbeconfiguredonalltheremoteRoutersB,C,D,andE.Example8-23ConfigurationforPoint-to-MultipointNetworkType

RouterA#interfaceserial0encapsulationframe-relayipaddress141.108.1.1255.255.255.0ipospfnetwork-typepoint-to-multipoint

Thisistherecommendednetworktypetouseinnon–fullymeshedNBMAnetworks.Sometimes,amediumisNBMAbutisnotcapableofsupportingmulticast,sopoint-to-multipointnetworktypecannotbeused.Forthiskindofmedium,anothernetworktypehasbeenintroduced,calledpoint-to-multipointnonbroadcast.AssuminginFigure8-27thattheNBMAnetworkdoesnotsupportmulticastcapabilities,thisnewtypecanbeused.Example8-24showstheconfigurationrequiredforthisnetworktype.ThisnetworktypeisconfiguredonlyonSerial0onRouterA,butitmustbeconfiguredonalltheremoterouter’sserialinterfaces.Theneighborstatementisrequiredforthisnetworktype,butaDRandBDRwillnotbeelected.

Example8-24ConfiguringPoint-to-MultipointNonbroadcastNetworkType

RouterA#interfaceserial0encapsulationframe-relayipaddress141.108.1.1255.255.255.0ipospfnetwork-typepoint-to-multipointnonbroadcast!routerospf1neighbor141.108.1.2neighbor141.108.1.3neighbor141.108.1.4neighbor141.108.1.5

DemandCircuitsThedemandcircuitoptionwasintroducedasofCiscoIOSSoftwareRelease11.2.Withdemandcircuits,anadjacencyisformedandallthedatabasesareexchangedatthebeginning.Thenafterthedeadtimerkicksin,theadjacencyremainsupevenaftertheLayer2goesdown.Thisisusefulwhenyouhavetopayunnecessarytollchargestokeepthelinkinuse.ISDNisaprimeexampleofasituationinwhichademandcircuitcanbeused.AslongastheISDNlinkisup,youmustpayforthelink.Themaincharacteristicsofademandcircuitthatmakeitdifferentfromanormalcircuitareasfollows:•PeriodicHellosaresuppressed.•PeriodicLSAsrefreshesaresuppressed.

PeriodicHellosaresuppressedonlyonpoint-to-pointandpoint-to-multipointnetworktypes.AllothernetworktypeHellosstillaresentovertheinterface.TheperiodicLSArefreshthattakesplaceevery30minuteswillnothappenwithademandcircuitbecausewhenthedemandcircuitlinkisestablished,auniqueoptionbit,theDCbitorDoNotAge(DNA)bit(discussedearlierinthe“HelloPackets”section),issentacross.IftworoutersnegotiatetheDCbitsuccessfully,theymakeanoteofitandsetaspecificbitintheLSAAgefieldthatisthemostsignificantbit.Bysettingthisbit,theLSAstopsagingoverthedemandcircuit,sonoperiodicupdatesaresent.IntwonormalscenariostheperiodicrefreshoftheLSAwillbesent:•Ifthereisachangeinnetworktopology•IfthereisarouterinOSPFdomainthatcannotunderstanddemandcircuits

Inthefirstcase,notmuchcanbedonebecausetheroutermustsendthenewLSAinformationtoupdatetheneighboraboutthetopologychange.Inthesecondcase,however,thereisaspecialwaytohandlethissituation.TheABR,whichistherouterbetweenAandCinFigure8-28,knowsthatRouterCisincapableofunderstandingDNALSAsbecauseitseestheoptionsintheLSAoriginatedbyRouterCandbecausetheDCbitisclearintheOptionfield.Whenthissituationoccurs,theABRindicatestothedemandcircuit–capableroutersnottooriginatetheLSAwiththeDNAbitsetbecausethereisarouterthatdoesnotunderstandtheDNAbit.TheABRoriginatesanindicationLSAinthebackbone,tellingeveryoneinthebackbonenottooriginateanyDNALSAs.ThisindicationLSAisshowninExample8-25.ThisisaType4summaryLSAinwhichthelink-stateIDistheABRitselfinsteadoftheASBR.Example8-25IndicationLSAExample

RouterA#showipospfdatabaseasbr-summaryAdvRouterisnot-reachable

LSage:971Options:(NoTOS-capability,NoDC)LSType:SummaryLinks(ASBoundaryRouter)LinkStateID:141.108.1.129(ASBoundaryRouteraddress)AdvertisingRouter:141.108.1.129LSSeqNumber:80000004Checksum:0xA287Length:28NetworkMask:/0TOS:0Metric:16777215

Figure8-28ScenarioinWhichthePeriodicLSARefreshWillBeSentAcrossaDemandCircuit

ThemetricofindicationLSAissettoinfinity,andthelink-stateIDisalwaystherouterIDoftheABRoriginatingtheindicationLSA.InFigure8-28,thelinkbetweenRoutersAandBisconfiguredasademandcircuit,butbecausethereisarouterinArea1thatisincapableofunderstandingtheDNALSA,noDNALSAwillbeoriginatedbyArea2.Asaresult,theperiodicrefreshoftheLSAswillbesentacrossthedemandcircuit.Asasolution,configureArea1asastuborNSSAarea.Thisisbecauseofsection2.5.1oftheDemand

CircuitRFC1793thatstates:“LSAsinregularOSPFareasareallowedtohaveDoNotAgesetifandonlyifeveryrouterintheOSPFdomain(exceptingthoseinstubareasandNSSAs)iscapableofDoNotAgeprocessing.”So,ifArea1isdefinedasstuborNSSA,LSAinArea2willbeallowedtohaveLSAwithDNAbitset.Anotherrecommendationistoalwaysincludeademandcircuitinanonbackbonearea.IfasituationarisessimilartotheoneshowninFigure8-28andthedemandcircuitisalsoapartofthebackbone,thereisnosolutionforthisbecausethebackboneareacannotbeconfiguredasastuborNSSAarea.Theadvantageofconfiguringdemand-circuitinastubareaisthatifthereareanyroutersinaremoteOSPFareathatcannotunderstandtheDNALSA,theindicationLSAthatwillbegeneratedbytheABRcanneverenterintothestubarea.Therefore,thedemand-circuitcapablerouterscanstillgeneratetheLSAwithDNAbitsetwithinthearea.Example8-26showstheconfigurationnecessarytomakeacircuitademandcircuit.Onlyonesideisrequiredtohavethedemandcircuitcommandundertheinterfacebecause,iftheothersideiscapableofunderstandingdemandcircuits,itautomaticallynegotiatesthiscapabilityintheHellopacket;otherwise,itsimplyignoresthisoption.Example8-26ConfiguringaDemandCircuit

RouterA#interfaceserial0encapsulationframe-relayipaddress141.108.1.1255.255.255.0ipospfnetwork-typepoint-to-multipointipospfdemand-circuit

Ademandcircuitcanberunonanynetworktype.Thedifferenceisthat,withoutapoint-to-pointorpoint-to-multipointnetworktype,theHelloswillnotbesuppressed;however,thesemediatypescanstillusethefloodingrobustnessofdemandcircuit,andtheLSAwillnotageoutoverthatdemandcircuitlinks.

OSPFMediaTypeSummaryTable8-4explainsthedefaultvalueforeachtypeofmediumandgivestherecommendednetworktype.

Table8-4DifferentRouterLinkTypes

Table8-5MediaTypewithPossibleOSPFNetworkTypes

OSPFAdjacenciesOSPFcreatesadjacenciesbetweenneighboringroutersforthepurposeofexchangingroutinginformation.Noteveryneighborbecomesadjacentinabroadcastenvironment.TheHelloprotocolisresponsibleforestablishingandmaintaininganadjacency.Hellopacketsaresentperiodicallyoutallrouterfunctionalinterfaces.Two-waycommunicationisestablishedwhentherouterislistedintheneighbor’sHellopacket.OnbroadcastandNBMAnetworks,HellopacketsareusedtoelecttheDR/BDR.Afterthetwo-waycommunicationisestablished,thedecisionismadewhethertoformanadjacencywiththisneighbor.Thisdecisionisbasedontheneighborstateandnetworktype.Ifthenetworktypeisbroadcastornonbroadcast,theadjacencyisformedonlywiththeDRandBDRrouters.Inallothernetworktypes,theadjacencyisformedbetweentwoneighborrouters.Thefirststepinformingtheadjacencyissynchronizationofthedatabase.Eachrouterdescribesitslink-statedatabaseintheDBDpacket.OnlytheLSAheadersareexchangedbetweenneighbors.Masterandslaveelectiontakesplaceduringthisdatabaseexchange.EachroutermakesanoteoftheLSAheadersthatitreceivesduringthisDBDexchange.AttheendoftheDBDexchange,itsendstheLSrequestpackettorequestLSAswhoseheadershavebeenseenduringtheDBDexchange.TheneighborrouterthenreplieswiththeLSupdatepacketlistingtheentirecontentofthoseLSAs.ThisLSupdatepacketisthenacknowledgedbysendingthelink-stateacknowledgmentpacket.Atthispoint,allthedatabasesarefullyexchanged,andtheneighborgoesintoFullstate.Aroutercanbeinseveralneighborstates:•Down•Attempt•Init•2-way•Exstart•Exchange•Loading•Full

ThesectionsthatfollowdescribethedifferentOSPFstatesinmoredetail.

OSPFDownStateInFigure8-29,R1andR2arerunningOSPF.TheneighborstateshowsDOWN.Thisstatemeansthatno

informationhasbeenreceivedfromtheneighboryet.

Figure8-29OSPFDownState

OSPFAttemptStateTheAttemptstateisvalidforneighborsonNBMAnetworks.Ifaneighborisinthisstate,itmeansthatnoinformationisreceivedfromthisneighbor,butseriouseffortisbeingmadetocontacttheneighbor.SeriouseffortmeansthatthisrouterwillconstantlysendaHellopacketuponeveryHellointervaltocontacttheneighbor.InFigure8-30,R1issendingaHellopacketthatsaysthatR1hasnotseenanyoneyetanddoesn’tknowabouttheDR.

Figure8-30OSPFAttemptState

OSPFInitStateInitstateisaone-wayHello.InFigure8-31,R1sendsaHellopacket.UponreceivingthisHello,R2declaresaone-waystatebecauseR2doesn’tseeitself(itsrouterID)inthatHellopacket.

Figure8-31OSPFInitState

OSPF2-WayStateAnOSPFneighborreachesthe2-waystatewhenbidirectionalcommunicationisestablished.ThisisthebeginningofanOSPFadjacency.TheDRandBDRareelectedinthisstate.InFigure8-32,R2sendsaHellopacketthatsaysthatR2hasseenR1’sHello;therouterIDofR2ishigher,soithasalsoelecteditselfasaDR.

Figure8-32OSPF2-WayState

OSPFExstartStateThisstateisusedforinitializationofthedatabasesynchronizationprocess.Masterandslaveareelectedinthisstate.ThefirstsequencenumberforDBDexchangeisalsodecidedinthisstate.InFigure8-33,R1sendsthefirstDBDpacket.R2alsosendsitfirstDBDpacket.TherouterthathasthehighestrouterIDbecomesthemaster.Inthisexample,R2hasahigherrouterID,soR2isthemaster.

Figure8-33OSPFExstartState

OSPFExchangeStateIntheExchangestate,therouterdescribesitsentirelink-statedatabasethroughDBDpackets.EachDBDsequenceisexplicitlyacknowledged.OnlyoneoutstandingDBDpacketisallowedatatime.Link-staterequestpacketsarealsosentinthisstatetorequestanewinstanceoftheLSA.Figure8-34showstheexchangeprocessinaction.R1andR2areexchangingtheirdatabaseinformation.ThelastarrowshowsthattheMbitissetto0.Thismeansthatthemasterhasnomoredatatosend.AtthisstageR1,theslavewillsendwhateverdatabaseisleft,andR1willalsosettheMbitto0.Thisistheindicationthatbothroutershaveexchangedthecompletedatabase.

Figure8-34OSPFExchangeState

OSPFLoadingStateIntheLoadingstate,LSrequestpacketsaresenttorequestthemorerecentinstanceofanLSAthathasnotbeenreceivedduringtheexchangeprocess.InFigure8-35,R1isintheLoadingstateandissendingLSrequestpacketstoreceiveamorerecentinstanceofanLSA.

Figure8-35OSPFLoadingState

OSPFFullState

ThisstatemeansthatthecompleteinformationhasbeenexchangedbetweenOSPFneighbors.InFigure8-36,R1andR2haveexchangedtheirentiredatabaseinformationandareintheFullstate.

Figure8-36OSPFFullState

SummaryOSPFisalink-stateprotocol.OSPFhasfivepackets—Hello,DBD,link-staterequest,link-stateupdate,andlink-stateacknowledgment.Thesepacketsareusedaccordingtothestateofadjacency.SeveraltypesofLSAsexist,themostcommonorwhicharerouter,network,summary,summaryASBR,external,andNSSALSAs.OSPFhasseveralareatypes,whicharenormal,stub,totallystub,NSSA,andtotallyNSSA.Theseareascanbeusedaccordingtothenetworkneed.Themostrestrictedformofareaisatotallystubbyarea,inwhichtheareareliesononlythesummarydefaultroutethatitreceivesfromtheABR.OSPFcanberununderseveralmediatypesoptions—multiaccess,point-to-point,NBMA,anddemandcircuit.Innon–fullymeshedNBMAenvironments,themostrecommendednetworktypeispoint-to-multipoint.Point-to-multipointnonbroadcastnetworksareusefulonlywhenthemediumdoesnotsupportthemulticastcapabilities.NoDRorBDRiselectedinthisnetworktype.OSPFadjacenciesgothroughseveralstagesbeforetheyareformed.ThelaststateofadjacencyisFull,whichmeansthatacompletedatabasehasbeenexchangedfromtheneighbor.Onbroadcastmedia,adjacenciesareformedonlywiththeDRandtheBDR.Allotherneighborgoesuptothe2-waystate.Thisistoreducethenumberofadjacenciessothattherewillbelessfloodingtrafficonthesegment.

ReviewQuestions1HowmanytypesofpacketarethereinOSPF?2WhichoftheLSAshasafieldcalledForwardingAddress?3WhichoftheLSA(s)arenotallowedinatotallystubbyarea?4WhatisthemulticastaddressforAllSPFRouters?5WhichoftheOSPFprotocolpacketsisusedtoelectamasterandaslave?6WhichoftheOSPFprotocolpacketsimplementfloodingoftheLSA?7WhatisthetimelimitinsecondsbeforeanLSAisdeclaredasMAXAGED?8HowmanybyteslongisacommonLSAheader?

Chapter9.TroubleshootingOSPF

ThischaptercoversthefollowingOSPFtroubleshootingtopics:•TroubleshootingOSPFneighborrelationships•TroubleshootingOSPFrouteadvertisement•TroubleshootingOSPFrouteinstallation•TroubleshootingredistributionproblemsinOSPF•TroubleshootingroutesummarizationinOSPF•TroubleshootingCPUHOGproblems•Troubleshootingdial-on-demandrouting(DDR)issuesinOSPF•TroubleshootingSPFcalculationandrouteflapping•CommonOSPFerrormessages

ThischapterdiscussescommonproblemsofOSPFandtellshowtotroubleshootthoseproblems.OSPFisacomplexprotocolwhencomparedtoRIPorIGRP.Sometimes,theproblemscanberelativelyeasytotroubleshootandrequirefewconfigurationchanges.Othertimes,theproblemscanbeverycomplexandrequiremoreassistance.Thischapterdiscussesseveraltypesofproblems.Theseexampleshavebeencollectedoverseveralyearsfromrealcustomernetworkenvironments.Someproblemsrequireturningondebugs.DebugsinOSPFnormallyarenotveryCPU-intensiveunlesstheproblemisimpactingtheentireOSPFnetwork.Forexample,ifOSPFneighborsarenotcomingup,turningondebugipospfadjisnotCPU-intensiveunless300neighborsarehavingproblemsatthesametime.TheflowchartsthatfollowdocumenthowtoaddresscommonproblemswithOSPFwiththemethodologyusedinthischapter.

FlowchartstoSolveCommonOSPFProblems

TroubleshootingOSPFNeighborRelationshipsThissectiondiscussestheproblemsrelatedtoestablishingOSPFneighborrelationships.OSPFneighborrelationshipproblemscanbeofanytype.Sometimes,theneighborlistisempty(thatis,anOSPFneighbormightnotevenseetheHellosfromeachother).Sometimes,theproblemisthattheneighborisstuckinaspecificstate.RecallfromChapter8,“UnderstandingOpenShortestPathFirst(OSPF),”thatthenormalstateofanOSPFneighborisFULL.IfthestateissomethingotherthanFULLforalongperiodoftime,thisindicatesaproblem.ThissectioncomesfirstbecausethisisthemostimportantstepinusingtheOSPFprotocol.IfnoneighborrelationshipsareestablishedortheneighborsarestuckinastateotherthanFULL,OSPFwillnotinstallanyroutesintheroutingtable.Therefore,itisveryimportantinOSPFtomakesurethattheneighborsareup.OSPFneighborrelationshipproblemscanbeofanyofthesetypes:•TheOSPFneighborlistisempty.•AnOSPFneighborisstuckinATTEMPT.•AnOSPFneighborisstuckinINIT.•AnOSPFneighborisstuckin2-WAY.•AnOSPFneighborisstuckinEXSTART/EXCHANGE.•AnOSPFneighborisstuckinLOADING.

Noneofthestatesmentionedinthislistisanindicationofaproblem,butifaneighborisstuckinoneofthesestatesforalongtime,thisisaproblemandmustbecorrected;otherwise,OSPFwillnotfunctionproperly.

Problem:OSPFNeighborListIsEmptyThisisthemostcommonprobleminOSPFneighborrelationships.Themostcommoncausesarerelatedtoeithermisconfigurationorlackofconfiguration.Iftheneighborlistisempty,itwillnotevenproceedto

formOSPFneighborrelationships.Themostcommonpossiblecausesofthisproblemareasfollows:•OSPFisnotenabledontheinterface.•Layer1/2isdown.•TheinterfaceisdefinedaspassiveunderOSPF.•AnaccesslistisblockingOSPFHellosonbothsides.•Asubnetnumber/maskhasbeenmismatchedoverabroadcastlink.•TheHello/deadintervalhasbeenmismatched.•Theauthenticationtype(plaintextversusMD5)hasbeenmismatched.•Anauthenticationkeyhasbeenmismatched.•AnareaIDhasbeenmismatched.•Stub/transit/NSSAareaoptionshavebeenmismatched.•AnOSPFadjacencyexistswithsecondaryIPaddressing.•AnOSPFadjacencyexistsoveranasynchronousinterface.•NonetworktypeorneighborisdefinedoverNBMA(FrameRelay,X.25,SMDS,andsoon).•Theframe-relaymap/dialermapstatementismissingthebroadcastkeywordonbothsides.

Figure9-1showstworoutersrunningOSPFbetweeneachother.Theoutputofshowipospfneighborshowsanemptylist.Inanormalscenario,theoutputdisplaystheOSPFneighborstatus.Thisfigureisusedformostofthecausesdescribedinthissection.

Figure9-1OSPFNetworkTopologyVulnerabletoEmptyOSPFNeighborListProblem

Example9-1showstheoutputofshowipospfneighbor,whichshowstheemptyneighborlist.Example9-1showipospfneighborCommandOutputHasanEmptyNeighborList

R2#showipospfneighborR2#

OSPFNeighborListIsEmpty—Cause:OSPFNotEnabledontheInterface

OSPFcanbeenabledonaper-interfacebasis.ToenableOSPFonanyinterface,putanetworkcommandunderrouterospfandincludethenetworkaddresswiththewildcardmask.WhendefiningthenetworkstatementinOSPF,youshouldcarefullyexaminethewildcardmasktoseetherangeofaddressesitcovers.Figure9-2showstheflowcharttofollowtosolvethisproblembasedonthiscause.


Example9-2showstheconfigurationofRouterR2.Theconfigurationshowsthatthewrongmaskisputunderthenetworkstatementthatincludesonlyloopback0intoarea0.ThenetworkstatementisdeterminedinOSPFinexactlythesamewaythatyoudefineanaccesslist.Themainideahereistoincludetherangeofaddressesinanarea.InExample9-2,thenetworkstatementof131.108.0.0withthewildcardmaskof0.0.0.255willnotcover131.108.1.2;itcoversonlytherangefrom131.108.0.0to131.108.0.255,asindicatedbythewildcardmask.Example9-2R2ConfigurationwiththeWrongMask

R2#interfaceLoopback0ipaddress131.108.0.1255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0!routerospf1network131.108.0.00.0.0.255area0!

Example9-3showstheconfigurationofRouterR2.OSPFisnotenabledontheEthernetinterfaceofR2.Example9-3OSPFNotEnabledonR2’sEthernet0Interface

R2#showipospfinterfaceEthernet0Ethernet0isup,lineprotocolisupOSPFnotenabledonthisinterface

Solution

Sometimes,theconfigurationshowsthecorrectmaskandtheOSPFneighborliststillshowsempty.Thisisaveryrarecase.DuringnetworkconfigurationchangesunderOSPF,acutandpasteoftheOSPFconfigurationmightcreatethisproblem.Therefore,youalwaysshouldlookattheoutputofshowipospfinterfaceforthatspecificinterfaceandseewhetherOSPFisenabledonthatinterface.Thistypeofproblemcanbecorrectedbyre-enteringthenetworkstatement.IfOSPFisnotenabledontheinterface,theinterfaceisincapableofsendingorreceivingOSPFHellos.Tocorrectthisproblem,changethenetworkmasksothatitincludestheEthernetaddress.Example9-4showsthenewconfigurationthatfixesthisproblem.Inthisexample,thewildcardmaskis0.0.255.255,whichmeansthatitcoverstherangefrom131.108.0.0to131.108.255.255.Example9-4FixingtheConfigurationonR2toIncludetheProperNetworkMask

R2#routerospf1network131.108.0.00.0.255.255area0

Example9-5showstheoutputofshowipospfneighborafterapplyingthecorrectnetworkmask.Example9-5showipospfneighborCommandOutputVerifiesThatOSPFIsUpAftertheCorrectNetworkMaskHasBeenConfigured

R2#showipospfneighbor

NeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/DR00:00:38131.108.1.1Ethernet0

BeginningwithCiscoIOSSoftwareRelease12.0,theoutputofshowipospfinterfacedoesn’tdisplayanythingifOSPFisnotenabledontheinterface.OSPFNeighborListIsEmpty—Cause:Layer1/2IsDown

OSPFrunsatLayer3ontopofLayer2.OSPFcannotsendorreceiveanyHellosifLayer2isdown.OneofthecausesforOSPFnotformingneighborsisthatLayers1or2mightbedown.IfLayer1orLayer2isdown,it’snotaproblemdirectlyrelatedtoOSPF.Figure9-3showstheflowcharttosolvethisproblem.


Example9-6showstheoutputofshowipospfinterfaceforEthernet0,whichshowsthatthelineprotocolisdown.Example9-6showipospfinterfaceCommandOutputIndicatesThattheLineProtocolIsDown

R2#showipospfinterfaceEthernet0Ethernet0isup,lineprotocolisdownInternetAddress131.108.1.2/24,Area0ProcessID1,RouterID131.108.1.2,NetworkTypeBROADCAST,Cost:10TransmitDelayis1sec,StateDOWN,Priority1NodesignatedrouteronthisnetworkNobackupdesignatedrouteronthisnetworkTimerintervalsconfigured,Hello10,Dead40,Wait40,Retransmit5

Solution

Layers1or2couldbedownforseveralreasons.Thelistthatfollowscoverssomeofthemostcommonthingstochecktodeterminewhethertheinterfaceorlineprotocolisdown:•Unpluggedcable•Loosecable•Badcable•Badtransceiver

•Badport•Badinterfacecard•Layer2problemattelcoincaseofaWANlink•Missingclockstatementincaseofback-to-backserialconnections

Tocorrectthisproblem,fixtheLayer2problembycheckingthepreviouslymentionedconditions.Example9-7showstheoutputofshowipospfinterfaceforEthernet0afterfixingtheLayer2problem.Example9-7VerifyingThatLayer2IsUp

R2#showipospfinterfaceEthernet0Ethernet0isup,lineprotocolisupInternetAddress131.108.1.2/24,Area4ProcessID1,RouterID131.108.1.2,NetworkTypeBROADCAST,Cost:10TransmitDelayis1sec,StateBDR,Priority1DesignatedRouter(ID)131.108.2.1,Interfaceaddress131.108.1.1BackupDesignatedrouter(ID)131.108.1.2,Interfaceaddress131.108.1.2Timerintervalsconfigured,Hello10,Dead40,Wait40,Retransmit5Helloduein00:00:07NeighborCountis1,Adjacentneighborcountis1Adjacentwithneighbor131.108.1.1(DesignatedRouter)Suppresshellofor0neighbor(s)

Example9-8showstheoutputofshowipospfneighbor,whichshowsthatOSPFadjacencyisFULL.Example9-8VerifyingOSPFAdjacencyState



OSPFNeighborListIsEmpty—Cause:InterfaceIsDefinedasPassiveUnderOSPF

WhenaninterfaceisdefinedaspassiveunderrouterOSPF,itsuppressesOSPFHellos.ThismeansthatOSPFdoesnotsendorreceiveanyHellosonsuchinterfaces.Therefore,noadjacencyisformed.Figure9-4showsaflowcharttosolvethisproblem.


Example9-9showstheoutputofshowipospfinterfaceforEthernet0ofRouterR2.Thiscommandshowsthatthisinterfaceisdefinedaspassive.Example9-9DeterminingWhetheranInterfaceIsDefinedasPassive

R2#showipospfinterfaceEthernet0Ethernet0isup,lineprotocolisupInternetAddress131.108.1.2/24,Area0ProcessID1,RouterID131.108.1.2,NetworkTypeBROADCAST,Cost:10TransmitDelayis1sec,StateDR,Priority1DesignatedRouter(ID)131.108.1.2,Interfaceaddress131.108.1.2NobackupdesignatedrouteronthisnetworkTimerintervalsconfigured,Hello10,Dead40,Wait40,Retransmit5NoHellos(Passiveinterface)NeighborCountis0,Adjacentneighborcountis0Suppresshellofor0neighbor(s)

Example9-10showstheconfigurationofRouterR2.ThisconfigurationshowsthattheEthernet0ofR2isdefinedaspassive.Example9-10TheEthernet0InterfaceofR2IsDefinedasPassive

R2#interfaceLoopback0

ipaddress131.108.0.1255.255.255.0!interfaceEthernet0ipaddress131.108.1.2255.255.255.0!routerospf1passive-interfaceEthernet0network131.108.0.00.0.255.255area0

Solution

Tocorrectthisproblem,removethepassive-interfacecommandfromtheOSPFconfiguration.Sometimes,thecommandisenteredintentionallysothattheroutercannottakepartinanyOSPFprocessonthatsegment.Thisisthecasewhenyoudon’twanttoformanyneighborrelationshiponaninterfacebutyoudowanttoadvertisethatinterface.Sometimes,theintentionisnottosendanyroutesbuttoreceiveallroutesonthatinterface,justaswithRIPorIGRP.Remember,definingapassiveinterfaceunderRIPorIGRPhasadifferentmeaningthandefiningapassiveinterfaceunderOSPForEIGRP.WhenRIPorIGRPisdefinedaspassive,RIPorIGRPwillnotsendanyroutingupdatesonthatinterfacebutwillreceivealltheroutingupdatesonthatinterface.InOSPF,apassiveinterfacemeans“donotsendorreceiveOSPFHellosonthisinterface.”So,makinganinterfacepassiveunderOSPFwiththeintentionofpreventingtherouterfromsendinganyroutesonthatinterfacebutreceivingalltheroutesiswrong.Example9-11showsthenewconfigurationofRouterR2.Thepassive-interfacecommandisremovedfromtheconfiguration.Example9-11RemovingthePassiveInterfaceDefinitionfromaRouterInterface

routerospf1nopassive-interfaceEthernet0network131.108.0.00.0.255.255area0

Example9-12showsthatOSPFisformingadjacencyafterremovingthepassive-interfacecommand.Example9-12VerifyingtheNewInterfaceDefinitionCorrectstheProblem



OSPFNeighborListIsEmpty—Cause:AccessListBlockingOSPFHellosonBothSides

OSPFsendsitsHelloonamulticastaddressof224.0.0.5.AllOSPF-enabledinterfaceslistentothisaddress.Itisverycommontoimplementanaccesslistforsecuritymeasuresattheinterfacelevel.BesuretopermitOSPFmulticastHellos’addressesintheaccesslistinthissituation;otherwise,theaccesslistmightblocktheOSPFmulticastaddressunknowinglyandpreventOSPFfromformingneighborsonthatinterface.ThissituationhappensonlywhentheaccesslistisblockingHellosonbothrouters.IfonlyonesideisblockingOSPFHellos,theoutputofshowipospfneighborwillindicatethattheneighborisstuckintheINITstate.Thiscaseisdiscussedlaterinthischapter.Figure9-5showstheflowcharttofollowtosolvethisproblem.


Example9-13showstheconfigurationofbothRoutersR1andR2,whichshowsthattheaccesslistispermittingonlyincomingTCPandUDPtraffic.Theinboundaccesslistchecksonlytrafficcominginonthatinterface.Becausethereisanimplicitdenyattheendofeachaccesslist,thisaccesslistwillblocktheOSPFmulticastaddressof224.0.0.5.Accesslist101inExample9-13isdefinedfordebuggingpurposesonly.ThisaccesslistlooksattheIPpacketssourcingfrom131.108.1.0–255addressesdestinedforOSPFmulticastaddressof224.0.0.5.Example9-13AccessListConfigurationforR1andR2

R1#interfaceEthernet0ipaddress131.108.1.1255.255.255.0ipaccess-group100in!access-list100permittcpanyanyaccess-list100permitudpanyany

access-list101permitip131.108.1.00.0.0.255host224.0.0.5

R2#interfaceEthernet0ipaddress131.108.1.2255.255.255.0ipaccess-group100in!access-list100permittcpanyanyaccess-list100permitudpanyany

access-list101permitip131.108.1.00.0.0.255host224.0.0.5

Example9-14showstheoutputofdebugippacket101detail.ThisdebugtracksdowntheOSPFHellopacketonlyontheEthernetsegment.ThedebugshowsthattheOSPFHellopacketfromRouterR1isdeniedonR2.Example9-14debugShowsThattheOSPFMulticastPacketsAreBeingDenied

R2#debugippacket101detailIPpacketdebuggingison(detailed)foraccesslist101IP:s=131.108.1.2(Ethernet0),d=224.0.0.5,len68,accessdenied,proto=89

Solution

Tocorrectthisproblem,youmustreconfiguretheaccesslisttopermitOSPFmulticastHellos.Example9-15showstheconfigurationthatfixesthisproblem.Inthisconfiguration,OSPFmulticastHellosarepermitted.Example9-15ConfiguringtheAccessListtoPermittheOSPFMulticastAddress

interfaceEthernet0ipaddress131.108.1.2255.255.255.0ipaccess-group100in!access-list100permittcpanyanyaccess-list100permitudpanyanyaccess-list100permitipanyhost224.0.0.5

Similarly,changetheaccesslistontheotherside,makingsurethattheOSPFHellosarepermittedintheaccesslist.Example9-16showstheOSPFneighborinFULLstateafterfixingtheconfiguration.Example9-16VerifyingThattheReconfiguredAccessListHasResolvedtheProblem


NeighborIDPriStateDeadTimeAddressInterface

131.108.2.11FULL/DR00:00:37131.108.1.1Ethernet0

OSPFNeighborListIsEmpty—Cause:MismatchedSubnetNumber/MaskoveraBroadcastLink

OSPFperformsthesubnetnumberandmaskcheckonallmediaexceptpoint-to-pointandvirtuallinksasspecified,bySection10.5ofOSPFRFC2328.Forpurposesofthisscenario,themediumisEthernetandthenetworktypeonEthernetisbroadcast.ThenetworkmaskgetsadvertisedintheHellopacket.Inthecaseofunnumberedpoint-to-pointlinksandvirtuallinks,thenetworkmaskfieldcontains0.0.0.0.IfthesubnetmaskisdifferentacrosstheEthernetlink,OSPFwillnotformaneighborrelationshiponthatlink.Figure9-6showstheflowcharttofollowtosolvethisproblem.


Example9-17showstheoutputofdebugipospfadj.ThisdebugshowsthatthereisamismatchedHelloparameter.Theneighborsubnetmaskis255.255.255.252andRouterR2’ssubnetmaskis255.255.255.0.Example9-17debugipoospfadjCommandOutputIndicatesaMismatchedHelloParameter

R2##debugipospfadjOSPFadjacencyeventsdebuggingisonR2#OSPF:Rcvhellofrom131.108.2.1area4fromEthernet0131.108.1.1OSPF:Mismatchedhelloparametersfrom131.108.2.1DeadR40C40,HelloR10C10MaskR255.255.255.248C255.255.255.0

TheletterRmeans“neighborconfiguration,”andCmeans“thisrouterconfiguration.”Inthecaseofdifferentsubnetnumbersthedebugmessagewillbe

OSPF:Rcvpktfrom131.108.1.1,Ethernet0,area0.0.0.1:srcnotonthesamenetwork

Example9-18showstheconfigurationofbothRoutersR1andR2,whichshowsthatbothrouters’Ethernetshavedifferentsubnetmasks.Example9-18ConfigurationsforR1andR2HaveDifferentSubnetMasks

R2#interfaceEthernet0ipaddress131.108.1.2255.255.255.0

R1#interfaceEthernet0

ipaddress131.108.1.1255.255.248.0

Solution

Tofixthisproblem,changetheneighbor’s(R1’s)subnetmasktomatchRouterR2’s,orchangethesubnetmaskofR2tomatchtheneighbor’ssubnetmask.AssumeherethatyouchangedthesubnetmaskofR1to255.255.255.0tomatchwithR2.Example9-19showsthatafterfixingthesubnetnetwork/mask,adjacencyisFULL.Example9-19VerifyThatSubnetMasksforR1andR2NowMatch



OSPFNeighborListIsEmpty—Cause:MismatchedHello/DeadIntervals

OSPFneighborsexchangeHellopacketsperiodicallytoformandmaintainneighborrelationships.OSPFadvertisestherouter’sHelloanddeadintervalsintheHellopackets.Theseintervalsmustmatchwiththeneighbor’s;otherwise,anadjacencywillnotform.Figure9-7showstheflowcharttofollowtosolvethisproblem.


Example9-20showstheoutputofdebugipospfadj,whichindicatesthattheneighbor’sHellointervaldoesnotmatchwithRouterR2’s.Example9-20VerifyingMismatchedHelloIntervalsBetweenOSPFNeighbors

R2#debugipospfadjOSPFadjacencyeventsdebuggingisonR2#OSPF:Rcvhellofrom131.108.2.1area4fromEthernet0131.108.1.1OSPF:Mismatchedhelloparametersfrom131.108.2.1DeadR40C40,HelloR15C10MaskR255.255.255.0C255.255.255.0

Example9-21showstheconfigurationofbothRoutersR1andR2.InR1,theHellointervalisconfiguredas15seconds.InR2,theHellointervaldefaultsto10seconds.Example9-21HelloIntervalConfigurationsforR1andR2


R1#interfaceEthernet0ipaddress131.108.1.1255.255.248.0ipospfhello-interval15

Solution

ThisexampleshowsaproblemwhentheHellointervalconfiguredforOSPFneighborsdoesn’tmatch.Thesameproblemhappenswhenthedeadintervaldoesn’tmatchbetweenOSPFneighbors.Inbothcases,thesolutionistochangetheHello/deadintervaltobeconsistentbetweenOSPFneighbors.Unlessthereareanyspecificreasonstodeviatefromthedefaultsettings,theHelloanddeadintervalsshouldbekepttotheirdefaultvalues.InExample9-22,theconfigurationonR1ischangedsothatitusesthedefaultvaluefortheHellointervalonEthernet,whichis10seconds.RemovingtheHellointervalchangestheHellointervalvaluebacktoitsdefault.Example9-22ChangingHelloIntervaltoItsDefaultValue

R1#interfaceEthernet0ipaddress131.108.1.1255.255.248.0noipospfhello-interval15

Example9-23showsthatafterfixingtheHelloanddeadintervals,OSPFformsanadjacency.Example9-23VerifyingThatOSPFIsFormingNeighborsAfterMatchingHello/DeadIntervals



OSPFNeighborListIsEmpty—Cause:MismatchedAuthenticationType

OSPFusestwotypesofauthentication,plain-text(Type1)andMD5(Type2).Type0iscallednullauthentication.Iftheplain-textauthenticationtypeisenabledononeside,theothersidemustalsohaveplain-textauthentication.OSPFwillnotformanadjacencyunlessbothsidesagreeonthesameauthenticationtype.Inonesituation,onesideisconfiguredforplain-textorMD5authenticationbuttheothersideisnotconfiguredforanyauthentication.ThissituationcreatesacaseofanOSPFneighborbeingstuckinINIT,whichisdiscussedlaterinthischapter.Figure9-8showstheflowcharttofollowtosolvethisproblem.


Example9-24showstheoutputofdebugipospfadj,indicatingthatR2’sneighborisconfiguredforMD5authenticationandthatR2isconfiguredforplain-textauthentication.Example9-24debugShowsMismatchedAuthenticationType

R2#debugipospfadjOSPFadjacencyeventsdebuggingisonR2#OSPF:Rcvpktfrom131.108.1.1,Ethernet0:MismatchAuthenticationtype.Inputpacketspecifiedtype2,weusetype1

Example9-25showstheconfigurationofbothRoutersR1andR2,indicatingthatR2isusingplain-textauthenticationandR1isusingMD5authentication.Example9-25AuthenticationTypeConfigurationforR1andR2

R2#routerospf1area0authenticationnetwork131.108.0.00.0.255.255area0

R1#routerospf1area0authenticationmessage-digestnetwork131.108.0.00.0.255.255area0

Solution

Tofixthisproblem,makesurethatbothsidesareusingthesameauthenticationtype.Example9-26showsthatafterusingaconsistentauthenticationtype,OSPFformstheadjacency,asindicatedbytheFULLstate.Example9-26VerifyingThattheAuthenticationTypeBetweenOSPFNeighborsIsNowConsistent


NeighborIDPriStateDeadTimeAddressInterface

131.108.2.11FULL/DR00:00:32131.108.1.1Ethernet0

OSPFNeighborListIsEmpty—Cause:MismatchedAuthenticationKey

Whenauthenticationisenabled,theauthenticationkeyalsomustbeconfiguredontheinterface.Authenticationpreviouslywassupportedonaper-areabasis,butbeginningwiththespecificationsinRFC2328,authenticationissupportedonaper-interfacebasis.ThisfeaturehasbeenimplementedinCiscoIOSSoftwareRelease12.0.8andlater.Ifauthenticationisenabledononesidebutnottheother,OSPFcomplainsaboutthemismatchinauthenticationtype.Sometimes,theauthenticationkeyisconfiguredcorrectlyonbothsidesbutdebugipospfadjstillcomplainsaboutamismatchedauthenticationtype.Inthissituation,authentication-keymustbetypedagainbecausethereisachancethataspacewasaddedduringtheauthenticationkeyconfigurationbymistake.Becausethespacecharacterisnotvisibleintheconfiguration,thispartisdifficulttodetermine.Anotherpossiblethingthatcangowrongisforoneside,R1,tohaveaplain-textkeyconfiguredandtheotherside,R2,tohaveanMD5keyconfigured,eventhoughtheauthenticationtypeisplaintext.Inthissituation,theMD5keyiscompletelyignoredbyR2becauseMD5hasnotbeenenabledontherouter.Thisisequivalenttonothavinganyplain-textkeyconfiguredundertheinterface.Formoreinformationonauthentication,refertoChapter8.Figure9-9showstheflowcharttofollowtosolvethisproblem.


Example9-27showstheoutputofdebugipospfadj,whichshowsthatthereisanauthenticationkeymismatch.Example9-27DetectinganAuthenticationKeyMismatch

R2#debugipospfadjOSPFadjacencyeventsdebuggingisonR2#OSPF:Rcvpktfrom131.108.1.1,Ethernet0:MismatchAuthenticationKey-ClearText

Example9-28showstheconfigurationofR1andR2.NotethatR2isnotconfiguredforanyauthenticationkey,whereasR1isconfiguredwithanauthenticationkeythatiscausingthisproblem.Example9-28ConfigurationofR1andR2


R1#interfaceEthernet0ipaddress131.108.1.1255.255.248.0ipospfauthentication-keyCisco

Solution

Tosolvethisproblem,makesurethatbothsideshavethesamekindofauthenticationkey.Iftheproblemstillexists,retypetheauthenticationkey;thereisapossibilityofanaddedspacecharacterbeforeoraftertheauthenticationkey.Example9-29showstheoutputofshowipospfneighborafterfixingthisproblem.Example9-29VerifyingThatOSPFNeighborsAreUpAfterUsingIdenticalAuthenticationKeys



OSPFNeighborListIsEmpty—Cause:MismatchedAreaID

OSPFsendsareainformationintheHellopackets.Ifbothsidesdonotagreethattheyaremembersofacommonarea,noOSPFadjacencywillbeformed.TheareainformationisapartoftheOSPFprotocolheader.Figure9-10showstheflowcharttofollowtosolvethisproblem.


Example9-30showstheconfigurationofR2andR1.ReferbacktoFigure9-1;ifR1’sEthernetinterfaceisincludedinarea0andR2’sEthernetisincludedinarea1,itwillcauseareaIDmismatch.Example9-30AreaConfigurationsforInterfacesonR1andR2

R2#interfaceEthernet0ipaddress131.108.1.2255.255.255.0!routerospf1network131.108.0.00.0.255.255area1


Example9-31showstheoutputofdebugipospfadjonR1,indicatingthatR1isreceivinganOSPFpacketfromR2andthattheOSPFheaderhasarea0.0.0.1init.Thisprovesthattheothersideisconfiguredforarea0.0.0.1insteadofarea0.Thereisnoneedtochecktheotherside’sconfigurationinthiscase.

Example9-31DeterminingtheOSPFNeighborAreaConfiguration

R1#debugipospfadjOSPFadjacencyeventsdebuggingisonR1#OSPF:Rcvpktfrom131.108.1.2,Ethernet0,area0.0.0.0mismatcharea0.0.0.1intheheader

Example9-32showstheconsolelogofR2.ThislogshowsthatR1isreceivinganOSPFpacketthathasarea0.0.0.0intheOSPFheader.Becausethisrouterisnotconfiguredforarea0,itreceivesthismessageattheconsoleloglevel.IftheneighborRouterR1isconfiguredwithsomeotherarea,theonlywaytofindoutaboutareamismatchistoturnondebugipospfadj,asincaseofR1.Example9-32ConsoleLogsofR2ShowingMismatchArea

R2#showlog%OSPF-4-ERRRCV:Receivedinvalidpacket:mismatchareaID,frombackboneareamustbevirtual-linkbutnotfoundfrom131.108.1.1,Ethernet0

Solution

Tosolvethisproblem,configurethesameareaacrossthelink.Example9-33showsthattheR1configurationhasbeenchangedsothattheareaIDofR1nowmatchesR2’s.Example9-33CorrectedConfigurationonR1

R1#interfaceEthernet0ipaddress131.108.1.1255.255.255.0!routerospf1nonetwork131.108.0.00.0.255.255area0network131.108.0.00.0.255.255area1

Example9-34showsthatafterfixingthisproblem,OSPFformedanadjacency.Example9-34VerifyingOSPFNeighborsAfterFixingtheMismatchedAreaID



OSPFNeighborListIsEmpty—Cause:MismatchedStub/Transit/NSSAAreaOptions

WhenOSPFexchangesHellopacketswithaneighbor,oneofthethingsthatitexchangesintheHellopacketisanoptionalcapabilityrepresentedby8bits.OneoftheoptionfieldsisfortheEbit,whichistheOSPFstubareaflag.WhentheEbitissetto0,theareawithwhichtherouterisassociatedisastubarea,andnoexternalLSAsareallowedinthisarea.IfonesidehastheEbitsetto0andtheothersidedoesn’t,OSPFadjacencyisnotformed.Thisiscalledanoptionalcapabilitymismatch.Onesidesaysthatitcanallowexternalroutes,andtheothersidesaysthatitcannotallowexternalroutes,soOSPFneighborrelationshipsarenotformed.Figure9-11showstheflowcharttofollowtosolvethisproblem.


Example9-35showstheconfigurationofRoutersR1andR2.R2’sconfigurationshowsthatarea1isconfiguredasastub,butR1’sarea1isconfiguredasastandardarea.Example9-35AreaConfigurationforR1andR2

R2#interfaceEthernet0ipaddress131.108.1.2255.255.255.0!routerospf1area1stubnetwork131.108.0.00.0.255.255area1


Example9-36showstheoutputofdebugipospfadjonR1.Thisdebugshowstheproblemasastub/transitmismatch.Example9-36debugipospfadjCommandOutputDeterminesaStub/TransitAreaOptionBitMismatch

R1#debugipospfadjOSPFadjacencyeventsdebuggingison

R1#OSPF:Rcvhellofrom131.108.0.1area1fromEthernet0131.108.1.2OSPF:Hellofrom131.108.1.2withmismatchedStub/Transitareaoptionbit

Solution

Tosolvethisproblem,makesurethatbothsidesagreeonthesametypeofarea.Thisexampletalksaboutonlythestubarea,butasimilarproblemcanhappenifonesideisconfiguredforstubandtheothersideisconfiguredasanOSPFNSSA.AnothersituationisthatonesideisconfiguredforNSSAandtheothersideisconfiguredforanormalarea.Inanycase,wheneverthereisamismatchedareatype,OSPFadjacencywillnotbeformed.Example9-37showsthedebugipospfadjoutputinthecaseofanNSSAareamismatch.Example9-37debugipospfadjCommandOutputDeterminesanNSSAOptionBitMismatch

R1#debugipospfadjOSPFadjacencyeventsdebuggingisonR1#OSPF:Rcvhellofrom131.108.0.1area1fromEthernet0131.108.1.2OSPF:Hellofrom131.108.1.2withmismatchedNSSAoptionbit

Example9-38showsaconfigurationchangeonR1thatfixestheproblem.NowR1isalsoapartofthestubarea.Example9-38ConfigurationChangeonR1ThatFixestheProblem

R1#interfaceEthernet0ipaddress131.108.1.1255.255.255.0!routerospf1area1stubnetwork131.108.0.00.0.255.255area1

Example9-39showstheoutputofshowipospfneighborafterfixingthisproblem.Example9-39VerifyingThatOSPFNeighborsAreUpAfterFixingtheMismatchStub/NSSAProblem



OSPFNeighborListIsEmpty—Cause:OSPFAdjacencyOverSecondaryIPAddress

ThisisaverycommonprobleminwhichacustomermighthaveoneClassCaddressonaLANsegment.Whenthecustomerrunsoutofaddressspace,hegetsanotherClassCaddressandassignsthenewaddressasasecondaryaddressunderthesameinterface.EverythingworksfineuntiltworoutersmustexchangeOSPFHellos/updatesandonerouter’sprimaryIPaddressisassignedasthesecondaryIPaddressontheotherside,asdepictedinthenetworkinFigure9-12.ThetworoutersareconnectedthroughaLayer2switch.

Figure9-12TwoRoutersConnectedThroughaSwitch,withOneSide’sPrimaryInterfaceIPAddress

IdenticaltotheOtherSide’sSecondary



Example9-40showstheconfigurationofbothR1andR2.TheconfigurationillustratesthatR2hasaprimaryandasecondaryaddressconfiguredonitsEthernetinterface,andthatthesubnetnumberusedfortheprimaryaddressonR1isforthesecondaryaddressonR2.Example9-40R2’sFastEthernet0/0InterfaceSecondaryAddressConfigurationMatchesR1’sEthernet0InterfacePrimaryAddressConfiguration

R2#interfaceFastEthernet0/0ipaddress131.108.1.2255.255.255.0secondaryipaddress131.108.4.2255.255.255.0


Example9-41showstheoutputofdebugipospfadj.Thisoutputisexactlythesameasthedebugoutputincaseofamismatchedsubnetnumber.Thisisbecause,whenR1receivesaHellopacketfromR2,the

sourceaddresswillbe131.108.4.2,whichisadifferentsubnetthanitsconnectedinterface.Asaresult,R1willcomplain.Example9-41debugipospfadjCommandOutputIndicatesanIPAddressConflict

R2#debugipospfadjOSPFadjacencyeventsdebuggingisonR2#OSPF:Rcvpktfrom131.108.1.1,FastEthernet0/0,area0.0.0.1:srcnotonthesamenetwork

Solution

ThesolutiontothiskindofproblemistocreatesubinterfacesonR1.ThisispossibleonlyiftheinterfacethathasthesecondaryaddressisFastEthernetorGigabitEthernetanditisconnectedthroughaLayer2switch.ThiscanbeachievedthroughanInter-SwitchLink(ISL),inthecaseofaCiscoswitch,ordot1Qencapsulation,inthecaseofadifferentvendor’sswitch.ISLordot1QencapsulationisusedtoroutebetweentwoseparateVLANs.TheswitchportthatconnectstotheFastEthernetinterfaceofR2isconfiguredasatrunkport,soallthetrafficbetweenVLAN1andVLAN2willgothroughtherouterandtherouterwillroutebetweenthesetwoVLANs.Example9-42showstheconfigurationofR1andaCiscoswitchtouseanISLtrunksothatitcancreatesubinterfacesonR2.Example9-42CreatingSubinterfacesonR2

R2#interfaceFastEthernet0/0noipaddressfull-duplex!interfaceFastEthernet0/0.1encapsulationisl2ipaddress131.108.1.2255.255.255.0

interfaceFastEthernet0/0.2encapsulationisl1ipaddress131.108.4.2255.255.255.0cat-5k-1>(enable)settrunk11/10onPort(s)11/10trunkmodesettoon

Example9-42showstheexampleofhowtocreatesubinterfacesandhowtoenableVLANtrunkingontheCiscoCatalystswitch.R1’sFastEthernetinterfaceisincludedinVLAN2,andthesubinterfaceofR2,FE0/0.1,alsoisaddedinVLAN2.Also,port11/10oftheswitchthatconnectstoR2isenabledfortrunkingsothatitwillcarrybothVLAN1andVLAN2traffic.Similarconfigurationscanbeimplementedinthecaseof802.1Qencapsulation.Figure9-14showsthelogicalpictureaftermakingthischange.FE0/0.1isasubinterfaceusingISLencapsulation.

Figure9-14LogicalFigureofSubinterfacesAfterISLEncapsulation

Aftermakingthischange,R2willformaneighborrelationshipwithR1onFE0/0.1.Theother

subinterface,FE0/0.2,whichisinVLAN1,willformaneighborrelationshipwithotherroutersinVLAN1.FE0/0.1andFE0/0.2arelogicalsubinterfaces.Thismeansthatbothofthesesubinterfacesaresubsetsofonephysicalinterface(FE0/0)thatconnectstoport11/10oftheswitch.Example9-43showstheoutputofshowipospfneighboraftermakingthischange.Example9-43OSPFFormingNeighborsAfterCreatingSubinterface


NeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/DR00:00:32131.108.1.1FastEthernet0/0.1

OSPFNeighborListIsEmpty—Cause:OSPFAdjacencyoverAsynchronousInterface

YoumustenableasynchronousdefaultordynamicroutingwhenOSPFisenabledbetweentworoutersoverasynchronousinterface.Whenasyncdefaultroutingisenabled,therouteralwayssendsroutingpacketsoveranasynchronousinterface.IncaseofinteractiveasynchronousconnectionsforwhichusershavetotypeppptoestablishthePPPsession,theasyncdynamicroutingcommandcanbeused,butthenusersmusttypeppp/routingtoenableroutingovertheasynchronousinterface.AninabilitytodothiscausesOSPFnottoformanyadjacencyovertheasynchronouslink.Figure9-15showsthenetworkdiagramwiththetworoutersrunningOSPFbetweenasynchronousinterfaces.

Figure9-15OSPFRunningBetweenAsynchronousInterfaces



Example9-44showstheconfigurationofR1andR2.Thisconfigurationshowsthatasynchronousdefaultroutingismissingfromtheinterfaceconfiguration.Example9-44VerifyingThatAsynchronousDefaultRoutingIsMissingontheAsynchronousInterfacesofR1andR2

R1#interfaceAsync1descriptionASYNCLINETOR2ipaddress131.108.1.1255.255.255.0encapsulationpppasyncmodededicateddialerin-banddialermapip131.108.1.2nameRouter2broadcastdialer-group1pppauthenticationchap

R2#interfaceAsync1descriptionASYNCLINETOR1ipaddress131.108.1.2255.255.255.0encapsulationpppasyncmodededicateddialerin-banddialermapip131.108.1.1nameRouter2broadcastdialer-group1pppauthenticationchap

Solution

Inthisexample,useeitherasyncdefaultroutingorasyndynamicroutingtosolvethisproblem.Example9-45showstheconfigurationsofR1andR2afterusingasyncdefaultrouting.Example9-45ConfiguringR1andR2toUseasyncdefaultrouting

R1#interfaceAsync1descriptionASYNCLINETOR2ipaddress131.108.1.1255.255.255.0encapsulationpppasyncdefaultroutingasyncmodededicateddialerin-banddialermapip131.108.1.2nameRouter2broadcastdialer-group1pppauthenticationchap

R2#interfaceAsync1descriptionASYNCLINETOR1ipaddress131.108.1.2255.255.255.0encapsulationpppasyncdefaultrouting

asyncmodededicateddialerin-banddialermapip131.108.1.1nameRouter2broadcastdialer-group1pppauthenticationchap

Example9-46showsthatOSPFformsneighborrelationshipsafterfixingthisproblem.Example9-46VerifyingThatR1andR2AreFormingNeighborsAfterUsingasyncdefaultrouting


NeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/-00:00:32131.108.1.1Async1

OSPFNeighborListIsEmpty—Cause:NoNetworkTypeorNeighborDefinedoverNBMA

ThisisaclassicproblemofNBMAnetworks.OSPForanyotherroutingprotocolwillnotbecapableofsendingorreceivinganyHellopacketunlessyouconfigureaneighborstatementorchangethenetworktypetobroadcastorpoint-to-multipoint.Whentheneighborstatementisconfigured,ittriggersOSPFHellosandneighborrelationshipsareformed.Changingthenetworktypealsochangestheinterfacebehavior;inthecaseofthebroadcastnetworktype,OSPFstartssendingandreceivingtheOSPFHellos.Chapter8providesadetailedexplanationofOSPFnetworktypes.Figure9-17showsthenetworkdiagramwithtworoutersrunningOSPFinFrameRelaycloud.FrameRelayisjustoneexample;thisproblemcanbeproducedinanynonbroadcastnetwork,suchasX.25,SMDS,andsoon.

Figure9-17OSPFoverNonbroadcastMedia



Example9-47showstheoutputofshowinterfaceserial0onR2.Thenetworktypeisshowingasnonbroadcast.Anynonbroadcastinterface—forexample,X.25,SMDS,FrameRelay,andsoon—alwaysshowsthenetworktypeasnonbroadcast.Example9-47DeterminingtheNetworkTypeonR2’sSerial0Interface

R2#showipospfinterfaceserial0Serial0isup,lineprotocolisupInternetAddress131.108.1.2/24,Area1ProcessID1,RouterID131.108.1.2,NetworkTypeNON_BROADCAST,Cost:64TransmitDelayis1sec,StateDR,Priority1DesignatedRouter(ID)131.108.1.2,Interfaceaddress131.108.1.2NobackupdesignatedrouteronthisnetworkTimerintervalsconfigured,Hello30,Dead120,Wait120,Retransmit5Helloduein00:00:00NeighborCountis0,Adjacentneighborcountis0Suppresshellofor0neighbor(s)

Solution

Tosolvethisproblem,configuretheneighborstatementunderrouterospf,asdoneinExample9-48.Byconfiguringtheneighborstatement,OSPFstartssendingtheHellopacketasaunicastinsteadofa

multicast.Thisisalsoausefultechniquewhenthemulticastcapabilitiesofanymediumarebroken.Besuretodefinetherightneighboraddress;otherwise,theOSPFHellopacketwillnotmakeittotheneighbor.Example9-48OSPFConfigurationwithneighborStatement

R2#routerospf1network131.108.0.00.0.255.255area1neighbor131.108.1.1priority1

Othermethodstosolvethisproblemincludechangingthenetworktypetoeitherbroadcastorpoint-to-multipoint.Inthiscase,OSPFstartssendingthemulticastHellosacrossthelink.Example9-49showshowtochangethenetworktypetobroadcastandthenshowstheoutputofshowinterfaceserial0afterusingthenetworktypebroadcast.Example9-49VerifyingThattheBroadcastNetworkTypeConfigurationIsAllowingOSPFtoFormanAdjacency

R2#interfaceSerial0ipospfnetworkbroadcast

R2#showipospfinterfaceserial0Serial0isup,lineprotocolisupInternetAddress131.108.1.2,Area1ProcessID1,RouterID131.108.1.2,NetworkTypeBROADCAST,Cost:64TransmitDelayis1sec,StateBDR,Priority1DesignatedRouter(ID)131.108.2.1,Interfaceaddress131.108.1.1BackupDesignatedrouter(ID)131.108.1.2,Interfaceaddress131.108.1.2Timerintervalsconfigured,Hello10,Dead40,Wait40,Retransmit5Helloduein00:00:05NeighborCountis1,Adjacentneighborcountis1Adjacentwithneighbor131.108.2.1(DesignatedRouter)Suppresshellofor0neighbor(s)

Similarly,changingthenetworktypetopoint-to-multipointwillmakeitwork.Example9-50showshowtochangethenetworktypetopoint-to-pointandthenshowstheoutputofshowipospfneighbor,whichshowsthattheneighborsareFULLacrosstheseriallinkaftermakingthechange.Example9-50VerifyingThatthePoint-to-MultipointNetworkTypeConfigurationIsAllowingOSPFtoFormAdjacency

R2#interfaceSerial0ipospfnetworkpoint-to-multipoint


NeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/-00:01:42131.108.1.1Serial0

OSPFNeighborListIsEmpty—Cause:FrameRelay/DialerInterfaceMissingthebroadcastKeywordonBothSides

OSPFusesmulticastHellostoformadjacencies.Otherroutingprotocols—forexample,RIPandEIGRP—alsousebroadcastsormulticaststoformneighborrelationships.InthecaseofFrameRelayordialer

interfaces,youmustenablethebroadcastkeywordinframe-relayordialer-mapstatementsonbothendstopropagateOSPFHellos.Thesemapsstatementsarevalidonlyiftheinterfacesaremultipointinnature.Forexample,bydefault,FrameRelayinterfacesaremultipoint.Also,theBRIinterfaceismultipointbecauseitiscapableofdialingmorethanonenumber.Onethingtonotehereisthatbothsidesshouldhavethisbroadcastkeywordmissingfromtheframe-relaymapordialer-mapconfigurationstoproducethisproblem.Ifjustonesideismissingthebroadcastkeyword,theothersidewillseethisrouterinINITandtheneighborswillneverbecomeadjacent.Thiscaseisdiscussedlaterinthischapterinthesection“Problem:OSPFNeighborStuckinINIT.”Figure9-19showstheflowcharttofollowtosolvethisproblem.


Example9-51showstheoutputofdebugippacket100detail,whichindicatesthattheHellopacketsgeneratedfromR1arenotgettingacrossbecauseofencapsulationfailure.Theaccesslisthereisusedonlyforthedebuggingpurpose.ThisaccesslistmonitorsthoseIPpacketsthataresourcingfrom131.108.1.1and131.108.1.2anddestinedfor224.0.0.5.Example9-51VerifyingThatOSPFHellosAreBeingDroppedBecauseofEncapsulationFailure

R1#showaccess-list100ExtendedIPaccesslist100permitip131.108.1.00.0.0.3host224.0.0.5(8matches)R1#debugippacket100detailIPpacketdebuggingison(detailed)foraccesslist100R1#IP:s=131.108.1.2(Serial0),d=224.0.0.5,len64,rcvd0,proto=89IP:s=131.108.1.1(local),d=224.0.0.5(Serial0),len68,sendingbroad/multicast,

proto=89IP:s=131.108.1.1(local),d=224.0.0.5(Serial0),len68,encapsulationfailed,proto=89

Example9-52showstheconfigurationofR1andR2.Theconfigurationshowsthatthebroadcastkeywordismissingfromtheframe-relaymapstatements.Example9-52ConfigurationsforR1andR2RevealMissingbroadcastKeywords

R1#interfaceSerial0ipaddress131.108.1.1255.255.255.0encapsulationframe-relayframe-relaymapip131.108.1.216


Solution

Example9-53showsthemodifiedconfigurationsforR1andR2thatfixesthisproblem.Again,thekeywordbroadcastmustbeenabledonbothsides.Ifitisenabledononlyoneside,itwillproduceastuckinINITproblem,whichisdiscussedlaterinthischapter.Example9-53AddingthebroadcastKeywordtotheframe-relaymapStatementsforR1andR2

R1#interfaceSerial0ipaddress131.108.1.1255.255.255.0encapsulationframe-relayipospfnetworkbroadcastframe-relaymapip131.108.1.216broadcast


Youcanuseasimilarconfigurationforadialerinterface,asdemonstratedinExample9-54.Example9-54AddingthebroadcastKeywordtothedialermapStatementsforR1andR2

R1#interfaceBRI0ipaddress131.108.1.1255.255.255.0encapsulationpppdialermapip131.108.1.2broadcastnameR276444

R2#interfaceBRI0ipaddress131.108.1.2255.255.255.0encapsulationpppdialermapip131.108.1.1broadcastnameR176555

Example9-55showsthatanOSPFadjacencyisformedacrosstheserialinterfaceusingFrameRelayencapsulationafterfixingthisproblem.Example9-55VerifyingThattheNewConfigurationsforR1andR2AreSuccessful


NeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/DR00:00:32131.108.1.1Serial0

Problem:OSPFNeighborStuckinATTEMPTThisproblemisvalidonlyforNMBAnetworksinwhichneighborstatementsaredefined.StuckinATTEMPTmeansthatarouteristryingtocontactaneighborbysendingitsHellobuthasn’treceivedanyresponse.ThestateofATTEMPTitselfisnotaproblembecausethisisanormalstatethataroutergoesthroughinNBMAmode;however,ifarouterisstuckinthisstateforalongtime,it’sanindicationofaproblem.Chapter8discussestheATTEMPTstateingreaterdetail.Themostcommonpossiblecausesofthisproblemareasfollows:•Misconfiguredneighborstatement•UnicastbrokenonNBMA

Figure9-20showsanetworkinwhichtworoutersarerunningOSPF.ThisnetworksetupisusedtoproduceastuckinATTEMPTproblem.

Figure9-20NetworkSetupVulnerabletoStuckinATTEMPTProblem

Example9-56showstheoutputofshowipospfneighbor,whichindicatesthattheneighborisstuckinATTEMPT.TheneighborIDfieldshowsN/A,whichmeansthatthisrouterdoesn’thaveanyinformationabouttheneighbor—that’swhythisfieldisshowingN/A;otherwise,itwouldshowtheneighbor’srouterID.Example9-56OSPFNeighborsStuckinATTEMPTState


NeighborIDPriStateDeadTimeAddressInterfaceN/A0ATTEMPT/DROTHER00:01:57131.108.1.1Serial0

OSPFNeighborStuckinATTEMPT—Cause:MisconfiguredneighborStatement

OSPFsendsaunicastpacketonNBMAinterfacesifneighborstatementsmanuallyareconfiguredundertherouterospfconfiguration.ThisneighborstatementdefinesthedestinationIPaddressoftheOSPFpacket.Iftheneighborstatementisnotcorrect,OSPFcannotsendthepackettotherightneighbor.Itisverycommontomakeaconfigurationmistake,soiftheneighbordoesn’tcomeupafterawhile,checktheneighborstatementeitherintheOSPFconfigurationorintheoutputofshowipospfneighbor.IftheneighborshowsinATTEMPTstate,thisrouteristryingtocontactaneighborbysendingtheHellopacket,butithasnotreceivedanyresponsefromtheneighbor.Figure9-21showstheflowcharttofollowtosolvethisproblem.


InExample9-57,theoutputofshowipospfneighborindicatesthattheneighborisstuckinATTEMPT.Theneighborstatementisconfigured,buttheneighborIPaddressisnotcorrect.Insteadof131.108.1.1(asshownintheFigure9-20),itshows131.108.1.11.Example9-57showipospfneighborCommandOutputIndicatesThattheNeighborIsStuckinATTEMPT


NeighborIDPriStateDeadTimeAddressInterfaceN/A0ATTEMPT/DROTHER00:01:57131.108.1.11Serial0

Example9-58showstheconfigurationofR2,indicatingthattheneighborstatementalsoiswronglyconfigured.Example9-58R2’sConfigurationHasanIncorrectneighborStatement


Solution

Tofixthisproblem,configuretheproperneighborstatementwiththeproperIPaddress.Example9-59

showsthenewconfigurationofR2thatfixesthisproblem.Example9-59ConfiguringtheProperneighborStatementonR2toCorrecttheProblem


Example9-60showstheoutputofshowipospfneighborafterfixingtheproblem.Example9-60VerifyingThattheNewneighborStatementHasResolvedtheIssue



OSPFNeighborStuckinATTEMPT—Cause:UnicastConnectivityIsBrokenonNBMA

OSPFsendsunicastHellosoverNBMAinterfacesifneighborstatementsmanuallyareconfigured.Iftheunicastconnectivityisbroken,OSPFwillneverformanyadjacencies.OSPFtriestocontactneighborseveryHellointerval(thatis,every30seconds)bydefaultoverNBMAinterfaces.Ifitdoesnotreceiveanyreplyfromtheneighbor,itwillshowthattheneighborisstuckinATTEMPT.Manypossiblereasonscanexistforbrokenunicastconnectivity.Youshouldconsiderthefollowingcausesforabrokenunicastconnectivity,assumingthatLayer2isup:•AwrongDLCIorVPI/VCImappingexistsinaFrameRelayorATMswitch,respectively.•Anaccesslistisblockingtheunicast.•NATistranslatingtheunicast.



Example9-61showstheoutputofapinginitiatedfromR2toR1.Thepingshows100percentfailure.BecausethepingusesICMPandisaunicastpacket,thefailureindicatesthattheunicastconnectivityisbroken.Example9-61pingFailureIndicatesaConnectivityProblem

R2#ping131.108.1.1

Typeescapesequencetoabort.Sending5,100-byteICMPEchosto131.108.1.1,timeoutis2seconds:.....Successrateis0percent(0/5)R2#

Solution

Asmentionedpreviously,theunicastbrokenconnectivitycouldbetheresultofmanyfactors.Ifit’sawrongDLCIorVCmapping,besuretocheckthesemappingsandcorrectthose.Ifit’stheaccesslistthatisblockingtheunicastconnectivity,besuretopermitthenecessaryunicastIPaddressintheaccesslist.Example9-62showstheoutputofshowipospfneighborafterfixingtheunicastconnectivityproblem.Example9-62VerifyingThatUnicastIsOperationalAgainandThatOSPFIsFormingNeighbors



Problem:OSPFNeighborStuckinINITWhenarouterreceivesanOSPFHellofromaneighbor,itsendstheHellopacketbyincludingthatneighbor’srouterIDintheHellopacket.Ifitdoesn’tincludetheneighbor’srouterID,theneighborwillbestuckinINIT.Thisisanindicationofaproblem.ThefirstpacketthatarouterreceiveswillcausetheroutertogointoINITstate.Atthispoint,itisnotaproblem,butiftherouterstaysinthisstateforalongtime,it’sanindicationofaproblem.ItmeansthattheneighborrouterisnotseeingHellossentbythisrouter—that’swhyitisnotincludingtherouterIDoftherouterinitsHellopacket.ThenetworksetupinFigure9-20isusedheretodiscussthestuckinINITproblem.Themostcommonpossiblecausesofthisproblemareasfollows:•AnaccesslistononesideisblockingOSPFHellos.•Multicastcapabilitiesarebrokenononeside(6500switchproblem).•Authenticationisenabledononlyoneside(virtuallinkexample).•Theframe-relaymap/dialermapstatementononesideismissingthebroadcastkeyword.•HellosaregettinglostononesideatLayer2.

Example9-63showstheoutputofshowipospfneighbor,whichshowsstuckinINIT.Example9-63showipospfneighborCommandOutputIndicatesThatR2’sNeighborIsStuckinINIT


NeighborIDPriStateDeadTimeAddressInterface131.108.2.11INIT/-00:00:33131.108.1.1Ethernet0

OSPFNeighborStuckinINIT—Cause:AccessListonOneSideIsBlockingOSPFHellos

OSPFusesamulticastaddressof224.0.0.5forsendingandreceivingHellopackets.IfanaccesslistisdefinedontheinterfaceandOSPFisenabledonthatinterface,thismulticastaddressmustbeexplicitlypermittedintheaccesslist;otherwise,itcanproduceproblemssuchasstuckinINIT.ThestuckinINITproblemoccursonlyifonesideisblockingOSPFHellos.IfbothsidesareblockingOSPFHellos,theoutputofshowipospfneighborreturnsanemptylist.Figure9-23showstheflowcharttofollowtosolvethisproblem.


Example9-64showstheoutputofshowaccess-list101anddebugippacket101detailonR1,whereaccesslist101isconfiguredtoseeonlytheOSPFHellopacketsbetweenR1andR2.Example9-64debugOutputShowsThatOSPFHellosAreDenied

R1#showaccess-list101ExtendedIPaccesslist101permitip131.108.1.00.0.0.3host224.0.0.5(8matches)R1#debugippacket101detailIPpacketdebuggingison(detailed)foraccesslist101R1#IP:s=131.108.1.1(local),d=224.0.0.5(Ethernet0),len60,sendingbroad/multicast,proto=89IP:s=131.108.1.2(Ethernet0),d=224.0.0.5,len82,accessdenied,proto=89IP:s=131.108.1.1(local),d=224.0.0.5(Ethernet0),len60,sendingbroad/multicast,proto=89IP:s=131.108.1.2(Ethernet0),d=224.0.0.5,len82,accessdenied,proto=89

Example9-65showstheconfigurationofR1.Accesslist100onR1ispermittingonlytrafficdestinedforR1andR2interfaceaddresses;itdeniesanyothertraffic,includingOSPFHellos.Accesslist101onRouterR1isconfiguredtolimitthedebugsothatitwilldisplayonlyOSPFHellosgoingacross.

Example9-65AccessListConfigurationonR1ThatBlocksOSPFHellos

R1#!interfaceEthernet0ipaddress131.108.1.1255.255.255.0ipaccess-group100in!access-list100permitipany131.108.1.00.0.0.255

Solution

Tofixthisproblem,allowtheOSPFHellosinaccesslist100onR1.Thenewlineallowsanypacketsourcefrom131.108.1.0–255destinedforOSPFmulticastaddressof224.0.0.5.Example9-66showsthemodifiedaccesslistonR1.Example9-66ModifiedAccessListonR1

R1#access-list100permitipany131.108.1.00.0.0.255access-list100permitip131.108.1.00.0.0.255host224.0.0.5

Example9-67showstheoutputofshowipospfneighborafterfixingtheproblem.Example9-67showipospfneighborCommandOutputVerifiesThattheAccessListNowPermitsOSPFMulticastsandOSPFNeighborsAreFormed



OSPFNeighborStuckinINIT—Cause:MulticastCapabilitiesAreBrokenonOneSide(6500SwitchProblem)

ThisisaspecificsituationthatisvalidonlyinthecaseofaCatalyst6500switchwiththemultilayerswitchfeaturecard(MSFC).TheproblemisthatonesideissendingOSPFHellosthattheothersidedoesnotreceive.ThenetworksetupinFigure9-24showshowthiscanbeaproblem.

Figure9-24NetworkSetupVulnerabletoOSPFNeighborStuckinINITProblemBecauseofBrokenMulticastCapabilities

Thissituationisproducedwhenthecommandsetprotocolfilterenabledisenteredonthe6500switch.Bydefault,theprotocolfilterisdisabled.EnablingthiscommandbeginsalteringthemulticastframetoandfromMSFCandportadapterwithintheFlexWanmoduleofthe6500switch.Figure9-25showstheflowcharttofollowtosolvethisproblem.


Example9-68showstheoutputofshowipospfneighbor.TheneighborisstuckinINIT,andtheswitchinthemiddleis6500withMSFC,asshowninFigure9-24.Example9-68OSPFNeighborStuckinINITState


NeighborIDPriStateDeadTimeAddressInterface131.108.2.11xINIT/-00:00:33131.108.1.1FastEthernet0/0

Solution

Tofixthisproblem,disabletheprotocolfilteron6500switchasfollows:CAT6k(enable)setprotocolfilterdisable

Example9-69showstheOSPFneighborsinFULLstateafterfixingthisproblem.Example9-69VerifyingThattheOSPFNeighborsAreUpAftertheProtocolFilteronthe6500SwitchHasBeenDisabled


NeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/DR00:00:33131.108.1.1FastEthernet0/0

OSPFNeighborStuckinINIT—Cause:Cause:AuthenticationIsEnabledOnlyonOneSide

Whenauthenticationisused,itmustbeenabledonbothsides;otherwise,onesidewillshowtheneighborstuckintheINITstate.Therouterthathasauthenticationenabledwillrejectallthenonauthenticatedpackets,andtheadjacencywillshowstuckinINIT.Theothersidewillnotdetectanyproblembecause

theauthenticationisturnedon,soitwillsimplyignoretheauthenticationinapacketandtreatitasanormalpacket.Figure9-26showstheflowcharttofollowtosolvethisproblem.


Example9-70showstheoutputofdebugipospfadjonR2indicatingthatRouterR2hasplain-textauthenticationenabledbutR1issendingpacketswithoutanyauthentication.Asaresult,R2rejectsthosepackets.Thisisanexampleofplain-textauthentication.IncasesofMD5authentication,thedebugoutputwillsayweusetype2.Example9-70debugipospfadjCommandOutputIndicatesanAuthenticationTypeMismatchontheNeighboringRouter

R2#debugipospfadjOSPFadjacencyeventsdebuggingisonR2#OSPF:Rcvpktfrom131.108.1.1,Ethernet0:MismatchAuthenticationtype.Inputpacketspecifiedtype0,weusetype1

Example9-71showstheconfigurationofR2.TheconfigurationshowsthatR2isusingplain-textauthenticationinarea1.Thisproblemwillreproducewithorwithoutdefiningtheauthenticationkeyundertheinterface.Ifthekeysarenotdefined,therouterusesadefaultkey.

Example9-71R2UsesPlain-TextAuthenticationinArea1

R2#routerospf1network131.108.1.00.0.0.255area1area1authentication

Solution

Tofixthisproblem,enableauthenticationonbothsidesanddefinetheauthenticationkeyonbothsides.Example9-72showsthenewconfigurationforbothR1andR2thatfixesthisproblem.Example9-72ConfiguringAuthenticationonBothRouterstoResolvetheProblem

R2#!interfaceEthernet0ipaddress131.108.1.2255.255.255.0ipospfauthentication-keycisco!routerospf1network131.108.1.00.0.0.255area1area1authentication

R1#!interfaceEthernet0ipaddress131.108.1.1255.255.255.0ipospfauthentication-keycisco!routerospf1network131.108.1.00.0.0.255area1area1authentication

Example9-73showstheneighborstateafterfixingthisproblem.Example9-73showipospfneighborCommandOutputVerifiesThattheAuthenticationFixHasResolvedtheProblem



Similarproblemsoccurinavirtuallinksituation.Whenauthenticationisenabledonbackbonerouters,itisaverycommonmistakenottoenableauthenticationontherouterthatisconnectedtotwodifferentareas.ThisrouterbecomesavirtualABRaftercreatingavirtuallink;therefore,authenticationmustbeenabledforarea0onthatroutereventhougharea0isnotmanuallyconfiguredonit.OSPFNeighborStuckinINIT—Cause:Theframe-relaymap/dialer-mapStatementonOneSideIsMissingthebroadcastKeyword

OSPFusesamulticastaddressof224.0.0.5tosendandreceiveOSPFHellos.IfonesideisincapableofsendingorreceivingHellos,theOSPFneighborwillbestuckintheINITstate.Theimportantthingtonotehereisthatonlyonesidesuffersfromthismulticastproblem.R1seestheneighborinINITstatebutcanseetheneighborHelloswithoutanyproblem.WhenR1sendstheHellotoR2,itneverreachesR2becauseLayer2isincapableofsendinganybroadcastormulticastpackets.Thisisbecauseofthelackof

thebroadcastkeywordinframe-relaymapstatementonR1.AsimilarproblemcanoccurinthecaseofISDNordialerinterfacewhenthedialermapstatementisconfiguredwithoutthebroadcastkeyword.Figure9-27showsthenetworksetupforthediscussionofthisproblem.

Figure9-27NetworkTopologyUsedtoProduceOSPFNeighborStuckinINITProblem



Theoutputofdebugippacket100detailinExample9-74indicatesthattheHellopacketsgeneratedfromR1arenotgettingacrossbecauseofanencapsulationfailure.Example9-74EncapsulationFailureIsPreventingHelloPacketsfromBeingPropagatedfromR1

R1#showaccess-list100ExtendedIPaccesslist100permitip131.108.1.00.0.0.3host224.0.0.5(8matches)

R1#debugippacket100detailIPpacketdebuggingison(detailed)foraccesslist100R1#IP:s=131.108.1.2(Serial0),d=224.0.0.5,len64,rcvd0,proto=89IP:s=131.108.1.1(local),d=224.0.0.5(Serial0),len68,sendingbroad/multicast,proto=89IP:s=131.108.1.1(local),d=224.0.0.5(Serial0),len68,encapsulationfailed,proto=89

Example9-75showstheconfigurationofR1andR2.Theconfigurationshowsthatthebroadcastkeywordismissingfromtheframe-relaymapstatementonR1.R2,however,hasthecorrectframe-relaymapstatement.Example9-75ConfigurationsforR1andR2;R1OmitsthebroadcastKeyword


R2#interfaceSerial0ipaddress131.108.1.2255.255.255.0encapsulationframe-relayframe-relaymapip131.108.1.116broadcast

Solution

Tofixthisproblem,makesurethatthebroadcastkeywordisconfiguredinallframe-relaymapordialer-mapstatements.Example9-76showsthenewconfigurationsofR1andR2tofixtheproblem.Example9-76Correctingtheframe-relaymapStatementonR1toIncludethebroadcastKeyword



Example9-77showsthatOSPFadjacencyisformedacrosstheserialinterfaceusingFrameRelayencapsulationafterfixingthisproblem.Example9-77showipospfneighborCommandOutputIndicatesThattheProblemHasBeenResolved


NeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/BDR00:00:32131.108.1.1Serial0

OSPFNeighborStuckinINIT—Cause:HellosAreGettingLostonOneSideatLayer2

ThissituationhappenswhenthereisaproblemontheLayer2media;forexample,theFrameRelayswitchisblockingthemulticasttrafficforsomereason.WhenR1sendstheHello,R2neverreceivesit.BecauseR2neversawHellosfromR1,theneighborlistofR2willbeempty.However,R1seestheHellosfromR2,whichdoesnotlistR1asavalidneighbor;so,R1declaresthisneighborintheINITstate.Figure9-29showstheflowcharttofollowtosolvethisproblem.


Example9-78showsthedebugippacketdetailoutputonbothR1andR2.Thisdebugisturnedonagainstaccesslist100,whichshowsthatR1issendingandreceivingOSPFHellosbutR2isonlysendingandnotreceivinganyOSPFHellos.Example9-78debugOutputShowsThatR2IsSendingbutNotReceivingAnyOSPFHellosfromR1

R1#showaccess-list100ExtendedIPaccesslist100permitip131.108.1.00.0.0.3host224.0.0.5(8matches)R1#debugippacket100detailIPpacketdebuggingison(detailed)foraccesslist100R1#IP:s=131.108.1.2(Serial0),d=224.0.0.5,len64,rcvd0,proto=89IP:s=131.108.1.1(local),d=224.0.0.5(Serial0),len68,sendingbroad/multicast,

proto=89

R2#showaccess-list100ExtendedIPaccesslist100permitip131.108.1.00.0.0.3host224.0.0.5(8matches)R2#debugippacket100detailIPpacketdebuggingison(detailed)foraccesslist100R1#IP:s=131.108.1.1(local),d=224.0.0.5(Serial0),len68,sendingbroad/multicast,proto=89IP:s=131.108.1.1(local),d=224.0.0.5(Serial0),len68,sendingbroad/multicast,proto=89

R1keepssendingOSPFHellosbutneverreceivesanyHellosfromR2.ThismeansthatR2’sHellosaregettinglostinthemiddlebecausethedebugshowsthatR2issendingaswellasreceivingOSPFHellos.Solution

Thedebugisdoneonbothsides,anditisclearthatbothsidesaresendingHellosbutR1Hellosnevergetacross.Mostlikely,theFrameRelaycloudorotherLayer2mediumisdroppingthismulticastpacket.Thisalsocanbeverifiedbyusingasnifferonthewire.ThesolutionforthisproblemistofixtheLayer2multicastcapabilities,whichisoutofthescopeofthisbook.Onepossibleworkaroundinthissituationhasthefollowingsteps:

Step1Changethenetworktypeonbothsidestononbroadcast.

Step2Configuretheneighborstatementononerouter.

Example9-79showsthenewinterfaceconfigurationthatisusedsothataneighborstatementcanfixthisproblem.Basically,theinterfacehasbeendefinedasnonbroadcast,soaneighborstatementcanbedefined.Whenaneighborstatementisdefined,OSPFsendsaunicastHellopacket.ThisconfigurationalwaysworkswhenthemulticastcapabilitiesofanyLayer2mediaarebroken.Example9-79ChangingtheNetworkTypeonBothSidestoNonbroadcast

R1#interfaceSerial0ipaddress131.108.1.1255.255.255.0encapsulationframe-relayipospfnetworknonbroadcastframe-relaymapip131.108.1.216broadcast

R2#interfaceSerial0ipaddress131.108.1.2255.255.255.0encapsulationframe-relayipospfnetworknonbroadcastframe-relaymapip131.108.1.116broadcast

Example9-80showstheOSPFconfigurationthatconfigurestheneighborstatementsothatOSPFsendsunicastHellopackets.Example9-80ConfiguringneighborStatementSoThatOSPFSendsaUnicastHello

R1#routerospf1network131.108.1.00.0.0.255area1neighbor131.108.1.2

ThissolutionisaworkaroundfortheLayer2problem,butitdoesn’tfixtheoriginalLayer2problem.Bychangingthenetworktypetononbroadcast,asdoneinExample9-79,OSPFwillsendandreceiveHellosasunicastinsteadofmulticast.So,ifanyissuesoccurwithmulticastatLayer2,changingthenetworktypetononbroadcastandconfiguringaneighborstatementcausesOSPFtoformneighborsonamediumwhosemulticastcapabilitiesarebroken.Example9-81showsthattheOSPFadjacencyisformedacrosstheserialinterfaceusingtheneighborcommandwithanonbroadcastnetworktype.Example9-81VerifyingThatUsingaNonbroadcastNetworkTypeResolvestheOSPFNeighborStuckinINITCausedbyaLayer2Issue



Problem:OSPFNeighborStuckin2-WAY—Cause:Priority0IsConfiguredonAllRoutersItisnormalinbroadcastmediatohavea2-WAYstatebecausenoteveryrouterbecomesadjacentonbroadcastmedia.EveryrouterentersintoFULLstatewiththeDRandtheBDR.Inthisexample,thereareonlytworoutersonEthernet;bothareconfiguredwithpriority0.Priority0meansthatthisrouterwillnottakepartinDR/BDRelectionprocess.Thisconfigurationisusefulwhenthereare“low-end”routersonthesegmentandthedesireisnottomakethoselow-endroutersDRs.Forthispurpose,youshouldconfigurepriority0.Bydefault,thepriorityissetto1.ArouterwiththehighestpriorityonasegmentwinsaDRelection.Ifallprioritiesarekepttothedefault,therouterwiththehighestrouterIDbecomestheDR.FormoreinformationonDRandBDRelection,refertoChapter8.IfalltheroutersonanEthernetsegmentareconfiguredwithpriority0,noroutersonthesegmentwillbeinFULLstatewithanyotherrouter.Thiscreatesproblems.Atleastonerouteronthesegmentmusthaveaprioritythatisnotsetto0.Figure9-30showsthenetworksetupsufferingfromthisproblem.

Figure9-30NetworkSetupUsedtoProduceOSPFNeighborStuckin2-WAYProblem



Example9-82showstheoutputofshowipospfneighbor.NoneighborsonthisinterfaceareinFULLstatewitheachother.Example9-82showipospfneighborCommandOutputDeterminesThatNeighborsArein2-WAYStatewithEachOther


NeighborIDPriStateDeadTimeAddressInterface131.108.2.102-WAY/DROTHER00:00:32131.108.1.1Ethernet0

Example9-83showsthatbothR1andR2Ethernetinterfacesareconfiguredwithpriority0.Example9-83PrioritySettingsonEthernet0InterfacesofR1andR2

R1#interfaceEthernet0ipaddress131.108.1.1255.255.255.0ipospfpriority0


ipaddress131.108.1.1255.255.255.0ipospfpriority0

Solution

Tofixthisproblem,removethepriority0commandonatleastoneroutersothatrouterbecomesaDRandformsaFULLadjacency.Example9-84showstheconfigurationchangeonR1thatfixesthisproblem.Example9-84Removingpriority0fromR1SoThatItCanFormFULLAdjacencywithR1

R1#interfaceEthernet0ipaddress131.108.1.1255.255.255.0noipospfpriority0

Example9-85showsthatafterremovingthepriority0commandonR1,theproblemisfixedandOSPFformsanadjacencywithitsneighbor.Example9-85VerifyingThatRemovingpriority0onR1HasFixedtheProblem



Problem:OSPFNeighborStuckinEXSTART/EXCHANGEThisisanimportantstateduringtheOSPFadjacencyprocess.Inthisstate,therouterelectsamasterandaslaveandtheinitialsequencenumber.Thewholedatabasealsoisexchangedduringthisstate.IfaneighborisstuckinEXSTART/EXCHANGEforalongtime,itisanindicationofaproblem.FormoreinformationontheEXSTART/EXCHANGEstate,refertoChapter8.Themostcommonpossiblecausesofthisproblemareasfollows:•MismatchedinterfaceMTU•DuplicaterouterIDsonneighbors•InabilitytopingacrosswithmorethancertainMTUsize•Brokenunicastconnectivitybecauseofthefollowing:

—WrongVC/DLCImappinginFrameRelay/ATMswitch—Accesslistblockingtheunicast—NATtranslatingtheunicast

•Networktypeofpoint-to-pointbetweenPRIandBRI/dialerFigure9-32showstworoutersrunningOSPF.ThissetupproducesthestuckinEXSTART/EXCHANGEprobleminOSPF.

Figure9-32NetworkSetuptoProduceStuckinEXSTART/EXCHANGEProblem

Example9-86showstheoutputofshowipospfneighbor,whichindicatesthattheneighborisstuckinEXSTART/EXCHANGE.

Example9-86showipospfneighborCommandOutputIndicatesThataNeighborIsStuckinEXSTART/EXCHANGE


NeighborIDPriStateDeadTimeAddressInterface131.108.2.11EXSTART/-00:00:33131.108.1.1Serial0

OSPFNeighborStuckinEXSTART/EXCHANGE—Cause:MismatchedInterfaceMTU

OSPFsendstheinterfaceMTUinadatabasedescriptionpacket.IfthereisaMTUmismatch,OSPFwillnotformanadjacency.TheinterfaceMTUoptionwasaddedinRFC2178.Previously,therewasnomechanismtodetecttheinterfaceMTUmismatch.ThisoptionwasaddedinCiscoIOSSoftwareRelease12.0.3andlater.Figure9-33showstheflowcharttofollowtosolvethisproblem.


Example9-87showstheoutputofthedebugipospfadjcommandonR1,whichindicatesthattheneighborMTUishigher.Asaresult,OSPFcan’tformanadjacency.Example9-87debugipospfadjCommandOutputIndicatesaMismatchedInterfaceMTU

R1#debugipospfadjOSPF:RetransmittingDBDto131.108.1.2onSerial0.1OSPF:SendDBDto131.108.1.2onSerial0.1seq0x1E55opt0x2flag0x7len32

OSPF:RcvDBDfrom131.108.1.2onSerial0.1seq0x22ABopt0x2flag0x7len32mtu1500stateEXSTARTOSPF:Nbr131.108.1.2haslargerinterfaceMTU

Example9-88showstheoutputofshowipinterfaceonR1andR2.TheIPinterfaceMTUonR1issetto1400bytes;onR2,itissetto1500bytes.ThiscreatesanMTUmismatchproblem.Example9-88showipinterfaceCommandOutputonR1andR2PinpointstheMTUMismatch

R1#showipinterfaceserial0.1Serial0.1isup,lineprotocolisupInternetaddressis131.108.1.1/24Broadcastaddressis255.255.255.255MTUis1400bytes

R2#showipinterfaceserial0.1Serial0.1isup,lineprotocolisupInternetaddressis131.108.1.2/24Broadcastaddressis255.255.255.255MTUis1500bytes

Solutions

InCiscoIOSSoftwareRelease12.0.3andlater,ifthereisaMTUmismatch,CiscoIOSSoftwarewillindicatethisinadebugmessage,asshowninExample9-87.IfR2’sMTUissmallerthanR1’s,thismessageisnotgenerated.Also,ifR1isnotrunningCiscoIOSSoftwareRelease12.0.3orlater,thismessagedoesnotappearinthedebug.TheonlywaytodetectthisMTUmismatchistochecktheinterfaceconfigurationsonbothsides.Tocorrectthisproblem,makesurethattheMTUissettothesamevalueonbothsides.Example9-89showsthenewconfigurationonR1thatfixesthisproblem.Example9-89SettingtheSameMTUValueonR1

R1#interfaceSerial0.1multipointipaddress141.108.10.3255.255.255.248mtu1500

ThereisanothersituationthatcouldleadtoaMTUmismatch—whenarouterisconnectedthroughFDDItoaswitchwiththerouteswitchmodule(RSM)bladeinit.Figure9-34showsthissetup.

Figure9-34NetworkSetupThatReproducesMTUMismatchProblem

TheVLAN1interfaceisthevirtualEthernetinterfacewiththeMTUof1500bytes,whiletheFDDIinterfaceonR2hastheMTUof4470,asshowninExample9-90.

Example9-90ConfigurationofRSMandR2ShowsMTUMismatch

RSM#showinterfacevlan1Vlan1isup,lineprotocolisupHardwareisCat5kRPVirtualEthernet,addressis0030.f2c9.8338(bia0030.f2)Internetaddressis131.108.1.1/24MTU1500bytes,BW10000Kbit,DLY1000usec,

R2#showinterfacefddi0Fddi0isup,lineprotocolisupHardwareisDASFDDI,addressis0000.0c17.acbf(bia0000.0c17.acbf)Internetaddressis131.108.1.2/24MTU4470bytes,BW100000Kbit,DLY100usec,rely255/255,load1/255

ThisisanormalsetupinaCatalystswitchenvironment.WhenapacketisreceivedonaswitchFDDIport,itgoesacrosstheswitchbackplanetotheslotwheretheRSMisinstalled.Theconversion/fragmentationfromFDDItoEthernethappensattheswitchlevel.WiththeMTUmismatch-detectionfeature,thesetworoutersneverformanadjacency.Forthisparticularsituation,aninterface-levelcommand,ipospfmtu-ignore,wasaddedinCiscoIOSSoftwareRelease12.1.3andlater.ThiscommandignorestheFDDIMTUandformsanadjacencyinthisparticularsituation.ThiscommandmustneverbeusedinanyothersituationbecauseMTUmismatchdetectionisimportantfortroubleshootingpurposes.Tousethiscommand,applyitundertheinterface.Inthisexample,itshouldbeappliedundertheVLAN1interface.Example9-91showstheoutputofshowipospfneighborafterfixingtheMTUproblem.Example9-91VerifyingThattheMTUMismatchHasBeenResolved

R2#showipospfneighborNeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/DR00:00:32131.108.1.1Fddi0

OSPFNeighborStuckinEXSTART/EXCHANGE—Cause:DuplicateRouterIDsonNeighbors

WhenOSPFsendsaDBDpackettoelectamasterandaslave,therouterwiththehighestrouterIDbecomesthemaster.ThishappensintheEXSTARTprocess.Ifthereisanyproblemwithelection,therouterwillbestuckintheEXSTART/EXCHANGEstate.Figure9-35showstheflowcharttofollowtosolvethisproblem.


Example9-92showstheoutputofshowipospfneighboronR1indicatingthattheneighborisstuckintheEXSTARTstate.Example9-92showipospfneighborCommandOutputShowsThatR1IsintheEXSTARTState


NeighborIDPriStateDeadTimeAddressInterface131.108.2.11EXSTART/-00:00:33131.108.1.1Serial0

Example9-93showstheoutputofdebugipospfadj.IftheDBDpacketskeepretransmittingandtheflagvalueremains7,thisisanindicationofaproblem.Thismeansthatneitherroutercandeterminewhichwillbethemasterandwhichwillbeaslave.Aflagisa3-bitvaluethatcomesfromtheDBDpacketformatandrepresentstheI,M,andMSbits.Thevalueoftheflagissetto7inthefirstDBD—thismeansthattheI,M,andMSbitvaluesaresetto1.FormoreinformationontheI,M,andMSbits,refertoChapter8.Example9-93debugOutputShowsThataMasterandSlaveAreNotBeingFormed

R2#debugipospfadjOSPF:RetransmittingDBDto131.108.2.1onSerial0OSPF:SendDBDto131.108.2.1onSerial0seq0x793opt0x2flag0x7len32OSPF:RcvDBDfrom131.108.2.1onSerial0seq0x25F7opt0x2flag0x7len32mtu0state

EXSTARTOSPF:FirstDBDandwearenotSLAVE

Example9-94showstheoutputofshowipospfinterfaceserial0onR2,whichdisplaystherouterIDas131.108.2.1—thesameastheneighbor’s.Thispreventstheelectionofmasterandslave.Example9-94RouterIDofR2IsSameasNeighborR1’s

R2#showipospfinterfaceserial0Serial0isup,lineprotocolisupInternetAddress131.108.1.2/24,Area1ProcessID1,RouterID131.108.2.1,NetworkTypePOINT_TO_POINT,Cost:64

Solution

Example9-93showsthatR2issendingaDBDpacketwithaflagof7,saying,“Iamthemaster.”R2alsoreceivesaDBDfromR1saying,“Iamthemaster.”R2comparesR1’srouterIDandseesthatitisnothigherthanitsown,soitsendstheDBDpackettoR1saying,“Iamthemaster.”So,bothrouterskeepfightingforthemasterstatusandtheroutergetsstuckintheEXSTARTstate.Tosolvethisproblem,carefullyreviewtheneighborrouterIDandthelocalrouterIDtoseeiftheyareexactlythesame.Ifso,youmustchangetherouterIDforoneoftheroutersandrestarttheOSPFprocesssothatitcantakeeffect.

NoteCiscoIOSSoftwareRelease12.0andlaterprovideawarningmessage,OSPF-3-DUP_RTRID,thatwarnsifthereisaduplicaterouterID.

Example9-95showstheoutputofshowipospfneighborafterthisproblemisfixed.Example9-95VerifyingThattheDuplicateRouterIDProblemHasBeenFixedandanOSPFAdjacencyCanBeEstablished

R2#showipospfneighborNeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/-00:00:32131.108.1.1Serial0

OSPFNeighborStuckinEXSTART/EXCHANGE—Cause:Can’tPingAcrosswithMoreThanCertainMTUSize

WhenOSPFbeginsforminganadjacencywithitsneighbor,itgoesthroughseveralstates.InEXSTARTstate,OSPFdetermineswhichwillbethemasterandwhichwillbetheslave.Aftertheroutersdecidedthis,theystartexchangingtheLSAheaderintheformofDBDpackets.Ifthedatabaseishuge,OSPFusestheinterfaceMTUandtriestosendasmuchdataaspossibleuptothelimitoftheinterfaceMTU.IfthereisaproblemwithLayer2acceptinglargepacketsthatarewithintheinterfaceMTUrange,theOSPFadjacencywillbestuckintheEXCHANGEstate.Figure9-36showsthenetworksetupthatreproducesthisproblem.TheLayer2mediumintentionallyisnotshowninthisfigurebecausethisproblemcanhappeninanyLayer2media.

Figure9-36NetworkSetupUsedtoReproduceMTUProblem

Example9-96showstheoutputofshowipospfneighboronR2,whichisstuckintheEXCHANGEstate

withR1ontheseriallink.Thismeansthatthemasterandslavenegotiationalreadyhastakenplace.Example9-96showipospfneighborCommandOutputIndicatesanEXSTARTProblem

R2#showipospfneighborNeighborIDPriStateDeadTimeAddressInterface131.108.2.11EXCHANGE/-00:00:46131.108.1.2Serial0/0



Example9-97showstheoutputofdebugipospfadj.ThedebugshowsthatR2keepsretransmittingtheDBDpacketsevery5seconds,whichisadefault,andisnotreceivinganyreply.Alsonotethatthelengthofthispacketis1274andtheflagvalueis3;thismeansthatR2isamaster.Recallfromthepreviousproblemthataflagof3meansthattheMandMSbitsareset.Example9-97debugipospfadjCommandOutputShowstheDBDPacketTransmissionHistory

R2#debugipospfadjOSPF:SendDBDto131.108.2.1onSerial0seq0x793opt0x2flag0x3len1274OSPF:RetransmittingDBDto131.108.2.1onSerial0OSPF:SendDBDto131.108.2.1onSerial0seq0x793opt0x2flag0x3len1274OSPF:RetransmittingDBDto131.108.2.1onSerial0OSPF:SendDBDto131.108.2.1onSerial0seq0x793opt0x2flag0x3len1274OSPF:RetransmittingDBDto131.108.2.1onSerial0OSPF:SendDBDto131.108.2.1onSerial0seq0x793opt0x2flag0x3len1274

OSPF:RetransmittingDBDto131.108.2.1onSerial0

Example9-98showstheoutputofnormalandextendedpingsfromR1toR2.WhenR1pingsR2withanMTUequaltoorgreaterthan1200,thepingneverreachestheotherside.ThisindicatesaproblematLayer2.Example9-98NormalPingIsSuccessfulandPingwith1,200Fails

R1#ping131.108.1.2

Typeescapesequencetoabort.Sending5,100-byteICMPEchosto131.108.1.2,timeoutis2seconds:!!!!!Successrateis100percent(5/5),round-tripmin/avg/max=1/1/1msR1#

R1#pingipTargetIPaddress:131.108.1.2Repeatcount[5]:Datagramsize[100]:1200Timeoutinseconds[2]:Extendedcommands[n]:Sweeprangeofsizes[n]:Typeescapesequencetoabort.Sending5,1200-byteICMPEchosto131.108.1.2,timeoutis2seconds:.....Successrateis0percent(0/5)R1#

Solution

TheproblemisactuallywithLayer2.R1canpingR2whenusinga100-bytedatagram,butthepingstartsfailingwhenthedatagramsizeisgreaterthan1200bytes.Tosolvethisproblem,fixtheLayer2issue.Onewaytonarrowthisproblemistoconnectthetwodevicesdirectlyinsteadofgoingthroughswitchesandsoforth,toseewhethertheproblemiswiththeLayer2devicesorwiththerouteritself.Ifconnectingroutersbacktobackdoesn’tfixtheproblem,thereisapossibilityofbadhardware.Mosttimes,itturnsouttobeaprobleminthemiddle—forexample,aLANswitchoratelcocloud.Dependinguponthemedia,thereareseveralrecommendations:•InthecaseofaLANmedium

—ChecktheMTUsizedefinedintheswitchconfigurationforthismedium.—Tryusingadifferentport.

•InthecaseofaWANmedium—IfyouaretheWANcloudprovider,checkatwhichhopitfails.—Ifyouaregettingacircuitfromatelco,requestthattheWANcloudinthemiddlebecheckedtoseewhereitfails.

OSPFNeighborStuckinEXSTART/EXCHANGE—Cause:UnicastConnectivityIsBroken

WhenOSPFroutersbeginexchangingdatabaseinformationwitheachother,theysendaunicastpackettoeachotherinEXSTART/EXCHANGEstate.Thishappensonlyifthenetworktypeisnotapoint-to-pointlink.Incasesofapoint-to-pointlink,OSPFsendsallmulticastpackets.Ifunicastconnectivityisbroken,OSPFneighborremainsinEXSTARTstate.



Example9-99showstheoutputofapingfromR1toR2.Theoutputshowsthatapingpacketwith100-bytedatagramsfails.Example9-99PingFailureShowsThatUnicastConnectivityIsBroken

R1#ping131.108.1.2

Typeescapesequencetoabort.Sending5,100-byteICMPEchosto131.108.1.2,timeoutis2seconds:.....Successrateis0percent(0/5)R1#

Solutions

Thispingfailurecouldoccurforseveralreasons,includingthefollowing:•ThewrongDLCIorVPI/VCImappingexistsinaFrameRelayorATMswitch,respectively.•Anaccesslistisblockingtheunicast.•NATistranslatingtheunicast.

WrongDLCIorVPI/VCIMapping

IncasesofFrameRelayorATM,thisisaverycommonproblem.ThepacketwillbelostintheFrame

RelayorATMcloud.Tofurtherverifythatthisisthecase,turnondebugippacketdetailwiththeaccesslistonbothrouters.Example9-100showstheoutputofdebugippacketdetailonbothR1andR2,indicatingthattheICMPpacketisbeingsentintotheFrameRelaycloudbutnothingiscomingback.Example9-100debugippacketdetailCommandOutputIndicatesSuccessfulICMPPacketTransmissionbutNoReceipt

R1#showaccess-list100ExtendedIPaccesslist100permitip131.108.1.00.0.0.255131.108.1.00.0.0.255(10matches)R1#debugippacketdetail100R1#ping131.108.1.2


IP:s=131.108.1.1(local),d=131.108.1.2(Serial0),len100,sendingICMPtype=8,code=0IP:s=131.108.1.1(local),d=131.108.1.2(Serial0),len100,sendingICMPtype=8,code=0IP:s=131.108.1.1(local),d=131.108.1.2(Serial0),len100,sendingICMPtype=8,code=0IP:s=131.108.1.1(local),d=131.108.1.2(Serial0),len100,sendingICMPtype=8,code=0IP:s=131.108.1.1(local),d=131.108.1.2(Serial0),len100,sendingICMPtype=8,code=0R1#

R2#showaccess-list100ExtendedIPaccesslist100permitip131.108.1.00.0.0.255131.108.1.00.0.0.255(10matches)R2#debugippacketdetail100R2#ping131.108.1.1


IP:s=131.108.1.2(local),d=131.108.1.1(Serial0),len100,sendingICMPtype=8,code=0IP:s=131.108.1.2(local),d=131.108.1.1(Serial0),len100,sendingICMPtype=8,code=0IP:s=131.108.1.2(local),d=131.108.1.1(Serial0),len100,sendingICMPtype=8,code=0IP:s=131.108.1.2(local),d=131.108.1.1(Serial0),len100,sendingICMPtype=8,code=0IP:s=131.108.1.2(local),d=131.108.1.1(Serial0),len100,sendingICMPtype=8,code=0R2#

Tosolvethisproblem,thetelephonecarriershouldbecontactedtodeterminewhetheranysuchthinghashappened.Thereisaslightchancethattheproblemcouldbewiththerouteritselfandthatitisdroppingthepacket.Anyotherproblemswillappearinthedebugmessages.ProblemssuchasthewrongFrameRelaymappingwithintherouterproduce“encapsulationfailure”messagesinthedebugoutput.

AccessListBlockingtheUnicast

Ifanaccesslistisconfiguredonarouter,makesurethatit’snotblockingtheunicastpacket.Example9-101showstheoutputofdebugippacketdetail100onR2,whichshowsthattheunicastisbeingblocked.Accesslist101showsthatonlythemulticastpacketsofOSPFareallowedandthatunicastpacketsfromthe131.108.1.0addressaredeniedbecausethereisanimplicitdenyattheendofeachaccesslist.Example9-101RevealingThattheUnicastConnectionIsBeingBlocked

R1#showaccess-list100ExtendedIPaccesslist100permitip131.108.1.00.0.0.255131.108.1.00.0.0.255R1#showaccess-list101ExtendedIPaccesslist101permitip141.108.10.00.0.0.255anypermitip141.108.20.00.0.0.255anypermitip141.108.30.00.0.0.255anypermitip131.108.1.00.0.0.255host224.0.0.5R1#debugippacket100detailIPpacketdebuggingison(detailed)foraccesslist100R1#IP:s=131.108.1.2(Serial0.2),d=131.108.1.1,len100,accessdeniedICMPtype=8,code=0IP:s=131.108.1.1(local),d=131.108.1.2(Serial0.2),len56,sendingICMPtype=3,code=13R1#IP:s=131.108.1.2(Serial0.2),d=131.108.1.1,len100,accessdeniedICMPtype=8,code=0IP:s=131.108.1.1(local),d=131.108.1.2(Serial0.2),len56,sendingICMPtype=3,code=13R1#IP:s=131.108.1.2(Serial0.2),d=131.108.1.1,len100,accessdeniedICMPtype=8,code=0IP:s=131.108.1.1(local),d=131.108.1.2(Serial0.2),len56,sendingICMPtype=3,code=13R1#

Example9-101clearlyshowsthatthepacketisbeingrejectedbecauseoftheaccesslist.Allaccesslistshaveanimplicitdenyattheendofthelist,sotheyalsodenyanypacketnotexplicitlypermitted(inthiscase,unicastpackets).ThiscausesOSPFtogetstuckintheEXCHANGEstate.Tosolvethisproblem,modifyaccesslist101soitallowstheunicastpackets.Example9-102showsthemodifiedaccesslistthatwillsolvetheproblem.Example9-102ModifyinganAccessListtoPermitUnicastPackets

R1#showaccess-list101ExtendedIPaccesslist101permitip141.108.10.00.0.0.255anypermitip141.108.20.00.0.0.255anypermitip141.108.30.00.0.0.255anypermitip131.108.1.00.0.0.255host224.0.0.5permitip131.108.1.00.0.0.255131.108.1.00.0.0.255

NATIsTranslatingtheUnicast

ThisisanothercommonproblemthatoccurswhenNATisconfiguredontherouter.IfNATismisconfigured,itwillstarttranslatingtheunicastpacketcomingtowardit,whichwillbreaktheunicast

connectivity.Example9-103showsthatR1isconfiguredwithNAT.TheoutsideinterfaceofR1isSerial0.2,whichconnectstoR2.Figure9-39showsR1andR2connectedtoeachother,withR1runningNAT.

Figure9-39NetworkinWhichR1IsRunningNAT

WhenR2sendsaunicastpackettoR1,R1triestotranslatethatpacketandR2neverreceivesthepingreply.ThemainthingtowatchforistheaccesslistinNAT.Iftheaccesslistispermittingeverything,thisproblemwilloccur.Example9-98showstheNATconfigurationonR1.Example9-103NATConfigurationResultinginUnicastPacketsBeingTranslated

R1#interfaceEthernet0ipnatoutside!ipnatinsidesourcelist1interfaceSerial0.2overload!access-list1permitany

Tosolvethisproblem,changeaccesslist1andpermitonlythoseIPaddressthatrequiretranslation.Example9-104showsthecorrectaccesslistthatsolvestheproblem.Theaccesslistcouldbedifferentfromnetworktonetwork.Thewholeideaisthattheaccesslistpermitstatementshouldnotcovertheneighbor’sIPaddress.InExample9-104,onlytheinsidenetwork10.0.0.0/8ispermitted.ThismeansthatR1willnolongertranslatethepacketsbelongingtothe131.108.1.0network.Example9-104CorrectingtheAccessListtoSolvetheUnicastConnectivityProblem

R1#interfaceEthernet0ipaddress131.108.1.1255.255.255.0ipnatoutside!ipnatinsidesourcelist1interfaceSerial0.2overload!access-list1permit10.0.0.00.255.255.255

Example9-105showstheoutputofshowipospfneighbor,whichshowsthatOSPFneighborsareintheFULLstateafterfixingtheunicastproblem.Example9-105VerifyingThattheUnicastIssueHasBeenResolved

R2#showipospfneighborNeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/-00:00:32131.108.1.1Ethernet0

OSPFNeighborStuckinEXSTART/EXCHANGE—Cause:NetworkTypeIsPoint-to-PointBetweenPRIandBRI/Dialer

ThenetworktypeonaPRIinterfaceispoint-to-point.ThiscausesOSPFtosendmulticastpacketsevenafterthe2-WAYstate.IfonlyoneBRIcomesupasanOSPFneighbor,itwillworkfine.However,when

multipleBRIstrytoformanadjacencywiththePRI,thePRIwillcomplainbecauseitsnetworktypeispoint-to-point.BecauseallOSPFpacketsaresentasmulticastonapoint-to-pointlink,thePRIreceivesDBDpacketsfrommultipleBRIneighbors,andthiscausesalltheneighborstogetintotheEXSTART/EXCHANGEstate.Figure9-40showsanetworksetupthatproducesthisproblem.R1hasaPRI,andbothR2andR3dialintothisPRI.ThiscreatesaprobleminOSPFbecausethenetworktypeispoint-to-point.

Figure9-40PRItoBRISetupwithNetworkTypePoint-to-Point

Example9-106showstheoutputofshowipospfneighboronR1.R2andR3botharestuckintheEXSTARTstate,withR1onanISDNlink.IftheoutputshowsneighborsintheEXSTARTstate,foralongtime,itisanindicationofaproblem.Example9-106PRINeighborsAreStuckinEXSTARTState

R1#showipospfneighborNeighborIDPriStateDeadTimeAddressInterface131.108.1.21EXSTART/-00:00:38131.108.1.2Serial0/0:23131.108.1.31EXSTART/-00:00:32131.108.1.3Serial0/0:23



Example9-107showstheoutputofshowipospfinterfacebri0onR2indicatingthatthenetworktypeispoint-to-point.Example9-107VerifyingtheNetworkTypeonR2’sbri0Interface

R2#showipospfinterfacebri0BRI0isup,lineprotocolisup(spoofing)InternetAddress131.108.1.2/24,Area2ProcessID1,RouterID131.108.1.2,NetworkTypePOINT_TO_POINT,Cost:1562TransmitDelayis1sec,StatePOINT_TO_POINT,Timerintervalsconfigured,Hello10,Dead40,Wait40,Retransmit5Helloduein00:00:06index1/1,floodqueuelength0

Next0x0(0)/0x0(0)Lastfloodscanlengthis1,maximumis1Lastfloodscantimeis0msec,maximumis0msecNeighborCountis1,Adjacentneighborcountis0Suppresshellofor0neighbor(s)

Example9-108showstheoutputofdebugipospfadjonR2.ThedebugshowsthatR2isreceivingtwodifferentDBDpacketsonapoint-to-pointnetworktype.TheproblemisthatwhenR1sendstheDBDpacketstoR2andR3,itsendsthemasmulticastsbecausethenetworktypeisdefinedaspoint-to-point.Inpoint-to-pointnetworks,allOSPFpacketsaresentasmulticast.ThiscausesR2toreceiveDBDpacketsdestinedforR3,andviceversa.WhenR2receivesaDBDpacket,itcomplainsbecausetheDBDpacket’ssequencenumberandtheflagsaredifferent.ThiscausesR2togobackintotheEXSTARTstate.Thiscyclekeepsrepeating.Example9-108debugOutputShowingThatR2IsReceivingR3’sDBDPackets,WhichCausesProblems

R2#debugipospfadjSendDBDto131.108.1.1onBRI0seq0xB41opt0x42flag0x7len32RcvDBDfrom131.108.1.1onBRI0seq0x1D06opt0x42flag0x7len32mtu1500stateEXSTARTFirstDBDandwearenotSLAVERcvDBDfrom131.108.1.1onBRI0seq0xB41opt0x42flag0x2len92mtu1500stateEXSTARTNBRNegotiationDone.WearetheMASTERSendDBDto131.108.1.1onBRI0seq0xB42opt0x42flag0x3len92Databaserequestto131.108.1.1sentLSREQpacketto131.108.1.1,length12RcvDBDfrom131.108.1.1onBRI0seq0x250opt0x42flag0x7len32mtu1500stateEXCHANGEEXCHANGE-inconsistentinMASTER/SLAVEBadseqreceivedfrom131.108.1.1onBRI0SendDBDto131.108.1.1onBRI0seq0x2441opt0x42flag0x7len32RcvDBDfrom131.108.1.1onBRI0seq0x152Copt0x42flag0x2len92mtu1500stateEXSTARTUnrecognizeddbdforEXSTARTRcvDBDfrom131.108.1.1onBRI0seq0xB42opt0x42flag0x0len32mtu1500stateEXSTARTUnrecognizeddbdforEXSTART

Solution

Tosolvethisproblem,changethenetworktypeofPRIandBRItopoint-to-multipoint.Example9-109showstheinterface-levelcommandtochangethenetworktypetopoint-to-multipoint,followedbytheoutputofshowipospfinterfaceonR2.Example9-109VerifyingtheNetworkTypeonR2’sbri0Interface

R2#interfaceBRI0ipospfnetworkpoint-to-multipoint

R2#showipospfinterfacebri0BRI0isup,lineprotocolisup(spoofing)InternetAddress131.108.1.2/24,Area2ProcessID1,RouterID131.108.1.2,NetworkTypePOINT_TO_MULTIPOINT,Cost:1562TransmitDelayis1sec,StatePOINT_TO_MULTIPOINT,Timerintervalsconfigured,Hello30,Dead120,Wait120,Retransmit5Helloduein00:00:06

index1/1,floodqueuelength0Next0x0(0)/0x0(0)Lastfloodscanlengthis1,maximumis1Lastfloodscantimeis0msec,maximumis0msecNeighborCountis1,Adjacentneighborcountis1Suppresshellofor0neighbor(s)

ThischangemustbemadeonalltheroutersconnectedtotheISDNcloud.Changingthenetworktypetopoint-to-multipointforcesOSPFtosendaunicastpacketforDBDsinsteadofamulticastafter2-WAYstate,sothepacketdestinedforR3neverreachesR2.

Problem:OSPFNeighborStuckinLOADINGThisisarareprobleminOSPFneighborrelationships.WhenaneighborisstuckintheLOADINGstate,thelocalrouterhassentalink-staterequestpackettotheneighborrequestinganoutdatedormissingLSAandiswaitingforanupdatefromitsneighbor.Ifaneighbordoesn’treplyoraneighbors’replyneverreachesthelocalrouter,therouterwillbestuckintheLOADINGstate.Themostcommonpossiblecausesofthisproblemareasfollows:•MismatchedMTU•Corruptedlink-staterequestpacket

Figure9-42showsanetworkwithtworoutersrunningOSPF,withR1experiencingastuckinLOADINGproblem.

Figure9-42NetworkTopologyforOSPFNeighborStuckinLOADINGProblem

Example9-110showstheoutputofshowipospfneighborindicatingthatR2’sneighborisstuckinLOADING.Example9-110showipospfneighborCommandOutputIndicatesNeighborState—LOADING,inThisCase


NeighborIDPriStateDeadTimeAddressInterface131.108.2.11LOADING/-00:00:37131.108.1.1Serial0

OSPFNeighborStuckinLOADING—Cause:MismatchedMTUSize

ThisisauniqueproblemthathappenswhenanMTUmismatchoccurs.IftheMTUsarenotthesameacrossthelink,thisproblemoccurs.Specifically,ifaneighbor’sMTUisgreaterthanthelocalrouter’s,theneighborsendsalargeMTUpacketasalink-stateupdate.Thispacketneverreachesthelocalrouter;asaresult,theneighborgetsstuckintheLOADINGstate.Figure9-42showstheflowcharttofollowtosolvethisproblem.


Example9-111showstheinterfaceconfigurationsonbothR1andR2.BothconfigurationsshowtheMTUvaluedifferentfromeachother’s.Example9-111R1andR2ConfigurationsHaveDifferentMTUValues

R2#showinterfaceSerial0Serial0/0isup,lineprotocolisupHardwareisPQUICCwithFractionalT1CSU/DSUMTU2048bytes,BW256Kbit,DLY20000usec,

R1#showinterfaceATM4/0/0ATM4/0/0isup,lineprotocolisupHardwareiscyBusATMMTU4470bytes,subMTU4470,BW155520Kbit,DLY80usec,

Example9-112showstheCiscoIOSSoftwarereleasethatbothR1andR2arerunning.BecauseR2isrunning11.3(10)T,whichislowerthan12.0.3,itfailstodetectthemismatchedMTU.TheMTUmismatchdetectionwasaddedinRFC2178andwasimplementedinCiscoIOSSoftwareRelease12.0.3andlater.Example9-112VerifyingCiscoIOSSoftwareReleasesUsedonR1andR2

R2#showversion

CiscoInternetworkOperatingSystemSoftwareIOS(tm)C2600Software(C2600-I-M),Version11.3(10)T,RELEASESOFTWARE(fc1)Copyright(c)1986-1999byciscoSystems,Inc.

R1#showversionCiscoInternetworkOperatingSystemSoftwareIOS(tm)RSPSoftware(RSP-JSV-M),Version12.0(7)T,RELEASESOFTWARE(fc2)Copyright(c)1986-1999byciscoSystems,Inc.

Example9-113showstheoutputofdebugipospfadjonR2.ThedebugsshowthatR2continuallyisretransmittingtheDBDpackettoR1,butR1’sreplynevermakesittoR2becausethepacketistoolarge.Example9-113debugipospfadjCommandOutputonR2ShowstheTransmissionHistoryofDBDPacketstoR1

R2#debugipospfadjOSPFadjacencyeventsdebuggingisonR2#OSPF:Retransmittingrequestto131.108.2.1onSerial0OSPF:Databaserequestto131.108.2.1OSPF:sentLSREQpacketto131.108.1.1,length12OSPF:Retransmittingrequestto131.108.2.1onSerial0

Solution

Inthisparticularcase,R2isrunningCiscoIOSSoftwareRelease11.3.10T,whichdoesnotsupportMTUmismatchdetection.R1isrunningCiscoIOSSoftwareRelease12.0.7T,whichdoessupportMTUmismatchdetection.R1detectsMTUmismatchesonlywhenR2’sMTUishigherthanR1’s;otherwise,itdoesnotcomplain.Inotherwords,MTUmismatchdetectionisvalidonlyforaneighborwithanMTUhigherthanthatofthelocalrouter.Inthiscase,R2’sMTUis2048,soeventhoughR1isrunningCiscoIOSSoftwarecodewithMTUmismatchdetection,R1cannotdetectanMTUmismatchbecauseR2’sMTUislowerthanR1’s.WhenR2sendstheLSrequestpacketforthenewinstanceoftheLSAs,R1replieswithanLSAthatexceeds2048,soR2nevergetsthatpacketbecauseitistoolarge.Tofixthisproblem,makesurethattheMTUsonbothsidesmatch.TochangetheMTUonaninterface(inthiscase,R2’sSerial0interface),enterthefollowinginterface-levelcommand:

interfaceserial0mtu4470

Example9-114showstheoutputofshowipospfneighbor,indicatingthatOSPFneighborsareintheFULLstateafterfixingtheunicastproblem.Example9-114VerifyingThatOSPFFormsNeighborAfterFixingtheMTUProblem


OSPFNeighborStuckinLOADING—Cause:Link-StateRequestPacketIsCorrupted

Whenalink-staterequestpacketiscorrupted,theneighbordiscardsthepacketandthelocalrouterneverreceivestheresponsefromtheneighbor.ThiscausestheOSPFneighbortobestuckintheLOADINGstate.Link-staterequestpacketsusuallybecomecorruptedbecauseofthefollowingreasons:

•Adevicebetweentheneighbors,suchasaswitch,iscorruptingthepacket.•Thesendingrouter’spacketisinvalid.Inthiscase,eitherthesendingrouter’sinterfaceisbadortheerroriscausedbyasoftwarebug.•Thereceivingrouteriscalculatingthewrongchecksum.Inthiscase,eitherthereceivingrouter’sinterfaceisbadortheerroriscausedbyasoftwarebug.Thisistheleastlikelycauseofthiserrormessage.



Example9-115showsthelogmessagesonR2indicatingthatR2isreceivinganOSPFpacketwithabadchecksum.Thisisasignofpacketcorruption.Example9-115LogsShowOSPFReceivedBadPackets

R2#showlog%OSPF-4-ERRRCV:Receivedinvalidpacket:BadChecksumfrom131.108.1.1,Serial0%OSPF-4-ERRRCV:Receivedinvalidpacket:BadChecksumfrom131.108.1.1,Serial0

Example9-116showsthatR2isretransmittingtheLSrequestpacketandisnotgettinganyrepliesbecausetherepliesaregettingcorrupted.

Example9-116R2IsNotReceivingRepliestoItsLink-StateRequestPacketsBecauseofPacketCorruption

R2#debugipospfadjOSPFadjacencyeventsdebuggingisonR2#OSPF:Retransmittingrequestto131.108.2.1onSerial0OSPF:Databaserequestto131.108.2.1OSPF:sentLSREQpacketto131.108.1.1,length12OSPF:Retransmittingrequestto131.108.2.1onSerial0

Solution

Mostofthetime,thisproblemisfixedbyreplacinghardware.Thiscouldbeasimplebadportontheswitchorabadinterfacecardonthesending/receivingrouter.Example9-117showstheoutputofshowipospfneighborindicatingthatOSPFneighborsareintheFULLstateafterfixingthecorruptlink-staterequestpacketproblem.Example9-117VerifyingThattheCorruptLink-StateRequestPacketProblemHasBeenResolved,AllowinganOSPFAdjacencytoForm


TroubleshootingOSPFRouteAdvertisementThissectiondiscussestheproblemsrelatedwithOSPFrouteadvertisement.OSPFisalink-stateprotocol.Whenitformsneighborrelationships,itexchangestheentirelink-statedatabasewithitsneighbor(s).Ifanydatabaseinformationisnotsharedwiththeneighbor,thelink-statecharacteristicsofOSPFwillbreak.ThemostcommonreasonsforOSPFtonotsharethedatabaseinformationaboutaspecificlinkareasfollows:•TheOSPFneighborisnotadvertisingroutes.•TheOSPFneighbor(ABR)isnotadvertisingthesummaryroute.•TheOSPFneighborisnotadvertisingexternalroutes.•TheOSPFneighborisnotadvertisingthedefaultroute.

Thesectionsthatfollowaddresstheseproblems,thepossiblecausesforeach,andthesolutionsforresolvingthem.

Problem:OSPFNeighborIsNotAdvertisingRoutesWhenaneighbordoesn’tadvertisearoute,thatroutewillnotshowupinthelocalrouter’sroutingtable.Thismeansthattheneighborhasnotincludedtherouteinitsdatabase;otherwise,thelocalroutermusthavereceivedit.Themostcommonpossiblecausesofthisproblemareasfollows:•OSPFisnotenabledontheinterfacethatissupposedtobeadvertised.•Theadvertisinginterfaceisdown.•Thesecondaryinterfaceisinadifferentareathantheprimaryinterface.

Figure9-45showsanOSPFnetworksetupusedtoproducethisproblem.

Figure9-45OSPFNetworkWhereRoutesAreNotBeingAdvertisedSuccessfully

Example9-118showstheoutputofshowiproute131.108.3.0,whichindicatesthattherouteismissingfromtheroutingtableofR2.Example9-118R2’sRoutingTableIsMissingRoute131.108.3.0

R2#showiproute131.108.3.0%NetworknotintableR2#

OSPFNeighborIsNotAdvertisingRoutes—Cause:OSPFNotEnabledontheInterfaceThatIsSupposedtoBeAdvertised

OSPFincludestheinterfacesubnetaddressinitsdatabaseonlyiftheOSPFisenabledonthatinterface.OSPFmightnotbeenabledonaninterfacebecauseofanincorrectnetworkstatementthatdoesn’tcovertheIPaddressassignedonaninterfaceoramissingnetworkstatementforthatinterfaceaddress.Inboth

cases,OSPFwillexcludetheinterfaceaddressfromitsdatabaseandwillnotadvertisetoitsneighbor.Figure9-46showstheflowcharttofollowtosolvethisproblem.


Example9-119showstheoutputofshowipospfdatabaserouterforR1,whichindicatesthatthenetwork131.108.3.0/24ismissingfromthedatabase.Example9-119R1’sDatabaseIsMissing131.108.3.0

R1#showipospfdatabaserouter131.108.2.1

OSPFRouterwithID(131.108.1.2)(ProcessID1)

RouterLinkStates(Area0)

LSage:301Options:(NoTOS-capability,DC)LSType:RouterLinksLinkStateID:131.108.2.1AdvertisingRouter:131.108.2.1LSSeqNumber:80000148Checksum:0x1672Length:48

NumberofLinks:2




Example9-120showstheoutputofshowipospfinterfacee0onR1,whichindicatesthatOSPFisnotenabledontheinterface.InCiscoIOSSoftwareRelease12.0andlater,theoutputwillnotdisplayanythingifOSPFisnotenabledontheinterface.Example9-120R1DoesNotHaveOSPFEnabledontheEthernet0Interface

R1#showipospfinterfaceEthernet0Ethernet0isup,lineprotocolisupOSPFnotenabledonthisinterface

Example9-121showstheconfigurationofR1,whichshowsthatthenetworkstatementfor131.108.3.0/24ismissingfromtheconfiguration.Example9-121R1’sConfigurationIsMissinganetworkStatementfor131.108.3.0

R1#routerospf1network131.108.1.00.0.0.255area0network131.108.2.00.0.0.255area0

Solution

R1isnotadvertisingitsEthernet0interfaceinitsrouterLSA.ThedatabaseoutputverifiesthattheEthernetsubnetisnotbeingadvertised.TheproblemisthatthenetworkstatementonR1fortheEthernetinterfaceisincorrectorthenetworkstatementismissingfromtheconfiguration.Inthiscase,OSPFwillnotincludethatparticularinterfaceintotherouterLSA;whenR2receivestherouterLSA,thisparticularlinkisnotincludedinit.Tosolvethisproblem,makesurethatthenetworkstatementiscorrectsothatR1includes131.108.3.0/24initsrouterLSA.Example9-122showsthatcorrectconfigurationthatsolvesthisproblem.Example9-122CorrectingR1’sConfigurationtoEnableOSPFon131.108.3.0/24


network131.108.3.00.0.0.255area0

Example9-123showstherouterLSAofR1afterfixingthisproblem.TherouterLSAshows131.108.3.0nowasastublink.Example9-123Network131.108.3.0/24NowAppearsintheOSPFDatabase

1#showipospfdatabaserouter131.108.2.1



LSage:301Options:(NoTOS-capability,DC)LSType:RouterLinksLinkStateID:131.108.2.1AdvertisingRouter:131.108.2.1LSSeqNumber:80000148Checksum:0x1672Length:48NumberofLinks:2


Linkconnectedto:aStubNetwork(LinkID)Network/subnetnumber:131.108.1.0(LinkData)NetworkMask:255.255.255.0NumberofTOSmetrics:0TOS0Metrics:0R



Example9-124showstheoutputofshowiproute131.108.3.0,whichindicatesthatafterfixingthisproblem,therouteshowsupintheroutingtableagain.Example9-124VerifyingThatthe131.108.3.0RouteIsOperationalAgain

R2#showiproute131.108.3.0Routingentryfor131.108.3.0/24Knownvia"ospf1",distance110,metric64,typeintraareaRedistributingviaospf1Lastupdatefrom131.108.1.1onSerial0,04:22:21agoRoutingDescriptorBlocks:*131.108.1.1,from131.108.2.1,04:22:21ago,viaSerial0

Routemetricis64,trafficsharecountis1

OSPFNeighborIsNotAdvertisingRoutes—Cause:AdvertisingInterfaceIsDown

OSPFdoesnotadvertiseanetworkthatisdown.Ifaninterfaceisdown,thenetworkassignedtothatinterfaceisnotadvertisedinarouter’sLSA.Figure9-47showstheflowcharttofollowtosolvethisproblem.


RecallfromFigure9-45thattheEthernet0addressis131.108.3.0/24.Ifthisinterfaceisdown,itwillnotbeadvertisedintheOSPFdatabase.Example9-125showstheoutputofshowipospfinterfaceforEthernet0,whichindicatesthatthelineprotocolisdown.Example9-125showipospfinterfaceCommandOutputDeterminesLineProtocolStatusofEthernet0onR1

R1#showospfinterfaceEthernet0Ethernet0isup,lineprotocolisdownInternetAddress131.108.3.1/24,Area0ProcessID1,RouterID131.108.2.1,NetworkTypeBROADCAST,Cost:10TransmitDelayis1sec,StateDOWN,Priority1

NodesignatedrouteronthisnetworkNobackupdesignatedrouteronthisnetworkTimerintervalsconfigured,Hello10,Dead40,Wait40,Retransmit5

Example9-126showsthattheEthernet0networkaddressof131.108.3.0/24isnotlistedintherouterLSAofR1.Example9-126R1’sEthernet0InterfaceIsMissingfromR1’sLSA








Solution

Tofixthisproblem,bringuptheEthernet0interface.Example9-127showstheinterfacestatisticsafterfixingtheLayer2problem.SomesuggestionsonfixingtheLayer2problemwerediscussedearlierinthischapterinthesection“OSPFNeighborListIsEmpty—Cause:Layer1/2IsDown.”Example9-127VerifyingThattheLineProtocolIsBackUpforanInterface

R1#showipospfinterfaceEthernet0Ethernet0isup,lineprotocolisupInternetAddress131.108.3.1/24,Area0ProcessID1,RouterID131.108.2.1,NetworkTypeBROADCAST,Cost:10

Example9-128showstheoutputofshowiproute131.108.3.0,whichshowsthatafterfixingthisproblem,theroutecamebackintheroutingtable.

Example9-128VerifyingThatthe131.108.3.0RouteIsOperationalAgain

R2#showiproute131.108.3.0Routingentryfor131.108.3.0/24Knownvia"ospf1",distance110,metric64,typeintraareaRedistributingviaospf1Lastupdatefrom131.108.1.1onSerial0,04:22:21agoRoutingDescriptorBlocks:*131.108.1.1,from131.108.2.1,04:22:21ago,viaSerial0Routemetricis64,trafficsharecountis1

R2#

OSPFNeighborIsNotAdvertisingRoutes—Cause:SecondaryInterfaceIsinaDifferentAreaThanthePrimaryInterface

Whendealingwithsecondaryaddresses,OSPFrequiresthesecondaryaddresstobelongtothesameareaastheprimaryaddress.Ifthisisnotfollowed,OSPFwillnotadvertisethesecondaryaddressinitsrouterLSA.Figure9-48showsthenetworksetupusedtoproducethisproblem.

Figure9-48OSPFNetworkSetupUsedtoProduceSecondaryAddress/LSAProblems



Example9-129showstherouterLSAinformationofR1.TheLSAshowsthat131.108.3.0/24isnotincludedinthedatabase.R1generatestherouterLSAforarea2,butbecausethesecondaryaddressistheonlyaddressinarea2,thenumberofthelinkis0.Thisisbecausethesecondaryinterfaceaddresscannotbeputintoaseparateareathantheprimaryinterfaceaddress.Example9-129DisplayingR1’sRouterLSAInformation









LSage:39Options:(NoTOS-capability,DC)LSType:RouterLinksLinkStateID:131.108.2.1AdvertisingRouter:131.108.2.1LSSeqNumber:800001B0Checksum:0x46E4Length:24NumberofLinks:0

Example9-130showstheconfigurationofR1,whichshowsthattheprimaryandsecondaryaddressareincludedindifferentareas.Example9-130R1’sPrimaryandSecondaryAddressConfigurations

R1#interfaceEthernet0ipaddress131.108.3.1255.255.255.0secondaryipaddress131.108.2.1255.255.255.0!routerospf1network131.108.1.00.0.0.255area0network131.108.2.00.0.0.255area0network131.108.3.00.0.0.255area2

Solution

Tofixthisproblem,changetheconfigurationonR1sothatthesecondaryaddressalsobelongstoarea0.Example9-131showstheconfigurationonR1,whichshowsthatthesecondaryaddressisincludedintheareaastheprimaryaddress.Example9-131ConfiguringR1’sSecondaryAddresstoBeintheSameAreaasthePrimaryAddress

R1#interfaceEthernet0ipaddress131.108.3.1255.255.255.0secondaryipaddress131.108.2.1255.255.255.0!routerospf1network131.108.1.00.0.0.255area0network131.108.2.00.0.0.255area0network131.108.3.00.0.0.255area0

Example9-132showstheoutputofshowiproute131.108.3.0,whichshowsthatafterfixingthisproblem,theroutecamebackintheroutingtable.Example9-132VerifyingThatthe131.108.3.0RouteIsBeingAdvertisedAgain


R2#

Problem:OSPFNeighbor(ABR)NotAdvertisingtheSummaryRouteWhenOSPFisconfiguredwithmorethanonearea,oneareahastobeabackbonearea.TherouterthatsitsattheborderofthebackboneandanyotherareaistheABR.TheABRgeneratesthesummaryLSAforoneareaandsendsittoanotherarea.WhentheABRfailstogeneratethesummaryLSA,theareasbecomeisolatedfromeachother.Themostcommonpossiblecausesofthisproblemareasfollows:•Anareaisconfiguredasatotallystubbyarea.•AnABRisnotconnectedtoarea0.•Adiscontiguousarea0exists.

OSPFNeighbor(ABR)NotAdvertisingtheSummaryRoute—Cause:AreaIsConfiguredasTotallyStubbyArea

Whenanareaisconfiguredasastubbyarea,noexternalLSAcanbeleakedintothatarea.Similarly,anareacanbeconfiguredasatotallystubbyarea,whichmeansthatnoexternalorsummaryLSAscanbeleakedintothisarea.Figure9-50showsanOSPFnetworksetupusedtoproducethisproblem.R1isanABR,andarea2isdefinedasatotallystubbyarea.

Figure9-50NetworkSetupUsedtoProduceThisProblem



Example9-133showstheconfigurationofR1thatshowsarea2configuredasatotallystubbyarea.Example9-133R1ConfigurationShowsAreaTypes

R1#routerospf1network131.108.1.00.0.0.255area2network131.108.2.00.0.0.255area3network131.108.3.00.0.0.255area0area2stubno-summary

Example9-134showstheoutputofshowipospfdatabasesummaryfor131.108.2.0,whichindicatesthatthesummaryLSAisgeneratedonlyinarea0andnotinarea2.Example9-134showipospfdatabasesummaryCommandOutputShowsSummaryLSAInformation

R1#showospfdatabasesummary131.108.2.0


SummaryNetLinkStates(Area0)LSage:58Options:(NoTOS-capability,DC)LSType:SummaryLinks(Network)LinkStateID:131.108.2.0(summaryNetworkNumber)AdvertisingRouter:131.108.3.1LSSeqNumber:8000000EChecksum:0x4042Length:28NetworkMask:/24TOS:0Metric:1

Solution

Inthisexample,area2isconfiguredasatotallystubbyarea,sonosummaryLSAisoriginatedforthisareabytheABR.Ifthereisonlyasingleexitpoint,thereisnoneedtoreceivespecificsummaryLSAsinanarea;thedefaultsummaryLSAof0.0.0.0issufficient.ThisisalsotrueinthecaseofatotallystubbyNSSAarea.Becausethisisnormalbehavior,nosolutionisgivenforthis.However,ifmultipleABRsexistforthisareaandreceivingaspecificsummaryLSAisnecessarytoavoidsuboptimalrouting,justremovetheno-summarykeywordfromthearea2configurationonABR.Thiswillmakearea2astubandallthesummaryLSAswillbeleakedintothisarea.OSPFNeighbor(ABR)NotAdvertisingtheSummaryRoute—Cause:ABRIsNotConnectedtoArea0

Whenarouterisconnectedtomorethanonearea,oneofthoseareasmustbearea0.TheABRwillnotgeneratesummaryLSAsifitisnotconnectedtoarea0.ThisisstandardOSPFbehavior.Figure9-52showsanOSPFnetworkexperiencingthisproblem.R1isbetweenarea2andarea3,butitisnotconnectedtoarea0.

Figure9-52OSPFNetworkinWhichtheABRIsNotConnectedtoArea0



Example9-135showsthatR1isnotoriginatingasummary.Example9-135R1IsNotOriginatingaSummaryRoute

R1#showipospfdatabasesummary


R1#

Example9-136showstheconfigurationonR1,whichshowsthatR1isnotconnectedtoarea0.Example9-136R1’sConfigurationIndicatesThatItIsNotConnectedtoArea0

routerR1#routerospf1network131.108.1.00.0.0.255area2network131.108.3.00.0.0.255area3

Thereisanotherwaytoseewhetheranareaisconnectedtothebackbone.Example9-137showstheoutputofshowipospf.Ifthisrouterwereconnectedtoarea0,theoutputwouldsay“Itisanareaborderrouter.”Example9-137showipospfCommandOutputIndicatesWhethertheRouterIsanABR

R1#showipospfRoutingProcess"ospf1"withID131.108.3.1SupportsonlysingleTOS(TOS0)routes

SPFscheduledelay5secs,HoldtimebetweentwoSPFs10secsMinimumLSAinterval5secs.MinimumLSAarrival1secs

Solution

Tosolvethisproblem,createabackbonearea.AfterabackboneareaiscreatedonR1,itwillstartgeneratingsummaryLSAs.Ifnoarea0existsinthenetwork,oneoftheareasmustbechangedtoarea0forOSPFtoworkproperly.Example9-138showsthenewconfiguration,whichshowsthatR1nowisconnectedtoarea0byremoving131.108.3.0fromarea3andputtingitintoarea0.Example9-138ConfiguringR1toConnecttoArea0


Ifabackboneareaalreadyexists,createavirtuallinkbetweenthenearestABRandR1,asshowninExample9-139.Example9-139CreatingaVirtualLinkBetweenR1andtheNearestABR

R1#routerospf1network131.108.1.00.0.0.255area2network131.108.3.00.0.0.255area3area2virtual-link141.108.1.1

Example9-140showstheoutputofshowipospf,whichnowshowsR1asanABR.Example9-140VerifyingThatR1IsanABR

R1#showipospfRoutingProcess"ospf1"withID131.108.3.1SupportsonlysingleTOS(TOS0)routesItisanareaborderrouterSPFscheduledelay5secs,HoldtimebetweentwoSPFs10secsMinimumLSAinterval5secs.MinimumLSAarrival1secs

Example9-141showsthatR1startsgeneratingthesummaryLSA.Example9-141VerifyingThatR1IsGeneratingaSummaryLSA

R1#showipospfdatabasesummary


SummaryNetLinkStates(Area0)

LSage:58Options:(NoTOS-capability,DC)LSType:SummaryLinks(Network)LinkStateID:131.108.1.0(summaryNetworkNumber)AdvertisingRouter:131.108.3.1LSSeqNumber:8000000EChecksum:0x4042

Length:28NetworkMask:/24TOS:0Metric:1

SummaryNetLinkStates(Area2)

LSage:58Options:(NoTOS-capability,DC)LSType:SummaryLinks(Network)LinkStateID:131.108.3.0(summaryNetworkNumber)AdvertisingRouter:131.108.3.1LSSeqNumber:8000000EChecksum:0x4042Length:28NetworkMask:/24TOS:0Metric:1

OSPFNeighbor(ABR)NotAdvertisingtheSummaryRoute—Cause:DiscontiguousArea0

Figure9-54showsanOSPFnetworkexperiencingthisproblem.ThelinkbetweenR1andR2isbroken,whichmakesarea0discontiguous.

Figure9-54OSPFNetworkwithaDiscontiguousArea0



Example9-142showstheroutingtableofABR2.Theroute131.108.1.0/24showsupintheroutingtableasaninterarearoute.Theroute131.108.1.0trulyexistsinthebackbonearea,butbecausethebackbonehasbecomediscontiguous,thisrouteiscomingtoABR2througharea2asaninterarearoute.TheABR2willnotgeneratethesummaryLSAforthisroutebecauseit’saninterarearoute.Example9-142ABR2IsReceivingthe131.108.1.0/24RouteasanInterareaRouteBecauseofaDiscontiguousBackbone

ABR2#showiproute131.108.1.0Routingentryfor131.108.1.0/24Knownvia"ospf1",distance110,metric129,typeinterareaRedistributingviaospf1Lastupdatefrom131.108.0.1onSerial0.1,00:56:02agoRoutingDescriptorBlocks:*131.108.0.1,from131.108.3.1,00:56:02ago,viaSerial0.1Routemetricis129,trafficsharecountis1

Example9-143showsthatABR2isnotgeneratingasummaryLSAforthisrouteintoarea0.Example9-143NoSummaryLSAIsGeneratedfor131.108.1.0intoArea0

ABR2#showipospfdatabasesummary131.108.1.0


ABR2#

Solution

Thisisobviouslyabaddesign.Thebackbonesareattachedtoeachotherthroughonelink.Ifthatlinkfails,thebackbonebecomesdiscontiguous.ABR2receivestheinterarearoutefromABR1anddoesn’tcreatesummaryLSAsforthoseroutes.ThisisinaccordancewithOSPFRFC2328thatasummaryLSAshouldnotbeinjectedintothebackboneforinterarearoutes.InjectingasummaryLSAintothebackboneforinterarearoutersisolatesthebackbonesfromeachother.Tofixthisproblem,besuretoavoidasinglepointoffailure,asshowninthisexample,thatcouldmakeabackboneareadiscontiguous.AnothersolutionistocreateavirtuallinkbetweenABR1andABR2.Aftercreatingthevirtuallink,thearea0databaseofABR1andABR2willbesynchronizedoverthevirtuallink.ItwilllookexactlyasiftherewereaphysicallinkbetweenABR1andABR2andthatlinkwereinarea0.TheonlydifferenceisthatbothABR1andABR2wouldusearea2toforwardtheOSPFpackets.Formoreinformationonvirtuallinks,referbacktoChapter8.Example9-144showstheconfigurationofbothABR1andABR2,whichshowsthatavirtuallinkisconfiguredtomakearea0contiguous.Example9-144ConfiguringABR1andABR2withaVirtualLink

ABR1#routerospf1network131.108.0.00.0.0.255area2network131.108.3.00.0.0.255area0area2virtual-link131.108.4.1

ABR2#routerospf1network131.108.0.00.0.0.255area2network131.108.4.00.0.0.255area0area2virtual-link131.108.3.1

Avirtuallinkisconfiguredfirstbydefiningthetransitarea.ThisistheareathatiscommonbetweenthetwoABRs.ThisareaisusedtoformavirtualadjacencybetweenthetwoABRs.Inthisexample,itisarea2.OnABR1,thecommanddefinedunderrouterOSPFisarea2virtual-link131.108.4.1.Theaddress131.108.4.1istherouterIDofABR2.Similarly,theaddress131.108.3.1istherouterIDofABR1.TherouterIDisthehighestIPaddressonthebox—or,ifaloopbackexists,theloopbackbecomestherouterID.ItishighlyrecommendedthatyoudefinealoopbackaddresssothatitwillbeelectedasarouterID.Onegoodreasonisthat,ifalinkiselectedasarouterIDinsteadofaloopbackandthatlinkgoesdown,therouterIDwillbechanged.WhenarouterIDchanges,itbreaksthevirtuallinkalso.Ontheotherhand,ifaloopbackisdefinedasarouterID,therouterIDalwayswillbethesame.Example9-145showsthataftercreatingthevirtuallink,ABR2startsreceivingrouterLSAsforarea0thatincludethislink131.108.1.0/24.Example9-145VerifyingThatABR2ReceivesRouterLSAsforArea0,Includingthe131.108.1.0/24Link

ABR2#showipospfdatabaserouter131.108.1.1



RoutingBitSetonthisLSALSage:6(DoNotAge)Options:(NoTOS-capability,DC)LSType:RouterLinksLinkStateID:131.108.1.1AdvertisingRouter:131.108.1.1LSSeqNumber:80000002Checksum:0xC375Length:48NumberofLinks:3

Linkconnectedto:apoint-to-pointLink(LinkID)NeighboringRouterID:131.108.3.1(LinkData)RouterInterfaceaddress:131.108.3.2NumberofTOSmetrics:0TOS0Metrics:64



Example9-146showsthatR2startsreceivingintra-arearoutesfor131.108.1.0/24afterthevirtuallinkiscreated.Example9-146VerifyingThatR2ReceivesIntra-AreaRoutesfor131.108.1.0/24

ABR2#showiproute131.108.1.0Routingentryfor131.108.1.0/24Knownvia"ospf1",distance110,metric193,typeintraareaRedistributingviaospf1Lastupdatefrom131.108.4.1onSerial0.1,00:56:02agoRoutingDescriptorBlocks:*131.108.4.1,from131.108.4.1,00:56:02ago,viaSerial0.1Routemetricis193,trafficsharecountis1

Problem:OSPFNeighborIsNotAdvertisingExternalRoutesWheneverthereisaredistributioninOSPF,itgeneratesanexternalLSA(Type5)thatisfloodedthroughouttheOSPFnetwork.ExternalLSAsarenotleakedintostub,totallystubby,andNSSAareas.Themostcommonpossiblecausesofthisproblemareasfollows:•TheareaisconfiguredasastuborNSSA.•TheNSSAABRisnottranslatingType7intoType5LSA.

OSPFNeighborIsNotAdvertisingExternalRoutes—Cause:AreaIsConfiguredasaStubAreaorNSSA

InOSPF,Type5LSAsarenotallowedinastuborNSSAarea.WhenenteringtheredistributecommandonarouterthatiscompletelyinastuborNSSAarea,awarningmessageisdisplayed.Thisredistribute

commandintheconfigurationisincapableofimportinganyexternalLSAsintoastuborNSSAarea.Figure9-56showstheflowcharttofollowtosolvethisproblem.


Example9-147showstheconfigurationerrorwhentryingtoredistributeintoOSPFfromanotherroutingprotocolonarouterinastubarea.Example9-147ErrorsCausedbyRedistributingintoOSPFonaStubAreaRouter

R1(config)#routerospf1R1(config-router)#redistributeripsubnetsWarning:RouteriscurrentlyanASBRwhilehavingonlyoneareawhichisastubarea

Example9-148showstheconfigurationonR1.EventhoughRIPisbeingredistributed,R1willnotgenerateType5LSAsforRIPsubnetsbecauseR1iscompletelyinastubarea.FormoreinformationonType5LSAs,refertoChapter8.Example9-148RedistributingRIPintoOSPFWhileanOSPFAreaIsDefinedasaStub

R1#routerospf1redistributeripsubnetsnetwork131.108.1.00.0.0.255area2network131.108.2.00.0.0.255area2area2stub

Example9-149showsthatnoexternalLSAsaregeneratedbyR1becauseR1iscompletelyinastubarea.R1willignoretheredistributioncommand.Example9-149NoExternalLSAsAreGeneratedbyR1

R1#showipospfdatabaseexternal132.108.3.0


R1#

Solution

Thisproblemcanbesolvedintwoways.Onesolutionistomakearea2anormalareabytakingoutthearea2stubcommandonalltheroutersinarea2.Thisisnotagoodsolutionbecausesometimes,astubareadoesnotrequireexternalLSAs.ThesecondsolutionisapreferredsolutionthatinvolveschangingtheentireareaasanNSSA.AnNSSApermitsredistributionofexternalroutes.However,theNSSAwillnotgenerateType5LSAs.ItwillgenerateType7LSAs,whichwillbeconvertedtoType5LSAsbytheNSSAABR.Chapter8explainsNSSAsinmoredetail.Example9-150showstheconfigurationthatconvertsastubareaintoanNSSA.TheareaidnssacommandmustbeissuedonallroutersintheNSSA.Example9-150ConvertingaStubAreatoanNSSAtoPermitRedistributionofExternalRoutes

R1#routerospf1redistributeripsubnetsnetwork131.108.1.00.0.0.255area2network131.108.2.00.0.0.255area2area2nssa

Example9-151showsthatR1isgeneratingType7LSAsfortwoRIProutesintotheNSSAarea.TheNSSAABRconvertstheseType7LSAsfurtherintoType5LSAs,whichthencanbefloodedtotherestoftheOSPFdomain.Example9-151ShowingOSPFGeneratingType7LSAsforRIPRoutes

R1#showipospfdatabasenssa-external132.108.3.0


Type-7ASExternalLinkStates(Area2)

LSage:1161Options:(NoTOS-capability,Type7/5translation,DC)LSType:ASExternalLinkLinkStateID:132.108.3.0(ExternalNetworkNumber)AdvertisingRouter:131.108.2.1LSSeqNumber:80000001Checksum:0x550Length:36NetworkMask:/24MetricType:2(Largerthananylinkstatepath)TOS:0Metric:1

ForwardAddress:0.0.0.0ExternalRouteTag:1

R1#




LSage:1161Options:(NoTOS-capability,Type7/5translation,DC)LSType:ASExternalLinkLinkStateID:132.108.4.0(ExternalNetworkNumber)AdvertisingRouter:131.108.2.1LSSeqNumber:80000001Checksum:0x550Length:36NetworkMask:/24MetricType:2(Largerthananylinkstatepath)TOS:0Metric:1ForwardAddress:0.0.0.0ExternalRouteTag:1

R1#

OSPFNeighborIsNotAdvertisingExternalRoutes—Cause:NSSAABRNotTranslatingType7LSAsintoType5LSAs

NSSARFC1587statesthatbeforeNSSAABRconvertsfromType7intoType5,allNSSAABRsmustexamineallNSSAABRsforaparticularNSSA.TheABRwiththehighestrouterIDmustdotheconversionofType7intoType5.IfType7isnottranslatedintoType5bytheNSSAABR,noroutersoutsideofNSSAbecomeawareoftheexternalrouteredistributionthatishappeningwithintheNSSA.ThisdefeatstheentirepurposeofNSSA.Figure9-57showsanOSPFnetworkexperiencingthisproblem.Router2isanNSSAABR,butit’snotconvertingType7LSAsintoType5LSAs.

Figure9-57OSPFNetworkinWhichOSPFNeighborR2IsNotAdvertisingExternalRoutesintoArea0



Example9-152showstheoutputofshowipospfdatabasenssa-externalonroute132.108.4.0,indicatingthatR2isgeneratingType7LSAs.Example9-152showipospfdatabasenssa-externalCommandOutputIndicatesThatType7IsBeing

Generated




LSage:1161Options:(NoTOS-capability,Type7/5translation,DC)LSType:ASExternalLinkLinkStateID:132.108.4.0(ExternalNetworkNumber)AdvertisingRouter:131.108.1.2LSSeqNumber:80000001Checksum:0x550Length:36NetworkMask:/24MetricType:2(Largerthananylinkstatepath)TOS:0Metric:1ForwardAddress:0.0.0.0ExternalRouteTag:1

Example9-153showstheoutputoftheshowipospfdatabaseexternalcommandfor132.108.4.0,whichindicatesthatR2isnotconvertingType7LSAsintoType5LSAs.Example9-153showipospfdatabaseexternalCommandOutputIndicatesThatConversionofType7toType5IsNotOccurring


OSPFRouterwithID(131.1081.2)(ProcessID1)

R2#

Example9-154showsthatR2isanNSSAABR,soitissupposedtodotheconversion.Example9-154VerifyingThatR2IsanNSSAABR,SubjecttoType7-to-Type5LSAConversion

R2#showipospfRoutingProcess"ospf1"withID131.108.1.2SupportsonlysingleTOS(TOS0)routesItisanareaborderrouterSPFscheduledelay5secs,HoldtimebetweentwoSPFs10secsMinimumLSAinterval5secs.MinimumLSAarrival1secsNumberofexternalLSA3.ChecksumSum0x14DAANumberofDCbitlessexternalLSA0NumberofDoNotAgeexternalLSA0Numberofareasinthisrouteris4.3normal0stub1nssaAreaBACKBONE(0)Numberofinterfacesinthisareais2AreahasnoauthenticationSPFalgorithmexecuted60timesArearangesareNumberofLSA16.ChecksumSum0x9360DNumberofDCbitlessLSA7NumberofindicationLSA0NumberofDoNotAgeLSA0Area2Numberofinterfacesinthisareais1

ItisaNSSAareaPerformtype-7/type-5LSAtranslationAreahasnoauthenticationSPFalgorithmexecuted54timesArearangesareNumberofLSA11.ChecksumSum0x7A449NumberofDCbitlessLSA0NumberofindicationLSA0NumberofDoNotAgeLSA0

Example9-155showsanotherrouterintheNSSAarea,R1,whichalsoclaimstobeanABR.ThisrouterisafakeABRbecauseitisnotconnectedtoarea0.Example9-155showipospfCommandOutputIndicatesThatR1ClaimstoBeanABR

R1#showipospfRoutingProcess"ospf1"withID131.108.2.1SupportsonlysingleTOS(TOS0)routesItisanareaborderrouterSummaryLinkupdateintervalis00:30:00andtheupdateduein00:29:48ExternalLinkupdateintervalis00:30:00andtheupdateduein00:19:43SPFscheduledelay5secs,HoldtimebetweentwoSPFs10secsNumberofDCbitlessexternalLSA0NumberofDoNotAgeexternalLSA0Numberofareasinthisrouteris2.1normal0stub1nssaAreaBACKBONE(0)(Inactive)Numberofinterfacesinthisareais1AreahasnoauthenticationSPFalgorithmexecuted2timesArearangesareLinkStateUpdateIntervalis00:30:00andduein00:29:47LinkStateAgeIntervalis00:20:00andduein00:19:47NumberofDCbitlessLSA0NumberofindicationLSA0NumberofDoNotAgeLSA0Area2Numberofinterfacesinthisareais1ItisaNSSAareaAreahasnoauthenticationSPFalgorithmexecuted65timesArearangesareLinkStateUpdateIntervalis00:30:00andduein00:16:27LinkStateAgeIntervalis00:20:00andduein00:14:39NumberofDCbitlessLSA0NumberofindicationLSA0NumberofDoNotAgeLSA0

Example9-156showsthatR1isdoingalltheconversioninsteadofR2.Example9-156R1PerformsType7-to-Type5LSAConversionInsteadofR2



Type-5ASExternalLinkStates

LSage:1161Options:(NoTOS-capability,DC)LSType:ASExternalLink

LinkStateID:132.108.3.0(ExternalNetworkNumber)AdvertisingRouter:131.108.2.1LSSeqNumber:80000001Checksum:0x550Length:36NetworkMask:/24MetricType:2(Largerthananylinkstatepath)TOS:0Metric:1ForwardAddress:0.0.0.0ExternalRouteTag:1

R1#




LSage:1161Options:(NoTOS-capability,DC)LSType:ASExternalLinkLinkStateID:132.108.4.0(ExternalNetworkNumber)AdvertisingRouter:131.108.2.1LSSeqNumber:80000001Checksum:0x550Length:36NetworkMask:/24MetricType:2(Largerthananylinkstatepath)TOS:0Metric:1ForwardAddress:0.0.0.0ExternalRouteTag:1

R1#

Example9-157showstheOSPFconfigurationonR1.AnetworkstatementonR1includesoneinterfaceofR1inarea0.ThisnetworkstatementiscausingproblemsbecausenoneoftheinterfacesonR1belongstothebackbone.Example9-157R1’sConfigurationShowsOneInterfaceinArea0

R1#routerospf1network131.108.1.00.0.0.255area2network131.108.2.00.0.0.255area2network131.108.5.00.0.0.255area0area2nssa

Solution

Inthiscase,R1hasarouterID(RID)of131.108.2.1andR2hasarouterIDof131.108.1.2,asshownintheoutputofExamples9-154and9-155.BecauseR1hasahigherRIDthanR2,R1doestheconversionandtheType5LSAgoesintoablackhole.Youcanresolvethisproblemusingmultiplesolutions:•Removethewrongnetworkstatement.•ChangetherouterIDofR1sothatitislowerthanR2’s.

•ChangetherouterIDofR2sothatitishigherthanR1’s.Example9-158showstheeasiestsolution,whichistoremovetheincorrectnetworkstatement.Example9-158CorrectingthenetworkStatementonR1soThatR2PerformstheType7-to-Type5LSAConversion

R1#routerospf1network131.108.1.00.0.0.255area2network131.108.2.00.0.0.255area2nonetwork131.108.5.00.0.0.255area0area2nssa

TheothersolutionistoaltertherouterIDofR1orR2sothateitherR1’sislowerthanR2’sorR2’sishigherthanR1’s.TochangetherouterID,configuretheloopbackinterfaceofR1withalowerIPaddressthanR2’sloopback,andthenrestarttheOSPFprocess.RestartingOSPFwillcausenetworkdowntimeforfewseconds.ThefasteryouentertheOSPFconfigurationbackontherouter,thelessdowntimetherewillbe.InCiscoIOSSoftwareRelease12.0andlater,acommandhasbeenaddedtoconfiguretherouterIDmanuallyandthenrestartOSPF.Example9-159showshowtochangetherouterIDwithCiscoIOSSoftwareRelease12.0.Example9-159ChangingtheRouterIDofR1toBeLowerThanR2’s

R2(config)#routerospf1R2(config-router)#router-id131.108.0.1R2(config-router)#endR2#clearipospfprocess

Example9-160showsthatafterfixingtheconfiguration,R2startsconvertingType7LSAsintoType5LSAsproperly.TheoutputofshowipospfdatabaseexternalonR2showsthatitisgeneratingType5LSAsandthatR1isreceivingType5LSAs.Example9-160ConfirmingThattheLSATypeConversionProblemHasBeenResolved



+Type-5ASExternalLinkStates


R1#





R1#

Problem:OSPFNeighborNotAdvertisingDefaultRoutesSometimes,OSPFusesadefaultroutefordestinationsthatareunknowntoOSPF.Mostofthetime,thesedestinationsarenetworksexternaltoOSPF.InsteadofimportingalltheexternalroutesintoOSPF,justonedefaultrouteisneededthatwillbeusedforallunknownexternaldestinations.Intheabsenceofsuchadefaultroute,allthetrafficdestinedforanyunknownaddresswillbedroppedbyOSPF.ThemostcommonpossiblecausesforanOSPFrouternottoadvertisethedefaultrouteareasfollows:•Thedefault-informationoriginatecommandismissing.•Thedefaultrouteismissingfromtheneighbor’sroutingtable.•Aneighboristryingtooriginateadefaultintoastubarea.•TheNSSAABR/ASBRisnotoriginatingtheType7default.

OSPFNeighborNotAdvertisingDefaultRoutes—Cause:Missingdefault-informationoriginateCommands

OSPFdoesnotoriginatethedefaultrouteunlesstheOSPFdefault-informationoriginatecommandispresentintheOSPFconfiguration.Thiscommandoriginatesthedefaultrouteontherouteronwhichitisconfigured.ThereisnootherwayinOSPFtogeneratethedefaultroute.Figure9-59showsanetworksetupthatproducesthisproblem.

Figure9-59NetworkSetupThatProducesThisProblem



Example9-161showsthatR1isreceivingadefaultroutethroughRIP.ThisisimportantbecauseifR1,whichistheoriginatorofadefaultroute,doesnothavethedefaultroute,itcan’tgenerateadefaultrouteinOSPF.Example9-161R1ReceivesaDefaultRouteThroughRIP

R1#showiproute0.0.0.0Routingentryfor0.0.0.0/0,supernetKnownvia"rip",distance120,metric1,candidatedefaultpathRedistributingviaripLastupdatefrom132.108.0.2onSerial0,00:00:16agoRoutingDescriptorBlocks:132.108.0.2,from132.108.0.2,00:00:16ago,viaSerial0Routemetricis1,trafficsharecountis1

Example9-162showstheconfigurationofR1illustratingthatR1isredistributingalltheRIProutesintoOSPF.Asmentionedinthebeginningofthisproblem,theonlywaytooriginateadefaultinOSPFisthroughthedefault-informationoriginatecommand.So,redistributionofadefaultroutewillnotcause

OSPFtogeneratethedefaultroute.Example9-162R1RedistributesAllRIPRoutesintoOSPF

R1#routerospf1redistributeripsubnetsnetwork131.108.1.00.0.0.255area0network131.108.2.00.0.0.255area0!routerripnetwork132.108.0.0!

Example9-163showsthat0.0.0.0isnotinR1’sdatabasebutthatotherRIProutesareinthedatabase.ThisindicatesthatthedefaultroutethatwasapartofRIPdidnotgetredistributedintoOSPF.Example9-163R1’sOSPFDatabaseIsMissingInformationAboutthe0.0.0.0Route



R1#





R1#




LSage:1161Options:(NoTOS-capability,DC)LSType:ASExternalLinkLinkStateID:132.108.4.0(ExternalNetworkNumber)AdvertisingRouter:131.108.2.1LSSeqNumber:80000001

Checksum:0x550Length:36NetworkMask:/24MetricType:2(Largerthananylinkstatepath)TOS:0Metric:1ForwardAddress:0.0.0.0ExternalRouteTag:1

Example9-164showstheconfigurationofR1,whichshowsthatthedefault-informationoriginatecommandismissingfromtheconfiguration.Example9-164R1’sConfigurationIsMissingthedefault-informationoriginateCommand

R1#routerospf1redistributeripsubnetsnetwork131.108.1.00.0.0.255area0network131.108.2.00.0.0.255area0

Solution

Inthisexample,eventhoughR1isreceivingadefaultroutefromRIP,it’snotgettingredistributedintotheOSPFdatabase.Tosolvethisproblem,configurethedefault-informationoriginatecommandunderrouterospfonR1.Example9-165showstheconfigurationchangeonR1thatfixesthisproblem.Example9-165ConfiguringR1toIncludethedefault-informationoriginateCommand

R1#routerospf1redistributeripsubnetsnetwork131.108.1.00.0.0.255area0network131.108.2.00.0.0.255area0default-informationoriginate

Example9-166showsthatR1isoriginatingthedefaultrouteinthedatabaseafterfixingtheconfigurationonR1.Example9-166TheNewConfigurationofR1FixestheDefaultRouteProblem




LSage:1161Options:(NoTOS-capability,DC)LSType:ASExternalLinkLinkStateID:0.0.0.0(ExternalNetworkNumber)AdvertisingRouter:131.108.2.1LSSeqNumber:80000001Checksum:0x550Length:36NetworkMask:/0MetricType:2(Largerthananylinkstatepath)TOS:0

Metric:1ForwardAddress:0.0.0.0ExternalRouteTag:1

Example9-167showsthatR2startsreceivingthisdefaultroutefromR1afterchangingtheconfigurationonR1.Example9-167VerifyingThatR2ReceivestheDefaultRoutefromR1

R2#showiproute0.0.0.0Routingentryfor0.0.0.0/0,supernetKnownvia"ospf1",distance110,metric1,candidatedefaultpathTag1,typeextern2,forwardmetric128Redistributingviaospf1Lastupdatefrom131.108.1.2onSerial0,00:54:59agoRoutingDescriptorBlocks:*131.108.1.2,from131.108.2.1,00:54:59ago,viaSerial0Routemetricis1,trafficsharecountis1

OSPFNeighborNotAdvertisingDefaultRoutes—Cause:DefaultRouteMissingfromtheNeighbor’sRoutingTable

OSPFwillnotoriginatethedefaultrouteunlessthecommanddefault-informationoriginateisconfiguredunderrouterOSPF.Thiscommandhasonemorerestriction:Theroutermusthaveadefaultrouteinitsroutingtabletooriginateadefaultroute.Figure9-61showstheflowcharttofollowtosolvethisproblem.



Example9-168showsthatR1isnotgeneratingthedefaultrouteinOSPFdatabasebecausenodefaultrouteispresentintheroutingtable.RefertoFigure9-56forthenetworksetup.Example9-168R1IsNotGeneratingtheDefaultRoute




R1#

Example9-169showstheconfigurationonR1toconfirmthatthecommanddefault-informationoriginateisalsoconfiguredtoruleoutthecauseaddressedintheprevioussection.Example9-169ConfirmingThatR1’sConfigurationIncludesthedefault-information-originateCommand

R1#routerospf1redistributeripsubnetsnetwork131.108.1.00.0.0.255area0network131.108.2.00.0.0.255area0default-informationoriginate

Solution

Thisproblemcanbesolvedintwoways.Oneistomakesurethatthedefaultrouteispresentintheroutingtable.Itcouldbederivedfromanyotherroutingprotocol,includingstaticordefaultrouteinformation.Example9-170showsthatafterthedefaultrouteisbackinR1’sroutingtable,itstartsgeneratingadefaultexternalLSA.Example9-170DefaultRouteinR1IsBackSoThatItGeneratestheExternalLSAfor0.0.0.0

R1#showiproute0.0.0.0Routingentryfor0.0.0.0/0,supernetKnownvia"rip",distance120,metric1,candidatedefaultpathRedistributingviaripLastupdatefrom132.108.1.1onSerial1,00:00:16agoRoutingDescriptorBlocks:132.108.1.1,from132.108.1.1,00:00:16ago,viaSerial0Routemetricis1,trafficsharecountis1




LSage:1161Options:(NoTOS-capability,DC)LSType:ASExternalLinkLinkStateID:0.0.0.0(ExternalNetworkNumber)

AdvertisingRouter:131.108.2.1LSSeqNumber:80000001Checksum:0x550Length:36NetworkMask:/0MetricType:2(Largerthananylinkstatepath)TOS:0Metric:1ForwardAddress:0.0.0.0ExternalRouteTag:1

Thesecondmethodistousethealwayskeywordwithdefault-informationoriginate.Thealwayskeywordinstructstheroutertooriginatethedefaultwhetherornotthereisadefaultpresentintheroutingtable.Example9-171showstheconfiguration,whichoriginatesadefaultrouteintheOSPFdatabase.Example9-171ConfiguringthealwaysKeywordtoForceOriginationoftheDefaultRoute

R1#routerospf1redistributeripsubnetsnetwork131.108.1.00.0.0.255area0network131.108.2.00.0.0.255area0default-informationoriginatealways

Example9-172showsthatthedefaultoriginatedintheOSPFdatabaseofR1.Example9-172VerifyingThatR1OriginatestheDefaultRoute





Example9-173showsthatR2startsreceivingthisdefaultroutefromR1afterchangingtheconfigurationonR1.Example9-173R2IsReceivingtheDefaultfromR1

R2#showiproute0.0.0.0Routingentryfor0.0.0.0/0,supernetKnownvia"ospf1",distance110,metric1,candidatedefaultpath

Tag1,typeextern2,forwardmetric128Redistributingviaospf1Lastupdatefrom131.108.1.2onSerial0,00:54:59agoRoutingDescriptorBlocks:*131.108.1.2,from131.108.2.1,00:54:59ago,viaSerial0Routemetricis1,trafficsharecountis1

OSPFNeighborNotAdvertisingDefaultRoutes—Cause:NeighborTryingtoInjectaDefaultintoaStubArea

Whenanareaisdefinedasastub,noexternalLSAsareallowedinit.ThisincludestheType5defaultexternalLSAscreatedbythedefault-informationoriginatecommandonarouter.AnABRautomaticallygeneratesaType3summaryLSAdefaultinastubarea;however,ifadefault-informationoriginatecommandisconfiguredontheABRornon-ABR,itisnotadvertisedasthedefaultroutebecausethiscommandgeneratesType5LSAs,whicharenotallowedinastubarea.InFigure9-62,R1isarouterthatiscompletelyinarea2,whichisdefinedasastubarea.




Example9-174showsthewarningmessagethatR1getswhenittriestooriginateadefaultroutewiththedefault-informationoriginatecommand.R1hasallinterfacesinarea2,whichisdefinedasastub,sodefault-informationoriginateisnotpossibleforR1becauseitwillmakeR1anASBR.Example9-174WarningMessageGeneratedWhenAttemptingtoOriginateaDefaultRoutewiththedefault-informationoriginateCommand

R1(config)#routerospf1R1(config-router)#default-informationoriginateWarning:RouteriscurrentlyanASBRwhilehavingonlyoneareawhichisastubarea

Example9-175showstheconfigurationonR1,whichrevealsthatR1hasthedefault-informationoriginatecommandconfigured.However,R1willnotgeneratedefaultType5LSAsintoarea2becauseit’sastubarea.Also,noinformationon0.0.0.0intheOSPFdatabaseofR1canbefound.Example9-175R1’sConfigurationIndicatesThatIt’sDefinedasaStubArea

R1#routerospf1network131.108.1.00.0.0.255area2network131.108.2.00.0.0.255area2default-informationoriginate

area2stub



R1#

Solution

Inthisexample,alltheinterfacesofR1areincludedinarea2,whichisastubarea.Whenthedefault-informationoriginatecommandisconfigured,itsimplyignorestheareawithawarning.Normally,whenanareaisdefinedasastub,aType3summarydefaultisgeneratedbytheABR.Thisproblemcanbesolvedinthreeways:•ChangetheareatoNSSAandthenoriginateaType7default.•Changethestubareatoanormalareaandthenoriginateadefaultroute.•Configureastaticdefaultroute.

Thefirstsolutionisdiscussedlaterinthissection.Thesecondsolutionisnotagoodonebecausearea2willbecomeanormalareaandwillcontainunnecessaryType5LSAs.Inthiscase,however,itisanacceptablesolution.Example9-176showstheconfigurationchangesnecessarytoachievethis.Example9-176ConfiguringR1asaNormalAreaandOriginatingaDefaultRoute

R1#routerospf1network131.108.1.00.0.0.255area2network131.108.2.00.0.0.255area2default-informationoriginatenoarea2stub

Example9-177showsthatR2isreceivingadefaultfromR1aftertheconfigurationchange.Example9-177VerifyingThatReconfiguringR1asaNormalAreaResolvestheProblem

R2#showiproute0.0.0.0Routingentryfor0.0.0.0/0,supernetKnownvia"ospf1",distance110,metric1,candidatedefaultpathTag1,typeextern2,forwardmetric128Redistributingviaospf1Lastupdatefrom131.108.1.1onSerial0,00:54:59agoRoutingDescriptorBlocks:*131.108.1.1,from131.108.2.1,00:54:59ago,viaSerial0Routemetricis1,trafficsharecountis1

Thethirdsolutionissimpletoimplement.TherequirementistooverridethesummarydefaultroutethatiscomingfromtheABRincasetheareaisdefinedasastub.Ifthatsummarydefaultisdesirable,thereisnoneedforanychangeintheconfiguration.Example9-178showsthatR1hasastaticdefaultrouteconfigured.Tooverridethesummarydefaultonalltheroutersinanarea,thestaticdefaultroutemustbeconfiguredonalltheroutersinanarea.Thismakesthissolutionlessdesirable.Example9-178R1HasaStaticDefaultRouteConfigured

R1(config)#iproute0.0.0.00.0.0.0131.108.2.2

R1#showiproute0.0.0.0Routingentryfor0.0.0.0/0,supernetKnownvia"static",distance1,metric0,candidatedefaultpathRoutingDescriptorBlocks:*131.108.2.2Routemetricis0,trafficsharecountis1

OSPFNeighborNotAdvertisingDefaultRoutes—Cause:NSSAABR/ASBRNotOriginatingType7Default

WhenanNSSAisdefined,bydefault,theNSSAABRdoesnotoriginateanydefaultroute.Thisisnotthecaseinstubareasortotallystubbyareas.Whenanareaisdefinedasastub,theABRoriginatestheType3defaultrouteintheformofasummaryLSA.ThisisbecauseastubareacannothaveanyType5LSAs,sothedefaultroutemustnotbeaType5LSA.Thisisalsotrueintotallystubbyareas.WhenanNSSAareaisdefinedwiththeno-summaryoption,theNSSAABRautomaticallygeneratesaType3summarydefault.ThiscreatesatotalNSSA.InFigure9-64,R1isanNSSAASBRthatistryingtooriginateadefaultrouteintoarea2,whichisanNSSA.




Example9-179showstheconfigurationofR1.TheconfigurationshowsthatR1istryingtooriginateadefault.Example9-179R1IsMisconfiguredtoOriginatetheDefaultRoute

R1#routerospf1network131.108.1.00.0.0.255area2network131.108.2.00.0.0.255area2default-informationoriginatearea2nssa

Example9-180showsthatR1isnotoriginatingadefaultroute.Example9-180R1IsNotOriginatingaDefaultRoute



R1#



R1#

Solution

TypethehighlightedcommandinExample9-181tooriginateadefaultrouteinanNSSA.ThiscommandworksoneitherNSSAABRsorNSSAASBRs.Example9-181OriginatingaDefaultRouteinanNSSA

R1#routerospf1network131.108.1.00.0.0.255area2network131.108.2.00.0.0.255area2area2nssadefault-informationoriginate

Inthepast,thiscommandworkedonlyonanNSSAABR,butCiscoIOSSoftwareRelease12.0.11and12.1.2providesupportforthistoworkonNSSAASBRsaswell.Example9-182showsthatafterconfiguringthiscommand,R2receivesadefaultfromR1.Example9-182R1SuccessfullyOriginatesaDefaultRoute

R2#showiproute0.0.0.0Routingentryfor0.0.0.0/0,supernetKnownvia"ospf1",distance120,metric1,candidatedefaultpath,typeNSSAextern2,forwardmetric64Redistributingviaospf1Lastupdatefrom131.108.1.1onSerial0,00:00:03agoRoutingDescriptorBlocks:*131.108.1.1,from131.108.2.1,00:00:03ago,viaSerial0Routemetricis1,trafficsharecountis1

TroubleshootingOSPFRouteInstallationThissectiondiscussestheproblemsrelatedtorouteinstallation.ThismeansthatOSPFroutershavefullysynchronizedtheirdatabaseswiththoseoftheirneighborsbutarenotinstallingroutesintheroutingtable.Aftertherouteisinthedatabase,therecanbeseveralreasonsthattherouteisnotinstalledinthedatabase.Thissectiondiscussesthosereasonsindetailandalsotellshowtosolvethesekindsofproblems.ThemostcommonreasonsforOSPFfailingtoinstallroutesintheroutingtableareasfollows:•OSPFisnotinstallinganyroutesintheroutingtable.•OSPFisnotinstallingexternalroutesintheroutingtable.

Problem:OSPFNotInstallingAnyRoutesintheRoutingTableThisisalsoacommonprobleminOSPFtofindroutesinthedatabasebutnotintheroutingtable.WhenOSPFfindsanykindofdiscrepancyinthedatabase,itdoesnotinstallanyroutesintheroutingtable.Thissectionassumesthatthesenderisadvertisingtheroutesinthedatabase.Ifthesenderisnotadvertisingtheroutes,oriftherouteisnotevenpresentinthedatabase,troubleshootthatproblemfirst.Thiswasdiscussedintheprevioussection,fortroubleshootingwhenOSPFisnotadvertisingroutes.Themostcommonpossiblecausesofthisproblemareasfollows:

•Thenetworktypeismismatched.•IPaddressesareflippedindualserial-connectedroutersorasubnet/maskmismatchhasoccurred.•Onesideisanumberedandtheothersideisanunnumberedpoint-to-pointlink.•Adistributelistisblockingtheroutes’installation.•ThereisabrokenPVCinafullymeshedFrameRelaynetworkwiththebroadcastnetworktype.

Figure9-66showsanetworksetupthatproducestheOSPFrouteinstallationproblem.Thecloudinthemiddleisirrelevant.ItcouldbeFramerelay,PPPHDLC,orsomethingelse,butitmustbeapoint-to-pointWANlinkinthisscenario.

Figure9-66OSPFNetworkSetupUsedtoProduceRouteInstallationProblems

Example9-183showsthatR2isnotinstallinganyroutesintheroutingtable.Example9-183R2HasNoRoutesinItsRoutingTable

R2#showiprouteospfR2#

OSPFNotInstallingAnyRoutesintheRoutingTable—Cause:NetworkTypeMismatch

Amismatchednetworktypeproducesadiscrepancyinthedatabase,andOSPFwillnotinstallthoseroutesintheroutingtable.ThissituationiscommoninNBMAnetworksinwhichonesidehasapoint-to-pointnetworktypeandtheothersidehasabroadcastnetworktype.Thisproblemalsooccursifonesideisdefinedasapoint-to-multipointnetworkandtheothersideisleftasnonbroadcast.Inthisexample,onesideisdefinedasbroadcastandtheothersideisdefinedaspoint-to-point.Whenaninterfacenetworktypeisdefinedasbroadcast,OSPFconsidersthatlinktobeatransitlinkandputsthatlinkinitsrouterLSAasatransitlink.Figure9-67showstheflowcharttofollowtosolvethisproblem.


Example9-184showstheinterfaceconfigurationonbothR1andR2.TheR1serialinterfacenetworktypeisbroadcast,whileR2usesthedefaultnetworktype,whichisnonbroadcast.Example9-184NetworkTypesforR1andR2

R1#interfaceSerial0ipaddress131.108.1.1255.255.255.0ipospfnetworkbroadcast!

R2#interfaceSerial0ipaddress131.108.1.2255.255.255.0

Example9-185showstheoutputofshowipospfinterfacefortheSerial0interfaceofbothrouters,whichshowsthatthereisanetworktypemismatchonbothends.Example9-185DeterminingWhetherR1andR2HaveaNetworkTypeMismatchontheSerial0Interfaces

R1#showipospfinterfaceserial0Serial0isup,lineprotocolisupInternetAddress131.108.1.1/24,Area0

ProcessID20,RouterID131.108.2.1,NetworkTypeBROADCAST,Cost:64TransmitDelayis1sec,StateDR,Priority1DesignatedRouter(ID)131.108.2.1,Interfaceaddress131.108.1.1BackupDesignatedrouter(ID)131.108.2.2,Interfaceaddress131.108.2.2Timerintervalsconfigured,Hello10,Dead40,Wait40,Retransmit5Helloduein00:00:08NeighborCountis1,Adjacentneighborcountis1Adjacentwithneighbor131.108.2.2(BackupDesignatedRouter)Suppresshellofor0neighbor(s)

R2#showipospfinterfaceserial0Serial0isup,lineprotocolisupInternetAddress131.108.1.2/24,Area0ProcessID20,RouterID131.108.1.2,NetworkTypePOINT_TO_POINT,Cost:64TransmitDelayis1sec,StatePOINT_TO_POINT,Timerintervalsconfigured,Hello10,Dead40,Wait40,Retransmit5Helloduein00:00:02NeighborCountis1,Adjacentneighborcountis1Adjacentwithneighbor131.108.2.1Suppresshellofor0neighbor(s)

Example9-186showstheoutputofrouterLSAsoneachrouter.TherouterLSAiscomplainingthattheadvertisingrouterisunreachable.Thisiswhytheroutersarenotinstallingroutesintheroutingtable.Example9-186LSAsforR1andR2IndicateThattheAdvertisingRouterIsUnreachable


AdvRouterisnot-reachableLSage:418Options:(NoTOS-capability,DC)LSType:RouterLinksLinkStateID:131.108.1.2AdvertisingRouter:131.108.1.2LSSeqNumber:80000002Checksum:0xFA63Length:60NumberofLinks:3Linkconnectedto:anotherRouter(point-to-point)(LinkID)NeighboringRouterID:131.108.2.1(LinkData)RouterInterfaceaddress:131.108.1.2NumberofTOSmetrics:0TOS0Metrics:64




AdvRouterisnot-reachableLSage:357Options:(NoTOS-capability,DC)

LSType:RouterLinksLinkStateID:131.108.2.1AdvertisingRouter:131.108.2.1LSSeqNumber:8000000AChecksum:0xD4AALength:48NumberofLinks:2

Linkconnectedto:aTransitNetwork(LinkID)DesignatedRouteraddress:131.108.1.1(LinkData)RouterInterfaceaddress:131.108.1.1NumberofTOSmetrics:0TOS0Metrics:64


Solution

Inthisexample,onesideofalinkisshownasapoint-to-pointlinkinthedatabase,andtheothersideofthesamelinkisshownasatransitlink.Thiscreatesadiscrepancyinthedatabaseandtherouterwillnotinstallanythingintheroutingtable.Tofixthisproblem,changethenetworktypeofR1backtoitsdefault,whichispoint-to-point.Example9-187showshowtochangethenetworktypebacktopoint-to-pointonR1.Example9-187ChangingNetworkTypeBacktoPoint-to-Point

R1#interfaceSerial0ipaddress131.108.1.1255.255.255.0noipospfnetworkbroadcast

Example9-188showstheoutputofshowipospfinterfacefortheserialinterface.Itshowsthatthenetworktypeispoint-to-point.Example9-188VerifyingThatR1’sSerial0InterfaceIsofNetworkTypePoint-to-Point

R1#showipospfinterfaceserial0Serial0isup,lineprotocolisupInternetAddress131.108.1.1/24,Area0ProcessID20,RouterID131.108.2.1,NetworkTypePOINT_TO_POINT,Cost:64TransmitDelayis1sec,StatePOINT_TO_POINT,Timerintervalsconfigured,Hello10,Dead40,Wait40,Retransmit5Helloduein00:00:02NeighborCountis1,Adjacentneighborcountis1Adjacentwithneighbor131.108.1.2Suppresshellofor0neighbor(s)

Example9-189showsthatR2startsinstallingOSPFroutesinitsroutingtable.Example9-189ConfirmingThatOSPFRoutesNowAreBeingInstalled

R2#showiproute131.108.3.0Routingentryfor131.108.3.0/24Knownvia"ospf1",distance130,metric74,typeintraareaRedistributingviaospf1

Lastupdatefrom131.108.1.1onSerial0,01:39:09agoRoutingDescriptorBlocks:*131.108.1.1,from131.108.2.1,14:39:09ago,viaSerial0Routemetricis64,trafficsharecountis1

OSPFNotInstallingAnyRoutesintheRoutingTable—Cause:IPAddressesAreFlippedinDualSerial-ConnectedRouters

TheIPaddressingondualserialinterfacescancausethisproblem.OSPFformsaFULLadjacencybecausetheneighborisstillreachable,butthiscreatesadiscrepancyintheOSPFdatabase.ThisalsocanhappenwhenthewrongIPsubnetormaskisassignedononeside.ThiscreatesadiscrepancyintheOSPFdatabase.Figure9-68showsanetworksetupinwhichtheaddressesontheserialinterfacesareflipped;forexample,R1’sSerial0addressis131.108.1.1/24.TheotherendofthisinterfacegoesintoSerial0ofR2,whichhasthe131.108.2.1/24addressdefinedunderSerial0.AsimilarthingcanbeobservedwiththeSerial1interface.Thisobviouslylooksliketheaddressesareflipped.

Figure9-68OSPFNetworkinWhichRouterSerialInterfaceIPAddressesAreFlipped

Example9-190showsthatR2isnotinstallinganyroutesintheroutingtablebecauseofthediscrepancyinthedatabase.Example9-190R2IsNotInstallingAnyOSPFRoutesinItsRoutingTable




Example9-191showstheoutputofshowipospfneighbor,whichshowsthatOSPFisformingFULLadjacencyonbothseriallinks.Theaddresscolumnshowsthattheneighboraddressandinterfacedonotmatch.Forexample,inExample9-191,R2hastwoneighbors.BecauseR2’sSerial0addressisintherange131.108.2.0/24,asshowninFigure9-68,theneighboraddressonSerial0alsoshouldbeinthesamerange,butitshows131.108.1.1asaneighboronSerial0.Example9-191showipospfneighborCommandOutputIndicatesOSPFAdjacencyFormationonR1’sSerialLinks


NeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/-00:00:37131.108.1.1Serial0131.108.2.11FULL/-00:00:31131.108.2.1Serial1

Solution

Tofixthisproblem,assigntheIPaddressonthecorrectcorrespondinginterface.EitherchangeR1’sIPaddressesonitsseriallinksorchangeR2’sIPaddressesonitsseriallinks.Inthisexample,R2’sseriallinkshavebeenchangedtomatchR1’s.Serial0IPaddressesandSerial1IPaddresseshavebeenswapped,asshowninExample9-192.

Example9-192ChangingIPAddressesonR2’sSerialLinks

R2#interfaceserial0noipaddressipaddress131.108.1.2255.255.255.0!interfaceserial1noipaddressipaddress131.108.2.1255.255.255.0

Example9-193showsthatafterfixingthisproblem,R2installsOSPFroutesinitsroutingtable.Example9-193R2’sRoutingTableIndicatesThattheProblemHasBeenResolved


R2#

OSPFNotInstallingAnyRoutesintheRoutingTable—Cause:OneSideIsaNumberedandtheOtherSideIsanUnnumberedPoint-to-PointLink

WhenOSPFcreatesarouterLSAforpoint-to-pointlinks,itadherestothefollowingruletofilltheLinkIDandLinkDatafieldswithintherouterLSA(seeTable9-1).Table9-1LinkIDandLinkDataValuesforOSPFPoint-to-PointNumberedandUnnumberedLinks

Table9-1showsthattheLinkDatafieldforunnumberedpoint-to-pointlinksshouldhaveanMIB-IIifIndexvalue.Becausethelinkdatavalueofthenumberedinterfacedoesnotmatchthatoftheunnumberedinterface,thiscreatesthediscrepancyintheOSPFdatabase.Figure9-70showsanetworksetupinwhichtheR1seriallinkisunnumberedtoaloopbackinterface,whiletheR2seriallinkisnumbered.

Figure9-70OSPFNetworkwithaSerialLinkUnnumberedtoaLoopbackInterface



Example9-194showsthediscrepancyintheOSPFdatabase.R1’srouterLSAshowstheMIB-IIIfIndexvalueintheLinkDatafieldforSerial0,whileR2’srouterLSAshowstherouter’sserialinterfaceaddressintheLinkDatafield.Example9-194CheckingtheOSPFDatabaseforaDiscrepancy

R2#showipospfdatabaserouter



AdvRouterisnot-reachableLSage:855Options:(NoTOS-capability,DC)LSType:RouterLinksLinkStateID:131.108.1.1AdvertisingRouter:131.108.1.1LSSeqNumber:8000000DChecksum:0x55ADLength:60NumberofLinks:1





AdvRouterisnot-reachableLSage:855Options:(NoTOS-capability,DC)LSType:RouterLinksLinkStateID:131.108.1.2AdvertisingRouter:131.108.1.2LSSeqNumber:8000000DChecksum:0x55ADLength:60NumberofLinks:1


Example9-195showstheconfigurationonbothR1andR2,whichshowsthatR1’sserialinterfaceisunnumberedtoaloopbackaddress,whileR2’sserialinterfaceisnumbered.Example9-195SerialInterfaceConfigurationsforR1andR2

R1#interfaceLoopback0ipaddress131.108.1.1255.255.255.0!interfaceSerial0ipunnumberedLoopback0!routerospf1network131.108.0.00.0.255.255area0

R2#interfaceSerial0ipaddress131.108.1.2255.255.255.0!routerospf1network131.108.0.00.0.255.255area0

Solution

Tofixthisproblem,makesurethatbothsidesareeitheranumberedpoint-to-pointlinkoranunnumberedpoint-to-pointlink.Example9-196showsthenewconfigurationthatfixesthisproblem.Inthisexample,R1’sserialinterfaceisassignedanIPaddress.Example9-196AssigninganIPAddressonR1’sSerial0Interface,WhichWasUnnumberedBefore

R1#

interfaceSerial0ipaddress131.108.1.1255.255.255.0!routerospf1network131.108.0.00.0.255.255area0

R2#interfaceSerial0ipaddress131.108.1.2255.255.255.0!routerospf1network131.108.0.00.0.255.255area0

Example9-197showsthatR2installsroutesintheroutingtableafterthisproblemisfixed.Example9-197ConfirmingOSPFRouteInstallation


R2#

OSPFNotInstallingAnyRoutesintheRoutingTable—Cause:DistributeListIsBlockingtheRouteInstallation

OSPFisalink-stateprotocol.Whenitformsanadjacencywithanyneighbor,itsynchronizesitsdatabasewiththatneighbor.Becauseofitslink-statenature,filteringinOSPFisnotpossible.Configuringdistribute-listinpreventsOSPFroutesfrombeinginstalledintheroutingtable.Thisdoesn’tmeanthattheroutesdisappearfromtheOSPFdatabase.ItsimplymeansthatbeforeOSPFinstallstherouteintotheroutingtable,itchecksforthedistributelistandinstallsonlythosenetworksthatarepermittedinthedistributelist.However,itkeepstheroutesinthedatabase.Figure9-72showsanetworksetupinwhichOSPFisnotinstallinganyroutesintheroutingtable.Specifically,Router2isnotseeinganyOSPFroutesinitsroutingtable.

Figure9-72OSPFNetworkThatProducesRouteInstallationProblems



Example9-198showstheconfigurationonR2,whichshowsthatR2hasdistribute-listinconfiguredandisnotinstallinganyOSPFroutesintheroutingtable.Accesslist1,whichisusedinthedistributelist,allowsonlythe10/8and20/8networkstobeinstalledintheroutingtable.Theremainingnetworksareimplicitlydenied.Example9-198alsoshowsthatthe131.108.3.0networkisnotintheroutingtablebecauseitisdeniedbythedistributelist.Example9-198R2ConfigurationwithaDistributeList

R2#!routerospf1network131.108.0.00.0.255.255area0distribute-list1in!access-list1permit10.0.0.0access-list1permit20.0.0.0


Solution

Ifanetworkisinthedatabasebutnotintheroutingtable,makesurethatthenetworkispermittedinthedistributelist.Example9-199showsthenewconfigurationthatfixesthisproblem.Inthisconfiguration,network

131.108.3.0ispermitted.Example9-199ConfiguringR2’sDistributeListtoPermitthe131.108.3.0/24Network

R2#!routerospf1network131.108.0.00.0.255.255area0distribute-list1in!access-list1permit10.0.0.0access-list1permit20.0.0.0access-list1permit131.108.3.00.0.0.255

Example9-200showsthatnetwork131.108.3.0/24appearsintheroutingtableafterfixingtheconfigurationonR2.Example9-200ConfirmingThatthe131.108.3.0RouteIsInstalled


R2#

OSPFNotInstallingAnyRoutesintheRoutingTable—Cause:BrokenPVCinaFullyMeshedFrameRelayNetworkwithBroadcastNetworkType

TheOSPFnetworktypebroadcastshouldneverbedefinedonamediumthatisnotfullymeshed.Sometimes,themediumisfullymeshedbuttheLayer2connectivityisnotstable.Inthatcase,whenLayer2isbroken,itcreatesaninconsistencyandthemediumbecomesnon–fullymeshedagain.Figure9-74showsanetworkexperiencingthisproblem.BeforethePVCbetweenR1andR2wasbroken,R2wasaDRandR3wasaBDR.

Figure9-74OSPFNetworkinWhichaBrokenPVCinaFullyMeshedFrameRelayNetworkwithBroadcastNetworkTypeCausesProblems

Example9-201showsthatR1isnotinstallinganyroutesintheroutingtable.Example9-201R1IsNotInstallingAnyRoutes




Example9-202showstheconfigurationonR1,R2,andR3.TheconfigurationshowsthatthenetworktypeisbroadcastonallroutersfortheFrameRelaycloud.Example9-202ConfirmingtheNetworkTypeonR1,R2,andR3

R1#!interfaceSerial0.1multipointipaddress131.108.0.1255.255.255.0ipospfnetworkbroadcast



Example9-203showstheoutputofshowipospfneighboronallthreerouters.TheoutputonR1showsthatitconsidersR2tobetheDR.However,theactualDRisR3,asshowninFigure9-74,becauseithasthehighestrouterID.BecausethelinkbetweenR1andR3isbroken,R1declaresR2tobetheDR.Example9-203DeterminingtheDesignatedRouter

R1#showipospfneighborNeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/DR00:00:31131.108.0.2Serial0.1

R2#showipospfneighborNeighborIDPriStateDeadTimeAddressInterface131.108.1.11FULL/DROTHER00:00:34131.108.0.1Serial0.1131.108.3.11FULL/DR00:00:33131.108.0.3Serial0.1

R3#showipospfneighborNeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/BDR00:00:31131.108.0.2Serial0.1

Example9-204showstherouterLSAoutputonR1displayingtherouterLSAforR1,R2,andR3.R1stillconsidersR2theDRinsteadofR3.R1showsthattheFrameRelaylinkisastublinkbecauseitcouldn’tfindanynetworkLSAgeneratedbyR2inthedatabase.ThisFrameRelaylinkisdefinedasatransitlinkinbothR2andR3’sdatabase.ThiscreatesadiscrepancyintheOSPFdatabase.Example9-204OSPFDatabaseonR1,R2,andR3ShowsDiscrepancy




LSage:148Options:(NoTOS-capability,DC)LSType:RouterLinksLinkStateID:131.108.1.1AdvertisingRouter:131.108.1.1LSSeqNumber:8000000BChecksum:0x55ALength:48NumberofLinks:2



AdvRouterisnot-reachableLSage:1081Options:(NoTOS-capability,DC)LSType:RouterLinks

LinkStateID:131.108.2.1AdvertisingRouter:131.108.2.1LSSeqNumber:80000006Checksum:0x4F72Length:48NumberofLinks:2



AdvRouterisnot-reachableLSage:306Options:(NoTOS-capability,DC)LSType:RouterLinksLinkStateID:131.108.3.1AdvertisingRouter:131.108.3.1LSSeqNumber:80000007Checksum:0xC185Length:48NumberofLinks:2



Solution

Thesolutioninthiscaseistorunapoint-to-multipointnetworktype.Withapoint-to-multipointnetworktype,thefloodingincreasesbecausenoDR/BDRelected.Ifthereisanyconnectivityproblem,however,itwillnotcreateanyblackholes.So,atrade-offexistsbetweenreliabilityandincreasedflooding.Selectingapoint-to-multipointnetworktypeoverunstableFrameRelaylinksprovidesreliability,whileselectingabroadcastnetworktypecreatesinconsistencieswheneveranyLayer2instabilityoccurs.Example9-205showsthenewconfigurationchangesonR1,R2,andR3.Thenetworktypeisnowpoint-to-multipoint.Example9-205ConfiguringR1,R2,andR3withPoint-to-MultipointInterfaces

R1#!interfaceSerial0.1multipointipaddress131.108.0.1255.255.255.0ipospfnetworkpoint-to-multipoint



Example9-206showsthatR1startslearningOSPFroutesfromR2aftertheconfigurationchanges.Example9-206ConfirmingThatR1IsLearningOSPFRoutesfromR2

R1#showiproute131.108.3.0Routingentryfor131.108.3.0/24Knownvia"ospf1",distance130,metric129,typeintraareaRedistributingviaospf1Lastupdatefrom131.108.0.2onSerial0.1,00:00:19agoRoutingDescriptorBlocks:*131.108.0.2,from131.108.3.1,14:39:09ago,viaSerial0.1Routemetricis64,trafficsharecountis1

R1#

Problem:OSPFNotInstallingExternalRoutesintheRoutingTableWhenOSPFredistributesanyroutes,whetherconnected,static,orfromadifferentroutingprotocol,itgeneratesaType5LSAforthoseexternalroutes.TheseType5LSAsarefloodedintoeveryOSPFrouter,withtheexceptionofthoseinstubandNSSAareas.Sometimes,theproblemisthattheexternalroutesareintheOSPFdatabasebutarenotbeinginstalledintheroutingtable.Themostcommoncausesofthisproblemareasfollows:•Theforwardingaddressisnotknownthroughtheintra-areaorinterarearoute.•TheABRisnotgeneratingType4summaryLSAs.

OSPFNotInstallingExternalRoutesintheRoutingTable—Cause:ForwardingAddressIsNotKnownThroughtheIntra-AreaorInterareaRoute

WhenOSPFlearnsanexternalLSA,itmakessurethattheforwardingaddressisknownthroughanOSPFintra-areaorinterarearoutebeforeitinstallsitintotheroutingtable.Iftheforwardingaddressisnotknowthroughanintra-areaorinterarearoute,OSPFwillnotinstalltherouteintheroutingtable.ThisisinaccordancewiththeRFC2328standard.Figure9-76showsanetworkwiththefollowingspecifications:•R3isanASBRthatisredistributingRIProutesintoOSPF.•R4isrunningRIPwithR3.•R4islearning200.200.200.0/24throughRIP.•R2isrunningOSPFwithR3.•R2istheABR.

Figure9-76OSPFNetworkExperiencingaProblemofExternalRoutesNotGettingInstalledintheRoutingTable

Example9-207showstheoutputofshowiproutefor200.200.200.0.ThisnetworkresidesinaRIPdomain.BecauseRIPisbeingredistributedintoOSPFonR3,allOSPFroutersshouldseethisrouterasOSPFexternal.However,R1isnotseeingthisrouteinitsroutingtable.Example9-207R1IsMissingRIPRouteof200.200.200.0inItsRoutingTable




Example9-208showstheexternalLSAforrouter200.200.200.0.TheexternalLSAexistsintheOSPFdatabase,buttheroutestillisnotbeinginstalledintheroutingtable.Also,thereisaforwardingaddressinvolvedinthisexternalLSA.Example9-208ExternalLSADatabaseforRIPRoute200.200.200.0




LSage:14Options:(NoTOS-capability,DC)LSType:ASExternalLinkLinkStateID:200.200.200.0(ExternalNetworkNumber)AdvertisingRouter:131.108.0.129LSSeqNumber:80000001Checksum:0x88BELength:36NetworkMask:/24MetricType:2(Largerthananylinkstatepath)TOS:0Metric:20ForwardAddress:131.108.0.4ExternalRouteTag:0

Example9-209showsthattheroutetotheforwardingaddressisknownthroughanOSPFexternalroute.Example9-209RoutetotheForwardingAddressIsKnownThroughanOSPFExternalRoute

R1#showiproute131.108.0.4Routingentryfor131.108.0.0/26Knownvia"ospf1",distance110,metric20,typeextern2,forwardmetric70Redistributingviaospf1Lastupdatefrom131.108.1.2onSerial0,00:00:40agoRoutingDescriptorBlocks:*131.108.1.2,from131.108.0.129,00:00:40ago,viaSerial0Routemetricis20,trafficsharecountis1

Example9-210showsthattheABRissummarizing131.108.0.0/24withanarearangecommand,sothemorespecificintra-arearoutesaresummarizedintooneroute.Thisrangesummarizesallroutesunderthe131.108.0.0/16range.Example9-210R2SummarizestheIntra-areaRoutesas131.108.0.0/24

R2#routerospf1network131.108.1.00.0.0.255area0network131.108.0.00.0.0.255area2area2range131.108.0.0255.255.255.0

Example9-211showsthattheASBRisdoingtheredistributionfromRIPintoOSPF.Italsoshowsthattheconnectednetworksintherangeof131.108.0.0/26arebeingredistributedintoOSPFbecauseRIPownsthoseconnectedroutes.Thisconfigurationredistributes131.108.0.4/26,whichisaconnectedinterfaceonR3.ThissubnetcoverstheforwardingaddressthatappearedinExample9-209.Example9-211R3RedistributesRIPRoutesinthe131.108.0.0/26RangeintoOSPF

R3#routerospf1redistributeripsubnetsnetwork0.0.0.0255.255.255.255area2!routerripnetwork131.108.0.0

Solution

R1isseeingtheforwardingaddresslearnedthroughOSPFexternalbecauseR3hasredistributeconnectedunderrouterospf.ThisleaksamorespecificroutefortheconnectedinterfacesofR3.Thisalsoincludestheforwardingaddresssubnet,whichis131.108.0.4/26.Also,theintra-arearouteforthissubnetissuppressedbyR2becauseR2issummarizing131.108.0.0/16.Becausethemorespecificroutealwaysispreferred,R1prefersthemorespecificexternalrouteof131.108.0.4/26overthelessspecificsummarizedrouteof131.108.0.0/16.Thisproblemcanbesolvedintwoways:•DonotsummarizeattheABR.•FiltertheconnectedsubnetfrombeingredistributedintoOSPFattheASBR.

Toimplementthefirstsolution,gototheABRandremovethearearangecommand.Example9-212showsthenewconfigurationonABRthatsolvesthisproblem.

Example9-212RemovingSummarizationCapabilitiesattheABR

R2#routerospf1network131.108.1.00.0.0.255area0network131.108.0.00.0.0.255area2noarea2range131.108.0.0255.255.255.0

Toimplementthesecondsolution,gototheASBRandaddafiltertocontrolredistributedroutes.Example9-213showsthenewconfigurationsthatfixthisproblem.Thefilteractuallypreventstheroute131.108.0.0/26fromgettingredistributedintoOSPFasanexternalroutebecauseonly200.200.200.0ispermitted;allotherroutesaredenied.Example9-213ConfiguringtheASBRtoFilterConnectedRoutes

R3#routerospf1redistributeripsubnetsroute-mapno_connectednetwork0.0.0.0255.255.255.255area2!routerripnetwork131.108.0.0!route-mapno_connectedpermit10matchipaddress1!access-list1permit200.200.200.00.0.0.255

Example9-214showsthatafterfixingthisproblem,R1startsinstallingtheroutesintheroutingtablebecausetheforwardingaddressisnowknownthroughanOSPFinterarearoute.Example9-214ConfirmingThatExternalRoutesAreBeingInstalledAgainonR1

R1#showiproute200.200.200.0Routingentryfor200.200.200.0/24Knownvia"ospf2",distance110,metric20,typeextern2,forwardmetric128Redistributingviaospf2Lastupdatefrom131.108.1.2onSerial0.1,00:47:24agoRoutingDescriptorBlocks:*131.108.1.2,from131.108.0.29,00:47:24ago,viaSerial0.1Routemetricis20,trafficsharecountis1

Also,Example9-215showsthattheforwardingaddressisnowknownthroughOSPFinterareainsteadofOSPFexternal.Example9-215ForwardingAddressIsNowKnownThroughOSPFInterarea

R1#showiproute131.108.0.4Routingentryfor131.108.0.4/26Knownvia"ospf2",distance110,metric64,typeinterareaRedistributingviaospf2Lastupdatefrom131.108.1.2onSerial0.1,00:50:25agoRoutingDescriptorBlocks:*131.108.1.2,from131.108.0.193,00:50:25ago,viaSerial0.1Routemetricis64,trafficsharecountis1

OSPFNotInstallingExternalRoutesintheRoutingTable—Cause:ABRNotGeneratingType4SummaryLSA

OneofthefunctionsofaType4summaryLSAistoannouncethereachabilityofanASBRtotheotherareas.ThisType4LSAisnotrequirediftheASBRexistsinthesamearea.TheASBRdoesn’tgeneratetheType4summaryLSAifit’snotconnectedtoarea0.TogenerateasummaryLSAofType3orType4,aroutermusthaveaconnectionintoarea0.Asaresult,theexternalrouteswillnotbeinstalledinthenetwork.Chapter8coversType3andType4LSAsingreaterdetail.Figure9-78showsanetworkinwhichR3redistributesRIProutesintoOSPF.

Figure9-78OSPFNetworkExperiencingExternalRouteInstallationProblemBecauseofMissingType4SummaryLSAs

Example9-216showsthatR1isnotinstallingtheexternalroute200.200.200.0/24intotheroutingtable.Example9-216R1NotInstallingExternalRoute200.200.200.0




Example9-217showsthattherouteexistsintheexternaldatabase.Example9-217ConfirmingThatRoute200.200.200.0ExistsintheExternalOSPFDatabase




LSage:199Options:(NoTOS-capability,DC)LSType:ASExternalLinkLinkStateID:200.200.200.0(ExternalNetworkNumber)AdvertisingRouter:131.108.3.3LSSeqNumber:80000001Checksum:0x4B3ALength:36NetworkMask:/24MetricType:2(Largerthananylinkstatepath)TOS:0Metric:20ForwardAddress:0.0.0.0ExternalRouteTag:0

Example9-218showsthethereisnoType4LSAforthisroute.Example9-218NoType4LSAExistsfortheExternalRoute

R1#showipospfdatabaseasbr-summary131.108.3.3


ThenextlogicalstepistogoontheABRandseeifitisindeedanABR.IfitdoesnotconsideritselfanABR,itwillnotgenerateanysummaryLSAofType3orType4.Example9-219showsthatR2isnotidentifyingitselfasanABRintheoutputofshowipospf.IfR2wereanABR,theoutputwoulddisplay“It’sanareaborderrouter.”Example9-219R2Doesn’tAcknowledgeItselfasanABR

R2#showipospfRoutingProcess"ospf1"withID131.108.2.2SupportsonlysingleTOS(TOS0)routesSPFscheduledelay5secs,HoldtimebetweentwoSPFs10secs

Solution

Inthisexample,R2doesn’tgeneratetheType4summaryLSAsbecauseitisnotconnectedtoarea0.TogenerateasummaryLSAofType3orType4,aroutermusthaveaconnectionintoarea0.Tosolvethisproblem,connectR2toarea0eitherphysicallyorvirtuallybycreatingavirtuallink,asshowninExample9-220.Toreadmoreaboutvirtuallinks,refertoChapter8.Example9-220ConfiguringVirtualLinkBetweenR2andR1

R1#routerospf1area2virtual-link131.108.2.2

R2#routerospf1area2virtual-link131.108.2.1

ByconfiguringavirtuallinkonR2,therouterisnowvirtuallyconnectedtoarea0;therefore,itnowconsidersitselfanABR.Example9-221showsthatafterconnectingR2toarea0,theoutputofshowipospfshowsthatitisanABR.ComparethisoutputtoExample9-219,inwhichtherouterdoesn’tconsideritselfasanABR.Example9-221ConfirmingThatR2IsNowAwareofItsABRStatus

R2#showipospfRoutingProcess"ospf1"withID131.108.2.2SupportsonlysingleTOS(TOS0)routesItisanareaborderrouterSPFscheduledelay5secs,HoldtimebetweentwoSPFs10secs

Now,getonR1againandseeiftheType4LSAisbeingreceived.Example9-222showsthataftertheconfigurationchangesonR2,ithasstartedgeneratingType4summaryLSAsintoarea3.Example9-222R2NowGeneratesType4LSAsintoArea2,andR1ReceivesIt

R1#showipospfdatabaseasbr-summary


SummaryASBLinkStates(Area2)

LSage:17Options:(NoTOS-capability,DC)LSType:SummaryLinks(ASBoundaryRouter)LinkStateID:131.108.3.3(ASBoundaryRouteraddress)AdvertisingRouter:131.108.2.2LSSeqNumber:80000001Checksum:0xE269Length:28NetworkMask:/0TOS:0Metric:64

BecausetheType4LSAnowisbeinggenerated,R1installstheexternalroutesinitsroutingtable.Example9-223showsthatafterfixingthisproblem,theexternalroute200.200.200.0/24isintheroutingtableofR1.Example9-223ExternalRoute200.200.200.0IsNowinR1’sRoutingTable

R1#showiproute200.200.200.0Routingentryfor200.200.200.0/24Knownvia"ospf2",distance110,metric20,typeextern2,forwardmetric128Redistributingviaospf2Lastupdatefrom131.108.2.2onSerial0.1,00:47:24agoRoutingDescriptorBlocks:*131.108.2.2,from131.108.3.3,00:47:24ago,viaSerial0.1Routemetricis20,trafficsharecountis1

TroubleshootingRedistributionProblemsinOSPFThissectiondescribesproblemsrelatedtoredistributioninOSPF.WhenarouterinOSPFdoestheredistribution,itbecomesanASBR.TheroutesthatareredistributedintoOSPFcouldbedirectlyconnectedroutes,staticroutes,ordynamicallylearnedroutesfromanotherroutingprotocoloranotherOSPFprocess.Thefollowingareproblemsthatcanhappenduringredistribution:•ASBRisnotadvertisingredistributedroutes.•OSPFisnotinstallingexternalroutesintheroutingtable.

ThesecondproblemalreadywasdiscussedintheearliersectiononOSPFroutesinstallationproblems.Thefirstproblemisdiscussedinthesectionthatfollows.

Problem:OSPFNeighborIsNotAdvertisingExternalRoutesWheneverarouteisknowntobeconnectedorstatic,orwhenanyotherroutingprotocolisredistributedintoOSPF,anexternalLSAisgeneratedforthatroute.IfanOSPFrouterisnotadvertisingtheexternalrouteevenaftertheredistribution,thisindicatesaproblemonarouterthatisdoingtheredistribution.Mostly,theproblemstemsfromconfigurationmistakes.Themostcommoncausesofthisproblemareasfollows:•ThesubnetskeywordismissingfromtheASBRconfiguration.•distribute-listoutisblockingtheroutes.

Figure9-80showsanetworkexperiencingthisproblem.Inthisfigure,R1isrunningRIPonEthernetandredistributingRIProutesintoOSPF.

Figure9-80NetworkSetupShowsRedistributioninOSPFOSPFNeighborIsNotAdvertisingExternalRoutes—Cause:SubnetsKeywordMissingfromtheASBRConfiguration

WhenanyprotocolisredistributedintoOSPF,ifthenetworksthatarebeingredistributedaresubnets,youmustdefinethesubnetskeywordunderOSPFconfiguration.Ifthesubnetskeywordisnotadded,OSPFwillignoreallthesubnettedrouteswhengeneratingtheexternalLSA.ThesituationcouldarisewhenconnectedorstaticroutesarebeingredistributedintooroutofOSPF.Inthatcase,thesameruleapplies:Thesubnetskeywordmustbeenteredtoredistributesubnettedroutes.Figure9-81showstheflowcharttofollowtosolvethisproblem.


Example9-224showstheoutputofshowipospfdatabaseexternalfor132.108.3.0.TheoutputshowsnoLSAinformation,whichmeansthatR1isnotevenoriginatingtheexternalLSAfor132.108.3.0.

Example9-224R1IsNotOriginatinganExternalLSAfor132.108.3.0



R1#

Example9-225showstheOSPFconfigurationonR1.TheconfigurationshowsthatredistributionofRIPismissingthesubnetskeyword.Example9-225R1’sConfigurationIsMissingthesubnetsKeywordforRIPRedistribution

R1#routerospf1redistributeripnetwork131.108.1.00.0.0.255area0network131.108.2.00.0.0.255area0!routerripnetwork132.108.0.0!

Solution

Tofixthisproblem,addthesubnetskeywordtotheredistributioncommand.Example9-226showsthecorrectconfigurationthatfixesthisproblem.Example9-226AddingsubnetsKeywordintheConfigurationofR1

R1#routerospf1redistributeripsubnetsnetwork131.108.1.00.0.0.255area0network131.108.2.00.0.0.255area0

Afterthesubnetskeywordhasbeenadded,OSPFredistributesalltheroutesthataresubnetted;forexample,131.108.3.0isasubnettedroutewithamaskof/24.Example9-227showsthatR1startsgeneratingtheexternalLSAfor132.108.3.0and132.108.4.0.Example9-227ConfirmingThatR1IsOriginatingtheExternalLSAfor132.108.3.0and132.108.4.0




LSage:1161Options:(NoTOS-capability,DC)LSType:ASExternalLinkLinkStateID:132.108.3.0(ExternalNetworkNumber)AdvertisingRouter:131.108.2.1LSSeqNumber:80000001Checksum:0x550Length:36NetworkMask:/24MetricType:2(Largerthananylinkstatepath)

TOS:0Metric:1ForwardAddress:0.0.0.0ExternalRouteTag:1

R1#





R1#

OSPFNeighborIsNotAdvertisingExternalRoutes—Cause:distribute-listoutIsBlockingtheRoutes

Whendistribute-listoutisconfiguredonanASBR,theaccesslistassociatedwiththedistributelistisexaminedandType5externalLSAsareoriginatedfornetworksthatareexplicitlypermittedinthedistributelist.Allothernetworksaredenied,andnoType5externalLSAsaregeneratedforthosenetworks.Figure9-82showstheflowcharttofollowtosolvethisproblem.


Thefirstlogicalstepistolookattheconfiguration.Noteinthepreviousexamplethatthesubnetskeywordwaspreventingtheroutesfrombeinginstalledintheroutingtable.Inthisexample,however,thedistributelististheculpritthatisblocking131.108.3.0fromgettingredistributedintoOSPF.Example9-228showstheconfigurationofR1,whichhasdistribute-listoutconfiguredunderOSPF,whichisblocking132.108.3.0intotheOSPFdatabase.Example9-228R1’sDistributeListBlocksthe132.108.3.0RoutefromBeingInstalledintheOSPFDatabase

R1#routerospf1redistributeripsubnetsnetwork131.108.1.00.0.0.255area2network131.108.2.00.0.0.255area2distribute-list1out!access-list1permit132.108.4.00.0.0.255

Example9-229showsthatR1isoriginatingtheType5externalLSAfor132.108.4.0butnotfor132.108.3.0because131.108.3.0networkimplicitlyisdeniedinaccesslist1.Example9-229DeterminingExternalLSAOriginatedbyR1



R1#





R1#

Solution

Tosolvethisproblem,youmusteitherremovethedistributelistsothatR1generatesType5externalLSAsforalltheRIProutesormodifiesthedistributelistsothatitcontainsallthenecessarynetworksforwhichType5LSAsarerequired.Thisproblemalsocanhappenwhenusingroutemapsinsteadofdistributelists.Inanycase,besuretopermitthedesirednetworkintheaccesslist.Example9-230showstheconfigurationofR1thatallowsnetwork132.108.3.0intheaccesslistsothatR1generatestheType5externalLSAforthisnetwork.Example9-230ConfiguringR1’sDistributeListtoPermitthe132.108.3.0Network

R1#routerospf1redistributeripsubnetsnetwork131.108.1.00.0.0.255area2network131.108.2.00.0.0.255area2distribute-list1out!access-list1permit132.108.4.00.0.0.255access-list1permit132.108.3.00.0.0.255

Aftertheaccesslistismodified,checktoseewhetherR1startsgeneratingtheexternalLSAfor131.108.3.0.Example9-231showsthatR1startsgeneratingtheexternalLSAfornetwork132.108.3.0afterthenecessaryconfigurationchanges.Example9-231VerifyingThatR1NowGeneratesanExternalLSAfor132.108.3.0





R1#

TroubleshootingRouteSummarizationinOSPFThissectiondiscussesafeatureinOSPFcalledroutesummarization.Theideaisthatiftherearecontiguousrangesofaddresses,insteadofadvertisingeverynetwork,youcanformagroupofcontiguousnetworksandsummarizethosenetworksinone,two,orfewerblocksandadvertisethoseblocks.Thisfeaturehelpsreducethesizeoftheroutingtable.ReducingtheroutingtablesizedecreasestheconvergencetimeandincreasesOSPFperformance.Thus,summarizationneedstobeconfiguredmanuallyontherouter.OSPFcanusetwotypesofsummarization:•InterareasummarizationthatcanbedoneontheABR•ExternalsummarizationthatcanbedoneontheASBR

TwocommonproblemsrelatedtosummarizationinOSPFareasfollows:•Arouterisnotsummarizinginterarearoutes.•Arouterisnotsummarizingexternalroutes.

Problem:RouterIsNotSummarizingInterareaRoutes—Cause:arearangeCommandIsNotConfiguredonABRYoumustensurethatthearearangecommandisconfiguredonthecorrectrouter.ArearangesummarizationcanbedoneonlyontheABR.Insummarization,insteadoforiginatingseparateLSAsforeachnetwork,theABRoriginatessummaryLSAstocoverthoserangesofaddresses.Sometimes,thenetworkmaskisconfiguredwrongandsummarizationdoesn’tworkbecauseofthemisconfiguration.Whenconfiguringthearearangecommand,makesurethatthesummarizationmaskisintheformofaprefixmaskratherthanawildcardmask(thatis,255.255.255.0insteadof0.0.0.255).Figure9-83showsanetworksufferingfromthisproblem.Inthisexample,thearearangecommandisconfiguredonR1.Thiscommandshouldbeconfiguredonlyontherouterthatbelongstotheareaforwhichroutesarebeingsummarized.Inaddition,theroutermustbeanABR.

Figure9-83OSPFNetworkinWhichaRouterIsNotSummarizingInterareaRoutes



Example9-232showsthatR1hasthearearangecommandforsummarizationofarea3routes.ThecommandhighlightedinExample9-232definestherangetobesummarized.Thismeansthatanyaddressintherange131.108.3.0–255willbesummarizedintoasingleroute—131.108.3.0/24.Also,themaskshouldbeintheformatof255.255.255.0insteadof0.0.0.255.Theformat0.0.0.255isusedfortheaccesslistrange,butinOSPF,theformatshouldbe255.255.255.0.

Thesyntaxofthisarearangecommandiscorrect,buttheproblemisthatR1isnotanABR.R1indeedisincludedinarea0,butitisnotconnectedtoarea3andthuscannotsummarizearea3routes.Example9-232R1SummarizesArea3Routes

R1#routerospf1network131.108.2.00.0.0.255area0area3range131.108.3.0255.255.255.0

Thereisaneasywaytocheckwhetherarouterissummarizingtheroutesproperly.Example9-233showstheoutputofshowipospf,whichshowsthatthearea3rangeispassive.Passivemeansthatnoaddresseswithinthisareafallwithinthisrange.Infact,R1doeshavetheroutesinthisrange;however,becauseR1isnotconnectedtoarea3,therangeappearsaspassive.Alsonotethatthenumberofinterfacesinthisareais0,meaningthatthisrouterisnotconnectedtoarea3.Asaresult,summarizationwillnotworkproperly.Example9-233Area3InterfacesAreDefinedasPassive

R1#showipospf

Area3Numberofinterfacesinthisareais0AreahasnoauthenticationSPFalgorithmexecuted1timesArearangesare131.108.3.0/24Passive

Becausesummarizationisnothappening,R1isreceivingfourroutesinitsroutingtableinsteadofonesummarizedroute.Example9-234showsthatR1isreceivingfourroutesintheroutingtableknownthroughOSPFinterarea.Example9-234R1’sRoutingTableShowsFourRoutesInsteadofOneSummarizedRoute

R1#showiproute...OIA131.108.3.0/26[110/64]via131.108.2.2,00:01:35,Serial0OIA131.108.3.64/26[110/64]via131.108.2.2,00:01:35,Serial0OIA131.108.3.128/26[110/64]via131.108.2.2,00:01:35,Serial0OIA131.108.3.192/26[110/64]via131.108.2.2,00:01:35,Serial0

Solution

Tosolvethisproblem,thecommandmustbeconfiguredonR2,whichisconnectedtoarea3andalsoisanABR.Example9-235showsthatthearearangecommandisconfiguredontheABR,whichisR2.Example9-235ConfiguringthearearangeCommandonR2(ABR)

R2#routerospf1network131.108.3.00.0.0.255area3network131.108.2.00.0.0.255area0area3range131.108.3.0255.255.255.0

Again,afterconfiguringtherange,checktherangestatustoseewhetheritisactiveorpassive.Ifitappearsactive,therouterproperlyissummarizingtheroutes.Example9-236showstheoutputofshowip

ospf,whichindicatesthatarea3hasarearangesdefinedandactive.Example9-236DeterminingtheAreaRangeStatusinArea3

R2#showipospf

Area3Numberofinterfacesinthisareais4AreahasnoauthenticationSPFalgorithmexecuted1timesArearangesare131.108.3.0/24Active(64)

AfterverifyingthatR2indeedissummarizingandthattherangeisactive,checkR1’sroutingtabletoseewhetherR1stillisseeingfourroutes.Example9-237showsthataftersummarization,R1startsreceivingonerouteinsteadoffourroutes.Example9-237R1ReceivesaSingleSummarizedRoute

R1#showiproute...OIA131.108.3.0/24[110/64]via131.108.2.2,00:01:35,Serial0

Problem:RouterIsNotSummarizingExternalRoutes—Cause:summary-addressCommandIsNotConfiguredonASBRAnOSPFASBRoriginatestheexternalLSAwheneveranyexternal,static,orconnectedprotocolsareredistributedintoOSPF.TheseLSAsaregeneratedattheASBR.So,whensummarizationisconfigured,italwaysshouldbeconfiguredontheASBRthatisoriginatingtheseexternalLSA;otherwise,summarizationwillnotworkproperly.Again,thesummarymasksyntaxisthesameasthearearange—thatis,255.255.255.0insteadof0.0.0.255(prefixmaskratherthanwildcardmask).Figure9-85showsanetworksetupinwhicharouterisnotsummarizingexternalroutesproperly.R2isanASBRthatisredistributingRIProutesintoOSPF.

Figure9-85OSPFNetworkSufferingfromaRouterNotProperlySummarizingExternalRoutes



Example9-238showsthesummary-addressconfigurationonR1.NotethatR1isnotanASBR.Alsonotethattherangeisusingtheformat255.255.255.0insteadof0.0.0.255,asexplainedinthepreviousproblem.Inaddition,inthepreviousexample,thearearangecommandwasusedtosummarizethearearoutes,butthatcommandcannotbeusedherebecausetheseareexternalroutes.Tosummarizetheexternalroutes,summary-addressmustbeused.Example9-238R1IsConfiguredforAddressSummarizationEvenThoughItIsNotanASBR

R1#routerospf1network131.108.2.00.0.0.255area0summary-address132.108.3.0255.255.255.0

Example9-239showstheoutputofshowipospfsummary-address,whichindicatesthatthemetriconthissummaryrouteis16777215—thisisinfinitybecausetheexternalLSAmetricis24bitslongand224isequalto16,777,215.Ametricofinfinitymeansthatnovalidaddressesbelongtothisrange.Example9-239SummaryRouteHasaMetricofInfinity

R1#showipospfsummary-address

OSPFProcess1,Summary-address

132.108.3.0/255.255.255.0Metric16777215,Type0,Tag0R1#

Solution

Tofixthisproblem,configurethesummarizationonR2,whichistheASBR.Example9-240showsthatsummarizationisnowconfiguredontheOSPFASBR,whichisR2.Example9-240ConfiguringAddressSummarizationontheCorrectRouter,theASBR

R2#routerospf1network131.108.2.00.0.0.255area0summary-address132.108.3.0255.255.255.0!routerripnetwork132.108.0.0

Besuretoremovethesummary-addresscommandfromR1.Afterconfiguringthesummary-addresscommandonR2,theoutputofshowipospfsummary-addressshouldbecheckedagainfortherightmetric.Example9-241givestheoutputofshowipospfsummary-address,whichshowsthattherangeisvalidwithacorrectmetric.Themetricforthesummarizedrouteisthelargestmetricofalltheaddressesinthatsummaryrange.ThisisasofRFC2178.InRFC1583,themetricforthesummaryrouteusedtobethelowestmetricofalltheaddressesinsummaryrange.Example9-241VerifyingThattheSummarizedAddressRangeIsNowValid

R2#showipospfsummary-addressOSPFProcess1,Summary-address

132.108.3.0/255.255.255.0Metric5,Type0,Tag0R2#

TroubleshootingCPUHOGProblemsWhenOSPFformsanadjacency,itfloodsallthelink-stateupdatepacketstoitsneighbors.Sometimes,thefloodingprocesstakesalotoftime,dependingupontherouterresources.Whenarouter’sCPUgetstoobusywhenfloodingusingthemostoftherouter’sresources,CPUHOGmessagesappearinthelog.TheCPUHOGmessagesusuallyappearintwosignificantstages:•Neighborformationprocess•LSArefreshprocess

ThissectiondiscussesthepossiblesolutionsforthesetwoinstancesofSPF:•CPUHOGmessagesduringadjacencyformation•CPUHOGmessagesduringLSArefreshperiod

Problem:CPUHOGMessagesDuringAdjacencyFormation—Cause:RouterIsNotRunningPacket-PacingCodeWhenOSPFformsanadjacency,itfloodsallitslink-statepacketstoitsneighbor.ThisfloodingsometimestakesalotofCPU.Also,releasesofCiscoIOSSoftwarebefore12.0Tdidnotsupportpacketpacing,whichmeansthatarouterwilltrytosenddataasfastasitcanoveralink.Ifalinkissloworthe

routerontheothersideisslowinresponding,thisresultsinretransmissionoftheLSAandeventuallyleadstoCPUHOGmessages.PacketpacingaddsapacingintervalbetweentheLSupdates.Insteadoffloodingeverythingatonce,itssendsthepacketwithagapofafewmillisecondsinbetween.Figure9-87showstheflowcharttofollowtosolvethisproblem.


CPUHOGmessagescanbeseenonaconsoleofarouterduringadjacencyformationandlatercanbecheckedwiththeshowlogcommand.Example9-242showsthelogmessagesonaroutershowingCPUHOG.Example9-242LogMessagesShowingCPUHOGbyOSPFRouter

R1#showlog%SYS-3-CPUHOG:Taskranfor2424msec(15/15),process=OSPFRouter%SYS-3-CPUHOG:Taskranfor2340msec(10/9),process=OSPFRouter%SYS-3-CPUHOG:Taskranfor2264msec(0/0),process=OSPFRouter

Solution

Packetpacingintroducesadelayof33msbetweenpacketsand66msbetweenretransmissions.ThispacingintervalreducestheCPUHOGmessages,andtheadjacencyisformedmorequickly.ThisfeatureisonbydefaultinCiscoIOSSoftwareRelease12.0Tandlater.ThisfeatureisnotavailableintheCiscoIOSSoftwarereleasesearlierthan12.0T.IfyouarerunningCiscoIOSSoftwarecodeearlierthan

Release12.0TandyouareseeingCPUHOGmessagesduringadjacencyformation,upgradetoatleastCiscoIOSSoftwareRelease12.0Torhighercodetosolvethisproblemthroughpacketpacing.

Problem:CPUHOGMessagesDuringLSARefreshPeriod—Cause:RouterIsNotRunningLSAGroup-PacingCodeThisproblemoccurswhentheCiscoIOSSoftwarecodeisnotRelease12.0orlater.InCiscoIOSSoftwareRelease12.0,theLSAgrouppacingfeaturewasintroducedtoeliminatethisCPUproblemthatcanoccurevery30minutes.InpreviousversionsofCiscoIOSSoftware,allLSAsrefreshevery30minutestosynchronizetheageofallLSAs.Therefore,thereisasignificantfloodevery30minutestorefreshallLSAsatthesametime.ThisfloodingcausestheCPUHOGmessagesevery30minutes.ImagineasituationinwhichacouplethousandLSAsarerefreshingatthesametime.Figure9-88showstheflowcharttofollowtosolvethisproblem.


Example9-243showstheCPUHOGmessagesthatappearintherouter’slogevery30minutes.Example9-243RouterIsSeeingCPUHOGMessagesEvery30Minutes

R1#showlog%SYS-3-CPUHOG:Taskranfor2424msec(15/15),process=OSPFRouter%SYS-3-CPUHOG:Taskranfor2340msec(10/9),process=OSPFRouter

%SYS-3-CPUHOG:Taskranfor2264msec(0/0),process=OSPFRouter

Solution

LSAgrouppacinglooksattheLSAeveryperiodicinterval(every4minutes,bydefault)andrefreshesonlythoseLSAsthatarepasttheirrefreshtime.ThisisanefficientwayofreducingalargefloodbychoppingitdowntosmallerLSAfloods.Noextraconfigurationisrequiredforthisfeature,butforlargenumbersofLSAs(generally10,000ormore),itisrecommendedtousesmallintervals(forexample,every2minutes);forfew100sofLSAs,usealargeinterval,suchas20minutes.If10,000LSAsneedtoberefreshed,keepingtherefreshintervalsmallerwillchecktheLSAevery2or4minutestoseehowmanyLSAshavereachedtherefreshinterval,whichis30minutes.TheadvantageofcheckingthisfrequentlyisthatfewerLSAswouldneedtoberefreshedevery2or4minutes,andthiswillnotcauseahugestormofLSAupdates.IfthenumberofLSAsissmall,itreallydoesn’tmatterwhethertherefreshoccursat2minutesor20minutes.Thatiswhyit’sbettertoincreasethetimersothatalltheLSAsthatarefewinnumbercanberefreshedatonce.Example9-244showshowtoconfiguretheLSArefreshinterval.Example9-244ConfiguringtheLSARefreshInterval

R1(config)#routerospf1R1(config-router)#timerlsa-group-pacing?<10-1800>IntervalbetweengroupofLSAbeingrefreshedormaxaged

TroubleshootingDial-on-DemandRoutingIssuesinOSPFThissectiondiscussestheissuesrelatedtoDDR.WhenOSPFisconfiguredoveraDDRlink,besuretosuppressOSPFHellosbecauseOSPFsendsHellosoverpoint-to-pointlinksevery10seconds.ThemostcommonissuesrelatedtoOSPFoverDDRlinksareasfollows:•Problem:OSPFHellosarebringingupthelink•Problem:OSPFHellosarenotgettingacrossthelink*•Problem:Demandcircuitkeepsbringingupthelink

Note*TheproblemofOSPFHellosnotgettingacrossthelinkwasaddressedearlierinthesection“TroubleshootingOSPFNeighborRelationships.”Refertothissectionforthesolutiontothisproblem.

Problem:OSPFHellosAreBringingUptheLink—Cause:OSPFHellosArePermittedasInterestingTrafficWhenrunningOSPFfordialbackuppurposesoverDDRlinks,defineanaccesslisttoexplicitlydefinetheinterestingtraffic.OSPFusesamulticastaddressof224.0.0.5tosendtheHellos.ThisaddressmustbedeniedintheaccesslistsothatOSPFdoesn’tbringupthelinkevery10seconds.Figure9-89showsanetworkexperiencingthisDDRproblem.

Figure9-89OSPFNetworkExperiencingaPerpetualDDRLinkProblem



Example9-245showstheconfigurationonR1thatcanproducethisproblem.Inthisconfiguration,onlyTCPtrafficisdenied.Inotherwords,TCPtrafficwillnotbringupthelink,butanyotherIPtrafficcandoso.Example9-245R1’sAccessListDeniesOnlyTCPTraffic

R1#interfaceBRI3/0ipaddress192.168.254.13255.255.255.252encapsulationpppdialermapip192.168.254.14nameR2broadcast57654dialer-group1isdnswitch-typebasic-net3

pppauthenticationchap


TheoutputoftheshowdialercommandinExample9-246indicatesthatthereasonforthelinkcomingupisOSPFmulticastHellos.Example9-246DeterminingWhytheDDRLinkKeepsComingUp


Solution

Tosolvethisproblem,denyOSPFHellosintheinterestingtraffic.Example9-247showsthecorrectconfigurationchangeinR1.Inthisconfiguration,alltrafficdestinedtothe224.0.0.5addressisdenied.ThismeansthatOSPFHellosorupdatesoverthispoint-to-pointlinkwillnotbringupthelinkafterthisconfigurationchange.Example9-247ConfiguringR1’sAccessListtoDenyOSPFMulticastsHellos

R1#access-list100denytcpanyanyaccess-list100denyipany224.0.0.5access-list100permitipanyanydialer-list1protocoliplist100

Itisnotnecessarytoput224.0.0.6intheaccesslistbecauseonlytheDRusesthisaddress.Also,becausethereisnoDRoverpoint-to-pointlinks,thereisnoneedtodenythisaddressintheaccesslist.

Problem:DemandCircuitKeepsBringingUptheLinkTheOSPFdemandcircuitfeaturewasintroducedinCiscoIOSSoftwareRelease11.2.ThisfeatureformstheOSPFadjacencyoveralinkandthenlaterkeepstheLayer2downtosavethetollchargeswhilekeepingtheOSPFadjacencyoverthislink.Ifthelinkkeepscomingup,itdefeatsthepurposeofademandcircuit.Themostcommonpossiblecausesofthisproblemareasfollows:•Alinkflapexistsinthenetwork.•Thenetworktypeisdefinedasbroadcast.•APPPhostrouteisgettingredistributedintotheOSPFdatabase.•Oneoftheroutersisnotcapableofusingademandcircuit.

DemandCircuitKeepsBringingUptheLink—Cause:ALinkFlapintheNetwork

Themostcommonreasonforademandcircuittobringupthelinkistheexistenceofalinkflap.Alinkflapoccurswhenalinkinanypartofthenetworkgoesupordown.Thiscauseschangesinthedatabaseinformation,andOSPFmustbringupthelinkandrefreshitsdatabasewiththeneighboroverthedemand

circuit.ThisisshowninthenetworksetupinFigure9-91.Alinkisflappinginarea0andcausesSPFinarea0.BecauseR1isalsoapartofarea0,R1willrunSPFandthenbringupthedemandcircuitlinkacrossR2toinformitsneighborofthischange.

Figure9-91OSPFNetworkSufferingfromaChronicallyActiveLinkCausedbyaDemandCircuit



Example9-248showstheoutputofshowdialer,whichshowsthelasttimethecallwasconnectedbecauseoftheOSPFHelloandindicatesthatthecallhasbeenconnectedforeightseconds.Example9-248DeterminingCallHistoryontheDialerInterface


WhenalinkisflappinginOSPF,iteasilycanbediscoveredwiththedebugipospfmonitorcommand.ThiscommandoutputdisplaystheexactLSAthatisflappinginanarea.Example9-249showstheoutputofdebugipospfmonitor,whichshowsthatachangeoccurredintheOSPFdatabaseastheresultofarouterLSAregeneratedbyarouterwitharouterIDof192.168.1.129becauseofalinkflapinarea0.Example9-249debugThatDiscoverstheCulpritforaLinkFlap

R1#debugipospfmonitorOSPF:ScheduleSPFinarea0.0.0.0

ChangeinLSID192.168.1.129,LSAtypeR,OSPF:scheduleSPF:spf_time1620348064mswait_interval10s

Solution

ThisisnormalindemandcircuitsthatmustbringupthelinkandfloodthischangetotheneighborwheneverthereisachangeinOSPFtopology.AlinkflapinsomeareawillregeneratearouterLSA,whichthenregeneratesthesummaryLSAforthatnetwork.Becausealinkflapalmostnevercanbeavoided,asolutioninthiscasewouldbetoisolatethisareaasmuchaspossible.Inotherwords,trytorunitasastubortotallystubbyarea.Whenanareaisdefinedasastub,noexternallinkflapcanbringupthedialuplink.Whentheareaisconfiguredastotallystubby,nointerareaflapcanbringupthedialuplink.Thisisbecausewhenanareaisdefinedasastub,noexternalLSAcanenterastubarea;noexternalflapwillbenoticedinastubarea.Similarly,whenanareaistotallystubby,nosummaryLSAcanexistinthatarea;anychangeinasummaryLSAwillnotbenoticedinatotallystubbyarea.Example9-250showsthatarea2isconfiguredasatotallystubarea,sonointerarealinkflapcancausethelinktogoup.Example9-250ConfiguringArea2asTotallyStubbytoPreventInterareaLinkFlapsfromBringingUptheLink

OnR1andR2:routerospf1network192.168.254.00.0.0.255area2area1stubno-summary

Thecommandno-summaryisnotreallyrequiredonR2.ItshouldbeenoughthatthecommandisconfiguredonR1,butthiscommandwillnotcauseanyharmifitisconfiguredonbothends.DemandCircuitKeepsBringingUptheLink—Cause:NetworkTypeDefinedasBroadcast

Whenanetworktypeisdefinedasbroadcast,OSPFHellosarenotsuppressed.However,nofloodingoccursevery30minutesbecausethedemandcircuitisconfigured.So,byconfiguringthenetworktypeasbroadcast,theonlygainisoptimalflooding;Hellosstillbringupthelink.Figure9-93showstheflowcharttofollowtosolvethisproblem.


ThedefaultnetworktypeofaPPPlinkispoint-to-point,butsomeonemanuallychangedthenetworktypetobroadcast.Example9-251showstheconfigurationonR1,whichshowsthatthenetworktypeisdefinedasbroadcast.Example9-251R1’sBRI1/1InterfaceIsDefinedasBroadcast

R1#interfaceBRI1/1ipaddress192.168.254.13255.255.255.0ipospfnetworkbroadcast!

Example9-252showstheoutputoftheshowipospfinterfaceontheBRI1/1interface,whichindicatesthattheHellosarenotsuppressed.Example9-252showipospfinterfaceCommandOutputRevealsThatOSPFHellosAreNotBeingSuppressed

R1#showipospfinterfacebri1/1BRI1/1isup,lineprotocolisupInternetAddress192.168.254.13/24,Area1ProcessID1,RouterID192.168.254.13,NetworkTypeBROADCAST,Cost:64

TransmitDelayis1sec,StateBDR,Priority240DesignatedRouter(ID)192.168.254.14,Interfaceaddress192.168.254.14BackupDesignatedrouter(ID)192.168.254.13,Interfaceaddress192.168.254.13Timerintervalsconfigured,Hello30,Dead120,Wait120,Retransmit5Helloduein00:00:21

ThisobviouslymeansthatOSPFHelloswillkeepupthelinkateveryHellointerval.Example9-253showsthatthedialbackuplinkisbroughtupbyOSPFHellos.Example9-253OSPFHellosBringUptheDialBackupLink

R1#showdialerBRI1/1:1-dialertype=ISDNIdletimer(120secs),Fastidletimer(20secs)Waitforcarrier(30secs),Re-enable(2secs)DialerstateisdatalinklayerupDialreason:ip(s=192.168.254.13,d=224.0.0.5)InterfaceboundtoprofileDi1Currentcallconnected00:00:08Connectedto57654(R2)

Solution

Tosolvethisproblem,changethenetworktypebacktopoint-to-point.ThiswillkeepOSPFHellosfrombringingupthelink.Example9-254showsthenewconfigurationthatsolvesthisproblem.Thenetworktypeisnotshownintheconfigurationbecause,bydefault,thenetworktypeonaBRIlinkispoint-to-point.Example9-254ByDefault,theBRIforR1andR2NowIsConfiguredasPoint-to-Point

R1#interfaceBRI1/1ipaddress192.168.254.13255.255.255.0noipospfnetworkbroadcast!

R2#interfaceBRI0/1ipaddress192.168.254.14255.255.255.0noipospfnetworkbroadcast!

Example9-255showsthatafterchangingthenetworktype,theoutputofshowipospfinterfacefortheBRI1/1interfaceindicatesthatitissuppressingHellosforitsneighboroverthedemandcircuit.Threesignificantthingsarehighlightedinthisexample:•Thislinkisnowrunasapoint-to-pointnetwork.•Thelinkisconfiguredasademandcircuit.•OSPFHellosaresuppressedonthislink.

Example9-255OSPFHellosAreSuppressedforR1’sBRI1/1Interface

R1#showipospfinterfaceBRI1/1BRI1/1isup,lineprotocolisupInternetAddress192.168.254.13/24,Area1ProcessID1,RouterID192.168.254.13,NetworkTypePOINT_TO_POINT,Cost:64Configuredasdemandcircuit.Runasdemandcircuit.

DoNotAgeLSAallowed.TransmitDelayis1sec,StatePOINT_TO_POINT,Timerintervalsconfigured,Hello10,Dead40,Wait40,Retransmit5Helloduein00:00:06NeighborCountis1,Adjacentneighborcountis1Adjacentwithneighbor192.168.254.14(Hellosuppressed)Suppresshellofor1neighbor(s)

DemandCircuitKeepsBringingUptheLink—Cause:PPPHostRoutesAreGettingRedistributedintotheOSPFDatabase

WhenaPPPencapsulationisusedoveralink,itinstallsahostroutefortheremoteneighbor’sIPaddress.ThisisnormalforaPPP-encapsulatedlink.InOSPF,thishostroutenevergetsredistributedinthedatabase.Specially,whenOSPFisrunasademandcircuitoveralink,includingthishostrouteinthedatabasecancauseproblemsinconstantlybringingupthelink.Figure9-94showsanetworkinwhichademandcircuitperpetuatesanactivelinkasaresultofPPPhostroutesgettingredistributedintotheOSPFdatabase.

Figure9-94NetworkSufferingfromaChronicallyActiveLinkCausedbyaDemandCircuitBecauseofPPPHostRouteRedistribution

R1isrunningRIPaswellasOSPFandisdoingredistributionofRIPintoOSPF.ThehostroutegetsredistributedintotheOSPFdatabasebecauseRIPownsthehostroute,whichgetsinstalledthroughPPP.RIPinjectsthisrouteasanexternalroute,andthiscausesthelinkflap.Figure9-95showstheflowcharttofollowtosolvethisproblem.


First,verifythattheencapsulationisindeedPPPbylookingintoR1’sconfiguration.Example9-256showstheconfigurationonR1.TheconfigurationrevealsthatR1’sBRI1/1isrunningPPPencapsulation.Also,R1isredistributingRIProutesintoOSPF;RIPhasanetwork131.108.0.0statement,soanyconnectedrouteintherangeof131.108.0.0willbeownedbyRIP.ThisincludesthePPPhostroutesaswell.Example9-256R1RedistributesRIPRoutesintoOSPF

R1#interfaceBRI1/1encapsulationPPPipaddress131.108.1.1255.255.255.0routerospf1redistributeripsubnetsnetwork131.108.1.00.0.0.255area1!routerripnetwork131.108.0.0

Example9-257showsthata/32routegetsinstalledintoR1’sroutingtablefor131.108.1.2.Example9-257R1IsInstallingaPPPHostRouteforR2

R1#showiproute131.108.1.2Routingentryfor131.108.1.2/32Knownvia"connected",distance0,metric0(connected,viainterface)RoutingDescriptorBlocks:*directlyconnected,viaBRI1/1Routemetricis0,trafficsharecountis1

BecauseRIPhasownershipofalltheconnectedroutesintherangefor131.108.0.0,italsoownsthisconnectedhostroute.WhenRIPisredistributedintoOSPF,thishostroutegetsredistributedasanexternalrouteinOSPF.Example9-258showsthatthisconnectedrouteisredistributedintotheOSPFdatabasebecauseRIPhasanetworkstatementthatincludesthishostroute.Example9-258HostRouteRedistributedinOSPFDatabaseasExternal




LSage:298Options:(NoTOS-capability,DC)LSType:ASExternalLinkLinkStateID:131.108.1.2(ExternalNetworkNumber)AdvertisingRouter:131.108.3.1LSSeqNumber:80000001Checksum:0xDC2BLength:36NetworkMask:/32MetricType:2(Largerthananylinkstatepath)TOS:0Metric:20ForwardAddress:0.0.0.0ExternalRouteTag:0

Solution

ThisproblemishappeningbecauseRIPhasanetworkstatementof131.108.0.0.Bydefinition,anyinterfacethatfallsunderthisaddressrangeisadvertisedbyRIP.WhenthePPPconnectiongetsestablished,a/32hostrouteisinjectedbyPPP.Thishostroutefallswithintherangeof131.108.0.0becausetheBRIaddressis131.108.1.0/24.BecauseRIPisbeingredistributedintoOSPF,this32alsogetsredistributedintoOSPF.Whenthelinkgoesdown,this32disappearsandOSPFalsoremovesitfromthedatabase,resultinginaconvergenceevent.WhenOSPFremovesthisroute,achangeintheOSPFdatabaseoccurs,tobringupthedemand-circuitinterfaceagain.Thisproblemcanbesolvedinthreeways:•Usenopeerneighbor-routeundertheinterfacecommandifrunningCiscoIOSSoftwareRelease11.3orlater.•Assignadifferentmajornetworkoverthedialuplink.•Filterthehostrouteduringredistribution.

Solution1isdependentupontheCiscoIOSSoftwareReleasebeinghigherthanversion11.3.Example9-259showsthenewconfigurationonR1thatsolvesthisproblem.Example9-259RemovingPPPHostRoutesfromR1

R1#interfaceBRI1/1ipaddress131.108.1.1255.255.255.0encapsulationpppnopeerneighbor-route

Afterthiscommand,R1willnotinstallthe131.108.1.2/32routeinitsroutingtable,sothisproblemwillnothappenanymore.Solution2canbedifficulttoimplement,butifitcanbedone;RIPnolongerwilladvertisethehostroutethatgetsinstalledbyPPP.Solution3isthemoredesirablesolutionbecauseitisnotdependentonanyspecificCiscoIOSSoftwarerelease.Example9-260showsthenewconfigurationthatwillsolvethisproblemusingthismethod.Inthisconfiguration,RIPisbeingredistributedintoOSPFwhilefilteringtheconnectedhostroutethrougharoutemap.Aroutemapnormallyfiltersroutesduringredistribution.Theroutemapcallsanaccesslist;inthisexample,accesslist1hastheconnectedhostroutethatisbeingfiltered.Example9-260FilteringtheHostRouteDuringRedistribution

R1#routerospf1redistributeripsubnetsroute-maprip_filternetwork131.108.1.00.0.0.255area1!routerripnetwork131.108.0.0!route-maprip_filterpermit10matchipaddress1!access-list1permit131.108.3.00.0.0.255

DemandCircuitKeepsBringingUptheLink—Cause:OneoftheRoutersIsNotDemandCircuit–Capable

ThedemandcircuitwillbringupthelinkifanyrouterinthenetworkdoesnotunderstandtheDNALSA.DNALSAsarediscussedindetailinChapter8.Normally,thishappensintwocases:•Arouterisanon-Ciscorouterwithnodemandcircuitcapability.•ArouterisaCiscorouterrunningCiscoIOSSoftwareearlierthanRelease11.2anddoesnotsupportdemandcircuit.

Figure9-96showsanetworksetupinwhichademandcircuitperpetuatesanactivelinkbecauseoneoftheroutersisnotdemandcircuit–capable.R1isrunningCiscoIOSSoftwareRelease11.1.20andisnotdemandcircuit–capable.Allotherroutersareinarea1.

Figure9-96NetworkwithaRouterThatDoesNotSupportDemandCircuits



Example9-261showsthatR3’sBRIinterfaceisdefinedasademandcircuit,butnoDoNotAgeLSAsareallowedinarea1.Example9-261DNALSAsAreNotAllowedinArea1,butHellosStillAreSuppressed

R3#showipospfinterfaceBRI1/1BRI1/1isup,lineprotocolisupInternetAddress131.108.1.1/24,Area1ProcessID1,RouterID131.108.3.3,NetworkTypePOINT_TO_POINT,Cost:64Configuredasdemandcircuit.Runasdemandcircuit.DoNotAgeLSAnotallowed(NumberofDCbitlessLSAis1).TransmitDelayis1sec,StatePOINT_TO_POINT,Timerintervalsconfigured,Hello10,Dead40,Wait40,Retransmit5Helloduein00:00:01NeighborCountis1,Adjacentneighborcountis1Adjacentwithneighbor131.108.2.2(Hellosuppressed)Suppresshellofor1neighbor(s)

BecausetheOSPFHellosaresuppressed,thelinkwillnotcomeupduringtheHellointerval;however,

thelinkwillcomeupduringLSAfloodingwhenit’stimetorefreshtheLSA.Example9-262showsthattheISDNlinkisbroughtupbecauseanLSAreachestherefreshtimeandtheinformationisbeingfloodedintothedemand-circuitlink.TheoutputshowsthatanOSPFHellopacketbroughtupthelink.Example9-262LSAFloodingBringsUptheISDNLink

R3#showdialerBRI1/1:1-dialertype=ISDNIdletimer(120secs),Fastidletimer(20secs)Waitforcarrier(30secs),Re-enable(2secs)DialerstateisdatalinklayerupDialreason:ip(s=131.108.1.1,d=224.0.0.5)InterfaceboundtoprofileDi1Currentcallconnected00:00:08Connectedto57654(R2)

Solution

TheproblemishappeningbecauseR1isrunninganoldcodethatdoesnotsupportdemandcircuits.ThiscaseismentionedinRFC1793forthedemandcircuit.ThesolutionisnottooriginateanyDoNotAgeLSAsbecausethedemandcircuit–incapablerouterwillnotinterpretthemcorrectly.Severalsolutionstothiscaseexist.TheeasiestistoupgradeR1todemandcircuit–capablecode.Thisexamplerepresentsthedemandcircuitbringingupthelinkwithinasinglearea.Whenmultipleareasexist,asimilarproblemcanoccur.Figure9-98showsanothersetupthatproducesthisproblem.R3willbringuptheISDNlinkbecauseR1isincapableofunderstandingtheDNALSA.ThisparticularcaseisdiscussedinmoredetailinChapter8,inthesection“DemandCircuits.”

Figure9-98DemandCircuitBringsUptheLinkinMultipleAreas

Thesolutioninthiscaseistoconfigurearea2asatotallystubbyarea.Bydefiningarea2astotallystubby,noexternalorsummaryLSAscangetintoarea2.ThismeansthattheindicationLSAalsowillbeblockedfromenteringarea2.Chapter8discussestheindicationLSAingreaterdetail.Example9-263showstheconfigurationthatchangesarea2intoatotallystubbyarea.Alltheroutersinarea2mustbeconfiguredasastubarea;otherwise,norouterswillformanadjacencywithR1.Example9-263ConfiguringArea2asaStubArea

R3#routerospf1network131.108.1.00.0.0.255area2area2stubno-summary

Thecommandno-summaryneedstobeaddedonlytoR3,butaddingitonotherroutersinarea2willnotcauseanyharm.Allotherroutersinarea2musthaveatleastthearea2stubcommandconfigured.

TroubleshootingSPFCalculationandRouteFlappingThissectionexplainsthemostcommonreasonsbehindrouteflappinginOSPFandSPFcalculation.Wheneverthereisachangeintopology,OSPFrunstheSPFalgorithmtocomputetheshortestpathfirsttreeagain.UnstablelinksexistingwithintheOSPFnetworkcouldcauseconstantSPFcalculation.ThissectiondiscussestheproblemofSPFrunningconstantlyinthenetworkforthefollowingreasons:•Interfaceflapwithinthenetwork•Neighborflapwithinthenetwork•DuplicaterouterID

SPFRunningConstantly—Cause:InterfaceFlapWithintheNetworkThisisacommonprobleminOSPF.Wheneverthereisalinkflapinanarea,OSPFrunsSPF.So,ifanetworkhasunstablelinks,itcancauseconstantSPFrun.SPFitselfisnotaproblembecauseOSPFisjustadjustingthechangeindatabasethroughcalculatingSPF.TherealproblemoccursiftherearesmallroutersinthenetworkandaconstantSPFrunmightcauseaCPUspikeinarouter.AlinkflapisshowninFigure9-99.BecauseR1alsoisincludedinarea0,anylinkflapinarea0causesallroutersinarea0torunSPF.

Figure9-99ALinkFlapCausesSPFinArea0



AlinkflapinanareacausesSPFtorun.Ifalinkisflappingconstantly,thiscanincreasethenumberofSPFcalculationsinanarea.AconstantnumberofSPFcalculationsisnotaproblem,butifthenumberisincrementingconstantly,itisanindicationofaproblem.Example9-264showstheoutputofshowipospf,whichshowsthatthereisahugecounterforSPFinarea0.Example9-264DeterminingHowOftenSPFIsRunning

R1#showipospfRoutingProcess"ospf1"withID192.168.254.13SupportsonlysingleTOS(TOS0)routesItisanareaborderSPFscheduledelay5secs,HoldtimebetweentwoSPFs10secsMinimumLSAinterval5secs.MinimumLSAarrival1secsNumberofexternalLSA8.ChecksumSum0x48C3ENumberofDCbitlessexternalLSA0NumberofDoNotAgeexternalLSA0Numberofareasinthisrouteris3.2normal1stub0nssaAreaBACKBONE(0)Numberofinterfacesinthisareais1AreahasnoauthenticationSPFalgorithmexecuted2668times

TheeasiestwaytofindoutwhichparticularLSAisflappingistoturnondebugipospfmonitor.ThisdebugshowsexactlywhichLSAisflapping.Example9-265showstheoutputofdebugipospfmonitorandrevealsthatarouterLSAisflappinginarea0.Example9-265debugipospfmonitorOutputPinpointsRouteFlap

R1#debugipospfmonitorOSPF:ScheduleSPFinarea0.0.0.0ChangeinLSID192.168.1.129,LSAtypeR,OSPF:scheduleSPF:spf_time1620348064mswait_interval10s

ThenextstepistogoonthatrouterwhoserouterLSAisflappingandcheckthelogforanyinterfaceflap.Example9-266showsthelogoftherouterwithrouterID192.168.1.129.Thelogshowsthataseriallinkkeepsgoingupanddown.Wheneverthereisaninterfaceflap,itcausesSPFtorun.Example9-266RouterLogPinpointstheInterfaceCausingRouteFlap

R3#showlog*Mar2901:59:07:%LINEPROTO-5-UPDOWN:LineprotocolonInterfaceSerial1,changedstatetodown*Mar2901:59:09:%LINEPROTO-5-UPDOWN:LineprotocolonInterfaceSerial1,changedstatetoup*Mar2901:59:30:%LINEPROTO-5-UPDOWN:LineprotocolonInterfaceSerial1,changedstatetodown*Mar2902:00:03:%LINEPROTO-5-UPDOWN:LineprotocolonInterfaceSerial1,changedstatetoup

Solution

Actuallytwosolutionsexistinthiscase:•Fixthelinkflap.•Redefinetheareaboundaries.

Sometimes,thefirstsolutionmightnotbemanageablebecausethelinkisflappingastheresultofsometelcooutagebeyondyourcontrol.Onewaytofixthistemporarilyistomanuallyshutdownthatinterface.Thesecondsolutionrequiressomeredesigning.Ifthelinkflapishappeningtoooften,itmightbepossibletoredefinethearea,excludethisrouterfromthearea,andmakeitamemberofatotallystubbyarea.Sometimes,thisisalsodifficulttoimplement.Inshort,linkflapsarerealities;iftherearetoomanylinkflaps,thenumberofroutersinanareashouldbedecreasedsothatfewerroutersareaffected.

SPFRunningConstantly—Cause:NeighborFlapWithintheNetworkAneighborflapalsocausesSPFtorun.Aneighborflapcanhappenbecauseofseveralreasonsdiscussedalreadyinthischapter.Whenalinkgoesdown,theneighborgoesdownaswell.Whenaneighborgoesdown,itcausesachangeintopology,soSPFruns.InFigure9-101,R3issufferingfromaneighborflap,andalltheroutersinarea0arerunningSPFbecauseofthis.

Figure9-101OSPFNeighborFlapCausesSPFtoRun



Example9-267showsthatSPFisbeingrunconstantlyinarea0.Example9-267DeterminingHowOftenSPFIsRunning


ThenextthingtodohereistogotoR3andcheckthelogs,asdoneinpreviousexample.ThereisawaytotracktheneighborchangesinOSPF.Configureospflog-adjacency-changesunderrouterospftotrackalltheneighborchanges.Example9-268showshowtoconfigureospflog-adjacency-changes.Example9-268Configuringospflog-adjacency-changesonR3

R3#routerospf1ospflog-adjacency-changes

Whenthiscommandisconfigured,itsavesalltheneighborstatechangesintherouter’ssyslog.Example9-269showsasyslogmessageofR3thatshowsneighborstatechanges.Theoutputshowsoneinstance,buttherearealotofinstancesofneighborchange.Example9-269SysLogMessagesofR3ShowsOSPFStateChanges

R3#showlog

%OSPF-5-ADJCHG:Process1,Nbr192.168.4.4onSerial1fromFULLtoDOWN,NeighborDown%OSPF-5-ADJCHG:Process1,Nbr192.168.4.4onSerial1fromFULLtoINIT,1-Way%OSPF-5-ADJCHG:Process1,Nbr192.168.4.4onSerial1fromDOWNtoINIT,ReceivedHello%OSPF-5-ADJCHG:Process1,Nbr192.168.4.4onSerial1fromINITto2WAY,2-WayReceived%OSPF-5-ADJCHG:Process1,Nbr192.168.4.4onSerial1from2WAYtoEXSTART,AdjOK?%OSPF-5-ADJCHG:Process1,Nbr192.168.4.4onSerial1fromEXSTARTtoEXCHANGE,NegotiationDone%OSPF-5-ADJCHG:Process1,Nbr192.168.4.4onSerial1fromEXCHANGEtoLOADING,ExchangeDone%OSPF-5-ADJCHG:Process1,Nbr192.168.4.4onSerial1fromLOADINGtoFULL,LoadingDone

InsomeolderversionsofCiscoIOSSoftware,theospflog-adjacency-changescommandisnotavailableormightnotbeconfiguredontherouter.Inthiscase,theshowipospfneighborcommandhelps.Example9-270showsthatR3seesR4goingfromFULLtoINITandthenbacktoFULLthroughtheshowipospfneighborcommand.Thisprocesskeepsrepeating.Example9-270DeterminingNeighborState

R3#showipospfneighborNeighborIDPriStateDeadTimeAddressInterface192.168.4.41FULL/-00:00:34131.108.1.1Serial1.1

R2#showipospfneighborNeighborIDPriStateDeadTimeAddressInterface192.168.4.41INIT/-00:00:33131.108.1.1Serial1.1

R2#showipospfneighborNeighborIDPriStateDeadTimeAddressInterface192.168.4.41FULL/-00:00:37131.108.1.1Serial1.1

Solution

ThisproblemiscommoninFrameRelayhub-and-spokeenvironments.IftherearetoomanyneighborsinFrameRelay,thereisahighchancethattheirHellosmightstartdropping.Thesolutioninthiscaseistotunethebroadcastqueuesothatitdoesn’tdroptheOSPFHellopackets.TheneighborgoesintoINITafterFULLbecausetheneighbormissedthreeHellosanddeclaredR2dead.Thiscanbeconfirmedbylookingattheshowinterfacestatisticsthatindicatethattheserialinterfacebroadcastqueueisdroppingmanypackets.Example9-271showstheoutputofshowinterfacefortheSerial1interface,whichshowsasignificantnumberofdropsintheFrameRelaybroadcastqueue.Example9-271DisplayingBroadcastQueueStatus

R3#showinterfaceSerial1

Serial1isup,lineprotocolisupHardwareisMK5025Description:CharlotteFrameRelayPortDLCI100MTU1500bytes,BW1024Kbit,DLY20000usec,rely255/255,load44/255EncapsulationFRAME-RELAY,loopbacknotset,keepaliveset(10sec)LMIenqsent7940,LMIstatrecvd7937,LMIupdrecvd0,DTELMIupLMIenqrecvd0,LMIstatsent0,LMIupdsent0LMIDLCI1023LMItypeisCISCOframerelayDTEBroadcastqueue64/64,broadcastssent/dropped1769202/1849660,interfacebroadcasts3579215

TheoutputinExample9-271furtherprovesthatthereissomeproblemattheinterfacelevel.Toomanydropsareoccurringattheinterfacelevel.Thisiscausingtheroutetoflap.Tocorrectthisproblem,youmusttunetheFrameRelaybroadcastqueueaccordingly.TuningtheFrameRelaybroadcastqueueisbeyondthescopeofthisbook,butseveralpapersonCisco’swebsitediscusshowtotunetheFrameRelaybroadcastqueue.Forfurtherresearch,youcanconsultthematthefollowingURLs:

www.cisco.com/warp/partner/synchronicd/cc/techno/media/wan/frame/prodlit/256_pb.htmwww.cisco.com/warp/public/125/20.html

Example9-272showsthatafterfixingtheinterfacedropproblem,routeflappingdisappears.Thebroadcastqueuesizeischangedfrom64to256.ThecorrectnumbercanbedeterminedafterreadingtheURLsmentionedearlierfortuningthebroadcastqueue.Example9-272VerifyingThattheBroadcastQueueHasBeenFixed

R3#showinterfaceSerial1Serial1isup,lineprotocolisupHardwareisMK5025Description:CharlotteFrameRelayPortDLCI100MTU1500bytes,BW1024Kbit,DLY20000usec,rely255/255,load44/255EncapsulationFRAME-RELAY,loopbacknotset,keepaliveset(10sec)LMIenqsent7940,LMIstatrecvd7937,LMIupdrecvd0,DTELMIupLMIenqrecvd0,LMIstatsent0,LMIupdsent0LMIDLCI1023LMItypeisCISCOframerelayDTEBroadcastqueue0/256,broadcastssent/dropped1769202/0,interfacebroadcasts3579215

SPFRunningConstantly—Cause:DuplicateRouterIDThisisalsoacommonprobleminOSPF.WhentworoutershaveidenticalrouterIDs,confusionresultsintheOSPFtopologydatabase,andtheroutekeepsgettingaddedanddeleted.ThemostcommonsymptomofthisproblemisthattheLSAgefieldalwayshasasmallvalue.Thisproblemusuallyisgeneratedbyacutandpasteofarouterconfigurationintoanotherrouter.ThisresultsintworouterswithidenticalrouterIDs.Figure9-103showsanetworksetupinwhichR2andR3haveduplicaterouterIDsof192.168.1.129.

http://www.cisco.com/warp/partner/synchronicd/cc/techno/media/wan/frame/prodlit/256_pb.htm

http://www.cisco.com/warp/public/125/20.html

Figure9-103OSPFNetworkwithDuplicateRouterIDs



WhenthereisaduplicaterouterID,itcausesSPFfrequently,andtheSPFcounterkeepsincrementingunlesstheproblemisfixed.Example9-273showsthatSPFinarea0ran2446times,whichisalargenumber.Example9-273DeterminingHowOftenSPFIsRunning


Thenextstepistoturnondebugipospfmonitor.ThisdebugshowsexactlywhichLSAtochase.Example9-274showstheoutputofdebugipospfmonitor,whichshowsthatarouterwitharouterIDof192.168.1.129istheproblem.Theoutputalsoshowsthatit’sarouterLSA.Example9-274debugipospfmonitorOutputPinpointstheRouterCausingThisProblem

R1#debugipospfmonitorOSPF:ScheduleSPFinarea0.0.0.0ChangeinLSID192.168.1.129,LSAtypeR,OSPF:scheduleSPF:spf_time1620348064mswait_interval10s

Example9-275showstheoutputoftherouterLSAinquestion.Therearetwoinstancesofthisoutputtaken15secondsapart.Thefirstoutputshowsthatthenumberoflinksinthisrouterisone;thesecondoutputshowsthatthenumberoflinksonthisrouteristhree.ThisisadiscrepancybecauseofaduplicaterouterID.ThismeansthattheremustbeanotherrouterwiththesamerouterIDcausingthenumberoflinkstochangeevery15seconds.Also,theLSAgefieldisalwayslessthan10seconds.ThefirstoutputinthisexampleistherouterLSAofR2;thesecondoutputistherouterLSAofR3.Example9-275DeterminingtheDiscrepancyintheRouterLSA



RouterLinkStates(Area0.0.0.0)

LSage:9Options:(NoTOS-capability,DC)LSType:RouterLinksLinkStateID:192.168.1.129AdvertisingRouter:192.168.1.129LSSeqNumber:80067682Checksum:0xC456

Length:36NumberofLinks:1





LSage:7Options:(NoTOS-capability,DC)LSType:RouterLinksLinkStateID:192.168.1.129AdvertisingRouter:192.168.1.129LSSeqNumber:80067683Checksum:0xA7D8Length:60NumberofLinks:3




R1#

Example9-276showsthatR2andR3haveidenticalrouterIDs.Example9-276DetectingDuplicateRouterIDs

R2#showipospfRoutingProcess"ospf1"withID192.168.1.129


Solution

Tocorrectthisproblem,eitherchangetherouterIDofR3orchangetherouterIDofR2.Example9-277showshowtochangetherouterIDofR3andgivestheoutputoftheshowipospfcommandtoverifythattherouterIDhasbeenchanged.

Example9-277ChangingtheRouterIDofR3

R3(config)#interfaceloopback0R3(config-if)#ipaddress192.168.3.129255.255.255.255R3(config-if)#end


Example9-278showsthatafterchangingtherouterIDofR3,theLSagefor192.168.1.129becomesstableintheOSPFdatabase.TheLSagehasreached90seconds,sotheentryisnowstable.Example9-278TheLSAgefortheProblemLSAIsNowStable




LSage:90Options:(NoTOS-capability,DC)LSType:RouterLinksLinkStateID:192.168.1.129AdvertisingRouter:192.168.1.129LSSeqNumber:80067686Checksum:0xC456Length:36NumberofLinks:1


CommonOSPFErrorMessagesThissectiondiscussessomeofthecommonerrormessagesinOSPF.Somemessagesareanindicationofabug,butthosemessagesarenotdiscussedinthissection.Somemessagesalsoareself-explanatory,suchasthisone:

Warning:RouteriscurrentlyanASBRwhilehavingonlyoneareawhichisastubarea

Thiswarningmessagemeansthatyouaretryingtoredistributeintoastubarea.Hereisthelistoferrormessagesthatwillbediscussedinthissection:•“Unknownroutingprotocol”•“OSPF:Couldnotallocaterouterid”•“%OSPF-4-BADLSATYPE”•“%OSPF-4-ERRRCV”

“Unknownroutingprotocol”ErrorMessageThiserrormessageisgeneratedwhentherouterospf1commandistypedonaroutertoconfigureOSPF.ThismessagemeansthatthesoftwareorthehardwaredoesnotsupportOSPF.Usuallylow-endplatforms,suchas1000and1600seriesrouters,needaspecialimage(thatis,thePlusfeatureset)torunOSPF.

Somelow-endplatforms,suchas800seriesrouters,donotsupportOSPF.

OSPF:“Couldnotallocaterouterid”ErrorMessageThismessageappearsintwosituations:•Noup/upinterfacewithavalidIPaddress•NotenoughupinterfaceswithavalidIPaddressformultipleOSPFprocesses

OSPFrequiresavalidIPaddressthatisup/upsothatitcanallocatearouterIDfortheOSPFprocess.TheIPaddressmustbeassignedonanup/upinterface.IfarouterfailstoallocaterouterIDs,OSPFwillnotfunction.Thisproblemcanbecorrectedbyusingloopbackaddresses.Theloopbackinterfacesolutionworksforbothsituations.Justconfigurealoopbackinterfaceforoneprocess.Ifyouaretryingtorunmorethanoneprocess,youmightneedmorethanoneloopbackinterface.

“%OSPF-4-BADLSATYPE:Invalidlsa:BadLSAtype”Type6ErrorMessageThisisnormaliftheneighboringrouterissendingthemulticastOSPF(MOSPF)packet.FormoreinformationonMOSPF,refertoRFC1584.CiscoroutersdonotsupportMOSPF,sotheysimplyignoreit.Togetridofthesemessages,simplytypethefollowing:

routerospf1ignorelsamospf

Ifthetypeissomethingotherthan6,it’sprobablyabugoramemorycorruptionerror.Refertothesection“OSPFNeighborStuckinLOADING”tolearnmoreabouthowtofixtheBADLSAproblem.

“OSPF-4-ERRRCV”ErrorMessageThismessagemeansthatOSPFreceivedaninvalidpacket.Threecommontypesofthismessagecanoccur:•MismatchareaID•Badchecksum•OSPFnotenabledonthereceivinginterface

MismatchedAreaID

Thismessagelookslikethis:%OSPF-4-ERRRCV:Receivedinvalidpacket:mismatchareaID,frombackboneareamustbevirtual-linkbutnotfoundfrom170.170.3.3,Ethernet0

Thismeansthattheneighbor’sinterfaceconnectingtothisinterfaceisinarea0butthatthisinterfaceisnotinarea0.Inthissituation,therouterwillnotformanOSPFadjacencywiththeneighborthatthispacketcomesfrom.Thisalsohappensifoneside’svirtuallinkismisconfigured.Toavoidthesemessages,makesurethatbothsideshavethesameareaIDbycheckingthenetworkstatementunderOSPFintherouterconfiguration.Forexample,ifthelink10.10.10.0/24betweentworoutersshouldbeinarea1,makesurethatthenetworkstatementonbothroutersincludesthisparticularlinkinarea1.Thenetworkcommandwouldlooklikethis:

routerospf1network10.10.10.00.0.0.255area1

Ifavirtuallinkisconfigured,double-checktheconfigurationforvirtuallink.BadChecksum

Themessagelookslikethis:%OSPF-4-ERRRCV:Receivedinvalidpacket:BadChecksumfrom144.100.21.141,TokenRing0/0

ThismeansthatOSPFencounteredanerrorinapacketthatwasreceived.ThisisbecausetheOSPFchecksumdoesnotmatchtheOSPFpacketthatwasreceivedbythisrouter.Thisproblemhasthreecauses:•Adevicebetweentheneighbors,suchasaswitch,iscorruptingthepacket.•Thesendingrouter’spacketisinvalid.Inthiscase,eitherthesendingrouter’sinterfaceisbadorasoftwarebugiscausingtheerror.•Thereceivingrouteriscalculatingthewrongchecksum.Inthiscase,eitherthereceivingrouter’sinterfaceisbadorasoftwarebugiscausingtheerror.Thisistheleastlikelycauseofthiserrormessage.

Thisproblemcanbedifficulttotroubleshoot,butyoucanstartwiththefollowingsolution,whichiseffectivein90percentofcases.It’simportantthatyoufollowthestepsinorder:

Step1Changethecablebetweentherouters.Fortheexamplegiveninthissection,thiswouldbetherouterthatissendingthebadpacket(144.100.21.141)andtherouterthatiscomplainingaboutthesebadpackets.

Step2IfStep1doesn’tfixtheproblem,useadifferentportontheswitchbetweentherouters.

Step3IfStep2doesn’tfixtheproblem,connecttheroutersdirectlyusingacross-overcable.Ifyoureceivenofurthermessages,theswitchmostlikelyiscorruptingthepacket.

Ifnoneofthesestepssolvestheproblem,contacttheCiscoTechnicalAssistanceCenter(TAC)andworkwithanengineertolookforabuginCiscoIOSSoftwareortoobtainapossibleReturnMaterialAuthorization(RMA)forpartialorfullpartsreplacement.OSPFNotEnabledontheReceivingInterface

Themessagelookslikethis:%OSPF-4-ERRRCV:Receivedinvalidpacket:OSPFnotenabledoninterfacefrom141.108.16.4,Serial0.100

Theroutergeneratingthismessagereceivedapacketfrom141.108.16.4onSerial0.100,butOSPFisnotenabledontheSerial0.100interface.Thismessageisgeneratedonlyonceforanon-OSPFinterface.

Chapter10.UnderstandingIntermediateSystem-to-IntermediateSystem(IS-IS)

Thischaptercoversthefollowingkeytopics:•IS-ISprotocoloverview•IS-ISprotocolconcepts•IS-ISlink-statedatabase•ConfiguringIS-ISforIProuting

ThischapterpresentsthefundamentalconceptsbehindtheIntermediateSystem-to-IntermediateSystem(IS-IS)routingprotocol.Specifically,thematerialcoveredisslantedtowardIntegratedIS-ISanditsusabilityforroutinginIPenvironments.TheIS-ISprotocolisoneofthepopularInteriorGatewayProtocols(IGP)usedontheInternet.OSPF,whichisalsocoveredinthisbook,isanotherpopularIGP.TheIS-ISprotocolarchitectureeasilylendsitselftoadaptationforvariousapplications.IS-ISisoneofthekeyunderlyingprotocolsforMultiprotocolLabelSwitching(MPLS)–basedtrafficengineering4.Morerecently,therehasbeenactivityintheInternetEngineeringTaskForce(IETF)tostandardizeIS-ISforroutinginIPv6environments9.However,thescopeofthischapterislimitedtothekeyconceptsandarchitecturalorganizationoftheIS-ISprotocolanditsrelevantcapabilitiesforunicastIProuting.Thematerialpresentedisusefulforaquickreviewoftheprotocolfundamentals;youareencouragedtoconsultthelistedreferencesattheendofthechapterforfurtherreading.

IS-ISProtocolOverviewTheIS-ISroutingprotocolisoneofthreeprotocolsspecifiedbytheInternationalOrganizationforStandardization(ISO)tosupportconnectionlessnetworkservices(CLNS):•ConnectionlessNetworkProtocol(CLNP)—ISO84381.SeealsoIETFRFC994.•EndSystem-to-IntermediateSystemRoutingExchangeProtocol(ES-IS)—ISO95422.SeealsoIETFRFC995.•IntermediateSystem-to-IntermediateSystemRoutingExchangeProtocol(IS-IS)—ISO105893.SeealsoIETFRFC1142.

ISOCLNSwasmeanttoprovideconnectionlessdatagramservicesfordatatransmissioninsteadoftheconventionalconnection-orientedservices.Unlikeconnection-orientedservicesthatrequireend-to-endcallestablishmenttoprecedeanycommunicationbetweennetworkdevices,datagramservicesallowdatatobetransmittedinindependentchunks,knownalsoaspackets,withouthavingtosetapredefinedpaththroughthenetworkbetweensourceanddestinationbeforetransmission.CLNP,whichisverysimilartotheInternetProtocol(IP),iscentraltotheoperationofISOCLNS.ES-ISandIS-ISareauxiliaryprotocolsthathelpnetworknodes(endsystemsandrouters)discovereachotherandgatherroutinginformation,whichisusedforforwardingpackets.Forexample,theIS-ISprotocolprovidesadynamicmechanismthatallowsrouterstogatherinformationaboutvariousreachabledestinationsinanetwork.Thisinformationisthenprocessedtodetermineoptimalpathsthatrouterscanuseformovingdatafromoneendofthenetworktoanother.ISO10589specifiesIS-ISforroutingCLNPpackets,andRFC11954providesextensionstoISO10589tosupportroutingofIPpacketsinadditiontoCLNPpackets.Specifically,RFC1195definesIntegrated

(Dual)IS-IS,whichallowsIS-IStoobtainandalsoexchangeCLNPandIProutinginformationsimultaneously.Despiteitsdualcapabilities,IntegratedIS-IScanbeusedinCLNS-onlyorIP-onlyenvironments.ThischapterandthenextfocusesonuseofIntegratedIS-ISinIP-only(pureIP)environments.Unlikemostroutingprotocols,whicharetypicallyencapsulatedinanetworklayerprotocol,IS-ISisitselfanetworklayerprotocolandridesoverthedatalinkalongsideCLNPandIP.Actually,allthreeISOprotocolsthatsupportconnectionlessnetworking(CLNP,ES-IS,andIS-IS)areindividuallynetworklayerprotocols.ThiscontrastswiththedesignofIP-specificroutingprotocols,suchastheOpenShortestPathFirst(OSPF)andtheBorderGatewayProtocols,whichultimatelyareencapsulatedinIPandoperateatahigherlayeroftheOpenSystemInterconnection(OSI)referencemodel.ProtocoldesignrequiresassociatingaprotocoloranapplicationwithanidentifierforthecorrespondinglayerofoperationintheOSImodel.Thefollowingisalistofnetworklayerprotocolidentifiers(inbinary)forthenetworklayerprotocolsthathavebeenmentionedsofar.Thehexadecimalequivalentisprovidedinbrackets:•CLNP:10000001(0x81)•ES-IS:10000010(0x82)•IS-IS:10000011(0x83)•IP:11001100(0xCC)

TheISOnetworklayerprotocolfamilyisidentifiedatthedatalinklayerby0xFEFE.IPisidentifiedby0x0800.CLNPbyitselfisnotrelevanttopureIPenvironments,andonlyIS-ISessentiallyisrequiredtosupportIProutinginsuchenvironments.However,theoperationofIS-ISistiedintrinsicallytocertainelementsoftheISOCLNSenvironment,suchasISOaddressing,networkserviceaccesspoints(NSAP),andtheES-ISprotocol.TheES-ISprotocolisdesignedtofacilitatecommunicationbetweenCLNSendsystemsandrouters,andithasnorelevancetothecommunicationbetweenIPhostsandIProuters.InanIPenvironment,networkdevicesuseIP-associatedmechanisms,suchasdefaultgateways,theAddressResolutionProtocol(ARP)forIPaddress-to-datalinkaddressresolution,andtheInternetControlMessageProtocol(ICMP)fornetwork-discoveryandcontrolfunctions.DiscussionsregardingdetailsofCLNPandES-ISarebeyondthescopeofthisbook,andfurtherdiscussionislimitedtoissuesofrelevancetotheoperationoftheIS-ISprotocol.

IS-ISRoutingProtocolIS-ISisalink-stateprotocoldesignedforintradomainrouting.Itsupportsatwo-levelroutinghierarchy:•Routingwithinareas(Level1)•Routingbetweenareas(Level2)

RoutersrunningtheIS-ISprotocolformadjacencieswithotherdirectlyconnectedIS-ISroutersandexchangeroutinginformationcontainedinlink-statepackets(LSPs).EachroutercollectsLSPsintoseparateLevel1andLevel2link-statedatabasesbasedontheirmodeofoperation(Level1only,Level2only,orLevel1–2).TheLevel1link-statedatabaseprovidesaviewofthelocalarea’stopology,whiletheLevel2link-statedatabaseprovidesaglobalviewofinterareaconnectivity.Theshortestpathfirst(SPF)algorithm(namedafterDijkstra)isrunseparatelyoverLevel1andLevel2databasestoobtainthebestpathstovariousdestinationsinthenetwork.IS-ISisoneoftwopopularInteriorGatewayProtocols(IGP)usedonthelargeservice-providernetworksthatareinterconnectedtoformtheglobalInternet.TheotherpopularIGPistheOpenShortestPathFirst(OSPF)protocol.TheBorderGatewayProtocol(BGP)isusedforinterdomainrouterbetweennetworkdomains(orautonomoussystems).

AsidefromRFC1195,whichallowsIS-IStocarryIProutinginformation,severalotherenhancementshavebeenproposedforstandardizationintheIETF.MostprominentoftheseareMultiprotocolLabelSwitchingTrafficEngineering(MPLSTE)relatedenhancements7.Inrecenttimes,interestintheIS-ISprotocolhassignificantlyincreased,culminatinginthereopeningoftheIS-ISworkinggroupintheIETF.SeveralofthenewcapabilitiesproposedinIETFalreadyhavebeenimplementedasvendor-specificenhancements,andtheeffortisdirectedatstandardizationandinteroperabilityacrossdifferentvendorrouterproducts.ThesuccessfuladoptionandwidespreadacceptanceoftheIS-ISprotocolforIProutingisaresultofitsflexibilityforextension,simplicity,andeaseoftroubleshooting.TroubleshootingoftheIS-ISprotocolisdiscussedinthenextchapter.ThischapterdrillsintokeyconceptsbehindtheIS-ISprotocolandlaysthegroundworkforChapter11,“TroubleshootingIS-IS.”

IS-ISProtocolConceptsThegoalofthissectionistohelpyouunderstandtheoperation,features,strengths,andlimitationsofthevariousarchitecturalconceptsunderlyingtheIS-ISprotocol.Inparticular,thefollowingpointsarediscussed:•IS-ISnodes,links,andareas•IS-ISadjacencies•Level-1andLevel-2routing•IS-ISpackets•IS-ISmetrics•IS-ISauthentication•AddressingfortheCLNPprotocol

IS-ISNodes,Links,andAreasIS-ISinheritsthefollowingISOclassificationanddefinitionofthetwobasictypesofnetworknodes:•Endsystems•Intermediatesystems

Endsystemsarehostsinanetworkthattypicallydonothaveextensiveroutingcapabilities.Intermediatesystemsrefertorouterswhoseprimaryfunctionistoroutepackets.Networknodesareinterconnectedbylinks.Again,inIS-IS,onlytwobasiclinkstypesareofpracticalrelevance:•Point-to-pointlinks•Broadcastlinks

Point-to-pointlinksinterconnectpairsofnodes,whilebroadcasttypelinksaremultipointandcaninterconnectmorethantwonodesatthesametime.Transporttechnologies,suchasserial(T1,DS-3,andsoon)andPacket-over-SONET(PoS)links,areinherentlypoint-to-point,whilelocal-areanetwork(LAN)media,suchasEthernet,aretypicalbroadcast-typelinks.Nonbroadcastmultiaccess(NBMA)transportmedia,suchasAsynchronousTransferMode(ATM)andFrameRelay,canbeconfiguredtooperateassimulatedbroadcastorpoint-to-pointlinks.Becausebroadcastlinksinherentlyimplyconnectednodesarefullymeshed,NBMAmediashouldbeconfiguredasbroadcastlinksonlywhentheroutersarefullymeshedbytheunderlyingpermanentvirtualcircuits(PVC).NonfullymeshedNBMAenvironmentsshouldusepoint-to-pointsetups,whichalignwiththeunderlying

topologyofPVCinterconnectionsandaresimplertomanageandtroubleshoot.AnetworkrunningtheIS-ISroutingprotocolfrequentlyisreferredtoasanIS-ISroutingdomain.AlargeIS-ISroutingdomaincanbepartitionedintomultipleareasforthepurposeofscalingroutingovertheentiredomain.Aroutingareacanbeofanyarbitrarysize;thenumberofnodesthatitcontainslargelyisdefinedatthediscretionofthenetworkdesigner.Keyfactorsnormallytakenintoconsiderationwhencreatingareasincludememoryandprocessingcapacitiesoftheroutersinvolved.Thelargertheareais,thehighertheresource(memoryandCPUcapacity)needsperrouterareformaintainingtheIS-ISdatabaseandcomputingroutesfastenoughtosustainreasonableconvergencetimeswhenchangesoccurinthenetwork.AllIS-ISroutersinthedomainareassignedtoatleastoneIS-ISarea.EachIS-ISnodehasauniquenode-basedaddressreferredtoasanetworkserviceaccesspoint(NSAP).NSAPsarediscussedlaterinthischapter,but,fornow,allyouneedtoknowisthattheNSAPhasanareaidentifiercomponentthatdefinesthenativeareaofeachnode.Figure10-1showsthelayoutofanIS-ISdomaincarvedintothreeareaswiththefollowingsimplearea-identifiers:49.001,49.002,and49.003.Asdepicted,theareasareinterconnectedthroughtheregionknownasthebackbone.Fromthisdiagram,itisalsoapparentthateachnodewhollysitsinaspecificareaandthattheareaboundariescutacrossthelinkstootherareas.EachIS-ISareaisspecifiedinISO10589tobeastub—meaningthatinterarearoutinginformationremainsonlywithinthebackbone.ArecentIETF-sponsoredenhancement6removesthisrestriction.ThiscapabilityisavailableinCiscoIOSSoftwareasafeatureknownasIS-ISrouteleaking.

Figure10-1IS-ISAreas

Adjacencies

Asalink-stateprotocol,IS-ISreliesoncurrentandcompleteknowledgeofthenetworktopologytocomputeroutesaccuratelyandoptimally.SomekeyfunctionsofroutersparticipatinginIS-ISroutinginvolvediscovering,establishing,andmaintainingroutingadjacencieswithneighborrouters.Thetypeandmannerinwhichanadjacencyisformedbetweentworoutersdependonthetypeoflinkinterconnectingthem.ThissectionaddressesthetwotypesofIS-ISadjacencies,whichcorrelatewiththetwotypesoflinksdiscussedearlier.Theadjacencytypesarelistedhere:•Adjacenciesoverpoint-to-pointlinks•Adjacenciesoverbroadcastlinks

FormationandmaintenanceofadjacenciesbetweenIS-ISrouterstakeplacethroughtheexchangeofspecialpackets,referredtoashellos.RoutersneedtoformbothES-ISandIS-ISadjacenciesovereitherpoint-to-pointorbroadcastlinks.EventhoughES-ISisnotnecessaryforIProuting,IS-ISadjacencyformationonpoint-to-pointlinksisdependentonES-ISadjacencydetectiononsuchlinks.Therefore,CiscoIOSSoftwareenablestheES-ISprotocolevenifIS-ISisenabledforonlyIProuting.ES-ISusesend-systemhellos(ESHs)andintermediate-systemhellos(ISHs)forES-ISadjacencies,whileIS-ISusesintermediatesystem-to-intermediatesystemhellos(IIHs).ES-ISAdjacencies

InES-IS,endsystemsadvertiseESHstoroutersbyaddressingthemtotheMACaddress09-00-2B-00-00-05(AllIntermediateSystems).Ontheotherhand,routersadvertiseISHsto09-00-2B-00-00-04(AllEndSystems).ES-ISessentiallyprovidesahost-discoverymechanismintheISOCLNSenvironment.Throughthismechanism,endsystemslocatetheclosestrouterthoughwhichtheycantransitdatatononconnectedmedia.Routers,inturn,learnaboutendsystemsintheirarea.RoutersalsodiscovereachotherthroughtheES-ISadjacencyprocess.Figure10-2showsISHandESHtransmissionsbetweenroutersandaworkstationonaLAN.

Figure10-2ES-ISAdjacenciesIS-ISAdjacencies

Forrouterstoexchangeroutinginformation,theyneedtotranscendES-ISadjacenciesandformIS-ISadjacencieswiththeirneighbors.AninterestingpointtonoteisthatES-ISadjacencyisrequiredtotriggeradvertisementofIIHsonpoint-to-pointlinks,whichultimatelycanleadtoIS-ISadjacencies.

TheIS-ISadjacenciesonpoint-to-pointlinksareformedandmaintainedalittledifferentlythanonbroadcastlinks.Also,IIHsusedonpoint-to-pointlinkshaveaslightlydifferentformatthanthoseusedonbroadcastmultipointlinks.ThefollowingarethethreetypesofspecifiedIIHs:•Point-to-pointIIH—Usedoverpoint-to-pointlinks.•Level1LANIIH—UsedoverbroadcastlinksbutforLevel1adjacencies.Advertisedto01-80-C2-00-00-14(AllL1ISs).•Level2LANIIH—UsedonbroadcastlinksbutforLevel2adjacencies.Advertisedto01-80-C2-00-00-15(AllL2ISs).

Thepoint-to-pointIIHsandLANIIHshaveslightlyvariedinformationintheirfixedheaderareas.Forexample,thepoint-to-pointIIHshavealocalcircuitID,whereasLANIIHshaveaLANID.Also,point-to-pointIIHsdon’thavethepriorityinformationfoundinLANIIHs.IS-ISpacketformatsarecoveredlaterinthischapter,inthesectiontitled“IS-ISPackets.”Completeformatsofhellopacketsareprovidedattheendofthechapterinthesectiontitled“AdditionalIS-ISPacketInformation.”IS-IShasatwo-levelroutinghierarchy,and,asalludedtopreviously,thetypeofadjacencyformedbetweenIS-ISroutersdeterminesthetypeofroutingrelationshipbetweenthem(thatis,Level1,Level2,orboth).Routinginformationisexchangedthroughtheuseoflink-statepackets(LSPs),withcontrolprovidedbysequencenumberpackets(SNP).LSPsandSNPswillbediscussedfurtherinthesection“IS-ISLink-StateDatabase.”OnmultiaccesslinkssuchasbroadcastLANsormultipointATMandFrameRelaylinksinwhichmorethentwonodesareconnectedtothesamelink,formingadjacenciesbetweenallofthemresultsinn×(n−1)/2adjacencies,wherenisthenumberofconnectednodes.InIS-IS,allnodesonmultipointlinksactuallydetecteachotherbymeansofthehellosmulticastacrossthemedium.Eachnode,therefore,formsn−1adjacenciesonsuchmedia.Anodedeclaresaneighbortobeadjacentifthatneighborisannouncedinthelistofdetectedneighbors.Reliablyupdatingandsynchronizingdatabaseswitheachoftheseadjacentneighborscertainlyisresource-demanding.Therefore,toreducetheamountofeffortrequiredfordatabasesynchronization,IS-ISmodelssuchmultipointlinksasvirtualnodes,alsoreferredtoasapseudonodes(PSN)(seeFigure10-3).

Figure10-3Broadcast-LinkPseudonode

OneoftheroutersonthemultipointlinkiselectedasadesignatedroutertoplaytheroleofthePSN.InISOterminology,thedesignatedrouterisreferredtoasthedesignatedintermediatesystem(DIS).ElectionoftheDISisbasedoninterfaceprioritiesoftheroutersconnectingtothemultiaccesslink,withthehighestMACaddressbeingthetiebreakerinthecaseofLANmedia.Thedefaultpriorityis64onCiscoroutersandcanbemodifiedwiththeisispriorityvalueinterface-levelconfigurationcommand.ThepriorityinformationiscarriedonlyinLAN-typehellos,asmentionedpreviously.TheroleoftheDISistofacilitatesynchronizationoftheIS-ISlink-statedatabasesbetweenroutersconnectedtothe

multipointmedium.ItdoesthisbyperiodicallymulticastingsummariesofallknownLSPsoverthemedium.TheDISalsogeneratesaPSNLSPthatlistsallknownneighborsonthemultipointlink.AllnodesonthemultipointmediumbecomeadjacenttoboththePSNandtheactualrouteractingastheDIS.AllnodesontheLANmustconsistentlyacknowledgethesameDISforIS-ISoperationstoworkwellontheLAN.DISelectionispreemptive;atanypoint,themostqualifiedroutertakesovertherole.Three-wayreliableadjacencyformationisspecifiedinISO10589foronlybroadcastlinksbutnotforpoint-to-pointlinks.Therefore,unlikepoint-to-pointhellos,LANhellopacketscontainalistofISneighborsontheLANthathelloshavebeenreceivedfrom.ALANroutermovesitssideoftheadjacencywithaspecificneighbortoUPstatewhenitreceivesahellofromthatneighborinwhichitislisted.BothISO10589andRFC1195donotspecifypoint-to-pointhellostocarrytheISneighborlist.TherecentIETFdraft5proposesstandardizationofthethree-wayhandshakemethodforadjacencyformationonpoint-to-pointlinks.ThisissupportedinCiscoIOSSoftwareRelease12.OSandlater.Figure10-4illustratestheadjacencyformationprocessonpoint-to-pointlinks.

Figure10-4Point-to-PointIS-ISAdjacencies

Asshown,RTAandRTBbothadvertisehellostoeachotherinwhichtheylistonlythemselvesinthelistofknownneighbors,indicatingthattheyhaven’theardfromeachotheryet.Aftertheyreceiveeachother’shello,eachliststheotherintheneighborlistinsubsequenthelloexchanges.ThisresultsinbothroutersmovingtheiradjacenciestotheUPstate.Thesameprocessisusedonmultiaccesslinks.

HierarchicalRoutingAsindicatedearlier,IS-ISareasprovideameansforscalingroutingintheIS-ISdomain.RegularIS-ISareasandthebackboneinterconnectingthemareorganizedintoatwo-levelroutinghierarchy.RoutingwithinanareaisreferredtoasLevel1routing.RoutingbetweentherespectiveareasinadomainisreferredtoasLevel2routing.Figure10-5showsanIS-ISdomainpartitionedintotwoareas:49.001and

49.002.Itisinterestingtonotethat,althoughLevel1routingisrestrictedonlytotheconfinesofeacharea,Level2routingoccurswithinthestretchofthebackbone,whichcanoverlapwellintoanyareabasedonconfigurationoftherouters.

Figure10-5ISRoutingHierarchy

IS-ISrouterscanbeLevel1only(L1),Level2only(L2),orbothLevel1andLevel2(Level1–2),basedontheirconfiguration.Theconfigurationofarouterdeterminesthetypeofadjacency(Level1orLevel2)thatitcanformwithitsneighbors,regardlessofthetypeoflink.This,inturn,determinesthelevelofrouting(Level1orLevel2)thataroutercanparticipatein.Inthedefaultmodeofoperation,CiscoroutersareLevel1–2andcanformanykindofadjacencywiththeirneighbors.ArouterinoneareacanformonlyaLevel2adjacencywitharouterinanotherarea,soonlyLevel2routingoccursbetweenthem.However,dependingontheirconfiguration,tworoutersinthesameareacanformaLevel1adjacencyorbothLevel1andLevel2adjacencieswitheachother.Typically,routersthatareLevel2,byvirtueoftheirconnectivitytothebackbone,alsoengageinLevel1routingwithintheirrespectiveareas,makingthemLevel1–2routers.Level1–2routersfacilitateaccesstootherareasforLevel1–onlyroutersinthearea.Level1–2routersflagtheirconnectivitytothebackboneintheirLevel1routingadvertisements.AsspecifiedinISO10589,IS-ISLevel1areasarestubs,andtheLevel1–onlyroutershavenovisibilityintoroutesinotherareaswithinthesamedomain.TheydependonadefaultroutetothenearestLevel2routertoforwardpacketstodestinationsoutsidethelocalarea.RelyingonadefaultroutetothenearestLevel2routerpotentiallycouldresultinsuboptimaldeterminationofthebestexittootherdestinationsinthenetwork.RFC29666standardizesdomain-wideprefixadvertisement(IS-ISrouteleaking)byallowinginterarearoutestobeadvertisedfromtheLevel2backboneintoLevel1areas.ThiscapabilityenablesoptimalpathselectionbyLevel1routersfordestinationsoutsidetheirlocalareas.

IS-ISPacketsBecausetheobjectiveofthisbookistoassistwithtroubleshootingIProutingproblems,itwouldnotbeanoverstatementtopointoutherethatfamiliaritywiththevarietyofpacketsandtheirformatsusedbyaroutingprotocoliskeytounderstandingtheprotocolnuancesrequiredforsuccessfultroubleshooting.ThissectionreviewsthevarioustypesofIS-ISpacketsandstudiesthegenericIS-ISpacketformat.InISOparlance,packetsarereferredtoasprotocoldataunits(PDU).Thecompleteformatsofeachpackettypeareprovidedattheendofthechapterinthesectiontitled“AdditionalIS-ISPacketInformation.”

ThreecategoriesofIS-ISpacketsexist:•Hellopackets(IIHs)—EstablishandmaintainadjacenciesbetweenIS-ISneighbors.•Link-statepackets(LSPs)—DistributeroutinginformationbetweenIS-ISnodes.•Sequencenumberpackets(SNPs)—ControlthedistributionofLSPs.SNPsprovidemechanismsforsynchronizinglink-statedatabasesbetweenroutersinthesameareaorthebackbone.

Varioustypesofpacketsexistundereachofthepacketcategories.Eachtypeisassignedatypenumber,asshowninTable10-1.AllIS-ISpacketsaremulticastonLANmediatooneofthefollowingaddresses,dependingonthelevelofroutingforwhichitisintended:•01-80-C2-00-00-14(AllL1ISs)—ForLevel1systems•01-80-C2-00-0-15(AllL1ISs)—ForLevel2systems

Table10-1IS-ISPacketTypes

GenericIS-ISPacketFormat

EachtypeofIS-ISpacketismadeupofapacketheaderandanumberofoptionalvariable-lengthfieldsreferredtoasType-Length-Value(TLV)fields.Thefieldsofeachpackettypevaryslightlyfromeachother,consistingofthegenericfieldsandpackettypespecificfields,asshowninFigure10-6.

Figure10-6IS-ISPacketHeader

Thegenericheaderfieldsaredescribedasfollows:•IntradomainRoutingProtocolDiscriminator—ThisisthenetworklayeridentifierassignedtoIS-IS,asspecifiedbyISO9577.Itsvalueis0x83inhexadecimal.•LengthIndicator—Thisspecifiesthelengthofthepacketheaderfieldsinoctets(bytes).•Version/ProtocolIDExtension—Currentlythisfieldhasavalueof1.•Version—Thevalueofthisfieldis1.•Reserved—Theseareunusedbits;thisfieldissetto0.•MaximumAreaAddresses—Thisfieldincludesvaluesbetween1and254fortheactualnumber.0impliesamaximumofthreeaddressesperarea.

TheTLVfieldsaresonamedbecauseeachisdescribedbythefollowingthreeattributes:•Type—A1-bytefieldcontaininganumbercode.ISO10589usesthewordCodeinplaceofType.However,TypeseemstobepreferredinIETFandCiscoliteratureonIS-IS.•Length—A1-bytefieldthatspecifiesthetotallengthofTLVsofthattypeinthepacket.•Value—ContentoftheTLV.Typically,thevalueismadeupofrepeatedblocksofsimilarinformation.

Byspecification,eachIS-ISpackettypeincludesonlyspecificTLVtypes.ThenumberofactualTLVs

presentinarealpacketisdeterminedbytheconfigurationandenvironmentoftheoriginatingrouter.MostofthecurrentlyspecifiedTLVscanbepresentinbothLevel1andLevel2packets.Afew,however,arededicatedtoonlyLevel1orLevel2packets.RFC1195specifiesadditionalTLVstothosespecifiedinIS010589.Tables10-2and10-3listTLVsspecifiedbyISO10589andRFC1195,respectively.

Table10-2TLVsSpecifiedbyISO10589

Table10-3TLVsSpecifiedbyRFC1195

MostenhancementstotheoriginalIS-ISprotocol(ISO10589)haveoccurredthroughtheintroductionofnewTLVsinsteadofnewpackettypes.ThispointslargelytotheflexibilityandextensibilityoftheIS-ISprotocol.Forexample,TLVsintroducedbyRFC1195adaptedIS-ISforroutingIPinadditiontoCLNP.Table10-4listsrecentlyintroducedTLVswithintheIETFthatprovidevariousextensionsandadditionalcapabilitiestotheIS-ISprotocol.TLVs22,134,and135areIS-ISextensionsforMPLS-basedtrafficengineering.

Table10-4SomeTLVsSpecifiedbyIETFExtensionstoIS-IS

IS-ISMetricsThefollowingIS010589andRFC1195TLVscarrymetricinformationinadditiontotheirprimaryobjects:•ESNeighborTLV(Type2)•ISNeighborTLV(Type3)•PrefixNeighborTLV(Type5)•IPInternalReachabilityTLV(Type128)•IPExternalReachabilityTLV(Type130)

Obviously,eachTLVwouldhaveadifferentoverallformat,buttheyallhavethesamesetofmetricfields.Figure10-7showstheformatofthevaluefieldintheIPInternalReachabilityTLV.OtherfieldsoftheTLVincludetheTypeandvaluefields,all1byteeach.

Figure10-7IPInternalReachabilityTLV

ThefollowingfourmetrictypesarespecifiedbyISO10589andhavebeenadoptedbyRFC1195:•DefaultMetric—Alsoknownascost.MustbesupportedbyallroutersintheIS-ISdomain.Providesindicationoflinkspeed.Lowervaluesimplyrelativelyfasterlinkspeedormorebandwidth.•DelayMetric—(Optional)Measurestransitdelayoflink.•ExpenseMetric—(Optional)Measuresmonetarycostoflink.•ErrorMetric—(Optional)Measuresresidualerrorprobabilityoflink.

Thedefaultmetrictypemustbesupportedonallnodesintheroutingdomain.Theothermetrictypes—delay,expense,anderror—areoptionalandareintendedfordifferentiatedroutingofqualityofservice(QoS)–enabledCLNPpackets.TheIS-ISQoSmetricsarenotapplicabletoIPtrafficdifferentiation,whichisbasedontheprecedencebitsintheIPheader.Inanycase,Cisco’simplementationofIS-ISsupportsonlytherequireddefaultmetrictype.AsdepictedinFigure10-7,eachtypeofmetricis1bytelong.Bit8indicatesthepresenceofthemetrictypeintheTLV,andbit7classifiesthemetricasinternalorexternal.InternalmetricsreferstoroutesgeneratedwithintheIS-ISdomain,whileexternalmetricsreferstoroutesoriginatingoutsidetheIS-IS

domainorfromanotherroutingprotocolsource,suchasOSPF.Consequently,only6bitsareavailablefordefiningtheactualvalueofthemetric.Thisgivesamaximumcostof63perlink,inthecaseofthedefaultmetrictype.OnCiscorouters,thecostofalinkisdeterminedbythevalueappliedtotheoutgoinginterface.Avalueof10isassignedbydefaultonallinterface.Thecostisnotderivedautomaticallyfromtheinterfacebandwidth,asinthecaseofOSPF.Thetotalmetricofacompletepathisthesumofcostvaluesonalloutgoinginterfacesfromsourcetodestination.ISO10589specifies1023asthemaximumpathcost.RecentIETF-drivenextensions7toIS-ISproposeusingthemostlyunusedQoSmetricfieldsaspartofthedefaultmetrictypefieldtoallowhigher-costvaluesforthedefaultmetrictype.ThefollowingLSPTLVs,whichwererecentlyintroducedtosupportMPLSTE,supportawiderfieldforthedefaultmetrictype:•ExtendedISReachabilityTLV(Type22)•ExtendedIPReachabilityTLV(Type135)

Figure10-8showstheformatofeachprefixelementcontainedintheExtendedIPReachabilityTLV.

Figure10-8FormatofPrefixinExtendedIPReachabilityTLV

ThefollowingisthelistoffieldsintheExtendedIPReachabilityTLV:•Type—(1byte)Type135.IndicatestheExtendedIPReachabilityTLV.•Length—(1byte)TotallengthoftheValuefield.•Value—ManyprefixescanexistineachTLV,andthenumberisconstrainedonlybythemaximumLSPsize.Eachprefixelementinthisfieldconsistsofthefollowinginformation:—4bytesofmetricinformation—Controlinformation(1byte)—Thisbyteiscomposedof—1-bitsub-TLVpresencebit—6bitsofprefixlength

—IPv4Prefix—Rangesfrom0to4bytes.—OptionalSub-TLVs—Rangesfrom0to250bytesandiscomposedof

—1byteoflengthofsub-TLVs—0to249bytesofsub-TLVs

The4-bytemetricfield(32bits)permitslargemetricvalues,which,asspecified,shouldnotbemorethanthevalueMAX_PATH_METRIC(0xFE000000).PrefixeswithmetricslargerthanMAX_PATH_METRICaretobeignoredinSPFcomputations.ConsulttheRFCdraft7forfurtherdetails.CiscoIOSSoftwarereleasesfromthe12.0Sand12.0TtrainssupporttheexpandedIS-ISmetricvaluesforthedefaulttype,alsoknownaswidemetrics.TheIS-ISrouter-levelcommandmetric-style[narrow|wide]enablesanddisableswideIS-ISmetrics.A“hidden”optionofthecommandmetric-styletransitionisprovidedforonlymigrationpurposes.Whenenabled,thiscommandallowsaroutertosendandreceivebothnarrowandwidemetrics.

IS-ISAuthenticationBothISO10589andRFC1195specifyauthenticationmechanisms(TLV10and133,respectively),inanattempttotackleprotocolsecurityconcerns.OnlyminordifferencesexistbetweentheformatsoftheseTLVs;however,significantcommonalityisthattheybothspecifyonlyclear-textpasswordschemes.However,bothTLVsprovidereservedfieldsforfutureadvancedauthenticationoptions.Well,thefutureisalreadyhere!AnewIETFdraft10proposesaprotocolextensionthatusesanHMAC-MD5authenticationoptioninadditiontothepreviouslyspecifiedclear-textpasswordschemes.MostexistingIS-ISimplementationsuseTLV10overTLV133,eveninpureIPenvironments.TheIS-ISHMAC-MD5authenticationextensionthereforeextendsapplicationofthisTLVbydefininganewauthenticationtype54(or0x36inhexadecimal)withinTLV10.Theclear-textpasswordisauthenticationType1.

ISOCLNPAddressingAninterestingparadigmconcerningIS-ISisthatitisdeeplyrootedinCLNPtotheextentthat,evenifitisusedforroutingonlyIP,CLNPaddressesstillmustbeconfiguredontheIProuters.Therefore,itisimportantfornetworkoperationsstaffusingIS-ISinpureIPenvironmentstobecomecomfortablewiththeCLNPaddressingarchitecture.CLNPaddressesarereferredtoasnetworkserviceaccesspoints(NSAPs).ObviousdifferencesbetweenIPaddressingandCLNPaddressingareasfollows:•InIP,addressesareassignedtotherouterinterfacesaspartofsubnetsdefinedforconnectinglinks.InCLNP,anaddressisassignedtothewholenodeinsteadoftheconnectinglinks.Also,subnetmasksarenotrequiredforNSAPconfigurationasinthecaseofIPaddressing,eventhoughmaskscanbeusedinCLNPstaticroutestatements.•CLNPaddressesareofvariablelength,withaminimumlengthof8bytesandamaximumof20bytes.ThesystemIDandN-selectorpartsoftheaddressmusthaveaconsistentlength,6bytesand1byte,respectively,onCiscorouters.Incontrast,anIPversion4addressappliedtoarouter’sinterfacemustbe32bitslong.

NSAPFormat

AsimplifiedversionoftheCLNSNSAPformat,specifiedinISO10589andassociatedspecifications,wasadoptedbyRFC1195inadaptingIS-ISforIProuting.Thisformat,asshowninFigure10-9,delineatesonlythreekeycomponentsinanNSAPaddress:•Areaidentifier(AreaID)—ThisdefinestheIS-ISareatowhicharouterbelongs.•Systemidentifier(SysID)—ThisisauniqueidentifierforanIS-ISrouterwithinanareaortheLevel2backbone.•N-selector(NSEL)—Thisisanalogoustoanapplicationidentifier.Itindicatesahand-offpointof

IS-ISpacketstothenexthigherlayerabovethenetworklayer.IS-ISpacketsareforwardedtotheroutinglayerinarouter,whichisdesignatedbyanall-zero(0x00)N-selector.

Figure10-9NSAPFormatforIPRouting

ThemaximumlengthofanNSAPis160bits(20bytes),comparedtothe32bits(4bytes)ofanIPaddress.TheNSELis1bytelong.TheSysIDisspecifiedinISO10589tobeofvariablelength,rangingfrom1byteto8byteslong.However,CiscofollowstheUSGOSIPstandard,whichspecifies6bytesfixed-lengthfortheSysID.TheAreaIDfieldisavariable-lengthfieldfrom1to13bytes.AkeycomponentoftheAreaIDthatRFC1195seemstoglossoveristheAuthorityandFormatIdentifier(AFI).TheAFIisthefirstbyteoftheAreaID,anditspecifiesatop-levelISOaddressingauthorityaswellasencodingoftheNSAP.Table10-5liststheAFIvaluesforsevenISOtop-leveladdressingdomains.EachdomainfeaturestwoAFIvaluesforbinaryanddecimalencodingoftheremainderoftheaddressfollowingtheAFIfield.

Table10-5AFIValues

Variousaddress-registrationauthoritiesoverseeallocationofaddressesfromeachofthetop-leveldomains.Forexample,ICDISO6523addressesareallocatedthroughnational-levelregistrationauthorities,suchastheUnitedStatesNationalInstituteofStandards(NIST)ortheBritishStandardsInstitute(BSI).TheU.S.NISTisresponsibleforallocationofISO6523ICD(AFI47)addressestoorganizationsintheUnitedStates,includingU.S.federalgovernmentinstitutions.Similarly,theAmericanNationalStandardsInstitute(ANSI)isthenationalregistrationauthorityforISODCC(AFI39)addressesintheUnitedStates.AFI49designatesaprivateNSAPaddressspacesimilartotheprivateIPaddressspacespecifiedinRFC191811.NSAPExamples

Figure10-10showsexamplesofNSAPaddresses.Example1isacomplete,full-length(20bytes)

address,whileExample2isashorter-lengthaddressfromtheprivatespace.

Figure10-10NSAPExamples

Asmentionedearlier,thesystemID(SysID)isa6-bytefieldthatuniquelyrepresentsanodeinanIS-ISdomain.Frequently,networkadministratorsuseaMACaddressfortheSysID.However,thisisnotnecessary.Also,aroutermighthavemanyLANinterfacesand,therefore,manyMACaddressesmakingitunclearwhichisbestsuitableforthepurpose.MostISPswhouseIS-ISasIGPhavefiguredoutacreativeanddecisivewaytodefinethesystemIDand,therefore,theNSAPaddressonarouter.ThesystemIDiscreatedfromaloopbackaddress.Inmanycases,anIPloopbackaddressisdefinedonarouterforotherpurposes,suchasnetworkmanagementorspecifyingtherouterIDforBGPpeering.TocreatethesystemID,theloopbackIPaddress,whichisindotted-decimalformatisfirstpaddedwithzerostoobtainthe12-digitaddress,asshowninFigure10-10,Example3.Thedigitsthenareregroupedinfourstoobtainthe6-bytehexadecimalsystemID,whichcanbeusedfordefiningauniqueNSAPfortherouter.GuidelinesforDefiningNSAPAddresses

ThefollowingprovidesasummaryoftheguidelinesforselectingordefiningNSAPaddressesonroutersinanIS-ISroutingdomain:•RoutersindifferentareaswithinthedomainmustusedifferentareaIDs.RouterswithinanareahavethesameareaprefixintheirNSAPs.•EachnodeinanareamusthaveauniquesystemID.Thisalsoappliestonodesinthebackbonerelativetoeachother.

•AllsystemsinanIS-ISroutingdomainmustusethesamelengthfortheirsystemIDs.Ciscoroutersuseafixedsizeof6bytes.•EachnodemusthaveatleastoneNSAP.Bydefault,youcanconfigureCiscorouterswithuptothreeNSAPs,eachwiththesamesystemIDcomponentbutadifferentareaID.Therouter-levelcommandmax-area-area{0-254}allowsupto254NSAPstobeconfiguredinasimilarmanner.

TheconceptofconfiguringmultipleNSAPspernodeforasingleinstanceofIS-ISroutingallowsaroutertobeassociatedwithmorethanoneLevel1area,aconceptreferredtoasmultihoming.Theeffectofmultihomingisthatalltheareasconfiguredaremergedintoasinglearea,allowingLevel1LSPstobeadvertisedacrosspreviousareaboundaries.Inessence,multihomingisusedfortransitionalpurposes,suchasnetworkrenumbering,partitioning,ormergingIS-ISareasinadomain.Thetechniquepermitsnondisruptivenetworkreconfiguration.

IS-ISLink-StateDatabaseAsalink-stateprotocol,IS-ISworksbygatheringreliableandcompleteinformationabouttheroutingenvironmentthroughtheuseofspecialpacketsknownasLinkStateProtocolDataUnits(LSPs).Aprotocoldataunit(PDU)alsomeansapacket.EachroutergeneratesanLSP,whichcaptureslocallink-stateinformationdescribingconnectedlinks,neighborrouters,IPsubnets,relatedmetricinformation,andsoforth.CopiesoftheLSParedistributedtoallroutersinaspecificareathroughaprocessreferredtoasflooding.Ultimately,allroutersinanareaobtaineveryotherrouter’sLSPandsynchronizetheirdatabases.Becausethearealink-statedatabaseisusedforonlyintra-arearouting(alsoreferredtoasLevel1routing),itiscalledtheLevel1link-statedatabase.TheLevel2routersinterconnectedintothebackbonesimilarlymaintainaLevel2link-statedatabasethroughtheexchangeofLevel2LSPs.BestpathsthoughthenetworkareresolvedbyrunningtheSPFalgorithmovertheinformationintheLevel1andLevel2databasesseparately.Thesectionsthatfollowaddressthefollowingsubtopics:•OverviewoftheIS-ISlink-statedatabase•Floodinganddatabasesynchronization•TheSPFalgorithmandroutecalculation

Thefirstsectionprovidesahigh-leveloverviewoftheIS-ISlink-statedatabase.Thenextsectiondiscussesthefloodingprocessthroughwhichdatabasesynchronizationisachieved,andthelastsectiontopstheearlierdiscussionswithanoverviewoftheSPFalgorithm,alsoknownastheDijkstraalgorithm.

OverviewoftheIS-ISLink-StateDatabaseTheoperationofalink-stateprotocolrequireseachnodeinanareatohaveacompleteviewoftheentireareaand,usingthatknowledge,calculatethebestpathstoeachdestinationinthearea,startingwithitself.Asindicatedpreviously,LSPsarethevehiclesforpropagatingeachrouter’slimitedviewofitsimmediatesurroundings;therefore,theassemblyofLSPsbyrouterstoobtainthecompleteroutingpictureofthenetworkfrequentlyhasbeencomparedtotheprocessofsolvingajigsawpuzzle.Thesolvedpuzzlerepresentstheentirepictureofthenetworkoritscompletetopology.EachoftheuniqueLevel1databasesrepresentsthestateofadjacencieswithinaspecificarea,whiletheLevel2databaserepresentstheinterconnectionsamongthevariousareasinthedomain.OnCiscorouters,thecommandshowisisdatabase[detail|level-1|level-2][lspid]canbeusedtoviewtheLSPsintheLevel1orLevel2databases.ExercisingthedetailoptionofthecommanddisplaysdetailsaboutelementsinallknownLSPsoraspecificLSP.Figure10-11showstheformatofanLSP.

Figure10-11Link-StatePDUFormat

TheLSPheaderfeaturesgenericfieldsthathavealreadybeendiscussedinthischapter.ThefollowingaresomeofthefieldsspecifictotheLSPheader:•RemainingLifetime—ThisisthetimeintervaluntilexpirationofanLSP.AnLSPagesfromthetimethatitisgenerated.Ifitisnotrefreshedbeforeitsmaximumage(Maxage)isreached,itexpiresanditisthensubsequentlydeletedfromtheLSPdatabase.ThedefaultvalueofMaxageis20minutes.•LSPIdentifier—TheLSPidentifier(LSPID)obviouslyisusedforidentificationpurposesandindicatestheowneroftheLSP.TheLSPIDformat,asshowninFigure10-12,consistsofthreecomponents.

Figure10-12LSPIdentifier

—Systemidentifier(SysID)—ThisisthesystemIDoftheoriginatingrouterorthedesignated

router(DIS),inthecaseofapseudonodeLSP.—Pseudonodeidentifier—Thisis0foranon-PSNLSPandnonzeroforaPSNLSP.—LSPnumber—ThisdenotesLSPfragments.

•SequenceNumber—AroutertagstheLSPthatitgenerateswithasequencenumbertodifferentiatenewercopiesfromolderones.TheLSPsequencenumberisincreasedby1whenevertheroutergeneratesanewLSPtoreplaceanoutdatedversion.NewLSPsareissuedwhenchangesoccurinlocalsurroundingsoftherouterthatneedtobereportedtotherestofthenetwork.AnIS-ISrouterperiodicallyissuesanewLSPwiththesameinformationasthepreviousLSP,justtorefreshanLSPbeforeitexpires.Thedefaultrefreshintervalis15minutes.•Checksum—ThismaintainstheintegrityofanLSPduringstorageorwhentheLSPisinflightduringflooding.ThechecksumvalueisinsertedintotheLSPbytheoriginatingrouterandisverifiedbyanyrouterthatreceivesacopy.IfanLSPfailsachecksumvalidation,itisconsideredascorruptedandshouldnotbeusedinroutingcalculationsorfloodedtootherpartsofthenetwork.Asaprecaution,whenarouterdeterminesanLSPiscorrupted,itattemptstopurgetheLSPfromthenetworkbysettingitsremaininglifetimeto0andfloodingcopiestoallitsneighbors.

OtherinterestingfieldsintheLSPheader,asshowninFigure10-11,areasfollows:•PartitionBit(P)—Bit8.SettoindicatewhethertheoriginatoroftheLSPsupportspartitionrepair.ThiscapabilitycurrentlyisnotsupportedinCiscoIOSSoftware.•AttachedBit(ATT)—Bits4to7.AnyofthesebitsissettoindicatethatthenodeisattachedtoanotherareaortheLevel2backbone.ThesebitsaresetintheLevel1LSPsgeneratedbyLevel1–2routers.Theonespecificbitsetindicatesthetypeofmetricusedinthebackbone.Thebitsaredefinedasfollows:—Bit4—Defaultmetric—Bit5—Delaymetric—Bit6—Expensemetric—Bit7—Errormetric

Onlybit4issetonCiscoroutersbecausethedefaultmetricistheonlysupportedmetrictype.•LSPDatabaseOverloadBit(O)—Bit3.Thisissettoindicatethattheoriginrouterisoverloadedandcouldbeexperiencingresource(memoryorprocessing)starvationproblems.NopathsshouldbecalculatedthroughtheoriginsofLSPwiththeoverloadbitset.TheCiscoIOSSoftwarecommandset-overload-bitcanmanuallysettheoverloadbitforadministrativeandresource-managementpurposes.Theoverloadbitisalsoknownasthehippitybit.•ISType—Bits1and2.ThisfieldindicatesthetypeofrouterissuingtheLSP.Bit1onlyissetforaLevel1router,andbothbitsaresetforaLevel2router.Theothercombinationsareunused.Obviously,iftheIStypeissetforaLevel2routerinaLevel1LSP,thesourceisaLevel1–2router.

Example10-1showstheoutputoftheCiscoIOSSoftwarecommandshowisisdatabasedetail.Asmentionedpreviously,thekeyelementsofanLSParecapturedinthisoutput.ThisisaveryusefulcommandfortroubleshootingIS-ISroutingproblemsinvolvingmissingroutes.Example10-1DisplayingDetailsofanLSPonaCiscoRouter

GSR2#showisisdatabaselevel-2detailRTA.00-00

IS-ISLevel-2LSPRTA.00-00LSPIDLSPSeqNumLSPChecksumLSPHoldtimeATT/P/OL

GSR2.00-00*0x0000000E0x08B59860/0/0AreaAddress:49.0001NLPID:0xCCHostname:RTAIPAddress:13.1.1.2Metric:10ISRTA.02Metric:10ISRTB.01Metric:10ISRTC.00Metric:10IP10.1.1.0255.255.255.252Metric:10IP12.1.1.0255.255.255.0Metric:10IP13.1.1.2255.255.255.255

FloodingandDatabaseSynchronizationTheIS-ISfunctionalprocessresponsibleformaintainingthelink-statedatabase(thatis,generatinglocalLSPs,receivingandadvertisingLSPstoneighbors)isreferredtoastheupdateprocess.TheupdateprocessplaysanimportantroleinIS-ISroutingbymakingsurethatroutersinthedomainreceivetimely,reliable,andcompleteinformationabouttheroutingenvironment.Thisinformationisnecessaryfordeterminationofoptimalpathstovariousdestinationsthroughoutthenetwork.TheprocessbywhichLSPsareadvertisedanddistributedbetweenroutersinadomainisknownasflooding.WhenarouterreceivesLSPsfromitsneighbors,itstorescopiesinitslocaldatabaseandthenforwardscopiestoneighborsonlinksotherthanthoseonwhichtheLSPswerereceived.AllL1routersinthesameareaultimatelybuildidenticalcollectionsofLevel1LSPsintheirLevel1database.ThesamethingappliestotheLevel2routersthatareconnectedtothebackbone.Understableconditions,theLevel2routersinthedomainhavethesamesetofLSPsintheirLevel2link-statedatabasesjustasLevel1routersinthesameareahavethesamesetofLSPsintheirLevel1databases.TheprocessofensuringthateveryrouterreceivesallknownLSPsintheLevel1orLevel2databasesisreferredtoasdatabasesynchronization.Otherauxiliaryfunctionscarriedoutbytheupdateprocessensuredatabasesynchronization.Varioustimersandcontrolmechanismsareemployedtoguaranteeeffectivenessoftheupdateprocessincarryingoutfloodinganddatabasesynchronization.SequenceNumberPDUs(SNPs)providecontrolofthesynchronizationprocess.Actually,therearetwotypesofSNPs:•CompletesequencenumberPDUs(CSNP)—ContainsummariesofallLSPsknownbytheissuingrouter•PartialsequencenumberPDUs(PSNP)—ContainsummariesofonlyasubsetofknownLSPsandsolicitnewerversionsofacompleteLSPoracknowledgereceiptofLSPs

EachLSPsummaryinaCSNPorPSNPconsistsofthefollowingattributesfromtheheaderoftheoriginalLSP:•Remaininglifetime•LSPID•LSPsequencenumber•LSPchecksum

Figure10-13elaborateshowCSNPsandPSNPsareusedforLSdatabasesynchronization.ThecompleteformatsofCSNPandPSNPareprovidedattheendofthechapterinthesectiontitled“AdditionalIS-ISPacketInformation.”

Figure10-13LSPFloodingandSynchronization

Asnotedpreviously,varioustimersplaysignificantrolesinthefloodinganddatabase-synchronizationprocess.Table10-6listssomekeytimersemployedbytheupdateprocess.AlsofeaturedaretheirdefaultvaluesinCiscoIOSSoftware,whichmostlyconformtovaluesspecifiedbyISO10589.Theright-mostcolumnofthetablelistscorrespondingCiscoIOSSoftwarecommandsformodifyingthedefaulttimervalues.

Table10-6Link-StateDatabaseUpdateTimers

Figure10-13showsanetworkwithapoint-to-pointconnectionbetweenRT1andRT2.RT2alsoisconnectedtoRT3andRT4overabroadcastLAN.AlsodepictedistheprocessofLSPfloodingoverthepoint-to-pointandLANlinks.IS-ISusesareliablefloodingmechanismonpoint-to-pointlinksinwhichLSPsfloodedoutaninterfacemustbeacknowledgedwithaPSNPbythenodeattheotherendofthelink.LSPsfloodedoverbroadcastlinks,ontheotherhand,don’tneedtobeacknowledgedbytherecipients.Synchronizationofdatabasesoverbroadcastlinksiscarriedoutwiththehelpofthedesignatedintermediatesystem(DIS),whichperiodicallymulticastsasummaryofallknownLSPsinaCSNP.RoutersthatnoticeanyLSPsintheCSNPthattheydonothavethenrequestthecompletecopiesbyusingPSNPs.IS-ISLevel1andLevel2packetsareadvertisedtotheAllL1ISsandAllL2ISmultidestinationaddresses,respectively.InFigure10-13,RT1advertisesanLSP(RT1.00-00)overthepoint-to-pointconnectiontoRT2,whichacknowledgesasexpectedwithaPSNP.RT2thensavesacopyinitsdatabaseandfloodsanothercopyovertheLANtoRT3andRT4.RT3andRT4donotacknowledgereceiptofRT1.00-00.AttheexpirationoftheCSNPtimer,however,RT2,whichisalsotheDISontheLAN,advertisesaCSNPwithsummariesofallknownLSPs.BecauseRT4obviouslydidn’treceiveacopyofRT1.00-00transmittedbyRT2,itnoticesthatitismissingthatLSPfromthesummarythatitreceives,anditrequestsacompletecopywithaPSNP.ThecompleteRT1.00-00thenismulticastagainovertheLANbyRT2.

ShortestPathFirst(SPF)AlgorithmandIS-ISRouteCalculationTheprevioussectiondiscussesthelink-statedatabaseandthevariousmechanismsforreliablypopulatingitwithLSPs.EventhoughLSPsareroutingrelatedinformation,theyarenotroutesinthemselvesandneedtobeprocessedfurthertoobtaintheactualroutesforforwardingdatapackets.TheIS-ISprocessresponsibleforconvertingtherawlink-stateinformationintoroutesisknownasthedecisionprocess.Thedecisionprocessusestheshortestpathfirst(SPF)(Dijkstra)algorithmforcalculatingthepathstoeveryknowndestinationwithinanareaorthebackbone.IndependentprocessesarerunforLevel1andLevel2usingtherespectivelink-statedatabasesasinput.TheSPFalgorithm12,13computesashortest-pathtreetoallnodesinanareaorthebackbonewiththecalculatingrouterattheroot.Thecalculationisdoneinaniterativemannerbyusingthreesets:•Unknown•Tentative(TENT)•Paths(PATH)

AllnodeswiththeexceptionoftherootinitiallyareplacedintheunknownsetandaremovedtotheTENTsetinturn,beginningwiththenodesdirectlyconnectedtotheroot.Ateachiteration,thenodeintheTENTsetthatisclosesttotherootismovedintothePATHlist.ThenodesdirectlyconnectedtothemostrecentgraduatefromtheTENTsetarethenmovedintotheTENTsetifnotalreadypresent.ThecostsofnodesintheTENTsetarethenadjustedforthenextiteration.ThiscontinuesuntilallnodesareinthePATHsetandtheshortest-pathtreeiscompletelybuilt.Routesthenarederivedfromtheshortest-pathtree.

ConfiguringIS-ISforIPRoutingThissectionreviewsthebasictasksinvolvedinenablingIS-ISonCiscorouters.Inadditiontothebasicconfiguration,numerousCiscoIOSSoftwarecommandsexistforenablingvariousoptimizationandmanagementcapabilities,suchasmodifyinghellotimers,loggingIS-ISadjacencychanges,performingauthentication,andsoon.Chapter11coverssomeoftheseoptionsingreaterdetail.Forcompleteness,however,youshouldconsultthe“IOSNetworkProtocolsConfigurationGuide,”availableatwww.cisco.com.8

EnablingIS-ISonpoint-to-pointandLANbroadcast–typelinksissimpleandsimilarinbothcases.Additionally,onLANtypelinks,youcanusetheinterface-levelcommandisispriorityvaluetoselectapreferredroutertobeDIS.Thedefaultinterfacepriorityis64.Ahighervalueispreferred.ThefollowingsectionsprovideexamplesthatelaborateonconfiguringIS-ISspecifically:•ConfiguringIS-ISonpoint-to-pointseriallinks•ConfiguringIS-ISonbroadcastlinks(thatis,LANmedia)•ConfiguringIS-ISonNBMAlinks,includingthefollowing:

—ATMpoint-to-point—ATMmultipoint

•IPdefaultrouteadvertisement•Redistribution•IProutesummarization

ConfiguringIS-ISonPoint-to-PointSerialLinksFigure10-14showstworouters,RT1andRT2,connectedbacktobackbyaseriallink.Bothroutersare


placedinthesameIS-ISarea.Figure10-15showsasimilarsetupbutwithRT1andRT2indifferentareas.TheAreaIDsofRT1andRT2aremismatchedtoputthemindifferentareas.

Figure10-14IS-ISConfiguration:NetworkDiagramforExample10-2

Figure10-15IS-ISConfiguration:NetworkDiagramforExample10-3

ThefollowingtwostepsarerequiredtoenablebasicIS-ISroutingonCiscorouters:

Step1Configuretheroutingprocess.

Step2ApplyIS-ISroutingtorelevantinterfacesoftheroutertoactivateIS-ISroutingoverthem.

Theconfigurationcommand,routerisis[tag],enablestheIS-ISroutingprocess.Thetagisanoptionalkeywordforlabelingtheroutingprocess,anditisofsignificanceonlyinthelocalrouterwhereitisused.Someserviceprovidersmaintainthesametagonallroutersinthedomain,eventhoughitisnotrequired.Itshouldbenoted,however,thatsomeoldCiscoIOSSoftwarereleasesrequirethetagstomatchbetweenneighborrouters.Bydefault,CiscoroutersbehaveasLevel1–2whenIS-ISfirstisenabledonthem.Thecommandclnsroutingalsoisenteredautomaticallyintotheconfigurationwhentheroutingprocessisactivated.AnNSAPaddressmustbeconfiguredontherouterevenifitistobeusedtorouteonlyIP.Therouter-levelcommandnet{nsap}isusedforthis.ANETisanNSAPwitha0-valueNSEL.ThenextstepafterconfiguringtheroutingprocessistoenableIS-ISroutingontheinterfaceswhereIS-ISroutingisdesired.Thecommandiprouterisis[tag]issufficientforIP-onlyrouting.Thetagmustbethesameastheoneusedfortheroutingprocess.IfISOCLNProutingandpacketforwardingarerequired,theycanbeenabledwiththeinterfacecommandclnsrouterisis[tag].ExclusiveLevel1orLevel2routingcanbeenabledforindividualinterfaceswiththeinterface-levelcommandisiscircuittype{level-1|level-2|level-1-2}.Thelevel-1-2optionrestoresthedefaultbehavior.Therouter-levelcommandis-type{level-1|level-2-only|level-1-2}appliesthepreferredmodeofoperationtoallinterfacessimultaneously.InFigure10-14,bothroutersareinthesameareaandshareacommonareaprefix(49.0001).Therefore,

accordingtothedefaultCiscoIOSSoftwarebehavior,theyestablishLevel1andLevel2adjacencies.Example10-2showstheconfigurationforRT1andRT2,whicharedepictedinFigure10-14.Example10-2ConfiguringPoint-to-PointIS-ISNeighborsinSameArea

hostnameRT1clnsrouting!interfaceLoopback0ipaddress10.1.1.1255.255.255.255iprouterisis!interfaceSerial0/0ipaddress192.168.1.1255.255.255.252iprouterisis!routerisisnet49.0001.0000.0000.0001.00

hostnameRT2clnsrouting!interfaceLoopback0ipaddress10.1.1.2255.255.255.255iprouterisis!interfaceSerial0/0ipaddress192.168.1.2255.255.255.252iprouterisis!routerisisnet49.0001.0000.0000.0002.00

IncontrasttoFigure10-14,theroutersinFigure10-15areindifferentareas,sotheywillformonlyaLevel2adjacency.Example10-3showstheconfigurationforRT1andRT2depictedinFigure10-15.Example10-3ConfiguringPoint-to-PointIS-ISNeighborsinDifferentAreas

hostnameRT1!interfaceLoopback0ipaddress10.1.1.1255.255.255.255iprouterisis!interfaceSerial2/0ipaddress192.168.1.1255.255.255.252iprouterisis!routerisisnet49.0001.0000.0000.0001.00

hostnameRT2!interfaceLoopback0ipaddress10.1.1.2255.255.255.255iprouterisis!interfaceSerial2/0

ipaddress192.168.1.2255.255.255.252iprouterisis!routerisisnet49.0002.0000.0000.0002.00

ThefollowingcommandsareusefulforverifyingproperconfigurationandoperationofIS-ISonCiscorouters:•showclnsprotocol•showclnsneighbors[detail]•showclnsinterface•showisistopology•showisisdatabase

ThesectionsthatfollowprovideexampleoutputsfromtheseshowcommandsbasedontheroutersetupinFigure10-15.Eachexamplefeaturesoutputfromeachrouter(RT1andRT2)toshowthestateofeithersideoftheconnection.Becausethesetupisbasic,mostoftheoutputisself-explanatory.The“IntegratedIS-ISConfigurationGuide,”atCisco.com,9providesadetailedexplanationofthefieldsintheshowcommandoutputpresentedinthesesections.

showclnsprotocolCommand

Theshowclnsprotocolcommandliststheprotocol-specificinformationforeachIS-ISorISOIGRProutingprocessinarouter.Example10-4displaystheshowclnsprotocolcommandoutputforbothroutersdepictedinFigure10-15.Example10-4showclnsprotocolCommandOutput

RT1#showclnsprotocolIS-ISRouter:<NullTag>SystemId:0000.0000.0001.00IS-Type:level-1-2Manualareaaddress(es):49.0001Routingforareaaddress(es):49.0001InterfacessupportedbyIS-IS:Loopback0-IPSerial0/0-IPRedistributing:staticDistance:110RRRlevel:noneGeneratenarrowmetrics:level-1-2Acceptnarrowmetrics:level-1-2Generatewidemetrics:noneAcceptwidemetrics:none

RT2#showclnsprotocolIS-ISRouter:<NullTag>SystemId:0000.0000.0002.00IS-Type:level-1-2Manualareaaddress(es):49.0002Routingforareaaddress(es):49.0002InterfacessupportedbyIS-IS:Loopback0-IPSerial0/0-IP

http://Cisco.com

Redistributing:staticDistance:110RRRlevel:noneGeneratenarrowmetrics:level-1-2Acceptnarrowmetrics:level-1-2Generatewidemetrics:noneAcceptwidemetrics:none

showclnsneighborsdetailCommand

Theshowclnsneighborsdetailcommanddisplaysbothend-system(ES)andintermediate-system(IS)neighbors.Example10-5displaystheshowclnsneighborsdetailcommandoutputforbothroutersdepictedinFigure10-15.Example10-5showclnsneighborsdetailCommandOutput

RT1#showclnsneighborsdetail

SystemIdInterfaceSNPAStateHoldtimeTypeProtocolRT2Se0/0HDLCUp27L2IS-ISAreaAddress(es):49.0002IPAddress(es):192.168.1.2*Uptime:00:48:46


SystemIdInterfaceSNPAStateHoldtimeTypeProtocolRT1Se0/0HDLCUp26L2IS-ISAreaAddress(es):49.0001IPAddress(es):192.168.1.1*Uptime:00:52:14

showclnsinterfaceCommand

TheshowclnsinterfacecommandliststheCLNS-specificorES-ISinformationabouteachinterface.Example10-6displaystheshowclnsinterfacecommandoutputforbothroutersdepictedinFigure10-15.Example10-6showclnsinterfaceCommandOutput

RT1#showclnsinterfaceser0/0Serial0/0isup,lineprotocolisupChecksumsenabled,MTU1500,EncapsulationHDLCERPDUsenabled,min.interval10msec.RDPDUsenabled,min.interval100msec.,AddrMaskenabledCongestionExperiencedbitsetat4packetsCLNSfastswitchingenabledCLNSSSEswitchingdisabledDECcompatibilitymodeOFFforthisinterfaceNextESH/ISHin3secondsRoutingProtocol:IS-ISCircuitType:level-1-2Interfacenumber0x0,localcircuitID0x100Level-1Metric:10,Priority:64,CircuitID:RT1.00Numberofactivelevel-1adjacencies:0Level-2Metric:10,Priority:64,CircuitID:RT1.00Numberofactivelevel-2adjacencies:1NextIS-ISHelloin8seconds

RT2#showclnsinterfaceserial0/0Serial0/0isup,lineprotocolisupChecksumsenabled,MTU1500,EncapsulationHDLCERPDUsenabled,min.interval10msec.RDPDUsenabled,min.interval100msec.,AddrMaskenabledCongestionExperiencedbitsetat4packetsCLNSfastswitchingenabledCLNSSSEswitchingdisabledDECcompatibilitymodeOFFforthisinterfaceNextESH/ISHin8secondsRoutingProtocol:IS-ISCircuitType:level-1-2Interfacenumber0x0,localcircuitID0x100Level-1Metric:10,Priority:64,CircuitID:RT2.00Numberofactivelevel-1adjacencies:0Level-2Metric:10,Priority:64,CircuitID:RT2.00Numberofactivelevel-2adjacencies:1NextIS-ISHelloin2seconds

showisistopologyCommand

Theshowisistopologycommanddisplaysalistofallconnectedroutersinallareas.Example10-7displaystheshowisistopologycommandoutputforbothroutersdepictedinFigure10-15.Example10-7showisistopologyCommandOutput

RT1#showisistopIS-ISpathstolevel-1routersSystemIdMetricNext-HopInterfaceSNPART1--

IS-ISpathstolevel-2routersSystemIdMetricNext-HopInterfaceSNPART1--RT210RT2Se0/0HDLC

RT2#showisistopologyIS-ISpathstolevel-1routersSystemIdMetricNext-HopInterfaceSNPART2--

IS-ISpathstolevel-2routersSystemIdMetricNext-HopInterfaceSNPART110RT1Se0/0HDLCRT2--

showisisdatabaseCommand

TheshowisisdatabasecommanddisplaystheIS-ISlink-statedatabase.Example10-8displaystheshowisisdatabasecommandoutputforbothroutersdepictedinFigure10-15.Example10-8showisisdatabaseCommandOutput

RT1#showisisdatabaseIS-ISLevel-1LinkStateDatabaseLSPIDLSPSeqNumLSPChecksumLSPHoldtimeATT/P/OLRT1.00-00*0x000000080x8B7511261/0/0RT1.01-00*0x000000010x459B11310/0/0

IS-ISLevel-2LinkStateDatabaseLSPIDLSPSeqNumLSPChecksumLSPHoldtimeATT/P/OL

RT1.00-00*0x0000008A0x8FED11260/0/0RT2.00-000x0000001E0xB82C9980/0/0

RT2#showisisdatabaseIS-ISLevel-1LinkStateDatabaseLSPIDLSPSeqNumLSPChecksumLSPHoldtimeATT/P/OLRT2.00-00*0x000000190x3DAB8831/0/0RT2.01-00*0x0000000D0x339F9800/0/0

IS-ISLevel-2LinkStateDatabaseLSPIDLSPSeqNumLSPChecksumLSPHoldtimeATT/P/OLRT1.00-000x0000008A0x8FED9310/0/0RT2.00-00*0x0000001E0xB82C8080/0/0

Table10-7listsandexplainsthekeyfieldsinthiscommand’soutput.Table10-7ExplanationofshowisisdatabaseCommandOutput

ATMConfigurationExamplesAsanNBMAmedium,ATMconnectivitycanbeconfiguredasmultipointonarouter’smaininterfaceorsubinterfaces.Anotherconfigurationoptionistousepoint-to-pointconnectivityonsubinterfaces.EnablingIS-ISonATMinterfacesfollowsthesametwostepsforconfiguringIS-ISonpoint-to-pointseriallinks:

Step1Configuretheroutingprocess.

Step2ApplyIS-ISroutingtorelevantinterfaces.

ThemultipointconfigurationworksinthesamewayasthesimplebroadcastLANdescribedpreviously.Similarly,operationofthepoint-to-pointconfigurationisjustliketheserialpoint-to-pointsetup.TheIS-ISconfigurationforFrameRelayisanalogoustotheATMsetupoptionsshowninthissection.ThelargenumbersofvirtualcircuitsinNMBAcloudsresultinhighlymeshedpoint-to-pointconnections.Largemeshesposeresource-related(memoryandCPU)challengestoconnectedroutersbecauseofthehighnumbersofLSPrequiredtobefloodedandprocessedbetweenthelargenumberofconnectedneighbors(intheorderofN3,whereNisthenumberofnodes).ItisstronglyrecommendedthatyouusetheIS-ISmeshgroupfeatureinhighlymeshedenvironmentstocutdownonredundantflooding.

Figure10-16showsanetworkdiagramillustratingasimpleATMconfigurationusingpoint-to-pointsubinterfaces.

Figure10-16ATMNetwork:Point-to-PointSetup

Example10-9showstheconfigurationforRT5andRT6depictedinFigure10-16.Example10-9ATMPoint-to-PointConfigurations

hostnameRT5!clnsrouting!interfaceATM6/0.2point-to-pointipaddress10.1.1.5255.255.255.252noipdirected-broadcastiprouterisisatmpvc2010aal5snap!routerisisnet49.0001.0000.0000.0005.00is-typelevel-2-only

hostnameRT6!clnsrouting!interfaceATM6/0.2point-to-pointipaddress10.1.1.6255.255.255.252noipdirected-broadcastiprouterisisatmpvc2010aal5snap!routerisisnet49.0001.0000.0000.0006.00

is-typelevel-2-onlyintatm6/0.2pointipaddress...iprouterisispvc0/10encapsulationaal5snap

Figure10-17showsthenetworkdiagramfortheATMmultipointconfigurationspresentedinExample10-10.

Figure10-17ATMNetwork:MultipointSetup

Formultipointconfigurations,thecorrespondingclnsmapstatementisrequired,asshowninExample10-10.InATM,theclnsmapstatementsareplacedundertheATMmaplist.Example10-10ATMPoint-to-PointConfigurations

hostnameRT7!clnsrouting!interfaceATM6/0.1multipointipaddress10.1.1.7255.255.255.0noipdirected-broadcastiprouterisisatmpvc108aal5snapmap-groupISIS_CONFIG!routerisisnet49.0001.0000.0000.0007.00is-typelevel-2-only!map-listISIS_CONFIGip10.1.1.8atm-vc1broadcast

clns49.0001.0000.0000.0008.00atm-vc1broadcast

hostnameRT8!clnsrouting!interfaceATM6/0.1multipointipaddress10.1.1.8255.255.255.0noipdirected-broadcastiprouterisisatmpvc108aal5snapmap-groupISIS_CONFIG!routerisisnet49.0001.0000.0000.0008.00is-typelevel-2-only!map-listISIS_CONFIGip10.1.1.7atm-vc1broadcastclns49.0001.0000.0000.0007.00atm-vc1broadcastIntatm6/0Pvc0/5Encapsulationqsaal

IPDefaultRouteAdvertisementInIS-IS,Level1routersautomaticallyinstallanIPdefaultroutetothenearestLevel1–2routersinthearea.TheLevel1routersdetecttheLevel2routersbytheattached(ATT)bitsettingintheLevel1LSPsissuedbyLevel1–2routers.Level1–2routersgenerateLevel1LSPsintotheirlocalareaandsettheATTbitintheseLSPstoflagtheirconnectivitytothebackbone.Ontheotherhand,amanualconfigurationisrequiredtogenerateadefaultrouteintotheLevel2backbone.Therouter-levelcommanddefault-informationoriginateallowsaLevel2routertoadvertiseadefaultrouteintothebackbone,whichwillbeseenbyotherLevel2routers.ThecommandcausesadefaultroutetobeinsertedintotheLevel2LSPoftheadvertisingrouter.UnlikesimilarconfigurationsinotherIProutingprotocols,anexplicitstaticdefaultrouteisnotrequiredtobackupthedefault-informationoriginatecommand.Figure10-18showsthenetworkdiagramforillustratingusageofthedefaultinformationprovidedinExample10-11.

Figure10-18NetworkDiagramforExample10-11

Example10-11showsexcerptsoftheconfigurationfileofarouterwiththedefault-informationoriginatecommandenabledundertheIS-ISroutingprocess.AlsoshownistheLevel2LSPfeaturingadefaultrouteentrywithametricof0.Example10-11Usingthedefault-informationoriginateCommand

RT1#showrunning-config[snip]HostnameRT1!routerisisdefault-informationoriginatenet49.0001.0000.0000.0001.00[snip]

RT2#showisisdatabasedetailRT1.00-00level-2

IS-ISLevel-2LSPRT1.00-00LSPIDLSPSeqNumLSPChecksumLSPHoldtimeATT/P/OLRT1.00-000x000000E10x7A1E6510/0/0AreaAddress:49.0001NLPID:0xCCHostname:RT1IPAddress:10.1.1.1Metric:10ISRT1.01Metric:10ISRT2.00Metric:0IP0.0.0.00.0.0.0Metric:10IP10.1.1.1255.255.255.255Metric:10IP192.168.1.0255.255.255.252

RouteRedistributionTheIS-ISprotocolconsidersallrouteslearnedbyarouterfromothersources,suchasstaticroutes,theRoutingInformationProtocol(RIP),andOpenShortestPathFirst(OSPF),asexternalroutes.ExternalroutescanbeintroducedintotheIS-ISenvironmentbymeansofrouteredistribution.TheprocedurecanalsobeusedtoadvertiseIS-ISroutesintoanotherroutingprotocol,suchasOSPF.Thissectionfocusesontheformer,redistributingroutesintoIS-IS.RFC1195allowsredistributionintoonlytheLevel2routingenvironment.Forpracticalpurposes,however,CiscoIOSSoftwareallowsredistributionintoLevel1aswell.ThiscapabilityprimarilywasrequiredbyserviceproviderswhobuiltsingleLevel1IS-ISareasfortheirIGPinfrastructures,toavoidsuboptimalroutingissuesinhierarchicalarchitecturesintheabsenceofdomain-wideprefixdistribution.HavingexternalIPreachabilityinformationinLevel1LSPsshouldnotposeanyinteroperabilityproblemsbecauseIS-ISroutersarenotexpectedtoparseanyunknownTLVsinanIS-ISpacket.TheyshouldjustskipthemtothenextsupportedTLV.TheconfigurationandmechanismsunderlyingoperationofrouteredistributionareelaboratedinExample10-12,whichisbasedonFigure10-19.

Figure10-19NetworkDiagram:RedistributionExample

AsinthecaseofotherIProutingprotocols,redistributionofIPstaticroutesintoIS-ISrequiresexplicitconfigurationwiththerouter-levelcommandredistribute.ThecompletecommandforIS-ISis

redistributesourceipoptions.NotethattheipkeywordisrequiredonthecommandlinetospecifythattheoperationisrelevanttoIProuting.YoumightrecallthatIntegratedIS-ISsupportsbothIPandCLNProuting.Otherconfigurationoptionsoftheredistributecommandincludeametricvalue,ametrictype,aroutemap,andsoon.TheroutemapoptionprovidesamechanismforfilteringroutesimportedintotheIS-ISenvironment.Bydefault,themetrictypeinternalisassignedtoexternalroutes,andtheyareaddedintoonlytheLevel2environmentifnolevelisspecified.ThisisdemonstratedinExample10-12.Thehighlightedlineintheshowrunning-configoutputshowstheredistributioncommandlineintheconfigurationfile.ThehighlightedlineintheshowisisdatabaseoutputshowsanexternalrouteinanLSP.ThelastoutputinExample10-12showsashowiproutecommandoutputfromRouterRT2;thehighlightedlineistheexternalroutethatwasoriginatedfromRT1.Example10-12ConfiguringBasicRouteRedistribution

RT1#showrunning-config[snip]routerisisredistributestaticipmetric0metric-typeinternallevel-2default-informationoriginatenet49.0001.0000.0000.0001.00

RT2#showisisdatabaselevel-2detailRT1.00-00

IS-ISLevel-2LSPRT1.00-00LSPIDLSPSeqNumLSPChecksumLSPHoldtimeATT/P/OLRT1.00-000x000000F30x04DF9560/0/0AreaAddress:49.0001NLPID:0xCCHostname:RT1IPAddress:10.1.1.1Metric:10ISRT1.01Metric:10ISRT2.00Metric:0IP0.0.0.00.0.0.0Metric:0IP-External10.4.4.0255.255.255.0Metric:10IP10.1.1.1255.255.255.255Metric:10IP192.168.1.0255.255.255.252

RT2#showiproute[snip]Gatewayoflastresortis192.168.1.1tonetwork0.0.0.010.0.0.0/8isvariablysubnetted,4subnets,2masksC10.1.1.2/32isdirectlyconnected,Loopback0iL210.4.4.0/24[115/10]via192.168.1.1,Serial0/0iL210.1.1.1/32[115/20]via192.168.1.1,Serial0/0192.168.1.0/30issubnetted,1subnetsC192.168.1.0isdirectlyconnected,Serial0/0i*L20.0.0.0/0[115/10]via192.168.1.1,Serial0/0

InExample10-13,themetrictypeexplicitlyisconfiguredandspecifiedtobeexternal.Internalmetricsarecomparabletometricsusedforinternalroutes;externalmetricsrequiretheI/Ebitofthemetricfieldtobeset,bumpingupthevalueofthemetricapplied.

CautionCiscoIOSSoftwaresetsbit8insteadofbit7fortheI/Ebitwhenusingnarrowmetrics,whichresultsinanincreaseinthemetricvalueby128insteadof64.

Example10-13SpecifyingExternalMetricTypeinIS-ISRedistribution

RT1#showrunning-config[snip]routerisisredistributestaticipmetric0metric-typeexternallevel-2default-informationoriginatenet49.0001.0000.0000.0001.00!iproute10.4.4.0255.255.255.0Null0

RT2#showisisdatalevel-2detailRT1.00-00

IS-ISLevel-2LSPRT1.00-00LSPIDLSPSeqNumLSPChecksumLSPHoldtimeATT/P/OLRT1.00-000x000000F10xA7BD7270/0/0AreaAddress:49.0001NLPID:0xCCHostname:RT1IPAddress:10.1.1.1Metric:10ISRT1.01Metric:10ISRT2.00Metric:0IP0.0.0.00.0.0.0Metric:128IP-External10.4.4.0255.255.255.0Metric:10IP10.1.1.1255.255.255.255Metric:10IP192.168.1.0255.255.255.252

RT2#showiproute[snip]Gatewayoflastresortis192.168.1.1tonetwork0.0.0.010.0.0.0/8isvariablysubnetted,4subnets,2masksC10.1.1.2/32isdirectlyconnected,Loopback0iL210.4.4.0/24[115/138]via192.168.1.1,Serial0/0iL210.1.1.1/32[115/20]via192.168.1.1,Serial0/0192.168.1.0/30issubnetted,1subnetsC192.168.1.0isdirectlyconnected,Serial0/0i*L20.0.0.0/0[115/10]via192.168.1.1,Serial0/0

ThehighlightedlineinExample10-13showstheredistributecommandsyntaxwiththemetrictypespecifiedasexternal.Thecorrespondingexternalentryishighlightedintheshowisisdatabaseoutputwithametricof128insteadofthe0thatwasfeaturedinExample10-12.TheexternalrouteadvertisedfromRT1ishighlightedintheshowiprouteoutputofRT2attheendoftheexample.

IPRouteSummarizationAnIS-ISroutercanbeconfiguredtosummarizeIProutesintoLevel1,Level2,orbothwiththefollowingrouter-levelconfigurationcommand:

summary-addressprefix[level-1|level-2|level-1-2].

Bydefault,summariesgointoLevel2ifnolevelisspecifiedonthecommandline.Example10-14displaysasampleconfigurationandrelatedshowcommandoutputsbasedonFigure10-20.Intheexampleprovided,theIPsubnetassignedtoEthernet0/0ofRT1,11.1.1.0/24,issummarizedas11.0.0.0/8.

Thesummaryroute11.0.0.0/8thenisobservedatRT2.

Figure10-20NetworkDiagram:IPRouteSummarizationExample

Thehighlightedlineintheshowrunning-configoutputprovidedinExample10-14showsthecommandlineonRT1.ThehighlightedlineintheshowisisdatabaseoutputshowsthesummaryentryinRT1’sLSP,andthehighlightedlineintheshowiprouteonRT2showsevidencethatthesummaryroutehasbeenpropagatedtootherLevel2routers.Example10-14RouteSummarizationConfigurationExample

RT1#showrunning-configinterfaceEthernet0/0ipaddress11.1.1.1255.255.255.0iprouterisis!interfaceSerial0/0ipaddress192.168.1.1255.255.255.252iprouterisis!routerisissummary-address11.0.0.0255.0.0.0redistributestaticipmetric0metric-typeinternallevel-2default-informationoriginatenet49.0001.0000.0000.0001.00

RT2#showisisdatalevel-2detailRT1.00-00

IS-ISLevel-2LSPRT1.00-00LSPIDLSPSeqNumLSPChecksumLSPHoldtimeATT/P/OLRT1.00-000x000000F70xF8AA5180/0/0AreaAddress:49.0001NLPID:0xCCHostname:RT1IPAddress:10.1.1.1Metric:10ISRT1.02Metric:10ISRT1.01Metric:10ISRT2.00Metric:0IP0.0.0.00.0.0.0Metric:0IP-External10.4.4.0255.255.255.0Metric:10IP10.1.1.1255.255.255.255Metric:10IP192.168.1.0255.255.255.252Metric:10IP11.0.0.0255.0.0.0RT2#showiproute[snip]Gatewayoflastresortis192.168.1.1tonetwork0.0.0.0

10.0.0.0/8isvariablysubnetted,4subnets,2masksC10.1.1.2/32isdirectlyconnected,Loopback0iL210.4.4.0/24[115/10]via192.168.1.1,Serial0/0

iL210.1.1.1/32[115/20]via192.168.1.1,Serial0/0iL211.0.0.0/8[115/20]via192.168.1.1,Serial0/0192.168.1.0/30issubnetted,1subnetsC192.168.1.0isdirectlyconnected,Serial0/0i*L20.0.0.0/0[115/10]via192.168.1.1,Serial0/0

SummaryThischapterelaboratedonthearchitectureoftheIS-ISroutingprotocol,discussingbasicconceptsaswellasadvancedprotocolmechanismsinvolvingthelink-statedatabase.ThechapteralsoprovidedinsightintoconfigurationproceduresrequiredforenablingIS-ISroutingonCiscorouters.EventhoughthisbookisfocusedonuseofIS-ISforIProuting,sometimewasdedicatedtoexploringtheoriginsoftheIS-ISprotocolasadynamicroutingapplicationforISOCLNP.IS-ISisspecifiedinISO10589,whichisreproducedasRFC1142.RFC1195adaptsIS-ISforIProutingbyintroducingextensions(TLVfields)forcarryingIProutinginformationinadditiontoCLNPinformation.CLNPaddresses,alsocalledNSAPs,aredifferentfromIPaddresses:Theyhaveavariablelengthfrom8bytes(onCiscorouters)upto20bytes,comparedtothefixed4-bytelengthforIPaddresses.Also,NSAPsarenode-based,whileIPaddressesareconfiguredonrouterinterfaces,essentiallynumberingtheconnectedlinks(link-based).YoualsolearnedinthischapterabouttwotypesoflinkscommonlyrecognizedinIS-ISimplementations:point-to-pointandbroadcastlinks.ThesetwolinkstypesaretiedtothetwotypesofadjacenciessupportedinIS-IS:point-to-pointandbroadcastadjacencies.IS-ISadjacenciesareneededforsubsequentsharingoflink-stateinformationandbuildingoflink-statedatabasesonparticipatingrouters.IS-IShellopacketsareusedtoestablishandmaintainadjacencies.IS-ISsupportsatwo-levelroutinghierarchywithlevel-1routingoccurringinsectionsofthenetworkreferredtoasareas.AreasconstituteinterconnectedrouterswithacommonareaidentifierintheirNSAPaddresses.TheregionthatspansinterconnectionbetweenareasisaspecialareaknownastheIS-ISbackbone.Level2routingoccursinthebackbone.ThespecialpacketsforadvertisingroutinginformationbetweenadjacentIS-ISroutersarelink-statepackets.FloodingistheprocessusedintransmittingLSPsbetweenrouters.RoutersinthesameareamusthavethesameLevel1link-statedatabase;similarly,routersinthebackbonemusthavethesameLevel2link-statedatabase.Theprocessforensuringconsistencyinthevariouslink-statedatabasesbetweenroutersisdatabasesynchronization.Specialpacketsknownassequencenumberpackets(CSNPsandPSNPs)areusedforthesynchronizationprocess.Youalsolearnedhowsequencenumberpacketsareusedfordatabasesynchronization.IndiscussingtheIS-ISconfigurationonCiscorouters,examplesforserialpoint-to-pointlinksandATMconnectivityareprovided.Inaddition,itisnotedthattheexamplesprovidebaselineconfigurationapplicabletoothermedia,suchasFrameRelay.EnablingIS-ISroutingonaCiscorouterinvolvestwobasicsteps:configuringtheIS-ISroutingprocessandthenenablingIS-ISroutingontheinterfaceswhereIS-ISadjacenciesandroutesharingoccur.ThischapterprovidesareviewoftheIS-ISprotocolandpreparesyouforthenextchapter,whichdiscussestechniquesfortroubleshootingIS-ISroutingproblems.FormorecompletecoverageonconfiguringtheIS-ISroutingprotocolonCiscorouters,readingreferencesareprovidedattheendofthechapter.

AdditionalIS-ISPacketInformationThefollowingsectionsprovideadditionalinformationonthefollowingpackettypes:•IS-ISpackets•Hellopackets

•Link-statepackets•Sequencenumberpackets

IS-ISPacketFields(AlphabeticalOrder)•ATT—Specifiestheattachmentbits(flagattachmentstootherareas).•Checksum—GivesthechecksumofthecontentsoftheLSPfromthesourceIDtotheend.•CircuitType—DefineswhetherthelinkisLevel1and/orLevel2.•EndLSP—IstheLSPIDofthelastLSPinCSNP.•HoldingTime—Defineshowlongtowaitforahellofromthissystembeforeclearingtheadjacency.•IDLength—GivesthelengthofthesystemIDfieldinanNSAP(NET).•IntradomainRoutingProtocolDiscriminator—Isthenetworklayerprotocolidentifier•ISType—Definesthetypeofrouter,Level1orLevel2.•LANID—ConsistsofthesystemIDofthedesignatedintermediatesystem,plusauniquenumberasanidentifieroftheLAN.•LengthIndicator—Givesthelengthofthefixedheaderofthepacket,inbytes.•LocalCircuitID—Isauniqueidentifierforalink.•LSPID—Isanidentifierforarouter’sLSP,consistingofthesystemIDoftherouter,afragmentnumber,andanonzerooctetforthepseudonodenumber,incaseofapseudonodeLSP.•MaximumAreaAddresses—Specifiesthenumberofareaspermitted.•OL—IsanLSPoverloadbit(alsorepresentedasLSPDBOL).•P—Isthepartitionrepairbit.•PDULength—Givesthelengthofthepacket(PDU),inbytes.•PDUType—Specifiesthetypeofpacket.•Priority—ShowsthepriorityforanodeforDISarbitration.•R—SeeReserved.•RemainingLifetime—SpecifiestheremainingtimeforanLSPtoexpire.•Reserved—Consistsofunspecifiedfields.Istransmittedaszerosandignoredonreceipt.•SequenceNumber—IsthesequencenumberoftheLSP.•SourceID—Isthesameasthesystemidentifier(SysID).•TLVFields—ConsistsofType(orcode),Length,andValuefields.Alsoknownasvariable-lengthfields.•Version/ProtocolIDExtension—AppliestotheIS-ISprotocol(definedas1).

HelloPackets

Figure10-21LANLevel1HelloPacketFormat(PDUType15)

Figure10-22LANLevel2HelloPackets(PDUType16)

Figure10-23Point-to-PointHelloPackets(PDUType17)

Link-StatePackets

Figure10-24Level1Link-StatePackets(PDUType18)

Figure10-25Level2Link-StatePackets(PDUType20)

SequenceNumberPackets

Figure10-26CompleteSequenceNumberPackets(PDUType24)

Figure10-27Level2CompleteSequenceNumberPackets(PDUType25)

Figure10-28Level1PartialSequenceNumberPackets(PDUType26)

Figure10-29Level2PartialSequenceNumberPackets(PDUType27)

ReviewQuestions1NamethethreenetworklayerprotocolsthatformthebasisofISOconnectionlessnetworkservices.2HowmanylevelsarethereintheroutinghierarchysupportedbytheIS-ISroutingprotocol?3WhatisthegenerallayoutoftheIS-ISpacketformat?4WhatdoestheacronymNSAPstandfor,andwhatisitusedfor?5WhatarethethreemajorcomponentsofanNSAP?Describethesignificanceofeach.6WhatisthemaximumlengthofanNSAP,andwhatistheminimumlengththatcanbeconfiguredonaCiscorouter?

7WhatisthesignificanceoftheIS-ISlink-statedatabase?8WhatisthebasicdifferencebetweenLevel1andLevel2link-statedatabases?9Howarefloodinganddatabasesynchronizationdifferentbetweenapoint-to-pointlinkandabroadcastlink?

10DescribethetwostepsforenablingbasicIS-ISroutingonaCiscorouter.11ListsomeshowcommandsthatyoucanusetoverifyconfigurationandoperationofIS-IS.

FurtherReading1ISO8473,“ConnectionlessNetworkProtocol,”forprovidingtheconnectionless-modenetworkservice(CLNP).AlsopublishedasIETFRFC994.

2ISO9542,“EndSystem-to-IntermediateSystemRoutingExchangeProtocol,”foruseinconjunctionwiththeprotocolforprovidingtheconnectionless-modenetworkservice(ES-IS).AlsopublishedasIETFRFC995.

3ISO10589,“IntermediateSystem-to-IntermediateSystemIntradomainRoutingExchangeProtocol,”foruseinconjunctionwiththeprotocolforprovidingtheconnectionless-modeservice(IS-IS).AlsopublishedasIETFRFC1142.

4IETFRFC1195,“UseofOSIIS-ISforRoutinginTCP/IPandDualEnvironments.”R.Callon,1990.5.

5draft-ietf-isis-3way-01.txt:Three-wayHandshakeforIS-ISpoint-to-pointadjacencies.6RFC2966,“DomainWidePrefixDistributionwithTwo-LevelIS-IS.”TonyLi,TonyPrzygienda,andHenkSmit.

7Li,Tony,andHenkSmit.“IS-ISExtensionsforTrafficEngineering.IETFdraft,June2001.http://search.ietf.org/internet-drafts/draft-ietf-isis-traffic-03.txt.

8“ConfiguringIntegratedIS-IS.”Ciscodocumentation.www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/np1_c/1cprt1/1cisis.htm#4552.

9Hopps,ChristianE.“RoutingIPv6withIS-IS.”IETFdraft2001.http://search.ietf.org/internet-drafts/draft-ietf-isis-ipv6-02.txt.

10Li,Tony,andR.J.Atkinson.“IS-ISCryptographicAuthentication.”IETFdraft,July2001.http://search.ietf.org/internet-drafts/draft-ietf-isis-hmac-03.txt.

11ETF1996RFC1918,“AddressAllocationforPrivateInternets.”Y.Rekhter,B.Moskowitz,D.Karrenberg,D.J.deGroot,andE.Lear.

12RFC1195,“UseofOSIIS-ISforRoutinginTCP/IPandDualEnvironments.”RossCallon,1990.pp.51–57.

13Perlman,Radia.Interconnections,SecondEdition.AddisonWesley,1999.ISBN0-201-63448-1.pp.317–322.

http://search.ietf.org/internet-drafts/draft-ietf-isis-traffic-03.txt

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/np1_c/1cprt1/1cisis.htm#4552

http://search.ietf.org/internet-drafts/draft-ietf-isis-ipv6-02.txt

http://search.ietf.org/internet-drafts/draft-ietf-isis-hmac-03.txt

Chapter11.TroubleshootingIS-IS

Thischaptercoversthefollowingkeytopics:•TroubleshootingofIS-ISadjacencyproblems•TroubleshootingofIS-ISroutingupdateproblems•IS-ISerrors•CLNSpingandtraceroute•Casestudy:ISDNconfigurationproblem

Chapter10,“UnderstandingIntermediateSystem-to-IntermediateSystem(IS-IS),”providesanoverviewoftheIS-ISroutingprotocol,coveringIS-ISprotocolconceptsandbasicconfigurationonCiscorouters.Inlinewiththeoverallthemeofthisbook,thischaptercoverstroubleshootingofIS-ISroutingproblems.CiscoroutersandIOSSoftwareprovidetheframeworkfortheensuingdiscussions,whichfocusononlyIP-relatedissues.TwomaincategoriesofIS-ISroutingproblemsexist:•Misconfigurationandinteroperabilityproblems•Problemscausedbymalfunctioningofsoftwareorhardware

Intheabsenceofanyobviousmisconfigurationorinteroperabilityissues,anyoperationalissuesmostlikelywouldbetheresultofmalfunctioninghardwareorsoftwarebugs.Inmostsuchcases,thiscanbediscernedafterconfirmingtheconfigurationisokayortheproblemseemstobelimitedtoaparticularinterface.Problemscausedbyhardware-andsoftware-relatedbugsarebeyondthescopeofthischapterandarenotdiscussedfurther.AnysuchproblemsshouldbereferredtotheCiscoTechnicalAssistanceCenterforfurtherdiagnosis.Thediscussionsinthischapterlargelyfocusontroubleshootingproblemscausedbymisconfiguration,interoperability,orinadequatenetworkresourceissues.NetworkresourceissuesaretriggeredwhensomeoralloftheroutersinthenetworkarelowonCPUormemoryresourcesrequiredforstoringandcomputinglargeamountsofroutinginformation.Ingeneral,however,IS-ISseemsrelativelyeasiertotroubleshootwhencomparedtosimilarlycomplexroutingprotocols,suchasOSPF.AmajorcontributingfactortothisisthatIS-ISroutersadvertiseroutinginformationconsolidatedusuallyinsingleLSPs,whichareeasytotrackthroughoutthenetwork.LSPscanbefragmented,ifnecessary,butthisisrareintoday’slargeIS-ISdomainsthatconnecttotheInternet.Incontrast,OSPF,forexample,usesmultipleLSAtypesforcarryingdifferentkindsoflink-stateinformation.ThemultipleindividualLSAsadvertisedbyeachroutercreateacomplexenvironmenttrackingroutinginformationandtroubleshootingproblems.AnotherreasonisthatIS-IShasbeendeployedinsomeofthelargestservice-providernetworks,eventhoughinsingle-areatopologies,forreasonablylongenoughtoenabletheCiscoimplementationtobematureandstable.Additionally,inherentattributesoftheIS-ISprotocolallowfordeploymentinalarge,flatnetworkdesignwithremarkablestability.Incontrast,OSPFrequireshierarchicaldeploymentinlargenetworks,forconstrainingareasintomanageablesizes.Ingeneral,hierarchyisnecessaryforscalinganynetwork,yetitundoubtedlyintroducessophisticationintothedesign,which,inturn,complicatestroubleshooting.Insummary,itissignificantlyeasiertotroubleshootalarge,flatIS-ISnetworkbytrackingasingleLSPforeachrouterthanitistotrackmultipleOSPFLSAsforeachrouterinahierarchicaltopology.Thisforegoingobservationisnotintendedtopitchoneprotocolagainsttheother.Forthemostpart,IS-ISandOSPFareidenticalinfunctionalityanddemonstratesimilarcapabilitiesinawell-designednetwork.ProbablythemostchallengingthingaboutIS-ISforthenewlyinitiatedishavingtodealwithtwo

independentaddressingschemes—IPaddressingandISOCLNPaddressing.Inmostcases,thereislessfamiliaritywithCLNPaddresses,whicharealsoknownasNSAPs.TheratherlongNSAPaddresses(upto160bits)canbedauntingformanywhoarelessexposedtothem.Ontheotherhand,IPaddresseshaveamaximumsizeof32bits,withanother32bitsforthemask.CLNPaddressingiscoveredaspartoftheintroductiontoIS-ISinChapter10.Aspointedoutinthatchapter,eventhoughIS-ISisusedforIProuting,itoperateswithintheframeworkoftheISOconnectionlessnetworkprotocolrequiringtheneedforNSAPstobeconfiguredonroutersfornodeidentification.Asalreadyindicated,IntegratedIS-IScanbeusedforroutingCLNPandIPsimultaneously.Ingeneral,CLNPaddressingisnotascomplicatedasitmightseem.UnderstandingthestructureofNSAPsshouldhelpalleviateanypotentialdiscomfortworkingwiththem.Additionally,familiaritywiththeNSAPformatcanprovidesignificantadvantagesintroubleshootingsomeIS-ISproblems—inparticular,adjacency-formationproblems.BecauseofthecomplicityofCLNPintheIS-ISframework,youmustbefamiliarwithCLNP-specificshowcommandsaswellasIS-IS-specificcommands,inadditiontothegenericIPcommandsfortroubleshootingroutingproblems.CiscoIOSSoftwarealsofeaturesdebuggingcommandsforCLNPandIS-ISthatyoushouldbecomefamiliarwith.Asyoumightrecall,CLNPistheLayer3protocolwithintheISOconnectionlessnetworkservices(CLNS)framework.Forhistoricalreasons,thekeywordclnsisusedinplaceofthemoreappropriateclnpinCLNP-relatedcommands.Thismisnomer,however,hasbeenretainedintheCiscoIOScommandlineinterface(CLI)forbackwardcompatibility.ThefollowingkeyshowcommandscommonlyareusedfortroubleshootingIS-ISroutingproblems:•showclnsneighbors—Verifiesthestatusofadjacencies•showclnsinterface—VerifiesconfigurationofanactiveCLNSinterface•showisisdatabase—ListsLSPsinthelink-statedatabase•showisistopology—ListsthesystemIDsofknownIS-ISrouters•showisisspf-log—DisplaysloggedSPF-relatedevents

ThefollowingIS-ISdebuggingcommandsprovideusefuloutputandfrequentlyareusedinadditiontoshowcommandsfortroubleshootingcomplicatedproblems:•debugisisadj-packets•debugisisupdate-packets•debugisisspf-events

Unliketheshowanddebugcommands,whichareusedreactivelyfortroubleshootingproblems,thelog-adjacency-changescommand,whichisanIOSrouter-levelconfigurationcommand,proactivelyenablesloggingofIS-ISadjacencychanges.Anysuchloggedinformationcanbeanindicationofflakylinksandpotentialconnectivityproblems.Sometimes,asimpleresetofIS-IS–relateddatastructureswiththecommandclearisis*canhelpsavetheday.Inthiscase,theproblemobviouslymightbecausedbybuggycode.Infrequently,anetworkoperatorcouldgettemporaryrelieffromaproblembyrestartingtheIS-ISprocess—thatis,removingtheIS-ISrouterconfigurationandre-enteringit.Problemsresolvedthatwayaretheresultofbugsandwouldalwayscomebacktohauntyou.Youmightrunintomanyproblemsthatarecausedbymisconfigurationandmalfunctionofsoftwareandhardware.Thischaptercoversthefollowinggenericproblemcategoriesindetailandelaboratesonthestepsneededtotroubleshootthem:•IS-ISadjacencyproblems•Routeadvertisementproblems

•Routeinstallationproblems•Routeredistributionandsummarizationproblems•Routeflaps•IS-ISerrormessages•Interoperabilityissues

Therestofthechaptertacklestheseproblems.

TroubleshootingIS-ISAdjacencyProblemsIS-ISadjacency-relatedproblemsnormallyarecausedbylinkfailuresandconfigurationerrors.OnCiscorouters,linkfailureseasilycanbeidentifiedbyinspectionofashowinterfacecommandoutput.Also,becauseIS-ISroutingisnotrequiredtoestablishIPconnectivitytodirectlyattachedrouters,itiseasytodiscernwhethertheproblemismedia-relatedorspecifictotheIS-ISconfiguration.TheshowclnsneighborscommandisusuallythestartingpointfortroubleshootingIS-ISadjacencyproblems.Chapter10providesapreviewofthiscommandinthecoverageofbasicconfigurationandverificationofIS-ISoperation.Theoutputofthiscommandshouldlistallneighborsexpectedtobeadjacenttotherouterbeinginvestigated.Thecommandshowclnsis-neighborsprovidessimilaroutput,butitisintendedtolistonlyneighborroutersorIS-ISadjacencies;thepreviouscommandlistsalltypesofadjacencies,bothforIS-ISandforES-IS.Beforeproceedingwiththetroubleshootingscenarios,takealookatthiscommandagain.TheoutputinExample11-1wasobtainedfromRT1,whichisconnected,asshowninFigure11-1.AlsoshowninExample11-1isavariationofthiscommandwithanadditionalkeyword,detail.

Figure11-1NetworkDiagramforExample11-1

Example11-1showclnsneighborsCommandOutput

RT1#showclnsneighbors

SystemIdInterfaceSNPAStateHoldtimeTypeProtocolRT2Se0/0HDLCUp27L2IS-ISRT5Et0/000d0.58eb.ff01Up25L1IS-IS


SystemIdInterfaceSNPAStateHoldtimeTypeProtocolRT2Se0/0HDLCUp24L2IS-ISAreaAddress(es):49.0002IPAddress(es):192.168.1.2*Uptime:02:15:11RT5Et0/000d0.58eb.ff01Up23L1IS-IS

AreaAddress(es):49.0001IPAddress(es):10.1.1.5*Uptime:02:15:11

Theshowclnsneighborscommandprovidesasummaryofknownneighbors,theconnectinginterface,andthestateoftheadjacency.Theshowclnsneighborsdetailcommandprovidesmoreinformationabouteachneighbor,suchastheareathatitbelongstoandhowlongithasbeenknown(uptime).Explanationofthefieldsinthisoutputisasfollows:•SystemID—Systemidentifieroftheneighbor.•Interface—Physicalinterfacewheretheneighborisconnected.•SNPA—Subnetworkpointofattachment.Thisisthedatalinktypeoraddress(HDLCorPPPforserial,andMACaddressforLANs).•State—Stateoftheadjacency—up,down,orinit.•Holdtime—Thetimeintervaluntilexpirationoftheadjacency.Theholdtimeisresettotheproductofthehellointervalandhellomultiplierforcorrespondingneighborseverytimethatahelloisreceivedfromthem.Thedefaultvaluesofthehellointervalandthehellomultiplierare10secondsand3,respectively;hence,theholdtimeisresetto30secondsonreceiptofahellopacketunderdefaultconditionsofoperation.•Type—Typeofadjacency—Level1,Level2,orboth.•Protocol—Thetypeofadjacency—IS-IS,ISOIGRP,orES-IS.

ProblemswithIS-ISadjacencyformationcanberegisteredbythepresenceoffewerneighborsthanareexpectedorasituationinwhichthestatusofanexpectedadjacencyisnotup.AnothersymptomcouldbethattheneighborisknownthroughtheES-ISprotocolinsteadofIS-IS.YoumightrecallfromChapter10thattheES-ISprotocolisoneofthreeprotocolsthatsupportstheISOCLNSenvironment.AllISOdevicesruntheES-ISprotocoltofacilitatemutualdiscoveryandcommunicationbetweenendsystemsandroutersintheCLNSenvironment.Endsystemsandroutersexchangeend-systemhellos(ESHs)andintermediate-systemhellos(ISHs)withintheES-ISframework.Connectedroutersalsoreceiveeachother’sISHsandformES-ISadjacencies.Therefore,itispossiblethatES-ISadjacenciesmightstillbeformedbetweentworoutersevenifthereareproblemswiththeIS-ISadjacency.IntheoutputofshowclnsdisplayedinExample11-1,RT1hasproperlyformedadjacencieswithitsdirectlyconnectedneighbors,RT2(overSerial0/0)andRT5(overEthernet0/0).Byusingathree-wayhandshaketocompletetheadjacencyprocess,RT1canbecertainthatbothRT2andRT5alsohavenormallyestablishedcorrespondingadjacenciesinthereversedirection.Example11-2showssimilaroutputfromRT1featuringproblemswiththeadjacenciesformedwithRT2andRT5.Example11-2showclnsneighborsCommandOutput


SystemIdInterfaceSNPAStateHoldtimeTypeProtocolRT2Se0/0HDLCInit27L2IS-ISRT5Et0/000d0.58eb.ff01Up25L1ES-IS

Inthisexample,theIS-ISadjacencywithRT2isinINITstateinsteadofUP.TheprotocoliscorrectlyshownasIS-IS.However,theadjacencywithRT5isinUPstate;however,theprotocolisES-ISinsteadofIS-IS.Asexplainedpreviously,theES-ISprotocolrunsindependentlyofIS-IS;therefore,theES-IS

adjacencyformedbetweenRT1andRT5hasnothingtodowithIS-IS.TheserouterscannotformanIS-ISadjacencywitheachother,apparentlybecauseofaproblemintheconfigurationortheIS-ISenvironment.WhenyoudeterminethatanIS-ISadjacencyproblemisnottheresultoflinkproblems,youcanusetheshowclnsinterfacecommandtodisplayanomalies,suchascontentionovertheroleofdesignatedintermediatesystem(DIS).MostadjacencyproblemsrelatedtotheIS-ISenvironmentcanbedebuggedwiththedebugisisadj-packetscommand.Theoutputofthiscommandcanbedauntingiftherouterunderinspectionhasmanyneighborsbecausethedisplayshowsallthehellostransmittedandreceivedbythelocalrouters.Consecutivehellossentandreceivedbetweentwostationsarespacedatapproximately10seconds,inthedefaultsetting,soinformationfillsthescreenquickly.Theobjectiveofthesectionsthatfollowistoassistyouinunderstandingthenatureofadjacencyproblems,uncoverthecauses,andcorrectthem.Networksarecriticalintoday’sbusinessenvironment,andtheabilitytotroubleshootproblemsquicklyisavirtuethathelpssavebusinessesfromthehighcostsassociatedwithnetworkoutagesandearnsthenetworkoperatoryearsofemployabilityandaccompanyingbenefits.Thefollowingsectionsdiscussadjacencyproblemsandsuggestpossiblecauses.Table11-1summarizestheadjacencyproblemsandpossiblecausescoveredinthissection.Thisabbreviatedrepresentationisdesignedtofacilitatereferencetothematerial.Eachproblemlistedissubsequentlyelaborated,andpointersareprovidedonhowtoidentifythesymptomsandthenecessaryactionsrequiredtocorrectaspecificproblem.

Table11-1IS-ISAdjacencyProblems/Causes

Problem1:SomeorAlloftheAdjacenciesAreNotComingUpTheabsenceofsomeexpectedIS-ISadjacenciesmeansthattheaffectedrouterswillnotbecapableof

exchangingroutinginformation,effectivelycreatingreachabilityproblemstocertaindestinationsinthenetwork.Figure11-2showsasimplenetworkinwhichfourdaisy-chainedroutersaregroupedintwosandplacedinseparateareas.

Figure11-2SimpleNetworkDiagramforIllustratingAdjacencyProblems

TheoutputoftheshowclnsneighborscommandcapturedonRT1andshowninExample11-3displaysonlyoneneighborinsteadoftheexpectedtwo.RT2islisted,butRT5ismissing.BecauseRT5alsoisexpectedtobeadjacent,thissignalsanadjacencyproblemthatneedstobefurtherinvestigated.Example11-3showclnsneighborsCommandOutputRevealsaMissingNeighbor


SystemIdInterfaceSNPAStateHoldtimeTypeProtocolRT2Se0/0HDLCUP27L2IS-IS

TheflowchartinFigure11-3illustratesthelogicalstepsfortroubleshootingtheproblem.Thesestepsalsoareelaboratedinthetextthatfollows.

Figure11-3FlowchartforResolvingMissingIS-ISAdjacencies

Step1:CheckingforLinkFailures

Thefirststeptowardaddressingthisproblemistomakesurethatalltheinterfacesonwhichadjacenciesshouldbeformedareintheup/upstate.OnCiscorouters,thiscanbedonequicklywiththeshowipinterfacesbriefcommand,whichdisplaysasummaryofalltheinterfaces,asshowninExample11-4.TheexampleisbasedonFigure11-2.Example11-4showipinterfacesbriefCommandOutputDisplaysPhysicalStateofInterfaces

RT1#showipinterfacebriefInterfaceIP-AddressOK?MethodStatusProtocolEthernet0/010.1.1.1YESNVRAMadministrativelydowndownSerial0/0192.168.1.1YESNVRAMupupFastEthernet1/0unassignedYESunsetadministrativelydowndownLoopback011.1.1.1YESNVRAMupup

TheStatuscolumnoftheshowipinterfacesbriefcommandtellswhetheraninterfaceisup,down,oradministrativelydownatthephysicallevel.TheProtocolcolumnalsoneedstobeupinordertoconfirmnormaloperationatthedatalink.Verifythattheinterfaceisworkingbypingingacrosstotheotherend,asdemonstratedonExample11-5.FromFigure11-2,youknowthatRT2isontheotherendofserial0/0andhasanIPaddressof192.168.1.2onthecorrespondinginterface.Therefore,apingtothisinterfacewillverifywhetherpacketscangooverthelink.Asuccessfulpingtestisconfirmedbyexclamations,asshowninExample11-5.Whenthepingtestfails,dotsinsteadofexclamationsaredisplayed.Ifthepingfails,thephysicalconnectivityproblemfirstmustberesolvedbeforeIS-ISoperationischeckedanyfurther.Example11-5Usingpingtoverifyconnectivity

RT1#ping192.168.1.2

Typeescapesequencetoabort.Sending5,100-byteICMPEchosto192.168.1.2,timeoutis2seconds:!!!!!Successrateis100percent(5/5),round-tripmin/avg/max=1/2/4ms

Step2:VerifyingBasicConfiguration

Ifthelinkisfine,thenextstepinvolvesverifyingtheIS-ISconfiguration.Ingeneral,IS-ISisenabledintwosteps.First,theIS-ISprocessisconfigured,asshowninExample11-6.MakesurethattheIS-ISprocessisdefinedandthatanNSAPorNETisconfigured.Example11-6IS-ISProcessConfiguration

routerisisnet49.0001.0000.0000.0001.00

UnlikeotherIProutingprotocols,suchasRIPandOSPF,theIS-ISconfigurationdoesn’tusenetworkstatementstoenableIS-ISroutingontherouter’sinterfaces.Forexample,inOSPF,iftheIPsubnetconfiguredonaninterfacefallsintherangeofanetworkstatement,OSPFwillsendHellosoverthatinterfacetoformadjacenciesandthereforeexchangeIProutinginformationoverthatinterface.ToenableIS-ISroutingforIPonaCiscorouter,youmustconfiguretheiprouterisiscommandontheappropriateinterfaces.TheIPsubnetsoninterfacesenabledforIS-ISroutinginthismannerautomaticallyareputintothelocallygeneratedLSP.TheonlynetworkstatementrequiredinIS-ISistheISONSAP,whichalsocommonlyisreferredtoasthenetworkentitytitle(NET).However,itshouldbenotedthat

misconfiguredNETsareacommoncauseofIS-ISadjacencyproblems.ThisisfurtherdescribedlaterinStep4,“CheckingforAreaMisconfiguration.”Forinterfacesonwhichtheiprouterisiscommandismissing,makesurethattherouter-levelpassive-interfacecommandisnotbeingusedtodisableIS-ISroutingonthem.Whenaninterfaceismadepassive,theiprouterisiscommandautomaticallyisremovedfromtheinterface.AninterfaceismadepassiveifitisdesirabletoadvertiseitsassociatedIPsubnetwithoutforminganyadjacenciesoverit.Loopbackinterfacesnormallyareconfiguredthisway.Step3:CheckingforMismatchedLevel1andLevel2Interfaces

IS-ISsupportsatwo-levelroutinghierarchyinwhichroutingwithinanareaisdesignatedasLevel1androutingbetweenareasisdesignatedasLevel2.AnIS-ISroutercanbeconfiguredtoparticipateinLevel1routingonly(Level1router),Level2routingonly(Level2router),orboth(Level1–2router).Level1–2routersactasborderroutersbetweenIS-ISareasandfacilitateinterareacommunication.Inthedefaultmodeofoperation,CiscoroutershaveLevel1–2capability.TwodirectlyconnectedrouterswithacommonareaIDwillformaLevel1–2adjacencybydefault,eventhoughonlyaLevel1adjacencyisnecessaryforthemtocommunicate.Youcanusetherouter-levelis-typecommandtochangethisbehavior.UsingFigure11-2asanexample,itmightbedesirabletomakeRT5aLevel1–onlyrouterwhileRT1remainscapableofLevel1–2.ThisrequiresRT5tobeconfiguredwiththeis-typelevel-1command,butnothingneedstobedoneonRT1.IfRT1ismadeaLevel2–onlyrouterwiththecommandis-typelevel-2-only,itwillnotbecapableofformingaLevel1adjacencywithRT5.AsshowninFigure11-2,thepropersetupistomakeRT5aLevel1routeronlyifithaslimitedresources(memoryandCPUcapacity);RT1shouldbeaLevel1–2routerforittocommunicatewithRT5atLevel1andwithRT2atLevel2becauseRT2isinanotherarea.JustaswithRT5,RT6canbeaLevel1–onlyrouter,ifnecessary.Step4:CheckingforAreaMisconfiguration

IntheCLNPaddressingoverviewprovidedinChapter10,thethreemaincomponentsofanNSAPaddressarediscussed.With1byteatthefarthestrightendoftheNSAPreservedfortheNSELandthefollowing6bytesforthesystemID,therestoftheaddressdefinestheareaID(seeFigure10-8inChapter10).JustasinthecaseofStep3,tworoutersindifferentareaswithdifferentareaIDsconsequentlyareassignedtodifferentareasand,therefore,formonlyaLevel2adjacency.UsingFigure11-2asanexample,ifRT5isconfiguredasLevel1onlybutitsareaIDismisconfiguredtobedifferentfromtheareaIDofRT1,thesetworouterswillnotformanyadjacency.TheconfigurationinExample11-7,eventhoughRT1isexpectedtobeinarea49.0001,hasbeenconfiguredwithanareaIDof49.0005placingitinadifferentareafromRT5.Therefore,RT5mustbeLevel2–capabletoformadjacencieswithRT1.However,ithasbeenmadeaLevel1–onlyrouterwiththecommandis-typelevel-1.Therefore,noIS-ISadjacencywillbeformedbetweenRT1andRT5.Example11-7RT1andRT5ConfigurationsShowAreaIDsandAdjacencyCapabilities

hostnameRT1!interfaceEthernet0/0ipaddress10.1.1.1255.255.255.0iprouterisis!routerisisnet49.0001.0000.0000.0001.00

hostnameRT5!interfaceEthernet0/0ipaddress10.1.1.5255.255.255.0iprouterisis!routerisisnet49.0005.0000.0000.0005.00is-typelevel-1

Step5:CheckingforMisconfiguredIPSubnets

InrecentreleasesofCiscoIOSSoftware,particularlyin12.0S,12.0ST,and12.0Treleasetrains,adjacencieswillnotbeformedbetweentwoneighborsiftheirdirectlyconnectedinterfacesarenotinthesameIPsubnet.InExample11-8,theaddressofRT1ischangedtothatofanothersubnet.AgainusingFigure11-2forillustration,Example11-9showsRT1rejectingthehelloreceivedfromRT5becausetheinterfaceaddress10.1.1.5advertisedbythelatterisnotonsubnet10.1.8.0/24.Example11-8VerifyingtheEffectofanIPSubnetMismatchonIS-ISAdjacencies

RT1#showinterfaceEthernet0/0Ethernet0/0isup,lineprotocolisupHardwareisAmdP2,addressis00d0.58f7.8941(bia00d0.58f7.8941)Internetaddressis10.1.1.1/24

RT1#conftEnterconfigurationcommands,oneperline.EndwithCNTL/Z.RT1(config)#inte0/0RT1(config-if)#ipaddress10.1.8.1255.255.255.0RT1(config-if)#^Z

Example11-9DebuggingAdjacencyProblemsCausedbyanIPSubnetMismatch

RT1#debugisisadj-packetIS-ISAdjacencyrelatedpacketsdebuggingison

Apr2121:55:39:ISIS-Adj:RecL1IIHfrom00d0.58eb.ff01(Ethernet0/0),cirty7Apr2121:55:39:ISIS-Adj:NousableIPinterfaceaddressesinLANIIHfromEth0Apr2121:55:40:ISIS-Adj:SendingL1IIHonEthernet0/0,length1497

Apr2121:55:41:ISIS-Adj:SendingserialIIHonSerial0/0,length1499Apr2121:55:42:ISIS-Adj:RecL1IIHfrom00d0.58eb.ff01(Ethernet0/0),cirty7Apr2121:55:42:ISIS-Adj:NousableIPinterfaceaddressesinLANIIHfromEth0Apr2121:55:43:%CLNS-5-ADJCHANGE:ISIS:AdjacencytoRT5(Ethernet0/0)Down,Apr2121:55:43:ISIS-Adj:L1adjcount0

InearlierCiscoIOSSoftwarereleases,itdidnotmatterwhethertheroutersbelongedtodifferentIPsubnetsbecauseIS-ISadjacencyformationoccursprimarilywithintheCLNPframework,whereIPaddressesareirrelevant.However,inIPapplications,directlyconnectedroutersmustbeonthesamesubnet,exceptwhenIPunnumberedisused.Therefore,therecentbehaviorprovidesanextracheckfortheIPconfigurationwhileintroducingsanityintoIS-ISdatastructuresfortrackingIPinformation.Insummary,itisimportanttomakesurethatdirectlyconnectedroutersthatneedtoformIS-ISadjacenciesforIProutingareonthesameIPsubnet.Step6:CheckforDuplicateSystemIDs

Ifthepreviousstepscheckedoutokaybutaspecificneighborisnotintheshowclnsneighboroutput,itis

possiblethatadjacencyisnotbeingformedbecausethatneighborhasaduplicatesystemIDwiththelocalrouter.AnIS-ISrouterwillnotformanadjacencywitharouterinthesameareathathasaduplicatesystemID.ItalsologsaduplicatesystemIDerror,asshowninExample11-10.Usetheshowloggingcommandtodisplayentriesinthelog.IfduplicatesystemIDerrorsarefound,thesourceoftheconflictcanbedeterminedfromtheoutputofdebugadj-packets,whichpointstotheinterfacewherethehelloswiththeduplicatesystemIDarecomingfrom.SeeExample11-11.Example11-10DuplicateSystemIDErrorLogs

RT1#showloggingApr2116:30:59:%CLNS-3-BADPACKET:ISIS:LANL1hello,DuplicatesystemIDdet)Apr2116:31:59:%CLNS-3-BADPACKET:ISIS:LANL1hello,DuplicatesystemIDdet)Apr2116:33:00:%CLNS-3-BADPACKET:ISIS:LANL1hello,DuplicatesystemIDdet)

Example11-11DetectingDuplicateSystemIDswithdebugisisadj-packet

RT1#debugisisadj-packetIS-ISAdjacencyrelatedpacketsdebuggingisonRT1#

Apr2121:43:08:ISIS-Adj:SendingL2IIHonEthernet0/0,length1497Apr2121:43:09:ISIS-Adj:SendingL1IIHonEthernet0/0,length1497Apr2121:43:09:ISIS-Adj:RecL1IIHfrom00d0.58eb.ff01(Ethernet0/0),cirty7Apr2121:43:09:ISIS-Adj:DuplicatesystemidApr2121:43:12:ISIS-Adj:SendingL1IIHonEthernet0/0,length1497Apr2121:43:12:ISIS-Adj:SendingL2IIHonEthernet0/0,length1497Apr2121:43:12:ISIS-Adj:RecL1IIHfrom00d0.58eb.ff01(Ethernet0/0),cirty7Apr2121:43:12:ISIS-Adj:Duplicatesystemid

Problem2:AdjacencyinINITStateThemostcommoncausesforanadjacencygettingstuckinINITstatearemismatchedinterfaceMTUandmisconfiguredauthenticationparameters.TheoutputinExample11-12showswhatanadjacencywouldlooklikewhenstuckinINIT.Example11-12IS-ISAdjacencyStuckinanINITState


SystemIdInterfaceSNPAStateHoldtimeTypeProtocolRT1Se0/0HDLCInit29L2IS-IS

ToguaranteethatadjacentIS-ISrouterscanreceiveandprocessLSPsofmanageablesizesfromeachother,ISO10589specifiesthathellos,whichareusedtoformandmaintainadjacencies,shouldbepaddeduptomaxsize–1,wheremaxsizeisthemaximumLSPbuffersizeortheMTUoftheoutgoinginterfaceofthesourcenode.TheobjectiveofthisrequirementistoensurethatanadjacencywillbeformedonlybetweenrouterscapableofhandlingallIS-ISpacketssenttoeachother.ThemaximumLSPbuffersizeisspecifiedas1492bytes;however,CiscoIOSSoftwaredefaultstotheMTU,meaningthathellosarepaddedtoMTU–1bytes.ThereforeforCiscorouters,everythingbeingequal,adjacenciesareformedonlywhenMTUsofdirectlyconnectedinterfacesmatch.Figure11-4illustratesasituationfornormaladjacencyformation.

Figure11-4InvestigatingIS-ISAdjacencies—ASimpleNetwork

InExample11-13,theoutputofshowclnsneighborsfromRT1showsthattheadjacencystateisupandthattheprotocoltypeisIS-IS.Example11-13alsoshowsexcerptsoftheshowclnsinterfacecommandfromthetworoutersinvolved,RT1andRT2.TheMTUis1500bytesoneitherside.Example11-13CorrectlyFormedIS-ISAdjacency


SystemIdInterfaceSNPAStateHoldtimeTypeProtocolRT2Se0/0HDLCUp250ISIS-IS

RT1#showclnsinterfaces0/0Serial0/0isup,lineprotocolisupChecksumsenabled,MTU1500,EncapsulationHDLC

RT2#showclnsints0/0Serial0/0isup,lineprotocolisupChecksumsenabled,MTU1500,EncapsulationHDLC

Often,anadjacencywillbestuckinINITbecauseonlyonesideisenabledforauthentication.Forexample,whenbasicIS-ISauthenticationisenabled,asimpleclear-textpasswordiscarriedinaTypeLengthValue(TLV)field(Type10)inthehellopackets.IfthehelloreceivedbyapeerdoesnotcontaintheauthenticationTLVorthepasswordintheTLVisnotasexpected,thepeerignoresthehello.Ontheotherhand,ifarouterisnotenabledforauthentication,itdoesn’tcareabouttheexistenceoftheauthenticationTLVinaneighbor’shello.Thislattersituationleadstoarouterprocessinganeighbor’shellos,registeringthatneighbor,advancingthestatusoftheadjacencytoINIT,andnotgoingfurther.Thisisbecausetheotherrouterignoresanyreceivedhellosfromthefirstand,therefore,neverliststhefirstrouterasadetectedISneighbor.Therefore,thetworoutersareunabletocompletethethree-wayadjacencyprocesstoformacompleteadjacency.Thisisfurtherelaboratedlaterinthischapter,inthe“MisconfiguredAuthentication”section.AnotherreasonwhyanadjacencymightbestuckinINITisthatthelocalrouters’hellomightnotbegettingcorruptedbeforereachingtheotherend.Figure11-5isaflowchartrepresentingtroubleshootingstepsforproblemsinwhichanIS-ISadjacencyisstuckinINIT.

Figure11-5FlowcharttoResolveIS-ISAdjacenciesStuckinINIT

Step1IfIS-ISauthenticationisconfigured,thefirststepintacklingthisproblemistoaddressanypotentialissuesinthisarea.Ifnoauthenticationisinuse,thepotentialcauseoftheproblemcouldbemismatchedMTUs.

Step2Inthisstep,theconfigurationforauthenticationisverified.TheCiscoimplementationallowsauthenticationtobeconfiguredinthreeways:atthedomain,area,orinterfacelevels.Makesurethattheappropriatemethodisproperlyconfiguredandthatthepasswordsusedareconsistent.Authenticationisfurtherelaboratedinasubsequentsection,“MisconfiguredAuthentication.”

Step3Inthisstep,itisassumedthattherearenoauthenticationissues.Hence,thenextpossibilityismismatchedMTUs.TheshowclnsinterfacecommandcanquicklyverifytheMTUsoneithersideofthelink.The“MismatchedMTU”sectionprovidesfurtherdetailsondebuggingandverificationproceduresfortroubleshootingMTUmismatchedproblems.

Step4Recent12.0Sand12.0STCiscoIOSSoftwarereleasesallowhellopaddingtobedisabledtoreducesignificantandunnecessarybandwidthconsumptioninsomenetworkenvironments.HellopaddingisdisabledwiththeassumptionthattheMTUsmatch.Thisstepsuggestsmakingsurethathellopaddingisconfiguredconsistentlyoneitherside.IftheMTUsmatchoneitherside,disabling

hellopaddingononlyonesidewillnothaveanyoperationalcon-sequences.Issuesrelatingtothedisablingofhellopaddingareexploredfurtherinthelatersection“IS-ISHelloPadding.”

Step5IfnoissuesarefoundwithauthenticationandMTUsalsomatch,debuggingoftheIS-ISadjacency-formationprocessshouldbeenabledwiththecommanddebugisisadj-packets.Theoutputshouldbescrutinizedforcluesthatcouldprovidemoreinsightintotheinitstateoftheadjacency.Debuggingshouldbeenabledatbothendswithtimestampstohelpcorrelateeventsatbothsides.

Step6Inthisdecisionstep,youdeterminewhetheryouhaveenoughinformationtodiagnosetheproblemandimplementasolution,orwhetheryouneedtoaskforexpertassistance.

Step7Ifnothingcanbediscernedabouttheproblematthistime,itmostlikelyiscausedbyasoftwaremalfunctionandshouldbeturnedoverfortechnicalassistance.

Step8Thisstepisthesolutionstage.Thetroubleshootingprocessendsatthisstepiftheproblemisfiguredout.Ifitisdeterminedthattheproblemiswithauthentication,thenecessaryconfigurationchangescanbemadetoenabletheadjacencytocomplete.Ontheotherhand,ifthereisanMTUmismatch,theMTUmustbechangedononesidetomatchtheother.DisablingthehellopaddingdoesnotremoveMTUverificationateitherend;itjustallowssmallerhellostobeadvertisedtosavebandwidth.

Asmentionedpreviously,apossiblecauseoftheadjacencygettingstuckinINITiswhenoneside’shellosarereachingtheothersidebutcorruptedintransition.Thissituationiscomparabletothemisconfiguredadjacencyscenario.Todetermineifpacketcorruptionmightbethecause,youneedtocheckforpacketcorruptionerrorsinthelogsoftheremoterouter.MismatchedMTU

Examples11-14and11-15demonstratetheeffectofthedefaultbehaviorofmismatchedMTUs.ThedemonstrationisbasedonFigure11-4.Example11-14DebuggingMTUMismatchonRT2

RT2(config)#interfaces0/0RT2(config-if)#mtu2000

RT2#debugisisadj-packetsIS-ISAdjacencyrelatedpacketsdebuggingisonRT2#

Apr2019:56:23:ISIS-Adj:SendingserialIIHonSerial0/0,length1999Apr2019:56:23:ISIS-Adj:RecserialIIHfromHDLC(Serial0/0),cirtypeL1L2Apr2019:56:23:ISIS-Adj:rcvdstateUP,oldstateUP,newstateUPApr2019:56:23:ISIS-Adj:Action=ACCEPTApr2019:56:31:ISIS-Adj:SendingserialIIHonSerial0/0,length1999Apr2019:56:33:ISIS-Adj:RecserialIIHfromHDLC(Serial0/0),cirtypeL1L2Apr2019:56:33:ISIS-Adj:rcvdstateUP,oldstateUP,newstateUPApr2019:56:33:ISIS-Adj:Action=ACCEPTApr2019:56:39:ISIS-Adj:RecserialIIHfromHDLC(Serial0/0),cirtypeL1L2Apr2019:56:39:ISIS-Adj:rcvdstateDOWN,oldstateUP,newstateINITApr2019:56:39:ISIS-Adj:Action=GOINGDOWNApr2019:56:39:%CLNS-5-ADJCHANGE:ISIS:AdjacencytoRT1(Serial0/0)Down,nesApr2019:56:39:ISIS-Adj:L2adjcount0Apr2019:56:39:ISIS-Adj:SendingserialIIHonSerial0/0,length1999Apr2019:56:40:ISIS-Adj:SendingserialIIHonSerial0/0,length1999Apr2019:56:42:ISIS-Adj:RecserialIIHfromHDLC(Serial0/0),cirtypeL1L2Apr2019:56:42:ISIS-Adj:rcvdstateDOWN,oldstateDOWN,newstateINITApr2019:56:42:ISIS-Adj:Action=GOINGUP,newtype=L2

Apr2019:56:42:ISIS-Adj:NewserialadjacencyApr2019:56:42:ISIS-Adj:SendingserialIIHonSerial0/0,length1999Apr2019:56:50:ISIS-Adj:RecserialIIHfromHDLC(Serial0/0),cirtypeL1L2Apr2019:56:50:ISIS-Adj:rcvdstateDOWN,oldstateINIT,newstateINITApr2019:56:50:ISIS-Adj:Action=GOINGUP,newtype=L2Apr2019:56:51:ISIS-Adj:SendingserialIIHonSerial0/0,length1999

AsshowninExample11-14,theMTUonRT2ischangedto2000bytes,andthedebugisisadj-packetcommandisenabledtoobservewhatgoesoninthebackground.NoticethatbecausetheMTUontheserialinterfaceisnow2000bytes,thehellopacketsarepaddedto1999bytes.ThedebugoutputshowsRT2sendingoutserialIIHsof1999bytes.ThisoutputalsoshowsthatRT2continuestoreceiveandprocessIIHsfromRT1.However,atthistime,RT1cannotacceptandprocessthe1999-byteIIHsfromRT2and,therefore,deletestheadjacency,removingRT2fromthelistofknownISneighborsadvertisedinitshello.Consequently,RT2changesthestateoftheadjacencytoINITandlogsanadjacencychangeerror.Fromthistimeon,theadjacencygetsstuckinINIT.RT2receives1499-bytehellosfromRT1,whicharenotlargerthanthe1999bytesexpected.However,theIS-ISadjacencyisstuckinINITstatebecauseRT1cannotcompletethethree-wayadjacencyprocess.Example11-15featuresshowclnsneighborscommandoutputfromRT2,confirmingthedebuggingoutput.Example11-15InitStateConfirmedonRT2


SystemIdInterfaceSNPAStateHoldtimeTypeProtocolRT1Se0/0HDLCInit29L2IS-IS

Example11-16featuresthecorrespondingdebuggingoutputonRT1.Example11-16DebuggingMTUMismatchonRT1

RT1#debugisisadj-packetsIS-ISAdjacencyrelatedpacketsdebuggingison

Apr2019:55:52:ISIS-Adj:RecserialIIHfromHDLC(Serial0/0),cirtypeL1L2Apr2019:55:52:ISIS-Adj:rcvdstateUP,oldstateUP,newstateUPApr2019:55:52:ISIS-Adj:Action=ACCEPTApr2019:55:52:ISIS-Adj:SendingserialIIHonSerial0/0,length1499Apr2019:56:00:ISIS-Adj:RecserialIIHfromHDLC(Serial0/0),cirtypeL1L2Apr2019:56:00:ISIS-Adj:rcvdstateUP,oldstateUP,newstateUPApr2019:56:00:ISIS-Adj:Action=ACCEPTApr2019:56:01:ISIS-Adj:SendingserialIIHonSerial0/0,length1499Apr2019:56:10:ISIS-Adj:SendingserialIIHonSerial0/0,length1499Apr2019:56:18:ISIS-Adj:SendingserialIIHonSerial0/0,length1499Apr2019:56:28:ISIS-Adj:SendingserialIIHonSerial0/0,length1499Apr2019:56:30:%CLNS-5-ADJCHANGE:ISIS:AdjacencytoRT2(Serial0/0)Down,hodApr2019:56:30:ISIS-Adj:L2adjcount0Apr2019:56:34:ISIS-Adj:SendingserialIIHonSerial0/0,length1499Apr2019:56:37:ISIS-Adj:SendingserialIIHonSerial0/0,length1499Apr2019:56:45:ISIS-Adj:SendingserialIIHonSerial0/0,length1499

Theloggingtimestampsarealmostsynchronizedtomatchrelatedeventsastheyoccurontheseparaterouters.RT1doesnotreportreceiptofanycorrespondinghellosfromRT2forthethreehighlightedconsecutivehellosthatitadvertises;consequently,itdropstheadjacencytoRT2andalsologsan

adjacencychangeerror.RT1silentlydiscardsthehellosfromRT2anddoesn’tloganycorrespondingerrorsuntilitdropstheadjacency.EventhoughRT1doesnotprocessanyoftheIIHsfromRT2becausetheyarelargerthanexpected,resultingindeletionoftheIS-ISadjacency,itretainsanES-ISadjacencytoRT2.TheES-ISadjacencyissustainedindependentlybyISHsundertheES-ISprotocol.Example11-17showsthecorrespondingoutputofshowclnsneighborsonRT1aftertheIS-ISadjacencyisdropped.Example11-17ES-ISAdjacencyRetainedonRT1WithoutIS-ISAdjacency


SystemIdInterfaceSNPAStateHoldtimeTypeProtocolRT2Se0/0HDLCUp250ISES-IS

Example11-18demonstratesreinstatementoftheadjacencyaftertheMTUiscorrectedonRT2.Ashighlightedinthedebuggingoutput,RT2beginstosend1499-byteIIHstoRT1.TheseobviouslyareacceptedandprocessedbyRT1,whichthensendsIIHswithRT2listedasanISnieghbortocompletethethree-wayhandshake,thusrestoringtheadjacency.Example11-18CorrectingtheMTUMismatchRestoresIS-ISAdjacencyBetweenRT1andRT2

RT2(config-if)#mtu1500RT2(config-if)#^ZRT2#RT2#debugisisadj-packetsApr2020:09:15:ISIS-Adj:SendingserialIIHonSerial0/0,length1499Apr2020:09:15:ISIS-Adj:RecserialIIHfromHDLC(Serial0/0),cirtypeL1L2Apr2020:09:15:ISIS-Adj:rcvdstateDOWN,oldstateINIT,newstateINITApr2020:09:15:ISIS-Adj:Action=GOINGUP,newtype=L2Apr2020:09:18:ISIS-Adj:SendingserialIIHonSerial0/0,length1499Apr2020:09:18:ISIS-Adj:RecserialIIHfromHDLC(Serial0/0),cirtypeL1L2Apr2020:09:18:ISIS-Adj:rcvdstateINIT,oldstateINIT,newstateUPApr2020:09:18:ISIS-Adj:Action=GOINGUP,newtype=L2Apr2020:09:18:%CLNS-5-ADJCHANGE:ISIS:AdjacencytoRT1(Serial0/0)Up,newyApr2020:09:18:ISIS-Adj:L2adjcount1Apr2020:09:19:ISIS-Adj:SendingserialIIHonSerial0/0,length1499Apr2020:09:19:ISIS-Adj:RecserialIIHfromHDLC(Serial0/0),cirtypeL1L2Apr2020:09:19:ISIS-Adj:rcvdstateUP,oldstateUP,newstateUPApr2020:09:19:ISIS-Adj:Action=ACCEPTApr2020:09:27:ISIS-Adj:SendingserialIIHonSerial0/0,length1499

IS-ISHelloPadding

RecentreleasesofCiscoIOSSoftwarefromthe12.0Sand12.0STtrainsallowpaddingofhellostobedisabled.OlderreleasesfollowISO10589,whichrequireshellostobepaddedautomatically,asdescribedearlier.ThemotivationbehinddisablinghellopaddingisbasedonthenotionthatthisprocessiseffectivelynotanMTUdiscoverymechanismanddesignedtocheckonlyMTUconsistencybetweenadjacentneighbors.BecausemostmediahavedefaultMTUs,thischeckis,therefore,redundantandcostly.Networkoperatorsarealsowellawareoftheirnetworkingenvironments,sopaddinghellostotheMTUsizeofoutgoinginterfacesresultsinunnecessarywasteofnetworkbandwidth.Acoupleofcommandsexistfordisablingandre-enablingIS-IShellopadding.HellosarepaddedbydefaultonCiscorouters.Thefollowingisarouter-levelcommandandappliesgloballytoallIS-IS–enabledinterfaces.Themultipointandpoint-to-pointkeywordsrestricttheeffectofthecommandtoonlymultipointorpoint-to-

pointinterfaces,respectively:[no]hellopadding[multipoint|point-to-point]

Thefollowingisaninterface-levelcommandthatcanbeappliedtodisablepaddingonaspecificinterface:

[no]isishellopadding

Thestatusofhellopaddingonaninterfacecanbeverifiedwiththeshowclnsinterfacecommand,asshowninExample11-19.Examples11-20and11-21displaydebugisisadj-packetoutputsforRT1andRT2,respectively(seeFigure11-4).Example11-20showsRT1sendinghellosofonly38bytesbecausepaddinghasbeendisabled.Ontheotherhand,RT2issending1499bytes,1byteshortoftheMTUonSerial0/0,becausehellopaddingisstillenabled.BecausetheMTUonRT2hasnotchanged,itsexpectedmaximumhellosizefromRT1remains1499.TheadjacencywillfailifRT1isconfiguredwithanMTUof2000,forexample,andstartssendinghellosof1999.Ingeneral,suppressinghellopaddingonlyshouldnotaffecttheadjacency,aslongasthehellossentoutonthetransmittingsidearesmallerthantheMTUonthereceivingside.Also,disablinghellopaddingdoesnotdisableverificationofthemaximumacceptablesizeofreceivedhellopackets.Example11-19VerifyingStatusofHelloPaddingonanInterface

RT1#showclnsinterfaceSerial0/0Serial0/0isup,lineprotocolisupChecksumsenabled,MTU1500,EncapsulationHDLCERPDUsenabled,min.interval10msec.RDPDUsenabled,min.interval100msec.,AddrMaskenabledCongestionExperiencedbitsetat4packetsCLNSfastswitchingenabledCLNSSSEswitchingdisabledDECcompatibilitymodeOFFforthisinterfaceNextESH/ISHin40secondsRoutingProtocol:IS-ISCircuitType:level-1-2Interfacenumber0x1,localcircuitID0x100Level-1Metric:10,Priority:64,CircuitID:RT2.00Numberofactivelevel-1adjacencies:0Level-2Metric:10,Priority:64,CircuitID:0000.0000.0000.00Numberofactivelevel-2adjacencies:1NextIS-ISHelloin3secondsNohellopadding

Example11-20DebuggingIS-ISHelloPacketsonRT1

RT1#debugisisadj-packets

Apr2914:34:22:ISIS-Adj:RecserialIIHfromHDLC(Serial0/0),cirtypeL1L2Apr2914:34:22:ISIS-Adj:rcvdstateUP,oldstateUP,newstateUPApr2914:34:22:ISIS-Adj:Action=ACCEPTApr2914:34:25:ISIS-Adj:SendingserialIIHonSerial0/0,length38Apr2914:34:32:ISIS-Adj:RecserialIIHfromHDLC(Serial0/0),cirtypeL1L2Apr2914:34:32:ISIS-Adj:rcvdstateUP,oldstateUP,newstateUPApr2914:34:32:ISIS-Adj:Action=ACCEPTApr2914:34:38:ISIS-Adj:SendingserialIIHonSerial0/0,length38

Example11-21DebuggingIS-ISHelloPacketsonRT2


Apr2914:34:15:ISIS-Adj:SendingserialIIHonSerial0/0,length1499Apr2914:34:17:ISIS-Adj:RecserialIIHfromHDLC(Serial0/0),cirtypeL1L2Apr2914:34:17:ISIS-Adj:rcvdstateUP,oldstateUP,newstateUPApr2914:34:17:ISIS-Adj:Action=ACCEPTApr2914:34:23:ISIS-Adj:SendingserialIIHonSerial0/0,length1499Apr2914:34:26:ISIS-Adj:RecserialIIHfromHDLC(Serial0/0),cirtypeL1L2Apr2914:34:26:ISIS-Adj:rcvdstateUP,oldstateUP,newstateUPApr2914:34:26:ISIS-Adj:Action=ACCEPT

Thenohellopaddingcommandiseffectiveonlyaftertheadjacencyisactivated(seeExample11-22).Therefore,beforeadjacencyisformed,thesizeofhellopacketstransmittedtosolicitadjacenciesisMTU–1.ThisalsoimpliesthatanadjacencystaysupwhentheMTUsizeischangedtoalargervalueafterthehellopaddingisdisabled;thehellopacketstransmittedaredeceptivelysmall.However,ifpacketslargerthantheMTUonthereceivingsidearetransmitted,theyaredropped.Inthissituation,ifthelinkflaps,theadjacencyfailsbecausetheMTUmismatchisdetectedduringtheinitialexchangeofhellosaftertheflap.Example11-22showsthatRT1stopssending38-byteunpaddedhellosandstartssending1499-bytehellosaftertheinterfaceisshutdowntodeactivatetheIS-ISadjacency.Example11-22DebuggingHelloPacketswithInterfaceShutDown

RT1(config-if)#interfaceserial0/0RT1(config-if)#shutdownRT1(config-if)#^ZRT1#


Apr2915:18:43:ISIS-Adj:SendingserialIIHonSerial0/0,length38Apr2915:18:46:%CLNS-5-ADJCHANGE:ISIS:AdjacencytoRT1(Serial0/0)Down,hodApr2915:18:46:ISIS-Adj:L2adjcount0Apr2915:18:49:ISIS-Adj:SendingserialIIHonSerial0/0,length1499Apr2915:18:52:ISIS-Adj:SendingserialIIHonSerial0/0,length1499Apr2915:19:02:ISIS-Adj:SendingserialIIHonSerial0/0,length1499Apr2915:19:11:ISIS-Adj:SendingserialIIHonSerial0/0,length1499

MisconfiguredAuthentication

Authenticationcanbemisconfiguredintwosituations,resultinginincompleteadjacencies:•Authenticationpasswordsoneithersideoftheadjacencydonotmatch.•Onesideoftheadjacencyisnotenabledforauthentication.

RecallfromChapter10thatcurrently(atthetimeofwriting)onlysimplepasswordsaresupportedonCiscorouters.ThreemethodsexistforenablingIS-ISauthentication:•Thefirstmethodisattheinterfacelevelwiththeisispasswordcommand.ThisconfigurationcanbeforroutingatLevel1orLevel2orboth.•Thesecondmethodusestherouter-levelarea-passwordcommandandappliestoonlyLevel1routingonallactiveIS-ISinterfacesontherouter.•ThethirdmethodisforLevel2onlyandusesthedomain-passwordcommandattherouterlevel.

Whenthereisapasswordmismatch,theIS-ISadjacencydoesnotcomeupatallfortheapplicablelevelofroutingoneithersideoftheconnection,andtheshowclnsneighborscommanddisplaysonlyES-ISadjacency,asshowninExample11-17.

Whenonlyonesideisenabledforauthentication,thatsidedoesnotprocesshellosfromaneighborthatdoesnotcontaintheappropriatepasswords.Thesidewithoutauthenticationdoesnotcheckforpasswords,soitreceivesandprocesseshellosasusual;however,theadjacencywillnotadvancebeyondINITbecausethelocalsideisneverlistedintheISneighbor’sTLVoftheremoterouter.TheoutputofshowclnsneighborslooksliketheoutputinExample11-15.TherouterconfiguredforauthenticationdoesnotprocessIS-IShellosfromtheremoteside,soIS-ISadjacencyisnotformed,eventhoughES-ISadjacenciesareformed,asshowninExample11-17.Example11-23showsthedebuggingoutputfromthedebugisisadj-packetscommand,providinganindicationofauthenticationproblems.Theauthenticationerrorsarehighlighted.Example11-23DebuggingAuthenticationProblems

RT1#debugisisadj-packetsApr2917:09:46:ISIS-Adj:RecserialIIHfromHDLC(Serial0/0),cirtypeL1L9Apr2917:09:46:ISIS-Adj:AuthenticationfailedApr2917:09:48:ISIS-Adj:SendingserialIIHonSerial0/0,length1499Apr2917:09:54:ISIS-Adj:RecserialIIHfromHDLC(Serial0/0),cirtypeL1L9Apr2917:09:54:ISIS-Adj:AuthenticationfailedApr2917:09:56:ISIS-Adj:SendingserialIIHonSerial0/0,length1499Apr2917:10:03:ISIS-Adj:RecserialIIHfromHDLC(Serial0/0),cirtypeL1L9Apr2917:10:03:ISIS-Adj:AuthenticationfailedApr2917:10:05:ISIS-Adj:SendingserialIIHonSerial0/0,length1499

Problem3:OnlyES-ISAdjacencyInsteadofIS-ISAdjacencyFormedCiscoroutersrunningIS-ISinIPenvironmentsstilllistentoISHsgeneratedbyES-ISprotocol,inconformancewithISO10589requirements.Hence,whenthephysicalanddatalinklayersareoperational,anES-ISadjacencycanbeformedevenifappropriateconditionsdonotexistforestablishinganIS-ISadjacency.Example11-24showswhattheoutputfortheshowclnsneighborscommandlookslikewhenanES-ISadjacencyisformedinsteadofanIS-ISadjacency.ThisismostlikelybecauseIS-IShellosarenotbeingprocessed,asaresultofinterfaceMTUmismatchormisconfiguredauthentication.Bothofthesecausesarecoveredextensivelyintheprevioussection.Example11-24ForminganES-ISAdjacency


SystemIdInterfaceSNPAStateHoldtimeTypeProtocolRT2Se0/0HDLCUp250ISES-IS

TroubleshootingIS-ISRoutingUpdateProblemsConfigurationinIS-ISisfairlysimpleandstraightforward.Inthetwo-stageprocessdiscussedinChapter10,theroutingprocessisenabledglobally,andIS-ISadjacencyformationandLSPfloodingisenabledonaninterfacebyapplyingthecommandiprouterisis.ThiscommandalsoputstheIPsubnetinformationoftheinterfaceintotherouter’sLSPthatisgeneratedandfloodedtoadjacentneighbors.ThissectioncoversIS-ISroutingupdateproblemsonthepremisethattherearenoadjacencyproblems.Thisessentiallyimpliesthattroubleshootinganyroutingupdateproblemsshouldstartwithverifyingtheappropriateadjacencies.Adjacencyproblemsandrelatedtroubleshootingmethodologyarediscussedextensivelyintheprevioussections.Thefollowingroutingupdateproblemsarecoveredinthissection:•Routeadvertisementproblems

•Routeflaps•Routeredistributionproblems

OneimportantmethodfortroubleshootingroutingproblemsinIS-ISisbydirectinspectionofthecontentsoflink-statepackets(LSPs).Dependingonitsconfiguration,anIS-ISroutergeneratesanLSPforeachofthelevelsofroutingthatitparticipatesin—Level1LSP,Level2LSP,orboth.InspectionoftheLSPcontentsoftheexpectedsourceofaroutecanhelpdiagnoseroutingadvertisementproblemsincaseswhennoobviousadjacencyproblemsexist.TheshowisisdatabasedetailcommanddisplaysthecontentsofaspecificLSP.Example11-25showssampleoutputfromthiscommand.Example11-25DisplayingtheRoutingInformationinanLSP

RT1#showisisdatabaselevel-1RT2.00-00detail

IS-ISLevel-2LSPRT2.00-00LSPIDLSPSeqNumLSPChecksumLSPHoldtimeATT/P/OLRT2.00-000x00001C9C0x5F3E10150/0/0AreaAddress:49.0002NLPID:0xCCHostname:RT2IPAddress:11.1.1.2Metric:10IS-ExtendedRT1.00Metric:10IP10.1.2.0/24Metric:0IP11.1.1.2/32Metric:10IP11.1.1.6/32Metric:10IP192.168.1.0/30

RT2.00-00istheLSPIDofRT2.DetailoutputoftheLSP,withIDRT2.00-00,showstheIPsubnetsfordirectlyconnectedlinks,togetherwiththeirmetricinformation.Anotherinterestingcommandisshowisistopology,whichdisplaysalistofallknownrouters.Forexample,Example11-26showstheIS-IStopologyforFigure11-6ascapturedonRT1.

Figure11-6ASimpleIS-ISNetworkTopology

Thebackbone(Level2)istheshadedarea.Example11-26showstheLevel1andLevel2databasesofRT1.TheLevel1databasefeaturesRT3andRT5,confirmingthattheseroutersareindeedinthesameareaasRT1.TheLevel2databasedescribesthebackbone,whichfeaturesRT2andRT3.RT2isnotinthesameareaasRT1,butitisconnectedtothebackbone,whereasRT3isaLevel1–2routerinthesameareaasRT1.

AllthisinformationgleanedfromExample11-26agreeswiththelayoutinFigure11-6;thismakestheshowisistopologycommandaninvaluablecommandfortroubleshootingrouting-relatedproblems.Example11-26ObtainingIS-ISTopologyInformation

RT1#showisistopology

IS-ISpathstolevel-1routersSystemIdMetricNext-HopInterfaceSNPART1--RT310RT3Et0/000d0.58eb.f841RT510RT5Et0/000d0.58eb.ff01

IS-ISpathstolevel-2routersSystemIdMetricNext-HopInterfaceSNPART1--RT210RT2Se0/0HDLCRT310RT3Et0/000d0.58eb.f841

RouteAdvertisementProblemsMostrouteadvertisementproblemscanbenarroweddowntoconfigurationproblemsatthesourceorLSPpropagationissues.SupposethatthereisconcernthataspecificrouteismissingonRT5(seeFigure11-6).Youcanstarttroubleshootingtheproblembyobtainingmoreinformationonthetopologyofthenetwork.Thisshouldhelpyoudeterminewhichrouteristheoriginalsourceoftheroute.Supposethattheroute11.1.1.2/32turnsouttobetheloopbackaddressofRT2;theflowchartinFigure11-7canbefollowedtonarrowthecauseoftheproblem.

Figure11-7FlowchartforTroubleshootingMissingRoutes

Usingknowledgeaboutthetopology,youknowthatRT2andRT5arenotinthesamearea.Inthiscase,ifrouteleakingisnotenabledinthenetwork,RT5,whichisaLevel1–onlyrouter,shouldnotseeanyroutefromRT2.Hence,trackingtheproblemtakesyoualongtheflowchartthroughboxes0-1-7-10-5,whereyoudeterminethatthisisnormalbehavior.AsaLevel1–onlyrouter,RT5shouldfollowadefaultroutertothenearestLevel1routertogettoremoteareas.IfyouendupinBox9orBox11alongtheflowchart,thenextcasestudiesandflowchartsmighthelpnarrowtheproblem.TheprocedurecoveredbytheflowchartinFigure11-7providesagenericmethodfortroubleshootingmissingrouteproblems.Thefollowingsectionsdiscussproceduresforspecificscenarios.LocalRoutesNotBeingAdvertisedtoRemote

BecauseIS-ISisalink-stateprotocol,IS-ISroutersdependonLSPfloodingtoobtaintopologyandroutinginformation.Forexample,duringstableconditions,eachIS-ISrouterinanareawillhavethesameLevel1link-statedatabase,whichcontainstheLSPsgeneratedbyeveryrouterinthearea.Dijkstra’salgorithmisrunovertheLSdatabasetoobtainthebestpathtoeveryadvertisedroute.Therefore,ifarouteismissingatasectionofthearea,it’sbecausetheroutersinthatsectiondidnot

receivetheoriginalLSP,ortheLSPwasreceivedcorruptedand,therefore,waspurged.AnevensimplerreasoncouldbethattheroutewasnotevenputintotheLSPatthesource.TheflowchartinFigure11-8providesthetroubleshootingmethodologyforsuchproblems.Theoutputofdebugisisupdate-packetsanddebugisissnp-packets,asdemonstratedinExample11-27,couldhelpdecipherthissortofproblemifitisrelatedtoLSPfloodingorissueswithlink-statedatabasesynchronization.

Figure11-8FlowchartforTroubleshootingRouteAdvertisementProblems

Step8oftheflowchartfortroubleshootingrouteadvertisementproblemscallsforenablingthedebuggingofLSPupdatesifitisdeterminedthatanLSPisnotmakingittocertainremotelocationsoftheIS-ISdomain.Example11-27showsanoutputofthedebugisisupdate-packetscommand.ThehighlightedlinesshowRT1floodingitsLSPandalsoreceivinganLSPfromRT2.Becausetheadjacencywasjustbroughtup,theoutputalsoshowstheone-timeexchangeofCSNPsonpoint-to-pointlinksbetweenRT1andRT2.Example11-27DebuggingIS-ISRoutingUpdateProblems

RT1#debugisisupdate-packets

Mar223:25:02:%LINEPROTO-5-UPDOWN:LineprotocolonInterfaceSerial0/0,chpMar223:25:02:ISIS-Update:BuildingL2LSP

Mar223:25:02:ISIS-Update:Nochange,suppressL2LSP0000.0000.0001.00-00,0Mar223:25:03:%CLNS-5-ADJCHANGE:ISIS:AdjacencytoRT2(Serial0/0)Up,newyMar223:25:07:ISIS-Update:BuildingL2LSPMar223:25:07:ISIS-Update:TLVcontentsdifferent,code16Mar223:25:07:ISIS-Update:FullSPFrequiredMar223:25:07:ISIS-Update:SendingL2LSP0000.0000.0001.00-00,seq160,ht0Mar223:25:07:ISIS-Update:RecL2LSP0000.0000.0002.00-00,seq1D16,ht11,Mar223:25:07:ISIS-Update:fromSNPAHDLC(Serial0/0)Mar223:25:07:ISIS-Update:LSPnewerthandatabasecopyMar223:25:07:ISIS-Update:NochangeMar223:25:08:ISIS-SNP:RecL2CSNPfrom0000.0000.0002(Serial0/0)Mar223:25:08:ISIS-SNP:RecL2PSNPfrom0000.0000.0002(Serial0/0)Mar223:25:08:ISIS-SNP:PSNPentry0000.0000.0001.00-00,seq160,ht1197Mar223:25:08:ISIS-Update:SendingL2CSNPonSerial0/0Mar223:25:08:ISIS-Update:BuildL2PSNPentryfor0000.0000.0002.00-00,se6Mar223:25:08:ISIS-Update:BuildL2PSNPentryfor0000.0000.0006.00-00,se2Mar223:25:08:ISIS-Update:SendingL2PSNPonSerial0/0Mar223:25:09:ISIS-Update:BuildingL1LSPMar223:25:09:ISIS-Update:ImportantfieldschangedMar223:25:09:ISIS-Update:ImportantfieldschangedMar223:25:09:ISIS-Update:FullSPFrequiredMar223:25:09:ISIS-Update:SendingL1LSP0000.0000.0001.00-00,seq15A,ht0Mar223:25:09:ISIS-Update:SendingL1CSNPonEthernet0/0

RT5#debugisissnp-packetsIS-ISCSNP/PSNPpacketsdebuggingisonRT5#Mar620:02:28:ISIS-SNP:RecL1CSNPfrom0000.0000.0001(Ethernet0/0)Mar620:02:28:ISIS-SNP:CSNPrange0000.0000.0000.00-00toFFFF.FFFF.FFFF.FFFMar620:02:28:ISIS-SNP:Sameentry0000.0000.0001.00-00,seq15DMar620:02:28:ISIS-SNP:Sameentry0000.0000.0001.01-00,seq104Mar620:02:28:ISIS-SNP:Sameentry0000.0000.0005.00-00,seqFEA

Thedebugisissnp-packetscommandenablesdebuggingofdatabasesynchronizationonbroadcastinterfacesandcantroubleshootrouteupdateproblemsovermediasuchasLANs.ThehighlightedlineindicatesreceiptofaCSNPbyRT5fromtheDIS(RT1).BycomparingthecontentsoftheCSNPwiththelocalLevel1database,RT5determinesthatnochangesoccurredinallknownLSPs.SolutionSummary

AsdepictedbytheflowchartinFigure11-8,therecouldbemanypotentialcausesforproblemsinwhichroutesarenotreachingremotelocationsinthenetwork.Intheextremecase,theroutemightnotbemakingitintotheroutingtablebecauseofasoftwareglitchrelatingtoIS-ISdatastructures(Steps4and5).SuchsituationsmightneedtobereportedtotheCiscoTechnicalAssistanceCenter(TAC)forfurtherassistance.Inothercases,theLSPsmightnotbereachingsomepartsofthenetworkbecausetheyaregettingcorruptedinflight(Step9).Suchproblemscanbedeterminedbyacombinationofactivities,suchasdebuggingtheupdateprocessandmonitoringrouterlogsforLSPerrors.Iftheculpritdeviceislocated,itcanbeisolatedorreplacedtoaddresstheproblem.Inmostcases,however,theproblemcouldbecausedbyatrivialconfigurationerror,suchasIS-ISnotbeingenabledonaninterface(Step11).Applyingtheappropriateinterfacecommand(iprouterisis)totheinterfaceshouldbesufficienttoaddresstheproblem.Situationsinvolvingrouteredistributionorroute-leakingproblemsareaddressedinthenextsection.

RouteRedistributionandLevel2-to-Level1Route-LeakingProblems

CiscoIOSSoftwareallowsroutesfromotherroutingsources,suchasstatic,connectedinterfaces,andotherroutingprotocols,toberedistributedintoIS-ISLevel1routing,Level2routing,orbothasexternalroutes.Technically,externalroutesshouldexistonlyintheLevel2routingenvironment,butCiscoprovidesaconfigurationattributethatallowsredistributionintoLevel1forpracticaloperationalpurposes.Forexample,serviceprovidersusingIS-ISasIGPwithflatLevel1-onlydomainsmightneedthiscapability.TheexistenceoftheIPExternalReachabilityTLVinaLevel1LSPshouldnotposeanyinteroperabilityissuesbecauseIS-ISroutersarerequiredtoskipTLVsthattheydon’tunderstandwhentheyparseanIS-ISpacket.RedistributioninIS-ISisstraightforwardwithhardlyanypotentialpitfallsexceptoccasional,unexpectedsoftwarebugs.Sometimes,effectivemetricassignmentbecomesachallengeinredistributionscenarios.Whenconfiguringredistribution,theoperatorisaskedtospecifyinternalorexternalmetrics.Thedefaultistheexternalmetrictype,whichbumpsupthemetricby128onCiscorouters.Theincreaseby128insteadof64istheresultofanincorrectbitsettinginthedefaultmetricfieldwhenusingnarrowmetrics.ThisissueisdiscussedintheconfigurationsectionasaCiscoIOSSoftwareimplementationissuethathasbeenretainedforbackwardcompatibility.TherathersimpleflowchartinFigure11-9shouldprovideguidancefortroubleshootingredistributionproblems.

Figure11-9FlowcharttoResolveRedistributionProblems

Route-FlappingProblemRouteflapsnormallyarecausedbyunstablelinksbetweenthesourceoftherouteandthelocationwheretheflapisbeingobserved.Typically,multipleroutesareimpactedatthesametimebecauseofanadjacencychangeaffectingmanyLSPs,allofwhichmightcarrynumerousIPprefixes.Also,routeflapscouldinduceconsistentrunningoftheSPFprocess,causingpotentiallydangeroushighCPUutilizationonrouteprocessorsthatmightcrashaffectedrouters.IftheadvertisedLSPchangesaffectonlyIPprefixes,onlypartialroutecalculation(PRC)isruninsteadoffullSPFcalculations.PRCislesscostlyintermsofCPUcyclesthanfullSPFruns.TheflowchartinFigure11-10providesguidancefortroubleshootingroute-flappingproblems.

Figure11-10FlowchartforTroubleshootingRoute-FlappingProblems

Apartfromcertaindestinationsnotbeingreachable—obviouslyimplyingroutingproblems—highCPUutilizationbytheSPFprocesscertainlyshouldflaginstabilitiesinthenetwork.HighCPUutilizationcanbeobservedthroughtheIOScommandlineinterface(CLI),network-managementapplications,orspecialnetwork-performanceanalysistools,suchasCiscoWorks2000,HPOpenview,andsoon.FromtheCiscoIOSSoftwareCLI,theshowprocesscpucommandcanobtainCPUutilizationinformation.IfanyindicationofhighCPUutilizationcausedbytheSPFprocessisdetermined,theshowisisspf-logcommandcandetermineSPF-relatedeventsthatmightcausethehighCPUutilization.Example11-28providessampleoutputofthiscommand.Example11-28TrackingSPFProcess-RelatedEvents

RT1#showisisspf-log

Level1SPFlogWhenDurationNodesCountLasttriggerLSPTriggers03:40:08031PERIODIC03:25:08031PERIODIC03:10:07031PERIODIC

02:55:07031PERIODIC02:40:07031PERIODIC02:25:06031PERIODIC02:10:06031PERIODIC01:56:08021RT1.01-00TLVCONTENT01:55:06021PERIODIC01:40:06021PERIODIC01:36:31021RT5.00-00LSPEXPIRED01:28:31022RT1.01-00NEWADJTLVCONTENT01:28:25031RT5.00-00NEWLSP01:25:06031PERIODIC01:10:06031PERIODIC

TheoutputinExample11-28listsSPFprocessrunsbytime,trigger,andduration.YoumightrecallthatLSPsarerefreshedevery15minutes,triggeringperiodicSPFcalculations.Sucheventsarelabeledperiodicintheshowisisspf-logoutput.Italsoshowsthatat01:25:25,theprocesswasrunoveraninsignificantperiodoftimebecauseofreceiptofanewLSPfromRT5.Table11-2listsanddescribescommonSPFtriggers.

Table11-2SPFProcessTriggers

ThefollowingIS-ISdebuggingcommandsalsocannarrowSPF-relatedproblems:•debugisisspf-events•debugisisspf-triggers•debugisisspf-statistics

•debugisisupdate-packets•debugisisadj-packets

Usecautionwhenenablingdebugginginsituationsinwhichtherouteprocessor’sCPUalreadyisovertaxed.Example11-29providessampleoutputofthedebugisisspf-eventscommand,whichdisplaystheeventsfollowinganinterfaceshuttosimulatealinkflap.LinesindicatingLSPsflaggedforrecalculationasaresultofthiseventarehighlighted.Also,eventsflaggingcomputationoftheLevel1andLevel2SPFtreesarehighlighted.Example11-29debugisisspf-eventsCommandOutputDisplaysEventsFollowinganInterfaceShut

RT1(config-if)#debugisisspf-events

Mar620:17:26:ISIS-SPF:L1LSP1(0000.0000.0001.00-00)flaggedforrecalculCMar620:17:26:ISIS-SPF:L1LSP5(0000.0000.0005.00-00)flaggedforrecalculCMar620:17:28:%LINK-5-CHANGED:InterfaceEthernet0/0,changedstatetoadmindownMar620:17:28:ISIS-SPF:ComputeL1SPTMar620:17:28:ISIS-SPF:3nodesforlevel-1Mar620:17:28:ISIS-SPF:Move0000.0000.0001.00-00toPATHS,metric0Mar620:17:28:ISIS-SPF:Add0000.0000.0001.01-00toTENT,metric10Mar620:17:28:ISIS-SPF:Add0000.0000.0001toL1routetable,metric0Mar620:17:28:ISIS-SPF:Move0000.0000.0001.01-00toPATHS,metric10Mar620:17:28:ISIS-SPF:AgingL1LSP1(0000.0000.0001.00-00),version214Mar620:17:28:ISIS-SPF:AgingL2LSP2(0000.0000.0001.00-00),version208Mar620:17:28:ISIS-SPF:AgingL1LSP3(0000.0000.0001.01-00),version207Mar620:17:28:ISIS-SPF:AgingL2LSP4(0000.0000.0002.00-00),version209Mar620:17:28:ISIS-SPF:AgingL1LSP5(0000.0000.0005.00-00),version207Mar620:17:28:ISIS-SPF:AgingL2LSP6(0000.0000.0006.01-00),version112Mar620:17:28:ISIS-SPF:AgingL2LSP7(0000.0000.0006.00-00),version114Mar620:17:28:ISIS-SPF:AgingL2LSP8(0000.0000.0001.01-00),version1Mar620:17:29:%LINEPROTO-5-UPDOWN:LineprotocolonInterfaceEthernet0/0Mar620:17:33:ISIS-SPF:ComputeL2SPTMar620:17:33:ISIS-SPF:5nodesforlevel-2Mar620:17:33:ISIS-SPF:Move0000.0000.0001.00-00toPATHS,metric0Mar620:17:33:ISIS-SPF:Add49.0001toL2routetable,metric0Mar620:17:33:ISIS-SPF:Add0000.0000.0001.01-00toTENT,metric10Mar620:17:33:ISIS-SPF:consideringadjto0000.0000.0002(Serial0/0)metricMar620:17:33:ISIS-SPF:(accepted)Mar620:17:33:ISIS-SPF:Add0000.0000.0002.00-00toTENT,metric10Mar620:17:33:ISIS-SPF:Nexthop0000.0000.0002(Serial0/0)Mar620:17:33:ISIS-SPF:Move0000.0000.0001.01-00toPATHS,metric10Mar620:17:33:ISIS-SPF:Move0000.0000.0002.00-00toPATHS,metric10Mar620:17:33:ISIS-SPF:Add49.0002toL2routetable,metric10Mar620:17:33:ISIS-SPF:RedundantIProute10.1.2.0/255.255.255.0,metric20dMar620:17:33:ISIS-SPF:RedundantIProute11.1.1.2/255.255.255.255,metricdMar620:17:33:ISIS-SPF:RedundantIProute11.1.1.6/255.255.255.255,metricdMar620:17:33:ISIS-SPF:Add192.168.1.0/255.255.255.252toIProutetable,m0Mar620:17:33:ISIS-SPF:Nexthop0000.0000.0002/192.168.1.2(Serial0/0)(rej)

SolutionSummary

Asshownintheflowchartfortroubleshootingrouteflappingproblems(seeFigure11-10),mostroute-flappingproblemscanbetracedtounstablelinksinthenetwork(seeStep2).Physicalconnectivityproblemsareaddressedbytroubleshootingthephysicalanddatalinklayers.Inmorecomplicatedscenarios,however,theflapscouldbecausedbyLSPcorruptionstormsorevenaroutingloop.ThismightbethecasewhentherearenounstablelinksinthenetworkbutCPUutilizationishigh,indicatingcontinuousrunningoftheSPFprocess(seeStep4).Theshowisisspf-logcommandcanprovideindicationofwhichLSPsarechangingthemostfrequentlyandaretriggeringtheSPF

calculations.Similarcluescanbegleanedbyenablingdebuggingoftheupdateprocesswithdebugisisupdate-packets.ThisshouldbedonewithcaresothattheCPUisnotoverloaded.ThelogsalsocanbeobservedforLSPerrorloggings,whichcouldgiveanindicationofpacketcorruptionbyaculpritdevice(seeStep7).ZeroinginonanycontinuouslychangingLSPsiscriticalfordeterminingandaddressingtheproblem.

IS-ISErrorsThissectionreviewsjustacoupleoftypicalerrorsencounteredinIS-ISroutingenvironments.Example11-30describesasituationinwhichtheIS-ISprocessreceivesahellopacketthatisonly51bytesinsteadoftheexpected53bytesATMcell.Thisiscausedbypacketcorruptionmostlikelybecauseofmalfunctionofsomeinterfacehardware.Thismightresultinadjacencyfailuresiftoomanyconsecutivehellosarecorruptedinthismanner.Example11-30UnexpectedHelloPacketSize

Nov1602:18:04.848EDT:%CLNS-4-BADPACKET:ISIS:P2Phello,option8length53remainingbytes(51)fromVC2(ATM4/0.2)

Example11-31indicatesanincorrectlyformattedlink-statepacketinwhichanNSAPaddresslengthappearslongerthanexpected.Thiscouldbecausedbysoftwareimplementationbugsandmighthaveaneffectonthedisseminationofroutinginformation.Example11-31UnexpectedNSAPAddressLengthinIncorrectlyFormattedLSP

Mar1011:59:46.171:%CLNS-3-BADPACKET:ISIS:L1LSP,option1addressprefixlength135>maxNSAPlength(21),ID0000.0000.04B7.00-00,seq25948,ht1115fromPPP(POS6/0).

Therouter-levelcommandlog-adjacency-changescausesloggingofadjacencychanges,asshowninExample11-32.Example11-32TrackingAdjacencyChanges

RT1#showlogging%CLNS-5-ADJCHANGE:ISIS:Adjacencyto0000.0000.0001(ethernet0)%CLNS-5-ADJCHANGE:ISIS:Adjacencyto0000.0000.0002(ethernet0)

Example11-33showsthetypeofmessageloggedwhenarouterdeterminesthatthereisanotherrouterinthesameareaorbackbonewithaduplicateofitssystemID.Example11-33DuplicateSystemIDMessage

RT1#showlogging%CLNS-4-DUPSYSTEM:ISIS:possibleduplicatesystemID0000.0000.0002detected

CLNSpingandtracerouteCiscoIOSSoftwareprovidespingandtraceroutetoolsforISOCLNP,whichareanalogoustotheall-too-familiarIPversion.pingclnsandtracerouteclnsapparentlyweredesignedforuseinISOCLNPenvironments,yettheycanbeusefulfortroubleshootingIS-ISoperationproblemsinIPenvironments.Contrarytopopularbelief,theclnsrouterisiscommandisnotrequiredtoenablethepingclnsandtracerouteclnscommandstowork.Youmightrecallthat,inadditiontotheIS-ISprocess,onlytheip

routerisiscommandisrequiredtoactivateIS-ISroutingforIPonlyonarouter’sinterface.Examples11-34through11-38demonstratetheoperationoftheCLNS-basedpingclnsandtracerouteclnscommands.TheseexamplesarebasedonFigure11-11.Thereisanextendedoptionforeachofthesecommands,justasinthecaseofthecorrespondingIPversions.

Figure11-11BasicNetworkforTestingOperationofthepingclnsandtracerouteclnsCommands

Example11-34OperationofthepingclnsCommand

RT5#pingclns49.0002.0000.0000.0006.00

Typeescapesequencetoabort.Sending5,100-byteCLNSEchoswithtimeout2seconds!!!!!Successrateis100percent(5/5),round-tripmin/avg/max=4/4/4ms

Example11-35OperationofthepingclnsCommandinExtendedMode

RT5#pingProtocol[ip]:clnsTargetCLNSaddress:49.0002.0000.0000.0006.00Repeatcount[5]:2Datagramsize[100]:Timeoutinseconds[2]:Extendedcommands[n]:ySourceCLNSaddress[49.0001.0000.0000.0005.00]:IncludeglobalQOSoption?[yes]:Padpacket?[no]:Validatereplydata?[no]:Datapattern[0xABCD]:Sweeprangeofsizes[n]:Verbosereply?[no]:Typeescapesequencetoabort.Sending2,100-byteCLNSEchoswithtimeout2seconds!!Successrateis100percent(2/2),round-tripmin/avg/max=4/4/4ms

Example11-36showsthepacketdebugsduringoperationofthepingclnscommand(seeExamples11-34and11-35).ThedebugsshowthesourceanddestinationNSAPs,aswellastheoutgoinginterfaceforeachoutgoingpacket.Example11-36CLNSPacketDebugsDuringCLNSpings

RT5#debugclnspacketsMar1007:50:43:CLNS:Originatingpacket,size100Mar1007:50:43:from49.0001.0000.0000.0005.00to49.0002.0000.0000.0006.00

via0000.0000.0001(Ethernet0/000d0.58f7.8941)

Mar1007:50:43:CLNS:EchoReplyPDUreceivedonEthernet0/0!

Mar1007:50:43:CLNS:Originatingpacket,size100Mar1007:50:43:from49.0001.0000.0000.0005.00to49.0002.0000.0000.0006.00via0000.0000.0001(Ethernet0/000d0.58f7.8941)

Mar1007:50:43:CLNS:EchoReplyPDUreceivedonEthernet0/0!

Examples11-37and11-38illustratetheoperationofthetracerouteclnscommandinstandardandextendedmodesfromRT5toRT6.Asinthecaseofthepingclnscommand,operationinextendedmodeallowscustomizationofthecommand,includingexplicitspecificationofthesourceNSAPaddressofthetraceroutepackets.Example11-37OperationoftracerouteclnsCommand

RT5#tracerouteclns49.0002.0000.0000.0006.00

Typeescapesequencetoabort.Tracingtherouteto49.0002.0000.0000.0006.00149.0001.0000.0000.0001.000msec!0msec!0msec!249.0002.0000.0000.0002.000msec!0msec!0msec!349.0002.0000.0000.0006.000msec!0msec!0msec!

Example11-38OperationoftracerouteclnsCommandinExtendedMode

RT5#tracerouteProtocol[ip]:clnsTargetCLNSaddress:49.0002.0000.0000.0006.00Timeoutinseconds[3]:Probecount[3]:MinimumTimetoLive[1]:MaximumTimetoLive[30]:Extendedcommands[n]:ySourceCLNSaddress[49.0001.0000.0000.0005.00]:IncludeglobalQOSoption?[yes]:Padpacket?[no]:Validatereplydata?[no]:Datapattern[0x60CD]:Sweeprangeofsizes[n]:Verbosereply?[no]:Typeescapesequencetoabort.Tracingtherouteto49.0002.0000.0000.0006.00149.0001.0000.0000.0001.004msec!0msec!0msec!249.0002.0000.0000.0002.000msec!0msec!0msec!349.0002.0000.0000.0006.000msec!0msec!0msec!

CaseStudy:ISDNConfigurationProblemThiscasestudyexploresaproblemthatinvolvessettingupIS-ISroutingoveranISDNlink.Theobjectiveistoputthetroubleshootingknowledgeacquiredinthischaptertoimmediateusebytryingtofigureoutanypotentialproblemsinthesetup.RTAandRTBareconnectedoveranISDNlink,asshowninFigure11-12.Standardconfigurationisemployed,asdemonstratedinExample11-39.

Figure11-12NetworkTopologyforISDNConfigurationProblem

Example11-39ConfigurationsforRTAandRTBinFigure11-12

RTA#interfaceBRI1/0ipaddress192.168.31.1255.255.255.0iprouterisisencapsulationpppbandwidth56000isdnspid1919472099801014720998isdnspid2919472099901014720999dialeridle-timeout1200dialermapclns49.0040.0000.0000.3200.00nameRTBbroadcast4723074dialermapip192.168.31.3nameRTBbroadcast4723074dialerhold-queue10dialerload-threshold100dialer-group1pppauthenticationchapclnsrouterisis!routerisispassive-interfaceLoopback0net49.0040.0000.0000.3100.00is-typelevel-1!clnsroute49.0040.0000.0000.3200.00BRI1/0dialer-list1protocolippermitdialer-list1protocolclnspermit

RTB#interfaceBRI1/0ipaddress192.168.31.3255.255.255.0iprouterisisencapsulationpppbandwidth56000isdnspid1919472307401014723074isdnspid2919472307501014723075dialeridle-timeout1200dialermapclns49.0040.0000.0000.3100.00nameRTAbroadcast4720998dialermapip192.168.31.1nameRTAbroadcast4720998dialerhold-queue20dialerload-threshold200dialer-group1pppauthenticationchapclnsrouterisis

routerisispassive-interfaceLoopback0net49.0040.0000.0000.3200.00is-typelevel-1!clnsroute49.0040.0000.0000.3100.00BRI1/0dialer-list1protocolippermitdialer-list1protocolclnspermit

IntheconfigurationsinExample11-39,thedialer-listcommandisusedtospecify“interesting”packets,whichcouldforceaconnectionsetupandbringuptheISDNlink.Bothipandclnskeywordsarespecifiedoneithersideofthelink;however,asshowninExample11-40andthecorrespondingdebugsinExample11-41,usingCLNSpingfromRTBcannotbringupthecircuit.Example11-40AttemptingtoBringUptheISDNConnectionwithCLNSpingfromRTB

RTB#pingclns49.0040.0000.0000.3100.00

Typeescapesequencetoabort.Sending5,100-byteCLNSEchoswithtimeout2seconds

CLNS:cannotsendECHO.CLNS:cannotsendECHO.CLNS:cannotsendECHO.CLNS:cannotsendECHO.CLNS:cannotsendECHO.Successrateis0percent(0/5)

Example11-41showshowdebuggingofCLNspacketsdeterminestherootcauseoftheproblem.ThehighlightedtextindicatesencapsulationfailurebecausetheBRIinterfaceisanunknowndatalinktype.Example11-41UsingdebugsclnspacketstoTroubleshoottheProblem

RTB#debugclnspacketsCLNSpacketsdebuggingison

Aug909:35:17:CLNS:Originatingpacket,size100Aug909:35:17:from49.0040.0000.0000.3200.00to49.0040.0000.0000.3100.00via49.0040.0000.0000.3100.00(BRI1/0**UnknownSNPAtype**)Aug909:35:17:CLNSencapsfailedonBRI1/0fordst=49.0040.0000.0000.3100.00Aug909:35:17:CLNS:Originatingpacket,size100Aug909:35:17:from49.0040.0000.0000.3200.00to49.0040.0000.0000.3100.00via49.0040.0000.0000.3100.00(BRI1/0**UnknownSNPAtype**)Aug909:35:17:CLNSencapsfailedonBRI1/0fordst=49.0040.0000.0000.3100.00Aug909:35:17:CLNS:Originatingpacket,size100Aug909:35:17:from49.0040.0000.0000.3200.00to49.0040.0000.0000.3100.00via49.0040.0000.0000.3100.00(BRI1/0**UnknownSNPAtype**)Aug909:35:17:CLNSencapsfailedonBRI1/0fordst=49.0040.0000.0000.3100.00Aug909:35:17:CLNS:Originatingpacket,size100Aug909:35:17:from49.0040.0000.0000.3200.00to49.0040.0000.0000.3100.00via49.0040.0000.0000.3100.00(BRI1/0**UnknownSNPAtype**)Aug909:35:17:CLNSencapsfailedonBRI1/0fordst=49.0040.0000.0000.3100.00Aug909:35:17:CLNS:Originatingpacket,size100Aug909:35:17:from49.0040.0000.0000.3200.00to49.0040.0000.0000.3100.00via49.0040.0000.0000.3100.00(BRI1/0**UnknownSNPAtype**)

Aug909:35:17:CLNSencapsfailedonBRI1/0fordst=49.0040.0000.0000.3100.00

Experimentationwiththevariousoptionsinthedialer-listcommand,however,confirmsthattheappropriatekeywordrequiredisclns_isinsteadofclns,asdemonstratedinExample11-42.Example11-42CLNSRelatedKeywordOptionsforthedialer-listCommand

RTB(config)#dialer-list1protocol?

clnsOSIConnectionlessNetworkServiceclns_esCLNSEndSystemclns_isCLNSIntermediateSystem

RTB(config)#dialer-list1protocolclns_ispermit

Example11-43showsthatthepingclnscannowbringupthelinksafterappropriatechangeismadeinthedialerlistconfiguration.ThiscasestudyelaborateshowthepingclnscommandiscombinedwithCLNPpacketdebuggingtotroubleshootabasicconnectivityproblem.Example11-43RetestingtheConnectionwiththeclnsisoptioninthedialer-liststatement

RTB#pingclns49.0040.0000.0000.3100.00

Typeescapesequencetoabort.Sending5,100-byteCLNSEchoswithtimeout2seconds!!!!!Successrateis100percent(5/5),round-tripmin/avg/max=40/42/44ms

IS-ISTroubleshootingCommandSummaryTable11-3IS-ISTroubleshootingCommands

SummaryThischapterfocusesontroubleshootingmethodologyforcommonIS-ISproblems.Twobroadclassesoftroubleshootingproblemsareidentifiedatthestartofthechapter:•Misconfigurationandinteroperabilityproblems•Problemscausedbymalfunctioningofsoftwareorhardware

Theprimaryobjectivesofthetroubleshootingtechniquesdiscussedinvolveidentifyingbothcategoriesofproblems.However,problemsthatseemtofallinthelaterclassnormallyrequirespecialtoolsanddeeperunderstandingoftheCiscoIOSimplementationandshould,therefore,bereferredtoCiscoforfurtherdiagnosis.Misconfigurationandinteroperabilityissuesarebrokendownintoadjacencyformationproblemsandroutingupdateproblems.Table11-1providesasummaryofadjacencyproblemsandlistspossiblecauses.Subsequentcoverageonadjacencyproblemsprovidesdetaileddescriptionsoftroubleshootingmethodologyandflowcharts,alongwithshowcommandsanddebuggingexamples.Latersectionsofthechapterarededicatedtoreviewingroutingupdateproblemsandflowcharts;relevantdebugginginformationfortroubleshootingsuchproblemsisalsoprovided.ThefinalsectionsreviewsomecommonIS-ISerrorsthatareloggedtoflagpotentialproblems.Theping

clnsandtracerouteclnscommandsarealsodiscussed.Attheendofthechapter,acasestudyfortroubleshootingabasicsetupofIS-ISroutingoveranISDNconnectionisdiscussed.

Chapter12.UnderstandingProtocolIndependentMulticast(PIM)

ThischaptercoversthefollowingkeytopicsaboutProtocolIndependentMulticast(PIM):•FundamentalsofIGMPversion1,IGMPversion2,andreversepathforwarding(RPF)•PIMdensemode•PIMsparsemode•IGMPandPIMpacketformat

Host-to-hosttransmissionhasbeentheissueofmanydiscussionsinthetechnicalworld.Astechnologiesadvance,newmethodologiesforfacilitatingthattransmissionemerge.Atransmissionfromonespecifichosttoanotherspecifichostisknownasaunicast.One-to-onetransmissioniseasy.Thebigpush,currently,isfiguringouthowtotransmitfromonehosttomanywithoutdisruptingtrafficflow.Upuntilnow,ifyouwantedonehosttotalktomultiplehosts,youhadtoresorttousingabroadcast.Multicasthasemergedinrecentyearsasamoreefficientalternative.Thedifferencebetweenmulticast,broadcast,andunicastisthatunicastpacketsaredestinedforonehostonly.Broadcastpacketsaredestinedforallhostsonthesamesegment,regardlessofwhetherthehostisinterestedinthepacket.Multicastisanefficientmethodofdeliveringpacketsonlytohostsinterestedinthepackets.MulticastpacketsarewithintheClassDaddressrangeof224.0.0.0to239.255.255.255.Themulticastsendersendsonlyonecopyofthepacket,andonlythehostsinterestedinthemulticastpacketprocessthepacket.Becausemulticastpacketsmighttraverseseveralroutersbeforereachingtheintendeddestination,theseroutersneedtohavearoutingprotocolenabledtoensurethatmulticastpacketsaredeliveredefficientlyandloop-free.Severalmulticastroutingprotocolshavebeendevelopedforthismatter.OneofthefirstisDistanceVectorMulticastRoutingProtocol(DVMRP);however,DVMRPisslowinconvergenceandisnotscalable.CiscodevelopeditsownmulticastroutingprotocolcalledProtocolIndependentMulticast(PIM).PIMusestheunicastroutingtabletomakeforwardingdecisions;therefore,therouter’schoiceofunicastroutingprotocolcouldbeanyoftheprotocolcoveredinthisbook—namely,RIP,IGRP,EIGRP,OSPF,BGP,orIS-IS.PIMworksintwodifferentmodes—densemodeandsparsemode.Eachmodehasitsownadvantagesanddisadvantages,andeachmodehasdifferentimplementationmethods.Densemodeusestheflood-and-prunemechanismtoforwardmulticasttraffic.Densemodeisextremelyeasytoimplementandislesscomplexthansparsemode;however,densemodeisnotscalableinlargenetworks.Therefore,densemodeismoresuitableforasmallmulticastenvironment.Sparsemodeusestheexplicitgroup-joinmechanismtoforwardmulticasttraffic.Unlikedensemode,sparsemodeisveryscalableandcanruninalargemulticastenvironment.Becauseitismorescalable,itsimplementationismorecomplexthandensemode,whichmeansthatitishardertotroubleshoot.

FundamentalsofIGMPVersion1,IGMPVersion2,andReversePathForwardingBeforedivingintotheintricaciesofthePIMprotocol,youneedtounderstandtheconceptbehindtheInternetGroupManagementProtocol(IGMP)andreversepathforwarding(RPF).IGMPistheprotocolthatfunctionsbetweenthehost,alsocalledthereceiver,andthemulticast-enabledrouter.Inshort,IGMPallowstheroutertoknowthatahostisinterestedinreceivingmulticasttrafficforaspecificgroup.IGMPisenabledontherouterwheneverPIMisenabled.IGMPmessagesaresentwithaTTLof1;therefore,IGMPpacketsareconstrainedtothelocalnetworkonly.

IGMPVersion1InIGMPversion1(definedinRFC1112),therouterssendsIGMPqueriestothe“all-hosts”multicastaddressof224.0.0.1tosolicitmulticastgroupswithactivemulticastreceivers.ThemulticastreceiversalsocansendIGMPreportstotheroutertonotifyitthattheyareinterestedinreceivingaparticularmulticaststream.HostscansendthereportasynchronouslyorinresponsetotheIGMPqueriessentbytherouter.Ifmorethanonemulticastreceiverexistsforthesamemulticastgroup,onlyoneofthesehostssendsanIGMPreportmessage;theotherhostssuppressestheirs.Forexample,inFigure12-1,therouterR1sendsperiodicIGMPqueriestothe224.0.0.1address.OnlyonememberpergrouppersubnetsendstheIGMPreportmessagetotherouter—inthiscase,H2—whiletheotherhostsH1andH3suppresstheirs.

Figure12-1ExampleofIGMPVersion1

InIGMPversion1,thereisnoelectionofanIGMPquerier.Ifmorethanonerouteronthesegmentexists,alltherouterssendperiodicIGMPqueries.IGMPversion1hasnospecialmechanismbywhichthehostscanleavethegroup.Ifthehostsarenolongerinterestedinreceivingmulticastpacketsforaparticulargroup,theysimplydonotreplytotheIGMPquerypacketssentfromtherouter.Theroutercontinuessendingquerypackets.IftherouterdoesnotheararesponseinthreeIGMPqueries,thegrouptimesoutandtherouterstopssendingmulticastpacketsonthesegmentforthegroup.Ifthehostlaterwantstoreceivemulticastpacketsafterthetimeoutperiod,thehostsimplysendsanewIGMPjointotherouter,andtherouterbeginstoforwardthemulticastpacketagain.

IGMPVersion2IGMPversion2(definedinRFC2236)introducesseveralchangestomakeIGMPmoreefficientinjoiningandleavingthegroup.Someoftheimportantchangesarelistedhere:•Querierelectionmechanism—Onamultiaccessnetwork,anIGMPquerierrouteriselectedbasedontheIPaddress.Therefore,onlyonerouterpersegmentsendsIGMPqueries.•Leavegroupmessage—Thehostsendsaleavemessageifitisnolongerinterestedinamulticastgroup.Thisreducesleavelatencywhencomparedtoversion1.•Group-specificquery—Theroutersendsagroup-specificquerybeforeittimesoutthegroup.Thisensuresthattherearenomorehostsleftonthesegmentthatmightstillbeinterestedinreceivingthemulticastgroup.

TheIGMPjoinmechanisminversion2isthesameasinversion1.Theleavemechanismisalittledifferent,though.Inversion2,whenahostwantstoleavethegroup,itsendsanIGMPleavemessage.Whentherouterreceivestheleavemessage,itsendsanIGMPquerypackettoseeifanymorehostsareinterestedinthegroup.Ifhostsstillareinterestedinthegroup,theysendanIGMPjoinmessagetooverridetheIGMPleavemessage;otherwise,therouterassumesthattherearenomorehostsinterestedinthemulticastgroup,andthegrouptimesout.Figure12-2illustratesthathostH2wantstoleavethemulticastgroupbecauseitsendsanIGMPleavemessage.WhenRouterR1receivestheleavemessage,itimmediatelysendsoutanIGMPquerytomakesurethatnootherhostsareinterestedinthegroup.Inthiscase,hostH1isstillinthegroup,andH1overridestheIGMPleavemessagebysendinganIGMPreportmessage.Inthisscenario,thegroupremainsactiveandtherouterkeepsforwardingmulticastpacketsonthesegment.

Figure12-2IGMPVersion2LeaveMechanism—MulticastGroupRetained

Figure12-3depictsthesamescenarioasintheFigure12-2.RouterR1sendsoutanIGMPqueryafteritreceivestheIGMPleavefromthehostH2.BecausebothhostsH1andH3arenotinterestedinthegroup,theysimplyignoretheIGMPquerymessagesentbytherouter.Whentherouterdoesn’thearanyresponsefromitsIGMPquery,ittimesoutthegrouponthesegment,andRouterR1stopssendingmulticastpacketsforthatgroup.

Figure12-3IGMPVersion2LeaveMechanism—MulticastGroupTimedOut

MulticastForwarding(ReversePathForwarding)YoumustunderstandthewaythemulticastforwardingmechanismworksbeforeunderstandinghowPIMcomesintoplay.Multicastroutingisbackwardfromunicastrouting.Unicastroutingisconcernedaboutwherethepacketisgoing,whereasinmulticastrouting,theconcerniswherethepacketsarecomingfrom.Multicastroutingusestheconceptofreversepathforwarding(RPF)todeterminewhetheraforwardingloopexists.Inshort,RPFallowstheroutertoforwardamulticastpacketonlyifthepacketisreceivedontheupstreaminterfacetothesource.Tobespecific,iftherouterreceivesamulticastpacketonaninterface,theunicastroutingtableisusedtocheckthesourceaddressofthemulticastpacket.Ifthepacketarrivesontheinterfacespecifiedintheunicastroutingtableforthesourceaddress,theRPFchecksucceeds;otherwise,theRPFcheckfailsandthemulticastpacketsaresilentlydropped.InFigure12-4,therouterreceivesamulticastpacketfrominterfaceS1,andthesourceis192.168.3.1.Therouterchecksitsunicastroutingtableforaddress192.168.3.1.Theunicastroutingtableindicatesthatitlearnedaboutnetwork192.168.3.0/24frominterfaceS1.TheRPFcheck,inthiscase,succeedsbecausethemulticastinterfaceandtheunicastroutingtablearecongruent.WhentheRPFchecksucceeds,therouterforwardsthemulticastpacketstoitsoutgoinginterfaces—inthiscase,interfacesE0andS2.Theoutgoinginterfacesareinterfacesthatmeetanyofthefollowingconditions:•APIMneighborisheardontheinterface.•Ahostonthisinterfacehasjoinedthegroup.•Theinterfacehasbeenmanuallyconfiguredtojointhegroup.

Figure12-4SuccessfulRPFCheck

InFigure12-5,therouterreceivesmulticastpacketsfrominterfaceS0withthesourceaddressof192.168.3.1.Therouterchecksitsunicastroutingtable,asinthepreviousexampleandfindsoutthattheunicastroutingtableknowsaboutnetwork192.168.3.0/24frominterfaceS1.Theunicastroutingtable,inthiscase,isnotcongruentwiththeinterfacethatthemulticastpacketsarecomingfrom.Therefore,theRPFcheckfailsandthemulticastpacketsaredropped.

Figure12-5FailedRPFCheck

PIMDenseModePIMhastwomodesofoperation—densemodeandsparsemode.Densemodeusesaflood-and-prunemechanismtoforwardmulticastpackets.Therouterassumesthateverymulticastinterfaceisinterestedinmulticastpackets,unlessitistoldotherwise.Therouterfirstforwardsmulticastpacketstoalltheinterfaces.Segmentsthatdon’twantmulticastpacketsreceiveprunemessagesfromtheneighboringrouters,andthebranchispruned.Whentherouterisfirstconfiguredformulticast,theroutersendsperiodicPIMquerypacketstothemulticastaddressof224.0.0.2(allroutersonthissubnetaddress)todiscoveritsPIMneighbors.ThePIMquerypacketsaresentouttheinterfacesthatareconfiguredforPIM.PIMneighborsareestablishedacrossaninterfacewhenPIMqueriesarereceivedonthatinterface.PIMdensemodefloodsmulticastpacketsonitsoutinterfacelist(alsoknownasanoilist).PIMdensemodeputsaninterfaceinitsoilistifthefollowingconditionsaretrue:•TheinterfacehasanestablishedPIMneighbor.•TheinterfacehashostsjoiningthemulticastgroupthroughIGMP.•Theinterfacehasbeenmanuallyconfiguredtojointhegroupthroughtheipigmpjoin-groupcommand.

WhenarouterrunningPIMdensemodefirstreceivesmulticastpackets,itfloodsthemulticastpacketstoallinterfaceslistedintheoilist.Therouterstopsforwardingmulticastpacketsonaninterfaceifitreceivesaprunepacketfromitsneighbor.InFigure12-6,theRouterR1receivesincomingmulticastpacketsoninterfaceS0.AsR1isrunningdensemode,itfloodsthemulticastpacketstoallitsoilistinterfaces,E0andS1.BecauseRouterR2doesn’thaveanyhostsinterestedinmulticasttraffic,itsendsaPIMprunemessagetowardR1.WhenR1

receivesthePIMprune,itwaitsforthreesecondsbeforeitstopsforwardingmulticastpacketsforthegrouptointerfaceE0.Thisthree-seconddelayallowsotherroutersonthesegmenttooverridetheprunewithaPIMjoin.

Figure12-6PIMDense-ModePruning

Whentheinterfacehasbeenpruned,therouterstopsforwardingmulticastpacketsforthegrouptotheinterface.InFigure12-6,supposethatRouterR2nowhasahostthatwantstoreceivemulticastpacketsoninterfaceE1.RouterR2sendsaPIMgraftpackettoRouterR1.WhenRouterR1receivesthePIMgraftmessage,itputsitsinterfaceE0intoaforwardingstate,andmulticasttrafficflowstoRouterR2.IftherearetworoutersonthesameLANinterfaceandbothroutershaveaconnectiontothesourceofthemulticaststream,bothrouterspotentiallycouldforwardmulticastpacketsandcauseduplicatepacketsontheLANinterface.PIMdensemodehasanassertmechanismtoavoidsuchscenarios.Figure12-7illustratesthePIMassertmechanism.

Figure12-7PIMAssertMechanism

IntheabsenceofthePIMassertprocess,bothroutersforwardmulticastpacketsontointerfaceE0.ThiscausesduplicatepacketsontheLANinterface.Withtheassertmechanism,bothrouterssendthePIMassertpacketwiththeunicastroutingdistanceandmetrictothesourceofthemulticaststream.Therouterwiththebestunicastroutetothesourcewinsandstartsforwardingthemulticastpackets.Therouterthatlosestheassertbattleprunestheoutgoinginterface.Ifatieisontheunicastroutingmetric,therouterwiththehighestIPaddresswinstheassert.Thisway,onlyonerouterisactivelyforwardingthemulticasttraffic.

PIMSparseModePIMsparsemodeworkstheoppositewayofdensemode.PIMdensemodeassumesthatallthemulticastinterfacesareinterestedinmulticastpackets,unlessbeingtoldotherwise.InPIMsparsemode,therouterassumesthatnoneofthemulticastinterfacesisinterestedinreceivingmulticastpackets,unlessaPIMjoinmessageisreceivedontheinterface.PIMsparsemodeismorescalablethanPIMdensemode,buttheconceptismorecomplex.PIMsparsemodeusestheconceptofarendezvouspoint(RP).TheRPiswherethesenderandthereceiversmeetfirstbeforetheshortest-pathtreeisestablished.Theshortest-pathtreeistheshortestpathbetweenthemulticastsenderandthereceiver.Foraparticularmulticastgroup,onlyoneRPischosen.TheselectionoftheRPisdonebyeitherstaticconfigurationordynamicallylearnedthroughtheAuto-RPmechanism.PIMsparsemodediscoversitsneighborthesamewaythatPIMdensemodeworks.ThePIMrouterssendoutPIMquerypacketstodiscoverPIMneighborsonthelink.InPIMsparsemode,thehighestIPaddressonaLANsegmentiselectedthedesignatedrouter.ThisdesignatedrouterisusedtosendPIMjoinstotheRPforthesegment.Insparsemode,multicastflowhastwoparts:1ReceiverssendPIMjoinstotheRP.2ThesourcesendsPIMregisterstotheRP.

InthePIMsparsemodejoinmechanism,therouterthatisclosesttothereceivingstationsendsthePIMjoinmessagetotheRP.IfmorethanonerouterexistsontheLANsegment,thePIMDRsendsthejointotheRP.ThePIMjoinsarethensenthopbyhoptowardtheRP.Figure12-8illustratesthePIMsparsemodejoinmechanism.

Figure12-8PIMSparseModeJoining

InFigure12-8,thePCsendsIGMPjoinstoitsEthernetinterface.RouterR2istheDRbecauseithasahigherIPaddressoninterfaceE1.RouterR2sendsPIMjoinstowardtheRP,soR2sendsPIMjoinstoRouterR1.RouterR1sendsthePIMjoinstowardtheRP.Therefore,thePIMjoinsaresenthopbyhopfromtheleafrouterclosesttothereceiver,allthewaytotheRP.Theleafrouterisdefinedastheoutermostedgerouterthathasonlyreceiversconnected.Thesecondpartofthesparsemodeoperationistheregisterprocess,whichcanbedissectedintothefollowingsequenceofevents:1Thesparsemoderegistermessagesaresentbytherouterthatisclosesttothesenderofthemulticaststream.IfmorethanonerouterexistsontheLANsegment,thePIMDRisresponsibleforsendingthePIMregistermessagetotheRP.

2Whenthesenderbeginssourcingamulticaststream,thefirst-hoprouterencapsulatesthemulticastpacketsintothePIMregistermessagesandunicaststhemtotheRP.

3WhentheRPreceivestheregistermessage,itfirstde-encapsulatesthemulticastpacketthatitcontains.

4TheRPthenforwardsthemulticastpackettowardanyexistingreceiversandalsosendsaPIMjoinmessagetowardthemulticastsource.

5WhenthePIMjoinreachesthefirst-hoproutertothesource,thefirst-hoprouterstartsforwardingnativemulticasttraffictowardtheRP,whilestillsendingPIMregistermessagestotheRP.

6WhentheRPreceivestwocopiesofamulticastpacket,onefromtheregistermessageandtheotherfromthenativemulticastpath,theRPsendsaregisterstopmessagetothefirst-hoprouter.

7Whenthefirst-hoprouterreceivestheregisterstopmessage,itstopsencapsulatingthemulticasttrafficintotheregistermessageandforwardsitnativelytotheRP.

Figure12-9illustratesthefirstpartofthesparsemoderegisterprocess,whichcorrespondstoevents1through4inthepreviousdiscussion.(ThePCsourcesthemulticaststream,andRouterR1encapsulatesthemulticastpacketsintoPIMregistermessagesandunicaststhepacketstotheRP.)WhentheRPreceivestheregisterpackets,itde-encapsulatesthemulticastpacketsandforwardsthemdownstreamtothereceivers.Atthesametime,theRPsendsPIMjoinstowardthesource.Inthiscase,theRPsendsjoinstoRouterR2,andRouterR2sendsPIMjoinstoR1.

Figure12-9PIMSparseModeRegisterProcess,Part1

Figure12-10isthecontinuationofthePIMsparsemoderegisterprocess.WhenRouterR1receivesthejoinfromtheRP,R1beginstosendthemulticasttraffictowardtheRP.TheregistermessagesfromR1arestillforwarded.TheRPthenreceivestwocopiesofthemulticastpacket,onefromtheregistermessageandtheotherfromthenativemulticastflow.WhentheRPseestwocopiesofthemulticastpacket,itsendsaregisterstopmessagetothefirst-hoprouter—inthiscase,RouterR1.WhenR1receivestheregisterstopmessage,itstopsencapsulatingthemulticastpacketsintoregistermessages,andthetrafficnowflowsnativelyfromR1toR2andthentotheRP.TheRPthenforwardsthemulticaststreamtoitsdownstreamneighbors.

Figure12-10PIMSparseModeRegisterProcess,Part2

Thesparse-modepruningmechanismisthesameastheoneusedindensemode.Iftherouterisnotinterestedinthemulticasttraffic,itsendsaPIMprunemessagetotheupstreamneighbortowardthesource.ForamoredetaileddescriptiononPIMoperation,refertoBeauWilliamson’sbookDevelopingIPMulticastNetworks,Volume1.

IGMPandPIMPacketFormatThepacketformatofIGMPandPIMisusefulinunderstandingtheoperationofPIM.UnderstandingthepacketformatalsohelpsyouintroubleshootingPIMproblems,incasesniffertracesneedtobelookedat.ThissectioncoverstheimportantpacketformatofIMGPandPIM.

IGMPPacketFormatIGMPmessagesarealwayssentwithaTTLof1andareIP-encapsulatedwithaprotocolnumberof2.Figure12-11showstheIGMPversion2packetformat.TheIGMPversion1packetformatisalittledifferentthantheformatofversion2.TheIGMPversion1packetsplitstheTypefieldinversion2intotwoparts,toincludeboththeversionnumberandthetype.

Figure12-11IGMPPacketFormat

TheTypefieldindicatesdifferenttypesofIGMPpackets:•Type11istheIGMPmembershipquery.•Type12istheIGMPversion1membershipreport.•Type16istheIGMPversion2membershipreport.•Type17indicatestheIGMPversion2leavegroup.

Thetypeslistedarethemostimportantones.YoucanfindotherTypefieldinformationinRFC2236.TheMaximumResponseTimefieldisusedonlyinmembershipquerymessages.Itspecifiesthemaximumtimeinunitsof1/10ofasecondthatahostmightwaittorespondtoaquerymessage.TheChecksumfieldisthechecksumoftheIGMPmessagetoverifypacketintegrity.TheGroupAddressfieldcontainsthemulticastgroupthatthereceiverisinterestedinreceiving.WhenthegeneralIGMPqueryissent,thisgroupaddressfieldissetto0.

PIMPacket/MessageFormatsPIMversion1packetsareencapsulatedinIGMPType14packets.PIMversion2usesitsownprotocol

numberof103andisnotencapsulatedintoIGMP.PIMversion2packetsaresenttothemulticastaddress224.0.0.13.Figure12-12showstheformatforPIMhellomessages.

Figure12-12PIMHelloPacketFormat

ThePIMhellomessagebelongstothePIMType0packet.OptionTypeisalwayssetto1.ThePIMhellopacketsareusedtoestablishthePIMneighborrelationship.Figure12-13showsthePIMregistermessageforPIMsparsemode.

Figure12-13PIMRegisterPacket

ThePIMregistermessagebelongstoPIMType1packets.TheDRencapsulatesthemulticastpacketintotheregisterpacketandsendsittotheRP.Fromthepacketformat,theBbitissetto1iftherouterisaPIMmulticastborderrouterforthesource.TheBbitissetto0ifthesendingrouterisaDRforadirectlyconnectedsource.TheNbitisthenullregister,anditisusedtopreventunnecessaryburstsoftrafficbeingsenttotheRPbetweenreceivingREGISTERSTOPmessages.Figure12-14showstheREGISTERSTOPmessageformat.

Figure12-14PIMREGISTERSTOPPacketFormat

TheencodedgroupaddresscontainsthegroupsofmulticastaddressesbeingencapsulatedintotheREGISTERmessage.TheEncodedunicast-sourceaddresscontainstheunicastaddressofthesourceofthemulticaststream.Fromthepreviousdiscussion,theREGISTERSTOPmessageissenttotherouterthatsendstheREGISTERmessage,toindicatethatanativemulticaststreamhasbeenreceivedandthattheDRcanstopsendingtheREGISTERpackets.Figure12-15illustratesthePIMJOIN/PRUNEmessagethatisusedinbothdenseandsparsemodes.

Figure12-15PIMJOIN/PRUNEPacketFormat

InthePIMJOIN/PRUNEpacket,theencodedunicastupstreamneighboraddressistheIPaddressoftheRPFneighborthatperformsthejoinorprune.Thenumberofgroupscontainsthenumberofmulticastgroupsetsinthemessage.Eachsetconsistsofanencodedmulticastgroupaddress,followedbyalistofencodedsourceaddressestojoinorprune.Figure12-16showstheformatforthePIMassertmessage.TheassertmechanismallowstheroutertoselectanactiveroutertoforwardthemulticastpacketstoavoidpacketduplicationontheLAN.

Figure12-16PIMAssertPacketFormat

Theencodedgroupaddressisthemulticastgroupaddress.TheencodedunicastsourceaddressistheIPaddressofthesourceofthemulticaststream.Themetricistheroutingmetrictothesourceofthemulticaststreamassociatedwiththeroutingprotocolused.ThemetriccouldbehopcountiftheroutingprotocolusedisRIP.TheRbitistheRPTbitandissetto1ifthemulticastpacketthattriggeredtheassertpacketisrouteddownthesharedtree.TheRbitissetto0ifthemulticastpacketisrouteddowntheshortest-pathtree.

SummaryThePIMprotocolprovidesmulticastroutingthatisindependentoftheunderlyingunicastroutingprotocol.TheIGMPmechanismisthecommunicationbetweentherouterandthemulticasthosts.PIMdensemodeprovidesaneasyimplementationofmulticastrouting,butbecauseofthenatureoftheflood-

and-prunemechanism,it’snotascalablemulticastsolution.PIMsparsemode,however,providesscalabilityforlargenetworks,butitsoperationisabitmorecomplexthanthatofPIMdensemode.ThenextchaptercoverstroubleshootingPIMbasedonthetheorycoveredinthischapter.

ReviewQuestions1Whatisthedifferencebetweenunicast,broadcast,andmulticast?2WhatarethedifferentmodesofPIM?3WhatmechanismdoesPIMdensemodeoperateon?4WhatmechanismdoesPIMsparsemodeoperateon?5WhatisthedifferencebetweenIGMPversion1andversion2concerningthegroupleavemechanism?6WhatmulticastaddressdoesIGMPuseforIGMPqueries?7HowdoesRPFcheckwork?8Whatistherendezvouspoint(RP)?

Chapter13.TroubleshootingPIM

ThischapterdiscussesmethodstotroubleshootPIMmulticast.Thischapterisdividedintothreeparts:•IGMPjoinsissues•PIMdensemodeissues•PIMsparsemodeissues

EachpartincludestroubleshootingflowchartsandcasestudiestoanalyzeandtroubleshootcommonPIMmulticastproblems.Chapter12,“UnderstandingProtocolIndependentMulticast(PIM),”discussesthegeneraloperationofPIM,ifyouneedarefresher.FormoredetaileddescriptiononmulticastandPIMprotocol,refertoDevelopingIPMulticastNetworks,Volume1,byBeauWilliamson.

TroubleshootingIGMPJoinsAsdiscussedinChapter12,“UnderstandingProtocolIndependentMulticast(PIM),”IGMPjoinsarealineofcommunicationbetweenthemulticastreceiver(host)andtherouter.IGMPjoinsareusedbythemulticastreceivertoinformthemulticastrouterthathostsonthelocalsegmentareinterestedincertainmulticastgroups;thisallowstheroutertoforwardmulticastpackettothesegment.ThissectiondiscussesissueswithIGMPjoins.RefertoFigure13-1forthetroubleshootingflowchartonIGMPjoinissues.

Figure13-1TroubleshootingFlowchartonIGMPJoinProblems

RefertoFigure13-2fornetworksetupofIGMPjoinproblem.

Figure13-2NetworkDiagramforCaseStudyonIGMPJoinProblem

InFigure13-2,themulticasthostisinterestedinjoiningmulticastgroup225.1.1.1.ThemulticasthostsendstheIGMPjoinstothemulticastaddress224.0.0.2,whichistheallroutersmulticastaddress.TheproblemisthatRouterAisnotseeingtheIGMPjoins.ToseewhichmulticastgroupsarejoinedtotheroutersthroughIGMP,usethecommandshowipigmpgroup.Example13-1showstheshowipigmpgroupcommandoutputforRouterA.Example13-1showipigmpgroupCommandOutputforRouterA

RTR_A#showipigmpgroup

IGMPConnectedGroupMembershipGroupAddressInterfaceUptimeExpiresLastReporterRTR_A#

TheoutputinExample13-1showsthatRouterAisnotseeingtheIGMPjoinsfromthemulticasthost.IfRouterAisnotseeingtheIGMPjoinsfromthemulticasthost,thenextlogicalstepintroubleshootingistoquestionwhetherthemulticasthostissendingoutIGMPjoinsandwhattherouterdidwiththeIGMPjoinpacket.ToseetheIGMPtransactiononarouter,usethedebugipigmpcommand,asdemonstratedinExample13-2forRouterA.Example13-2debugipigmpCommandOutputonRouterA

RTR_A#debugipigmp

IGMP:Receivedv2Reportfrom150.150.2.2(Ethernet0)for225.1.1.1IGMP:Group225.1.1.1accessdeniedonEthernet0

ThedebugoutputshowsthattherouterisreceivingtheIGMPjoinsfromthehost,buttheyarerejectedbytherouter.Example13-3showsRouterA’sconfiguration.Example13-3RouterAConfiguration

RTRA#showrunipmulticast-routinginterfaceethernet0ipaddress150.150.2.1255.255.255.0ippimdense-modeipigmpaccess-group1access-list1deny224.0.0.03.255.255.255

access-list1permitany

TheconfigurationinExample13-3revealsthereasonwhythe225.1.1.1IGMPjoinisgettingrejected—thereisanaccess-groupstatementconfiguredforIGMPoninterfaceEthernet0.Theaccessgroupistiedtoaccess-list1,whichdeniesanygroupjoinsfortherangeof224.0.0.0to227.255.255.255.Thenetworkadministratorwantstodenyonlygroupsfrom224.0.0.0to224.255.255.255,andthisisamisconfigurationontherouter.

SolutiontoIGMPJoinProblemThesolutionforthisIGMPjoinproblemistochangeaccess-list1tomatchthatshowninExample13-4.Example13-4AlterationoftheRouterAConfigurationtoPermitJoiningtheMulticastGroupof225.1.1.1

RTR_A#access-list1deny224.0.0.00.255.255.255access-list1permitany

Withthisnewconfiguration,therouternolongerwillrejecttheIGMPjoinforthe225.1.1.1group.Example13-5showsthedebugonRouterAandtheoutputfromtheshowipigmpgroupcommandafterthechangeshavebeenmade.Example13-5debugipigmpandshowipigmpgroupCommandOutputonRouterA

RTR_A#debugipigmp

IGMP:Receivedv2Reportfrom150.150.2.2(Ethernet0)for225.1.1.1

RTR_A#showipigmpgroup

GroupAddressInterfaceUptimeExpiresLastReporter225.1.1.1Ethernet000:00:4000:02:18150.150.2.2

NowRouterAshowsthe225.1.1.1groupasjoinedinEthernet0withtheIPaddressof150.150.2.2astheIGMPreporter.

TroubleshootingPIMDenseModeMulticastdensemodeoperationisverysimple—itusesthefloodandprunemechanismtoformamulticastforwardingtree.Becauseofthesimplicityinoperation,troubleshootingPIMdensemodeisalsoverysimple.MostofthePIMdensemodeproblemisrelatedtoReverse-PathForwarding(RPF)checkfailureandTimetoLive(TTL)valueproblems.Figure13-3showsthetroubleshootingflowchartformulticastdensemode.

Figure13-3FlowchartforTroubleshootingMulticastDenseModeProblem

ThecasestudythatfollowsdemonstratesatypicalPIMRPFcheckproblem.Figure13-4showsthenetworksetupforsuchacasestudy.

Figure13-4NetworkDiagramforCaseStudyonPIMRPFCheckProblem

Example13-6showsthepertinentconfigurationontheroutersdepictedinFigure13-4.Example13-6MulticastRouterConfiguration

MulticastSource#interfaceethernet0ipaddress172.16.1.1255.255.255.0

RTR_A#ipmulticast-routing

interfaceethernet0ipaddress172.16.1.2255.255.255.0ippimdensemodeinterfaceserial0ipaddress172.16.3.1255.255.255.0interfaceserial1ipaddress172.16.2.1255.255.255.0ippimdensemoderoutereigrp1network172.16.0.0

RTR_B#ipmulticast-routingipmulticast-routinginterfaceethernet0ipaddress172.16.5.1255.255.255.0ippimdensemodeinterfaceserial0ipaddress172.16.3.2255.255.255.0interfaceserial1ipaddress172.16.4.1255.255.255.0ippimdensemoderoutereigrp1network172.16.0.0

RTR_C#ipmulticast-routinginterfaceserial0ipaddress172.16.2.2255.255.255.0ippimdensemodeinterfaceserial1ipaddress172.16.4.2255.255.255.0ippimdensemoderoutereigrp1network172.16.0.0

MulticastReceiver#ipaddress172.16.5.2255.255.255.0

Theproblempresentinthecasestudyisthatthemulticastserverissendingamulticaststreamtothegroup225.1.1.1,butthemulticastreceiverisnotgettingthepacket.Whenaproblemlikethisisfirstpresented,thefirstthingtodoistomakesurethattheTTLofthemulticaststreamfromtheserverismorethan1andthattheTTLvalueismorethanthetotalnumberofhopsinthenetwork.TheTTLvalueissetonthemulticastapplicationintheserverwhensendingthestream.TochecktheTTLvalueofthepacket,asnifferisneededtocapturethemulticastpacketandtolookinsidethepackettodeterminetheTTLvalue.Inthiscasestudy,theTTLvalueofthemulticastserverissetto15hops.Thenextstepintroubleshootingistolookatthemulticastroutingtable.Example13-7showsthepertinentoutputoftheshowipmroutecommandonRouterA.Example13-7showipmrouteCommandOutputforRouterA

RTR_A#showipmroute225.1.1.1

IPMulticastRoutingTable(*,225.1.1.1),Incominginterface:Null,RPFnbr0.0.0.0Outgoinginterfacelist:Ethernet0,Forward/Dense,Serial1,Forward/Dense

(172.16.1.1/32,225.1.1.1),Incominginterface:Ethernet0,RPFnbr0.0.0.0

Outgoinginterfacelist:Serial1,Forward/Dense

FromthemulticastroutingtableforRouterAinExample13-7,youcanseethatRouterAhasreceivedthemulticaststreamfromEthernet0andisforwardingittotheandSerial1interface.TheshowipmroutecountcommandverifiesthatRouterAisindeedforwardingthemulticaststream,asdemonstratedinExample13-8.Example13-8showipmrouteCommandOutput

RTR_A#showipmroute225.1.1.1count

ForwardingCounts:PktCount/Pktsperseconds/AvgPktSize/KilobitspersecondOtherCounts:Total/RPFfailed/Otherdrops(OIF-null,rate-limit,etc)

Group:225.1.1.1,Sourcecount:1,Grouppktcount:29543Source:172.16.1.1/32,forwarding:29543/195/1043/203,other:0/0/0

AstheoutputinExample13-8reveals,RouterAispumpingatotalof29,543packets,at195packetspersecond.showipmroutecountisanimportantshowcommandbecauseitconfirmsthatarouterispassingmulticastpacketsandalsorevealswhetheranymulticastpacketdropsareoccurringbecauseofRPFfailures.FromtheshowcommandoutputinExamples13-7and13-8,RouterAlooksfine.Thenextstepistogotothenexthop,whichisRouterB.Example13-9showstheoutputfromtheshowipmroute225.1.1.1commandonRouterB.Example13-9showipmroute225.1.1.1CommandOutputforRouterB

RTR_B#showipmroute225.1.1.1IPMulticastRoutingTable(*,225.1.1.1),Incominginterface:Null,RPFnbr0.0.0.0Outgoinginterfacelist:Ethernet0,Forward/Dense,Serial0,Forward/Dense,Serial1,Forward/Dense

(172.16.1.1/32,225.1.1.1),Incominginterface:Serial1,RPFnbr172.16.3.1Outgoinginterfacelist:Ethernet0,Forward/Dense

TheoutputinExample13-9revealsthatRouterB’soutgoinginterfaceisEthernet0,whichisintheforwardingstate;however,themulticastreceiverisnotgettinganymulticastpackets.ThereceiverhassenttheIGMPjoinstoRouterB,andRouterBacknowledgesit,asshowninExample13-10.Example13-10RouterB’sConfirmationofIGMPJoins

RTR_B#showipigmpgroupGroupAddressInterfaceUptimeExpiresLastReporter225.1.1.1Ethernet000:00:4000:02:18172.16.5.2

ThenextstepistoseewhetherRouterBissendingthemulticastpacketbyexecutingtheshowipmroute225.1.1.1countcommand,asdemonstratedinExample13-11.Example13-11showipmroute225.1.1.1CommandOutputonRouterB

RTR_B#showipmroute225.1.1.1count

ForwardingCounts:PktCount/Pktsperseconds/AvgPktSize/KilobitspersecondOtherCounts:Total/RPFfailed/Otherdrops(OIF-null,rate-limit,etc)Group:225.1.1.1,Sourcecount:1,Grouppktcount:29543Source:172.16.1.1/32,forwarding:29543/0/0/0,other:29543/29543/0

NoticethatRouterBisnotforwardinganypacketsonitsEthernet0interface.RouterBstillputsEthernet0asinforwardingstatebecausethereisanactivereceiveronEthernet0.TheRPFfailedcounterhasbeenincrementingconstantly.ItappearsthatRouterBisnotforwardingpacketstoEthernet0becauseofRPFcheckfailureproblems.RPFcheckfailuremeansthattheunicastroutingpathisnotcongruouswiththemulticastpath.Toverify,theroutingtableonRouterBtothesourcenetworkof172.16.1.0/24lookslikeExample13-12.Example13-12showiprouteCommandOutputforRouterB

RTR_B#showiproute172.16.1.0255.255.255.0

Routingentryfor172.16.1.0/24Knownvia"EIGRP1",distance90,metric2195456,typeinternalRedistributingviaeigrp1Lastupdatefrom172.16.3.1onSerial0,00:10:30agoRoutingDescriptorBlocks:*172.16.3.1,from172.16.3.1,00:10:30ago,viaSerial0Routemetricis2195456,trafficsharecountis1Totaldelayis21000microseconds,minimumbandwidthis1544KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops1

TheunicastroutingtableonRouterBshowsthatitisusingSerial0asthenexthoptoreachnetwork172.16.1.0/24;however,themulticastpathpointstoSerial1basedontheoutputofshowipmroute225.1.1.1onRouterB.NoticethattheRPFneighborislistedas172.16.3.1,itsunicastpath.SuchdiscrepanciescausetheRPFchecktofail,andtheroutersimplydropsthepacket.

SolutiontoPIMDenseModeProblemLookingattheconfiguration,RouterAandRouterB’sSerial0interfacesarenotenabledfordensemode;however,thisisthecustomer’srequirement.Thecustomerdoesn’twantmulticaststreamstocongesttheWANlinkbetweenRouterAandRouterB,andthecustomeralsowantsthemulticaststreamtoflowinthedirectionofRouterA,RouterC,andthenRouterB.TofixtheRPFproblemandpreservethecustomer’srequirement,youneedtoconfigureastaticmulticastrouteonRouterBsothattheRPFcheckusesthestaticmulticastrouteinsteadoftheunicastroutingtable.Example13-13showthestaticmulticastrouteconfigurationforRouterB.Example13-13StaticMulticastRouteConfigurationforRouterB

RTR_B#ipmroute172.16.1.0255.255.255.0172.16.4.2

Withthisstaticmulticastrouteinplace,theRPFcheckinRouterBsucceedsandthemulticastpacketisforwardedtomulticastreceiverinsteadofbeingdropped.Example13-14showstheoutputfromshowipmroute225.1.1.1andshowipmroute225.1.1.1countonRouterBaftertheconfigurationchange.Example13-14showipmrouteCommandOutputonRouterB

RTR_B#showipmroute225.1.1.1IPMulticastRoutingTable

(*,225.1.1.1),Incominginterface:Null,RPFnbr0.0.0.0Outgoinginterfacelist:Ethernet0,Forward/Dense,Serial0,Forward/Dense,Serial1,Forward/Dense

(172.16.1.1/32,225.1.1.1),Incominginterface:Serial1,RPFnbr172.16.4.2Outgoinginterfacelist:Ethernet0,Forward/Dense

RTR_B#showipmroute225.1.1.1count

ForwardingCounts:PktCount/Pktsperseconds/AvgPktSize/KilobitspersecondOtherCounts:Total/RPFfailed/Otherdrops(OIF-null,rate-limit,etc)

Group:225.1.1.1,Sourcecount:1,Grouppktcount:26721Source:172.16.1.1/32,forwarding:26721/254/1253/318,other:0/0/0

TheoutputinExample13-14revealsthatRouterBisforwardingmulticastpacketsonEthernet0andthatthemulticastreceivernowisreceivingthemulticaststream.

TroubleshootingPIMSparseModePIMsparsemodeoperatesdifferentlythandensemodeandismorecomplex.Thetroubleshootingstepsaresimilartothedensemodecase.Figure13-5showsthetroubleshootingflowchartforthePIMsparsemodeproblem.

Figure13-5FlowchartforTroubleshootingPIMSparseModeProblems

ThecasestudythatfollowsexaminestroubleshootingaPIMsparsemodeprobleminwhichtheleafroutersendsjoinstotheRP.Figure13-6illustratesthenetworkdiagramofthiscasestudy.

Figure13-6NetworkDiagramforCaseStudyonPIMSparseModeProblem

FromFigure13-6,youcanseethatRouterAandRouterBformtheconnectionfromthemulticastservertothereceiver.RouterCisconnectedtoNetworkX,whichisnotdirectlyconnectedtothemulticastserver’snetwork.Themulticastserversendsthemulticaststreamovermulticastgroup225.0.0.1.Example13-15showstheconfigurationfortheroutersinFigure13-6.Thesparse-densemodeconfigurationontheroutersallowstheroutertoruninsparsemodeiftheRPispresent.IfRPisnotavailable,therouterswillrunindensemode.Example13-15RouterMulticastConfiguration

MulticastSource#interfaceethernet0ipaddress172.16.1.1255.255.255.0

RTR_A#ipmulticast-routinginterfaceethernet0ipaddress172.16.1.2255.255.255.0ippimsparse-densemodeinterfaceserial0ipaddress172.16.2.1255.255.255.0ippimsparse-densemoderoutereigrp1network172.16.0.0ippimsend-rp-announceethernet0scope16ippimsend-rp-discoveryscope16

RTR_B#ipmulticast-routinginterfaceethernet0ipaddress172.16.3.1255.255.255.0ippimsparse-densemodeinterfaceserial0ipaddress172.16.2.2255.255.255.0ippimsparse-densemoderoutereigrp1network172.16.0.0

RTR_C#ipmulticast-routinginterfaceethernet0ipaddress172.16.3.3255.255.255.0ippimsparse-densemodeinterfaceserial1ipaddress172.16.4.1255.255.255.0ippimsparse-densemoderoutereigrp1network172.16.0.0

MulticastReceiver#interfaceethernet0ipaddress172.16.3.2255.255.255.0

AstheconfigurationsinExample13-15show,RouterAistherendezvouspoint(RP)forallthemulticastgroups,anditannouncesitsEthernet0addressastheRPaddress.TheotherroutersdiscovertheRPthroughtheauto-rpmechanism.Theauto-RPmechanismeliminatestheneedtomanuallyconfiguretheRPinformationineveryrouterinthenetwork.Theauto-RPmechanismusesIPmulticasttodistributetheRPinformationtoallroutersinthenetwork.ThePIMroutersdiscovertheRPinformationthroughthemulticastaddressof224.0.1.40.Inthiscasestudy,theproblemariseswhenthereceiverattemptstosendthePIMIGMPjointothe224.0.0.2multicastaddress.RouterBandRouterCbothreceivetheIGMPjoin,butRouterBisnotsendingthePIMsparsemodejoinstotheRP.Therefore,noforwardingtreeisformed,andthemulticaststreamisnotforwardedfromtheservertothereceiver.Checkingwiththemulticastserversetup,themulticaststreamhasaTTLvalueof15.IfRouterBisnotsendingthePIMsparsemodejoinstotheRP,thenextstepistofindoutwhetherRouterBisreceivingmulticasttrafficfromRouterA.Todothis,youneedtolookatonlythemulticastroutingtableofRouterA,displayedinExample13-16.Example13-16showipmrouteCommandOutputfromRouterA

RTR_A#showipmroute225.1.1.1IPMulticastRoutingTable(*,225.1.1.1),

Incominginterface:Null,RPFnbr0.0.0.0Outgoinginterfacelist:Ethernet0,Forward/Sparse-Dense,Serial0,Forward/Sparse-Dense,

(172.16.1.1/32,225.1.1.1),Incominginterface:Ethernet0,RPFnbr0.0.0.0

Outgoinginterfacelist:Null

Lookingatthe(S,G)entry,theoutputshowsthattheRouterA’soutgoinginterfacelistisnullforgroup225.1.1.1,indicatingthatnodownstreamroutersareinterestedinreceivingpacketsforthisgroup.AstheshowipigmpgroupcommandoutputforRouterBinExample13-17reveals,however,thereisareceiver172.16.3.2thatalreadyhasjoinedgroup225.1.1.1throughIGMP.Example13-17showipigmpgroupCommandOutputforRouterB

RTR_B#showipigmpgroupGroupAddressInterfaceUptimeExpiresLastReporter225.1.1.1Ethernet000:00:4000:02:18172.16.3.2

ThenextstepistofindoutwhetherthereareanyotherneighborsinRouterB’sEthernetandwhichrouteristhedesignatedrouter(DR)ofthissegment.ItisimportanttodeterminetheDRbecausetheDRistherouterthatisresponsibleforsendingPIMjoinstotheRP.TofindoutwhichrouteristheDR,lookattheoutputgeneratedfromtheshowippimneighborcommand,asdemonstratedinExample13-18forRouterB.Example13-18showippimneighborCommandOutputonRouterB

RTR_B#showippimneighbor

PIMNeighborTableNeighborAddressInterfaceUptimeExpires172.16.3.3Ethernet000:50:2300:01:30(DR)

AstheoutputinExample13-18reveals,RouterB’sEthernetsegmenthasanotherneighborinitwiththeaddressof172.16.3.3(RouterC),andtheneighboristheDRofthesegment.ThenextstepistocheckwhetherRouterChastheRPinformation,asdeterminedfromtheshowippimrpcommandinExample13-19.Example13-19showippimrpCommandOutputonRouterC

RTR_C#showippimrpGroup:225.1.1.1,RP:172.16.1.2,uptime01:34:12,expiresnever

Asthisoutputconfirms,RouterChasRPinformationforgroup225.1.1.1.ThenextstepistodeterminewhetherRouterChasaroutetotheRP.Example13-20showstheresultsfromcheckingRouterC’sroutingtablefortheRPaddressof172.16.1.2.Example13-20showiprouteCommandOutputonRouterC

RTR_C#showIProute172.16.1.2

Routingentryfor172.16.1.0/24Knownvia"EIGRP1",distance90,metric2221056,typeinternal

Redistributingviaeigrp1Lastupdatefrom172.16.3.1onEthernet0,00:17:30agoRoutingDescriptorBlocks:*172.16.3.1,from172.16.3.1,00:17:30ago,viaEthernet0Routemetricis2221056,trafficsharecountis1Totaldelayis22000microseconds,minimumbandwidthis1544KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops2

NoticethattheroutingtableshowsthattherouteisfromtheEthernet0interface,whichistheinterfacethatheardtheIGMPjoins.Becauseofthis,RouterCwillnotsendajointotheRP.

SolutiontoPIMSparseModeProblemTheproblemintheprecedingcasestudyisthatRouterCdoesn’thaveanyotherwayofgettingtotheRPexceptthroughtheinterfacethatreceivestheIGMPjoins.OnesolutionistomakeRouterBtheDRforthesegment.Todothis,RouterBmusthaveahigherIPaddressthanalltheroutersinthesegment.ChangingRouterB’sEthernetaddressto172.16.3.254willensurethatRouterBistheDRforthesegmentandwillsendPIMjoinstotheRP.

SummaryThischapterpresentedyouwithmethodsfortroubleshootingcommonPIMproblems.ThesectionontroubleshootingPIMdensemodepresentedacasestudyofRPFcheckfailure.MostproblemsinPIMstemfromtheRPFcheckfailureproblem.TroubleshootinganRPFfailureproblemrequiresanup-to-datenetworkdiagram,aswellassomescrutinyoftheunicastandmulticastroutingtables.Ifnecessary,turningonmulticastdebuggingwillprovidesomecluestosolvingtheproblem.Whentroubleshootingamulticastproblem,theshowipmroutecommandisthemaintroubleshootingtool.Inmanycases,thenetworkadministratorneedstogohopbyhopthroughthemulticasttreesandlookatthemulticastroutingtableateachhoptocorrectlydeterminethecauseofthemulticastproblem.

Chapter14.UnderstandingBorderGatewayProtocolVersion4(BGP-4)

ThischaptercoversthefollowingkeytopicsaboutBorderGatewayProtocolversion4(BGP-4):•BGP-4protocolspecificationandfunctionality•Neighborrelationships•Advertisingroutes•Synchronization•Receivingroutes•Policycontrol•ScalingIBGPnetworks(routereflectorsandconfederations)•Bestpathcalculation

Anautonomoussystem(AS)isasetofdevicesundercommonadministration.Betweentwoormoreautonomoussystems,theBorderGatewayProtocoladvertisesnetworkreachabilityinformation.TheInternetbackbonereliessolelyonBGPtoannounceandreceiveIPprefixes,andtheonlyroutingprotocolthatrunsbetweentwoautonomoussystemsisBGP.BeforeBGP,exteriorgatewayprotocol(EGP)wastheprotocolusedbetweentwoautonomoussystems.EGPwasobsoletedbyBGP.Whytheneedforanewprotocol?GrowingInternetusageintheearly1990scalledforaprotocolthatcouldprovideclasslessroutingandIPprefixadvertisementwithouttheconceptofnetworkclass.Furthermore,thisprotocolneededtoaggregateIPprefixestoshrinktheInternetroutingtablesizeandrobustlyadvertisealargenumberofroutestootherautonomoussystems.BGPofferedallthatand,amongotherthings,offeredmechanismstocontroltrafficflowinandoutofthenetworksrunningBGP.InInternetserviceprovider(ISP)networkswhererevenuesaregeneratedbysellingInternetaccesstoothersmallISPsortoenterprisecustomers,itiscrucialthattrafficflowsaremanagedproperly.BGPofferedISPsthecapabilitytoconfigurerouterswithnetworkpoliciestomanagetrafficrequirements.ISPsmakethemostuseofBGP.WhetheritiscustomerIPtrafficdestinedtotheInternetorIPtrafficfromtheInternettoacustomernetwork,BGPallowsmanipulationoftrafficpathstomakethebestuseoftheISPnetwork.BeforedelvingintothevariousaspectsofBGP,youneedto(re)familiarizeyourselfwithafewterms:•IPprefix—ThisreferstotheIPsubnetassignedtonetworksbytheofficialgoverningbodythatmanagesIPaddresses.•BGPfeed—ThisisacommonlyusedtermforaBGPsessionthatprovidesreachabilityinformationofIPprefixesontheInternet.Inthiscontext,termssuchasfullfeedandpartialfeedarealsoused.FullfeedreferstoalltheInternetprefixes,whereaspartialfeedreferstoasubsetoftheInternetIPprefixes,basedonthetrafficrequirements.•BGPpeer—BGPpeersandBGPneighborsaretermsthatrefertonetworkdevicesinthesamenetworkthatrunBGP.•RouterID(RID)—Thisisa32-bituniqueidentifierrepresentingaBGPspeaker.InCiscoIOSSoftware,theRIDisthehighestloopbackIPaddress.Whenloopbacksarenotconfigured,thehighestIPaddressoftheinterfacethatisupistakenastheRID.RIDcanalsobemanuallyconfiguredinCiscoIOS.

•Exitpoint—Thisisarouterthatconnectstwoautonomoussystems,andtrafficcomesinandgoesouttoInternetthroughtheexitpoint.Inmostexamples,therewillbemorethanonerouterrunningEBGPforredundancyandforotherrequirements.•SmallandlargeBGPnetworks—Thereisnofixeddefinitionofasmallorlargenetwork.Justoneroutermightexistinthenetwork,orthenetworkmighthaveseveralhundredroutesrunningtheIProutingprotocol.•ExternalBGP(EBGP)—WhenBGPisrunbetweentwoautonomoussystems,suchaBGPsessioniscalledExternalBGP(EBGP).EBGPisprimarilyusedintwodifferentenvironments:—BetweenISPsandtheircustomers—Inthiscase,customerIPprefixesareadvertisedthroughBGPtotheISPandtheISPadvertisesthemtotheInternet.However,ISPmightadvertisefullfeedorpartialfeedoftheBGPtableoftheInternetroutestothecustomer.

—BetweendifferentISPs—Inthiscase,IPprefixesareadvertisedtopeeringISPconnections.ThisishowalltheInternetisgluedtogether.

•InternalBGP(IBGP)—ABGPsessionbetweentworoutersinthesameASiscalledanIBGPsession.Typically,thisisbetweentwoormorerouters.InIPnetworkswheremultipleEBGPpeeringoccursatmultipleexit-pointrouterswiththesameordifferentneighboringAS,itbecomesimperativetomanageIPtrafficcominginandgoingouttothoseneighboringautonomoussystems.IBGPsolvesthisproblembysharingEBGPfeedsbetweentheexit-pointrouters.IBGPcandictatehowtrafficwillexitthenetwork.Forexample,anexit-pointroutercanbeconfiguredinBGPtosendsometraffictothedirectlyconnectedEBGPlinkandthensendtherestofthetraffictotheremoteIBGPneighbor.ThismanagesbandwidthrequirementsofEBGPlinksandotherbackbonelinks.Inessence,IBGPplaysasignificantroleinlargerouter-basednetworkstomanagelinkbandwidthutilization.•Internetexchangepoints(IXP)—IXPprovidesaReal-Stateinwhichmost,ifnotall,ofthebigISPsexchangeBGProuteswitheachother.•BGPpeeringarrangement—InEBGPconnections,thetwoautonomoussystemsmustagreeonthekindofBGPpeering.ThefollowingarethemostpopularkindsusedintheInternettoday:—Transitpeering—SupposethatASAisrunningEBGPwithASB.IfBisconfiguredsothatitwillpassallInternettrafficfromA,BisatransitproviderofA.Typically,BwillprovideafullBGPfeedtoA.

—Publicpeering—AnEBGPsessionatIXPiscalledpublicpeering.—Privatepeering—AnEBGPsessiononaprivatelinkbetweentwoautonomoussystemsiscalledprivatepeering.Itoffloadstrafficfrompublic-peeringlocationsthataretypicallycongested.

•Dualormultihoming—WhenanASrunsmorethanoneEBGPsessionwiththesameordifferentAS,itisconsidereddualormutlihomedtothatAS.Dual-homednetworksmighthavesingleormultipleroutersintheAS.ThisprovidesredundantconnectionstotheInternetandalsoprovidesloadsharing.•BGPpolicies—TheseareBGPrulesdesignedtopredicthowBGPinfluencestraffic-flowpoliciescominginorgoingoutofthenetwork.PoliciesareeitherconfiguredoraretakenfromthedefaultbehaviorofBGPprotocol.•Administrativedistance(AD)—CiscoIOSSoftwareassignsanADtoeachprotocol.ADhaslocalsignificanceintherouterandisnotexchangedwithanyotherrouters.InCiscoIOSSoftware,EBGPandIBGPhaveanADof20and200,respectively.Whenaprefixislearnedbytwodifferentprotocolsinthesamerouter,ADdoesthetiebreakingandthelowerADprefixisinstalledintheIP

routingtable.CiscoIOSSoftwarealsoenablesyoutoreconfigureADvaluesundertheroutingprotocolcommandsetusingthedistancecommand.•BGPbestpath—BydefinitionofRFC1771,BGPmustdecideonasinglebestrouteoutofmanytoinstallintheroutingtable.IfBGPreceivesmultipleadvertisementsfrommultipleneighborsforthesameprefix,itmustdecideonasinglebestroutethroughBGPbestpathselection,discussedlaterinthischapter.ItisthisbestroutethatBGPinstallsintheIProutingtableandadvertisestootherBGPneighbors.•Hotpotato—AcommonlyusedtermforaBGPpolicythatgovernsthattrafficwillexittheASfromtheclosestexit-pointrouter.•Coldpotato—AcommonlyusedtermforaBGPpolicythatgovernsthattrafficwillbedeliveredthroughthepaththatisclosesttothedestination.Optimalroutingcanbeviewedascoldpotatorouting.

Figure14-1showsthatASA,C,andDarerunningEBGPsessionswithASB.RoutersASB—namely,R1,R2,R3,R4,andR5—areshowntorunIBGPwitheachother,andtheyarefullymeshedwitheachother.ASAisdualhomedtoASBforredundancyandloadsharing.ASAhasonehigh-bandwidthlinkandonelow-bandwidthlinktoASB.Inaddition,ASBisprovidingtransitservicestoASC,andASCalsohasaprivatepeeringsessionwithASD.

Figure14-1SampleBGPNetwork

Figure14-1providesasimpleviewofanISPBnetwork.AllsuchISPsconnectwitheachothertoformthisInternet.TheseISPsmightconnectatIXP,ortheymighthaveprivatepeeringwitheachother,likeASCandASDdointhisfigure.Figure14-1showsthatallautonomoussystemsexceptforASCmustgothroughASBtoreachothernetworks.ASCmayuseitsprivatepeeringlinkwithASDforallInternettrafficorsomeothertraffic,

dependingonthekindofBGPfeed(fullorpartial)exchanged.ThekindofBGPfeedfromASDtoASCandlocalBGPpolicyofCdictateshowtrafficgoesoutoftheCnetwork.ThisisoneexampleofBGPpolicy.InanotherexamplefromFigure14-1,ASAisdualhomedwithASBbuthasonehigh-bandwidthlinkandanotherlow-bandwidthlink.ASAmightuseahigh-bandwidthlinktoitsfullcapacityandmightnotuselowbandwidthatall;ASAcanchoosetousealow-bandwidthlinkforsometraffic,andtherestofthetrafficcangoonthebiggerlink.AllthesepoliciesandrequirementscanbeservicedbyBGP,andthatmakesusageofBGPsoimportantandpowerful.

BGP-4ProtocolSpecificationandFunctionalityRFC1771definesthecurrentBorderGatewayProtocol4(BGP-4)implementation.BGPreliesonareliabletransportmechanismtoestablishitsconnectionandforexchanginginformationbetweenBGPpeers.BGPusesTCPport179forthispurposeandbenefitsfromtheTCPprotocoltoofferreliablecommunicationbetweenBGPspeakers.RFC1771describesindetailtherequirementsofBGPneighborrelationships,BGPupdateformat,errornotifications,andhandlingofspecialcases.ProperBGPfunctionalityrequiresproperconfigurationontheroutersandcorrectimplementationoftheprotocolperRFC1771.ThesectionsthatfollowaddresstheseaspectsofBGP:•Neighborrelationships(peering)•Advertisingroutesandtheconceptofsynchronization•Receivingroutes•Bestpathcalculation•Policycontrolthroughthefollowing:

—UseofBGPattributes(LOCAL_PREF,AS_PATH,MULTI_EXIT_DISC(MED),ORIGIN,NEXT_HOP)

—Useofroutemapsinpolicycontrol—Useoffilterlistsinpolicycontrol—Useofdistributelistsinpolicycontrol—Useofcommunitiesinpolicycontrol—Useofprefixlist—Useofoutboundroute-filtering(ORF)capabilityinpolicycontrol—AggregationinBGP

•ScalingIBGPinlargenetworks•Routereflectors•Confederations

NeighborRelationshipsBGPrequiresaneighborrelationshiptobeestablishedbeforeanyinformationisexchangedbetweenBGPspeakers.BGPdoesnotdynamicallydiscoverroutersinterestedinrunningBGP;instead,BGPisconfiguredwithaspecificneighborIPaddress.Likemostotherdynamicprotocols,BGPusesperiodickeepalivemessagestoensureavailabilityofBGPneighbors.Thekeepalivetimerisonethirdoftheholdtime.Ifthreeconsecutivekeepalivemessagesaremissedfrom

aparticularBGPneighbor,theholdtimeexpiresandthatneighborisconsidereddead.InRFC1771,thesuggestedvaluefortheholdtimeis90seconds,andthesuggestedvalueforthekeepalivetimeris30seconds.ThesevaluesarenegotiatedbetweenBGPneighborswhentheneighborsfirstcomeup.RFC1771alsorequiresthat“animplementationofBGPmustallowthesetimerstobeconfigurable.”WhenBGPisconfiguredwithaneighborIPaddress,itgoesthroughaseriesofstagesbeforeitreachesthedesiredEstablishedstateinwhichBGPhasnegotiatedalltherequiredparametersandiswillingtoexchangeBGProutes.BGPgoesthroughthefollowingstagesofneighborrelationship,perRFC1771:1Idle—NoBGPresourcesareallocatedinIdlestate,andnoincomingBGPconnectionsareallowed.2Connect—BGPwaitsforaTCPconnectiontobecompleted.Ifsuccessful,theBGPstatemachinemovesintoOpenSentstateaftersendingtheOPENmessagetothepeer.FailureinthisstatecouldresultineithergoingintoActivestateorConnectstate,orrevertingbacktoIdlestate,dependingonthefailurereasons.

3Active—Inthisstate,aTCPconnectionisinitiatedtoestablishaBGPpeerrelationship.Ifsuccessful,BGPsendsitsOPENmessagetothepeerandmovestoOpenSentstate.FailurecanresultingoingtotheActiveorIdlestates.

4OpenSent—AftersendinganOPENmessagetothepeer,BGPwaitsinthisstatefortheOPENreply.Ifasuccessfulreplycomesin,theBGPstatemovestoOpenConfirmandakeepaliveissenttothepeer.FailurecanresultinsendingtheBGPstatebacktoIdleorActive.

5OpenConfirm—TheBGPstatemachineisonestepawayfromreachingitsfinalstate(Established).BGPwaitsinthisstateforkeepalivesfromthepeer.Ifsuccessful,thestatemovestoEstablished;otherwise,thestatemovesbacktoIdlebasedontheerrors.

6Established—ThisisthestateinwhichBGPcanexchangeinformationbetweenthepeers.Theinformationcanbeupdates,keepalives,ornotification.

Figure14-2highlightsasimpleBGPstatemachinethatrunswhileBGPisinoperation.Somedetailsareleftoutforsimplicity.RefertoRFC1771foramoredetailedexaminationoftheBGPstatemachineoperation.

Figure14-2BGPStateMachine

ExternalBGPNeighborRelationshipsThissectionexplainsasampleconfigurationofEBGPsessions.InFigure14-3,R1andR2belongtodifferentautonomoussystems—109and110,respectively.

Figure14-3ExternalBGPNeighborRelationshipExample

TherearetwowaystoconfigurewhenpeeringEBGP:•Case1—R1andR2arepeeringwithaphysicalinterface.•Case2—R1andR2areindirectlyconnectedortheyarepeeringwitheachother’sloopbackinterfaces.

ThepeeringrelationshipwithR1andR2inCase1meansthattheR1peeringIPaddressisinthesamesubnetasitsownphysicalinterface.Theconfigurationforthiscaseisasfollows:

R1#:routerbgp109neighbor131.108.1.2remote-as110

R1inFigure14-3hasaninterfacewithanIPaddressof131.108.1.1.Figure14-4showstwoscenariosofmultihopEBGPsessionsindicativeofthepeeringrelationshipinCase2.Inthisfigure,EBGPpeeringbetweenR1andR2isdonewitheachother’sloopbackaddresses.Thisistypicallyseenwhenmultipleconnectionsexistbetweenthetwoautonomoussystemsandbothlinksshouldcarrytraffic.EithereachASrunstwoseparateBGPneighborrelationshipsontwoseparatephysicalinterfaces,ortheycanconfigureoneBGPneighbortotheloopbackandconfiguretwostaticroutestoreacheachother’sloopback.ThelattermethodispreferablebecauseitsavesanextraBGPneighborrelationship.

Figure14-4EBGPPeeringRelationshipThroughLoopbackInterfaces

InFigure14-5,R3inAS110mightnotbecapableofrunningBGP,soR1andR2mustpeerwitheachgoingthroughR3.

Figure14-5EBGPPeeringRelationshipThroughaThird-PartyRouter

InbothcasesofFigure14-4andFigure14-5,itisassumedthatallroutershavereachabilitytoR1andR2’sloopbackaddresses.Loopbackaddressesareusedbecausetheyarevirtualinterfacesandtheynevergodownlikephysicalinterfacesdo.Evenifonephysicalinterfacegoesdown,BGPbetweenloopbacksremainsupaslongastheyexistasredundantpathstoeachother’sloopbacks.Example14-1showsasampleconfigurationofR1toconfiguremultihopEBGPsession.Example14-1SampleConfigurationofR1toShowMultihopEBGPSession

R1#:

routerbgp109neighbor131.108.10.2remote-as110neighbor131.108.10.2ebgp-multihop5neighbor131.108.10.2update-sourceLoopback0

ebgp-multihop5meansthatneighbor131.108.10.2canbeonlyfivehopsawayfromR1,andtheTimeToLive(TTL)fieldintheIPheaderissetto5.update-sourceLoopback0meansthatallBGPupdatesaresourcedfromtheLoopback0addressofR1.R2uses131.108.10.1asthenext-hopaddressforallrouteslearnedthroughR1.

InternalBGPNeighborRelationshipsAssumethatR1andR2belongtothesameAS,109,asshowninFigure14-6.

Figure14-6InternalBGPNeighborRelationshipExample

IfR1andR2areIBGPneighbors,meaningthattheyareBGPneighborsinthesameAS,theconfigurationcasescanbeanyofthefollowing:•Case1—R1andR2arepeeringwithaphysicalinterfaceofeachother,andpeeringisdonewiththeIPaddressthatbelongstothesubnetthattheybothshare.TheconfigurationofR1isasfollows:routerbgp109neighbor131.108.1.2remote-as109

•Case2—R1andR2areeitherindirectlyconnectedortheyarepeeringwitheachother’sloopbackinterfaces.TheconfigurationofR1isasfollows:routerbgp109neighbor131.108.10.2remote-as109neighbor131.108.10.2update-sourceLoopback0

NoteTheneighbor131.108.10.2ebgp-multihopcommandisnotneeded.IncasesofIBGP,theTTLintheIPheaderissetto255inCiscoIOSSoftwarebecauseitisassumedthatIBGPneighborsmightnotbephysicallydirectlyconnected.Inaddition,anIBGPneighborrelationshipcanalsobeestablishedbetweenloopbackaddressesthatareconsideredamultihopawayfromeachother.Incaseofaphysicalfailureinthenetwork,IBGPcanusealternatephysicalpaths,iftheyexist,toreachtheloopbackoftheBGPneighbor.Thisway,IBGPremainsintact,eveninthecaseofphysicalfailuresalongtheway.

AdvertisingRoutesABGProutercanadvertiseorreceiveupdatesfromitsBGPpeeronlyifithasachievedtheEstablishedstatewithitsneighbor.ArouterrunningBGPwilladvertiseonlyaprefixtootherneighborsthatitisgoingtouseinitsroutingtable.Suchaprefixiscalledthebestpath(definedlaterinthechapter).Arulesimilartothesplit-horizonworksinBGPaswell.Aprefixlearnedfromaneighborwillnotbeadvertisedbacktothatneighborifthatwasthebestroute.CiscoIOSSoftwareoffersmultiplewaystoadvertiseprefixesinBGP.OnerulethatBGPfollowswhenadvertisingprefixestootherneighborsisthattheprefixbeingadvertisedmustexistintheroutingtableoftheadvertisingrouter.InFigure14-7,R1advertises131.108.1.0/24throughBGPtoitsBGPpeer,R2.

Figure14-7RouteAdvertisement

InCiscoIOSSoftwareBGP,therearethreewaystoadvertisetheprefix:•Usingthenetworkstatement—Aswithotherroutingprotocols,thisisthefirstoption.Thefollowingconfigurationadvertises131.108.1.0/24throughthenetworkstatementinR1:routerbgp109network131.108.1.0mask255.255.255.0

131.108.1.0/24mustexistintheroutingtableofR1;otherwise,131.108.1.0/24willnotbeadvertisedinBGP.Themaskkeywordfollowedbytheactualmaskoftheprefixisneededwhensubnettedroutesarebeingadvertised.•Usingtheredistributecommand—If131.108.1.0/24isaconnectedrouteinR1’sroutingtable,thefollowingconfigurationwilladvertise131.108.1.0/24inBGP:routerbgp109redistributeconnectednoauto-summary

Withthisconfiguration,alltheconnectedroutes,including131.108.1.0/24,areadvertised.Toallowonly131.108.1.0/24toadvertise,BGPmustusethefilteringmechanismexplainedlaterinthischapter.Commandnoauto-summaryisusedbecauseBGPsbydefaultadvertisesredistributedroutestotheirnaturalClassfulmask.Forexample,131.108.1.0/24beingaClassBprefixwouldgoas131.108.0.0/16withoutthiscommand.

•Usingtheaggregatestatement—Prefixesareaggregatedorsummarizedtoreducethenumberofprefixannouncementsandreducethesizeoftheroutingtable.TheCiscoIOSSoftwareaggregatefeatureinBGPannouncessummarizedroutes.Ifmorespecificroutesof131.108.1.0/24arepresentintheBGPtable—forexample,131.108.1.128/26—thefollowingconfigurationadvertises131.108.1.0/24inBGP:R1#:routerbgp109aggregate-address131.108.1.0255.255.255.0

YouneedtounderstandtwoimportantrulesforthesetupshowninFigure14-8:•Rule1—AggregationorsummarizationofsubnetscanhappenonlyifthosesubnetexistinBGPtable.•Rule2—Fortheaggregated(summarized)route,CiscoIOSinstallsanIProutewiththenexthoptoNull0intheIProutingtable.ThisisdonetoinsurethatavalidrouteexistsintheroutingtabletoannouceittootherBGPpeers.

Figure14-8DemonstratingtheRulesforAggregatedRoutes/SummarizedSubnets

AsFigure14-8illustrates,perRule1,R1has131.108.1.128/25and131.108.1.192/26initsBGPtable,butitisconfiguredtoadvertise131.108.1.0/24toR2.ForRule2,whentheaggregate-addresscommandisused,CiscoIOSSoftwareautomaticallyinstalls131.108.1.0/24withanext-hopinterfaceofNULL0initsroutingtable.TheoutputinExample14-2illustratesthatR1isconfiguredtoadvertise131.108.1.128/25and131.108.1.192/26.R1isalsogeneratinganaggregateof131.108.1.0/24.ThefirstportiondisplaystheBGPtabletoshowthatallthreeroutes,includingtheaggregate,areintheBGPtable.ThesecondportionshowsthedetaileddisplayoftheaggregatedrouteinR1.ThethirdportionindicatesthatCiscoIOSSoftwareautomaticallyinstallsaNull0routefortheaggregatestatement.Example14-2ConfigurationandOutputforSetupinFigure14-8

R1#:routerbgp1

network131.108.1.192mask255.255.255.192network131.108.1.128mask255.255.255.128aggregate-address131.108.1.0255.255.255.0

R1#showipbgpBGPtableversionis5,localrouterIDis1.1.1.1Statuscodes:ssuppressed,ddamped,hhistory,*valid,>best,i-internalOrigincodes:i-IGP,e-EGP,?-incomplete

NetworkNextHopMetricLocPrfWeightPath

*>131.108.1.0/240.0.0.032768i*>131.108.1.128/250.0.0.0032768i*>131.108.1.192/260.0.0.0032768i

R1#showipbgp131.108.1.0255.255.255.0BGProutingtableentryfor131.108.1.0/24,version3Paths:(1available,best#1,tableDefault-IP-Routing-Table)

Local,(aggregatedby11.1.1.1)0.0.0.0from0.0.0.0(1.1.1.1)OriginIGP,localpref100,weight32768,valid,aggregated,local,atomic-aggregate,best

R1#showiproute131.108.1.0Routingentryfor131.108.1.0/25Knownvia"static",distance1,metric0(connected)RoutingDescriptorBlocks:*directlyconnected,viaNull0Routemetricis0,trafficsharecountis1

Null0isabitbucketandwillnotcauseanyharmforthedatatrafficbecausedatatrafficisswitchedbasedonmorespecific25and26routes,notthis/24NULL0route.Withtheaggregate-addresscommandinCiscoIOSSoftware,BGPadvertisestheaggregateandthesubnettedroutesaswell.CiscoIOSallowsaknobinconfigurationthatwillsuppressthesesubnettedroutes;onlytheaggregatedprefixwillbeannounced:

R1#routerbgp1aggregate-address131.108.1.0255.255.255.0summary-only

SynchronizationRuleThisruleinRFC1771statesthattheIGProutingtablemustbesynchronizedwiththeIBGProutingtable.ThiscanhappenonlyifEBGP-learnedroutesareredistributedinIGP(OSPF)astheASBR.Thepotentialofblack-holingtrafficexistsifIGPisnotsynchronizedwithIBGP-learnedroutes.Figure14-9showshowsynchronizationrulecanblack-holetraffic.R2,R3,andR4areinAS110runningIBGPandalsoOSPF.R1inAS109advertisesprefix131.108.1.0/24throughEBGPtoR2,whichadvertisesthisprefixtoR3andR4;andR4advertisestoitsEBGPneighborR5.

Figure14-9NetworkTrafficSusceptibletoBlack-Holing

AssumethatalltheroutersexceptR3haveprocessedthisBGPupdateandhaveinstalledtheroutefor131.108.1.0/24intheirroutingtables.IfsourcesbehindR5startsendingtrafficto131.108.1.0/24,packetsarriveatR4,andtheR4routingtablemightreportthatthenexthoptoreach131.108.1.0/24isthroughR3.Asaresult,datatrafficarrivesatR3andisdroppedbecauseR3isstillprocessingtheupdateanddoesnothavetheroutetoreach131.108.1.0/24.Thisiscalledtransientblack-holingoftraffic.Overtime,R3willhavetherouteandwillbecapableofpassingtrafficfor131.108.1.0/24.BytheRFC1771synchronizationrule,R5shouldhavewaiteduntilitsIGP(OSPF)wouldhavealsoreceivedtheroutefor131.108.1.0/24;thenitcouldhaveadvertisedtheroutetoexternalpeerR5toattracttraffic.AnnouncingallEBGProutesinIGPrequiresmanualredistributionatASBR(R1)inthisexample.R1mustredistribute131.108.1.0/24inOSPFsothatallroutersinAS110definitelyreceivetheprefix.However,withthesizeofInternetroutingtablestoday,itisnotpossibleorscalabletoredistributeafullInternetfeedintoIGP.Therefore,allBGPspeakersrunningCiscoIOSSoftwareturnoffsynchronizationusingthefollowingcommand:

R2#routerbgp110noSysnchronization

Transientblack-holingcanstillhappen,butbyturningoffsynchronization,IGPisnotrequiredtocarryfullBGProutes.IncaseswheresomeroutersarenotrunningBGPandtheyareintransitpathoftheIBGPneighbor,synchronizationcannotbeturnedoffandBGPmustberedistributedintheIGP.

ReceivingRoutesInBGP,iftheBGPpeerisintheEstablishedstate,noadditionalconfigurationisneededtoreceiveroutingupdates.BGPwillacceptalltheupdatesfromthepeer,providedthatthoseupdatespassthenecessarychecksforpacketformatandfilters.

PolicyControl

PolicycontrolmeansthatBGPprovidespowertocontrolprefixfilteringandmanageIPtrafficflowintoandoutoftheBGPnetwork.BGPpoliciescanflowdownstreamandaffectpolicyofthoseautonomoussystemstowhichroutesarebeingpropagated.InalargeBGPnetworkthatisdividedintomultipleregions,specialrequirementsmustbemetintermsofwhattypeandhowmuchtrafficcanflowinandoutofeachregion.BGPpolicycontrolgivesnetworkoperatorsahighlyscalablewayofmaintainingtrafficflows.BGPpoliciesaredefinedbyBGPattributesthatconsistofthefollowing:•LOCAL_PREF•AS_PATH•MULTI_EXIT_DISC(MED)•ORIGIN•NEXT_HOP•ATOMIC_AGGREGATE•AGGREGATOR

Typically,ATOMIC_AGGREGATEandAGGREGATORarenotusedindefiningandconfiguringBGPpoliciesinroutersandthereforewillnotbediscussedindetailinthischapter.Theremainingattributeswillbeillustratedandexplainedindetailinthischapter.Theroutingtableofarouterdictateshowtrafficdestinedtoacertaindestinationexitsthatrouter.Ifthefocusoftrafficflowisshiftedtoaregionwheremanyroutersarepresent,theroutingpolicydepictedintheroutingtablesofeachrouterdictateshowtrafficexitsthatregion.Similarly,alltheregionscombinedcanbeviewedasacompleteIPnetwork.Routingpolicydepictedinroutingtablesofallthedevicesinthenetworkreflectshowtrafficexitsoutthenetwork.Figure14-10showshownetworktrafficflowsacrossmultipleregionsandthroughmultipleroutersbasedontheBGPpolicydefinedtoinfluencethepaththatdatatraffictakesfromsourcetodestination.

Figure14-10NetworkDesignedtoTakeAdvantageofBGPRoutingPolicies

SingleBGPASisdividedintomultipleregions.Trafficflowsfromsourcetodestination,crossingmultipleregionsbasedontheBGPpolicydefined.InFigure14-10,itseemsmorelogicalthattrafficfromsourcetodestinationtravelsRegion1,Region2,andRegion3,andthentothefinaldestinationbecausethatseemstobetheshortestpathfromsourcetodestination.Region2,however,isconfiguredwithaBGPpolicythatshiftstrafficfromRegion2toRegion4instead.Networkarchitectsdesignanddecideonsuchpolicieswhentraffictakesalongerpath.Factorssuchasbandwidthavailability,congestion,routercapacity,andmanyothersplayasignificantroleinthedefinitionofthesepolicies.HowisaBGPpolicycreated?ManipulationofBGPattributesdefinesBGPpolicies.PacketforwardinginarouterhappensfromtheroutingtableandBGPpolicydictateswhichrouteofmanyischosentogointheroutingtable.Figure14-11illustratesasimpleexampleofpolicycontrolinthecaseofEBGP.

Figure14-11BGPPolicyControlExample

AS109networkadministratorsrequireaBGPpolicysothat,asshowninFigure14-11,trafficdestinedto131.108.1.0/24fromAS109mustusetheR1–R3link.TheR1–R2linkshouldbeusedasabackup.ThiscanhappenonlyifroutingtablesinallthedevicesofAS109showR1–R3astheexitpointandifthepaththroughR2ispresentintheBGPtableandnotinroutingtableofR1.ThemethodofchoosingonepathovertheotherisaccomplishedbymanipulatingtherightBGPattribute.InFigure14-11,R1learnstwopathstoreach131.108.1.0/24—onethroughR2andtheotherthroughR3.R1mustpickthepaththroughR3becauseoftherequiredBGPpolicy,andBGPattributesmustbechangedsothatthepathfromR3becomesmoreattractivethanthepathfromR2.Whenthathappens,IPtraffic(afterfollowingtheroutingtable)flowsfromalldevicesinAS109toexitthroughR3toreach131.108.1.0/24.ThefollowingsectionsexplainusingtheBGPattributesandthemethodsofchangingthemtodefineBGPpolicies.

PolicyControlUsingBGPAttributesBGPpicksabestpathforadestinationIPprefixfrommultiplepathsandtheninstallsitintheroutingtable.ThisbestpathforwardsIPtraffic.Bydefault,BGPdoesadecentjobofchoosingtheappropriatepath;however,withthehugesizeofrouter-basednetworks,itisessentialthatBGPpathselectionbemanagedbynetworkoperatorstohaveaBGPpolicythatoptimallyusesthenetwork.BGPattributesareoftenmanipulatedtomanageBGPnetworks.ExamplesofmostcommonlyusedBGPattributesarelistedhere:•LOCAL_PREF•AS_PATH•MULTI_EXIT_DISC(MED)•ORIGIN•NEXT_HOP•WEIGHT(WEIGHTisnotaBGPattribute—itisaCiscoproprietaryattribute)

ThesectionsthatfollowdescribetheseBGPattributesingreaterdetailanddescribehowtomanipulatethemforBGPpolicycontrol,whereapplicable.

LOCAL_PREFAttribute

A32-bitnon-negativeintegervalueofLOCAL_PREFinBGPupdatesdefinesapreferenceofoneexitpointwithinanASoverotherstoreachtheoriginatoroftheroute.LOCAL_PREFhasnosignificanceoutsideanAS;therefore,itaffectsonlytheoutgoingtrafficfromanAS.LOCAL_PREFisnotadvertisedtoEBGPneighborsandispropagatedtoonlyIBGPneighbors.Figure14-12explainshowLOCAL_PREFishandledinnetworksrunningBGP.

Figure14-12LOCAL_PREFAttributeOperationinBGPNetworks

R1inAS109isadvertising131.108.1.0/24toitsEBGPneighborsR2andR3inAS110.BGPupdatessenttoEBGPneighborsdonotcontainLOCAL_PREF.InCiscoIOSSoftware,LOCAL_PREFisgivenadefaultvalueof100foralltheprefixeslearnedfromEBGPneighbors.CiscoIOSSoftwarealsoallowstheusertoconfigureLOCAL_PREF,asshownlaterinthischapter.AsFigure14-12shows,becausethelinkbetweenR1andR2isbiggerthanthelinkfromR1toR3,itislikelydesiredthattrafficfromAS110toAS109usetheR1–R2linkratherthantheR1–R3link.Therefore,R2isconfiguredsothatitchangestheLOCAL_PREFto200foralltheprefixesthatitlearnedfromR1.BecauseLOCAL_PREFisadvertisedtoallIBGPneighbors,R3,R4,andR5receive131.108.1.0/24withaLOCAL_PREFof200fromR2.R3hasanadditionalpathfor131.108.1.0/24fromR1,anditsLOCAL_PREFwasunchangedandisdefaultedto100.Now,R3mustdecidebetweentwopathsfor131.108.1.0/24,onefromR1andtheotherfromR2.AsexplainedlaterinthediscussionofbestpathcalculationofBGP,thepathwiththehigherLOCAL_PREFwins;therefore,thepathfromR2willwinandgetinstalledintheroutingtableforR3.Similarly,R4andR5willchooseR2toreach131.108.1.0/24.InFigure14-12,R4andR5arereceivingonlyonepathfor131.108.1.0/24,andthatisfromR2.IftheywerereceivingmultiplepathsfrommultipleIBGPneighbors,theywouldhavedecidedonthebestpathbasedonahigherLOCAL_PREF,justlikeR3did.WhenR6inAS111issendingtrafficfor131.108.1.1,itexitsAS110fromR2becauseAS110has

preferredR2asanexitpointfor131.108.1.0/24.Figure14-12explainsthatLOCAL_PREFplaysasignificantroleinmanagingoutgoingtrafficfromAS109todestinationsoutsideAS109.Example14-3showstheconfigurationneededtomanipulatetheLOCAL_PREFattributeinR2,asillustratedinFigure14-12.Example14-3ConfiguringtheLOCAL_PREFAttribute

R2#routerbgp110neighbor1.1.1.1remote-as109neighbor1.1.1.1route-mapSET_LOCAL_PREFin

route-mapSET_LOCAL_PREFpermit10matchipaddress1setlocal-preference200

route-mapSET_LOCAL_PREFpermit20matchipaddress2access-list1permit131.108.1.0


TheIPaddressofR1inAS109is1.1.1.1.SET_LOCAL_PREFistheroutemapthatisappliedonanEBGPsessionwithR1.TheroutemapusageisdefinedindetailinChapter1,“UnderstandingIPRouting.”Thefirstsequenceoftheroutemaphasamatchstatementagainstaccess-list1thatpermits131.108.1.0/24.ThesetcommandconfigurestheLOCAL_PREFto200forprefixesthatpassaccess-list1.ThesecondsequenceoftheroutemapisnecessarytoallowallotherprefixesfromthisneighborwithoutchangingtheLOCAL_PREF.AfterthisconfigurationinR2,theoutputoftheBGPtableforprefix131.108.1.0/24fromR2andR3lookslikeExample14-4.Example14-4BGPOutputofthePrefix131.108.1.0/24AfterLOCAL_PREFChange

R2#showipbgp131.108.1.0BGProutingtableentryfor131.108.1.0/24,version8Paths:(1available,best#1)Advertisedtononpeer-grouppeers:1.1.8.31091.1.7.1from1.1.7.1(10.1.1.1)OriginIGP,metric0,localpref200,valid,external,best

R3#showipbgp131.108.1.0BGProutingtableentryfor131.108.1.0/24,version8Paths:(2available,best#1)Notadvertisedtoanypeer1091.1.7.1(metric307200)from1.1.8.2(10.0.0.5)OriginIGP,metric0,localpref200,valid,internal,best1091.1.2.1from1.1.2.1(10.1.1.1)OriginIGP,metric0,localpref100,valid,external

R3hastwoupdates,onefromR1andtheotherfromR2.ThepathfromR2isselectedasthebestpathbecauseofthehigherLOCAL_PREF.

MULTI_EXIT_DISC(MED)Attribute

A32-bitnon-negativeintegervalueofMEDinBGPupdatesdefinesamethodtochooseamongmultipleexitpointsinthesameneighboringAS.MEDisanontransitiveattributeofBGP;therefore,ifitisreceivedfromanEBGPneighbor,itissenttoanIBGPneighbor,butitdoesnotgetpropagatedtootherEBGPneighbors.Figure14-13explainstheusageofMED.InAS109,RIhastwolinkstoAS110.ThelinkbetweenR1andR2hasahigherbandwidththanthelinkbetweenR1andR3.Therefore,R1mightdecidethatalltrafficdestinedto131.108.1.0/24mustexitAS110throughtheR1–R2link,nottheR1–R3link.

Figure14-13MULTI_EXIT_DISC(MED)AttributeOperationinBGPNetworks

AlowerMEDvalueispreferredwhencomparingthetwoupdates.InCiscoIOSSoftware,MEDiscomparedonlybetweenupdatesfromwithinthesameAS.TocompareMEDvaluesinupdatesfromdifferentautonomoussystems,CiscoIOSSoftwaremustbeconfiguredwithbgpalways-compare-medinBGPsubcommands.TheAS109policydictatesthatalltrafficdestinedfor131.108.1.0/24shouldcomethroughtheR1–R2linkandthattheR1–R3linkshouldbeusedasabackupincasetheR1–R2linkgoesdown.Toachievethis,R1advertises131.108.1.0/24tobothneighborsinR2andR3inAS110.However,R1shouldadvertisealowerMEDvaluetoR2thantoR3.Example14-5showsasampleconfigurationofR1toachievethegoal.Example14-5ConfiguringtheMEDAttribute

R1#routerbgp109neighbor1.1.7.2remote-as110neighbor1.1.7.2route-mapSEND_LOWER_MEDout

neighbor1.1.2.3remote-as110neighbor1.1.2.3route-mapSEND_HIGHER_MEDout

route-mapSEND_LOWER_MEDpermit10matchipaddress1setmetric10!route-mapSEND_LOWER_MEDpermit20matchipaddress2

route-mapSEND_HIGHER_MEDpermit10matchipaddress1setmetric20!route-mapSEND_HIGHER_MEDpermit20matchipaddress2

access-list1permit131.108.1.0access-list2permitany

1.1.7.2and1.1.2.3aretwoneighborsofR1.TheyarebothconfiguredwithroutemapstoadvertiseaMEDof10and20,respectively,fortheprefix131.108.1.0/24.Thisoccursinsequence10oftheroutemap.Sequence20permitsallotherprefixes,ifany,advertisedfromR1toR2andR3,andnoMEDchangeswereappliedtothem.Example14-6showstheoutputofR3andR2afterthisconfigurationchangeinR1.Example14-6OutputofBGPTablefromR3andR2AftertheMEDAdvertisementfromR1

R3#showipbgp131.108.1.0BGProutingtableentryfor131.108.1.0/24,version10Paths:(2available,best#2)Notadvertisedtoanypeer1091.1.2.1from1.1.2.1(10.1.1.1)OriginIGP,metric20,localpref100,valid,external1091.1.7.1from1.1.8.2(10.0.0.5)OriginIGP,metric10,localpref100,valid,internal,best


Withthisconfiguration,theprefix131.108.1.0/24MEDfieldlookslikethefollowinginR2andR3:InR2,MED=10forthepathfromR1.InR3,MED=10forthepathfromR2;MED=20forthepathfromR1.

R2hasonlyonepathfor131.108.1.0/24,whereasR3hastwo.ThisisbecauseR2isadvertisingitsbestroutetoallitsIBGPneighbors(R3,R4,andR5,inthisexample).R3’sbestpathfor131.108.1.0/24isfromR2,soR3willnotadvertiseitsbestpathbacktoR2becausethatpathoriginallycamefromR2.BecausethelowerMEDwinsinBGPbestpathcalculation,inR3,thepathfromR2winsoverthepathfromR1.Thus,alltrafficfromautonomoussystem110for131.108.1.0/24willexitthroughR2.

MEDisanontransitiveattributeandwillnotbeadvertisedtoAS111byAS110.R5andR6mightconfiguretoadvertisethesameordifferentMEDtoR6inAS111,buttheMEDvalueoriginallysetbyR1inAS109willnotbekept.BecauseoftheBGPMEDpolicyofR1,trafficfromR6inAS111to131.108.1.1inAS109willexitfromR2,notfromR3inAS110.TheMEDattributeplaysasignificantroleininfluencingincomingtrafficincasemultipleconnectionsexistbetweenthesameAS.TheexampleinFigure14-13ismostcommonlyseeninenterpriseBGPnetworkswhereroutersinAS109aredualhomedtoanISPinAS110.InCiscoIOSSoftware,MEDiscomparedonlybetweenupdatesfromwithinthesameAS.InExample14-5,R3comparedMEDsbecause131.108.1.0/24camefromthesameAS109.TocompareMEDvaluesinupdatesfromdifferentautonomoussystems,CiscoIOSSoftwaremustbeconfiguredwithbgpalways-compare-medinBGPsubcommands.Figure14-14showsamorecomplexexample,asseeninISPnetworksadvertisingMEDtootherISP.

Figure14-14MULTI_EXIT_DISC(MED)AttributeOperationBetweenISPs

AS109hastworegionalconnections,eastandwest,withAS110.AS109needstomakesurethatregionaltrafficdestinedtoAS109regionsmustenterthroughtheirrespectiveregionallinks.Thiscanbeaccomplishedbydefiningthefollowing:•AS109mustadvertisetheproperMEDs,asshowninFigure14-14.•AS110musthonorAS109MEDannouncements.

Thefirsttaskisachievedthroughtheconfigurationshownlaterinthischapter.ThesecondtaskismoreofapeeringagreementbetweenAS109andAS110.HonoringMEDmeansthatAS110mustaccepttheMEDannouncementsfromAS109andwillnotoverwritethemwithitsownpolicies.HonoringMEDistypicallyatwo-wayrelationship:AS110honorsAS109MEDonlyifAS109doesthesameforAS110MED.ByhonoringtheMED,AS110carriestrafficdestinedtoAS109throughitsbackboneandexitsattheclosestpointinAS109.IfAS110decidesnottohonorAS109MED,itwillhaveitsownpoliciestocarrytrafficforAS109.Insteadofanoptimalexitpoint,AS110mightchoosetheclosestexitpoint.Figure14-15showshowtrafficflowsinAS110whenithonorstheMEDfromAS109.

Figure14-15MULTI_EXIT_DISC(MED)AttributeOperationBetweenISPs

TrafficsourcingbehindR2destinedfor140.1.1.1willtraverseAS110backboneroutersbecausetheyhaveallreceivedtheproperMEDannouncementfromAS109astheMEDispropagatedwithintheIBGPcloud.ThistrafficexitsAS110atR5,theexitpointclosesttothedestination,141.1.1.1.Similarly,trafficbehindR4destinedfor131.108.1.1exitsatR3.Insomesituations,ISPsdonothonoreachother’sMEDs.Inthiscase,AS110mightdumpalltrafficdestinedtoAS109toitsclosestexitpointandnotcarryitstrafficthroughthebackbone.Suchanexamplecanarisewhentrafficdestinedto140.1.1.1fromsourcesbehindR2carriesovertoR3andexitstoR1;AS109mustcarrythattrafficacrossitsbackbonetoreachR6intheeastregion.ProperusageoftheMEDattributecanalsobecalledcoldpotatorouting(definedearlierinthechapter).

AS_PATHAttribute

TheAS_PATHattributedefinesthelistofautonomoussystemsthroughwhichaBGPupdatehastraversed.ItisamandatoryattributethatBGPupdatesmustcarry,anditischangedonlywhenaBGPupdateissenttoanEBGPneighbor.Figure14-16explainshowtheAS_PATHattributeworks.

Figure14-16AS_PATHAttributeOperationinBGPNetworks

AS109isadvertising131.108.1.0/24toitsEBGPneighborinAS110.TheBGPspeakermustprependitsASnumberattheleft-mostpositionintheAS_PATHattributefield,whilesendinganupdatetoitsEBGPneighbor.R1prependsitsASnumber109inthatfield.R2advertisesthisupdatetoitsIBGPspeakersR3andR4butdoesnotchangetheAS_PATH.R3andR4prependtheirAS110whenadvertisingthisprefixtoAS111.WhenarouterreceivesaBGPupdatethathasanAS_PATHattributethatlistsitsownASinit,thatupdateisconsideredloopedandisdropped.ThismechanismisusedinBGPtodetectroutingloops.AsmallerAS_PATHlengthispreferredwhencomparingthetwoBGPupdates.ReferbacktothenetworktopologyinFigure14-13.AS109wantstodefineaBGPpolicysothatalltrafficdestinedto131.108.1.0/24fromAS110mustenterthroughtheR2–R1link,andtheR3–R1linkshouldbeusedasabackup.VisualizingthatinR2,R3,andR4(allinAS110),theAS_PATHfieldfortheprefix131.108.1.0/24is109.R3hastwopathsforthisprefix,onefromR1andtheotherfromR2.ThebestpathcalculationrulewilltiebecausetheAS_PATHlengthisidentical,at1.BGPBestpathcalculationmovesdowntonexttie-breakingcriteria,perthebestpathcalculationruledescribedinthischapter.Example14-7demonstrateshowR1canachieveitsgoalofpreferringtheR1–R2linkovertheR1–R3linkfortrafficdestinedto131.108.1.0/24/.OneapproachistouseMEDssothatR1advertisesalowerMEDwhenadvertisingprefix131.108.1.0/24toR2andadvertisesahigherMEDtoR3.AnotherapproachistomaketheAS_PATHlengthlongerfortheadvertisementfromR1toR3forthisprefix.BecausetheBGPbestpathcalculation

rulelooksatAS_PATHlengthasthetie-breakerrulebetweenmultiplepaths,theR1–R3pathwillloseandtheR1–R2pathwillwinandbeinstalledintheroutingtable.Example14-7showstheconfigurationneededinR1toachievethis.Example14-7UsingtheAS_PATHAttributeonR1toDictatetheBestPath

R1#routerbgp109

network131.108.1.0mask255.255.255.0neighbor1.1.2.3remote-as110neighbor1.1.2.3route-mapAS_PREPENDoutneighbor1.1.7.2remote-as110

route-mapAS_PREPENDpermit10matchipaddress1setas-pathprepend109109!route-mapAS_PREPENDpermit20matchipaddress2access-list1permit131.108.1.0access-list2permitany

1.1.2.3istheR3IPaddress,androute-mapAS_PREPENDisconfiguredinR1forR3toincreasethelengthoftheAS_PATHattributebyprependingAS109twiceinthelist.route-mapAS_PREPENDsequence10hasamatchclausethatmakessurethatonly131.108.1.0/24getsthisprependedAS_PATH,andsequence20ensuresthattherestoftheprefixesfromR1toR3remainunchanged.Accesslists1and2aredefinedtoachievethat.Afterthisconfiguration,R3hastwoupdatesforprefix131.108.1.0/24,onefromR2andanotherfromR1withtheprependedAS_PATH.R2justhasasingleupdatefromR1.Example14-8showstheoutputforR3andR2.Example14-8showipbgpOutputfromR3andR2AfterAS_PATHManipulationinR1

R3#showipbgp131.108.1.0BGProutingtableentryfor131.108.1.0/24,version5Paths:(2available,best#2)Notadvertisedtoanypeer1091091091.1.2.1from1.1.2.1(10.1.1.1)OriginIGP,metric0,localpref100,valid,external1091.1.7.1from1.1.8.2(10.0.0.5)OriginIGP,metric0,localpref100,valid,internal,best


Forprefix131.108.1.0/24,theAS_PATHfieldlookslikethefollowinginR2andR3:

InR2,AS_PATH=109forpathfromR2InR3,AS_PATH=109109109forpathfromR1;AS_PATH=109forpathfromR2

BecauseinR3theAS_PATHlengthofanupdatefromR1is(3)andfromR2is(1),R3picksthepathfromR2overthepathfromR1.Thisway,alltrafficfromAS110destinedfor131.108.1.0/24inAS109wouldexitthroughR2.R2hasonlyonepathfor131.108.1.0/24,whereasR3hastwo.ThisisbecauseR2isadvertisingitsbestroutetoallitsIBGPneighbors(R3,R4,andR5,inthisexample).R3’sbestpathfor131.108.1.0/24isfromR2,soR3doesnotadvertiseitsbestpathbacktoR2becauseitoriginallycamefromR2.TheAS_PATHprependtechniquetoinfluenceincomingtrafficisusedincaseswhenAS110doesnothonorMEDsfromAS109,orwhenAS109isdualhomedtodifferentISPs.Typically,EnterpriseBGPnetworksusetheAS_PATHprependtechniquewiththeirISPsbecausethenumberofprefixesthattheyadvertisearesmallandcanbeeasilymanaged,asshowedinExample14-7.InISPnetworksinwhichthenumberofprefixesisinthemagnitudeofthousands,managingAS_PATHperprefixdoesnotscalewell;therefore,ISPsrelyonLOCAL_PREF,MED,andWEIGHTtomanagetheirtraffic.ISPmightuseAS_PATHprependinpacketstosolvetemporaryproblemsbuttypicallydoesnotdeploythisasastandard,widelyusedpolicy.ByobservingtheAS_PATH,aBGPspeakercanfindoutwhichASoriginatedtheprefixandhowmanyautonomoussystemsthisprefixhastraversed.Theright-mostASistheoriginatoroftheprefixandtheleft-mostistheneighboringASthathasannouncedtheprefix.ThemiddleautonomoussystemsintheAS_PATHaretheintermediateautonomoussystemsthattheprefixhastraversed.SuchanorderofAS_PATHiscalledanAS_SEQUENCE,inwhichAS_PATHsequenceisintheorderthatithasmaintained.AnotherformofAS_PATHattribute,AS_SET,canbeexplainedifAS110aggregatesrouteslearnedfromAS109andotherautonomoussystemsandannouncesaprefixthatcontainsallthelistingsofautonomoussystems,buttheorderofAS_PATHisnotmaintained.Forexample,AS110isaggregating131.108.1.0/24and131.108.2.0/24to131.108.8.0/26andadvertisedtoAS111.The/24swerelearnedfromAS109andAS108.AS110mightchoosetoconfigureAS_PATHasAS_SET.SuchanAS_PATHmightlooklikethis:

AS_PATH=110{108109}

TheorderofAS108andAS109isnotpreserved.AS_SEQUENCEisthedefaultbehaviorofBGP,whereasAS_SETisaconfigurableoptioninCiscoIOSSoftware.NEXT_HOPAttribute

TheIPaddressoftheborderroutershouldbeusedasanexthoptoreachprefixespropagatedbythatborderrouter.ThiscouldbeanIPaddressthatbelongsinthesameASoritcouldbeanexternalIPaddressthatsharesthesamesubnetasthatonaborderrouter.NEXT_HOPistypicallylearnedthroughanInteriorGatewayProtocol(IGP),suchasOSPForIS-IS,andthecosttoreachtheNEXT_HOPoftenplaysanimportantruleincalculatingthebestpath.ReferringbacktoFigure14-16,inAS110,theNEXT_HOPfor131.108.1.0/24istheIPaddressoftheR1subnetthatconnectstoR2.TheNEXT_HOPattributeisnotchangedthroughouttheAS.CiscoIOSallowstheusertochangetheNEXT_HOPtobetheIPaddressofaninternalborderrouterinsteadofanexternaladdress,suchasLoopbackofR2.ThisisdonebyusingtheneighborIBGP-Neighbor-IP-addressnext-hop-selfcommandinBGP.BychangingNEXT_HOPfromanexternaladdresstotheloopback,routerscarryonelesssubnetintheroutingtable.BecauseloopbackIPaddressesarecarriedin

IGP,noadditionalworkisneededtopropagatetheNEXT_HOP.ORIGINAttribute

TheoriginatoroftheBGPupdategeneratestheORIGINattributeanddefineshowtheoriginalpathwasoriginated.EachprefixhasanORIGINattribute.Routers,whichreceiveupdateswiththeORIGINattribute,shouldforwardtheORIGINattributetoallBGPneighborsunchanged.Table14-1describesthemeaningofthedifferentORIGINattributecodesandexplainshowtheseprefixeswereoriginated.

Table14-1ORIGINAttributeCodes

WEIGHT:CiscoSystems,Inc.ProprietaryAttribute

WEIGHTisa4-byteintegernumberandisnotaBGPattributebecauseitisnotdefinedinRFC1771.ItisaCiscoSystems,Inc.proprietaryattributethathaspriorityoverallotherBGPattributeswhendoingthebestpathcalculationinCiscoIOSSoftware.WEIGHTisnotsharedwithanyBGPneighborbecauseithaslocalsignificanceintherouterandbecausetheneighboringroutermightnotunderstandCisco’sproprietaryattribute.BecauseWEIGHThaslocalsignificanceintherouter,itdoesnotaffectneighboringrouters’BGPpolicy,asinthecaseofLOCAL_PREFandMEDthatgetssharedamongotherroutersintheAS,andalltheASisaffectedwhenusingthoseattributes.Figure14-17explainstheuseofWEIGHT.AS109hasthreeexitpointsandconnectstothreedifferentISPs.AS109haslow-bandwidthlinksinitsCore,sothereforeAS109wouldliketohaveBGPpolicythatmakesminimaluseoftheCore.ThiscanhappenifeachexitrouterchoosesalltheprefixesfromitscorrespondingconnectedISPasthebestroute.InCiscoIOSSoftware,ifR1,R2,andR3assignWEIGHTtoalltheprefixeslearnedfromISP1,ISP2,andISP3,respectively,R1,R2,andR3chooseISP1,ISP2,andISP3,respectively,forallInternetroutes.TrafficoriginatedfromthesourceconnectedtoR1alwaysexitsthroughISP1,asshowninFigure14-17.Thisway,thecoreofAS109nevercarriesanyInternettrafficunlessaBGPsessionwithanISPfailsanywhere.

Figure14-17UsageWEIGHTtoAvoidUsingtheIBGPCore

SuchBGPpolicyisalsocalledhotPotatorouting,asdefinedintheintroductoryportionofthechapter.ReferringbacktothenetworktopologyinFigure14-13,AS110decidedonaBGPpolicystatingthatR3shoulduseR3–R1linktoreach131.108.1.0/24advertisedbyR1.AnypolicychangeinR2(LOCAL_PREFandsoforth)shouldnotaffectR3policy.TheeasiestwaytoaccomplishthisistoassignWEIGHTinR3ontheprefix131.108.1.0/24receivedfromR1.Example14-9showstheconfigurationneededinR3toassignWEIGHT.Example14-9SampleConfigurationofR3toAssignWEIGHT

R3#routerbgp110nosynchronizationneighbor1.1.2.1remote-as109neighbor1.1.2.1route-mapSET_WEIGHTinneighbor1.1.8.2remote-as110

route-mapSET_WEIGHTpermit10matchipaddress1setweight2000!route-mapSET_WEIGHTpermit20matchipaddress2


1.1.2.1istheIPaddressofR1inAS109.SET_WEIGHTistheroutemapthatisappliedonanEBGPsessionwithR1.TheroutemapusageisdefinedindetailinChapter1.Thefirstsequenceofroute-map10hasamatchstatementagainstaccess-list1,whichpermits131.108.1.0/24.ThesetcommandconfigurestheWEIGHTto2000forprefixesthatpassaccess-list1.ThesecondsequenceoftheroutemapisnecessarytoallowallotherprefixesfromthisneighborwithoutchangingtheWEIGHT.Example14-10showstheoutputfromR3aftersettingtheWEIGHT.Example14-10WEIGHTAssignmentShowninBGPOutput

R3#showipbgp131.108.1.0BGProutingtableentryfor131.108.1.0/24,version11Paths:(2available,best#1)Advertisedtononpeer-grouppeers:1.1.8.21091.1.2.1from1.1.2.1(10.1.1.1)OriginIGP,metric20,localpref100,weight2000,valid,external,best1091.1.7.1from1.1.8.2(10.0.0.5)OriginIGP,metric10,localpref100,valid,internal

R3hastwopathsfor131.108.1.0/24,onefromR1andtheotherfromR2.EventhoughthepathfromR2hasaMEDof10,R3prefersthepathfromR1becauseoftheWEIGHTassignment.Inbestpathcalculation,WEIGHThasthehighestpriorityoverallotherattributes.WithWEIGHT,R3usestheR1–R3linkfortrafficdestinedto131.108.1.0/24fromR3.TherestofAS110followsBGPpolicydefinedinotherrouterstodeterminethepathtoreach131.108.1.0/24.ReadingBGPAttributesfromCiscoIOSSoftwareOutput

ThissectiondemonstrateshowBGPattributesarereadfromtheoutputsofshowcommandsintheCiscoIOSSoftware.Example14-11showsthesampleoutputofaBGPprefixreceivedfromanEBGPpeer.Example14-11isfromroute-server.cerf.net.Example14-11BGPUpdatefromanEBGPPeer

showipbgp3.0.0.0174070180192.41.177.69from192.41.177.69(134.24.127.131)OriginIGP,metric20,localpref100,valid,external,best

Table14-2liststheBGPattributesshowninExample14-11.Table14-2ExplanationofBGPAttributesinExample14-11

http://route-server.cerf.net

AS_PATH,[174070180],meansthatprefix3.0.0.0wasadvertisedbyAS80.ThenitwasadvertisedtoAS701,and,from701,itcameto1740andwasgiventotheASwherethisoutputisdisplayed.AS_PATHshowstheASthisprefixhastraversed.LOCAL_PREF100meansthatnoLOCAL_PREFERENCEwassentintheupdateorLOCAL_PREFissetto100onthisrouter.CiscoIOSSoftwareusesapredefinedLOCAL_PREFof100foramissingLOCAL_PREF.AMEDof20meansthatneighbor192.41.177.69configureditsBGPpolicytosendtheMEDof20.Example14-12showssampleoutputofaBGPprefixreceivedfromanIBGPpeer.Example14-12isfromMAE-WestLookingGlassofInterMedia.Example14-12BGPUpdatefromanIBGPPeer

showipbgp198.133.219.011094.24.7.77(metric90200)from165.117.1.127(165.117.1.127)OriginIGP,metric40,localpref100,valid,internal,bestCommunity:1:10002548:1832548:2342548:6663706:153

Table14-3liststheBGPattributesshowninExample14-12.Table14-3ExplanationofBGPAttributesinExample14-12

AS_PATH[1109]meansthatprefix198.133.219.0wasadvertisedbyAS109.ThenitwasadvertisedtoAS1andwasgiventotheASwherethisoutputisdisplayed.AS_PATHshowstheautonomoussystemsthisprefixhastraversed.LOCAL_PREF100meansthatnoLOCAL_PREFERENCEwassentintheUPDATE.CiscoIOSusesapredefinedLOCAL_PREFof100foramissingLOCAL_PREF.AMEDof40meansthateithertheIBGPneighbor165.117.1.127ortheEBGPneighbor4.24.7.77of165.117.1.127configureditsBGPpolicytosendtheMEDof40.Laterinthischapter,communitiesarediscussed.

UseofRouteMapsinPolicyControlRoutemapsareusedextensivelyinBGPwhenitcomestomanagingpolicies.Theroutemapmightcontainmatchandsetstatements.Thematchstatementmatchesaspecificvalue,suchasanIPprefix.ThesetstatementchangesBGPattributes.Theroutemapfeatureismainlyusedwithoneofthefollowingstatements:aggregate,neighbor,network,orredistribute.Example14-13demonstratesasampleroutemap.Example14-13SampleRouteMapUsedforPolicyControl

routerbgp2neighborAremote-as1neighborAroute-maptestoutroute-maptestpermit10matchipaddress1setmetric20!route-maptestpermit20matchipaddress2


Thematchipaddress1statementexaminesaccesslist1,whichallowsonlytheprefix131.108.1.0/24to

gotothesetmetric20command.Theremainingprefixesgothroughwithoutanyadditionalmodificationintheroute-maptestpermit20statement,whichexaminesaccess-list2,whichpermitsallprefixesandsetsnoattribute.ThefollowingsectionsexplainanddemonstratethemostcommonmatchandsetstatementinroutemapswhenusedwithBGP.

UsingthematchipaddressCommandinaRouteMap

Viewthedifferentoptionsavailableforthematchipaddresscommandbyenteringthefollowing:matchipaddress?1-199IPaccess-listnumber1300-2699IPaccess-listnumber(expandedrange)WORDIPaccess-listnameprefix-listMatchentriesofprefix-lists

Example14-14demonstratesapplyingthematchipaddressstatementtoaroutemap.Example14-14UsingthematchipaddressStatementinaRouteMap

route-maptestpermit10matchipaddress1

access-list1permit131.108.1.0

UsingthematchcommunityCommandinaRouteMap

Whenprefixescontaincommunities,youshouldusearoutemapwiththematchcommunitycommandtoexaminetheprefixthathasthecommunitiesconfigured.Viewthedifferentoptionsavailableforthematchcommunitycommandbyenteringthefollowing:

matchcommunity?1-99Community-listnumber(standard)100-199Community-listnumber(extended)exact-matchDoexactmatchingofcommunities

Example14-15demonstratesapplyingthematchcommunitystatementtoaroutemap.Example14-15UsingthematchcommunityStatementinaRouteMap

route-maptestpermit10matchcommunity1

ipcommunity-list1permit1:1

matchcommunity1meansthatitwillexaminecommunity-listfilter1,whichpermitsprefixesthathavecommunity1:1configured.Later,thischapterdescribescommunitiesindepth.

Usingthematchas-pathCommandinaRouteMap

TheAS_PATHattributeintheBGPtableisviewedasatextstring;therefore,UNIX-likeregularexpressionscanexaminethebeginning,end,ormiddlecontentofthestring.AS_PATHfiltersarecommonlyusedonInternetroutersrunningBGP.Insteadoflistingeachprefixinanaccesslist,youcanconfigureCiscoIOSSoftwaretomatchagainstalltheprefixesthatcameinfromAS109.Similarly,AS_PATHfiltercanbeconfiguredtopassonlyprefixesthathaveanAS_PATHequalto109.Viewthedifferentoptionsavailableforthematchas-pathcommandbyenteringthefollowing:

matchas-path?

1-199ASpathaccess-list

Example14-16demonstratesapplyingthematchas-pathstatementtoaroutemap.Example14-16Usingthematchas-pathStatementinaRouteMap

route-maptestpermit10matchas-path1

ipas-pathaccess-list1permit^109$

Here,as-pathaccess-list1permitsallprefixesthathavetheAS_PATHfieldequalto109.Allotherprefixesaredenied.Usageofregularexpressionispowerfulandcomplex.YouareencouragedtoreadtheCiscoIOSSoftwaredocumentationbeforeusingregularexpressionsinyouraccesslists.Table14-4explainssomecommonlyusedregularexpressionsandtheirusage.

Table14-4CommonRegularExpressionsinAccessLists

Earlier,setcommandswereusedtomanipulateBGPattributes.Thissectionshowsafewmoreexamplesoftheuseofthesetcommand.setcommandsmayormaynotbeusedwithamatchstatementintheroutemap.Whensetisusedwithmatchstatements,onlyprefixesthatpassthematchstatementareappliedwithsetcommands.Asetcommandwithoutamatchmeansanunconditionalsetforalltheprefixes.

Usingthesetas-pathprependCommandinaRouteMap

setas-pathprependisusedwhentheAS_PATHattributeischanged.ThiscommandprependstheASnumber(s)listedintheSETcommand.UsageofAS_PATHprependsisdiscussedindetailearlier.Viewthedifferentoptionsavailableforthesetas-pathprependcommandbyenteringthefollowing:

setas-pathprepend?1-65535ASnumber

UsingthesetcommunityCommandinaRouteMap

Communitiesareassignedtoprefixesusingthesetcommunitycommandintheroutemap.Amatchstatementbeforesetcommunityassignscommunitiesonlytoprefixesthatpassthematch.Withoutthematchstatement,allprefixeswillbeassignedwithcommunitiesconfigured.Viewthedifferentoptionsavailableforthesetcommunitycommandbyenteringthefollowing:

setcommunity?1-4294967295communitynumberaa:nncommunitynumberinaa:nnformatadditiveAddtotheexistingcommunitylocal-ASDonotsendoutsidelocalAS(well-knowncommunity)no-advertiseDonotadvertisetoanypeer(well-knowncommunity)no-exportDonotexporttonextAS(well-knowncommunity)noneNocommunityattribute

Usingthesetlocal-preferenceCommandinaRouteMap

Viewthedifferentoptionsavailableforthesetlocal-preferencecommandbyenteringthefollowing:setlocal-preference?0-4294967295Preferencevalue

UsingthesetmetricCommandinaRouteMap

Viewthedifferentoptionsavailableforthesetmetriccommandbyenteringthefollowing:setmetric?+/-metricAddorsubtractmetric0-4294967295MetricvalueorBandwidthinKbitspersecond

UsingthesetweightCommandinaRouteMap

Viewthedifferentoptionsavailableforthesetweightcommandbyenteringthefollowing:setweight?0-4294967295Weightvalue

PolicyControlUsingfilter-list,distribute-list,prefix-list,Communities,andOutboundRouteFiltering(ORF)CiscoIOSSoftwareofferspowerfulconfigurationtoolsformanagingadvertisingandreceivingprefixesinBGP.NetworkoperatorsrunningBGPmusthaveconfigurationoptionstofilterwhatcomesinandwhatgoesoutinBGPupdatesfromtheirnetwork.ThefollowingsectionsdiscussthecapabilitiesofferedbyCiscoIOSSoftwaretocontrolBGPprefixesinascalablemannerbyusingfilterlists,distributelists,prefixlists,communities,andORF.UseofFilterListsinPolicyControl

FilterlistspermitordenyBGPupdatesbasedontheAS_PATHattribute.Filterlistsareusedpertheneighborstatementinbound,outbound,orboth.Example14-17demonstratesconfiguringafilterlistforpolicycontrol.Example14-17ConfiguringaFilterList

routerbgp110neighbor131.108.10.1remote-as109neighbor131.108.10.1filter-list1inipas-pathaccess-list1permit^109$

Theipas-pathstatementusesUNIX-likeregularexpressions,anditisexaminedagainsttheAS_PATHattributeintheBGPupdate.

Inthisexample,allincomingupdatesfromneighbor131.108.10.1areexaminedagainstas-path1,whichisconfiguredtopermitupdateswiththeAS_PATHattributeequalto109.AS_PATHfiltersarescalablebecause,forexample,^109$coversalltheprefixesandavoidsanotherwiselengthyaccesslist,whichwouldinvolvelistingalltheprefixes.UseofDistributeListsinPolicyControl

Likefilterlists,distributelistsareusedperneighborstatementinbound,outbound,orboth.TheyoperateonIPaccesslists.Indistributelists,prefixesarepermittedordeniedbasedonthenetworkslistedintheaccesslist.Example14-18makesuseofstandardIPaccesslist1usedwithadistributelist.Instandardaccesslists,aroutermakesthefilteringdecisionbasedontheprefixnetwork,notbasedonitsmask.Extendedaccesslistsenablenotonlynetworkfiltering,butalsofilteringbasedonthemaskoftheprefix.Example14-18UsingDistributeListsinaStandardIPAccessList

R2#routerbgp110neighbor131.108.10.1remote-as109neighbor131.108.10.1distribute-list1in

access-list1permit131.108.1.00.0.0.255

Example14-18usesstandardIPaccess-list1withadistributelistconfiguredforneighbor131.108.10.1inbound.AllprefixesthatthisneighboradvertisestoR2arecheckedagainstaccess-list1,whichpermitsnetwork131.108.1.0.Thisnetworkcouldhaveamaskof24,25,andsoonbecausethestandardaccesslistoffersnocheckingforamask.Example14-19makesuseofextendedIPaccesslists.Example14-19UsingDistributeListsinanExtendedIPAccessList

routerbgp110neighbor131.108.10.1remote-as109neighbor131.108.10.1distribute-list101in

access-list101permitip131.108.1.00.0.0.0255.255.255.00.0.0.0

Instandardaccesslists(1to99),thewildcardmaskcanbeappliedonlyontheprefix,notonitsmask,whereas,inextendedaccesslists,thesubnetmaskoftheBGPupdatealsocanbecheckedagainsttheaccesslist.WhenusedinBGPforfilteringasinthisexample,thesyntaxofextendedaccesslistshasadifferentmeaning.Extendedaccesslists,whenusedininterfacepacketfiltering,haveasourceaddressportionandadestinationaddressportion.WhenextendedaccesslistsareusedwithBGPdistributelists,thesourceaddressportionisthenetworknumberandthedestinationportionisthemaskofthatnetwork.Therefore,foraccess-list101,whenusedinBGP,thedistributelistcanalsobereadasfollows:

permitIPPrefixwildcard-for-prefixMask_ofthe_prefixwildcard-for-maskaccess-list101inExample14-19permits131.108.1.0onlywiththemaskof255.255.255.0.RefertoChapter1ortheCiscoIOSSoftwaredocumentationforamorein-depthexplanationofstandardandextendedaccesslists.UseofPrefixListsinPolicyControl

Prefixlistsreplacedistributelistsbecausetheyofferuser-friendlyconfigurationoptionswhenfilteringbasedonIPprefixes.Insteadofwritingdifficultprefixwildcardandmaskwildcardcombinationsinanextendedaccesslistappliedinadistributelist,prefixlistsuseaconfigurationthatiseasytoreadandcomprehend.Example14-20showsasampleconfigurationsubstitutionfortheconfigurationinExample14-19,butitusesaprefixlistinsteadofadistributelist.Example14-19hadaccess-list101thatpermitted131.108.1.0/24only.Example14-20usesprefix-listtoachievethat.Example14-20SampleConfigurationtoShowHowPrefixListsWork

R2#:routerbgp110neighbor131.108.10.1remote-as109neighbor131.108.10.1prefix-listFILTER1in

ipprefix-listFILTER1seq1permit131.108.1.0/24

NotePrefix-listalsohasanimplicitdenyattheend,likedistribute-listandAS_PATHlist.

InExample14-20,FILTER1isthenameoftheprefixlistthatisappliedontheneighbor131.108.10.1onalltheincomingBGPupdates.prefix-listFILTER1operationwillbedoneinsequentialascendingorder;thesmallestsequencenumberwillbeexaminedfirst.seq1permits131.108.1.0/24.Theprefixlistcertainlyoffersasimpler,yetpowerful,methodtoachievewhatdistributelistsonceoffered.UseofCommunitiesinPolicyControl

RFC1997definestheBGPCOMMUNITIESattribute,whichdescribesacommunityas“agroupofdestinationswhichsharesomecommonproperty.”Acommunityisa32-bitnumberthatisassignedtoaprefixbyconfigurationandthatispropagatedtoallneighborsinaBGPupdate.Aprefixcanbeassignedwithmultiplecommunities,withamaximumof255differentcommunitiesperprefix.BGPoperatorscangroupnetworksintocommunities.Forexample,allnetworksintheeastregionofaninternetworkareassignedacommunity,andthenetworksinthewestregionofaninternetworkareassignedadifferentcommunity.Thus,communitynumbersactasatagforeachprefix.BylookingatthecommunityinBGPoutput,itbecomeseasytodistinguisheastregionprefixesfromwestregionprefixes.CommunitiescanberepresentedintwowaysinCiscoIOSSoftware.Conventionalstyleisaplain32-bitnumber;newerstyleusestheformatAS:nn,whereASistheautonomoussystemandnnisa2-bytenumber.Thenewerformatcanbeusedafteripbgpnew-formatunderthebgpsubcommand.Figure14-18showshowsetsofprefixesaregroupedincertaincommunities.BGPattributemanipulationisoftendoneonaper-communitybasis.

Figure14-18NetworktoShowHowPrefixesAreGroupedintoCommunitiesforEasierOperationintheReceiver

InFigure14-18,AS109and110areconfiguredwithEBGP.InAS109,131.108.1.0/24and131.108.2.0/24belongtocommunity109:1,and131.108.3.0/24and131.108.4.0/24belongtocommunity109:2.Example14-21showsasampleconfigurationinR1,whichassignscommunities.AssumethatR1canoriginate131.108.1.0/24,131.108.2.0/24,131.108.3.0/24,and131.108.4.0/24.Example14-21SampleConfigurationtoAssignCommunitiesperPrefix

R1#routerbgp109network131.108.1.0mask255.255.255.0network131.108.2.0mask255.255.255.0network131.108.3.0mask255.255.255.0network131.108.4.0mask255.255.255.0neighbor131.108.6.2remote-as110neighbor131.108.6.2send-communityneighbor131.108.6.2route-mapSET_COMMUNITYout

ipbgp-communitynew-format

access-list1permit131.108.2.0access-list1permit131.108.1.0access-list2permit131.108.4.0access-list2permit131.108.3.0

route-mapSET_COMMUNITYpermit10matchipaddress1setcommunity109:1!route-mapSET_COMMUNITYpermit20matchipaddress2setcommunity109:2

R1hasconfiguredroute-mapSET_COMMUNITYandappliedittoneighbor131.108.6.2foralltheoutboundBGPupdatesthatR1advertisestoR2.route-mapSET_COMMUNITYhasamatchclauseineachsequencethatmatchesagainsttheaccesslist.Iftheprefixispermittedintheaccesslist,itisassignedacommunitybasedonwhichaccesslistitispermittedby.InExample14-21,131.108.2.0/24ispermittedbyaccess-list1,soitwillbeassignedwithcommunity109:1.Similarly,131.108.4.0/24getscommunity109:2.R2receivestheseupdateswithcommunitiesandmightbeconfiguredtoassignLOCAL_PREFbasedonthecommunities.R2mightassignLOCAL_PREFbasedonindividualprefix,butitwouldbedifficulttomanageifthenumberofprefixesgrowstoseveralthousand.Example14-22showsthesampleconfigurationofR2,whichassignsaLOCAL_PREFvalueof200forprefixesthatbelongtocommunity109:1,andassignsaLOCAL_PREFvalueof50forprefixesthatbelongtocommunity109:2.Example14-22SampleConfigurationtoShowCommunityFilterUsageinConfiguringBGPPolicy

R2#routerbgp110neighbor131.108.6.1remote-as109neighbor131.108.6.1route-mapSET_LOCAL_PREFinneighbor131.108.6.1send-community

ipbgp-communitynew-formatipcommunity-list1permit109:1

ipcommunity-list2permit109:2

route-mapSET_LOCAL_PREFpermit10matchcommunity1setlocal-preference200!route-mapSET_LOCAL_PREFpermit20matchcommunity2setlocal-preference50

Routemapsareconfiguredtomatchagainstcommunitylistfilters1and2thatlookforthesecommunitiesinBGPupdates.Ifthecommunityisfoundintheupdate,thesetoperationisperformed.Example14-23showstheBGPtableforR2.Allprefixesthatbelongtocommunity109:1areassignedaLOCAL_PREFvalueof200.Prefixeswithcommunity109:2areassignedaLOCAL_PREFvalueof50.Example14-23RouterR2BGPTableReflectsLOCAL_PREFAssignmentAlongwithCommunities

R2#showipbgp131.108.1.0BGProutingtableentryfor131.108.1.0/24,version4Paths:(1available,best#1,tableDefault-IP-Routing-Table)Notadvertisedtoanypeer109131.108.6.1from131.108.6.1(131.108.10.1)OriginIGP,metric0,localpref200,valid,external,bestCommunity:109:1

R2#showipbgp131.108.3.0BGProutingtableentryfor131.108.3.0/24,version2Paths:(1available,best#1,tableDefault-IP-Routing-Table)Notadvertisedtoanypeer109

131.108.6.1from131.108.6.1(131.108.10.1)OriginIGP,metric0,localpref50,valid,external,bestCommunity:109:2

TheLOCAL_PREFassignmentandcommunityislistedforeachprefix.CommunityusagegivesascalablewaytomanagetheBGPprefixinalargeBGPnetwork.BGPpoliciescanbeconfiguredbasedonasinglecommunitynumberthatmightrepresentthousandsofprefixes.Forexample,RouterR1intheeastregionofalargenetworkwantstoassignLOCAL_PREFof200toallprefixesofwestregionroutes.Ifwestregionroutersassignacertaincommunitynumbertoalltheirprefixeswhenadvertisingtotheeastregion,RouterR1willsimplyassignLOCAL_PREFinaroutemapbymatchingagainstacommunitythateastregionhasset.RouterR1couldhavemadeahugeaccesslisttopermiteachprefixandaccomplishthesameresult,but,usingcommunitymatching,R1accomplisheditinascalablefashion.NotonlyarecommunitiesusedinBGPpolicycontrol,buttheyalsoaidintroubleshootingBGPnetworkproblems.CustomerBGPprefixescanbeassignedwithdistinctanddifferentcommunitiesfrompeeringISPprefixes.Ifacustomerprefixishavinganissue,justlookingatthedistinctcommunitycanisolatecustomerprefixes,andtroubleshootingcanbedonefaster.SuchbenefitsmakecommunityusagecommoninBGPnetworks.UseofOutboundRouteFilteringinPolicyControl

Thedocumentdraft-chen-bgp-prefix-orf-00.txtdefinesthefunctionalityofexchangingprefixlist-basedoutboundroutefilter(ORF)capability.WhenconfiguredwithORF,onerouterpushesitsinboundprefixlisttoORF-capableBGPneighbors.Uponreceipt,thepushedprefixlistisautomaticallyconfiguredastheoutboundprefixlist.Typically,whenroutersmustdenycertainprefixesfromotherrouters,theyusefilterlists,distributelists,prefixlists,andsoonasinboundfilters.Thereceiverdeniestheprefixafterthesenderhassentthatprefix.ORFoffersadynamicwayinwhichthereceiveradvertisesitsinboundfiltertothesender;thesendertheninstallsthatfilteronitsoutboundneighborrelationshiptothereceiver.Whenaneighborrelationshipisformedbetweentworouters,theyexchangeORFcapabilitythatverifieswhetherbothroutersareORF-capable.OnlywhenbothagreecantheORFfeaturebeused.Figure14-19showshowBGPspeakersmakeuseofORF.TheboldnumbersindicatethesequenceofeventsinORF,definedinthelistfollowingthefigure.

Figure14-19OutboundRouteFilter(ORF)Operations

1R2inAS110isadvertisingprefixes131.108.2.0/24and131.108.3.0/24toR1inAS109.2R1’sgoalistodeny131.108.2.0/24andaccepteverythingelsethatcomesfromR2.ThisisdonethroughaprefixlistnamedABC,asshownintheExample14-24configuration.

3R1advertisesitsinboundprefixlistABCtoR2throughtheORFmechanism.4R2installsprefixlistABCasanoutboundfilterforneighborR1.

InFigure14-19,R2isoriginating131.108.2.0/24and131.108.3.0/24.R1wantstodeny131.108.2.0/24andreceiveeverythingelse.WithoutORF,R1mustconfigureaninboundprefixlistthatwilldeny131.108.2.0/24.WithoutORF,thisisachievedattheexpenseofreceivingtheupdateandthenfilteringit,thuswastinglotsofresources,suchasCPUprocessinginR2toadvertisetheprefixes,linkbandwidthtocarrytheupdatesthatwillbedroppedatR1,andCPUprocessinginR1tofilterthoseupdates.ORFsendsaninboundprefixlistfiltertotheneighbor.Afterreceivingthisprefixlist,theneighborappliesitasanoutboundprefixlist.Allupdatesthenmustpassbytheprefixlist,savingextracomputationatthereceiver.Example14-24showshowR1cansenditsinboundprefixlistABCtoR2.Example14-24SampleConfigurationtoShowHowORFCanBeUsed

R1:routerbgp109bgplog-neighbor-changesneighbor131.108.6.2remote-as110neighbor131.108.6.2ebgp-multihop2neighbor131.108.6.2capabilityorfprefix-listbothneighbor131.108.6.2prefix-listABCin!

ipprefix-listABCseq5deny131.108.2.0/24

ipprefix-listABCseq10permit0.0.0.0/0le32

R1#clearipbgp131.108.6.2inprefix-filter


NetworkNextHopMetricLocPrfWeightPath*>131.108.3.0/24131.108.6.200110I

Theneighbor131.108.6.2capabilityorfprefix-filterbothenablesORFcapabilityinR1withtheBGPneighbor,andthiscapabilityindicatesthattheR1iswillingtoacceptorsendaprefixlistwiththeneighborR2.Theneighbor131.108.6.2prefix-listABCincommandmeansthatR1hasconfiguredaninboundprefixlistABCforR2,whichsimplydenies131.108.2.0/24andpermitsallotherprefixes.Theclearipbgp131.108.6.2inprefix-filterinR1pushesitsinboundprefixlistfiltertoR2.TheshowipbgpcommandshowsthatR1isonlyreceiving131.108.3.0/24asR2hasacceptedprefix-listABCthatdenies131.108.2.0/24.Example14-25showsthenecessaryconfigurationofR2toaccepttheORFfromR1configuredinExample14-24.Example14-25SampleConfigurationofR2toAcceptORFfromR1

R2:

routerbgp110network131.108.2.0mask255.255.255.0network131.108.3.0mask255.255.255.0neighbor131.108.6.1remote-as109neighbor131.108.6.1ebgp-multihop2neighbor131.108.6.1capabilityorfprefix-listboth


NetworkNextHopMetricLocPrfWeightPath*>131.108.2.0/240.0.0.0032768i*>131.108.3.0/240.0.0.0032768I

R2#showipbgpneighbors131.108.6.1receivedprefix-filterAddressfamily:IPv4Unicastipprefix-list131.108.6.1:2entriesseq5deny131.108.2.0/24seq10permit0.0.0.0/0le32

Theneighbor131.108.6.1capabilityorfprefix-listbothcommandenablesORFcapabilityinR2withtheBGPneighbor,andthiscapabilityindicatesthattheR2iswillingtoacceptorsendaprefixlistwiththeneighborR1.ThetwoshowcommandsinR2indicatethatR2isadvertisingthetwoprefixesandR2hasreceivedthe

prefixlistfromR1thatdenies131.108.2.0/24andpermitseverythingelse.WhenR2acceptstheprefix-listABC,itinstallsitasanoutboundprefix-list,resultingindenialof131.108.2.0/24andpermitting131.108.3.0/24.R2hastheoptiontooverwritereceivedprefix-filterwithitsown.ORFisapowerfulmechanismtoinstallinboundprefixlistsontheremoteend,thusavoidingunnecessaryroutingupdatesonthelinkandsavingreceiverCPUtimetoprocessthoseupdatesanddenythem.

RouteDampeningRoutedampeningisthefeaturethatreducespropagationofflappingroutesintheInternet.RouteflappingoccurswhenIProutesareremovedandputbackinaroutingtable.Thiscanbebecauseofphysicallayerfailure,routingprotocolfailure,orrouternodefailure,andsoon.WhentheseflapsareannouncedthroughBGPtotheInternet,allofInternetroutersrunningBGPareaffected,astheyhavetoremoveandinstallsuchflappingroutes.InanunstableinternalnetworkwhereIProutescontinuouslyflaps,thisinstabilityispropagatedthroughBGPthroughouttheInternet.Routedampeningisthefeaturethatminimizesthisinstabilitybyassigningapenaltytosuchflappingroutes.Whenthepenaltyreachesapredefinedlimit(suppresslimit),thatrouteisremovedfromtheroutingtableandisnotadvertisedtoInternet.Whentheroutestopsflapping,thepenaltydecreasesexponentially.Whenthepenaltyisreducedtoapredefinedlimit(reuselimit),thatrouteisinstalledagainandpropagatedthroughBGP.Someoftherulesanddefinitionsregardingroutedampeningareasfollows:•CiscoIOSSoftwareapplication—RoutedampeningappliestoEBGPneighborsonly.•Flappenalty—Eachflapreceivesapenaltyof1000.Apenaltyisassignedonlywhenroutesarewithdrawnandnotwhentheyarere-advertised.•Suppresslimit—Arouteissuppressedandremovedfromtheroutingtableifthepenaltyexceedsthislimit.Thedefaultsuppresslimitis2000.•Halflifetime—Every5sec,apenaltyisexponentiallyreducedsuchthatinhalflifethepenaltywillbereducedtohalfofitsvalue.DefaultHalfLifeTimeis15minutes.•Reuselimit—Withexponentialreductionofpenalty,apenaltywillreachitsreuselimitatwhichtheroutewillnolongerbesuppressedandwillbeinstalledandadvertisedtootherBGPspeaker.TheReuse-limitdefaultis750.WhenpenaltyishalfofReuse-limit,thedampeninginformationwillbepurged.•Historystate—Whenflap(withdrawal)occurs,arouteisassignedapenaltyof1000.Inthisstate,BGPdoesnothavetheroutebecauseitiswithdrawn,butBGPmaintaintheinformationabouttherouteinhistorystatetokeeptrackofdampening.•Dampstate—Withrepeatedflaps,wherethepenaltyexceedsthesuppresslimit,therouteisremovedfromroutingtableandisnotadvertisedtoanyBGPspeaker.•Maximumdurationofdampening—Defaultis4timesofhalflifetime(15minutes).Aroutecanonlybedampenedfor1hourindefaultsettings.

InCiscoIOSSoftware,dampeningisconfiguredasshowninExample14-26.Example14-26ConfigurationofDampeninginCiscoIOSSoftware

R3#routerbgp110bgpdampening

Withthisconfiguration,thehalflife,reuselimit,suppresslimit,andmaximumsuppresstimewillget

defaultsof15min,750,2000,and1hour,respectively.ThesevaluescanbechangedwiththeconfigurationshowninExample14-27.Example14-27ConfigurationtoChangeDampeningParameters

routerbgp110bgpdampening140020004

InExample14-27,thehalflifeis1,reuselimitis400,suppresslimitis2000,andthemaximumsuppresstimeis4timesthehalflife,sorouteswillbesuppressedforamaximumof4minutes.TheexamplethatfollowsdemonstrateshowdampeningworksandwhatsequenceofeventstheCiscoroutergoesthroughwhenroutesareflapped.Inasimplenetwork,R1andR3arerunningEBGP.R1isadvertising131.108.1.0/24toR3.Example14-28showsthesequenceofeventswhenR3hasdampeningenabledandR1isflapping131.108.1.0/24.R3isrunningfollowingdebugstoobservethesequenceofevents.

NoteDebugsshouldberuncarefullyasexcessivedebugoutputcaninfluencerouterperformance.

Example14-28RouteDampeningExample

R3#debugipbgpupdates1debugipbgpdampening1


!FirstSequence:R1haswithdrawn131.108.1./24R3#Jul7:20:33.151MDT:BGP:1.1.2.1rcvUPDATEabout131.108.1.0/24withdrawn241.Jul417:20:33.151MDT:BGP:chargepenaltyfor131.108.1.0/24path1092withhalflife-time15reuse/suppress750/2000.Jul2417:20:33.151MDT:flapped1timessince00:00:00.Newpenaltyis1000

R3#showipbgp131.108.1.0BGProutingtableentryfor131.108.1.0/24,version3Paths:(1available,nobestpath)Flag:0x88Notadvertisedtoanypeer109(historyentry)1.1.2.1from1.1.2.1(10.1.1.1)OriginIGP,metric20,localpref100,externalDampinfo:penalty1000,flapped1timesin00:00:04

!SecondSequence:R1announces131.108.1.0/24toR3.R3#Jul2417:21:01.214MDT:BGP:1.1.2.1rcvUPDATEabout131.108.1.0/24

R3#showipbgp131.108.1.0BGProutingtableentryfor131.108.1.0/24,version4Paths:(1available,best#1)Flag:0x88

Notadvertisedtoanypeer1091.1.2.1from1.1.2.1(10.1.1.1)OriginIGP,metric20,localpref100,valid,external,bestDampinfo:penalty972,flapped1timesin00:00:39

!ThirdSequence:R1hasagainwithdrawn131.108.1./24R3#Jul2417:21:31.882MDT:BGP:1.1.2.1rcvUPDATEabout131.108.1.0/24--withdrawn.Jul2417:21:31.882MDT:BGP:chargepenaltyfor131.108.1.0/24path109withhalflife-time15reuse/suppress750/2000.Jul2417:21:31.882MDT:flapped2timessince00:00:58.Newpenaltyis1960

R3#showipbgp131.108.1.0BGProutingtableentryfor131.108.1.0/24,version5Paths:(1available,nobestpath)Flag:0x88Notadvertisedtoanypeer109(historyentry)1.1.2.1from1.1.2.1(10.1.1.1)OriginIGP,metric20,localpref100,externalDampinfo:penalty1937,flapped2timesin00:01:17

!FourthSequence:R1announces131.108.1.0/24toR3.

.Jul2417:22:13.706MDT:BGP:1.1.2.1rcvUPDATEabout131.108.1.0/24

R3#showipbgp131.108.1.0BGProutingtableentryfor131.108.1.0/24,version6Paths:(1available,best#1)Flag:0x88Notadvertisedtoanypeer1091.1.2.1from1.1.2.1(10.1.1.1)OriginIGP,metric20,localpref100,valid,external,bestDampinfo:penalty1891,flapped2timesin00:01:52R3#showiproute131.108.1.0Routingentryfor131.108.1.0/24Knownvia"bgp110",distance20,metric20Tag109,typeexternalLastupdatefrom1.1.2.100:00:13agoRoutingDescriptorBlocks:*1.1.2.1,from1.1.2.1,00:00:13agoRoutemetricis20,trafficsharecountis1ASHops1,BGPnetworkversion0

FifthSequence:R1hasagainwithdrawn131.108.1./24R3#Jul2417:22:40.781MDT:BGP:1.1.2.1rcvUPDATEabout131.108.1.0/24withdrawnJul2417:22:40.781MDT:BGP:chargepenaltyfor131.108.1.0/24path109withhalflife-time15reuse/suppress750/2000.Jul2417:22:40.781MDT:flapped3timessince00:02:07.Newpenaltyis2869

R3#showipbgp131.108.1.0BGProutingtableentryfor131.108.1.0/24,version7Paths:(1available,nobestpath)Notadvertisedtoanypeer109,(suppressedduetodampening)1.1.2.1from1.1.2.1(10.1.1.1)

OriginIGP,metric20,localpref100,valid,externalDampinfo:penalty2802,flapped3timesin00:02:44,reusein00:28:30

R3#showiproute131.108.1.0%Networknotintable

ThesignificanteventsinthefivesequencesinExample14-28areasfollows:•Inthedebugoutputofthefirstsequence,apenaltyof1000isappliedforthewithdrawnroute.BGPtableshowsthatpenaltyalongwithotherflapstatistics.•NoticeinBGPoutputofthesecondsequencethatthepenaltyisgraduallygoingdownat5secinterval.•Inthedebugoutputofthethirdsequence,thenewpenaltyisassignedforthisflap(Thenewpenaltyassignedis1000.)Thisnewpenaltyisaddedtotheoldpenaltyof937makingatotalpenaltyof1937,asshowninBGPoutput.•Inthefourthsequence,noticefromBGPandroutingtableoutputthat131.108.1.0/24isstillinstalledintheroutingtablebecausepenalty1891islessthanSuppress-Limit(2000).•Inthefifthsequence,withthethirdflap,thetotalpenaltyexceedsSuppressLimitof2000,andthisrouteisnowsuppressedintheBGPtable.Whenroutesaresuppressed,theyarenolongerinstalledintheroutingtableandarenotadvertisetotheotherBGPneighbor.FromtheBGPoutput,itisevidentthattherouteissuppressedfor28minutesand30secondsprovidednofurtherflapshappen.

Dampeningiscommonlyusedbecauseitoffersadynamicwaytopenalizeflappingandunstableroutes.

ScalingIBGPinLargeNetworks—RouteReflectorsandConfederationsItisacommonunderstandingthatthereexistsarulestatingthatIBGPneighborsmustbefullymeshedwitheachother.ThissectionaddresseswhythisisarequirementandhowtoavoidfullymeshedIBGP.Itisimportanttounderstandtworulesofprefixadvertisement:1WhenaprefixisreceivedfromanEBGPneighbor,theroutermustadvertisethatprefixtoallotherEBGPandIBGPneighbors.

2WhenaprefixisreceivedfromanIBGPneighbor,itcanbeadvertisedONLYtoEBGPneighbors,NOTtoanyotherIBGPneighbors.

ThissecondrulerequiresafullymeshedIBGPneighborrelationship;otherwise,prefixesarenotadvertisedtoallroutersinasingleAS.IBGPfullmeshcanscaleinnetworkswherethenumberofIBGPrunningroutersissmall;however,innetworkscharacteristicofabigISPinwhichthenumberofroutersrunningIBGPmightreachseveralhundred,havingann(n–1)(wherenisthetotalnumberofroutersintheAS)neighborrelationshipandexchangingroutesbetweenallsimplywillnotwork.Figure14-20showsafullymeshedIBGPwithonly12routersrunningIBGP.

Figure14-20Twelve-Router,FullyMeshedIBGPNetwork

Imaginethenightmarecausedbyreplacingthe12-routerfullmeshwitha500-routerfullmeshofIBGP.Thislimitationoffull-meshIBGPwasthecatalystforthedevelopmentoftwomechanismsthataddressthisproblem:•RouteReflection,asdescribedinRFC1966•ASConfederations,asdescribedinRFC3065

Thesectionsthatfollowbrieflydescribebothmechanisms.Formoredetailedcoverageofthesemechanisms,youareencouragedtoreadtheRFCs.

RouteReflectionInsteadofdoingfull-meshIBGPbetweenallrouters,Route-Reflectiondesignallowsrouternetworkstohaveahierarchy.Networksaredividedintoregions,andeachregioncanhaveamultiple-layerhierarchyofCore,Aggregation,andAccessrouters.IBGProutingupdatesarepropagatedbetweenlevelsinbothdirectionswhenrunningRoute-Reflection.Figure14-21replacesthefullymeshedIBGPmessillustratedinFigure14-20byusingRoute-ReflectioninanIBGPnetwork.EachAccesslayerrouterconnectstoonlyregionalAggregationrouters,andtheseAggregationroutersconnectonlytoCorerouters.TheCoreroutersneedtobefullymeshedwitheachother.Multipleconnectionsexistfromeachrouterforredundancy.RoutersspeakonlyIBGPwiththeirupper-layerrouters.Forexample,R1peersonlywithR4andR5,whichpeeronlywithR6andR7.Corerouterspeerwitheachotherandtoallroutersbelowtheminthehierarchy.Thisway,theCoreisconnectedtoallregions.

Figure14-21IBGPNetworkUsingRouteReflection

ThetoplevelisaRoute-Reflector(RR)forthebottomlevelthatactsasaRoute-Reflector-Client(RRC)forthetoplevel.InFigure14-21,theCorelayerrouters(R6andR7)actasRRsfortheAggregationlayerrouters(R4,R5,R8,andR9);therefore,theAggregationlayerrouters(R4,R5,R8,andR9)areRRCsoftheCorelayerrouters(R6andR7).AnRRclientcanbeaRoute-Reflectorforbottom-layerroutersaswell.AggregationlayerrouterR4,whichisanRRCfortheCorelayerrouters(R6andR7),isalsoactingasanRRforAccesslayerRoutersR1,R2,andR3,whichareRRCsfortheAggregationlayerrouters(R4andR5).Figure14-21givesanexampleofhierarchicalRoute-Reflection.Anetworkthathasjusttwolayers(CoreandAccess)hasonlyonelevelofRoute-Reflection.Route-ReflectionisconfiguredonlyontheRR(s).Route-Reflector-Clientsareunawarethattheyarepartofanyreflection;therefore,noconfigurationisneededtomakethemRRCs.ThewaythatIBGProutingupdatesflowinanRRnetworkisdefinedbythefollowingrules:1IfanupdatecamefromanEBGPneighbor,advertisethatupdatetoallneighbors(IBGP,EBGP,Route-Reflector-Client(s)).

2IfanupdatecamefromanIBGPneighbor,advertisethatupdatetoEBGPneighborsandRoute-Reflector-Clients.

3IfanupdatecamefromaRoute-Reflector-Client,advertisethatupdatetootherRoute-Reflector-Client(s),IBGP,andEBGPneighbors,butnottotheRoute-Reflector-Clientthatsenttheupdate.

InFigure14-21,supposethatanEBGPneighborisconnectedtoCoreRouterR6toadvertiseanupdatefor131.108.1.0/24.R6passesthatupdatetoallneighborsbecauseofrule1justmentioned,andthe

Aggregationlayer(R4andR5)willpassthattotheAccesslayer(R1,R2,andR3)becauseofrule2.Similarly,theeastregionwillalsopropagatetheupdate.Thisway,131.108.1.0/24willbepropagatedthroughouttheregionwithouthavingafullmeshofIBGP.Now,imaginethatAccesslayerRouterR1receivestheprefix140.1.1.0/24fromitsEBGPneighbor.R1propagatesthattotheAggregationlayer(R4andR5)becauseofrule1.R4andR5reflecttheupdatetotheAaccesslayer(R2andR3)andtotheCorelayer(R6andR7)becauseofrule3.TheCorelayer(R6andR7)reflectsthatupdatetotheeastregionAggregationlayer(R8andR9)becauseofrule3.Thisway,140.1.1.0/24willbepropagatedfromthelowerlayerstotheupperlayersinahierarchicalnetwork.HierarchicalRoute-ReflectionnetworksmakemoresensewhentheyareviewedasagroupofRRsandtheirclients.FollowingarethedefinitionofafewimportantandkeyconceptsinunderstandhierarchicalRoute-Reflection.•Cluster—AsetofoneormoreRRsandtheirclients.•Originator_IDattribute—ThisisaRIDoftherouterthatoriginatedorfirstreceivedtheroutefromEBGPneighborinthelocalASandtheRRcreatetheoriginatorID.•Cluster-ID—A4-byteintegerrepresentingthecluster.Ifthecluster-IDisnotconfigured,theRIDoftheRRistakenasthecluster-ID.Configurethecluster-IDusingthefollowingCiscoIOSSoftwarecommand:routerbgp109bgpcluster-idx.x.x.x

WhentwoRRsareconfiguredwiththesamecluster-ID,theyarepartofthesamecluster.•Cluster_listattribute—Alistofcluster-IDsrepresentingtheseriesofclustersthatanupdatehastraversed.WhenanRRreceivesanupdatefromitsclient,theRRaddsitslocalcluster-IDandsendsittoanonclient(upper-levelRRorIBGPneighbor).WhenanRRreceivesanupdatewithitsowncluster-IDintheclusterlist,theRRdropsthatupdate,assumingthattheupdatehaslooped.

Figure14-22showsclusterdefinitionasconfiguredonallRRs.

Figure14-22RouteReflectionUsingClusters

Example14-29showshowRRandclusterdefinitionsaredoneinCiscoIOSSoftware.Specifically,thisexamplelooksattheconfigurationofR4,theRRintheAggregationlayer.Example14-29SampleConfigurationofRRandClusterinR4

routerbgp109neighbor1.1.1.1remote-as109neighbor1.1.1.1route-reflector-clientneighbor2.2.2.2remote-as109neighbor2.2.2.2route-reflector-clientneighbor3.3.3.3remote-as109neighbor3.3.3.3route-reflector-clientneighbor6.6.6.6remote-as109neighbor7.7.7.7remote-as109bgpcluster-id1.1.1.1

R4hasthreeclients—R1(1.1.1.1),R2(2.2.2.2),andR3(3.3.3.3)—andtwonormalIBGPneighbors—R6(6.6.6.6)andR7(7.7.7.7).NoconfigurationinR4showsthatitisanRRCofR6andR7.AssumethatAccesslayerRouterR1inthewestregionadvertisesaprefixof140.1.1.0/24.Example14-30providesshowipbgpoutputtodisplayhowthisupdatewouldaffectAccesslayerRouterR12intheeastregion.Example14-30showipbgpOutputtoShowClusters

R12>showipbgp140.1.1.0BGProutingtableentryfor140.1.1.0/24

1.1.1.1from1.1.1.1(1.1.1.1)OriginIGP,metric0,localpref100,valid,internal,bestOriginator:1.1.1.1Clusterlist:2.2.2.21.1.1.1

InExample14-30,theoriginatoris1.1.1.1,whichistheRIDofR1.Theclusterlistshowsthetwoclustersthatthisupdatehastraversed.Route-ReflectionsolvesthefullIBGPmeshproblemveryelegantlyandoffersgreatflexibilityforBGPnetworkstogrowtomuchbiggerIBGPnetworks.AlmostalllargeBGPnetworksmakeuseofRoute-ReflectiontoscaletheirIBGP.

ASConfederationsInanASConfederation,anASisdividedintosmallerSubautonomoussystems,whichareconnectedthroughEBGPtoeachother.EachSub-ASactsasanindependentBGPASandrunsnormalIBGPinternallywithintheSub-AS.AsingleIGPisruninacompleteASandeachSub-AShasIGProutinginformationaboutallotherSubautonomoussystems.MostBGPattributes,suchasLOCAL_PREF,MED,andNEXT_HOP,arepreservedwhenupdatesgoacrossaSub-AS.TheAS_PATHattributeaddstheSubautonomoussystemsintheAS_PATH.Totheoutsideworld,theASrunningASConfederationappearsasasingleAS.TobetterunderstandASConfederations,youneedtoknowabouthowtheAS_PATHattributeoperateswithinanASConfederationnetwork.JustastheAS_PATHattributecarriesinformationaboutautonomoussystemstheupdateshavetraversed,AS_PATHinConfederationcarriesSub-ASinformation.JustaswiththeAS_PATHattribute,whenarouterrunningConfederationreceivesanupdatewhoseAS_PATHcontainsitsownSub-AS,therouterdropsthatupdatetoavoidloops.ThetwoBGPattributesassociatedwithASConfederationsaredescribedasfollows:•AS_CONFED_SEQUENCE—DefinesthelistofSubautonomoussystemsintheAS_PATH,insequentialorderofconfederatedSub-ASwheretheupdatehastraversed.ThisisanalogoustoAS_SEQUENCE,asdiscussedinAS_PATHattributedefinition.•AS_CONFED_SET—DefinesthelistofSubautonomoussystemsintheAS_PATHinanunorderedsetofSub-AS.ThiscanbeusedinsituationswhereaConfederationSub-ASisaggregatingroutestoformmultipleSubautonomoussystems.Inthiscase,youcansetAS_PATHasAS_CONFED_SETfortheaggregatedroute;itcarriesthelistofallSub-AS,buttheirorderisnotmaintained.ThisisanalogoustoAS_SET,asdiscussedintheAS_PATHattributedefinition.

Figure14-23showsanAS109dividedintoanASConfederationofthreesmallSub-AS:65001,65002,and65003.EachSub-ASrunsEBGPwiththeotherSubautonomoussystems.NoticethattheSubautonomoussystemsdonothaveafullmeshofEBGP.ThisissimilartotherealworldofBGPwhereallEBGPspeakersarenotfullymeshed.EachSub-AStreatstheotherSubautonomoussystemsasEBGPneighbors,thusforwardingallupdatesfromoneSub-AStootherSubautonomoussystems.

Figure14-23ASConfederationsUsingSubAutonomousSystems

Figure14-23showsthatR1inSub-AS65003isrunningEBGPwithautonomoussystem110,whichisadvertising140.1.1.0/24toR1.WhenR1receivestheupdatefromautonomoussystem110,theprefix140.1.1.0/24willhavetheAS_PATHas110.Sub-AS65003propagatesthispathtoSub-AS65002withtheAS_PATHattributeas(65003)110.InBGPoutput,(65003)meansthatthisautonomoussystemrepresentsaSub-ASofanASConfederation.Whenthisupdateleavessubautonomoussystem65002,theAS_PATHlookslike(6500265003)110.WhenR12inSub-AS65001advertises140.1.1.0/24totheoutsideworld,theAS_PATHfieldisstrippedfromtheConfederationSub-ASnumbers,andtheoutsideworldispresentedwithAS_PATHas109110forprefix140.1.1.0/24asiftherewerenoConfederationinAS109.Example14-31showsasampleBGPconfigurationinRouterR4inSub-AS65003.Example14-31SampleConfederationSub-ASConfiguration

R4#routerbgp65003confederationidentifier109bgpconfederationpeers65002neighbor1.1.1.1remote-as65003neighbor2.2.2.2remote-as65003neighbor3.3.3.3remote-as65003

neighbor6.6.6.6remote-as65002neighbor7.7.7.7remote-as65002

InExample14-31,confederationidentifierrepresentstherealASassignedtothisnetwork,and109is

theASthattheoutsideworldsees.ThebgpconfederationpeerscommandlistsalltheConfederationSubautonomoussystemswithwhichthisrouterispeering.Inthisexample,R4ispeeringwithSub-AS65002(R6andR7).R4isalsopeeringwiththreeinternalIBGPpeers,R1,R2,andR3,atthe1.1.1.1,2.2.2.2,and3.3.3.3addresses,respectively,inSub-AS65003.AlthoughanASConfederationoffersamechanismtoavoidfullymeshedIBGPinalargeAS,afullmeshofIBGPisstillarequirementwithinaSub-AS.ThispresentsachallengeofscalingIBGPwithineachSub-AS.EachSub-AScouldthenhaveafullmeshofIBGPoritcouldrunRoute-ReflectionwithineachSub-AS.InthequesttoeliminatefullymeshedIBGPusingRoute-ReflectionorASConfederations,BGPoperatorslookatvariousreasonstopreferonetotheother.Itdependson,amongotherthings,howthephysicalnetworkislaidout,whichmethodrequireslessconfigurationchange,andwhichmethodofferseaseinmanagingIBGP.

BestPathCalculationMaterialinthissectionisbasedontheCiscodocument“BGPBestPathSelectionAlgorithm,”availableatwww.cisco.com/warp/public/459/25.shtml.

Bydesign,aBGPspeakerreceivingupdatespicksonlyasinglebestupdatefromasetofmultipleupdatesandinstallsitintheroutingtable.BGPbestpathcalculationgoesthroughaseriesofcomparisonsbetweenmultipleupdates.ThecomparisonisdoneovertheBGPattributes,andaseriesoftestsisperformeduntiloneupdatewinsovertheotherandthebestpathupdateisplacedintheroutingtable.Withthebestpathalgorithm,BGPassignsthefirstvalidpathasthecurrentbestpath.BGPthencomparesthebestpathwiththenextpathinthelist,untilitreachestheendofthelistofvalidpaths.Thefollowinglistofrulesdeterminesthebestpath:1PreferthepathwiththelargestWEIGHT.WEIGHTisaCiscoproprietaryparameter,localtotherouteronwhichitisconfigured.

2Preferthepathwiththelargestlocalpreference(LOCAL_PREF).3PreferthepaththatwaslocallyoriginatedthroughanetworkoraggregateBGPsubcommand,orthroughredistributionfromanIGP.Localpathssourcedbynetwork/redistributecommandsarepreferredoverlocalaggregatessourcedbytheaggregate-addresscommand.

4PreferthepathwiththeshortestAS_PATH.TheAS_PATHisalistingoftheautonomoussystemsthroughwhichthisparticularupdatetraveledtoreachthelocalautonomoussystem.Thefewerautonomoussystemsitcrossed,themorepreferredtherouteis.Notethefollowing:—Thisstepisskippedifyouconfigurebgpbestpathas-pathignore.—AnAS_SETcountsas1,nomatterhowmanyautonomoussystemsareintheset.—TheAS_CONFED_SEQUENCEisnotincludedintheAS_PATHlength.

5Preferthepathwiththelowestorigintype:IGPislowerthanEGP,andEGPislowerthanINCOMPLETE.

6Preferthepathwiththelowestmulti-exitdiscriminator(MED).Notethefollowing:—Thiscomparisonisdoneonlyifthefirst(neighboring)ASisthesameinthetwopaths;anyConfederationSubautonomoussystemsareignored.Inotherwords,MEDsarecomparedonlyifthefirstASintheAS_SEQUENCEisthesameformultiplepaths.AnyprecedingAS_CONFED_SEQUENCEisignored.

—Ifbgpalways-compare-medisenabled,MEDsarecomparedforallpaths.Thisoptionneedsto

http://www.cisco.com/warp/public/459/25.shtml

beenabledovertheentireAS,otherwise,routingloopscanoccur.—Ifbgpbestpathmed-confedisenabled,MEDsarecomparedforallpathsthatconsistonlyofAS_CONFED_SEQUENCE(pathsoriginatedwithinthelocalconfederation).

—PathsreceivedfromaneighborwithaMEDof4,294,967,295willhavetheMEDchangedto4,294,967,294beforeinsertionintotheBGPtable.

—PathsreceivedwithnoMEDareassignedaMEDof0,unlessbgpbestpathmissing-as-worstisenabled;inthatcase,theyareassignedaMEDof4,294,967,294.

—Thebgpdeterministicmedcommandalsocaninfluencethisstep.7Preferexternal(eBGP)overinternal(iBGP)paths.PathscontainingAS_CONFED_SEQUENCEarelocaltotheconfederationand,therefore,aretreatedasinternalpaths.ThereisnodistinctionbetweenConfederationExternalandConfederationInternal.

8PreferthepathwiththelowestIGPmetrictotheBGPnexthop.9Ifthemaximum-pathsncommandisenabledandtherearemultipleexternalorconfederationexternalpathsfromthesameneighboringASorSub-AS,BGPinsertsuptonmostrecentlyreceivedpathsintheIProutingtable.ThisallowseBGPmulti-pathloadsharing.Themaximumvalueofniscurrently6.Thedefaultvalue,whenthisoptionisdisabled,is1.Theoldestreceivedpathismarkedasthebestpathintheoutputofshowipbgplonger-prefixes,andtheequivalentofnext-hop-selfisperformedbeforeforwardingthisbestpathtointernalpeers.

10Ifbothpathsareexternal,preferthepaththatwasreceivedfirst(theoldestone).Thisstepminimizesrouteflappingbecauseanewerpathwon’tdisplaceanolderone,evenifitwasthepreferredroutebasedontheRID.Itisbetterpracticetoapplytheadditionaldecisionstepsin11,12,and13toiBGPpathsonly,toensureaconsistentbestpathdecisionwithinthenetworkandtherebyavoidloops.Thisstepisskippedifanyofthefollowingistrue:—Thebgpbestpathcompare-routeridcommandisenabled.—TherouterIDisthesameformultiplepathsbecausetherouteswerereceivedfromthesamerouter.

—Nocurrentbestpathexists.Anexampleoflosingthecurrentbestpathoccurswhentheneighborofferingthepathgoesdown.

11PrefertheroutecomingfromtheBGProuterwiththelowestrouterID.TherouterIDisthehighestIPaddressontherouter,withpreferencegiventoloopbackaddresses.Itcanalsobesetmanuallyusingthebgprouteridcommand.IfapathcontainsRRattributes,theoriginatorIDissubstitutedfortherouterIDinthepathselectionprocess.

12IftheoriginatororRIDisthesameformultiplepaths,preferthepathwiththeminimumclusterIDlength.ThiswillbepresentonlyinaBGPRoute-ReflectorenvironmentinwhichclientspeerwithRRsorclientsinotherclusters.Inthisscenario,theclientmustbeawareoftheRR-specificBGPattribute.

13Preferthepathcomingfromthelowestneighboraddress.ThisistheIPaddressusedintheBGPneighborconfiguration,anditcorrespondstotheremotepeerusedintheTCPconnectionwiththelocalrouter.

Example14-32showshowabestpathiscalculated.Example14-32istakenfromroute-server.cerf.netandisslightlymodifiedtomakeitmoreinteresting.route-server.cerf.netisarouteserveravailableontheInternet.Example14-32ConfigurationtoDemonstrateCalculationoftheBestPath



showipbgp3.0.0.0BGProutingtableentryfor3.0.0.0/8,version16396661Paths:(4available,best#4)Notadvertisedtoanypeer!Path1174070180192.157.69.5from192.157.69.5(134.24.127.201)OriginIGP,metric20,localpref100,valid,external,!Path2174070180198.32.176.25from198.32.176.25(134.24.127.35)OriginIGP,metric20,localpref110,valid,external,!Path3174070180134.24.88.55from134.24.88.55(134.24.127.27)OriginIGP,metric20,localpref100,valid,external,!Path4174070180192.41.177.69from192.41.177.69(134.24.127.131)OriginIGP,metric10,localpref110,valid,external,best,

BygoingthroughtheBGPbestpathdecisionalgorithmstepbystep,path4isthebestforthesereasons:•Path2isbetterthanpath1becauseithasahigherLOCAL_PREF.•Path2isbetterthanpath3becauseithasahigherLOCAL_PREF.•Path4isbetterthanpath2becauseithasalowerMED.

SummaryBorderGatewayProtocol4(BGP-4)isadynamicroutingprotocolthatexchangesnetworkreachabilityinformationwithotherBGPpeers.BGPismostcommonlyusedinserviceprovidernetworksandinlargeenterprisenetworks,anditiswidelydeployedtomanageIPtraffic.ThepowerofBGPpolicycontrolthroughitsattributes(LOCAL_PREF,AS_PATH,MULTI_EXIT_DISC[MED],Origin,NEXT_HOPandsoon)providesnetworkoperatorsstrongcontroloverIPtrafficflow.InadditiontoIPv4,BGPhasbeenextendedtosupportmulticastandVPN-IPv4.CiscoIOSSoftwareoffersrichsupportofBGP,andthischaptershouldbeastartingpointinunderstandingCiscoIOSSoftwareimplementation.ReadersareencouragedtoreadtheCiscoIOSSoftwaredocumentationforadetailedexplanationoftheconfigurationsdiscussedinthischapter.

ReviewQuestions1DoesBGPhaveitsowntransportmechanismtoensuretheguaranteeofBGPupdates?A.BGPhasitsowntransportmechanismtodeliverBGPpacketstoitsneighbors.B.UDPisapreferredmethodbecauseBGPneighborsareinmostcasesdirectlyconnectedandthelossofpacketsisunlikely.

C.BGPusesTCPasitstransportmechanism.2AssumingnoRoute-ReflectionorConfederationsareused,whatproblemsmightoccurifIBGPneighborsarenotfullymeshed?A.AnIBGPupdatewillnotbepropagatedtoBGProutersintheASbecausetheIBGPlearnedupdateisnotannouncedtootherIBGPneighbors.

B.Everythingwillrunfine.

C.OnlyexternalBGPneighborswon’treceivetheBGPupdates.3WhatBGPtechniqueisusedtopenalizeflappingofBGProutesinsomeotherAS?A.Route-ReflectionB.DampeningC.Peergroups

4TheBGPprocesscanexchangeupdateswithitsneighborsafterpassingwhichneighborstate?A.EstablishedB.OpenSentC.Active

5WhichofthefollowingtechniquesareusedinsolvingtheIBGPfullmeshrequirement?A.DampeningB.AggregationC.RouteReflectionandConfederation

Chapter15.TroubleshootingBGP

Thischaptercoversthefollowingtroubleshootingtopics:•TroubleshootingBGPneighborrelationships•TroubleshootingBGProuteadvertisement/originationandreceiving•TroubleshootingaBGProutenotinstallinginroutingtable•TroubleshootingBGPwhenroutereflectorsareused•TroubleshootingoutboundtrafficflowissuesbecauseofBGPpolicies•Troubleshootingload-balancingscenariosinsmallBGPnetworks•TroubleshootinginboundtrafficflowissuesbecauseofBGPpolicies•TroubleshootingBGPbestpathcalculationissues•TroubleshootingBGPfiltering

Thischapterdiscussescommonandefficientreal-lifetechniquestosolveproblemsseeninrunningBGPnetworks.Cisco’simplementationofBGPisfairlyeasytoconfigure,androbustnessofCiscoIOSSoftwareoffersBGPoperatorsgreatflexibilitytouseBGPtoattainthemostbenefit.However,problemsareunavoidableandthingsgowronginrealnetworkseveryday.ThischapteroffersasimplemethodologytotackleproblemsinnetworksrunningBGP.TotroubleshootBGP-relatedproblems,operatorsmuststartfrombasics.MostofBGPproblemsaresimilartoOpenSystemInterconnection(OSI)modelproblems.Forexample,BGPneighborrelationshipissuesshouldbetackledbylookingfirstatthenatureoftheneighborrelationship(IBGPorEBGP),followedbythephysicalconnectionbetweentwoBGPneighbors(OSILayer1);thenencapsulationissuesbetweenneighbors(OSILayer2),IPconnectivity(OSILayer3),andfinallyTCPconnectivity(OSILayer4)shouldbeconsidered.Thistroubleshootingmethodoffersconsistentandaccurateresolutiontotheproblem.CiscoIOSSoftwaredebugsshouldnotberunasthefirsttroubleshootingtool.CPU-intensivedebugswithahugeamountofdatasometimesmightnotofferanyhelpintroubleshootingaproblem;instead,theycancausesevereinstabilitytotherouter.ItisimpossibletodiscussallBGP-relatedproblems,butthischaptercoversmostoftheproblemsseeninourreal-lifeexperiencegainedfromworkingwithnetworksrunningBGPonCiscodevices.TheflowchartsthatfollowdocumenthowtoaddresscommonproblemswithBGPwiththemethodologyusedinthischapter.

FlowchartstoSolveCommonBGPProblems

showanddebugCommandsforBGP-RelatedTroubleshootingCiscoIOSSoftwareoffersdescriptiveshowcommandsanddebugstoaidintroubleshootingBGP-relatedproblems.Furthermore,mostofthedebugscanberunwithaccessliststolimittheoutputdisplayedbecauseexcessivedebugoutputcanseverelydegraderouterperformance.SomeofthemostcommonlyusedshowanddebugcommandsintroubleshootingBGPproblemsinCiscoroutersareasfollows:•showipbgpprefix•showipbgpsummary•showipbgpneighbor[address]•showipbgpneighbors[address][advertised-routes]•showipbgpneighbors[routes]•debugipbgpupdate[access-list]•debugipbgpneighbor-ip-addressupdates[access-list]

showipbgpprefixCommandThisisprobablythemostwidelyusedBGPshowcommandtochecktheBGPpathentryforprefixinBGPtable.Amongotherthings,theoutputshowsallBGPattributesassignedtotheprefixandallavailablepathsfrommultipleneighbors.

showipbgpsummaryCommandThiscommandgivesasummarizedlistofthestatusofallBGPneighbors,thenumberofprefixesreceivedfromeachpeer,andlocalBGPparameters.

showipbgpneighbor[address]CommandThiscommanddisplaysdetailsabouttheBGPneighbor,includingitsstatus,thenumberofupdatessentandreceived,andTCPstatistics.

showipbgpneighbors[address][advertised-routes]CommandThiscommanddisplaysroutesadvertisedtoneighborsandisusedintroubleshootingcaseswhenneighborsdon’treceivesomeorallBGProutes.

showipbgpneighbors[routes]CommandThiscommanddisplaysroutesreceivedfromneighborsandisusedintroubleshootingcaseswhenthelocalroutersdon’treceivesomeorallBGProutes.

debugipbgpupdate[access-list]CommandThisisthemostcommonlyusedBGPdebugtotroubleshootproblemsinBGPpathadvertisement.Theaccess-listoptionlimitstheoutputdisplay;otherwise,ifthenumberofprefixesishuge,thisoutputcanseverelydegraderouterperformanceandalsocanreloadtherouterinworstcases.Bothstandardandextendedaccesslistscanbeused.StandardAccessListUsage

debugipbgpupdate1access-list1permithost100.100.100.0

Withstandardaccesslists,thehost100.100.100.0meansthatifaBGPupdatecontains100.100.100.0,onlythedebugdisplaystheoutput.Unlikeextendedaccesslists,standardaccesslistsdonotgiveanyoptiontolimittheoutputbasedonthemaskoftheprefix.

ExtendedAccessListUsagedebugipbgpupdate101access-list101permitiphost100.100.100.0host255.255.255.0

Fortheprecedingextendedaccesslist,onlyBGPupdatesrelatedto100.100.100.0/24display.Thefirstportionoftheaccesslist,host100.100.100.0,meansthattheprefixtodisplayoutputis100.100.100.0.Thesecondportion,host255.255.255.0,requiresthemaskof100.100.100.0tobeClassC255.255.255.0(/24).

debugipbgpneighbor-ip-addressupdates[access-list]CommandThisdebugcommandissimilartothepreviousone,exceptthatitgivestheoptionofdisplayingdebugoutputonaper-neighborbasis.

TroubleshootingBGPNeighborRelationshipsThissectiondiscussesthemostcommonissuesinforminganeighborrelationshipbetweentwoBGP-speakingrouters.BGPspeakersexchangeroutinginformationonlyaftertheysuccessfullybecomeneighborswitheachother.TroubleshootingneighborrelationshipissuesshouldfollowtheOSIreferencemodel.First,youshouldcheckLayer2connectivity;thencheckIPconnectivity(Layer3),TCPconnections(Layer4),andfinallytheBGPconfigurationinCiscoIOSSoftware.ThesectionisarrangedtodiscussexternalBGPneighbors’issues,internalBGPneighbors,andthenproblemsthatarecommoninbothexternalandinternalBGPneighborrelationships.ThefollowingisthelistofproblemsmostcommonlyseenwhenformingBGPneighborrelationships.•DirectlyconnectedexternalBGPneighborsnotinitializing•NondirectlyconnectedexternalBGPneighborsnotinitializing•InternalBGPneighborsnotinitializing•BGPneighbors(externalandinternal)notinitializing

Problem:DirectlyConnectedExternalBGPNeighborsNotInitializingThissectiondiscussesissueswhenadirectlyconnectedEBGPneighborrelationshipisunsuccessful.Theautonomoussystem(AS)willnotsendorreceiveanyIPprefixupdatestoorfromaneighboringASunlesstheneighborrelationshipreachestheEstablishedstate,whichisthefinalstageofBGPneighborestablishment,asdescribedinChapter14,“UnderstandingBorderGatewayProtocolVersion4(BGP-4).”WhenanAShasasingleEBGPconnection,noIPconnectivitycanoccuruntilBGPfinalizesitsoperationofsendingandreceivingIPprefixes.Figure15-1showsanetworkinwhichanexternalBGPneighborrelationshipisconfiguredbetweenAS109andAS110.

Figure15-1ExternalBGPNeighborRelationship

Themostcommonpossiblecausesofthisproblemareasfollows:•Layer2isdown,preventingcommunicationwithadirectlyconnectedEBGPneighbor.•AnincorrectneighborIPaddressisintheBGPconfiguration.

DirectlyConnectedExternalBGPNeighborsNotComingUp—Cause:Layer2IsDown,PreventingCommunicationwithDirectlyConnectedBGPNeighbor

IPconnectivitycannotoccuruntilLayer2intheOSIreferencemodelisup.WhetherthisLayer2informationislearneddynamicallyorisconfiguredstatically,eachroutermusthaveacorrectLayer2rewriteinformationofadjacentrouters.Ethernet,FrameRelay,ATM,andsoonaremostcommonlyusedLayer2technologies.MostnetworkadministratorsconfigureLayer2parametersinrouterconfigurationscorrectly;sometimes,basiccablingissuesalsocancauseLayer2issues.Amongcablingissues,misconfigurationinrouterconfigurationcancauseARP,DLCImapping,andVPI/VICencapsulationfailures,whicharethemostcommonLayer2failures.ItisbeyondthescopeofthisbooktoaddresshowthisLayer2informationisobtained.Case(s)inthissectiontrytoaddresshowtotroubleshootBGPproblemswhenthecauseoftheEBGPneighborrelationshipfailureisLayer2.Figure15-2showstheflowcharttofollowtofixthisproblem.


Example15-1showstherelevantconfigurationofR1andR2,respectively.Example15-1R1andR2Configuration

R1#routerbgp109neighbor131.108.1.2remote-as110

interfaceEthernet0ipaddress131.108.1.1255.255.255.0



YoucanverifytheBGPneighborrelationshiponCiscoIOSSoftwarebyusingthecommandsinExample15-2.Example15-2VerifyingBGPNeighborRelationship

R1#showipbgpsummaryBGProuteridentifier206.56.89.6,localASnumber109BGPtableversionis1,mainroutingtableversion1

NeighborVASMsgRcvdMsgSentTblVerInQOutQUp/DownState/PfxRcd131.108.1.241103700000:03:14Active

R1#showipbgpneighbors131.108.1.2BGPneighboris131.108.1.2,remoteAS110,externallinkBGPversion4,remoterouterID0.0.0.0BGPstate=ActiveLastread00:04:23,holdtimeis180,keepaliveintervalis60secondsReceived3messages,0notifications,0inqueueSent7messages,1notifications,0inqueueRouterefreshrequest:received0,sent0Minimumtimebetweenadvertisementrunsis30seconds

Foraddressfamily:IPv4UnicastBGPtableversion1,neighborversion0Index1,Offset0,Mask0x20acceptedprefixesconsume0bytesPrefixadvertised0,suppressed0,withdrawn0

Connectionsestablished1;dropped1Lastreset00:04:44,duetoBGPNotificationsent,holdtimeexpiredNoactiveTCPconnection

TheoutputinExample15-2showsthattheBGPneighborisintheActivestate.ThisstateindicatesthatnosuccessfulcommunicationbetweentheneighborshastakenplaceandthatBGPhasfailedtoformneighborrelationship.YoucanusepingtoverifyIPconnectivitybetweenR1andR2.Example15-3showsthatR1cannotpingR2’sIPaddress.Example15-3R1PingofR2’sIPAddressFails

R1#ping131.108.1.2


Solution

Inthisexample,thepingfailurefromR1toR2wastheresultofLayer2onR2beingdown.Example15-4showstheoutputindicatingaLayer2problem.Example15-4showinterfaceCommandOutputPinpointsThatThisIsaLayer2Problem

R2#showinterfaceethernet0Ethernet0isdown,lineprotocolisdown

Thismightbebecauseofcableissuesorahardwareproblem.Apartfromtheinterfacebeingdown,asinExample15-4,Layer2encapsulationfailurecanalsocauseIPconnectivitytobreak.Layer2encapsulationfailurecanoccurbecauseofcorruptionintheARPtableincaseofEthernetoranincorrectDLCI–VPI/VCImappingincasesofFrameRelayandATM,respectively.FixingtheseshouldenablebasicIPconnectivity,andtheBGPneighborrelationshipshouldinitialize.DirectlyConnectedExternalBGPNeighborsNotComingUp—Cause:IncorrectNeighborIPAddressinBGPConfiguration



Example15-5showstherelevantconfigurationofR1andR2,respectively.Example15-5R1andR2Configuration





Misconfigurationoftheneighboraddressisafairlycommonmistake,anditcanbecaughtwithvisualinspectionoftheconfiguration.However,inalargeIPnetwork,thismightnotbeatrivialtask.Example15-6showshowtocapturethismistakeusingdebugsinCiscoIOSSoftware.Example15-6debugipbgpCommandOutputHelpsPinpointIncorrectlyConfiguredNeighborAddresses

R2#debugipbgpBGPdebuggingisonR2#Nov2813:25:12:BGP:131.108.1.11openactive,localaddress131.108.1.2Nov2813:25:42:BGP:131.108.1.11openfailed:Connectiontimedout;remotehostnotresponding

TheoutputinExample15-6clearlypointsoutthatR2ishavingdifficultycommunicatingwithhost131.108.1.11.Solution

ThecorrectneighboraddressshouldbeconfiguredwhenestablishingBGPneighborrelationship.Therefore,R2’sBGPconfigurationmustlooklikeExample15-7.Example15-7CorrectingR2’sBGPConfiguration


AsimilarproblemcanoccurwhentheincorrectASnumberisconfigured.

Problem:NondirectlyConnectedExternalBGPNeighborsNotComingUpAsdiscussedinChapter14,insomecases,EBGPneighborsarenotdirectlyconnected.BGPneighborrelationshipscanbeestablishedinthefollowingsituationsaswell:•Betweenloopbackinterfacesoftworouters.•BetweenrouterstryingtomakeEBGPneighborrelationshipthatareseparatedbyoneormorerouters.SuchaneighborrelationshipistermedEBGPmultihopinCiscoIOSSoftware.

EBGPmultihopcanbeusedforseveralreasons.PeeringbetweenloopbacksbetweenEBGPtypicallyisdonewhenmultipleinterfacesexistbetweentherouters,andIPtrafficneedstobeload-sharedamongthoseinterfaces.AnotherscenariomightbeoneinwhichanedgeroutercannotrunBGPand,therefore,EBGPmustberunbetweenanonedgedeviceinoneASandanedgerouterinanother.AneighborrelationshipmustbeestablishedbeforeanyBGPupdatesandIPtrafficcanflowfromoneAStoanother.ThissectionaddressesmostofthecommoncausesinwhichnondirectlyconnectedEBGPneighborrelationshipswon’testablish.Figure15-4showsthatAS109andAS110areforminganEBGPneighborrelationshipbetweentheloopbackinterfaces.Suchaconnectionwillbeconsiderednondirectlyconnected.

Figure15-4NondirectlyConnectedEBGPSessionBetweentheLoopbackInterfaces

Themostcommonpossiblecausesofthisproblemareasfollows:•Theroutetothenondirectlyconnectedpeeraddressismissingfromtheroutingtable.•Theebgp-multihopcommandismissinginBGPconfiguration.•Theupdate-sourceinterfacecommandismissing.

NondirectlyConnectedExternalBGPNeighborsNotComingUp—Cause:RoutetotheNondirectlyConnectedPeerAddressIsMissingfromtheRoutingTable



WhenBGPtriestopeertheneighborrelationshipwithIPaddressesthatarenotdirectlyconnected,asshowninFigure15-4,theIProutingtablemusthavetheroutetothatIPaddress.InFigure15-4,R1isconfiguredtopeerwithLoopback0ofR2,andR2isconfiguredtopeerwithLoopback0ofR1.ThisisacommonpracticewhenmultipleconnectionsexistbetweenR1andR2andloadsharingoverthesemultiplelinesisrequired.DebugsandVerification

Example15-8showstherelativeconfigurationofbothRoutersR1andR2.Example15-8ConfigurationsforR1andR2inFigure15-4

R1#routerbgp109

neighbor131.108.10.2remote-as110neighbor131.108.10.2ebgp-multihop2neighbor131.108.10.2update-sourceLoopback0

R2#routerbgp110


InExample15-8,RoutersR1andR2areconfiguredtopeerwitheachother’sloopbackIPaddress.ebgp-multihop2meansthatR1andR2peeringaddressescouldbetwohopsaway.update-sourcemeansthatthesourceofBGPpacketsistheLoopbackthe0IPaddressbecausebothroutersacceptonlyBGPpacketssourcedwiththeLoopback0IPaddressofotherrouter.TheoutputinExample15-9showstheneighborrelationshipbetweenR1andR2.Example15-9showipbgpCommandOutputDisplaystheBGPNeighborRelationshipBetweenR1andR2


NeighborVASMsgRcvdMsgSentTblVerInQOutQUp/DownState/PfxRcd131.108.10.241103300000:03:21Active

R1#showipbgpneighbors131.108.10.2BGPneighboris131.108.10.2,remoteAS110,externallinkBGPversion4,remoterouterID0.0.0.0BGPstate=ActiveLastread00:04:20,holdtimeis180,keepaliveintervalis60secondsReceived3messages,0notifications,0inqueueSent3messages,0notifications,0inqueueRouterefreshrequest:received0,sent0Minimumtimebetweenadvertisementrunsis30seconds


Connectionsestablished1;dropped1Lastreset00:04:21,duetoUserresetExternalBGPneighbormaybeupto2hopsaway.NoactiveTCPconnection

ThehighlightedoutputinExample15-9showsthatR1’sneighborrelationshipwithR2isintheActivestateandthattheBGPrelationshipisnotcomplete.TheconfigurationshowninExample15-8isarequiredconfigurationwhenconfiguringanEBGPconnectiontoanondirectlyconnectedpeer;however,onethingthatisnotcontrolledbyBGPconfigurationisthereachabilitytopeeraddresses.Example15-10showsthatR1cannotreachtheloopbackinterfaceofR2becauseR1doesnothavetheroutetoreachR2.Example15-10R1CannotPingR2’sLoopbackInterfaceandHasNoRoutetoReachR2

R1#ping131.108.10.2



InR1,BGPwillsenditspacketstopeer131.108.10.2,butpacketswillbedroppedbyR1becausenoroutingreachabilityisavailablefor131.108.10.2.Solution

BGPreliesonanIProutingtabletoreachapeeraddress.IntheexampleinFigure15-4,R1musthavearoutetotheloopbackinterfaceofR2,andR2musthavearoutetotheloopbackinterfaceofR1.Itisirrelevanthowtheroutetothepeeraddressislearned,aslongastherouteispresentintheroutingtable.AdministratorsofR1andR2canchoosetorunadynamicIProuting(anIGP)betweeneachother(forexample,usingOSPF),ortheycouldnailastaticroutetoeachother.Usingastaticrouteisacommonpractice.AsimpleruleofthumbisthatR1andR2musthavemostspecificroutesforeachother’sloopbackaddressesthroughanyotherprotocolotherthanBGP.ToconfigureastaticrouteonR1toreachmultihopEBGPneighbors,youwouldenterthefollowing:

iproute131.108.10.2255.255.255.255131.108.1.2

R1hasahoststaticrouteforR2’sloopbackinterfacewithanexthopof131.108.1.2,whichisR2’sEthernetinterfaceIPaddress.Similarly,R2shouldhaveastaticrouteforR1’sloopbackinterface.ThiswillensurethatbothroutershavereachabilitytomultihopEBGPneighbors.NondirectlyConnectedExternalBGPNeighborsNotComingUp—Cause:ebgp-multihopCommandIsMissinginBGPConfiguration



Bydefault,inCiscoIOSSoftware,BGPpacketssenttoanexternalBGPneighborhavetheirIPTimeToLive(TTL)setto1.IfanEBGPneighborisnotdirectlyconnected,thefirstdeviceinthepathwilldropBGPpacketswithTTLequalto1tothatEBGPneighbor.


ReturningtothenetworkinFigure15-4,R1istryingtopeerEBGPtoR2’sLoopback0interface,whichisconsideredmorethanonehopaway.Example15-11showstheconfigurationofR1.Example15-11R1’sConfigurationtoFormEBGPMultihopNeighborRelationship

R1#routerbgp109

neighbor131.108.10.2remote-as110neighbor131.108.10.2update-sourceLoopback0

Example15-12showstheoutputtoverifythatnondirectlyconnectedEBGPneighborsareeithercomingupornotcomingup.Example15-12showipbgpCommandOutputVerifiesiftheEBGPNeighborsAreComingUp


NeighborVASMsgRcvdMsgSentTblVerInQOutQUp/DownState/PfxRcd131.108.10.24110252500000:00:51IdleR1#showipbgpneighbors131.108.10.2BGPneighboris131.108.10.2,remoteAS110,externallinkBGPversion4,remoterouterID0.0.0.0BGPstate=IdleLastread00:00:15,holdtimeis180,keepaliveintervalis60secondsReceived25messages,0notifications,0inqueueSent25messages,0notifications,0inqueueRouterefreshrequest:received0,sent0Minimumtimebetweenadvertisementrunsis30seconds


Connectionsestablished4;dropped4Lastreset00:02:18,duetoUserresetExternalBGPneighbornotdirectlyconnected.NoactiveTCPconnection

ThehighlightedoutputshowsthatBGPneighborisintheIdlestate,inwhichnoresourcesareallocatedtoBGPneighbor.ThismightbebecausetheothersidehasnotreceivedanyBGPnegotiationfromR1orbecauseR1hasnotreceivedanythingfromR2.Solution

Usetheebgp-multihopcommandtoincreasetheIPTTLvaluetothedesirednumber.Example15-13showstherequiredconfigurationonR1tobringuptheEBGPneighborR2.Example15-13Usingebgp-multihoptoIncreasetheIPTTLValue

R1#routerbgp109


Theebgp-multihop2commandsetstheIPTTLvalueto2ratherthanthedefaultof1.Thisway,ifaBGPspeakeristwohopsaway,theBGPpacketwillreachit;otherwise,itwouldhavebeendroppedbytheintermediatedevicebecauseoftheIPTTLexpiration.Example15-15showsthedebugippacketoutputandsniffercaptureinR2ofBGPpacketsfromR1toR2.ebgp-multihopissetto5,asshownintheconfigurationofExample15-14.Example15-14Settingebgp-multihopto5

R1#routerbgp109neighbor131.108.10.2remote-as110neighbor131.108.10.2ebgp-multihop5neighbor131.108.10.2update-sourceLoopback0

Example15-15debugippacketandSnifferCaptureinR2ofBGPPacketsfromR1toR2

IP:s=131.108.10.1(Ethernet0),d=131.108.10.2,len59,rcvd4TCPsrc=179,dst=13589,seq=1287164041,ack=1254239588,win=16305ACK

04009210:00000C47B94700000C09...G9G....04009220:9FEA080045C000280006000004069B2F.j..E@.(......./04009230:836C0A01836C0A0200B335154CB89089.l...l...35.L8..04009240:4AC22D6450103FB1CA17000000000000JB-dP.?1J.......04009250:0000C8..H

ThedebugshowsthatR2isreceivingaBGPpacketonTCPport179fromsource131.108.10.1(R1).Inthesniffercapture,thehighlightedhexvalue04istheIPTTLvalueof4.TheIPTTLvalueis4becauseR2decrementedtheTTLby1.Thisexampleofcapturingpacketsthroughsnifferisshowntoillustratetheuseoftheebgp-multihopcommandinBGPtoincreasetheIPTTLofaBGPpacket.NondirectlyConnectedExternalBGPNeighborsNotComingUp—Cause:update-sourceinterfaceCommandIsMissing

BydefaultinCiscoIOSSoftware,thesourceoftheBGPpacketistheoutgoinginterfaceIPaddressastakenfromtheroutingtable.InBGP,theneighbor’sIPaddressmustbestaticallydefinedinconfiguration.IfanEBGPspeakerdoesnotreceiveaBGPupdatefromaIPsourcethatisidenticaltowhatithasconfigured,itrejectsthatupdate.Theupdate-sourcecommandinBGPchangesthesourceaddressoftheIPpacket.InsteadofpickingtheoutgoinginterfaceasasourceIPaddress,BGPpacketswillbesourcedwiththeinterfaceIPaddressconfiguredwiththeupdate-sourcecommand.Figure15-7showstheflowcharttofollowtofixthisproblem.


Example15-16displaysoutputfromR1toshowsR1’sIProutingtableentryforR2’sloopback131.108.10.2andR1’soutgoinginterfaceaddresstoreachR2’sloopbackinterface.Example15-16R1IPRoutingTableEntryforR2’sLoopbackInterface

R1#showiproute131.108.10.2Routingentryfor131.108.10.2/32Knownvia"static",distance1,metric0RoutingDescriptorBlocks:*131.108.1.2Routemetricis0,trafficsharecountis1

R1#showiproute131.108.1.2Routingentryfor131.108.1.0/24Knownvia"connected",distance0,metric0(connected,viainterface)RoutingDescriptorBlocks:*directlyconnected,viaEthernet0Routemetricis0,trafficsharecountis1

R1#showinterfacesethernet0Ethernet0isup,lineprotocolisupHardwareisLance,addressis0000.0c09.9fea(bia0000.0c09.9fea)Internetaddressis131.108.1.1/24

AllIPpacketsdestinedfor131.108.10.2haveasourceaddressof131.108.1.1,whichistheoutgoinginterfaceaddressofR1,asshowninExample15-16.Example15-17showsasimpleBGPconfigurationofR1andR2(asdepictedinthenetworkinFigure15-4),peeringwitheachother’sloopback.TheconfigurationinExample15-17doesnotresultinanEBGPneighborrelationshipbecausetheIPsourceaddressofBGPpacketswon’tbewhatR2isconfiguredtoexpect.Theworkingconfigurationisshowninthe“Solution”section.Example15-17R1/R2BGPConfigurationwithPeeringwithLoopbackInterfaces

R1#routerbgp109neighbor131.108.10.2remote-as110neighbor131.108.10.2ebgp-multihop2

R2#routerbgp110neighbor131.108.10.1remote-as109neighbor131.108.10.1ebgp-multihop2

TheproblemcomesinwhenR1sendsitsBGPpacketstoitsconfiguredneighbor131.108.10.2.ThesourceIPaddressofthoseBGPpacketswillbe131.108.1.1,theoutgoinginterfaceaddress.R2isexpectingBGPpacketsfromR1withthesourceaddressofR1’sloopback131.108.10.1,thepeeringaddress,soitwillrejecttheseBGPpackets.Example15-18showstheoutputofthedebugipbgpthatshowshowR2rejectspacketsfromR1.Example15-18debugipbgpCommandOutputRevealsR2RejectingPacketsfromR1

R1#debugipbgp04:42:10:BGP:131.108.10.2openactive,localaddress131.108.1.104:42:10:BGP:131.108.10.2openfailed:Connectionrefusedbyremotehost

Solution

R1shouldbeconfiguredwiththeupdate-sourcecommand,usingtheneighborstatementforR2toacceptanyBGPpacketsfromR1.Theupdate-sourcecommandensuresthatthesourceaddressisthatofLoopback0,whichR2expects.Example15-19showsthenecessaryconfigurationadditioninR1andR2toformanEBGPmultihopneighborrelationship.Example15-19CorrectConfigurationofR1andR2toFormEBGPMultihopNeighborRelationship



Problem:InternalBGPNeighborsNotComingUpIBGPcanexperienceissuessimilartoEBGPinneighborrelationship.IBGPisanimportantpieceofoverallBGP-runningnetworks.Chapter14discussestheimportanceandusageofIBGP.ThissectionaddressessomecommonlyseenissuesexclusivetoIBGPneighborrelationshipproblems.Thecausesof

thisproblemareidenticaltothepreviousproblemofnondirectlyconnectedexternalBGPneighborsnotcomingup:•TheroutetothenondirectlyconnectedIBGPneighboraddressismissing.•Theupdate-sourceinterfacecommandismissinginBGPconfiguration.

YoucanusethesametroubleshootingandconfigurationtechniquesasthoseusedfortheEBGPproblem.

Problem:BGPNeighbors(ExternalandInternal)NotComingUp—Cause:InterfaceAccessListBlockingBGPPacketsInterfaceaccesslist/filtersareanothercommoncauseofBGPneighboractivationproblems.IfaninterfaceaccesslistunintentionallyblocksTCPpacketsthatcarryBGPprotocolpackets,theBGPneighborwillnotcomeup.Figure15-8showstheflowcharttofollowtofixthisproblem.


Example15-20showssampleaccesslist101thatexplicitlyblocksTCP.Example15-20showsaccesslist102thathasanimplicitdenyofBGPbecauseCiscoIOSSoftwarehasanimplicitdenyattheendofeachaccesslist.Bothaccesslists101and102willpreventaBGPneighborrelationshipfromcomingup.Example15-20AccessListConfigurationBlockingBGPNeighbors

R1#access-list101denytcpanyanyaccess-list101denyudpanyanyaccess-list101permitipanyany

interfaceethernet0

ipaccess-group101in

access-list102permitudpanyanyaccess-list102permitospfanyany

interfaceethernet0ipaccess-group102in

Solution

AninterfaceaccesslistmustpermittheBGPport(TCPport179)explicitlyorimplicitlytoallowneighborrelationships.Example15-21showstherevisedaccesslistconfigurationthatallowsBGP.Example15-21AccessListConfigurationPermittingBGP

R1#noaccess-list101

access-list101denyudpanyanyaccess-list101permittcpanyanyeqbgpaccess-list101permitipanyany

AllBGPpacketswillbepermittedbecauseofthesecondlineinaccesslist101.

TroubleshootingBGPRouteAdvertisement/OriginationandReceivingAnothercommonproblemafterneighborrelationshipissuesthatBGPoperatorsfaceoccursinBGProuteadvertisement/originationandreceiving.BGPoriginatesroutesonlybyconfiguration.However,itneedsnoconfigurationinreceivingroutes.LargerISPsoriginatenewBGProutesfortheircustomersonadailybasis,whereassmall-enterpriseBGPnetworksmostlyconfigureBGProuteoriginationuponfirstsetup.ProblemsinrouteoriginatingcanoccurbecauseofeitherconfigurationmistakesoralackofBGPprotocolunderstanding.ThissectionaddressesamixofsimpleandcomplicatedproblemsseeninBGProuteadvertisement/originationandreceiving.ThefollowingisalistofproblemsdiscussedinthissectionrelatedtoBGProuteoriginatingandadvertisement:•ABGProutenotgettingoriginated•Probleminpropagating/originatingaBGProutetoIBGP/EBGPneighbors•ProbleminpropagatingaBGProutetoanIBGPneighborbutnottoanEBGPneighbor•ProbleminpropagatinganIBGProutetoanIBGP/EBGPneighbor

Problem:BGPRouteNotGettingOriginatedBGPoriginatesIPprefixesandannouncesthemtoneighboringBGPspeakers(IBGPandEBGP)sothattheInternetcanreachthoseprefixes.Forexample,ifanIPaddressassociatedwithwww.cisco.comfailstooriginatebecauseofaBGPconfigurationmistakeoralackofprotocolrequirements,theInternetwillneverknowabouttheIPaddressofwww.cisco.com,resultinginnoconnectivitytothiswebsite.Therefore,itisessentialtolookatBGProute-originationissuesindetail.SeveralcausesinfailureofBGProuteoriginationexist,themostcommonofwhichareasfollows:•TheIProutingtabledoesnothaveamatchingroute.•Aconfigurationerrorhasoccurred.•BGPisautosummarizingtoaclassful/networkboundary.



BGPRouteNotGettingOriginated—Cause:IPRoutingTableDoesNotHaveaMatchingRoute

BGPrequirestheIProutingtabletohaveanexactmatchingentryfortheprefixthatBGPistryingtoadvertiseusingnetworkandredistributecommand.TheprefixandmaskofthenetworkthatBGPistryingtoadvertisemustbeidenticalintheIProutingtableandintheBGPconfiguration.BGPwillfailtooriginateanyprefixrelatedtothisnetworkifthisdiscrepancyexists.Figure15-9showstheflowcharttofollowtofixthisproblem.


ThissectionassumesthattherearenomistakesinBGPconfiguration.Case1:MatchingRouteDoesNotExistintheRoutingTable

Example15-22showsthatBGPisconfiguredtoadvertise100.100.100.0/24butfailstodosobecausetheroutingtabledoesnotcontainanexactmatchfortheprefixadvertised.Example15-22RoutingTableLackstheExactPrefixThatBGPIsTryingtoAdvertise

routerbgp109nosynchronizationnetwork100.100.100.0mask255.255.255.0neighbor131.108.1.2remote-as109


R1#showipbgp100.100.100.0%Networknotintable

BGPdoesnotconsider100.100.100.0/24asacandidatetoadvertisebecauseitsexactmatchdoesnot

existintheIProutingtable.ThehighlightedportionofExample15-22showsthattheIProutingtabledoesnothave100.100.100.0/24;therefore,BGPfailedtocreateanentryeventhoughitwasproperlyconfigured.Case2:RouteExistsintheIPRoutingTablebutMasksDifferfromWhatIsintheIPRoutingTableandWhatIsintheBGPConfiguration

ThisisanotherscenarioinwhichBGPfailstooriginateanIPprefix,evenwithproperconfiguration.TheBGPconfigurationisthesameastheconfigurationinExample15-22.Example15-23showsamismatchbetweentheprefixmaskintheIProutingtableentryandtheBGPconfiguration.Example15-23MismatchBetweenPrefixMaskinIPRoutingTableEntryandBGPConfiguration

R1#showiproute100.100.100.0Routingentryfor100.100.100.0/23Knownvia"static",distance1,metric0(connected)RoutingDescriptorBlocks:*directlyconnected,viaNull0Routemetricis0,trafficsharecountis1


Again,BGPdoesnotconsider100.100.100.0/24asacandidatetoadvertise.AlthoughtherouteexistsintheIProutingtable,themaskdiffers.TheIProutingtableentryfor100.100.100.0hasamaskof23,whereasBGPconfigurationhasamaskof24.TheadvertisedBGProutemustappearintheBGPtableoftheoriginatorrouterbeforereceiptbyBGPneighbors.Solution

IdenticaladvertisingBGProutesmustexistintheIProutingtablewhennetworkandredistributecommandsareused.TheIProutingtablelearnssuchrouteseitherdynamicallythrougharoutingprotocolorbyastaticroute.Commonly,BGPoperatorsdefineastaticroutefortheprefixbeingadvertised.Thisway,theIProutingtableisguaranteedtohaveavalidIProutingtableentryoftheadvertisedprefix.Toadvertise100.100.100.0/24,forexample,asamplestaticrouteandcorrespondingBGPwouldlooklikeExample15-24.Example15-24StaticRouteConfigurationtoMatchBGPAdvertisement

iproute100.100.100.0255.255.255.0null0

routerbgp109network100.100.100.0mask255.255.255.0

AsExample15-24demonstrates,null0isusedasanexthopofthestaticroute.Notrafficshouldeverfollowthisstaticroutebecauseitwillbesenttothebitbucket.Itisassumedthatamorespecificrouteof100.100.100.0/24existsintheIProutingtable.BGPRouteNotGettingOriginated—Cause:ConfigurationError

ConfigurationmistakesoftencauseBGPfailuretoadvertiseIPprefixes.MultiplewaystooriginateIPprefixesinBGPexist,andeachmethodrequiresstrictsyntaxinconfiguration.Therefore,itisessentialthatBGPoperatorsthoroughlyunderstandCiscoIOSSoftwareconfigurationguidelines.



ThreewaysexisttooriginateprefixesinBGP:•Useanetworkstatement.•Useanaggregatestatement.•Redistributeotherprotocol/staticroutesinBGP.

InCiscoIOSSoftware,BGPrequirestheconfigurationtohaveproperBGPsyntaxandcommandstoadvertiseanyroutetoIBGP/EBGPneighbors.Cases1,2,and3thatfollowshowmisconfigurationofBGPinadvertising100.100.100.0/24inallmethods.Case1:BGPPrefixOriginationwiththenetworkStatement

Example15-25showsamisconfigurationinBGPtoadvertise100.100.100.0/24usingthenetworkstatement.Example15-25ImproperlyConfiguringBGPtoAdvertise100.100.100.0/24UsingthenetworkStatement

routerbgp109nosynchronizationnetwork100.100.100.0mask255.255.255.0neighbor131.108.1.2remote-as109

iproute100.100.100.0255.255.254.0null0

Thestaticroutefor100.100.100.0hasamaskof23,whereasBGPisconfiguredtoadvertise24.

Therefore,BGPwillnotconsider/24asavalidadvertisementbecauseanexactmatchdoesnotexistintheroutingtable.Case2:BGPPrefixOriginationwiththeaggregate-addressCommandExample15-26showsthecorrectconfigurationofBGPtoadvertise100.100.100.0/24,butthisconfigurationfailstocreateanadvertisementinBGP.Theexplanationbehindthisfailureisthattheaggregate-addressconfigurationrequirestheBGPtabletocontainatleastoneroutethatismorespecificthantheaggregate.Example15-26ConfiguringBGPtoAdvertise100.100.100.0/24Usingtheaggregate-addressStatement

routerbgp109nosynchronizationaggregate-address100.100.100.0255.255.255.0neighbor131.108.1.2remote-as109

TheconfigurationinExample15-26assumesthatBGPalreadycontains100.100.100.0/24orahighermaskinitstable.Theaggregate-addressconfigurationwillfailifthisconditionfails,resultinginthefollowingoutput:


TheoutputinExample15-27revealsthatamorespecificrouteof100.100.100.0/24existsas100.100.100.128/25intheBGPtable.Example15-27AMoreSpecificBGPRoutingTableEntryExists

R1#showipbgp100.100.100.128255.255.255.128BGProutingtableentryfor100.100.100.128/25,version4Paths:(1available,best#1)

Advertisedtononpeer-grouppeers:172.16.126.2Local0.0.0.0from0.0.0.0(172.21.53.142)OriginIGP,metric0,localpref100,weight32768,valid,sourced,local,best

Thegoalistosummarizeall100.100.100.xBGPadvertisementsinto100.100.100.0/24andtoadvertiseonlythissummarizedroutetoBGPneighbors.TheconfigurationinExample15-28demonstrateshowanaggregateaddresscanbeusedtogenerateasummarizedrouteof100.100.100.0/24.Example15-28AggregateAddressCreatesaSummarizedIPPrefixinBGP

R1#routerbgp109network100.100.100.128mask255.255.255.128aggregate-address100.100.100.0255.255.255.0summary-only

R1#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version3Paths:(1available,best#1)Advertisedtononpeer-grouppeers:172.16.126.2Local,(aggregatedby109172.21.53.142)0.0.0.0from0.0.0.0(172.21.53.142)

OriginIGP,localpref100,weight32768,valid,aggregated,local,atomic-aggregate,best

ThehighlightedportionshowsthatAS109isdoingtheaggregationof100.100.100.0/24.Case3:BGPPrefixOriginationbyRedistributingDynamicProtocolsorStaticRoutes

YoucanconfigureBGPtoredistributeanydynamicroutingprotocol,suchasOSPF,orstaticroutestooriginateanyroute.CiscoIOSSoftwarestrictlycheckssuchaconfigurationandexpectsconfigurationguidelinestobemetfortheadvertisementofanyredistributedroute.Example15-29showsasampleOSPFredistributionexample.Example15-29OSPFRedistributionExampleinBGP

routerbgp109nosynchronizationredistributeospf100metric2matchinternalexternal1external2

TheredistributioncommandsinExample15-29redistributesintoBGPanyOSPFrouteintheIProutingtablethatisinternal(OSPFintra-orinterarea),orexternal(OSPFE1andE2)toanyroutewithaMEDof2.Solution

Allthreemethodscommonlyareused,butCases1and2offerthemoststabilityinBGPadvertisement.Case3requiresredistributionofanIProutingtablelearnedbysomeotherIGPprotocolorstaticroutesinBGP.AnyflappinginIGPorstaticroutesresultsinBGPchurn.Typically,BGPoperatorscreatestaticroutesforthenetworkblocksthattheyintendtooriginateinBGPanduseCase1orCase2tooriginatethoseroutes.

BGPRouteNotGettingOriginated—Cause:BGPIsAutosummarizingtoClassful/NetworkBoundarySometimes,classfulnetworksareadvertisedinBGPwhenotherroutingprotocolsareredistributedinBGP.Forexample,BGPmightbetryingtoredistribute100.100.100.0/24,butonly100.0.0.0/8getsadvertised.Anotherexamplecouldbethat131.108.0.0/16isadvertisedwhere131.108.5.0/24wasredistributed.BGPautosummarizessubnettedroutestotheirnetworkboundarieswhenredistributedintoBGPfromanyotherroutingprotocol.Forexample,subnettedClassAroutesautomaticallyaresummarizedtotheClassAmask/8whenredistributedinBGPfromanyotherprotocol.Figure15-11showstheflowcharttofollowtofixthisproblem.


Example15-30showsanexampleinwhichR1hasastaticroutefor100.100.100.0/24and131.108.5.0/24.NoticethatthesearesubnettedClassAandBroutes,respectively.WhenthesestaticroutesareredistributedinBGP,BGPautosummarizesthemtotheirnaturalclassmasks,whichare8and16respectively.Example15-30showstherelativeconfigurationinR1toredistributethesestaticroutesinBGP;italsodisplaystheBGPtableoutputfortheseadvertisements.Example15-30ConfiguringRedistributionofStaticRoutesinBGP

R1#routerbgp109nosynchronizationredistributestaticneighbor131.108.1.2remote-as109

iproute100.100.100.0255.255.255.0Null0iproute131.108.5.0255.255.255.0Null0

R1#showipbgp100.100.100.0BGProutingtableentryfor100.0.0.0/8,version2Paths:(1available,best#1,tableDefault-IP-Routing-Table)Advertisedtononpeer-grouppeers:131.108.1.2Local0.0.0.0from0.0.0.0(1.1.1.1)Originincomplete,metric0,localpref100,weight32768,valid,sourced,best

R1-2503#showipbgp131.108.5.0BGProutingtableentryfor131.108.0.0/16,version3Paths:(1available,best#1,tableDefault-IP-Routing-Table)

Advertisedtononpeer-grouppeers:131.108.1.2Local0.0.0.0from0.0.0.0(1.1.1.1)Originincomplete,metric0,localpref100,weight32768,valid,sourced,best

Notethemaskintheoutput./24staticroutesaresummarizedtothenetworkboundaryofClassAandClassB,respectively.Solution

IPprefixesneedtobeadvertisedwiththeiroriginalmasks.Oneexceptioniswhenmanualsummarizationisdone.TheproblemofBGPadvertisingclassfulnetworksafterredistributioncanbeovercomebydisablingtheautosummarizationfeatureinBGP.Example15-31showsthenecessaryconfigurationtoachievethis;italsoshowstheBGPadvertisementintheBGPtableafterthischange.Example15-31DisablingAutosummarizationinBGP

R1#routerbgp109nosynchronizationredistributestaticnoauto-summary

R1#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version4Paths:(1available,best#1,tableDefault-IP-Routing-Table)Flag:0x208Advertisedtononpeer-grouppeers:131.108.1.2Local0.0.0.0from0.0.0.0(1.1.1.1)Originincomplete,metric0,localpref100,weight32768,valid,sourced,best

R1#showipbgp131.108.5.0BGProutingtableentryfor131.108.5.0/24,version6Paths:(1available,best#1,tableDefault-IP-Routing-Table)Flag:0x208Advertisedtononpeer-grouppeers:131.108.1.2Local0.0.0.0from0.0.0.0(1.1.1.1)Originincomplete,metric0,localpref100,weight32768,valid,sourced,best

Notethemasksintheoutput—theyareexactlywhattherewereconfiguredoriginally.Inmostcases,itwouldbedesirabletoturnoffautosummarizationsothatpropermaskroutescanbeadvertisedtoBGPneighbors.AutosummarizationplaysaroleonlywhenanyotherprotocolroutesareredistributedintoBGP.BecauseitisnotcommonpracticetoredistributeotherprotocolsintoBGP,theautosummarizationfeatureisnotusedmuch.

ProbleminPropagating/OriginatingBGPRoutetoIBGP/EBGPNeighbors—Cause:MisconfiguredFiltersAscenariomightariseinwhichtheBGPconfigurationtooriginateandpropagaterouteslooksgood,butBGPneighborsarenotreceivingtheroutes.Theoriginator’sBGPtableshowsalltheroutes.Thereisapossibilitythatconfiguredfiltersarethecauseoftheproblem.WhenimplementingBGPinCiscoIOSSoftware,operatorshavemanyoptionstoconfigurefiltersto

controlwhichroutestopropagatetowhichneighbors.Thesefilterscouldbefairlystraightforwardorcouldgetverycomplex.MinorerrorscanresultinundesirableroutedenialoradvertisementtoBGPspeakers.Figure15-12showstheflowcharttofollowtofixthisproblem.


Chapter14discussesusingfiltersinBGP.Discussingeverysinglefilterisoutsidethescopeofthisbook;however,someofmostcommonlyseenreal-worldfilteringmistakesandmisconceptionsarediscussed.Usingadistributelistallowsforstandardaccesslists(1to99)andextendedaccesslists(100to199).Example15-32givesasampleconfigurationofboth.Example15-32SampleDistributeListConfigurationUsingStandardandExtendedAccessLists

R1#access-list1permit100.100.100.0

routerbgp109nosynchronizationneighbor131.108.1.2remote-as109neighbor131.108.1.2distribute-list1out

R1#access-list101permitiphost100.100.100.0host255.255.255.0

routerbgp109nosynchronizationneighbor131.108.1.2remote-as109neighbor131.108.1.2distribute-list101out

Onecommonmistakethatoperatorsmakeisnotrealizingthatthereisanimplicitdenyattheendofeachaccesslist.Allnetworksaredeniedexceptforthosethatareexplicitlypermittedintheaccesslist.Also,standardandextendedaccesslistsaretreateddifferentlywhenitcomestoBGPfilters.Instandardaccess

lists,themaskportionisnotcheckedandonlytheprefixportionischecked.Forexample,inthefollowingaccesslist,100.100.100.0couldhaveanymask—/24,/26,andsoon:


Inthefollowingaccesslist,ontheotherhand,themaskof100.100.100.0mustbe/24andnothingelse:access-list101permitiphost100.100.100.0host255.255.255.0

Similarly,whenothermethodsareappliedtofilterBGPupdates—namely,filterlists,prefixlists,routemaps,distributelists,andsoon—caremustbetakentounderstandthebehaviorofeachmethod.ItisbeyondthescopeofthisbooktogoovereachfilteringmethodthatCiscooffers,butrefertothesection,“TroubleshootingBGPFiltering.”Solution

AsdiscussedinChapter14,thereareseveralotherwaystofilterBGPupdates,andcaremustbetakenintermsofwhatexactlyisconfigured.EachkindoffilteroffersthepowertocontroltheBGPadvertisement,butimproperorincorrectusecanresultinincorrectorincompleteadvertisements.

ProbleminPropagatingBGPRoutetoIBGPNeighborbutNottoEBGPNeighbor—Cause:BGPRouteWasfromAnotherIBGPSpeakerInsomecases,certainroutesarenotpropagatedtoIBGPneighborsbutarepropagatedonlytoEBGPneighbors.WhenIBGPspeakersinanASarenotfullymeshedandhavenoroutereflectororconfederationconfiguration,anyroutethatislearnedfromanIBGPneighborwillnotbegiventoanyotherIBGPneighbor.SuchroutesareadvertisedonlytoEBGPneighbors,asillustratedinFigure15-13.Chapter14explainsusingroutereflectorsandconfederations.Youalsocanfindinformationonthistopicinthe“TroubleshootingBGPWhenRouteReflectorsAreUsed”section,laterinthischapter.

Figure15-13IBGPNetworkinWhichIBGPRoutesAreNotPropagatedtoOtherIBGPSpeakers



Example15-33showsthenecessaryconfigurationtohaveanIBGPrelationshipbetweenR8toR1andR1toR2.ThisexamplealsoshowsasampleconfigurationofR8advertising100.100.100.0/24toR1.Example15-33ConfiguringanIBGPRelationshipBetweenR8/R1andR1/R2

R8#routerbgp109nosynchronization

network100.100.100.0mask255.255.255.0neighbor206.56.89.2remote-as109

iproute100.100.100.0255.255.255.0Null0

R1#routerbgp109nosynchronizationneighbor131.108.1.2remote-as109neighbor206.56.89.1remote-as109

R2#routerbgp109nosynchronizationneighbor131.108.1.1remote-as109

Example15-33showsthattheIBGPnetworkisnotfullymeshedandthattheIBGP-learnedroutewillnotbegiventoanyotherIBGPneighbor.Example15-34showsBGPtableoutputfromR8,R1,andR2,respectively.R8isadvertising100.100.100.0/24,whichshowsupinitsBGPtableandinR1’stable.IntheoutputofR1,noticethehighlightedoutput“Notadvertisedtoanypeer.”AlthoughR1andR2areIBGPneighbors,R1doesnotadvertise100.100.100.0/24toR2anditislearnedfromanotherIBGPneighbor,R8.

Example15-34R8,R1,andR2BGPTablesShowThatanIBGP-LearnedRouteinR1WillNotBeGiventoIBGPNeighborR2

R8#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version3Paths:(1available,best#1,tableDefault-IP-Routing-Table)Advertisedtononpeer-grouppeers:206.56.89.2Local0.0.0.0from0.0.0.0(8.8.8.8)OriginIGP,metric0,localpref100,weight32768,valid,sourced,local,best

R1#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version9Paths:(1available,best#1,tableDefault-IP-Routing-Table)NotadvertisedtoanypeerLocal206.56.89.1from206.56.89.1(8.8.8.8)OriginIGP,metric0,localpref100,valid,internal,best

R1#showipbgpsummaryBGProuteridentifier1.1.1.1,localASnumber109BGPtableversionis11,mainroutingtableversion111networkentriesand1pathsusing133bytesofmemory1BGPpathattributeentriesusing52bytesofmemory0BGProute-mapcacheentriesusing0bytesofmemory0BGPfilter-listcacheentriesusing0bytesofmemoryBGPactivity24/237prefixes,35/34paths,scaninterval15secsNeighborVASMsgRcvdMsgSentTblVerInQOutQUp/DownState/PfxRcd131.108.1.241094304431911001d20h0206.56.89.14109108110110001:44:161


IntheoutputofR1,“Notadvertisedtoanypeer”meansthateventhoughR2istheneighbor,itisanIBGPneighborand100.100.100.0/24willnotbeadvertised.ThisrulecomesfromRFC1771section9.2.1,titled“InternalUpdates”:WhenaBGPspeakerreceivesanUPDATEmessagefromanotherBGPspeakerlocatedinitsownautonomoussystem,thereceivingBGPspeakershallnotredistributetheroutinginformationcontainedinthatUPDATEmessagetootherBGPspeakerslocatedinitsownautonomoussystem.

Solution

ItisessentialthatIBGP-learnedroutesarepropagatedtootherBGPspeakers.BGPoperatorscanusethreemethodstoaddressthisproblem:•UseIBGPfullmesh.•Designaroute-reflectormodel.•Designaconfederationmodel.

IBGPFullMesh

HavinganIBGPfullmeshisunacceptableeveninasmallISPnetwork.ForlargerISPsthatmaintainseveralhundredBGPspeakers,IBGPfullmeshwouldharmthemmorethanprovidingbenefit.Therefore,savvyBGPoperatorstypicallydonotchoosethismethod.Chapter14explainsthisisgreaterdetail.

DesigningaRoute-ReflectorModel

RFC1966discussesamodeltoavoidIBGPfullmeshbyintroducingtheconceptofroute-reflectorserversandroute-reflectorclients.ServerspeerBGPwithallclientsinthecluster.Aclusterisasetofserversandclients.ClientspeerBGPonlywithservers.ClientsadvertiseBGPupdatestoservers,andserversthenreflectthemtootherclients.InFigure15-15,R1actastheserverandR8andR2actasclients.R1,R2,andR8formacluster.RefertoChapter14toundersatndRoute-Reflectionindetail.

Figure15-15Route-ReflectorModeltoAvoidFull-MeshIBGP

Example15-35showstherelevantconfigurationtomakeR1theroute-reflector.Route-reflectorclientsneednoadditionalconfigurationotherthanwhatisalreadyshowninExample15-33.Example15-35ConfiguringR1astheRouteReflectorandR2andR8asRoute-ReflectorClients

R1#routerbgp109nosynchronizationneighbor131.108.1.2remote-as109neighbor131.108.1.2route-reflector-clientneighbor206.56.89.1remote-as109neighbor206.56.89.1route-reflector-client

TheoutputinExample15-36showsthatR1receives100.100.100.0/24fromR8andadvertisestoR2(131.108.1.2).NoticethatthiswasnotthecaseintheoriginalprobleminFigure15-13.Example15-36alsoshowsthatR2receives100.100.100.0/24fromR1.Example15-36BGPTableOutputtoDisplayHowRouteReflectorsSolvedtheIBGPUpdateFailureProblem

R1#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version13

Paths:(1available,best#1,tableDefault-IP-Routing-Table)Flag:0x208Advertisedtononpeer-grouppeers:131.108.1.2Local,(ReceivedfromaRR-client)206.56.89.1from206.56.89.1(8.8.8.8)OriginIGP,metric0,localpref100,valid,internal,best

R2#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version35Paths:(1available,best#1,tableDefault-IP-Routing-Table)Flag:0x208NotadvertisedtoanypeerLocal206.56.89.1from131.108.1.1(8.8.8.8)OriginIGP,metric0,localpref100,valid,internal,bestOriginator:8.8.8.8,Clusterlist:1.1.1.1

ThehighlightedsectioninR1’soutputshowsthatitisadvertising100.100.100.0/24toR2,itsIBGPneighbor,whichwasnotthecaseinExample15-34.DesigningaConfederationModel

RFC1965explainshowanASconfederationforBGPcanavoidfullIBGPmesh.Withconfederations,theBGPnetworkisdividedintosmallsub–autonomoussystems.Thesesub–autonomoussystemsareconnectedtoothersub–autonomoussystems.Thesesub–autonomoussystemsneednotbefullymeshed.BGPspeakerswithinasub–autonomoussystemmusthaveafullmeshofIBGP.Ifthenumberofsub–autonomoussystemsgrowstoalargenumberofIBGPspeakers,sub–autonomoussystemIBGPspeakersuseroutereflectors.AllrouterstakeaconfigurationchangewhenmovedfromanIBGPmodeltoaconfederationmodel.RefertoChapter14tounderstandConfederationindetail.Figure15-16showsthatR1andR2arecombinedinasub-ASandthatR8isinitsownsub-AS.

Figure15-16ConfederationModel

Example15-37highlightsallthechangesintheconfigurationofRoutersR1,R2,andR8.Example15-37ConfiguringtheNetworkofR1,R2,andR8asaConfederationModel

R8#routerbgp65201bgpconfederationidentifier109bgpconfederationpeers6520065201network100.100.100.0mask255.255.255.0neighbor206.56.89.2remote-as65200

iproute100.100.100.0255.255.255.0Null0

R1#routerbgp65200

bgpconfederationidentifier109bgpconfederationpeers6520165200neighbor131.108.1.2remote-as65200neighbor206.56.89.1remote-as65201

R2#routerbgp65200nosynchronizationbgpconfederationidentifier109bgpconfederationpeers6520065201neighbor131.108.1.1remote-as65200

Example15-37showsasignificantchangeinBGPconfigurationofRoutersR1,R2,andR8.WhenaBGP

networkmigratestoaconfederation,allroutersneedconfigurationchanges.InExample15-37,confederationidentifierrepresentsthatrealASofthenetwork;theconfederationpeerscommandliststhepeeringconfederationsub-ASintheBGPnetwork.Theconfederationsub-ASisconfiguredwiththerouterbgpcommand.AllBGPupdatessenttootherconfederationsaresentwithaconfederationsub-ASlistsimilartotheAS_PATHlist,butupdatestoEBGPneighborsaresentwiththerealASnumber.Aprefixreceivedfromtheoutsideconfederationsub-ASisadvertisedtoallconfederationneighbors,internalorexternal,resultinginprefixpropagation—thiswasnotpossibleinpartiallymeshedIBGP.Totheoutsideworld,aconfederationhasnovaluebecauseitisatechniqueusedlocallyintheBGPnetworktoreduceanIBGPmesh.Example15-38showstheoutputoftheBGPtablefromeachrouter.Example15-38BGPTablesfromtheRoutersinaBGPConfederation

R8#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version2Paths:(1available,best#1,tableDefault-IP-Routing-Table)Advertisedtononpeer-grouppeers:206.56.89.2Local0.0.0.0from0.0.0.0(8.8.8.8)OriginIGP,metric0,localpref100,weight32768,valid,sourced,local,best

R1#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version2Paths:(1available,best#1,tableDefault-IP-Routing-Table)Advertisedtononpeer-grouppeers:131.108.1.2(65201)206.56.89.1from206.56.89.1(8.8.8.8)OriginIGP,metric0,localpref100,valid,confed-external,best

R2#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version2Paths:(1available,best#1,tableDefault-IP-Routing-Table)Flag:0x208Notadvertisedtoanypeer(65201)206.56.89.1from131.108.1.1(1.1.1.1)OriginIGP,metric0,localpref100,valid,internal,best

R8isadvertising100.100.100.0/24toR1.InR1’soutput,thehighlightedlineshowstheconfederationsub-AS,65201,that100.100.100.0/24updatehastraversed.Thisisthesub-ASthathasR8init.R1advertisesthisupdatetoR2becausethisupdatecamefromanotherconfederationsub-AS.ThissetupsidestepstheneedforafullmeshofR1,R2,andR8,whichotherwisewasneededtopropagate100.100.100.0/24fromR8toR2.

ProbleminPropagatingIBGPRoutetoIBGP/EBGPNeighbor—Cause:IBGPRouteWasNotSynchronizedAscenariomightariseinwhichanIBGPlearnedrouteisnotpropagatedtoanyBGPneighbor,whetherIBGPorEBGP.OnecasecouldbethatwhenanIBGP-learnedrouteisnotsynchronized,thatrouteisnotconsideredasacandidatetoadvertisetootherBGPneighbors.AsyourememberfrompreviousdiscussionsinChapter14,aBGProuteissynchronizedonlyifithasbeenlearnedthroughanIGPorastaticroutefirst.

InCiscoIOSSoftware,BGPadvertisesonlywhatitconsidersthebestpathtoitsneighbors.IfanIBGPpathisnotsynchronized,itisnotincludedinthebestpathcalculation.Figure15-17showstheflowcharttofollowtofixthisproblem.


ReferbacktoChapter14fordetailsabouttherulesforsynchronization.Example15-39showshowanunsynchronizedroutewouldappearinBGPtable.Example15-39BGPTablewithUnsynchronizedRoute

R2#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version3Paths:(1available,nobestpath)Flag:0x208Notadvertisedtoanypeer(65201)206.56.89.1from131.108.1.1(1.1.1.1)OriginIGP,metric0,localpref100,valid,internal,notsynchronized

ThehighlightedoutputinExample15-39showsthatR2didnotconsider100.100.100.0/24assynchronizedandfailedtoinstallitintheroutingtable;therefore,itdidnotadvertisetheroutetoanypeer.Solution

AsdiscussedinChapter14,eitherturnoffsynchronizationormaketheroutessynchronizedbyredistributingthemintheIGPattherouterthatfirstintroducedthisrouteinIBGPdomain.Thefollowingselectionhasanexampletoaccomplishthis.

TroubleshootingBGPRouteNotInstallinginRoutingTable

ThissectiondiscussesissuesrelatedtoBGProutesnotgettinginstalledintheIProutingtable.IfaroutermustforwardanIPpacketbylookingattheIPdestinationaddressinIPpacket,theroutermusthaveanIProutingtableentryforthesubnetoftheIPdestinationaddress.IftheBGPprocessfailstocreateanIProutingtableentry,alltrafficdestinedformissingIPsubnetsintheroutingtablewillbedropped.Thisisagenericbehaviorofhop-by-hopIPpacketforwardingdonebyrouters.ProblemsinthissectionassumethattheBGPtablehasalltheupdatesforIPprefixesbutthatBGPisnotinstallingtheminIProutingtable.Followingisthelistofallproblemsdiscussedinthissection:•AnIBGP-learnedrouteisnotgettinginstalledintheIProutingtable.•AnEBGP-learnedrouteisnotgettinginstalledintheIProutingtable.

Problem:IBGP-LearnedRouteNotGettingInstalledinIPRoutingTableThemostcommoncausesofthisproblemareasfollows:•IBGProutesarenotsynchronized.•TheBGPnexthopisnotreachable.

Thesectionsthatfollowdiscussthesecausesandhowtoresolvetheproblembasedonthecause.IBGP-LearnedRouteNotGettingInstalledinIPRoutingTable—Cause:IBGPRoutesAreNotSynchronized

IBGPwillnotinstallorpropagatearoutetootherBGPspeakersunlessIBGP-learnedroutesaresynchronized.SynchronizationmeansthatforanIBGP-learnedroute,theremustexistanidenticalrouteintheIProutingtableprovidedbyanIGP(OSPF,IS-IS,andsoon).ThismeansthattheIGPmustholdallexternalBGProutinginformation.ThiscanbeaccomplishedbyredistributingEBGPintoanIGPattheborderroutersofanAS.InFigure15-18,R1isoriginating100.100.100.0/24toitsIBGPneighbor,R2(13.108.10.2).R2isconfiguredtoformIBGPneighborswithR1andisoriginatingnothing.

Figure15-18R1Advertising100.100.100.0/24toIBGPNeighborR2,WhichChecksfor

SynchronizationofBGPRoutes

Figure15-19showstheflowcharttofollowtoresolvethisproblem.


Example15-40istherelevantBGPconfigurationneededinR1andR2tooriginateandreceive100.100.100.0/24throughIBGP.Example15-40ConfiguringR1andR2toOriginateandReceive100.100.100.0/24ThroughIBGP

R1#routerbgp109network100.100.100.0mask255.255.255.0neighbor131.108.10.2remote-as109neighbor131.108.10.2update-sourceLoopback0

iproute100.100.100.0255.255.255.0Null0

R2#routerbgp109neighbor131.108.10.1remote-as109neighbor131.108.10.1update-sourceLoopback0

Example15-41showsthatR2hasreceivedanIBGPupdatefor100.100.100.0/24.Example15-41R2’sBGPRoutingTableEntryIndicatesThatanIBGPUpdateWasReceivedfor100.100.100.0/24

R2#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version3Paths:(1available,nobestpath)Flag:0x208NotadvertisedtoanypeerLocal131.108.10.1from131.108.10.1(131.108.10.1)

OriginIGP,metric0,localpref100,valid,internal,notsynchronizedR2#showiproute100.100.100.0%Networknotintable

TheoutputinExample15-41alsoexplainsthatBGPfindsnobestpathcandidatetobeinstalledinIProutingtable.ThereasonisthatthisparticularBGPupdateisnotsynchronized.Solution

Anetworkoperatorcanchoosetoworkaroundthisproblemintwoways:•SynchronizeallBGProutes.•Turnoffsynchronization.

SynchronizingAllIBGPRoutes

Thesolutionofturningoffsynchronizationneedsnofurtherexplanation.SynchronizingallBGProutes,however,requiressomemoredetailedcoverage.Tosynchronize100.100.100.0/24,R1mustadvertisethisrouteinitsIGPsothatR2canreceiveitthroughbothIBGPandIGP.Example15-42showsthatR1isadvertisingthisroutebyredistributingstaticroutesinOSPF,andR2receivesitasanexternalOSPFrouteandinnormalIBGPaswell.Example15-42ConfigurationNeededtoAdvertiseAllRoutesAdvertisedThroughIBGPandIGP(OSPF)

R1#routerospf1redistributestaticsubnetsnetwork131.108.1.00.0.0.255area0

R1#routerbgp109network100.100.100.0mask255.255.255.0neighbor131.108.10.2remote-as109neighbor131.108.10.2update-sourceLoopback0iproute100.100.100.0255.255.255.0Null0

TheconfigurationinExample15-42showsthatOSPFisredistributingstaticroutes;theonlystaticrouteshownis100.100.100.0/24.BGPisalsoadvertisingthesameprefixtoR2,asdemonstratedinExample15-43.Example15-43OutputtoShowR2IsReceivingaSynchronizedIBGPRoutefromR1

R2#showiproute100.100.100.0Routingentryfor100.100.100.0/24Knownvia"ospf1",distance110,metric20,typeextern2,forwardmetric10Redistributingviaospf1Lastupdatefrom131.108.1.1onEthernet0,00:07:21agoRoutingDescriptorBlocks:*131.108.1.1,from131.108.10.1,00:07:21ago,viaEthernet0Routemetricis20,trafficsharecountis1R2#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version4Paths:(1available,best#1,tableDefault-IP-Routing-Table)Flag:0x208NotadvertisedtoanypeerLocal131.108.10.1from131.108.10.1(131.108.10.1)OriginIGP,metric0,localpref100,valid,internal,synchronized,best

InExample15-43,BGPnowmarksthisrouteassynchronizedandwillinstallthisrouteinitsIProuting

table.ItalsowillpropagatethisroutetootherBGPspeakers.InExample15-43,theroutingtablechoosestheOSPFrouteinsteadoftheIBGProutebecauseoftheloweradministrativedistanceof110over200.

NoteInthecaseofOSPF,CiscoIOSSoftwareexpectstheOSPFrouterID(RID)andtheBGPRIDforR1,theadvertisingrouter,tobeidenticalforsynchronizationtoworkproperly.ThereisnosuchrestrictionforanyotherIGPs.

TurningOffSynchronization

ThismethodiswidelyusedinalmostallBGPnetworks.Example15-44providesthenecessaryconfigurationtoaccomplishthis.Example15-44TurningOffSynchronization

R2#routerbgp109nosynchronization

Asseenintheprevioussection,allroutesinBGPmustalsoberedistributedinIGPtohavesynchronizationintheIBGPnetwork.WiththesizeofBGPtablesthesedays(morethan110,000entries),itisnotrecommendedthatyouredistributeallBGProutesintoanIGP.Therefore,itbecomescommonpracticetoturnoffsynchronizationinstead.

IBGP-LearnedRouteNotGettingInstalledinIPRoutingTable—Cause:IBGPNextHopNotReachableThecauseofthisproblemismostcommoninIBGP-learnedrouteswhereBGPnexthopaddressshouldhavebeenlearnedthroughanInteriorGatewayProtocol(IGP).FailuretoreachthenexthopisanIGPproblem,andBGPismerelyavictim.WithBGP,whenIPprefixesareadvertisedtoanIBGPneighbor,theNEXTHOPattributeoftheprefixdoesnotchange.TheIBGPreceivermusthaveanIProutetoreachthisnexthop.Figure15-20showstheflowcharttofollowtoresolvethisproblem.


Figure15-21showsthatNEXTHOPofBGProutesadvertisedtoIBGPneighborsarenotchangedandmightresultinrouteinstallationfailure.

Figure15-21NexthopofBGPRoutesAdvertisedtoIBGPNeighborsIsNotChangedandMightResultinRouteInstallationFailure


Example15-45showsthatR8isadvertisingthe100.100.100.0/24routetoitsEBGPpeerR1,whichwilladvertisethisroutetoR2.However,onR2,theproblemofthenexthopappears.Example15-45showstherelevantconfigurationofR8,R1,andR2.Example15-45ConfigurationNeededinR1,R2,andR8toFormNeighborRelationshipandOriginate

andPropagate100.100.100.0/24

R8#routerbgp110nosynchronizationnetwork100.100.100.0mask255.255.255.0neighbor206.56.89.2remote-as109

iproute100.100.100.0255.255.255.0Null0

R1#routerbgp109nosynchronizationneighbor131.108.10.2remote-as109neighbor131.108.10.2update-sourceLoopback0neighbor206.56.89.1remote-as110

R2#routerbgp109nosynchronizationneighbor131.108.10.1remote-as109neighbor131.108.10.1update-sourceLoopback0

TheconfigurationinExample15-45showsthatR8hasoneEBGPneighbor,R1,whichhasR8andR2asEBGPandIBGPneighbors,respectively.R2hasR1asanIBGPneighbor.R8isadvertising100.100.100.0/24toR1,andR1willpropagatethattoR2asanIBGPadvertisement.Example15-46showsthatR1receivesthisroute,installsitinitsroutingtable,andpropagatesittoR2131.108.10.2.Example15-46R1ReceivestheRouteandPropagatesIttoR2

R1#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version2Paths:(1available,best#1,tableDefault-IP-Routing-Table)Advertisedtononpeer-grouppeers:131.108.10.2110206.56.89.1from206.56.89.1(100.100.100.8)OriginIGP,metric0,localpref100,valid,external,best

R1#showiproute100.100.100.0Routingentryfor100.100.100.0/24Knownvia"bgp109",distance20,metric0Tag110,typeexternalLastupdatefrom206.56.89.100:04:50agoRoutingDescriptorBlocks:*206.56.89.1,from206.56.89.1,00:04:50agoRoutemetricis0,trafficsharecountis1ASHops1

ThehighlightedoutputshowsthatR1isadvertising100.100.100.0/24to131.108.10.2,whichisR2.InFigure15-21,R2isanIBGPpeerofR1,whichadvertises100.100.100.024toR2.ThenR2receivesthisBGProutewithaNexthopof206.56.89.1butfailstoinstall100.100.100.024initsroutingtable,asdemonstratedinExample15-47.Example15-47R2FailstoInstallthe100.100.100.0/24RouteinItsRoutingTable

R2#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version0

Paths:(1available,nobestpath)Notadvertisedtoanypeer110206.56.89.1(inaccessible)from131.108.10.1(131.108.10.1)OriginIGP,metric0,localpref100,valid,internal


Noticethat206.56.89.1isinaccessiblebecauseR2doesnothavearoutetoreachitinitsIProutingtable,asconfirmedbyExample15-48.Example15-48R2’sIPRoutingTableConfirmsanInaccessibleRoute


ThismightbebecauseR1isnotadvertising206.56.89.1toR2throughitsIGP(OSPF)orR2isnotinstalling206.56.89.1foranyotherreason.Solution

BGPrequiresthenexthopofanyBGProutetoresolvetoaphysicalinterface.ThismightormightnotrequiremultiplerecursivelookupsintheIProutingtable.Twocommonsolutionsexistforaddressingthisproblem:•AnnouncetheEBGPnexthopthroughanIGPusingastaticrouteorredistribution.•Changethenexthoptoaninternalpeeringaddress.

AnnouncetheEBGPNextHopThroughanIGPUsingaStaticRouteorRedistribution

Thissolutionsimplyrequiresthatthesubnet206.56.89.0/30beadvertisedbyR1initsIGP—OSPF,inthisexample.Example15-49showsthenecessaryconfigurationinR1toaccomplishthisandshowsR2receivingthisroutethroughanIGP.Example15-49ConfiguringR1toAdvertiseEBGPNextHopThroughOSPF

R1#routerospf1network206.56.89.00.0.0.7area0

TheoutputinExample15-50showsthatR2receivesthisroutethroughOSPF.Example15-50R2’sIPRouteTableConfirmsReceiptoftheEBGPNextHopRouteAdvertisementThroughOSPF

R2#showiproute206.56.89.0255.255.255.252Routingentryfor206.56.89.0/30Knownvia"ospf1",distance110,metric74,typeintraareaRedistributingviaospf1Lastupdatefrom131.108.1.1onEthernet0,00:03:17agoRoutingDescriptorBlocks:*131.108.1.1,from1.1.1.1,00:03:17ago,viaEthernet0Routemetricis74,trafficsharecountis1

Notethat131.108.1.1resolvestointerfaceEthernet0.ChangetheNextHoptoanInternalPeeringAddress

ThissolutionsuggeststhatR1changetheBGPnexthoptoitsloopbackaddresswhenadvertisingIBGProutestoR2.Example15-51showsthattheconfigurationinR1requirestheBGPnexthoptobechangedtoitsownloopbackaddress.Example15-51ConfiguringR1SoThattheBGPNextHopIsItsOwnLoopbackAddress

R1#routerbgp109neighbor131.108.10.2remote-as109neighbor131.108.10.2update-sourceLoopback0neighbor131.108.10.2nexthop-selfneighbor206.56.89.1remote-as110

Thecommandneighbor131.108.10.2nexthop-selfchangestheNexthoptoitsownloopback0(131.108.10.1).Theneighbor-131.108.10.2update-sourceloopback0commandmakesR1’sloopback0thesourceofallBGPpacketssenttoR2.Example15-52showsthischangereflectedinR2.Example15-52R2’sBGPRouteTableConfirmsThatR1’sLoopbackAddressIstheNextHopofAllBGPUpdatesSenttoR2

R2#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version2Paths:(1available,best#1,tableDefault-IP-Routing-Table)Notadvertisedtoanypeer110131.108.10.1from131.108.10.1(131.108.10.1)OriginIGP,metric0,localpref100,valid,internal,bestR2#showiproute100.100.100.0Routingentryfor100.100.100.0/24Knownvia"bgp109",distance200,metric0Tag110,typeinternalLastupdatefrom131.108.10.100:00:25agoRoutingDescriptorBlocks:*131.108.10.1,from131.108.10.1,00:00:25agoRoutemetricis0,trafficsharecountis1ASHops1

TheexteriorNextHopchangedtotheloopbackofR1,131.108.10.1.ThissolutionismorewidelyusedandisthepreferredmethodofannouncingthenexthoptoIBGPpeer.InthesimpleexampleofFigure15-21,thesolutionofchangingthenexthoptoaninternalpeeringaddressallowsonelessIPsubnettogointheIProutingtable.Inaddition,ithelpsintroubleshootingbecausenetworkoperatorsrecalltheirinternalloopbackaddressesquickerthanexternalIPsubnets,suchasthatusedintheEBGPconnection.

Problem:EBGP-LearnedRouteNotGettingInstalledinIPRoutingTableJustaswithIBGP,EBGProutesmightnotgetinstalledintheIProutingtable,resultinginalackofIPtrafficreachabilitytothoseroutes.Multiplecausesofthisproblemmightexist,dependingonwhichEBGPscenarioisbeinglookedat.ThemostcommoncausesofEBGProutesnotgettinginstalledareasfollows:•BGProutesaredampened.•TheBGPnexthopisnotreachableincaseofmultihopEBGP.

•Themultiexitdiscriminator(MED)valueisinfinite.Thesectionsthatfollowdiscussthesecausesandhowtoresolvetheproblembasedonthecause.EBGP-LearnedRouteNotGettingInstalledinIPRoutingTable—Cause:BGPRoutesAreDampened

DampeningisthewaytominimizeinstabilityinalocalBGPnetworkcausedbyunstableBGProutesfromEBGPneighbors.RFC2439,“BGPRouteFlapDamping,”describesindetailhowdampeningworks.Inshort,dampeningisthewaytoassignapenaltyforaflappingBGProute.Awithdrawalofaprefixisconsideredaflap.Apenaltyof1000isassignedforeachflap;iftheflappenaltyreachesthesuppresslimitbecauseofcontinuedflaps(default2000),theBGPpathissuppressedandistakenoutoftheroutingtable.Thispenaltyisdecayedexponentiallybasedonthehalflifetime(default15minutes).Whenthepenaltyreachesthereusevalue(default750),thepathisunsuppressedandisinstalledintheroutingtableandadvertisedtootherBGPneighbors.Anydampenedpathcanbesuppressedonlyuntilthemaxsuppresstime(default60minutes).DampeningisappliedonlytoEBGPneighbors,nottoIBGPneighbors.BGPdampeningisoffbydefault;thefollowingBGPcommandturnsondampening:

routerbgp109bgpdampening

CiscoIOSSoftwareallowsdampeningparameterstobechangedandaredefinedasfollows:routerbgp1009bgpdampeninghalflife-timereusesuppressmaximum-suppress-time

Here,thevaluerangefortheoptionsisasfollows:•halflife-time—Rangeis1to45minutes.Currentdefaultis15minutes.•reuse—Rangeis1to20,000.Defaultis750.•suppress—Rangeis1to20,000.Defaultis2000.•max-suppress-time—Maximumdurationthataroutecanbesuppressed.Rangeis1to255.Defaultisfourtimeshalflife-time.



Figure15-23showsasimpleEBGPsetupbetweenR1andR2inAS109andAS110,respectively.R2hasadvertised100.100.100.0/24toR1.Toshowhowdampeningworks,R2ismadetoflap100.100.100.0/24multipletimes.RemovingtherouteinR2’sroutingtableandputtingitbackcansimulateflapping.R1receivestheseflapsand,ifconfiguredwithdampening,assignspenaltiesperflap.

Figure15-23EBGPSetuptoDemonstrateRouteDampening

Example15-53showsthenecessarydebugsruntoobservethedampeningfeatureinR1runningCiscoIOSSoftware.Example15-53ObservingtheBGPDampeningFeature

R1#debugipbgpdampening1R1#debugipbgpupdates1access-list1permit100.100.100.00.0.0.0

MostoftheBGPdebugscanberunalongwithanaccesslisttolimittheoutputcreatedbythesedebugs.Accesslist1ispermittingonly100.100.100.0.Example15-54showsthedebugoutputandflapstatisticsinBGPoutput.Example15-54DebugstoVerifyDampeningof100.100.100.0/24

Dec1303:33:57.966MST:BGP(0):131.108.1.2rcvUPDATEabout100.100.100.0/24--withdrawnDec1303:33:57.966MST:BGP(0):chargepenaltyfor100.100.100.0/24path110withhalflife-time15reuse/suppress750/2000Dec1303:33:57.966MST:BGP(0):flapped4timessince00:02:58.Newpenaltyis3838R1#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version17Paths:(1available,nobestpath)Flag:0x208Notadvertisedtoanypeer110,(suppressedduetodampening)131.108.1.2from131.108.1.2(10.0.0.3)OriginIGP,metric0,localpref100,valid,externalDampinfo:penalty3793,flapped4timesin00:03:13,reusein00:35:00

Highlighteddebugandshowcommandoutputshowsthat100.100.100.0/24hasflappedfourtimesin3minutesand13seconds.Foreachflap,apenaltyof1000isassigned;becausethesuppresslimitof2000hasbeenexceeded,100.100.100.0/24issuppressedandremovedfromtheroutingtable.Solution

IfR1wantstoreinstall100.100.100.0/24,itcandothefollowing:1Waitforthepenaltytogobelowthereuselimit(750).2RemovedampeningaltogetherfromtheBGPconfiguration.3Cleartheflapstatistics.

Example15-55showshowthedampenedpathcanbeclearedandimmediatelygetinstalledintheroutingtable.debugipbgpupdate1isontodisplaytheactivityintheBGPprocess.Example15-55ClearingBGPDampeningThroughaCommandLinewithDebugsOn

R1#clearipbgpdampening100.100.100.0Dec1303:36:56.205MST:BGP(0):Reviserouteinstalling100.100.100.0/24->131.108.1.2tomainIPtable

TheoutputinExample15-55camefromdebugipbgpupdate1runningtodisplayactivityof100.100.100.0/24goingintotheIProutingtable.Example15-56showsthefinalBGProutingtableentries.Example15-56BGPRoutingTableEntries

R1#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version18Paths:(1available,best#1,tableDefault-IP-Routing-Table)Flag:0x208Notadvertisedtoanypeer110131.108.1.2from131.108.1.2(10.0.0.3)OriginIGP,metric0,localpref100,valid,external,bestR1#showiproute100.100.100.0Routingentryfor100.100.100.0/24Knownvia"bgp109",distance20,metric0Tag110,typeexternalLastupdatefrom131.108.1.200:02:45agoRoutingDescriptorBlocks:*131.108.1.2,from131.108.1.2,00:02:45agoRoutemetricis0,trafficsharecountis1ASHops1,BGPnetworkversion0

EBGP-LearnedRouteNotGettingInstalledinIPRoutingTable—Cause:BGPNextHopNotReachableinCaseofMultihopEBGP

InamultihopEBGPsession,EBGPspeakersarenotdirectlyconnected.Peeringbetweenloopbackaddressesofadjacentroutersalsoisconsideredmultihop.ThisproblemofanEBGPmultihoproutenotgettinginstalledinanIProutingtableisidenticaltotheIBGPnexthopissue;however,mostofthecommonlyseenproblemsoccurwhentherouterfailstoresolvethenexthopaddresstoaninterface.Inthisproblem,themultihopEBGPnexthopisreachablethroughaBGProutewhosenexthopisagaintheoriginalmultihopBGPnexthop.Forexample,toreachprefixA,thenexthopisprefixB;toreachprefixB,thenexthopisagainB.ThisisconsideredarecursionprobleminwhicharoutercannotresolvetoaninterfacetoreachthenexthopB.Figure15-24showshowR2willnotinstallroutesfromR1whosenexthopcannotberesolvedtoaninterface.

Figure15-24R2FailstoInstallRoutesfromR1BecauseofNextHop/InterfaceResolution



R1andR2arepeeringtoeachother’sLoopbackaddresses.R1isadvertising100.100.100.0/24toitsmultihopEBGPneighborR2withanexthopof131.108.10.1.R2hasadefaultroutethatitusestoformaBGPneighborrelationshipwithR1,butfailuretoresolvethenexthoptoaninterfaceresultsinroutesnotgettinginstalledintheroutingtable.Example15-49showsthatR2isreceiving100.100.100.0/24fromR1withthenexthopof131.108.10.1.However,thisnexthopisadvertisedbyR1toR2onlythroughBGP.NoticeintheoutputofExample15-57thatthenexthopforBGPupdateof131.108.10.1/32is131.108.10.1.R2canneverresolvethereachabilityfor131.108.10.1throughanyphysicalinterface.InCiscoIOSSoftware,BGPcandetectthisbehaviorandmarks100.100.100.0/24asanunacceptableroutetogoinBestPathcalculationandthusnevergointheIProutingtable.Example15-57EBGPMultihopWillNotBeCapableofResolvingtheNextHop

R2#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version2Paths:(1available,best#1,tableDefault-IP-Routing-Table)Flag:0x208Notadvertisedtoanypeer109131.108.10.1from131.108.10.1(131.108.10.1)OriginIGP,metric0,localpref100,valid,external,bestR2#showipbgp131.108.10.1BGProutingtableentryfor131.108.10.1/32,version5Paths:(1available,nobestpath)Flag:0x208Notadvertisedtoanypeer109131.108.10.1(inaccessible)from131.108.10.1(131.108.10.1)OriginIGP,metric0,localpref100,valid,external



NotethetimestampinIProuteoutput;itisresettingeveryminute.ThisrouteinExample15-57willkeepcomingandgoingeveryminuteastheCiscoIOSSoftwareBGPscannerprocessdetectssuchinconsistenciesintheBGPnexthopandremovesthatroute.Solution

Thesolutiontothisproblembasedonthiscauseistosimplyhaveamorespecificrouteforthenexthopaddress.InthecaseofEBGP,thisiscommonlydonebyhavingastaticrouteforthemultihopEBGPpeeringaddress.ThisinstanceisobservedinthecaseofmultihopEBGPsessionswhenthenexthopaddressisnotdirectlyconnectedandtheIProutingtablemusthaveanexplicitroutetothenexthopaddress.ThesimplesolutionliesincreatingastaticroutefromR2toreachtheR1loopback,whichisthenexthopofallprefixesadvertisedbyR1toR2.ThiscanbedonewiththefollowingcommandonR2:

iproute131.108.10.1255.255.255.255131.108.1.1

Thestaticroute131.108.10.1istheloopbackaddressofR1,and131.108.1.1isthephysicalinterfaceaddressofR1.EBGP-LearnedRouteNotGettingInstalledintheRoutingTable—Cause:MultiexitDiscriminator(MED)ValueIsInfinite

InCiscoIOSSoftware,ifamultiexitdiscriminator(MED)issettoinfinite4294967295,therouterwillnotinstallthisrouteintheroutingtable.Figure15-26showstheflowcharttofollowtoresolvethisproblem.


InCiscoIOSSoftware,aninfiniteMEDinaBGPupdatemakesitincapableofenteringtheroutingtable.Thisrareoccurrenceistypicallytheresultofmisconfiguration.Example15-58showstheoutputoftheBGPtableforprefix100.100.100.0/24.Noticethemetricvalueof4.29billion,whichCiscoIOSSoftwareconsidersasinfinite.Example15-58alsoshowshowR2canbeconfiguredtosettheMEDvalueequalto4.29billion.Theinfinitemetricsometimesisusedinrouteservers,whichprovideamirrorviewoftheInternetBGPtable.SettingthemetrictoinfinityprohibitssuchroutesfromgoingintheIProutingtable,sonoIPtrafficwillusethoseroutes.ThiscaseisdiscussedherejusttoshowacornercaseofaBGPpathnotgettinginstalledintheroutingtable.SuchaconfigurationisnotseeninrealBGPnetworks.Example15-58BGPRouteTableforPrefix100.100.100.0/24IndicatesaMetricSettoInfinity

R2#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version0Paths:(1available,nobestpath)Notadvertisedtoanypeer1172.16.126.1from172.16.126.1(172.16.1.1)OriginIGP,metric4294967295,localpref100,valid,external

R2#showiproute100.100.100.0%NetworknotintableR2#routerbgp2nosynchronizationneighbor172.16.126.1remote-as1neighbor172.16.126.1route-mapSET_MEDin

R2#showroute-mapSET_MED

route-mapSET_MED,permit,sequence10Matchclauses:Setclauses:metric4294967295Policyroutingmatches:0packets,0bytes

TroubleshootingBGPRoute-ReflectionIssuesRoutereflectors(RR),discussedinRFCs1966and2796,areusedtoavoidIBGPfullmeshinanAS,asrequiredbyRFC1771.RoutereflectionensuresthatallIBGPspeakersinanASreceiveBGPupdatesfromallpartsofthenetworkwithouthavingtorunIBGPbetweenalltheroutersinthenetwork.RoutereflectionreducesthenumberofrequiredIBGPconnectionsandalsooffersfasterconvergenceinanIBGPnetworkwhencomparedwithafull-meshIBGPnetwork.Route-reflectorclients(RRCs)typicallypeerIBGPwithoneormoreRR,andtheycanhaveEBGPconnectionsunconditionally.LogicalBGPconnectionsbetweenRRandRRCtypicallyfollowthephysicalconnectiontopology.ThesearesomeofthecommonrulesthathelpBGPoperatorstroubleshootBGProute-reflectorissues.ThissectiondiscussesvariousissuesseeninBGPnetworksrelatedtoroutereflection.Themostcommonproblemsinroute-reflectionnetworksareasfollows:•Configurationmistakes•AnextraBGPupdatedstoredbyaroute-reflectorclient•Convergencetimeimprovementforroutereflectorsandclients•Lossofredundancybetweenroutereflectorsandroute-reflectorclients

Problem:ConfigurationMistakes—Cause:FailedtoConfigureIBGPNeighborasaRoute-ReflectorClientConfiguringroutereflectorsisfairlysimple.Inroute-reflectorBGPconfiguration,IBGPneighbors’peeringaddressesarelistedasroute-reflectorclients;however,aBGPoperatorinadvertentlymightconfigureanincorrectIBGPpeeringaddressasaroute-reflectorclient.Figure15-27showsthatR1isanRR.R8andR2areRRCsofR1.

Figure15-27SimpleRoute-ReflectionEnvironmentDebugsandVerification

Example15-59showstherequiredconfigurationneededtomakeR1anRRforR8andR2.NoadditionalconfigurationisneededinR8andR2tobecomeRRCsotherthanjustthenormalIBGPconfigurationtopeerwithR1.Example15-59ConfiguringR1asaRouteReflectorwithR8andR2asClients

R1#routerbgp109nosynchronizationneighbor131.108.1.2remote-as109neighbor131.108.1.2route-reflector-clientneighbor206.56.89.1remote-as109neighbor206.56.89.1route-reflector-client

TheneighborIPaddressmustbethesameintheroute-reflector-clientstatementasintheremote-asconfiguration.TheCiscoIOSSoftwareBGPparserdetectsthemisconfiguredRRCIPaddressifBGPdoesnothaveanIBGPneighborconfiguredwiththisaddress.Forexample,iftheBGPoperatortypesinthiscommand

R1#routerbgp109neighbor131.108.1.8route-reflector-client

CiscoIOSSoftwarewillimmediatelydisplayanerror:%Specifyremote-asorpeer-groupcommandsfirst

BGPdetectsthat131.108.1.8isnotconfiguredasaneighbor,soitcannotbeassociatedasanRRC.Usetheshowipbgpneighborcommand,asdemonstratedinExample15-60,toverifythattheneighborisconfiguredasanRRC.

Example15-60VerifyingNeighborConfigurationasanRRC

R1#showipbgpneighbor131.108.1.2

BGPneighboris131.108.1.2,remoteAS1,internallinkIndex1,Offset0,Mask0x2Route-ReflectorClient

Solution

ABGPoperatoraccidentallymightconfigureadifferentIPaddressintheRRCthanisconfiguredintheneighborstatementwheretheremoteASisconfigured.Ifthisproblemisdetected,theIPaddressmustbecorrected.

Problem:Route-ReflectorClientStoresanExtraBGPUpdate—Cause:Client-to-ClientReflectionTheproblemherestemsfromRRCsreceivingextraBGPupdates,whichconsumeextramemoryandtakeupCPUtoprocessthem.InFigure15-28,RRCR8peersIBGPwithRRR1;R8ispeeringIBGPwithRRCR2aswell.Becauseofthispeeringrelationship,R2receivesanextraBGPupdateforalltheroutesoriginated/propagatedbyR8.SuchasetuptypicallyisdonewhenaphysicalcircuitexistsbetweenRRCsandtheBGPoperatorwantstorunBGPdirectlyoverthem.Instandardnetworkdesign,suchBGPconnectionsbetweenRRCsdonotexist,andallRRCssimplypeerwiththeirrespectiveroutereflector(s)only.

Figure15-28Client-to-ClientIBGPPeeringinAdditiontoRouteReflectorSetup



TheoutputinExample15-61showsthatR2isreceivingtwoupdatesfor100.100.100.0,onefromR8andanotherreflectedfromR1.Example15-61R2’sBGPTableIndicatesUpdatesReceivedfromBoththeRRandAnotherRRC

R2#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version3Paths:(2available,best#1,tableDefault-IP-Routing-Table)NotadvertisedtoanypeerLocal131.108.10.8(metric20)from131.108.10.8(131.108.10.8)OriginIGP,metric0,localpref100,valid,internal,bestLocal131.108.10.8(metric20)from131.108.10.1(131.108.10.1)OriginIGP,metric0,localpref100,valid,internalOriginator:131.108.10.1,Clusterlist:0.0.0.109

Solution

Turningoffclient-to-clientreflectionsolvesthisproblem.ThisproblemarisesonlywhenanRRCpeersIBGPwithanotherRRC.WhenanRRCpeersonlywiththeRR,BGPdoesnotrunintothisissue.Example15-62showstheconfigurationneededonanRRtoturnoffclient-to-clientreflection.Example15-62DisablingClient-to-ClientReflection

R1#routerbgp109nobgpclient-to-clientreflection

Afterenablingthiscommand,theRRdoesnotreflectanyupdatefromoneRRCtoanotherRRC,butitdoesreflecttonormalIBGPandEBGPneighbors.TheBGPoperatormustbecertainthatRRCsare

peeringBGPwithotherRRCstomakethismodification.WhenR1isconfiguredinthismanner,itdoesnotadvertise100.100.100.0/24totheotherclient,R8,butdoesadvertisetootherIBGPandEBGPneighbors.Example15-63showsthatR1isreceiving100.100.100.0/24fromR8butisnotpropagatingfurthertoanyone.Example15-63R1’sBGPTableEnsuresThatDisablingClient-to-ClientReflectionIsSuccessful

R1#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version2Paths:(1available,best#1,tableDefault-IP-Routing-Table)Flag:0x208NotadvertisedtoanypeerLocal,(ReceivedfromaRR-client)131.108.10.8from131.108.10.8(131.108.10.8)OriginIGP,metric0,localpref100,valid,internal,best

Problem:ConvergenceTimeImprovementforRRandClients—Cause:UseofPeerGroupsWhenanRRisservingmanyclients,anyupdatethatitreceivesfromIBGP/EBGPpeersmustbegeneratedandpropagatedasseparateupdatesforeachRRC.IfthenumberofBGPupdatesandRRCsislarge,thisprocesscouldbecomeCPU-intensivefortheRR.ThisresultsinslowerpropagationofBGPupdatesandhenceresultsinslowerconvergenceinthenetworkoverall.Peer-groupclubsconfigureBGPneighborsinonegroup.Anycommonupdatethatneedstogotoallmembersofthepeergroupareprocessedonlyonce,andallmembersreceivethecopyofthatprocessedupdate.Arouterthathasapeergroupdoesnotprocessupdateforallmembersofthegroup,resultinginhugeCPUprocessingsavings.Overallconvergenceofthenetworksimprovesgreatly.Figure15-30showsaroute-reflectionenvironmentinwhichpeergroupscanbeused.

Figure15-30PeerGroupEfficiencyinAdvertisingRoutes



Typically,peergroupscontainseveralclientstoexplainthepeergroupusage.Example15-64showsthenecessaryconfigurationrequiredbyR1toputR8andR6inapeergroupnamedINTERNAL.Example15-64ConfiguringR8andR6asPeerGroupMembers

R1#routerbgp109nosynchronizationneighborINTERNALpeer-groupneighbor131.108.10.8remote-as109neighbor131.108.10.8update-sourceLoopback0neighbor131.108.10.8peer-groupINTERNALneighbor131.108.10.6remote-as109neighbor131.108.10.6update-sourceLoopback0neighbor131.108.10.6peer-groupINTERNAL

R1calculatesoneupdateforthefirstmemberofthepeergroupINTERNALandreplicatetoothers.OutputinExample15-65showsthat131.108.10.8(R8)isthefirstmemberinthelist;therefore,R1calculatesupdatesforR8andreplicatestotherestofthemembersinthelistINTERNAL,toavoidcalculatingfortherest.InExample15-65,R6istheothermemberinthelistINTERNAL.Example15-65DisplayingPeerGroupMembers

R1#showipbgppeer-groupINTERNALBGPpeer-groupisINTERNALBGPversion4Defaultminimumtimebetweenadvertisementrunsis5secondsBGPneighborisINTERNAL,peer-groupinternal,members:131.108.10.8131.108.10.6

Index1,Offset0,Mask0x2Updatemessagesformatted4,replicated2

Solution

Whenpeeringtoseveralneighbors,usetheCiscoIOSSoftwareBGPpeergroupfeaturetoavoidtheprocessingduplicationrequiredtogeneratethesameupdatetoeveryneighbor.Inpeergroups,BGPneighbors(inthiscase,allRRCs)arelistedasmembersofapeergroupthatsharethesameoutboundpolicy.RRcomputesanupdateforthefirstmemberofthepeergroupandsimplyreplicatesthesameupdatetoallmembers.ThisgreatlyreducesthenumberofCPUcyclesthattheRRhastospendtocomputeupdateforeachRRC.Inaddition,usingpeergroupsspeedsuptheprocessofpropagatingBGPupdatestoRRCs;therefore,RRCsconvergefasterincaseofanychurn.PeergroupscanbeusedinnormalIBGPandEBGPscenariostogetthisbenefit,withtheconditionthatallpeer-groupmembersareconfiguredwithsameoutboundpolicy.

Problem:LossofRedundancyBetweenRouteReflectorsandRoute-ReflectorClient—Cause:ClusterListCheckinRRDropsRedundantRoutefromOtherRRAclusterismadeupofanRRanditsclients.AclustercanhaveoneormoreRRandisidentifiedbyaclusterIDthatistherouterIDoftheRR.BecauseeachRRhasauniquerouterID,eachclusterhasonlyoneRRbydefault.NetworkoperatorsmustmanuallyconfigureidenticalclusterIDsontwoormoreRRstoconfiguretheminthesamecluster.WhenaBGPupdatetraversesfromanRRtootherneighbors,RRaddsitsclusterIDinthelistcalledtheclusterlist,whichcontainsallclusterIDsthatanyBGPupdatehastraversed.TheclusterlistissynonymouswiththeAS_PATHlist,whichcontainsASliststhatanyupdatehastraversed.JustasinAS_PATHloopdetection,inwhichupdatesaredroppediftheAS_PATHcontainsalocalAS,theclusterlistdetectsloopsiftheycontainalocalclusterID.Whenaroute-reflectorclientisconnectedtotwodifferentRRsthatareinthesamecluster,chancesaregoodthattheRRwillnotseetheredundantpathtotheclients.Figure15-32showstwoRRsconfiguredinthesamecluster.AnyupdateonereceivedfromtheotherthathasitsownclusterIDintheclusterlistwillbedropped.

Figure15-32RouteReflectorsConfiguredwiththeSameClusterID,ResultinginLossofRedundancy

Figure15-32showshowanRRandanRRCareconnectedinasinglecluster.EachRRmustbeconfiguredwithsameclusterID,asshowninthe“DebugsandVerification”section.R8isadvertising100.100.100.0/24toitsIBGPneighborsR1andR2,whichareRRsforR6andR8,andreflects100.100.100.0/24.R1reflectstoR6andR2,whereasR2reflectstoR1andR6.BecausetheybothareconfiguredwiththesameclusterID109,theclusterlistfrombothRRswillcontainclusterID109,representedas0.0.0.109inCiscoIOSSoftwareoutput.Figure15-33illustrateshowtheRRlosesredundancytotheclient.

Figure15-33HowanRRRejectsRoutesThatFailtheClusterIDCheckDebugsandVerification

Example15-66showstheconfigurationofthetwoRRswhentheyareconfiguredwithidenticalclusterIDsof109.Example15-66RRsConfiguredwithIdenticalClusterIDs

R1#routerbgp109nosynchronizationbgpcluster-id109neighbor172.16.18.8remote-as109neighbor172.16.18.8route-reflector-clientneighbor172.16.126.2remote-as109neighbor172.16.126.6remote-as109neighbor172.16.126.6route-reflector-client

R2#routerbgp109nosynchronizationbgpcluster-id109neighbor172.10.28.8remote-as109neighbor172.10.28.8route-reflector-clientneighbor172.16.126.1remote-as109neighbor172.16.126.6remote-as109neighbor172.16.126.6route-reflector-client

AsdepictedinFigure15-33,R8,anRRC,advertises100.100.100.0/24tobothofitsRRs,R1andR2.WhenR1andR2areconfiguredwiththesameclusterID,R1andR2haveonlyasingleupdateintheirBGPtablefor100.100.100.0/24,learnedfromtheRRCitself.Example15-67showsthattheRRshaveonlyasingleentryintheirBGPtablesfornetwork100.100.100.0/24,andthisentryisfromtheRRC.Example15-67RRsR1andR2HaveOnlyOneUpdatefor100.100.100.0/24,ResultinginLossofRedundancy

R1#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version2Paths:(1available,best#1,tableDefault-IP-Routing-Table)Flag:0x208Advertisedtononpeer-grouppeers:131.108.10.2131.108.10.6Local,(ReceivedfromaRR-client)131.108.10.8from131.108.10.8(131.108.10.8)OriginIGP,metric0,localpref100,valid,internal,bestR1#

R2#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version2Paths:(1available,best#1,tableDefault-IP-Routing-Table)Advertisedtononpeer-grouppeers:131.108.10.1131.108.10.6Local,(ReceivedfromaRR-client)131.108.10.8from131.108.10.8(131.108.10.8)OriginIGP,metric0,localpref100,valid,internal,best\

EachRRhasanupdatefor100.100.100.0/24onlyfromR8,notfromtheotherRR.Example15-68showstheoutputofdebugipbgpupdatefromR2.NoticethatR2isdroppingtheupdatefor100.100.100.0/24fromR1becauseitseesitsownclusterID,109,(representedas0.0.0.109)intheclusterlist.Example15-68debugipbgpupdateCommandOutputfromR2

R1#debugipbgpupdate

*Mar311:29:11:BGP(0):172.16.10.8rcvdUPDATEw/attr:nexthop172.16.10.8,origini,localpref100,metric0*Mar311:29:11:BGP(0):172.16.10.8rcvd100.100.100.0/24*Mar311:29:11:BGP(0):Reviserouteinstalling100.100.100.0/24->172.16.10.8tomainIPtable*Mar311:29:11:BGP:172.16.126.1RRinsamecluster.Reflectedupdatedropped*Mar311:29:11:BGP(0):172.16.126.1rcvUPDATEw/attr:nexthop172.16.10.8,origini,localpref100,metric0,originator172.16.8.8,clusterlist0.0.0.109,path,community,extendedcommunity*Mar311:29:11:BGP(0):172.16.126.2rcvUPDATEabout100.100.100.0/24--DENIEDdueto:reflectedfromthesamecluster;

Solution

IfalinkorIBGPconnectionbetweenR8andR2goesdown,R2hasnowaytoreach100.100.100.0/24.ThisisbecauseR2hasrejectedthe100.100.100.0/24advertisementfromR1asaresultoftheclusterlistcheck.ItisrecommendedthatincasessimilartothosedepictedinFigure15-33,RRsshouldnotbeputinthe

samecluster.TheclusterIDwillbepickedastherouterID(RID)ofeachRRandisguaranteedtobeuniquebecauseallRIDsareuniqueinanynetwork.Example15-69showstheconfigurationofallRRsandRRCs,whichareindifferentclusters.Example15-69alsoshowstheconfigurationinR8toadvertise100.100.100.0/24toR1andR2.Example15-69displaystheoutputfromtheBGPtable.OutputfromR1andR2showsthateachhasaredundantpathfor100.100.100.0/24,onedirectlytoR8andtheotheronethrougheachother.IfalinkorBGPsessionbetweenR1andR8islost,R1hasabackuppaththroughR2toreachR8.Example15-69UniqueRouterIDofEachRRWillMakeUniqueClusterIDperRR

R1#routerbgp109nosynchronizationneighbor131.108.10.8remote-as109neighbor131.108.10.8route-reflector-clientneighbor131.108.10.6remote-as109neighbor131.108.10.6route-reflector-clientneighbor131.108.10.2remote-as109

R2#routerbgp109nosynchronizationneighbor131.108.10.8remote-as109neighbor131.108.10.8route-reflector-clientneighbor131.108.10.6remote-as109neighbor131.108.10.6route-reflector-clientneighbor131.108.10.1remote-as109



R8#routerbgp109nosynchronizationnetwork100.100.100.0mask255.255.255.0neighbor131.108.10.1remote-as109neighbor131.108.10.2remote-as109!

iproute100.100.100.0255.255.255.0Null0R8#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version6Paths:(1available,best#1,tableDefault-IP-Routing-Table)Flag:0x208Advertisedtononpeer-grouppeers:131.108.10.1131.108.10.2Local0.0.0.0from0.0.0.0(131.108.10.8)OriginIGP,metric0,localpref100,weight32768,valid,sourced,local,Best

R1#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version2Paths:(2available,best#2,tableDefault-IP-Routing-Table)

Advertisedtononpeer-grouppeers:131.108.10.2131.108.10.6Local131.108.10.8(metric20)from131.108.10.2(131.108.10.8)OriginIGP,metric0,localpref100,valid,internalOriginator:131.108.10.8,Clusterlist:131.108.10.2Local,(ReceivedfromaRR-client)131.108.10.8from131.108.10.8(131.108.10.8)OriginIGP,metric0,localpref100,valid,internal,best

R2#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version2Paths:(2available,best#2,tableDefault-IP-Routing-Table)Advertisedtononpeer-grouppeers:172.16.126.1172.16.126.6Local131.108.10.8(metric20)from131.108.10.1(131.108.10.8)OriginIGP,metric0,localpref100,valid,internalOriginator:131.108.10.8,Clusterlist:131.108.10.1Local,(ReceivedfromaRR-client)131.108.10.8from131.108.10.8(131.108.10.8)OriginIGP,metric0,localpref100,valid,internal,best

BothR1andR2havearedundantpathtoreach100.100.100.0/24onlybecauseofauniqueclusterID.TheexampleshowspickingauniqueclusterIDfromauniquerouterID;analternatewaytoensureclusterIDuniquenesswouldbetomanuallyconfigureauniqueclusterIDperRR.

TroubleshootingOutboundIPTrafficFlowIssuesBecauseofBGPPoliciesBGP’srealpowerisinmanagingIPtrafficflowscominginandgoingoutoftheAS.BGPingeneralandCiscoIOSSoftwareinparticularofferagreatdealofflexibilityinmanipulatingBGPattributesLOCAL_PREFERENCE,MED,andsoforthtocontrolBGPbestpathcalculation.ThisbestpathdecisiondetermineshowtrafficexitstheAS.WiththelargesizeofBGPnetworkstoday,itiscrucialthatBGPoperatorsunderstandhowBGPattributesshouldbemanaged.ThissectiondiscusseswhatproblemscanarisewhiletryingtomanagetrafficleavingtheAS.Hereisthelistofthemostcommonproblemsencounteredinmanagingoutboundtrafficflow:•Multipleexitpointsexist,buttrafficgoesoutthroughoneorafewexitrouters.•Traffictakesadifferentinterfacefromwhatisshownintheroutingtable.•AmultipleBGPconnectionexiststothesameBGPneighbor,buttrafficgoesoutthroughonlyoneconnection.•AsymmetricalroutingoccursanditcausesaproblemespeciallywhenNATandtime-sensitiveapplicationsareused.

Problem:MultipleExitPointsExistbutTrafficGoesOutThroughOneorFewExitRouters—Cause:BGPPolicyDefinitionCausesTraffictoExitfromOnePlaceThisproblemcommonlyisseenwhenanASreceivesthesameprefixannouncementsfrommultipleEBGPconnectionsbuttrafficdestinedtothoseprefixesprefersonlyoneortwoexitpoints.AsillustratedbyFigure15-34,AS109hasmultipleconnectionstootherautonomoussystems.AS109hasthreeEBGPconnectionswithAS110,twowithAS111,andonewithAS112.AS111ispeeringwithAS110andAS112.

Figure15-34AutonomousSystemwithMultipleConnectionstoOtherAutonomousSystemswithMultipleExitPoints

PrefixesP1,P2,andP3areoriginatedbyAS110andareadvertisedtoEBGPneighboringautonomoussystems109,111,and112.AS109receiveupdatesfortheseprefixesfrommultiplelocations—threeupdatesfromAS110,twofromAS111,andonefromAS112.EvenwithsuchredundantBGPadvertisementsforPrefixesP1,P2,andP3,allthetrafficfortheseprefixesfromAS110mighttakeonlyoneortwoexitpoints.Therestoftheconnectionsareunderutilized.Suchascenariotypicallyresultsinoverutilizedlinksbecausetraffictendstoexitfromoneortwopreferredpaths,asgovernedbyBGPpolicyofAS109.Figure15-35showstheflowcharttofollowtoresolvethisproblem.


AS109BGPinstallsitsbestpathforPrefixesP1,P2,andP3intheIProutingtable,andtrafficdestinedfortheseprefixeswilllookintheroutingtablesforroutersinAS109.ItiscrucialtounderstandhowBGPselectsthebestpath;todothis,BGPoperatorsmustunderstandhowBGPpathattributeswork.TheseattributesincludeAS_PATH,LOCAL_PREFERENCE,MED,ORIGIN,andsoon,asdiscussedindetailinChapter14.ThissectiondiscusseshowAS_PATHaffectstrafficpatternsinAS109forPrefixesP1,P2,andP3.ItisassumedthatAS109isnotconfiguredwithanyadditionalBGPpolicies.RecallthatAS_PATHcontainsalistofautonomoussystemsthatanupdatehastraversed.ThissectionshowstheAS_PATHlistofR1andR4asanexample;youareencouragedtocomeupwiththeAS_PATHlistforR2andR3asanexercise.R1hastwoupdatesforPrefixesP1,P2,andP3andtheAS_PATHwouldlikethefollowing:•110—PathfromadirectconnectionbetweenR1andAS110.ThiswouldbeanEBGPpathwithan

AS_PATHlengthof1.•110—PathfromR2.ThiswouldbeanIBGPpathwithanAS_PATHlengthof1.

Outofthesetwopaths,thefirstonewillbeselectedasbestbecause,withthesameAS_PATHlength,theEBGPpathisbetterthantheIBGPpath.R4AS_PATHwouldlikethefollowing:•112111110—PathfromR4andAS112connection.ThisisanEBGPpathwithanAS_PATHlengthof3.•111110—PathfromR4andAS111connection.ThisisanEBGPpathwithanAS_PATHlengthof2.•110—PathfromR1.ThiswouldbeanIBGPpathwithanAS_PATHlengthof1.•110—PathfromR2.ThiswouldbeanIBGPpathwithanAS_PATHlengthof1.•110—PathfromR3.ThiswouldbeanIBGPpathwithanAS_PATHlengthof1.

TheAS_PATHlengthofthethird,fourth,andfifthpathsis1,andbestpathselectionwillbebasedonIBGPnexthopcostthroughtheIGP.IfyouassumethatthethirdpathfromR1wins,alltrafficfromR4destinedforPrefixesP1,P2,andP3willexitfromR1andtheAS110connection,leavingpath1,2,4,and5linksnotusedatallforPrefixesP1,P2,andP3.ReferbacktoChapter14forthefulldescriptionofhowthebestpathcalculationmethodworks.Thisexamplecouldbeareal-lifeoneinwhichAS110isabigTier1ISPthatpeersBGPwithjustaboutallotherISPs,bigorsmall.Chancesare,AS110willprovideAS109withmostoftheBGPprefixes(P1,P2,andP3)withtheshortestAS_PATH.ThiswillinfluenceAS109’sBGPbestpathproceduretopickAS110asthefirstpreferencetocarrytrafficforP1,P2,andP3,which,inturn,resultsinclogginglinksthatconnectAS109toAS110directly.BecauseAS109hasnotmadeanyBGPpolicychangeforP1,P2,andP3,AS109isatthemercyofBGPneighborsandisleftwithnocontroloftrafficflowfromitsAS109toP1,P2,andP3.ThelinksfromAS109toAS111,112,andsoforthareusedminimally,resultinginwastedhigh-costbandwidth.Solution

IfasituationarisesinwhichoneBGPneighbor(AS110,inthisexample)isattractingallthetrafficfromAS109toPrefixesP1,P2,andP3,AS109BGPoperatorsshoulddefinelocalpolicieswithinAS109toovercomethisbehavior.UsingtheBGPattributeLOCAL_PREFERENCEisdonecommonlytopredictablycontrolthetrafficleavingthelocalAS(AS109,inthisexample).AS109canchoosetomakeAS111andAS112carrytrafficforPrefixP2andP3,respectively,andcanleavetherestforAS110.Example15-70showsanexampleofhowR2inAS109canchangeLOCAL_PREFERENCEonaper-prefixbasiswithaneighborinAS111tomakeAS111attractallthetrafficforP2.Example15-70ImplementingtheLOCAL_PREFERENCEAttributetoControltheTrafficFlow

R2#routerbgp109neighbor172.16.1.1remote-as111neighbor172.16.1.1route-mapinfluencing_trafficin

access-list1permitP2wild_card


route-mapinfluencing_trafficpermit10matchipaddress1setlocal-preference200!route-mapinfluencing_trafficpermit20matchipaddress2setlocal-preference90

Accesslist1ispermittingPrefixP2.TheactualaccesslistwouldhavetherealIPprefix;P2isusedjustforillustrationpurposes.Thefirstsequence10ofroute-mapinfluencing_trafficallowsP2tobesetwithaLOCAL_PREFERENCEof200,andsequence20ofthesameroutemapsetsaLOCAL_PREFERENCEof90fortheotherprefixes(P1andP3).ThisresultsinmakingP2’sLOCAL_PREF200,thusmakingAS111paththebestpathforP2only.SettingtheP1andP3LOCAL_PREFattributesto90wouldhavenoeffectbecause,inCiscoIOSSoftware,thedefaultvalueforLOCAL_PREFERENCEis100;AS110willbepickedasthebestpathforP1andP3.WiththesizeoftheBGProutingtabletoday,itisdifficulttomanagetrafficonaprefix-by-prefixbasis.Typically,BGPspeakerschangetheLOCAL_PREFERENCEvaluebasedontheAS_PATHlist.AS109mightdecidethatallprefixesthatcomefromAS111thathaveintheAS_PATHlisteither“111”or“111andonemoreAS”shouldbeselectedasbestpathsthroughAS111neighbors.Therefore,AS110andAS112shouldnotbethepreferredcarriersforprefixesthatareoriginatedbyAS111orthatarecomingfromanASdirectlypeeringwithAS111.ManipulatingBGPattributes(LOCAL_PREFERENCE)basedonAS_PATHlistrequirestheuseoftheas_pathaccess-listcommand,whichusesUNIX-likeregularexpressions.Example15-71showsaconfigurationexampleofRouterR2inAS109thatchangestheLOCAL_PREFERENCEofalltheprefixesofthosereceivedfromAS111thathaveintheAS_PATHlisteither“111”or“111andonemoreAS.”Example15-71LOCAL_PREFERENCEManipulationUsingAS_PATHList

R2#routerbgp109neighbor172.16.1.1remote-as111neighbor172.16.1.1route-mapinfluencing_trafficin!

ipas-pathaccess-list1permit^111$ipas-pathaccess-list1permit^111[0-9]+$ipas-pathaccess-list2permit.*

route-mapinfluencing_trafficpermit10matchas-path1setlocal-preference200!route-mapinfluencing_trafficpermit20matchas-path2setlocal-preference90

Thefirstsequencenumber,10,ofroute-mapinfluencing_trafficlooksatASpath1,whichpermitsanyprefixthathasinitsAS_PATHlisteither“111”or“111andonemoreAS”;itthensetstheLOCAL_PREFERENCEto200,makinglinkstoAS111thepreferredpathfromtheAS109BGPview.Theregularexpression^111$meansthatAS_PATHshouldcontainonlyoneAS,andthatisAS111.Theexpression^111[0-9]+$meansthatAS_PATHshouldcontaintwoautonomoussystems,butthefirst

onemustbeAS111;thesecondonecanbeanyAS.Theexpression.*meansanyAS.Thesecondsequencenumber,20,ofroute-mapinfluencing_trafficlooksatASpath2,whichpermitseverythingandmakestheLOCAL_PREFERENCElowerthanthedefaultof100sothatothercarrierscanpicktherestofthetraffic.BGPattributemanipulationbasedonAS_PATHisafairlycommonpracticeamongsavvyBGPoperatorsbecausewildcardoperationsallowcoveringalargernumberofprefixestobecheckedinfewerlinesofconfiguration.Inessence,itiscrucialthatBGPoperatorsmanagetheirtrafficflowbymakingnecessaryBGPattributechangestoinfluencetheBGPpath-selectionprocess.ThisensurespredictabletrafficmanagementwithinanASandallowsfutureupgradesinbandwidthtoeasilybejudged.

Problem:TrafficTakesaDifferentInterfacefromWhatShowsinRoutingTable—Cause:NextHopoftheRouteIsReachableThroughAnotherPathInsomescenarios,BGPandtheroutingtablepathtoacertaindestinationprefixshowExitA,butactualtrafficleavesthroughExitB.Packetforwardingtoadestinationtakesplacefromtheroutingtable,andnetworkoperatorsdoexpecttoseethisbehavior.However,inmostcases,thenexthopsofprefixesintheroutingtablearenotdirectlyconnectedandpacketforwardingeventuallytakesplacebasedonthenexthoppath.Figure15-36triestoexplainonesuchsimplecase.

Figure15-36PacketMightTakeaDifferentPhysicalPathThanWhattheIPRoutingTableShows

Figure15-36showsthatR1andR2aretworoutereflectors,withR6andR8astheirclients.R6isadvertising100.100.100.0/24toR2andR1,andbothreflectthisadvertisementtoR8withanexthopof172.16.126.6.Now,assumethatR8hasaBGPpolicythatchoosesthepathfor100.100.100.0/24fromR2(theupperpath)asthebestpaththatitwillinstallinitsroutingtable.However,inthesamerouter,R8,thebestIGPpathtoreach172.16.126.6(nexthopof100.100.100.0/24)isthroughR1(thebottompath).AlltrafficdestinedfromorthroughR8to100.100.100.0/24willtakethebottompath;eventhoughthebestBGP-selectedpathintheroutingtableistheupperpath,itwillnotbeused.

Therefore,forwardingofIPpacketsinaroutereventuallyhappensbylookingatthepathforthenexthop(172.16.126.6)oftheactualpath(100.100.100.0/24).InCiscoIOSSoftware,recursivelookupisthetermusedforfindingoutthepathbasedonthenexthopandtheactualprefix.Insomecases,morethanonerecursivelookupmustbedonetofigureouttheactualphysicalpaththatpacketstaketoreachthedestination.Figure15-37showstheflowcharttofollowtoresolvethisproblem.


Example15-72showstheoutputof100.100.100.0/24inR8.Thenexthopis172.16.126.6.Whentrafficissentto100.100.100.0/24,itactuallyissenttotheinterfacethatprovidesabetterroutefor172.16.126.6.Example15-72BGPandRoutingTableOutputfor100.100.100.0/24ShowsBestPathThroughR2

R8#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version5870Paths:(1available,best#1,tableDefault-IP-Routing-Table)NotadvertisedtoanypeerLocal172.16.126.6(metric20)from172.16.126.2(172.16.126.2)OriginIGP,metric0,localpref100,valid,internal,best

InR8,172.16.126.6isthenexthopfor100.100.100.0/24advertisedbyR2andisconsideredthebestroute;therefore,itwillbeinstalledintheIProutingtable.Example15-73showsthatthebestwaytoreach172.16.126.6,thenexthopof100.100.100.0/24,isthroughR1,notthroughR2.Example15-73showiprouteCommandOutputShowstheBestRoutetoReach172.16.126.6

R8#showiproute172.16.126.6Routingentryfor172.16.126.0/24Knownvia"static",distance1,metric0RoutingDescriptorBlocks:*172.16.18.1Routemetricis0,trafficsharecountis1

Thehighlighted172.16.18.1isthenexthopfor172.16.126.6(nexthopof100.100.100.0/24).Therefore,alltrafficfromorthroughR8destinedfor100.100.100.0/24willgothrough172.16.18.1(R1).Example15-74showstheoutputofatraceroutedonefromR8to100.100.100.1.Thetrafficflowsthrough172.16.18.1,whichisR1.Example15-74tracerouteCommandOutputShowsTrafficGoingfromR1InsteadofR2

R8#traceroute100.100.100.1

Typeescapesequencetoabort.Tracingtherouteto100.100.100.1

1172.16.18.14msec4msec4msec2172.16.126.64msec8msec8msec3172.16.126.64msec8msec8msec

Solution

AroutermightprovidearoutetoBGPneighborbutmightneverbeinaforwardingpathtoreachthatroute.Thisisbecausepacketsareforwardedtothenexthopaddressoftheactualroute,whichmightnotbethesamerouterthatgavetherouteinthefirstplace.Ifroutingandforwardingpathsneedtomatch,caremustbetakeninhownexthopaddressesarelearnedthroughIGP.TofixtheprobleminFigure15-36,R8shouldhaveanIGPpathfor172.16.126.6(nexthopof100.100.100.0/24)throughR2.

Problem:MultipleBGPConnectionstotheSameBGPNeighborAS,butTrafficGoesOutThroughOnlyOneConnection—Cause:BGPNeighborIsInfluencingOutboundTrafficbySendingMEDorPrependedAS_PATHTypically,BGPnetworksaremultihomedtodifferentISPsorthesameISPtoprovideredundancyortoload-sharetraffic.Insomescenarios,theBGPnetworkmightbedualhomedtothesameISPandmightberunningBGPwiththatISP.InsteadofloadsharingtraffictotheISPovermultipleconnections,trafficmightexitonlyfromoneconnection.Theseconnectionsmightbeofequalbandwidthormightbedifferent.IfthemultipleEBGPconnectionlinksareofequalbandwidthandtrafficexitsfromonlyoneofthoseEBGPconnections,thisisnotdesirableandcanleadtosevereperformancedegradationbecauseofpacketlossandround-tripdelaysoverthecongestedlink.IftheEBGPconnectionsareofdifferentbandwidth—say,T3(45Mbps)andT1(1.5Mbps)—itmightbedesirableforalltraffictogooutthroughtheT3exitpoint.ThissectiondiscussestheissueinwhichallEBGPconnectionsgoingtothesameISPareofequalbandwidthbuttrafficgoesoutfromonlyoneofthoselinks.InthenetworkillustratedinFigure15-38,AS109hasthreeEBGPpeeringswithAS110,andAS110isadvertisingthesameprefixes,P1,P2,P3,andsoforth,atallpeeringpoints.However,alltrafficfromAS109destinedfortheseprefixesusesasingleexitpoint,X,withAS110.ThisresultsincongestionatXandunnecessaryusageoftheAS109backbone.

Figure15-38BGPNetworkinWhichTrafficIsRoutedInefficiently



Typically,EBGPspeakersagreeonsendingandacceptingMEDsfromeachother.However,AS110mightsendalowerMEDtoAS109forallitsprefixesatconnectionX.ThiswouldresultinAS109choosingExitXasabestpathtoreachPrefixesP1,P2,andP3.ThroughouttheBGPdomainofAS109,allBGPspeakersinstallExitXasanexthopforallroutes,P1,P2,andP3.AlltraffictotheseprefixesoriginatingortraversingthroughAS109chooseExitX.ThisresultsincloggingExitX,andtrafficusesavailablebandwidthintheAS109backbone.NoticethatexitpointsYandZareleftunusedfortrafficdestinedforPrefixesP1,P2,andP3.Solution

Youcanaddressthisproblemanumberofways:•RequestAS110tosendtheproperMEDforeachprefix.•Don’tacceptMEDfromAS110.•ManuallychangeLOCAL_PREFERENCEforP1,P2,andP3atalltheexitpoints,X,Y,andZ.

RequestAS110toSendtheProperMEDforEachPrefix

MEDexchangewithanEBGPpeerisatrickyandbilateralgame.Typically,BGPcarriersacceptMEDsonlyonamutualbasisinaprocessinwhichbothcarriersaccepteachother’sMED.AcceptingMEDmeansthatBGPcarrierscarryeachother’strafficthroughthebackboneandtrytoroutethetrafficinanoptimalfashion.IfthismutualagreementtakesplacebetweenAS109andAS110,AS109canrequestAS110tosendproperMEDsforprefixesannounced.Forexample,ifPrefixP1isclosertoExitX,AS110shouldsendaMEDforP1atX.AsimilarprocessshouldtakeplaceforP2atYandP3atZ,iftheyarecloserthere.TrafficdestinedforPrefixesP1,P2,andP3willridetheAS109backbonethemostandenterAS110attheoptimalexitfromtheAS109BGPspeaker’sview.Don’tAcceptMEDfromAS110

RequestAS110eithertonotsendtheMEDortomanuallysettheMEDto0atpeeringpointsX,Y,andZandforallprefixesfromAS110.ThisresultsinAS109pickingtheclosestexitpoint,X,Y,orZ,forPrefixesP1,P2,andP3throughthelowestIGP(OSPF,IS-IS,andsoon)costtoreachtheseexitpoints.ManuallysettingtheMEDto0canbedonethrougharoutemap,asdemonstratedinExample15-75.Example15-75ManuallySettingtheMEDto0toOverrideAnyAdvertisedMEDfromAS110

route-mapinfluencing_trafficpermit10

setmetric0!R1#routerBGP109neighbor4.4.4.4remote-as110neighbor4.4.4.4route-mapinfluencing_trafficin

ThisroutemapshouldbeappliedatallEBGPconnectionsbetweenAS109andAS110.Example15-75showsthisroutemapappliedonlybetweenR1andR4.TheconfigurationinExample15-75setstheMEDvalueforalltheprefixesfromAS110to0.Now,BGPspeakersinAS109usetheIGPcostasatiebreakerintheBGPbestpathselectionprocess.ThisresultsintrafficdestinedtoPrefixesP1,P2,andP3choosingtheclosestexitpoint.ManuallyChangeLOCAL_PREFERENCEforP1,P2,andP3atAlltheExitPointsX,Y,andZ

Tousethissolution,AS109mustknowwhichexitpointisclosertowhichprefix.Forexample,ifPrefixP1isclosertoexitpointX,AS109shouldmaketheLOCAL_PREFERENCE

higherforPrefixP1atX.ThismethodcanbeusedforP2andP3iftheyareclosertoYandZ,respectively.Example15-76showsasampleconfigurationatexitpointXtochangetheLOCAL_PREFERENCEhigherforP1thanthedefaultvalueof100.Example15-76SettingtheLOCAL_PREFERENCEValueHighertoSelecttheBestExitPoint

R1#routerBGP109neighbor4.4.4.4remote-as110neighbor4.4.4.4route-mapinfluencing_trafficin

route-mapinfluencing_trafficpermit10matchipaddress1setlocal-preference200!route-mapinfluencing_trafficpermit20setlocal-preference100

InExample15-76,theroutemapinfluencingtrafficisappliedbetweenR1andR4.Accesslist1,notshown,permitsPrefixP1only.Therefore,forP1,theLOCAL_PREFwillbe200;fortherestoftheprefixes,itwillbethedefault,whichis100.Asimilarroutemapwithproperprefixpermittinginaccesslist1needstobeappliedatallEBGPconnectionsbetweenAS109andAS110.WiththeconfigurationadditioninExample15-76,PrefixP1getsaLOCAL_PREFof200atR1,andallroutersinAS109receivePrefixP1withaLOCAL_PREFof200.R1andallroutersinAS109selectR1asanexitpointtoreachP1becauseofthehigherLOCAL_PREFERENCE.ThismethoddoesnotscalewellinlargeBGPnetworksinwhichBGPspeakersadvertiseandreceivethousandsofprefixes.ChangingtheLOCAL_PREFERENCEforeachprefixcouldbecomecumbersome.AsituationmightariseinwhichAS110PrefixesP1,P2,andP3alsoareadvertisedbyanotherEBGPspeaker—say,AS111.AS109mightsetahigherLOCAL_PREFERENCEforAS111thanfromAS110.Inthissituation,trafficfromAS109destinedforP1,P2,andP3takeAS111asanexitpoint,resultinginsuboptimalrouting.AS109mustensurethatAS110PrefixesP1,P2,andP3receivehigherLOCAL_PREFERENCEfromX,Y,andZ.

Problem:AsymmetricalRoutingOccursandCausesaProblemEspeciallyWhenNATandTime-SensitiveApplicationsAreUsed—Cause:OutboundandInboundAdvertisementAsymmetricroutingmeansthatpacketsflowingtoagivendestinationdon’tusethesameexitpointasthepacketscomingbackfromthatsamedestination.Thisisnotaprobleminitself,butitcancausesomeissueswhenNetworkAddressTranslation(NAT)oratime-sensitiveapplicationisinvolved.Symmetricalroutingisprobablyoneofhardestnetworkpoliciestoachieve.Figure15-40showsanetworkinwhichasymmetricalroutingoccurs.Figure15-40showsanetworksetupcomposedofAS109andAS110,andAS110hasprivateIPaddressinginthe10.0.0.0network.AS110hastwoexitpoints,R1andR2;however,R1istheonlyrouterperformingNATforanypacketssourcingfrominsideAS110.InFigure15-40,the10.1.1.1privateIPaddressistranslatedto131.108.1.1atR1when10.1.1.1issendingIPtraffictoprefixPinAS109.Fromthefigure,itisobviousthatthispacketwillenterAS109atInterfaceXofRouterR3andthatthispacketmightexitfromInterfaceYofR4.

Figure15-40NetworkVulnerabletoAsymmetricalRouting

Thismighthappenformultiplereasonsanditsresultscouldbesevere,themostcommonofwhicharelistedhere:•AS109BGPpolicymightdictatethatallAS110trafficshouldexitfromY.•AS110mightinfluenceAS109byusingMEDorAS_PATHprependtoreceivealltrafficfromAS109atExitY.•AS109BGPpolicymightgoverntheclosestexitpolicyforallAS110traffic.ForRouterR3inAS109,theclosestexitisY,regardlessofwherethedestination,131.108.1.1,is.•WhenR2receivesthereturnedpacketdestinedfor131.108.1.1,ithasnoNATentrytotranslatebackto10.1.1.1anditsimplydropsthispacket.•ThelinkbetweenR1andR3isofbiggerbandwidthbutthelinkbetweenR2andR4hassmallbandwidth.ThereturntrafficfromR2toR4couldaddsignificantdelaysintheoverallround-triptimeofthepacketfromAS109toAS110.


Becausepacketdropsandsluggishround-triptimesareobservedinAS109,administratorsinAS109mustfigureoutawaytodetermineifasymmetricalroutingisoccurring.AsimplepingfromR1toPrefixPinAS110willnothelpbecausereplypacketswillneverarrivebackatR1;instead,theywillbecomingbackatR2.AdministratorseitherwouldhavetosniffthepacketsatR1usingsniffersorwouldrunthedebugippacketcommandtoobservewhetherthepacketsaregoingthroughR1toreachPrefixPinAS110butarenotcomingback.AnydebugsinCiscoIOSSoftwaremustberunwithextremecautionbecausetoomuchoutputcandisturbtheperformanceoftherouter.IfsuchpacketsniffingisdoneatR2inAS109,administratorscanobservethatpacketsarereturningfromPrefixPandaredestinedtoaddressesinAS109.ThiscanassurethemthatIPtrafficisasymmetrical.Anotherapproachistousetraceroute;however,theproblemwithtracerouteisthatitprovidesthetrafficpathonlyinonedirection—fromsourcetodestination(AS109toAS110).Inasymmetricalrouting,administratorsaremoreinterestedinthedirectionoftrafficfromdestinationtosource(AS110toAS

109).ThiscanbeachievedonlyifAS110issuesatraceroutetothedestinationinAS109andAS109administratorsobservetheoutput.Solution

Theasymmetricalroutingissueisafairlydifficultproblemtotackleandsometimesisunavoidable.AsymmetricalroutingmightbeanissueincasesofNATwhenonlyonedevicemaintainstheNATtable;therefore,packetsmustcomeinandoutofthesamedevice.Time-sensitiveapplicationsalsomightfaceproblemswhentheexitpathoffersgoodthroughputbuttheentrypathissluggish,makingtheoverallround-triptime(RTT)bad.Asymmetricalroutingiseasytotackleinsmallnetworks,suchastheoneshowninFigure15-40.ToillustratehowAS109canavoidasymmetricalroutingwhenpeeringonlywithAS110,thefollowingconditionmustbemet:

IfapacketleavesfromR1tooutsideAS109,itmustcomebackintoAS109atR1.HowcanAS109achievethis?AS110mustknowthattoreachdestinations(131.108.1.0/24)inAS109,itmustusetheR3–R1peeringlink.Thefollowingareviablesolutions:•IntheBGPconfigurationofAS109,onlyR1advertises131.108.1.0/24toR3inAS110.AS110willhaveonlyonewaytoreach131.108.1.0/24,andthatisthroughtheR3–R1link,ensuringsymmetricalrouting.•BothR1andR2arerunningEBGPwithR3andR4,respectively.FromR1,advertise131.108.1.0/24toR3withaMEDof1;fromR2,advertise131.108.1.0/24toR4withaMEDof20.AS110willhavetwoadvertisements,butthepathfromthelowerMED(R1)willwinand,incasetheR1–R3BGPconnectionfails,thepathfromR2toR4willbeused.TheuseoftheMEDisdiscussedindetailinprevioussections.•Usingtheas-pathprependoptioninCiscoIOSSoftware,R2advertises131.108.1.0/24withtheAS_PATHlistcontainingAS109severaltimes.

Example15-77showstheconfigurationofR2toadvertise131.108.1.0/24withaprependedAS.Example15-77PrependingASNumbertoMakeanAS_PATHLonger

R2#routerbgp109

network131.108.1.0mask255.255.255.0neighbor4.4.4.4remote-as110neighbor4.4.4.4route-mapSYMMETRICALout

route-mapSYMMETRICALpermit10matchipaddress1setas-pathprepend109109109route-mapSYMMETRICALpermit20


InR2usingtheroutemapSYMMETRICALforneighborR4,R2isadvertising131.108.1.0/24throughaccesslist1andaddsintheAS_PATHAS109threeadditionaltimes.WhentheadvertisementgoestoR4,theoutputofBGPishighlightedinExample15-78.Example15-78BGPRoutingTableforR4

R4#showipbgp131.108.1.0BGProutingtableentryfor131.108.1.0/24,version19Paths:(2available,best#1,tableDefault-IP-Routing-Table)

1093.3.3.3from3.3.3.3(3.3.3.3)OriginIGP,metric0,localpref100,valid,internal,best

1091091091092.2.2.2from2.2.2.2(2.2.2.2)OriginIGP,metric0,localpref100,valid,external

ThesecondpathAS_PATHlistcontainsAS109listedfourtimes.OnetimeisfortheregularEBGPadvertisementfromR2,andthethreeadditionalpathstoAS109arebecauseoftheAS_PATHprependdoneinR2.Thebestpathisthefirstpath,whichcamefromR3toR4.ItisbestbecauseithasashorterAS_PATHlength.R3willhavetheregularsingleEBGPadvertisementfromR1,asshowninExample15-79.Example15-79EBGPAdvertisementfromR1toR3


ThisbestpathisadvertisetoR4(4.4.4.4)byR3.

Inshort,properBGPannouncementsmustbemadeatexitpointsandroutesmustbelearnedattherightplaceoftheAS.SmallerenterprisenetworkscanachievethisrathereasilywiththeprependedASpathsolution,butlargerenterpriseandISPnetworksfaceabiggerchallengetoensuresymmetricalrouting.ThisisbecauseISPshavealargernumberofprefixestoadvertise,alargernumberofexitpoints,andalargernumberofBGPpeeringrelationships.Unlesssymmetricalroutingisnotamust,especiallyinthecaseofNAT,mostnetworkstodayrunfinewithasymmetricalrouting.

TroubleshootingLoad-BalancingScenariosinSmallBGPNetworksProblem:LoadBalancingandManagingOutboundTrafficfromaSingleRouterWhenDualHomedtoSameISP—Cause:BGPInstallsOnlyOneBestPathintheRoutingTableInmultihomedscenarios,acommonconcernthatenterprisenetworkoperatorsfaceisimproperlyutilizingtheexternallinksgoingtotheISP.Typically,enterprisecustomersdual-hometoeitherthesameordifferentISPstoload-shareoutgoingandincomingtraffic.Figure15-41showsasimplesetupofR1ofAS109dualhomedtosameISPAS110atR2andR3.BothR2andR3areadvertisingprefix100.100.100.0/24toR1.Ideally,R1shouldload-sharetrafficdestinedforprefix100.100.100.0/24,but,bydefault,thisdoesnothappenandonlyoneofthemanypathsavailableisused.

Figure15-411ASDualHomedtoSameISPAS

BGPselectsonlyasinglebestrouteforaprefixoutofmanyalternatepaths.ThisisthedefaultbehaviorgovernedbyRFC1771.R1willhavetwopathsforprefix100.100.100.0/24—onefromR2andtheotherfromR3.R1willgothroughitsBGPbestpathcalculationandwillpickandinstallonerouteintheroutingtable.Figure15-42showstheflowcharttofollowtoresolvethisproblem.

Figure15-42Problem-ResolutionFlowchartDebugsVerification

Example15-80showsoutputinR1receivingtwopathsforprefix100.100.100.0/24butinstallingonlyone.Example15-80OutputofR1HavingMultiplePathsfor100.100.100.0/24butInstallingOnlyOneinItsRoutingTable

R1#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version2Paths:(2available,best#2)Notadvertisedtoanypeer110141.108.1.3from141.108.1.3(1.2.1.1)OriginIGP,metric0,localpref100,valid,external110141.108.1.1from141.108.1.1(141.108.6.1)OriginIGP,metric0,localpref100,valid,external,best


Solution

Fortunately,CiscoIOSSoftwareallows,byconfiguration,theinstallationofmorethanonerouteforthesameprefix,asdemonstratedinExample15-81.Thisdoescomewithatightcheck:MultiplepathsthatarecandidatestogointheroutingtablehavetheexactsameBGPattributeexceptfortherouterID(RID).IftwoormorepathshaveidenticalattributesexceptfortheRID,theycangointheroutingtableandloadsharingcanbeachievedfortrafficgoingtothatprefix.Example15-81ConfigurationAdditioninR1toAllowMultiplePathstoBeInstalledintheRoutingTablefor100.100.100.0/24

R1#routerbgp109neighbor141.108.1.1remote-as110neighbor141.108.1.3remote-as110

maximum-paths2

R1#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version2Paths:(2available,best#2)Notadvertisedtoanypeer110141.108.1.3from141.108.1.3(1.2.1.1)OriginIGP,metric0,localpref100,valid,external,multipath110141.108.1.1from141.108.1.1(141.108.6.1)

OriginIGP,metric0,localpref100,valid,external,best,multipath

Themaximum-path2commandallowstwoequalBGPpathstobeinstalledintheroutingtable.CiscoIOSSoftwareallowsamaximumofsixequalpaths.NoticethatintheBGPoutput,onlyonepathhas“best”initsoutput,butbothhave“multipath”andthusbothwillbeinstalledintheroutingtable,asshown

intheoutputofExample15-82.Example15-82MultiplePathsfor100.100.100.0/24intheRoutingTable

R1#showiproute100.100.100.0Routingentryfor100.100.100.0/24Knownvia"bgp109",distance20,metric0Tag110,typeexternalLastupdatefrom88.88.88.7800:34:36agoRoutingDescriptorBlocks:*141.108.1.1,from141.108.1.1,00:34:36agoRoutemetricis0,trafficsharecountis1ASHops1141.108.1.3,from141.108.1.3,00:34:36agoRoutemetricis0,trafficsharecountis1ASHops1

TrafficfromR1sentto100.100.100.0/24willusebothBGPconnections,thusloadsharingacrossdual-homedconnections.Problem:LoadBalancingandManagingOutboundTrafficinanIBGPNetwork—Cause:ByDefault,IBGPinCiscoIOSSoftwareAllowsOnlyaSinglePathtoGetInstalledintheRoutingTableEvenThoughMultipleEqualBGPPathsExist

IfmultiplepathsarereceivedfromdifferentIBGPneighborsforthesameprefix,onlyonebestpathwillbeselectedandinstalledintheroutingtable.Thisresultsinotheralternatepathsbeingunused.Figure15-43showsasimpleIBGPnetworkinwhichR1hasanIBGPpeeringwithR2andR3.BothR2andR3areadvertising100.100.100.0/24withnexthopsof2.2.2.2and3.3.3.3,respectively,toR1.Bydefault,R1goesthroughitsBGPbestpathcalculationandinstallsasingleroutefor100.100.100.0/24.Twopathsexist,butonlyonesendstrafficto100.100.100.0/24.

Figure15-43IBGPNetworkwithIBGPPeeringtoTwoRouters



Example15-83showsoutputinR1receivingtwoIBGPpathsforprefix100.100.100.0/24butinstallingonlyone.Example15-83OutputofR1HavingMultipleIBGPPathsfor100.100.100.0/24butInstallingOnlyOneinItsRoutingTable

R1#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version2Paths:(2available,best#1)Notadvertisedtoanypeer1102.2.2.2(metric11)from2.2.2.2(2.2.2.2)OriginIGP,metric0,localpref100,valid,internal,best1103.3.3.3(metric11)from3.3.3.3(3.3.3.3)OriginIGP,metric0,localpref100,valid,internal

R1#showiproute100.100.100.0Routingentryfor100.100.100.0/24Knownvia"bgp109",distance200,metric0Tag110,typeinternalLastupdatefrom2.2.2.200:32:25agoRoutingDescriptorBlocks:2.2.2.2,from2.2.2.2,00:32:25agoRoutemetricis0,trafficsharecountis1ASHops1

Solution

CiscoIOSSoftwareallows,byconfiguration,theselectionofmultipleIBGPpathsforthesameprefixtogointheroutingtable,asdemonstratedinExample15-84.

Example15-84ConfigurationAdditioninR1toAllowMultipleIBGPPathstoGetInstalledintheRoutingTablefor100.100.100.0/24

R1#routerbgp109neighbor2.2.2.2remote-as109neighbor3.3.3.3remote-as109neighbor2.2.2.2update-sourceloopback0neighbor3.3.3.3update-sourceloopback0

maximum-pathsibgp2

maximum-pathsibgp2allowstwoIBGP-learnedpathstobeinstalledintheroutingtable,andbothpathsareusedincarryingtrafficfor100.100.100.0/24.Formaximum-pathsibgptowork,thefollowingconditionsmustbemet:•Inbothpaths,allBGPattributes—LOCAL_PREF,MED,ORIGIN,andAS_PATH(entireAS_PATH)—mustbeidentical.•BothpathsmustbelearnedthroughIBGP.•Bothpathsmustbesynchronized.•Bothpathsmusthaveareachablenexthop.•BothpathsmusthaveanEQUALIGPcosttothenexthop.

Example15-85showstheoutputofBGPtableinR1afterapplyingthemaximum-pathsibgpcommand.Example15-85EffectofApplyingmaximum-pathsibgpCommandinR1

R1#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version2Paths:(2available,best#2)Notadvertisedtoanypeer1102.2.2.2from2.2.2.2(2.2.2.2)OriginIGP,metric0,localpref100,valid,internal,best,multipath1103.3.3.3from3.3.3.3(3.3.3.3)

OriginIGP,metric0,localpref100,valid,internal,multipath

Bothofthesepathsaremarkedas“multipath”inthehighlightedBGPoutput,andbothwillbeinstalledintheroutingtable,asshowninExample15-86.Example15-86MultipleIBGPPathsfor100.100.100.0/24intheRoutingTableofR1

R1#showiproute100.100.100.0Routingentryfor100.100.100.0/24Knownvia"bgp109",distance200,metric0Tag109,typeinternalLastupdatefrom88.88.88.7800:34:36agoRoutingDescriptorBlocks:*2.2.2.2,from2.2.2.2,00:34:36agoRoutemetricis0,trafficsharecountis1ASHops13.3.3.3,from3.3.3.300:34:36agoRoutemetricis0,trafficsharecountis1ASHops1

TrafficfromR1sentto100.100.100.0/24willusebothIBGPconnections,thusloadsharingacrossmultipleIBGPconnections.

TroubleshootingInboundIPTrafficFlowIssuesBecauseofBGPPoliciesJustasinmanagingoutboundIPtrafficfromanAS,CiscoIOSSoftwareoffersBGPoperatorsconfigurationoptionstomanageinboundtrafficinanAS.Itisimportantthatinboundtrafficfromotherautonomoussystemsbemanagedwell.Ifthisdoesnothappen,capacityofthenetworkwillnotbefullyutilized.Thiscausescongestioninonepartofthenetworkwhiletheotherpartsareunderutilized.Theendresultofthismismanagementofinboundtrafficflowissluggishthroughput,slowround-triptimes,anddelaysinIPtraffic.Therefore,itisessentialthatallinboundBGPpoliciesarecheckedandconfiguredcorrectly.SomeofthemostcommonproblemsinmanaginginboundIPtrafficinanASusingBGPareasfollows:•MultipleconnectionsexisttoanAS,butallthetrafficcomesinthroughoneBGPneighbor,X,inthesameAS.•ABGPneighborinAS110shouldjustbeabackupprovider,butsometrafficfromInternetstillcomesthroughAS110.•Asymmetricalroutingoccurs.•Traffictoacertainsubnetshouldcomethroughaparticularconnection,butitiscomingfromsomewhereelse.

Problem:MultipleConnectionsExisttoanAS,butAlltheTrafficComesinThroughOneBGPNeighbor,X,inthesameAS—Cause:EitherBGPNeighboratXHasaBGPPolicyConfiguredtoMakeItselfPreferredovertheOtherPeeringPoints,ortheNetworksAreAdvertisedtoAttractTrafficfromOnlyXAsFigure15-45illustrates,AS109hasmultipleBGPconnectionstoAS110,andAS109isadvertisingprefix100.100.100.0/24toAS110atalllocations.However,allthetrafficfromAS110to100.100.100.0/24comesthroughtheconnectionatX.Allotherlinksbetweenthetwoautonomoussystemsareunderutilized.

Figure15-45TwoEBGPConnectionsBetweenTwoAutonomousSystems,andOneLinkCarriesTraffic

Theremightbemultiplereasonsforthisbehavior,buttwoofthemostcommonscenariosareasfollows:•AS110hastheBGPpolicyconfiguredsothatallupdatesfromAS109atlocationXgettheLOCAL_PREFERENCEhigherthanatallotherneighborswithAS109.ThisresultsinmakingXthepreferredexitpointfromAS110toAS109for100.100.100.0/24.InFigure15-45,bothR1andR2inAS109areadvertising100.100.100.0/24toR6andR8inAS110,respectively.R8ischangingtheLOCAL_PREFERENCEof100.100.100.0/24sothatR8becomestheexitpointfromallBGPspeakersinAS110toreach100.100.100.0/24.ThissituationwillmakethelinkbetweenR6andR1unutilized,andallthetrafficto100.100.100.0/24willfollowtheR8–R2link.The“DebugsandVerification”sectionexplainshowR8canbeconfiguredtoachievethis.•AS109isinfluencingtrafficbyadvertisingdifferentMEDvaluesfortheprefix100.100.100.0/24atdifferentlocations.InFigure15-46,bothR1andR2areadvertising100.100.100.0/24,butwithdifferentMEDs.R1isadvertisingaMEDof20,whileaMEDof1comesfromR2atX.InAS110BGPbestpathselection,thelowestMEDcaninfluencethisdecision.AsdescribedinChapter14indetail,ifBGPbestpathselectionbreaksthetiebetweenthetwopathsbasedontheMED,thepathfromR2willwinandmakeitthemostattractiveexitpointfromAS110toAS109toreach100.100.100.0/24.The“DebugsandVerification”sectionexplainshowR2canbeconfiguredtoachievethis.

Figure15-46HowInboundTrafficIsInfluencedbytheMED



Thissectiondiscussesbothcasesofinboundtrafficinfluence,discussedintheproblem/causepresentationintheprecedingsection.Bothnecessaryrouterconfigurationsandshowcommandoutputsaredisplayedtoexaminetheproblem.

Case1

ThiscaseistheoneshowninFigure15-45,inwhichR8changedtheLOCAL_PREFERENCEfor100.100.100.0/24.Example15-87showstheconfigurationinR8.TheonlysignificantconfigurationchangeisinR8,whereroute-mapinfluencing_trafficisconfigured.Example15-87R8ConfigurationtoChangeLOCAL_PREFERENCEtoAffectBestPathCalculationofBGP

R8#routerbgp110nosynchronizationneighbor172.16.28.2remote-as109neighbor172.16.28.2route-mapinfluencing_trafficinneighbor172.16.126.6remote-as110

!access-list1permit100.100.100.0access-list2permitany

route-mapinfluencing_trafficpermit10matchipaddress1setlocal-preference200!route-mapinfluencing_trafficpermit20matchipaddress2setlocal-preference90

InExample15-87,R8isconfiguredwithroute-mapinfluencing_trafficsequence10,whichchangestheLOCAL_PREFERENCEto200forprefix100.100.100.0/24permittedbyaccesslist1.ThehighestLOCAL_PREFERENCEwinsinBGPbestpathcalculation,whichaffectsallIBGPspeakersinAS110(R6,inthisexample)andmakesthepathfromR8thebestexitpointtoreach100.100.100.0/24.Sequence20oftheroutemapinfluencingtrafficchangestheLOCAL_PREFERENCEattributeto90forallotherrouteslearnedfromneighbor172.16.28.2(R2).TheoutputinExample15-88showshowBGPinR6selectsR8asthebestexitpoint.Noticethatthefirstpath(thebestpath)isanIBGPpathfromR6toR8withaLOCAL_PREFERENCEof200.ThesecondpathisfromtheR1–R6connection.TheoutputfromR8inExample15-88showsthatithasonlyapathfor100.100.100.0/24andthatisfromR2.LOCAL_PREFERENCEisshownas200,makingitabestpathadvertisedtoR6.Example15-88showipbgpCommandOutputRevealstheBestExitPoint

R6#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version6Paths:(2available,best#1,tableDefault-IP-Routing-Table)Advertisedtononpeer-grouppeers:172.16.126.1109172.16.28.2(metric20)from172.16.28.8(172.16.8.8)OriginIGP,metric0,localpref200,valid,internal,best109172.16.126.1from172.16.126.1(172.16.1.1)OriginIGP,metric0,localpref100,valid,external

R8#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version2Paths:(1available,best#1,tableDefault-IP-Routing-Table)Notadvertisedtoanypeer

109172.16.28.2from172.16.28.2(172.16.2.2)OriginIGP,metric0,localpref200,valid,external,best

Case2

ThiscaseistheoneshowninFigure15-46,inwhichR1andR2advertisedifferentMEDsfor100.100.100.0/24toR6andR8,respectively.Example15-89detailstheconfigurationneededinR1andR2.R6andR8havethestandardBGPconfigurationforasimpleneighborrelationship,soitisnotshown.R1andR2haveroute-mapMED_advertisementthatadvertisesMEDstotheirEBGPneighborsR6andR8,respectively.Example15-89MEDAdvertisementfromR1andR2toInfluenceInboundTrafficfor100.100.100.0/24

R1#routerbgp109nosynchronizationbgplog-neighbor-changesnetwork100.100.100.0mask255.255.255.0network200.100.100.0neighbor172.16.126.2remote-as109neighbor172.16.126.6remote-as110neighbor172.16.126.6route-mapMED_advertisementout


!route-mapMED_advertisementpermit10matchipaddress1setmetric20!route-mapMED_advertisementpermit20matchipaddress2setmetric100

R2#routerbgp109nosynchronizationnetwork100.100.100.0mask255.255.255.0neighbor172.16.28.8remote-as110neighbor172.16.28.8route-mapMED_advertisementoutneighbor172.16.126.1remote-as109!

!access-list1permit100.100.100.0access-list2permitany

route-mapMED_advertisementpermit10matchipaddress1setmetric1!route-mapMED_advertisementpermit20matchipaddress2setmetric200

InExample15-89,R1andR2haveroute-mapMED_advertisementconfiguredwithneighborsR6andR8,respectively.InthecaseofR1,sequence10oftheroutemapsetsMEDof20for100.100.100.0/24by

accesslist1andsetstherestoftheprefixMEDto100bysequence20oftheroutemap.R2isconfiguredinasimilarmannertoR1,buttheMEDof1issenttoR8for100.100.100.0/24andaMEDof200issentforrestoftheprefixes.TheoutputinExample15-90showstheBGPoutputofprefix100.100.100.0/24.TheMEDvalueof1islearnedfromR2atR8,makingthisroutethebestrouteinAS110.AlltrafficfromAS110toprefix100.100.100.0/24willexitfromXatR8.NoticetheoutputinR6,whichpreferstheIBGPupdatefromR8becauseofalowerMEDforprefix100.100.100.0/24.Example15-90BGPOutputforPrefix100.100.100.0/24RevealstheBestRoute


R6#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version13Paths:(2available,best#2,tableDefault-IP-Routing-Table)Advertisedtononpeer-grouppeers:172.16.126.1109172.16.126.1from172.16.126.1(172.16.1.1)OriginIGP,metric20,localpref100,valid,external109172.16.28.2(metric20)from172.16.28.8(172.16.8.8)OriginIGP,metric1,localpref100,valid,internal,best

Solution

ReturntrafficinfluencecanbedesiredasinCase2,oritmighthappenasinCase1.AS109BGPoperatorsmustunderstandwhatiscausingthisinfluence.InCase1,inwhichAS110changeditsBGPpolicybyalteringtheLOCAL_PREFERENCE,BGPdoesnotofferanycommandsforAS109toinfluencetheAS110policy.EachAScanforceitsownpolicy,andtheoutsideAScannotchangethat.ThesolutionfortheCase1problemlieswiththeAS109administratorrequestingAS110toremoveanypolicythataffectsAS109.InCase2,AS109announcedaMEDandAS110wasnotconfiguredtochangeLOCAL_PREFERENCE(asinCase1).IftheMEDannouncementisnotproducingthedesiredbehaviorforAS109inboundtrafficmanagement,theseMEDsshouldberemoved,andthenormalBGPpoliciesofAS110shoulddecideonthebestentryintoAS109.InlargerBGPnetworkswithnumerousexitpointsandmultipleBGPASconnections,trafficbalancecouldbecomeachallenge.Therefore,carefulBGPpoliciesandpeeringagreementsmustbecreatedbetweenBGPspeakers,andtrafficflowmustbecarefullyobserved.

Problem:MultipleConnectionsExisttoSeveralBGPNeighbors,butMostoftheTrafficfromInternetto100.100.100.0/24AlwaysComesinThroughOneBGPNeighborfromAS110—Cause:RouteAdvertisementsfor100.100.100.0/24inAS109AttractInternetTrafficThroughThatBGPNeighborinAS110

WhenaBGPprefixisobservedfromaglobalInternetpoint-of-view,fewBGPattributesstayintactfromtheoriginatorofthatprefix.Forexample,AS_PATH,ORIGIN_CODEandAGGREGATORarethemostcommonBGPattributesthatgetcarriednomatterhowmanyautonomoussystemsaBGPupdatecrosses.Themostpopularattributes,LOCAL_PREFERENCEandMED,donotcrossanASboundary.Therefore,theydonotplayanyroleininfluencingreturntrafficfromsourcesmultipleautonomoussystemsaway.AsdiscussedinChapter14,themostcommonBGPattributesthatgetusedintheBGPbestpathalgorithmareLOCAL_PREFERENCE,AS_PATHandMED.Outofthese,AS_PATHistheonlyattributethatstaysintactfromtheoriginatoroftheprefixtoanyInternetBGPspeaker.Figure15-48showstheBGPupdateflowfromAS109andalsoshowsBGPbestpathselectionateachintermediateAS.AS109isoriginatingAS100.100.100.0/24,anditsgoalistoreceivetrafficfromtheInternetfor100.100.100.0/24onlythroughAS110,notthroughAS111.

Figure15-48BGPUpdateFlowfromAS109/BestPathSelectionatIntermediateAutonomousSystemsSolution

ThefollowingaretwocommonpracticesthatBGPadministratorsusetoachievethepreviouslymentionedgoal:•AS109advertisesnetwork100.100.100.0/24withamuchlongerAS_PATHlisttoallBGP

neighborsexceptAS110.Ifautonomoussystems110,112,and113donotmakeanyadditionalchangesintheBGPpolicy,autonomoussystems112and113alwaysgothroughAS110toreach100.100.100.0/24.Thisresultsinalltraffictonetwork100.100.100.0/24enteringAS109totraverseAS110;thelinksbetweenAS109andAS111forredundancy.•AS109advertises100.100.100.0/24onlytoAS110,nottoBGPneighborAS111.Therefore,trafficfromtheInternetseesonlyonepathtoreach100.100.100.0/24—throughAS110toAS109.However,thiscaselosesredundancyifAS109losesitsBGPsessionwithAS110.

TroubleshootingBGPBestPathCalculationIssuesChapter14discussesindetailhowtheBGPbestpathalgorithmworkstoselectasinglebestrouteoutofmanytoinstallintheIProutingtableandtoadvertisetootherBGPneighbors.Thissectiondiscussesafewcasesthatdealwithscenariosinwhichbestpathselectiondoesnotworkasintended.Thefollowingarethecasesdiscussedinthissection:•WhentherouterID(RID)selectsthebestpath,BGPdoesnotalwaysselectthelowestRIDpathasbest,asdescribedinthebestpathalgorithm.•TwoBGPneighborsinthesameASadvertiseadifferentMEDforthesameprefix,butthelowestMEDisnotselectedasbest,asdescribedinthebestpathalgorithm.

Problem:PathwithLowestRIDIsNotChosenasBestThisisthescenarioinwhichtwoormorepathsfromEBGPneighborshaveidenticalBGPattributesandBGPbestpathselectionisdonebasedontheRID.TheBGPbestpathselectionrulestatesthat,incaseallotherattributesareidentical,thepathwiththelowestRIDshouldbeselectedasbest.Inthiscase,thepathwiththehighestRIDisselectedasbest.InCiscoIOSSoftware,ifBGPselectsabestpathbasedontheRIDandanewpathcomesinwithalowerRID,withallotherattributesbeingequal,thepreviouslyselectedbestpathwillnotbetoggledandwillremainunchanged.ThisisdoneintentionallyinCiscoIOSSoftwaretomaintainstabilityinBGPpathsbecausenewlyselectedpathsmustbeadvertisedtoallBGPneighbors,andthepreviousonemustbewithdrawn.Toavoidthischurn,BGPinCiscoIOSSoftwaredoesnotselectanewbestpathifthepreviouspathselectedwasdonebasedonRID.Figure15-49showstheflowcharttofollowtoresolvethisproblem.


Figure15-50showsanetworkcomposedofR1inAS109,andR3andR5inAS110.BothR3andR5areadvertising100.100.100.0/24.TheRIDsofR3andR5are3.3.3.3and5.5.5.5,respectively.

Figure15-50NetworkinWhichPathwithLowestRIDIsNotChosenasBest

Example15-91showsthenecessaryconfigurationinR1,R3,andR5toformaBGPneighbor

relationship,andforR3andR5toadvertise100.100.100.0/24.Example15-91ConfiguringR3andR5toAdvertise100.100.100.0/24andtoFormanEBGPNeighborRelationshipwithR1

R1#routerbgp109bgprouterid1.1.1.1neighbor1.1.2.3remote-as110neighbor1.1.7.5remote-as110

R3#routerbgp110bgprouterid3.3.3.3network100.100.100.0mask255.255.255.0neighbor1.1.2.1remote-as109neighbor1.1.8.5remote-as110

R5#routerbgp110bgprouterid5.5.5.5network100.100.100.0mask255.255.255.0neighbor1.1.7.1remote-as109neighbor1.1.8.3remote-as110

ThehighlightedcommandsshowhowRIDcanbeconfiguredmanuallyinBGP.EachrouterisconfiguredwithrecognizableRIDs.ThisisdonetoeaseinunderstandingBGPoutputslaterinthissection.Now,R1willreceive100.100.100.0/24fromR3andR5.TheoutputinExample15-92showsthatR1isreceivingboththeupdatesandthatitpreferstheupdatefromR5.Example15-92BGPOutputinR1toShowtheBestPathfor100.100.100.0/24

R1#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version2Paths:(2available,best#2,tableDefault-IP-Routing-Table)Advertisedtononpeer-grouppeers:1.1.2.31101.1.2.3from1.1.2.3(3.3.3.3)OriginIGP,metric0,localpref100,valid,external1101.1.7.5from1.1.7.5(5.5.5.5)OriginIGP,metric0,localpref100,valid,external,best

AllBGPattributes(LOCAL_PREF,MED,ORIGINCODE,andEXTERNALversusINTERNAL)areidentical.AccordingtoBGPbestpathcalculationrules,asdescribedinChapter14,thebestpathshouldbetheonewiththelowestRIDifallotherattributesareidentical.Inthisoutput,thepathfromRID3.3.3.3(R3)shouldhavebeenthebest,buttheoutputinExample15-92showsthatthebestpathisfrom5.5.5.5(R5).Toexplainthisproblem,youmustunderstandthesequenceofeventsinR1.InR1,thepathfromR5musthavebeenreceivedbeforethepathfromR3.IfR1hasselectedthepathfromR5asbest,whenthepathfromR3comesandthedecidingfactorforthebestpathcalculationisRID,R1willkeepR5asthebesteventhoughR3offeredalowerRID.Solution

IfR1wantstheproperRIDtobethedecidingfactorinbestpathcalculation,itmustaddaBGPknobinCiscoIOSSoftware,asshowninExample15-93.

Example15-93BGPKnobtoCompareRIDinBestPathSelection

R1#routerbgp109bgprouterid1.1.1.1bgpbestpathcompare-routeridneighbor1.1.2.3remote-as110neighbor1.1.7.5remote-as110

ThehighlightedcommandenablesR1tocomparetheRIDsofallthepathsandpickthelowestRIDasthebestinBGPbestpathcalculation.TheeffectofthisconfigurationchangetakesplacewhentheBGPscannerruns.(ItrunseveryminuteinCiscoIOSSoftware.)TheoutputinExample15-94showsthatR1hasselectedtheR3pathasbestbecausetheR3pathhasalowerRID(3.3.3.3)thantheR5path(5.5.5.5).Example15-94BGPBestPathSelectionUsingRID

R1#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version3Paths:(2available,best#1,tableDefault-IP-Routing-Table)Advertisedtononpeer-grouppeers:1.1.7.51101.1.2.3from1.1.2.3(3.3.3.3)OriginIGP,metric0,localpref100,valid,external,best1101.1.7.5from1.1.7.5(5.5.5.5)OriginIGP,metric0,localpref100,valid,external

Problem:LowestMEDNotSelectedasBestPathInsomescenarios,therouterdoesnotselectthelowestMEDadvertisedbyneighborsasthebestpath.Figure15-51showsanetworksetupthathasAS109(R1)connectedtoAS110attwoBGPpeeringpoints(R3andR5);AS109hasoneconnectionwithAS111(R4).R1isreceiving100.100.100.0/24fromallthreeEBGPconnections.AllneighborsareadvertisingMEDstoinfluencereturntrafficfromAS109.R3andR5areadvertisingMEDsof50and30,respectively,whereasR4issendingaMEDof40.

Figure15-51NetworkinWhichLowestMEDIsOmittedfromSelectionofBestPath

R1receivesallthreeadvertisementsbutfailedtoselectthepathfromR5(lowestMED)asthebestpath;instead,itselectedthepathfromR3(highestMED)asthebest.ThismightcausetrafficpolicydisturbancefromtheperspectiveofbothAS109andAS110becausethelinkbetweenR1andR3couldbesmaller,andthelinkbetweenR1andR5mightbebigger;bothautonomoussystemswantR1andR5touseforalltraffic.InFigure15-51,bothAS109andAS110expectthatR1willselectthepathfromR5asbestbecauseR5clearlyisadvertisingaMEDof30,ascomparedtoaMEDof50fromR3.ByBGPbestpathcalculation,thepathfromthelowerMEDshouldbeselectedasbest.Inaddition,R4isadvertising100.100.100.0/24withaMEDof40.OneBGPrulethatmustbekeptinmindistheruleofMEDcomparison.Bydefault,CiscoIOSSoftwarewillnotcomparetheMEDsiftwopathscamefromdifferentautonomoussystems.R1willignoretheMEDwhenitiscomparingthepathsbetweenR5andR4.ThetiebreakerinR1toselectabestpathbetweenR4andR5willbesomethingotherthantheMED.IfnootherBGPattributesareused,theRIDbreaksthetietoselectthebestpath.The“DebugsandVerification”sectionshowsthesequenceofeventsandoutputfromtheR1BGPtabletoshowthatbestpathisindeednottheonethathasthelowestMED(R5).Figure15-52showstheflowcharttofollowtoresolvethisproblem.


Example15-95showstheoutputfromR1for100.100.100.0/24.Example15-95SelectionofBestPath,IgnoringLowestMED

R1#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version3Paths:(3available,best#1,tableDefault-IP-Routing-Table)Advertisedtononpeer-grouppeers:1.1.7.51.1.3.4

1102001.1.7.5from1.1.7.5(5.5.5.5)OriginIGP,metric30,localpref100,valid,external1112001.1.3.4from1.1.3.4(4.4.4.4)OriginIGP,metric40,localpref100,valid,external1102001.1.2.3from1.1.2.3(3.3.3.3)OriginIGP,metric50,localpref100,valid,external,best

Theoutputin15-95showsthatR1hasthreepathsinthisorder:1Path1:ThispathisfromR5(RID5.5.5.5),withaMEDof30.2Path2:ThispathisfromR4(RID4.4.4.4),withaMEDof40.3Path3:ThispathisfromR3(RID3.3.3.3)withaMEDof50.

IfthebestpathselectionalgorithmdescribedinChapter14wererun,thefollowingwouldbetheselectionprocess:1Path1iscomparedwithPath2.AllBGPattributesarethesameexceptfortheMED.However,these

twopathscamefromdifferentautonomoussystems—110and111,respectively—sotheMEDwillnotbethetiebreakerandwillbeignored.ThetiebreakerwillbetheRID.BasedontheRID,path2hasalowerRID(4.4.4.4)thanpath1(5.5.5.5).Therefore,path2isthewinner.

2ThewinnerofStep1,path2,iscomparedwithpath3.Again,theMEDwillbeignoredbecauseofadifferentAS_PATH.ThelowerRIDofpath3(3.3.3.3)willwinagainpath2’sRID(4.4.4.4).

Path3isselectedasbesteventhoughithasahigherMEDthananyofthepaths(MED50).Solution

Tosolvethisproblem,CiscoIOSSoftwaremustallowcomparisonofMEDsbetweendifferentautonomoussystems.Example15-96showstheconfigurationknobthatcanbeaddedinR1toachievethat.Example15-96KnobtoCompareMEDfromDifferentAutonomousSystems

R1#routerbgp109bgprouterid1.1.1.1bgpalways-compare-medneighbor1.1.2.3remote-as110neighbor1.1.7.5remote-as110neighbor1.1.3.4remote-as111

ThehighlightedcommandenablesR1tocompareMEDsinBGPbestpathselectioneventhoughthepathscamefromdifferentautonomoussystems.Example15-97showstheBGPtablefor100.100.100.0/24afterthechange.Example15-97DesiredBGPPathSelectionAfterComparingMEDsBetweenDifferentAutonomousSystems

R1#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version3Paths:(3available,best#1,tableDefault-IP-Routing-Table)Advertisedtononpeer-grouppeers:1.1.3.41.1.2.3

1102001.1.7.5from1.1.7.5(5.5.5.5)OriginIGP,metric30,localpref100,valid,external,best1112001.1.3.4from1.1.3.4(4.4.4.4)OriginIGP,metric40,localpref100,valid,external1102001.1.2.3from1.1.2.3(3.3.3.3)OriginIGP,metric50,localpref100,valid,external

ThebestpathistheonethathasthelowestMED.Asstatedearlier,choosingthepathwiththelowestMEDcouldbecrucialiflinksbetweenautonomoussystemsareofdifferentbandwidthandapathfromahigher-bandwidthneighborissendingalowerMED.Inaddition,oneimportantdesignrecommendationisthatthecommandbgpalways-compare-medshouldbeenabledonalltheroutesinanASrunningBGP;otherwise,packetforwardingloopsmightoccur.Forexample,RouterArunningthiscommandmightpointitsbestpathtoRouterB,whereasRouterBwithoutthiscommandmightpointthebestpathbacktoRouterA,resultinginaroutingloop.

TroubleshootingBGPFilteringBGPoffersapowerfulfilteringmechanismwhenadvertisingorreceivingBGProutes.FilteringrulesaredefinedbasedontheBGPpeeringrelationship.AnISPmightwanttoexchangefullBGProutestoanotherISPbutmightwanttogiveonlypartialroutestoitsenterprisecustomer.Ontheotherhand,anenterprisecustomermightwanttoadvertiseIPblocksthatruninitsnetworkonlytoitsprovider(say,ISP1)andmightwanttofilteradvertisementsfromallotherInternetroutesreceivedfromanotherprovider(say,ISP2).SuchrequirementeasilymightbemetbyusingpowerfulfilteringoptionsavailableinCiscoBGP,whichcanuseaccess-listfilters(bothstandardandextended),AS_PATHfiltering,communityfiltering,andprefix-listfiltering.AllofthesefilteringmethodscanbeappliedmodularlythroughCiscoIOSSoftwareroutemapsonaper-neighborbasisordirectlytotheneighbors.Theonlyexceptioniscommunity-basedfiltering,whichcanbeappliedonlythroughtheroutemap.Thissectiondiscussesissuesrelatedtoaccess-list,prefix-list,andAS_PATH–basedfiltering.

Problem:StandardAccessListFailstoCaptureSubnetsInIPnetworks,IPprefixesareslicedindifferentsubnets,andthesubnetmaskcarriedintheroutingtabledoesidentificationofthesesubnets.ThecurrentInternetBGPtablehasmanyIPprefixeswithidenticalnetworknumbersbutdifferentmasks.Example15-98showssuchanexampleinwhichR4hasthreedifferentmaskedprefixesof13.13.0.0.Toillustratethispoint,staticroutesarecreatedinR4,asshownbyoutputinExample15-98.Furthermore,thesestaticroutesareadvertisedinBGPbythehighlightedredistributestaticcommand.Example15-98ThreeDifferentMaskedStaticRoutesofSameNetworkandTheirAdvertisementinBGP

R4#showiproutestatic13.0.0.0/8isvariablysubnetted,3subnets,3masksS13.13.0.0/20isdirectlyconnected,Serial0S13.13.0.0/16isdirectlyconnected,Serial1S13.13.1.0/24isdirectlyconnected,Serial2

R4#routerbgp2redistributestaticneighbor131.108.1.1remote-as1noauto-summary

R1isanEBGPneighborofR4.R1’sgoalistoreceiveonly13.13.0.0/16andtofilteranymorespecificroutesof13.13.0.0.Typically,R1wouldusesomesortoffilteringtoblocktheseunwanted,morespecificroutes.DistributelistsareusedcommonlytoblockorallowpathsinBGP.ABGPoperatormightuseastandardorextendedaccesslistinconcertwithdistributelists.Standardaccesslistdonotallowfilteringbasedonthesubnetmaskoftheroute,andthisisthemostcommonmistakethatBGPoperatorsdowhenapplyingstandardaccesslistsindistributelists.Chapter14describesinsomedetailthedifferencebetweenstandardandextendedaccesslistswhenusedwithdistributelistsorinroutemaps.Figure15-53showstheflowcharttofollowtoresolvethisproblem.


Example15-99showstheBGPconfigurationofR1,withneighborrelationshipsandthedistribute-listcommandusingaccesslist1.Example15-99BGPConfigurationinR1UsingStandardAccessListindistribute-listCommand



distribute-list1meansthatanyBGPupdatesthatcomefrom131.108.1.2willbeexaminedbyaccesslist1.Accesslist1hasapermitstatementfor13.13.0.0withanexactmatchofthefirsttwooctets(13.13);itdoesn’tcareaboutthelasttwooctets(0.0).Standardaccesslist1hasnomentionofamaskof13.13.0.0,soallmasksareaccepted.TheoutputinExample15-100showsthattheBGPtableinR1isreceivingallthreemasksof13.13.0.0.Example15-100MaskofBGPUpdateIsIgnoredWhenaDistributeListUsesaStandardAccessList


NetworkNextHopMetricLocPrfWeightPath*>13.13.0.0/20131.108.1.2002?

*>13.13.0.0/16131.108.1.2002?*>13.13.1.0/24131.108.1.2002?

Solution

UseextendedaccesslistsorprefixliststhatsupportpropermaskcheckofrouteswhenreceivedinBGP.Example15-101showsusageofextendedaccesslist101,whichchecksnotonlythenetworknumber(13.13.0.0)butalsothemaskoftheupdate.Example15-101ExtendedAccessListCheckstheSubnetMaskofthePrefix



Theextendedaccesslisthastwoparts:•Thenetworkpart—13.13.0.00.0.255.255,whichallows13.13.x.x,wherexcananynumberbetween0and255.•Themaskpart—255.255.0.00.0.0.0.Withall0sinwildcard,themaskcanonlybe255.255.0.0,meaning/16.

TheoutputinExample15-102showsthatR1isreceivingonly13.13.0.0/16afterapplyingthischange.Example15-102ConfirmingExtendedAccessListFiltersRoutesSuccessfully


NetworkNextHopMetricLocPrfWeightPath*>13.13.0.0/16131.108.1.2002?

Problem:ExtendedAccessListsFailstoCapturetheCorrectMaskedRouteToreducethesizeofInternetBGP/routingtables,BGPoperatorsareforcedtoadvertiseaggregatedprefixesandsuppresssubnettedIPblocks.Toachievethis,almostallISPsexpecttheirpeeringISPsandcustomerstoadvertiseaggregatedblocksof,say,21(255.255.248.0)ofIPblocksandwillrefusetoacceptanyprefixwithamaskgreaterthan21.ProperBGPfilteringmustbeinplaceatpeeringpointssothatprefixeswithmasksgreaterthan21canbefilteredoutandonlyprefixeswithmaskslessthan21areaccepted.Manytimes,useofextendedaccesslistsisnotunderstoodproperly,resultinginfailuretocapturesubnettedprefixeswithmasksgreaterthan/21,forexample.Figure15-54showsasimpletwo-ISPnetworkrunningEBGP.ISPAS109issupposedtobeadvertisingonlythreeprefixestoISP2AS110.Theexpectedprefixesare100.100.100.0/21,99.99.99.0/21,and89.89.89.0/21.However,AS109hassubdividedtheseIPblocksintosmallersubnets,toassigntheminternallyinthenetwork.

Figure15-54Two-ISPNetworkRunningEBGP

Mistakenly,AS109isadvertisingallthetinysubnetstoAS110,resultinginitsunnecessaryincreaseinBGPandIProutingtablesize.Thisproblemhastwocauses:•AS109shouldfiltersubnetsandadvertiseonlytheaggregatedthreeprefixes.•AS110shouldfiltersubnetsandacceptonlytheaggregatedthreeprefixes.



Example15-103showsR1’sconfigurationtodefinestaticroutesforsubnettedblocksandBGP

configurationtoadvertisethesesubnettedblockstoR2.Example15-103ConfigurationinR1toCreateandAdvertiseSmallerSubnetRoutestoR2

R1#iproute100.100.100.0255.255.248.0Null0iproute100.100.100.128255.255.255.128serial0iproute100.100.100.192255.255.255.192serial1

iproute99.99.99.0255.255.248.0Null0iproute99.99.99.128255.255.255.128serial2iproute99.99.99.192255.255.255.192serial3

iproute89.89.89.0255.255.248.0Null0iproute89.89.89.128255.255.255.128serial4iproute89.89.89.192255.255.255.192serial5

routerbgp109neighbor131.108.1.2remote-as110redistributestaticnoauto-summary

TheredistributestaticcommandredistributesthesesubnetsinBGPandadvertisestoonlyneighborR2(131.108.1.2)inAS110.Example15-104showsR2receivingallthesubnetsinitsBGPtable.Example15-104R2BGPTableShowsAllSubnetsReceived


NetworkNextHopMetricLocPrfWeightPath*>100.100.100.0/21131.108.1.100109?*>100.100.100.128/25131.108.1.100109?*>100.100.100.192/26131.108.1.100109?*>99.99.99.0/21131.108.1.100109?*>99.99.99.128/25131.108.1.100109?*>99.99.99.192/26131.108.1.100109?*>89.89.89.0/21131.108.1.100109?*>89.89.89.128/25131.108.1.100109?*>89.89.89.192/26131.108.1.100109?

ThehighlightedprefixesaretheonlyprefixesthatshouldhavebeenacceptedbyR2.Moreover,thoseareonlyprefixesthatR1shouldhaveadvertisedtoR2.Solution

Tosolvethisproblem,eitherR1shouldadvertiseonlythe/21sandblockallthehigher-maskprefixes,orR2shouldblockhigher-maskprefixesandacceptonly/21s.Thissectiondiscussestwomethodstoaddressthisproblem.BothsolutionsaregenericenoughforR1andR2toapply.IfR1usesthesolution,itmustapplytheconfigurationontheoutboundpolicyforR2;ifR2isapplyingthechange,itmustapplyitasaninboundpolicytoR1.Thetwosolutionsareasfollows:•Useanextendedaccesslist.•Useaprefixlist.

ExtendedAccessListSolution

AgenericfilterneedstobecreatedthatcanapplytoanyIPnetworkbutthathasatightfilterforthemaskoftheprefix.WithBGPfiltering,youwouldusethefollowingextendedaccesslist:

access-list101permitipNETWORKWILDCARDMASKWILDCARD

AWILDCARDof0meansanexactmatch,whereasaWILDCARDof1means“don’tcare.”AnextendedaccesslistthatwouldpermitanyIPnetworkwhosemaskis/21orlower(20,19,andsoon)isconfiguredasfollows:


0.0.0.0255.255.255.255meansanyIPnetwork.255.255.248.0255.255.248.0meansthatamaskofthisprefixcanbeonly/21orlower(/20,/19,andsoon).CiscoIOSSoftwarehasanimplicitdenyattheendofeachaccesslist,soallprefixeswhosemasksaregreaterthan21aredenied.Examples15-105and15-106demonstratetwomethodsinwhichaccesslist101canbeappliedinR1.Example15-105ApplyingAccessList101withthedistribute-listCommandtotheNeighbor

R1#routerbgp109neighbor131.108.1.2remote-as110neighbor131.108.1.2distribute-list101out

Example15-106ApplyingAccessList101withtheroute-mapCommandtotheNeighbor

routerbgp109neighbor131.108.1.2remote-as110neighbor131.108.1.2route-mapFILTERINGout

route-mapFILTERINGpermit10matchipaddress101

Bothcommandshavethesameeffectofblockingtheadvertisementofanyprefixwithamaskgreaterthan/21.Examples15-107and15-108demonstratetwomethodsinwhichaccesslist101canbeappliedinR2.Example15-107ApplyingAccessList101withthedistribute-listCommandtotheNeighbor


Example15-108ApplyingAccessList101withtheroute-mapCommandtotheNeighbor

R2#routerbgp110neighbor131.108.1.1remote-as109neighbor131.108.1.1route-mapFILTERINGinroute-mapFILTERINGpermit10matchipaddress101

Bothcommandshavethesameeffectofblockinganyprefixwithamaskgreaterthan/21.

Apartfromdistributelists,prefixlistscanbeusedtoachievethesamegoal.YoucanapplythefollowingprefixlisttoR1andR2inasimilarfashionasadistributelistwithboththeneighborstatementandwitharoutemap:

ipprefix-listFILTERINGseq5permit0.0.0.0/0le21

0.0.0.0meansanyprefix,and0le21meansthatthemaskofanyprefixcouldbefrom0andlessthanorequal(le)to21.Allotherhigher-maskedprefixes(22,25,26,andsoon)willbedeniedbecauseofanimplicitdenyattheendofeachCiscoIOSSoftwarefilter.AfterapplyingthedistributelistorprefixlistinR1orR2,Example15-109showsthattheoutputoftheBGPtableinR2isreducedtoreceivingjust/21prefixes.Example15-109ProperFilteringResultedinReductioninBGPTableSize


NetworkNextHopMetricLocPrfWeightPath*>100.100.100.0/21131.108.1.100109?*>99.99.99.0/21131.108.1.100109?*>89.89.89.0/21131.108.1.100109?

Thedistributelistandprefixlisttakeeffectwhenupdatescomefromaneighbor.IfBGPupdatesalreadyhavebeenreceived,applyingthedistributelistorprefixlistwillhavenoeffect.Toreceiveupdatesfromneighbors,routersmustrestarttheBGPsessionbyusingthecommandsclearipbgpneighbororclearipbgpneighborsoftin,ifsoftreconfigurationisenabled.RefertotheCiscoIOSSoftwaremanualformoredetailsonthiscommand.ArecentfeatureofCiscoIOSSoftwarecalledrouterefreshautomaticallyrequestsfresherupdatesfromaneighborwhenanypolicy,suchasadistributelistoraprefixlist,getsapplied.ThisfeaturedoesnotrequireclearingofthecurrentBGPsession.

Problem:AS_PATHFilteringUsingRegularExpressionsAllBGPupdatesthatcontainanannouncementofIPprefixeshaveanAS_PATHfieldthatlistsalltheautonomoussystemsthatthisupdatehastraversed.BGPoperatorsusefilteringagainstthisAS_PATHfieldtoallowordenyIPprefixesandalsotoapplyBGPpolicybasedonAS_PATHfiltering.ThismethodoffersgreaterflexibilityinapplyingjustasinglelineoffilteringandnotlistingallIPprefixes,asinthecaseofdistributelistsorprefixlists.CommonlyseenproblemsaremostlytheresultofalackofunderstandingofUNIX-likeBGPregularexpressions.Chapter14sectionsonAS_PATHcoverthemostcommonlyusedregularexpressioninAS_PATHfilteringinCisco.

SummaryTroubleshootingBGPproblemsshouldbeaddressedbykeepingtheOSImodelinperspective.Forexample,ifaBGPneighborrelationshipishavingaproblem,physicalconnectivitytotheneighborshouldbeexaminedbeforelookingatTCPpacketscarryingBGPinformation.TheconfigurationtooperateBGPinCiscoIOSSoftwareisfairlystaticandsimple,butthedynamicsbehindthesesimpleconfigurationcommandsarefairlycomplex.Therefore,BGPstandardsasdescribedinRFCsmustbeunderstoodwellbeforeoperatingBGPinlargeIPnetworks.OperatorsofaBGPnetworkmustunderstandtheproperuseofCiscoIOSSoftwareconfigurationcommands.Anyminor

mistakecancauseseriousproblemsnotonlyinanoperator’sownnetwork,butalsotopeeringnetworksaswell.TheseproblemsevencancascadeintoaworldwideBGPproblem.Forexample,bogusstaticroutescanbecreatedfortestingpurposesinarouterthathasredistributestaticconfiguredinBGPconfigurationwithoutanyfilters.ThiswouldresultinaccidentallyannouncingthosebogusstaticroutestoallBGPpeers,whichwouldfurtherforwardthosebogusroutestotheirBGPpeers.ThiswouldresultinworldwideBGPannouncementoffakeroutesandmightwreakhavocinBGPnetworks.ThedynamicsbehindthestaticconfigurationmustbeunderstoodtotroubleshootproblemsinBGP.Commonly,BGPoperatorsfacechallengesinmanagingIPtrafficflowscominginandgoingoutoftheirIPnetworksrunningBGP.Toobtainoptimalutilizationofnetwork,BGPoperatorsmustunderstandhowtouseBGPtoinfluencetheirdesiredtrafficpatternsinthenetwork.Typically,tweakingBGPattributessuchasLOCAL_PREFERENCE,AS_PATH,MED,andORIGIN_CODEdoesthis.Therefore,BGPnetworkoperatorsmustmastertheseattributes.ProblemsmightresultfromtheconfigurationofBGPattributesorhowBGPusestheseattributestocomputetheBGPbestpathfrommanypathstoforwardIPtraffic.Ifproperpreferenceofeachattributeisnotunderstoodcorrectly,BGPoperatorsmightneverinfluencetrafficintheirnetworkcorrectly.Allsortsofproblemscomeindifferentprotocolsforavarietyofreasons,butaclearandlogicalapproachshouldbetakentoaddressthoseproblems.Thisrequiressolidunderstandingoftheprotocolsandanawarenessofbest-practicetroubleshootingtechniques.ThisbooktriestoofferfundamentalsofeachIPprotocolandtoprovideenhancedtroubleshootingtechniquesasseeninreal-worldIPnetworks.

Appendix.AnswerstoReviewQuestions

ThisappendixprovidesanswerstothereviewquestionsthatappearattheendofChapter1andtheeven-numberedchaptersthatcoverthekeyaspectsofRIP,IGRP,EIGRP,OSPF,IS-IS,PIM,andBGP.

Chapter11Whatisconnectionlessdatanetworking?Connectionlessnetworkingreferstotransferringdatainindependentunitsreferredtoaspackets,withouttheneedtopredefinethepathofdataflow.Instead,thepacketsareforwardedusingahop-by-hoproutingparadigmbetweenthesourceanddestination.

2Whyisroutingneededinaconnectionlessnetworkingenvironment?Listtwomeansbywhichroutersobtaininformationforroutingpacketstowardtheirdestinations.Thepacketsusedinconnectionlesstransferofdatahaveaddressinginformationfortheirintendeddestinationinpacketheaders.Routingisneededtoprovideinformationforforwardingpacketsalongoptimalpathstotheirtargetdestinations.VariousmechanismsexistforforwardingpacketsonCiscorouters.However,forwardingdecisionsultimatelyarebasedoninformationintheroutingtable,whichispopulatedmanuallywithstaticroutesordynamicallybyroutingprotocols.

3WhatisthedifferencebetweenfunctionalitiesofInteriorGatewayProtocols(IGPs)versusExteriorGatewayProtocols(EGPs)?IGPsexchangeroutesbetweenroutersbelongingtoasinglenetworkdomain.EGPssupportroutingbetweendomains.

4ListthetwomaingroupsofIProutingprotocolsbasedonthemethodofoperationandroutingalgorithm.Also,listtwoexamplesofeachtype.Distancevectorandlink-stateprotocols.RIPandCiscoIGRParedistancevector-based;OSPFandIntegratedIS-ISarelink-stateprotocols.EIGRPfallsunderyetathirdgroup,calledadvancedistancevectorprotocols.

5Brieflydescribetheoperationoflink-stateroutingprotocols.Link-stateroutingprotocolsshareandcollectnetworktopologyinformationbymeansoflink-stateadvertisements.Link-stateinformationisstoredinadatabase,whichisfedasinputtotheshortestpathalgorithmfordeterminingthebestroutes.

6Whatisthekeydifferencebetweenclasslessandclassfulroutingprotocols?Giveanexampleofeach.Classfulprotocolsoperateunderthenotionoftherigidboundariesofclassfuladdressing,whereasclasslessprotocolsaremoreflexibleinthis,regardingallowingthemtosupportVLSMsandCIDR.RIPisanexampleofaclassfulroutingprotocol.OSPFisanexampleofaclasslessprotocol.

7WhatistheuseofroutingprotocoladministrativedistancesonCiscorouters?Theconceptofadministrativedistanceisusedtodistinguishbetweenroutingsourcesandassignrelativepreferencesbetweenthem.

8WhatarethevaluesofadministrativedistanceofIS-ISandOSPF,respectively?

TheadministrativedistanceofIS-ISis115;theadministrativedistanceofOSPFis110.

9IfarouterisrunningbothOSPFandIS-ISprotocolsandhasthesameroutefromeachofthem,whichprotocol’sinformationwillbeusedintheIProutingtable?Theloweradministrativedistanceispreferred,soonlytheOSPFroutewillmakeitintotheIProutingtable.

Chapter21WhatisthemaximummetricinRIP?Themaximummetricis15becauseRIPwasdesignedforsmallnetworks.

2Whydoesn’tRIPsupportdiscontiguousnetworks?RIPisaclassfulprotocol,soitsummarizestheupdateatthemajornetworkboundary.

3Whydoesn’tRIPsupportVLSM?WhenRIPsendstheupdate,itcheckstoseewhetherthenetworkbeingadvertisedhasthesamemask.Iftheadvertisednetworkhasadifferentmask,RIPdoesn’tadvertisethatnetwork.

4WhatisthedefaultupdateintervalforRIP?Theentireroutingtableisupdatedevery30seconds.

5WhattransportprotocolandportnumberdoRIPuseforsendingupdates?RIPusesUDPport520totransportitsupdatepackets.

6Whatisthepurposeofthesplit-horizontechnique?SplithorizonisusedinRIPtoavoidroutingloops.

7DoesRIPVersion2solvethediscontiguousnetworkproblembydefault?No,thecommandnoauto-summaryisneededunderrouterrip.

8DoesRIPVersion2alsousebroadcastforsendingupdates?No,RIPVersion2usesamulticastaddressof224.0.0.9tosenditsroutingupdates.

9DoesRIPsupportauthentication?RIPVersion1doesnotsupportauthentication,butRIPVersion2doessupportit.

Chapter41WhatisthedefaultupdatetimerperiodforIGRP?Thedefaultupdatetimerperiodis90seconds.

2WhatvariablesdoesIGRPusetocalculateitsmetricsbydefault?Bydefault,IGRPconsidersonlythebandwidthandthedelayofthelinkwhencalculatingitsmetrics.

3WhataretheKvaluesintheIGRPmetricequation?TheK1throughK5variablesareconstantnumbersusedintheIGRPmetricequation.ThedefaultvalueoftheKvaluesareK1=K3=1,K2=K4=K5=0.ThenetworkadministratorcanchangethedefaultKvaluetoothernumberssothatothercomponentsofthemetricequation,

suchasloadandreliability,canbeused;however,suchachangeishighlynotrecommended.

4WhatcommandisusedinIGRPtoperformunequal-costloadbalancing?IGRPusesthevariancecommandtoperformunequal-costloadbalancing.

5Whatissplithorizon?DoesIGRPsupportthisfeature?Splithorizon,supportedbyIGRP,isthetechniqueusedtoavoidroutingloops.Withsplithorizon,therouterdoesnotadvertisearouteovertheinterfaceinwhichtherouteislearnedfrom.

6DoesIGRPsupportVLSM?BecauseIGRPdoesnotsendsubnetmaskinformationaspartoftheroutingupdate,IGRPdoesnotsupportVLSM.

Chapter61WhatisthedifferencebetweenmetriccalculationsinIGRPversusEIGRP?TheEIGRPmetricistheIGRPmetricmultipliedby256.

2WhatisanEIGRPquery,andwhatisitusedfor?AnEIGRPqueryissentwhenthesuccessorisgoneandthefeasiblesuccessorisnotavailable.AnEIGRPqueryisusedsothatEIGRPcanhavefastconvergence.

3Whatisthemeaningofthetermactiveroute?Activeroutesareroutesinwhichtheprimarypathisgoneandnofeasiblesuccessorsareavailable.Therouterisactivelysearchingforanalternatepath.

4Whatisafeasiblesuccessor?AfeasiblesuccessorisanEIGRPneighborthatdoesnotsatisfythefeasiblecondition.FeasiblesuccessorscanalsobethoughtofasEIGRPbackuproutesthatareusedwhentheprimaryrouteisgone.

5WhatisEIGRP’smulticastaddress?EIGRP’smulticastaddressis224.0.0.10.

6Whatisthefeasiblecondition?Thefeasibleconditionisaconditioninwhichthereporteddistanceislessthanthefeasibledistances.Thisconditionensuresaloop-freetopology.

7Whatisstuckinactive?Stuckinactiveisaconditioninwhichtherouterhassentoutqueriesforalostrouteandhasnotreceivedareplywithintheactivetimer.Bydefault,theactivetimeristhreeminutes.

Chapter81HowmanytypesofpacketarethereinOSPF?OSPFhasfivetypesofpackets.

2WhichoftheLSAshaveafieldcalledForwardingAddress?ExternalLSAshaveaForwardingAddressfield.

3WhichoftheLSAsarenotallowedinatotallystubbyarea?ExternalandsummaryLSAsarenotallowedinatotallystubbyarea.

4WhatisthemulticastaddressforAllSPFRouters?224.0.0.5isthemulticastaddress.

5WhichoftheOSPFprotocolpacketsareusedtoelectamasterandaslave?Type2DBDpacketsareusedtoelectamasterandaslave.

6WhichoftheOSPFprotocolpacketsimplementfloodingoftheLSA?Link-stateupdatepacketsimplementfloodingoftheLSA.

7WhatisthetimelimitinsecondsbeforeanLSAisdeclaredasMAXAGED?Thelimitis3600seconds.

8HowmanybyteslongisacommonLSAheader?AcommonLSAheaderis20byteslong.

Chapter101NamethethreenetworklayerprotocolsthatformthebasisofISOconnectionlessnetworkservices.CLNP,ES-IS,andIS-IS.

2HowmanylevelsarethereintheroutinghierarchysupportedbytheIS-ISroutingprotocol?ISO10589specifiestwolevels:Level1andLevel2.

3WhatisthegenerallayoutoftheIS-ISpacketformat?AllIS-ISpacketsconsistofaheadertowhichspecialroutinginformationfields,knownasTLVs,areappended.

4WhatdoestheacronymNSAPstandfor,andwhatisitusedfor?NSAPstandsfornetworkserviceaccesspoint.NSAPsarenetworklayeraddressOSInodesrunningtheCLNPprotocol.

5WhatarethethreemajorcomponentsofanNSAP?Describethesignificanceofeach.ThethreecomponentsareareaID,systemID,andN-selector.TheareaIDdefinestheareathatthenodebelongsto,thesystemIDisauniqueaddressofthenodewithinitsarea,andtheN-selectorspecifiesanetworkserviceuser.A0valuespecifiestheroutinglayer.

6WhatisthemaximumlengthofanNSAP,andwhatistheminimumlengththatcanbeconfiguredonaCiscorouter?ThemaximumlengthofanNSAPis160bits,or20bytes.TheminimumsizethatcanbeconfiguredonaCiscorouteris8bytes.The8bytesinclude1byteofN-selector,6bytesofsystemID,and1byteofareaID.

7WhatisthesignificanceoftheIS-ISlink-statedatabase?Link-stateprotocolssuchasIS-ISrequireeachrouterinanareatohavethesameviewofthearea’stopology.Eachroutercreatesalink-statepacketthatdescribesitsimmediateenvironmentsharedwithotherroutersinthearea.LSPsarecollectedinthelink-statedatabase.

Whenpiecedtogether,theLSPsinanarea’slink-statedatabasedescribethetopologyoftheentirearea.

8WhatisthebasicdifferencebetweenLevel1andLevel2link-statedatabases?ALevel1link-statedatabasedescribesasingleIS-ISareaandcontainsonlyLSPsfromtheroutersinthatarea.TheLevel2databasedescribestheinterconnectionbetweenareasintheIS-ISdomainandcontainsLSPsfromtheLevel2routers.TheLevel2LSPsareintendedtoprovideinterareainformation.

9Howarefloodinganddatabasesynchronizationdifferentbetweenapoint-to-pointlinkandabroadcastlink?LSPsarefloodedreliablywithacknowledgmentsonpoint-to-pointlinks,whereastheyarenotacknowledgedonbroadcastlinks.Databasesynchronizationoccursonbroadcastmediathroughthedesignatedrouter,whichsendsperiodicCSNPsoverthelinktoassistwithsynchronization.

10DescribethetwostepsforenablingbasicIS-ISroutingonaCiscorouter.First,anIS-ISroutingprocessisconfiguredwiththerouterisis[tag]command.Then,IS-ISroutingisenabledontherelevantinterfaceswiththeiprouterisis[tag]interface-levelcommand.

11ListsomeshowcommandsthatyoucanusetoverifyconfigurationandoperationofIS-IS.showclnsneighbors,showclnsinterface,showisistopology,andshowis-isdatabase.

Chapter121Whatisthedifferencebetweenunicast,broadcast,andmulticast?Unicastpacketsaredestinedforonlyonehost.Broadcastpacketsaredestinedforallhostsonthesamesegment,regardlessofwhetherthehostisinterestedinthepacket.Multicastpacketsaresentwithonecopy,andonlyhoststhatareinterestedinthemulticastpacketprocessthepacket.

2WhatarethedifferentmodesofPIM?PIMdensemodeandPIMsparsemodearethetwomodes.

3WhatmechanismdoesPIMdensemodeoperateon?PIMdensemodeoperatesontheflood-and-prunemechanism.Therouterfirstfloodsthemulticastpacketsonallinterfaces,andtheneighborsthatdon’twantthemulticastpacketprunetheinterface.

4WhatmechanismdoesPIMsparsemodeoperateon?PIMsparsemodeoperatesontheprune-and-joinmechanism.Therouterwon’tforwardthemulticastpacketuntilitreceivesaPIMjoinontheinterface.

5WhatisthedifferencebetweenIGMPversion1andversion2concerningthegroupleavemechanism?IGMPversion1doesn’thaveaspecificgroupleavemechanism.IGMPversion1groupmemberssimplyleavethegroupsilently.IGMPversion2hasaspecificgroupleavemechanisminwhichthehostsendsaspecificIGMPleavemessagetotherouterindicatingthatit’sleavingthemulticastgroup.

6WhatmulticastaddressdoesIGMPuseforIGMPqueries?224.0.0.1isused.

7HowdoesRPFcheckwork?Whenarouterreceivesamulticastpacketonaninterface,itchecksitsroutingtableonthesourceaddressofthemulticastpacket.Iftheroutingtablecorrespondswiththeinterfacefromwhichthemulticastpacketsarereceived,RPFchecksucceedsandpacketsareforwarded;otherwise,multicastpacketsaresilentlydiscarded.

8Whatistherendezvouspoint(RP)?Therendezvouspoint(RP)iswherethemulticastsenderandreceivermeetfirstbeforetheshortest-pathtreeisestablished.

Chapter141DoesBGPhaveitsowntransportmechanismtoensuretheguaranteeofBGPupdates?A.BGPhasitsowntransportmechanismtodeliverBGPpacketstoitsneighbors.B.UDPisapreferredmethodbecauseBGPneighborsareinmostcasesdirectlyconnectedandthelossofpacketsisunlikely.

C.BGPusesTCPasitstransportmechanism.Answer:C.BGPusesTCPasitstransportmechanism.

2AssumingnoRoute-ReflectionorConfederationsareused,whatproblemsmightoccurifIBGPneighborsarenotfullymeshed?A.AnIBGPupdatewillnotbepropagatedtoBGProutersintheASbecausetheIBGPlearnedupdateisnotannouncedtootherIBGPneighbors.

B.Everythingwillrunfine.C.OnlyexternalBGPneighborswon’treceivetheBGPupdates.Answer:A.AnIBGPupdatewillnotbepropagatedtoBGProutersintheASbecausetheIBGPlearnedupdateisnotannouncedtootherIBGPneighbors.

3WhatBGPtechniqueisusedtopenalizeflappingofBGProutesinsomeotherAS?A.Route-ReflectionB.DampeningC.PeergroupsAnswer:B.Dampening.

4TheBGPprocesscanexchangeupdateswithitsneighborsafterpassingwhichneighborstate?A.EstablishedB.OpenSentC.ActiveAnswer:A.Established.

5WhichofthefollowingtechniquesareusedinsolvingtheIBGPfullmeshrequirement?A.Dampening

B.AggregationC.RouteReflectionandConfederationAnswer:C.RouteReflectionandConfederation.

Index

Symbols%OSPF-4-BADLSATYPEerrormessages,529

Numerics128-bitaddressingscheme,IPv6,52-waystate,OSPFneighbors,336gettingstuck,398–400

32-bitaddressingscheme,IPv4,5classes,5–7privateaddressspace,7–8subnetting,8

AABRs(areaborderrouters),generatingdefaultsummaryroutes,326–327accesslistsdistributelistsIGRPuninstalledroutes,149–150unadvertisedIGRProutes,173–174

filteringBGPtrafficunfilteredmaskedroutes,831–835unfilteredsubnets,828–830

inboundinterfaces,blockedRIPbroadcast,63–65sourceaddress.blockedRIProuteinstallation,60–63unintentionalTCPpacketblockages,741–742

Acknowledgmentfield(EIGRPpackets),216activeroutes(EIGRP),213Activestate(BGP-4),663AD(administrativedistance),24,661AddressResolutionProtocol(ARP),5addressesCLNP,548NSAPs,536defining,551format,549–551

addressing,4classless,7CLNPNSAPs,536,548defining,551format,549–551

hop-by-hopdestination-basedforwarding,4IPv4CIDR,10classes,5–7privateaddressspace,7–8subnet,8

mediaindependence,5adjacencies,334–3352-waystate,336Attemptstate,336Downstate,335ES-IS,538,589formationinIS-ISnetwork,605

Exchangestate,337Exstartstate,336Fullstate,338Initstate,336IS-IS,537–540,587–589absenceof,590–596INITstate,596–605

Loadingstate,338OSPFoptionalcapabilitymismatches,370–372Stuckin2-WAYstate,398–400StuckinATTEMPT,383–386StuckinEXSTART/EXCHANGEstate,401–417StuckinINIT,387–398StuckinLOADINGstate,417–422

administrativedistance,24,661advanceddistancevectorroutingprotocolsEIGRPdialbackup,286–290errormessages,291mismatchedASnumbers,239mismatchedKvalues,237mismatchedmasks,235–237neighborrelationships,227–232redistribution,280–286routeadvertisement,250–256routeflapping,271–275routeinstallation,264–270routesummarization,276–280

SIAerrors,240–250uncommonsubnets,233–235unexpectedmetrics,259–263unexpectedrouteadvertisement,257–259

advertisingBGP-4routes,668–670synchronizationrule,671–672

IGRProutesbroadcastcapability,178–180distributelists,173–174misconfiguredneighborstatement,180–181misconfigurednetworkstatement,169–171networkinterface,175–176outgoinginterface,171–172passiveoutgoinginterface,176–178splithorizon,184,187–188troubleshooting,169VLSM,182–184

RIProutes,86blockedroutes,91–93brokenmulticastcapability,96–98downnetworkinterface,93–94downoutgoinginterface,89–91misconfiguredneighborstatement,99–100missingnetworkstatement,87–89passiveoutgoinginterface,95–96splithorizon,troubleshooting,102,105–106VLSMroutes,troubleshooting,100–102

AdvertisingRouterfieldOSPFlink-staterequestpackets,300LSAs,303

AFI(addressfamilyidentifier),42aggregate-addresscommand,configuringBGProuteorigination,747–749Area0,315AreaIDfield(OSPFpackets),297areas,315–318IS-IS,536–537hiearchicalrouting,541

normal,319NSSAs,321–324configuring,322–324defaultroutes,326–327

filteringType7LSAs,326injectingexternalroutes,325–326totallyNSSAs,324–326

stub,319–320totallystubby,321

ARP(AddressResolutionProtocol),5AS(autonomoussystem),659confederations,designing,758–761inboundtrafficflows,812underutilizedlinks,813–818

outboundIPtrafficflows,790asymmetricalrouting,802–806dual-homedconnections,798–802reachability,795–798singleexitpoint,791–795

ASconfederations,711–712AS_PATHattributefiltering,835policycontrol,682,684–685

AS_SEQUENCEattribute,685AS_SETattribute,685ASBR(autonomoussystemboundaryrouter),660assertmechanism,640PIMdensemode,631–632

assigningdefaultIGRPmetricforredistribution,191–194asymmetricalrouting,802–806AttachedBitfield(LSPs),554AttachedRouterfield(NetworkLSAs),307ATTEMPTstate,OSPFneighbors,336gettingstuck,383–386

attributes(BGP)AS_PATHfiltering,835policycontrol,682–685

COMMUNITIES,policycontrol,697–699interpretingfromcommandoutput,688–690LOCAL_PREFpolicycontrol,675–676MEDinfinitesetting,777policycontrol,677–682

NEXT_HOP,policycontrol,685ORIGIN,policycontrol,685

authenticationIS-IS,548keys,69nullauthentication,364RIP,42

Authenticationfield(OSPFpackets),297auto-costreference-bandwidthcommand,305AutonomousSystemNumberfield,EIGRPpackets,216autosummarizationEIGRP,219–220IProutesintoLevel1/Level2,573–574missingRIPsubnettedroutes,106–109RIP,43

AuTypefield(OSPFpackets),297avoidingroutingloops,splithorizon,130

BbackboneindicationLSAs,332–333IS-ISnetworks,537virtuallinks,316–318

BackupDesignatedRouterfield,OSPFHellopackets,299backupinterfacecommand,194backuplinks,dialup,194–198BadLSAtypeerrormessages,529bandwidth,calculatingIGRPmetric,128–129behavior,IGRP,131best-pathcalculation,661,668BGP,820–827BGP-4,713–716IS-ISSPFalgorithm,558

BGP-4(BorderGatewayProtocol),659AD,661advertisingroutes,668–670ASconfederations,711–712AS-PATH,filtering,835attributes,interpretingfromcommandoutput,688–690best-pathcalculation,661,713–716,820selectionoflowestMEDvalue,824–827selectionofwrongpath,821–823

coldpotato,661confederations,designing,758–761

EBGPmultihop,misconfiguration,736–740Establishedstate,663extendedaccesslists,unfilteredmaskedroutes,831–835externalneighborrelationshipsincorrectIPaddressassignment,731–732IPconnectivity,728Layer2problems,729–731nondirectlyconnected,732–733

hotpotato,661inboundtrafficflows,812underutilizedlinks,813–818

internalneighborrelationships,routepropagation,754–762loadbalancing,dual-homedoutboundtraffic,806–812neighborrelationships,663–664,659advertisedroutes,726external,665–667internal,667statistics,displaying,726

nondirectlyconnectedexternalneighborrelationships.missingroutingtableaddresses,733–736peers,659–660policies,661policycontrol,672–674AS_PATHattribute,682–685communities,697–699distributelists,695–696filterlists,695LOCAL_PREFattribute,675–676MEDattribute,677–682NEXT_HOPattribute,685ORF,700–702ORIGINattribute,685prefixlists,696routemaps,690–694WEIGHTknob,686–688

policyrouting,outboundIPtrafficflows,790–806privatepeering,660protocolspecifications,662publicpeering,660RFC1771,662routedampening,702–706routeoriginationclassfulnetworkadvertisements,749–751

misconfiguration,746–749misconfigureddistributelists,752–754missingroutingtableentries,743–746

routereflection,707–711,778client-to-clientreflection,780–782identicalclusterIDs,785,788–790misconfiguration,779–780peergroups,783–785

routingtableuninstalledEBGP-learnedroutes,771–777uninstalledIBGP-learnedroutes,763–771

standardaccesslists,unfilteredsubnets,828–830synchronizationrule,671–672synchronization,disabling,766

BGPfeed,659BitBfield(routerLSAs),305BitEfield(externalLSAs),313BitEfield(routerLSAs),304BitVfield(routerLSAs),304blackholes,671–672boundaries,EIGRPqueries,220broadcastaddresses,12broadcastcapability,unadvertisedIGRProutes,178–180broadcastlinks,IS-IS,536broadcastmode(NBMA),329–330

CcalculatingbestpathsBGP-4,713–716IS-ISSPFalgorithm,558

EIGRPmetrics,208–209IGRPmetric,127bandwidthvariable,128–129delayvariable,128–129

casestudy,IS-ISconfiguration,619–622causesofuninstalledRIProutesaccesslistsblockingRIPbroadcast,63–65accesslistsblockingsourceaddress,60–63discontiguousnetworks,71–74distributelistincomingroutes,58–60equalcostpaths,83–86

hopcountexceeded,81–83incompatibleRIPversion,65–68incorrectnetworkstatement,53–56invalidsource,74–76Layer1/2down,56–58Layer2problems,76–78mismatchedauthenticationkey,68–71offsetvaluetoohigh,79–81

characteristicsnormalareas,319NSSAs,322stubareas,320totallystubbyareas,321

ChecksumfieldEIGRPpackets,216IGMPpackets,636LSPs,554OSPFpackets,297

checksumoperation,LSAs,303CIDR(ClasslessInterdomainRouting),7,10classesofIPaddresses,5–7classfulnetworksmasks,8redistributionintoBGP,749–751subnetting,8

classfulroutingprotocols,29versusclassless,15

classlessaddressing,7CIDR,10

classlessroutingprotocolsversusclassful,15clearisiscommand,587clients,routereflection,757client-to-clientreflection,780–782CLNP(ConnectionlessNetworkProtocol),534,586addressing,548IS-IS,586NSAPs,format,549–551NSAPs,defining,551

CLNS(connectionlessnetworkservices),533clustersidenticalclusterIDsbetweenRR,785,788–790routereflectorclient/servers,designing,757–758

coldpotatorouting,661,682commandsaggregate-address,configuringBGProuteorigination,747–749auto-costreference-bandwidth,305backupinterface,194clearisis,587debugipbgpupdate,727debugipbgpupdates,727debugiprip,35,55ipdefault-network,132,221ipsummary-addresseigrp,219matchas_path,implementinginroutemaps,692–693matchcommunity,implementinginroutemaps,692matchipaddress,implementinginroutemaps,691output,interpretingBGPattributes,688,690pingclns,617–619setas-pathprepend,implementinginroutemaps,693setcommunity,implementinginroutemaps,693setlocalpreference,implementinginroutemaps,694setmetriccommand,implementinginroutemaps,694showclnsinterface,564,586showclnsneighbors,586showclnsneighborsdetail,563fielddefinitions,588

showclnsprotocol,562–563showipbgp,726showipbgpneighbor,726showipbgpneighbors,726–727showipbgpsummary,726showipeigrpneighbor,210showipeigrptopologyactive,242–245showipprotocols,56showiproute,12,56,134,142showisisdatabase,586showisistopology,565,586timersbasic,130traceroute,617–619variance,133–134,221–223

communities,BGP-4policycontrol,697–699comparingclasslessandclassfulroutingprotocols,15interiorandexteriorgatewayprotocols,15,17–18

IPv4andIPv6,5link-stateanddistancevectorprotocols,18TCP/IPandOSIreferencemodel,3Type7andType5LSAs,322

confederations(BGP),designing,758–761configuringEIGRPmanualsummarization,219IS-ISATMconnectivity,566–568autosummarization,573–574casestudy,619–622defaultrouteadvertisement,569IProuting,560,566–573redistribution,570–573routingonpoint-to-pointlinks,559–566

NSSAareas,322–324virtuallinks,316–318

Connectstate(BGP-4),663connectivityexternalBGPneighborrelationships,728IS-ISadjacencies,587–605pingclnscommand,617–619traceroutecommand,617–619

constantSPFcalculationsinOSPFnetworks,troubleshooting,518–528convergence,129BGPnetworks,peergroups,783–785diffusedcomputation,213distancevectorprotocols,19–20EIGRP,207queryprocess,220

localcomputation,213costIS-ISdefaultmetric,546OSPFmetriccalculation,overriding,305

“couldnotallocaterouteid”errormessages,529counttoinfinity,29distancevectorprotocols,21

CPUutilization,displayingIS-ISstatistics,613–615CPUHOGmessages,OSPF,499–503CSNPIntervaltimer,IS-ISlink-statedatabase,557CSNPs(completesequencenumberpackets),556

Ddampeningroutes,modifyingparameters,771–774data-forwardprocess,addressing,4datagramdeliveryservicemodel,3DBD(DatabaseDescription)packets,OSPF,299SequenceNumberfield,300

DCbit,332DDR(dial-on-demandrouting)IGRP,194dialbackup,194–198

OSPF,503–516RIP,116–122

debugipbgpupdatecommand,727debugipbgpupdatescommand,727debugipripcommand,35,55debuggingSPFproblems(IS-IS),615–616decisionprocess,IS-ISSPFalgorithm,558defaultroutesEIGRP,221IGRP,132–133unadvertisedcandidates,188–191

OSPFunadvertised,450–462NSSAs,326–327

RIP,39–40unadvertised,450–462

definingmetricforIGRPredistribution,191–194NSAPs,551

delay,calculatingIGRPmetric,128–129delaymetric,IS-IS,546demandcircuits(OSPF),331–334densemode(PIM),625,630–631assertmechanism,631–632prunemechanism,631troubleshooting,646–651

DesignatedRouterfield(OSPFHellopackets),299designingBGPconfederations,758–761routereflectormodel,757–758

devicesinterfaces,link-basedaddressing,5

Layer2media,troubleshootinguninstalledIGRProutes,161–163dialbackupEIGRP,286–290IGRP,194–198

diffusedcomputation,213Dijkstraalgorithm,295directinspectionofLSPs,606–607directedbroadcasts,12directlyconnectedexternalBGPneighbors,IPconnectivity,728–729DIS(designatedintermediatesystem),539disablingBGPsynchronization,766discontiguousnetworksEIGRP,252–253routingbehavior,218–219

RIP,36–37troubleshootingrouteinstallation,71–74

uninstalledIGRProutes,155–158displayingBGPneighborstatistics,726IS-ISCPUutilizationstatistics,613–615IS-ISlink-statedatabase,565IS-IStopology,565prefixes,assignedattributes,726

distancevectorprotocolsconvergence,19–20countingtoinfinity,21holddown,21IGRP,133–134behavior,131defaultroutes,132–133definingmetricforredistribution,191–194dialbackuplinks,194–198flappingroutes,198–201metrics,127–129packets,131splithorizon,130splithorizonwithpoisonreverse,130timers,129–130unadvertiseddefaultroutecandidates,troubleshooting,188–191uninstalledequal-costpaths,troubleshooting,166–168uninstalledroutes,troubleshooting,142–188variance,201–204

loopavoidance,20–21metrics,19periodicupdates,22poisonreverse,22RIPauthentication,42compatibilityissues,43DDR,116,118–122defaultroutes,39–40discontiguousnetworks,36–37flappingroutes,122–124multicast,42NextHopfields,41packetbehavior,31receivingupdates,33–35redistribution,113–116routeadvertisements,86–106

passiveoutgoinginterface,96routetagfield,40–41routeinstallation,52–85sendingupdates,31–33splithorizon,30

withpoisonreverse,31subnetmasks,41summarization,109–113timers,30uninstalledroutes,52versionfield,43VLSM,37–39

splithorizon,22triggeredupdates,22versuslink-state,18

distributelists,58BGP-4misconfiguration,752–754policycontrol,695–696

blockedroutes,troubleshooting,91–93IGRPuninstalledroutes,149–150incomingroutes,blockedRIProuteinstallation,58–60misconfiguration,251–252unadvertisedIGRProutes,troubleshooting,173–174

dotted-decimalnotation,IPaddressrepresentation,7

Downstate,OSPFneighbors,335Doyle,Jeff,214droppedpackets,IGRP,199–201DRs(designatedrouters),networkLSAs,307–308DUAL(DiffusingUpdateAlgorithm),207,211,240–241activeroutes,213FC,211FD,211FSM,213–214feasiblesuccessors,212passiveroutes,213RD,211successors,211

dualaddressingscheme,IS-IS,586dualhomingloadbalancing,806–812outboundBGPtrafficflows,798–802

duplicaterouterIDs,EIGRP,268–270dynamicrouting,4,11classlessversusclassful,15interiorversusexteriorgateway,15–18link-stateversusdistancevectorprotocols,18multicastversusunicast,12–14versusstaticrouting,11

EEBGP(ExternalBGP),660multihopmisconfiguration,736–740resolvingnondirectlyconnectedneighborrelationships,732unreachablenexthop,774–777

underutilizedlinksbetweentwoASes,813–818uninstalledroutes,771dampenedBGProutes,771–774infiniteMEDvalue,777

EGP(exteriorgatewayprotocol),659EIGRP(EnhancedInteriorGatewayRoutingProtocol),17,207convergence,207diffusedcomputation,213localcomputation,213

defaultroutes,221dialbackup,286–290

DUAL,207,211,240–241activeroutes,213FC,211FD,211feasiblesuccessors,212passiveroutes,213RD,211successors,211

errormessages,291holdtime,209metrics,208–209neighborrelationships,209–210,227log,reviewing,228–229mismatchedASnumbers,239mismatchedkvalues,237mismatchedmasks,235–237one-way,230–232SIAerrors,240–250uncommonsubnets,233–235

packets,TLV,216–217redistribution,280–286reliablepackets,214routeadvertisement,250discontiguousnetworks,252–253misconfigureddistributelists,251–252split-horizon,253–256unexpectedadvertisements,257–259unexpectedmetrics,259–263

routeflapping,271–275routeinstallation,264–270routesummarization,276–280routingbehavior,218–219RTP,214summarization,219–220unequal-costloadbalancing,221–223

emptyneighborlists,OSPF,351–383emptyroutingtables(IGRP),troubleshooting,142–166EnhancedInteriorGatewayRoutingProtocol.SeeEIGRPequal-costpaths,routeinstallationIGRP,166–168RIP,83–86

errormessages,EIGRP,291

errormetric,IS-IS,546ES-IS(EndSystem-to-IntermediateSystem),589adjacencies,538misidentificationinIS-ISnetworks,605

Establishedstate(BGP-4),663–664routeadvertisements,668–670synchronizationrule,671–672

establishingIGRPdialbackup,194–198Exchangestate,OSPFneighbors,337gettingstuck,401–417

expensemetric,IS-IS,546Exstartstate,OSPFneighbors,336gettingstuck,401–417

extendedaccesslistsBGPfiltering,unfilteredmaskedroutes,831–835debugipbgpupdatecommandoutput,727uninstalledIGRProutes,troubleshooting,151–155

exteriorgatewayprotocols,versusinterior,15–18externalLSAs(Type5),302,313–315externalmetrics,IS-IS,547externalneighborrelationships,BGP-4,665–667incorrectIPaddressassignment,731–732IPconnectivity,728Layer2problems,729–731nondirectlyconnected,732–733misconfiguration,736–740missingroutingtableaddresses,733–736

externalroutesinjectingintoNSSAs,325–326OSPF,unadvertised,441–449redistributionintoIS-IS,570–573summarization,497–499uninstalled,479–487

FFC(feasiblecondition),211FD(feasibledistance),211feasiblesuccessorroutes,17,212fielddefinitionsEIGRPpackets,216–217externalLSAs,313IGMPpackets,635

IS-ISpackets,TLVs,543–545LSPheaders,553–555showclnsneighborscommandoutput,588OSPFHellopackets,298–299LSAheaders,303–304packets,296

summaryLSAs,310filterlists,BGP-4policycontrol,695filteringtrafficBGPtrafficAS_PATH,835unfilteredmaskedroutes,831–835unfilteredsubnets,828–830

extendedaccesslists,troubleshootinguninstalledIGRProutes,151–155Type7LSAs,326

Flagsfield(EIGRPpackets),216flappingroutesdampening,702–706EIGRP,271–275IGRP,198–201IS-IS,612–616RIP,122–124

flooding,552IS-IS,555–557

flushtimersIGRP,130RIP,30

formatofNSAPs,549–551ForwardingAddressfield(ExternalLSAs),313forwardingpacketshigh-speed,25multicast,12–14

fullfeed,659Fullstate,OSPFneighbors,338

Ggatewayoflastresort,IGRP,188generatingdefaultsummaryroutes,326–327genericformat,IS-ISpackets,543–545GroupAddressfield,IGMPpackets,636

H

headersLSAs,303–304LSPs,553–555OSPFpackets,296

HelloIntervalfield,OSPFHellopackets,298hellosIIHs,538–539OSPF,297–299

hierarchicalRoute-Reflection,709hierarchicalrouting,IS-IS,541holdtimeBGP-4,663EIGRP,209

holddown,distancevectorprotocols,21holddowntimersIGRP,130RIP,30

hopcount,29troubleshootingRIProuteinstallation,81–83

hop-by-hopdestination-basedforwardingmechanism,4hotpotato,661hybridroutingprotocols,EIGRP,207convergence,207defaultroutes,221DUAL,207,211–213IPInternalRouteTLV(EIGRP),216–217metrics,208–209neighborrelationships,209–210packetfields,216–217queryprocess,220routingbehavior,218–219RTP,214summarization,219–220unequal-costloadbalancing,221–223

IIBitfield(OSPFDBDpackets),299IBGP(InternalBGP),660ASconfederations,711–712blackholes,671–672neighborrelationshipsclient-to-clientreflection,780–782

misconfiguration,779–780routereflection,707–711uninstalledroutes,763–766unreachablenext-hops,766–771

identicalclusterIDsinRRsession,troubleshooting,785,788–790identifyingroutersattachedtotransitlinks,308Idlestate(BGP-4),663IETFstandardizationofIS-IS,535IGMP(InternetGroupManagementProtocol)version1,626version2,627joins,643–645leavemechanism,627–628packets,635querierelectionmechanism,627

IGRP(InteriorGatewayRoutingProtocol)behavior,131DDR,194dialbackuplinks,194–198

defaultroutes,132–133intermediatemediaproblems,142loadbalancing,168metrics,127–129packets,131redistributionintoNSSAarea,321metric,defining,191–194

routeflapping,198–201routeinstallation,142–166splithorizon,130splithorizonwithpoisonreverse,130timers,129–130unadvertiseddefaultroutecandidates,188–191unequal-costloadbalancing,133–134uninstalledequal-costpaths,166–168uninstalledroutes,senderproblems,142,168–188variance,201–204

IIHs(intermediatesystem-to-intermediatesystemhellos),538–539improvingBGPnetworkconvergence,783–785inboundBGPtrafficflows,812underutilizedlinks,813–818

incompatibleRIPversions,troubleshootingRIProuteinstallation,65–68

incorrectnetworkstatements,RIProuteinstallation,53–56indicationLSAs,332–333INITstate,336gettingstuck,382,387–398IS-ISadjacencies,596–605

injectingexternalroutesintoNSSAs,325–326installingRIProutes,52accesslistsblockedRIPbroadcast,63–65blockedsourceaddresses,60–63

discontiguousnetworks,71–74distributelists,blockedRIProutes,58–60equal-costpaths,83–86hopcountexceeded,81–83incompatibleRIPversion,65–68incorrectnetworkstatements,53–56invalidsources,74–76Layer2problems,76–78lineprotocols,downstate,56–58mismatchedauthenticationkey,68–71offsetlistvaluetoohigh,79–81

IntegratedIS-IS.SeeIS-ISinterarearoutes,summarization,495–496interestingtraffic,117InterfaceMTUfield,OSPFDBDpackets,299interfaceslink-basedaddressing,5oilist,630–631

InteriorGatewayProtocolsEIGRP,17versusexterior,15–18

intermediatemediaproblems,142internalmetrics,IS-IS,547internalneighborrelationshipsBGP-4,667routepropagation,754–761synchronization,761–762

unintentionalTCPpacketblockages,741–742interpretingBGPattributesfromcommandoutput,688–690Invalidlsaerrormessages,529invalidsources,troubleshootinguninstalledroutesIGRP,159–161

RIP,74–76invalidtimersIGRP,129RIP,30

IPaddressingbroadcastaddresses,12CIDR,10dynamicrouting,11classlessversusclassfulroutingprotocols,15interiorversusexteriorgateway,15–18link-stateversusdistancevectorprotocols,18–24unicastversusmulticastrouting,12–14

subnets,12ipdefault-networkcommand,132,221IPInternalRouteTLV(EIGRP),216–217IPnetworknumbers,6IPprefix,659IProuting,IS-ISconfiguration,560,566–573ATMconnectivity,566–568autosummarization,573–574defaultrouteadvertisement,569point-to-pointlinks,559–566redistribution,570–573

ipsummary-addresseigrpcommand,219IPv4addressclasses,5–7privateaddressspace,7–8subnetting,8versusIPv6,5

ISTypefield(LSPs),555IS-IS(IntermediateSystem-to-IntermediateSystem),533–535adjacencies,538–540,587–589absenceof,590–596INITstate,596–605misidentifiedES-ISadjacencies,605three-wayreliable,540

areas,536–537authentication,548backbone,537broadcastlinks,536CLNPaddressing,548,586NSAPformat,549–551

NSAPs,defining,551DIS,539errors,616–617externalroutes,redistributiontoLevel1,611flappingroutes,612–616flooding,552hierarchicalrouting,541IETFstandardization,535IProutingATMconfiguration,566–568autosummarization,573–574configuring,560,566–573defaultrouteadvertisement,569point-to-pointlinks,559–566redistribution,570–573

level1,535links,536–537link-statedatabase,552–555displaying,565flooding,555–557synchronization,555–557updatetimers,556–557

LSPs,headerfields,553–555metrics,545–548external,547internal,547

nodes,536–537NSAPs,536packets,542genericformat,543–545

PDUs,542pingclnscommand,617–619point-to-pointlinks,536PSN,539routeadvertisements,misconfiguration,607–611routingdomains,536routingupdates,606–607SNPs,556SPFalgorithm,558triggers,614–615

traceroutecommand,617–619updateprocess,555

ISOCLNS(InternationalOrganizationforStandardizationConnectionlessNetworkingServices)CLNP,534IS-IS,533–535adjacencies,537areas,536–537ATMconfiguration,566–568autosummarization,573–574backbone,537broadcastlinks,536CLNPaddressing,548–551defaultrouteadvertisement,569DIS,539ES-ISadjacencies,538flooding,552headerfields,553–555hierarchicalrouting,541IETFstandardization,535IProutingconfiguration,559–573IS-ISadjacencies,538–540Level1,535links,536–537link-statedatabase,552–557metrics,545–548nodes,536–537NSAPs,536packets,542–545point-to-pointlinks,536PSN,539redistribution,570–573routingdomains,536SPFalgorithm,558three-wayreliableadjacencies,540updateprocess,555

SNPs,556ISPs,BGP-4659advertisingroutes,668–672bestpathcalculation,713–716externalneighborrelationships,665–667internalneighborrelationships,667neighborrelationships,663–664policycontrol,672–688protocolspecifications,662

routedampening,702–706IXP(InternetExchangePoint),660

J-K-LjoinmechanismIGMPversion2,627–628,643–645PIMsparsemode,633

knobs,policycontrol,686–688Layer1(OSI),IGRPuninstalledroutes,147–149Layer2(OSI)connectivitybetweenexternalBGPneighbors,729–731IGRPuninstalledroutes,161–163RIProuteinstallation,76–78

layeredprotocolsuites,TCP/IP,3leavemechanism,IGMPversion2,627–628Lengthfield(LSAs),304Level1LANIIHs,539Level2LANIIHs,539lineprotocolsRIProuteinstallation,56–58uninstalledIGRProutes,troubleshooting,147–149

LinkDatafield(routerLSAs),305linkflaps,506LinkIDfield(routerLSAs),305link-basedaddressing,5linksIS-IS,536–537OSPF,305

link-stateacknowledgmentpackets(OSPF),301link-statedatabase(IS-IS),552–555displaying,565flooding,555–557synchronization,555–557updatetimers,556–557

Link-StateIDfieldLSAs,303OSPFlink-staterequestpackets,300

link-stateprotocols,23IS-IS,533,535adjacencies,537,587–605areas,536–537ATMconfiguration,566–568

authentication,548autosummarization,573–574backbone,537broadcastlinks,536CLNPaddressing,548–551,586configuring,casestudy,619–622confusionwithES-ISadjacencies,605defaultrouteadvertisement,569DIS,539displayingCPUutilizationstatistics,613–615errors,616–617ES-ISadjacencies,538externalroutes,redistributionintoLevel1,611flappingroutes,612–616flooding,552headerfields,553–555hierarchicalrouting,541IETFstandardization,535IProutingconfiguration,559–573IS-ISadjacencies,538–540Level1,535links,536–537link-statedatabase,552–557metrics,545–548nodes,536–537NSAPs,536packets,542–545pingclnscommand,617–619point-to-pointlinks,536PSN,539redistribution,570–573routeadvertisements,607–611routingdomains,536routingupdates,606–607SNPs,556SPFalgorithm,558SPFprocesstriggers,614–615three-wayreliableadjacencies,540traceroutecommand,617–619updateprocess,555

metrics,24OSPF,295

“%OSPF-4-BADLSATYPEerrormessages,529adjacencies,334–338areas,315–320constantSPFcalculations,troubleshooting,518–528“couldnotallocaterouteid”errormessages,529CPUHOGmessages,499–503DDR,503–516debugs,CPUutilization,341demandcircuits,331–334Dijkstraalgorithm,295emptyneighborlists,351–383externalLSAs,313–315LSAs,302–304multiaccessmedia,327–328NBMAmedia,329–331networkLSAs,307–308NSSAs,321–326nullauthentication,364“OSPF-4-ERRRCV”errormessages,529–531packets,295–301point-to-pointmedia,328redistribution,488–494routerLSAs,304–306Stuckin2-WAYstate,398–400StuckinATTEMPTstate,383–386StuckinEXSTART/EXCHANGEstate,401–417StuckinINIT,state,387–398StuckinLOADINGstate,417–422summarization,494–499summaryLSAs,309–312totallystubbyareas,321unadvertiseddefaultroutes,450–462unadvertisedexternalroutes,441–449unadvertisedroutes,troubleshooting,422–429,431unadvertisedsummaryroutes,432–440uninstalledexternalroutes,479–487uninstalledroutes,463–478“unknownroutingprotocol”errormessages,528virtuallinks,316–317

versusdistancevector,18link-staterequestpackets(OSPF),300link-stateupdatepackets(OSPF),301

loadbalancingdual-homedoutboundBGPtraffic,806–812IGRP,168uninstalledequal-costpaths,166–168variance,201–204

Loadingstate,OSPFneighbors,338gettingstuck,417–422

localcomputation,213LOCAL_PREFattribute,policycontrol,675–676loopavoidance,distancevectorprotocols,20–21loopbackinterfaces,BGPpeering,732–733LSAgefield(LSAs),303LSChecksumfield(LSAs),303LSSequenceNumberfield(LSAs),303LSTypefield(OSPFlink-staterequestpackets),300LSTypefield(LSAs),303LSAHeaderfield(OSPFDBDpackets),300LSAs,295,302–303externalLSAs(Type5),313–315headerfields,303–304indicationLSAs,332–333networkLSAs(Type2),307–308NSSA,Pbit,324periodic,332routerLSAs(Type1),304–306summaryLSAs(Type3/4),309–312fields,310

Type7,filtering,326LSPDatabaseOverloadBitfield(LSPs),555LSPIdentifierfield(LSPs),553LSPnumberfield(LSPs),554LSPRefreshIntervaltimer,IS-ISlink-statedatabase,557LSPRetransmitIntervaltimer,IS-ISlink-statedatabase,557LSPs(link-statepackets),553directinspection,606–607flooding,552,555–557headerfields,553–555TLVs,547TransmissionIntervaltimer,557

MMBitfield,OSPFDBDpackets,299

manualsummarization,EIGRP,219–220masks,8matchas_pathcommand,implementinginroutemaps,692–693matchcommunitycommand,implementinginroutemaps,692matchipaddresscommand,implementinginroutemaps,691Maxagetimer,IS-ISlink-statedatabase,556MaximumResponseTimefield,IGMPpackets,636MED(multi-exitdiscriminator)attributebest-pathselection,824–827infinitevalue,777policycontrol,677–682

mediaindependenceofIPaddressing,5mediatypesLayer2,uninstalledIGRProutes,troubleshooting,161–163OSPFdemandcircuits,331–334multiaccessmedia,327–328NBMAmedia,329–331point-to-pointmedia,328

messages“%OSPF-4-BADLSATYPEInvalidlsaBadLSAtype”,529“couldnotallocaterouteid”,529CPUHOG(OSPF),499–503“OSPF-4-ERRRCV”,529–531“unknownroutingprotocol”,528PIM,638–640

Metricfield(routerLSAs),305metricfield(summaryLSAs),310metrics,29–30cost(OSPF),overriding,305distancevectorprotocols,19EIGRP,208–209IGRP,127–129definingforredistribution,191–194

IS-IS,545–548link-stateprotocols,24

misconfigurationaccesslists,troubleshootinguninstalledIGRProutes,149–155BGPdistributelists,752–754neighboraddresses,731–732routeorigination,746–749

IS-ISadjacencies,589–605casestudy,619–622redistribution,611routeadvertisements,607–611

neighborstatements,99–100unadvertisedIGRProutes,180–181

networkstatements,unadvertisedIGRProutes,169–171routereflectionIBGPneighbors,779–780identicalclusterIDs,785–790

routers,troubleshootinguninstalledIGRProutes,143–146mismatchedASnumbers(EIGRP),239mismatchedauthenticationkey,troubleshootingRIProuteinstallation,68–71mismatchedKvalues,EIGRP,237mismatchedmasks,EIGRP,235–237mismatchedsenderASnumber,troubleshootinguninstalledIGRProutes,163–166modifyingBGPdampeningparameters,771–772,774MSBitfield,OSPFDBDpackets,300multiaccessmedia,OSPFnetworks,327–328multicast,625IGMPjoins,643–645leavemechanism,627–628packetformat,635querierelectionmechanism,627version1,626version2,627

PIMdensemode,625,630–632,646–651messages,638–640packets,636–638sparsemode,625,632–634,651–656

RIPaddresses,42RPF,628–630

multicastrouting,versusunicast,12–14multihoming,552,660

NNBMAmedia,OSPFnetworks,329broadcastmode,329–330point-to-multipointmode,331

point-to-pointmode,330Neighborfield(OSPFHellopackets),299neighborrelationshipsBGP-4,663–664external,665–667external,incorrectIPaddressassignment,731–732internal,667routeadvertisements,668–672

EIGRP,209–210,227mismatchedASnumbers,239mismatchedKvalues,237mismatchedmasks,235–237one-way,230,232reviewingdocumentedchanges,228–229SIAerror,240–250uncommonsubnets,233–235

external(BGP)IPconnectivity,728Layer2problems,729–731

IBGP,client-to-clientreflection,780–782internalmisconfiguration,779–780routepropagation,754–762unintentionalTCPpacketblockages,741–742

OSPF2-waystate,336Attemptstate,336Downstate,335emptyneighborlists,351–383ES-IS,538Exchangestate,337Exstartstate,336Fullstate,338Initstate,336IS-IS,538–540Loadingstate,338Stuckin2-WAYstate,398–400StuckinATTEMPT,383–386StuckinEXSTART/EXCHANGEstate,401–417StuckinINIT,387–398StuckinLOADINGstate,417–422unadvetiseddefaultroutes,450–462

unadvetisedexternalroutes,441–449unadvetisedsummaryroutes,432–440

networkconvergencetime,129networkinterfaces,unadvertisedIGRProutes,troubleshooting,175–176networkLSAs(Type2),302,307–308NetworkMaskfieldExternalLSAs,313NetworkLSAs,307OSPFhellopackets,298summaryLSAs,310

NextHopfield(RIPpackets),41NEXT_HOPattribute,policycontrol,685nodes,IS-IS,536–537nondirectlyconnectedexternalBGPneighborrelationships,732–733misconfiguration,736–740missingroutingtableaddresses,733–736

normalareas,319NSAPs(networkserviceaccesspoints),536defining,551format,549–551

NSSAs,321–324configuring,322–324defaultroutes,326–327injectingexternalroutes,325–326totallyNSSAs,324–326Type7LSAs,302filtering,326Pbit,324

nullauthentication,364Null0route,advertising,670NumberofLinksfield(routerLSAs),305

Ooctets,IPaddressrepresentation,7offsetlistvaluestroubleshootingRIProuteinstallation,79–81

oilist,630–631one-wayneighborrelationships,EIGRP,230–232Opcodefield,EIGRPpackets,216OpenConfirmstate(BGP-4),664OpenSentstate(BGP-4),664optionalcapabilitymismatch,370–372

OptionsfieldOSPFDBDpackets,299OSPFHellopackets,298–299

Optionsfield(LSAs),303ORF,BGP-4policycontrol,700–702ORIGINattribute,policycontrol,685originatingBGProutesclassfulnetworkadvertisements,749–751misconfiguration,746–749misconfigureddistributelists,752–754missingroutingtableentries,743–746

OSIreferencemodelversusTCP/IPmodel,3OSPF,295%OSPF-4-BADLSATYPEerrormessages,529adjacencies,334–3352-waystate,336Attemptstate,336Downstate,335Exchangestate,337Exstartstate,336Fullstate,338Initstate,336Loadingstate,338optionalcapabilitymismatches,370–372

areas,315–316,318normal,319NSSAs,321–326stub,319–320totallystubby,321

backboneindicationLSAs,332–333virtuallinks,316–317

“couldnotallocaterouteid”errormessages,529DDR,503–516debugs,CPUutilization,341demandcircuits,331–334Dijkstraalgorithm,295externalroutes,summarization,497–499linktypes,305LSAs,295,302–303externalLSAs(Type5),313–315headerfields,303–304

networkLSAs(Type2),307–308routerLSAs(Type1),304–306summaryLSAs(Type3/4),309–312

multiaccessmedia,327–328NBMAmedia,329broadcastmode,329–330point-to-multipointmode,331point-to-pointmode,330

neighborrelationshipsemptyneighborlists,351–383unadvertiseddefaultroutes,450–462unadvertisedexternalroutes,441–449unadvertisedsummaryroutes,432–440

nullauthentication,364“OSPF-4-ERRRCV”errormessages,529–531packets,295–297DBD,299fields,296Hello,297–299link-stateacknowledgment,301link-staterequest,300link-stateupdate,301

point-to-pointmedia,328redistribution,488–494SPFcalculations,518–528Stuckin2-WAYstate,398–400StuckinATEMPT,383–386StuckinEXSTART/EXCHANGEstate,401–417StuckinINITstate,387–398StuckinLOADINGstate,417–422summarization,494–496unadvertisedroutes,422–431uninstalledexternalroutes,479–487uninstalledroutes,463–478“unknownroutingprotocol”errormessages,528

outbounddual-homedBGPtraffic,outboundtrafficflows(BGP)asymmetricalrouting,802–806dual-homed,798–802loadbalancing,806–812

reachability,795–798singleexitpointfromAS,791–795

outgoinginterface,unadvertisedIGRProutes,troubleshooting,171–172

overridingOSPFmetriccalculation,305

PPbit,324packetdrops,IGRP,199–201PacketLengthfield(OSPFpackets),297packets,3,533data-forwardingprocess,addressing,4EIGRPIPInternalRouteTLV,216–217Qcount,232queryprocess,220reliable,214TLV,216–217

forwarding,high-speed,25hop-by-hopdestination-basedforwarding,4IGMPTypefield,635IGRP,131IIHs,538–539IS-IS,542genericformat,543–545TLVfields,543–545

LSPsdirectinspection,606–607flooding,552headerfields,553–555

multicast,625multicastrouting,12–14OSPF,295–297DBD,299Hello,297–299link-stateacknowledgment,301Link-StateRequest,300link-stateupdate,301

PIM,636–638RIPAFI,42NextHopfield,41

SNPs,556TCP,unintentionalblockages,741–742

parametersforBGPdampening,modifying,771–774partialfeed,659

PartitionBitfield(LSPs),554passiveoutgoinginterfacesRIProuteadvertisement,95–96unadvertisedIGRProutes,176–178

passiveroutes(EIGRP),213payload,4PDUs(protocoldataunits),542peergroups,improvingBGPconvergence,783–785peeringbetweennondirectlyconnectedexternalneighbors,missingroutingtableaddresses,733–736BGP-4externalneighborrelationships,665–667internalneighborrelationships,667routeadvertisements,668–672

periodicLSAs,332periodicupdates,distancevectorprotocols,22PIM(ProtocolIndependentMulticast)densemode,625,630–631assertmechanism,631–632troubleshooting,646–651

IGMPjoins,643–645messages,638–640packets,636–638sparsemode,625,632,651,654–656discoveryprocess,632–633joinmechanism,633registerprocess,634RPs,632

pingclnscommand,617–619point-to-multipointmode(NBMA),331point-to-pointIIHs,539point-to-pointlinks,IS-IS,536point-to-pointmedia,OSPFnetworks,328point-to-pointmode(NBMA),330point-to-pointseriallinks,IS-ISconfiguration,559–565poisonreverse,distancevectorprotocols,22poisonupdates,130policies,BGP,661policycontrol,672–674AS_PATHattribute,682–685communities,697–699distributelists,695–696

filterlists,695LOCAL_PREFattribute,675–676MEDattribute,677–682NEXT_HOPattribute,685ORF,700–702ORIGINattribute,685prefixlists,696routemaps,690–694matchas_pathcommand,692–693matchcommunitycommand,692matchipaddresscommand,691setas-pathprependcommand,693setcommunitycommand,693setlocalpreferencecommand,694setmetriccommand,694

WEIGHTknob,686–688policyrouting(BGP),outboundIPtrafficflows,790asymmetricalrouting,802–806dual-homedconnections,798–802reachability,795–798singleexitpoint,791–795

prefixlists,BGP-4policycontrol,696prefixesadvertising,668–670synchronizationrule,671–672

assignedattributes,displaying,726originationclassfulnetworkadvertisements,749–752distributelists,752–754misconfiguration,746–749

prependingAS_PATH,682–685preventingroutingloopsDUAL,207,211activeroutes,213FC,211FD,211feasiblesuccessors,212passiveroutes,213RD,211successors,211

privateIPv4addressspace,7–8privatepeering,660

protocolheaderformat,OSPFpackets,296protocolspecifications,BGP-4,662

externalneighborrelationships,665–667internalneighborrelationships,667neighborrelationships,663–664

protocol-independentcommands,24prunemechanism,PIMdense-mode,631Pseudonodeidentifierfield(LSPs),554PSN(pseudonodes),539PSNPs(partialsequencenumberpackets),556publicpeering,660

Q-RQcount,232querierelectionmechanism,IGMPversion2,627queriesEIGRP,214,220RIPs,43

RD(reporteddistance),211reachabilityEBGPmultihopnexthops,774–777IBGPnext-hops,766–771IS-ISpingclnscommand,617–619traceroutecommand,617–619

IS-ISTLVs,547outboundBGPtrafficflows,795–798RIProuteinstallation,52

receiverproblems,IGRPuninstalledroutes,142receivingupdates,RIP,33–35redistributionEIGRP,280–286externalroutesintoIS-IS,570–573IGRPmetric,defining,191–194intoNSSAs,filteringType7LSAs,326IS-IS,misconfiguration,611OSPF,488–494RIP,113–116

redundancydialbackuplinksEIGRP,286–290IGRP,194–198

virtuallinks,316registermessage(PIM),638registerprocess,PIMsparsemode,634reliableEIGRPpackets,214RemainingLifetimefield(LSPs),553replies(EIGRP),214resolvingEIGRPSIAerrors,240–250reviewingEIGRPneighborchanges,228–229RFC1771,synchronizationrule,671–672RIDs(routerIDs),659best-pathselection,821–823

RIP(RoutingInformationProtocol)authentication,42compatibilityissues,43DDR,116–122defaultroutes,39–40discontiguousnetworks,36–37flappingroutes,122–124hopcount,29metrics,29–30missingsubnettedroutes,106–109NextHopfield,41packetbehavior,31packets,AFI,42redistribution,113–116routeadvertisements,86blockedroutes,91–93brokenmulticastcapability,96–98downnetworkinterface,93–94downoutgoinginterface,89–91misconfiguredneighborstatement,99–100passiveoutgoinginterface,95–96sendingRIProutes,86splithorizon,102,105–106VLSMroutes,100–102

routeinstallation,52splithorizon,30–31subnetmasks,41summarization,109–113timers,30uninstalledroutes,causesof,52blockedRIPbroadcast,63–65

blockedsourceaddress,60–63discontiguousnetworks,71–74distributelistincomingroutes,58–60equal-costpaths,83–86hopcountexceeded,81–83incompatibleRIPversion,65–68incorrectnetworkstatements,53–56invalidsources,74–76Layer2problems,76–78lineprotocolindownstate,56–58mismatchedauthenticationkey,68–71offsetlistvaluetoohigh,79–81

updatesreceiving,33–35sending,31–33

versionfield,43VLSM,37–39

RIP-2multicast,42RouteTagfield,40–41

routeadvertisementsEIGRP,250discontiguousnetworks,252–253misconfigureddistributelists,251–252split-horizon,253–256unexpectedadvertisements,257–259unexpectedmetrics,259–263

IGRP,168–188OSPF,troubleshootingunadvertisedroutes,422–431

routedampening,702–706routeflapping,EIGRP,271–275routeinstallationEIGRP,264summarization,265–270

OSPFuninstalledexternalroutes,479–487uninstalledroutes,463–478

routemaps,BGP-4policycontrol,690–694communities,697–699distributelists,695–696filterlists,695matchas_pathcommand,692–693

matchcommunitycommand,692matchipaddresscommand,691ORF,700–702prefixlists,696setas-pathprependcommand,693setcommunitycommand,693setlocal-preferencecommand,694setmetriccommand,694

routeorigination(BGP)classfulnetworkadvertisements,749–751misconfiguration,746–749misconfigureddistributelists,752–754missingroutingtableentries,743–746

routeredistribution,OSPF,488–494routereflection,707–711,778client-to-client,780–782clusterdesign,757–758identicalclusterIDs,785,788–790misconfiguredIBGPneighbor,779–780peergroups,783–785

routesummarizationEIGRP,276–280OSPFexternalroutes,497–499troubleshooting,494–496

routetagfield(RIP-2),40–41route-flapping,IS-IS,612–616RouterDeadIntervalfield(OSPFHellopackets),299RouterIDfield(OSPFpackets),297routerLSAs(Type1),302–306routersconvergence,129high-speedpacketforwarding,25OSPFadjacencies,334–338linktypes,305

routes,poisoned,22routingdomains,IS-IS,536routingloops,30DUAL,207,211activeroutes,213FC,211

FD,211feasiblesuccessors,212passiveroutes,213RD,211successors,211

IGRPsplithorizon,130splithorizonwithpoisonreverse,130

routingpolicies,BGP-4,672–674AS_PATHattribute,682–685LOCAL_PREFattribute,675–676MEDattribute,677–682NEXT_HOPattribute,685ORIGINattribute,685WEIGHTknob,686–688

routingprotocolsadministrativedistance,24classful,29distancevectorconvergence,19–20countingtoinfinity,21holddown,21loopavoidance,20–21metrics,19periodicupdates,22poisonreverse,22splithorizon,22triggeredupdates,22

EIGRP,207behavior,218–219convergence,207defaultroutes,221DUAL,207,211–213IPInternalRouteTLV,216–217metrics,208–209neighborrelationships,209–210packetfields,216–217queryprocess,220RTP,214summarization,219–220unequal-costloadbalancing,221–223

IGRP

behavior,131defaultroutes,132–133metrics,127–129packets,131splithorizon,130splithorizonwithpoisonreverse,130timers,129–130unequal-costloadbalancing,133–134

link-state,23–24OSPF,295adjacencies,334–338areas,315–326demandcircuits,331–334externalLSAs,313–315LSAs,302–304multaccessmedia,327–328NBMAmedia,329–331networkLSAs,307–308packets,295–301routerLSAs,304–306summaryLSAs,309–312virtuallinks,316–317

unicastversusmulticast,13–14routingtablesBGPuninstalledEBGP-learnedroutes,771–777uninstalledIBGP-learnedroutes,763–771

EIGRP,nonexistentsummarizedroutes,276–278IGRPflappingroutes,198–201uninstalledroutes,troubleshooting,142–166

OSPFuninstalledexternalroutes,479–487uninstalledroutes,463–478

routingupdates,606–607IS-ISredistributionintoLevel1,611routeadvertisements,607–611

RPF(reversepathforwarding),628–630RPFcheckfailure,650RPs(rendezvouspoints),632RTO(retransmissiontimeout),232

RTP(ReliableTransferProtocol),214RtrPrifield(OSPFHellopackets),299

Sscalability,IBGP

ASconfederations,711–712routereflectors,707–711

securityauthentication,nullauthentication,364IS-IS,authentication,548

selectingBGPbest-path,821–827senderproblemsIGRPuninstalledroutes,troubleshooting,142,168–188uninstalledIGRProutes,163–166

sendingRIProutes,31–33,86blockedroutes,91–93brokenmulticastcapability,96–98downnetworkinterface,93–94downoutgoinginterface,89–91misconfiguredneighborstatement,99–100missingnetworkstatement,87–89passiveoutgoinginterface,95–96splithorizon,102,105–106VLSMroutes,100–102

Sequencefield(EIGRPpackets),216SequenceNumberfield(LSPs),554seriallinks(point-to-point),IS-ISconfiguration,559–565servers,routereflectors,757setas-pathprependcommand,implementinginroutemaps,693setcommunitycommand,implementinginroutemaps,693setlocalpreferencecommand,implementinginroutemaps,694setmetriccommand,implementinginroutemaps,694showclnsinterfacecommand,564,586showclnsneighborscommand,586showclnsneighborsdetailcommand,563fielddefinitions,588

showclnsprotocolcommand,562–563showipbgpcommand,726showipbgpneighborcommand,726showipbgpneighborscommand,726–727showipbgpsummarycommand,726showipeigrpneighborcommand,210

showipeigrptopologyactivecommand,242–245showipprotocolscommand,56showiproutecommand,12,56,134,142showisisdatabasecommand,586showisistopologycommand,565,586SIA(stuckinactive)routeerrors,220EIGRP,240–250

SNPs(sequencenumberpackets),556sourcevaliditychecks,failureonIGRPnetworks,159–161sparsemode(PIM),625,632discoveryprocess,632–633joinmechanism,633registerprocess,634RPs,632troubleshooting,651,654–656

SPFalgorithm,17IS-ISdecisionprocess,558OSPF,518–528triggers,614–615

splithorizon,130–131distancevectorprotocols,22EIGRP,253–256RIP,30poisonreverse.31routeadvertisement,102,105–106

unadvertisedIGRProutes,troubleshooting,184,187–188SRTT(smoothround-triptime),232standardaccesslistsBGPfiltering,unfilteredsubnets,828–830debugipbgpupdatecommandoutput,727

staticrouting,4,11stubareas,319–320Stuckin2-WAYstate,398–400StuckinATTEMPT,383–386StuckinEXSTART/EXCHANGEstate,401–417StuckinINITstate,382,387–398StuckinLOADINGstate,417–422subnetmasks,RIP,41subnets,12autosummarization,106–109discontiguous,uninstalledIGRProutes,155–158masks,8

successors(EIGRP),211summarizationEIGRP,276–280OSPFexternalroutes,497–499troubleshooting,494–496

RIP,109excessivelylargeroutingtable,110–113

summaryASBRLSAs(Type4),302summaryLSAs(Type3),309–312summarynetworkLSAs(Type3),302summaryroutes,unadvertised,432–440supernets,10synchronizationBGProutes,disabling,766IS-IS,555–557

synchronizationrule(BGP-4),671–672synchronizedBGProutes,propagatingtoneighbor,761–762Systemidentifierfield(LSPs),554

TTCP(TransmissionControlProtocol),unintentionalpacketblockages,741–742TCP/IP(TransmissionControlProtocol/InternetProtocol)IPaddressingCIDR,10classes,5–7mediaindependence,5privateaddressspace,7–8subnets,12subnetting,8

IPprotocol,3versusOSIreferencemodel,3

three-wayreliableadjacencies,540timers,RIP,30timersbasiccommand,130TLV(Type/Length/Value),216–217IPInternalRoute,216–217IS-ISpackets,543–545LSPTLVs,547metricinformation,545–548

topologies,IS-IS,displaying,565topologytable(EIGRP)

convergence,19–20diffusedcomputation,213localcomputation,213

ToSfield(routerLSAs),305ToSfield(summaryLSAs),310ToSMetricfield(routerLSAs),305ToSmetricfield(summaryLSAs),310totallyNSSAs,324–326totallystubbyareas,321traceroutecommand,617–619trafficEIGRP,unequal-costloadbalancing,221–223IGRPloadbalancing,168unequal-costloadbalancing,133–134

transitlinks,identifyingattachedrouters,308transitpeering,660triggeredupdates,distancevectorprotocols,22Type1LSAs,304–306Type2LSAs,307–308Type3LSAs,309–312Type4LSAs,309–312Type5LSAs,313–315comparingtoType7,322

Type7LSAsfiltering,326NSSAs,321–324

TypefieldIGMPpackets,635OSPFpackets,296routerLSAs,305

UunadvertisedIGRProutesbroadcastcapability,178–180defaultroutecandidates,188–191distributelists,173–174misconfiguredneighborstatement,180–181misconfigurednetworkstatement,169–171networkinterface,175–176outgoinginterface,171–172passiveoutgoinginterface,176–178

splithorizon,184,187–188troubleshooting,169VLSM,182–184

uncommonsubnets,EIGRP,233–235unequal-costloadbalancing,133–134EIGRP,221–223IGRP,133–134variance,201–204

unexpectedmetrics,EIGRP,259–263unexpectedrouteadverisements,EIGRP,257–259unicastroutingversusmulticast,12–14unicasts,625unidirectionallinks,EIGRP,230,232uninstalledroutesEBGPdampening,771–774infiniteMEDvalue,777unreachalemultihopEBGPnexthop,774–777

EIGRP,265–270external(OSPF),479,481–487IBGPsynchronization,763–766unreachablenext-hops,766–771

IGRPreceiverproblems,142senderproblems,168–188troubleshooting,142–166

OSPF,463–478RIP,52

“unknownroutingprotocol”errormessages,528unreachableIBGPnexthops,766–771unreliableEIGRPpackets,214updatepackets(EIGRP),214updateprocess(IS-IS),555updatetimersIGRP,129IS-IS,556–557RIP,30

updatesIGRP,poisonupdates,130RIPreceiving,33–35

sending,31–33utilization(CPU),OSPF,499–503

Vvariable-lengthsubnetmask.SeeVLSMvariance,201–204variancecommand,133–134,221–223VersionfieldEIGRPpackets,216RIP,43

VersionNumberfield(OSPFpackets),296virtuallinks,316–318VLSM(variable-lengthsubnetmask),9RIP,37–39routeadvertisement,100–102

unadvertisedIGRProutes,troubleshooting,182–184

WWEIGHTknob,policycontrol,686–688

Documents

Cisco.press.troubleshooting.ip.Routing.protocols.may.2002