Cisco.press.troubleshooting.ip.Routing.protocols.may.2002
-
Upload
ljubisabrajovic -
Category
Documents
-
view
4 -
download
0
Transcript of 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
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
•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.
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)
DebugsandVerificationSolution
RIPRoutesNotintheRoutingTable—Cause:IncompatibleRIPVersionTypeDebugsandVerificationSolution
RIPRoutesNotintheRoutingTable—Cause:MismatchAuthenticationKey(RIP-2)DebugsandVerificationSolution
RIPRoutesNotintheRoutingTable—Cause:DiscontiguousNetworkDebugsandVerificationSolution
RIPRoutesNotintheRoutingTable—Cause:InvalidSourceDebugsandVerificationSolution
RIPRoutesNotintheRoutingTable—Cause:Layer2Problem(Switch,FrameRelay,OtherLayer2Media)
DebugsandVerificationSolution
RIPRoutesNotintheRoutingTable—Cause:OffsetListHasaLargeMetricDefinedDebugsandVerificationSolution
RIPRoutesNotintheRoutingTable—Cause:RoutesReachedRIPHopCountLimitDebugsandVerificationSolution
Problem:RIPIsNotInstallingAllPossibleEqual-CostPaths—Cause:maximumpathCommandRestrictsRIPfromInstallingMoreThanOnePath
DebugsandVerificationSolution
TroubleshootingRIPRoutesAdvertisementProblem:SenderIsNotAdvertisingRIPRoutes
SenderIsNotAdvertisingRIPRoutes—Cause:MissingorIncorrectnetworkStatementDebugsandVerificationsSolution
SenderIsNotAdvertisingRIPRoutes—Cause:OutgoingInterfaceIsDownDebugsandVerificationSolution
SenderIsNotAdvertisingRIPRoutes—Cause:distribute-listoutIsBlockingtheRouteDebugsandVerificationSolution
SenderIsNotAdvertisingRIPRoutes—Cause:AdvertisedNetworkInterfaceIsDownDebugsandVerificationSolution
SenderIsNotAdvertisingRIPRoutes—Cause:OutgoingInterfaceIsDefinedPassiveDebugsandVerificationSolution
SenderIsNotAdvertisingRIPRoutes—Cause:BrokenMulticastCapability(FrameRelay)
DebugsandVerificationSolution
SenderIsNotAdvertisingRIPRoutes—Cause:MisconfiguredneighborStatementDebugsandVerificationSolution
SenderIsNotAdvertisingRIPRoutes—Cause:AdvertisedSubnetIsVLSMDebugsandVerificationSolution
SenderIsNotAdvertisingRIPRoutes—Cause:SplitHorizonIsEnabledDebugsandVerificationSolution
Problem:SubnettedRoutesMissingfromtheRoutingTableofR2—Cause:AutosummarizationFeatureIsEnabled
DebugsandVerificationSolution
TroubleshootingRoutesSummarizationinRIPProblem:RIP-2RoutingTableIsHuge—Cause:AutosummarizationIsOff
DebugsandVerificationSolution
Problem:RIP-2RoutingTableIsHuge—Cause:ipsummary-addressIsNotUsedDebugsandVerificationSolution
TroubleshootingRIPRedistributionProblemsDebugsandVerificationSolution
TroubleshootingDial-on-DemandRoutingIssuesinRIPProblem:RIPBroadcastIsKeepingtheISDNLinkUp—Cause:RIPBroadcastsHaveNotBeen
DeniedintheInterestingTrafficDefinitionDebugsandVerificationSolution
Problem:RIPUpdatesAreNotGoingAcrosstheDialerInterface—Cause:MissingbroadcastKeywordinadialermapStatement
DebugsandVerificationSolution
TroubleshootingRoutesFlappingProbleminRIPDebugsandVerificationSolution
Chapter4UnderstandingInteriorGatewayRoutingProtocol(IGRP)
Metrics
TimersSplitHorizonSplitHorizonwithPoisonReverse
IGRPPacketFormatIGRPBehaviorDefaultRouteandIGRP
Unequal-CostLoadBalancinginIGRPSummaryReviewQuestions
Chapter5TroubleshootingIGRP
FlowchartstoSolveCommonIGRPProblemsTroubleshootingIGRPRouteInstallation
Problem:IGRPRoutesNotintheRoutingTableIGRPRoutesNotintheRoutingTable—Cause:MissingorIncorrectnetworkStatement
DebugsandVerificationSolution
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)
DebugsandVerificationSolution
IGRPRoutesNotintheRoutingTable—Cause:Sender’sASMismatchDebugsandVerificationSolution
Problem:IGRPIsNotInstallingAllPossibleEqual-CostPaths—Cause:maximumpathsRestrictsIGRPtoaMaximumofFourPathsbyDefault
DebugsandVerificationSolution
TroubleshootingIGRPRoutesAdvertisementProblem:SenderIsNotAdvertisingIGRPRoutes
SenderIsNotAdvertisingIGRPRoutes—Cause:MissingorIncorrectnetworkStatementDebugsandVerificationSolution
SenderIsNotAdvertisingIGRPRoutes—Cause:OutgoingInterfaceIsDownDebugsandVerificationSolution
SenderIsNotAdvertisingIGRPRoutes—Cause:distribute-listoutIsBlockingtheRouteDebugsandVerificationSolution
SenderIsNotAdvertisingIGRPRoutes—Cause:AdvertisedNetworkInterfaceIsDownDebugsandVerificationSolution
SenderIsNotAdvertisingIGRPRoutes—Cause:OutgoingInterfaceIsDefinedasPassiveDebugsandVerificationSolution
SenderIsNotAdvertisingIGRPRoutes—Cause:BrokenBroadcastCapability(EncapsulationFailureinLayer2)
DebugsandVerificationSolution
SenderIsNotAdvertisingIGRPRoutes—Cause:MisconfiguredneighborStatementDebugsandVerificationSolution
SenderIsNotAdvertisingIGRPRoutes—Cause:AdvertisedSubnetIsVLSMDebugsandVerificationSolution
SenderIsNotAdvertisingIGRPRoutes—Cause:SplitHorizonIsEnabledDebugsandVerificationSolution
Problem:CandidateDefaultIsNotBeingAdvertised—Cause:ipdefault-networkCommandIsMissing
DebugsandVerificationSolution
TroubleshootingIGRPRedistributionProblemsProblem:RedistributedRoutesAreNotGettingInstalledintheRoutingTable—Cause:MetricIs
NotDefinedDuringRedistributionintoIGRPDebugsandVerificationSolution
TroubleshootingDial-on-DemandRouting(DDR)IssuesinIGRP
Problem:IGRPBroadcastIsKeepingtheISDNLinkUp—Cause:IGRPBroadcastsHaveNotBeenDeniedintheInterestingTrafficDefinition
DebugsandVerificationSolution
Problem:IGRPUpdatesAreNotGoingAcrosstheDialerInterface—Cause:MissingBroadcastKeywordinadialermapStatement
DebugsandVerificationSolution
TroubleshootingRouteFlappingProbleminIGRPProblem:IGRPRoutesAreFlapping—Cause:PacketDropsonSender’sorReceiver’sInterface
DebugsandVerificationSolution
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
DebugsandVerificationSolution
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
DebugsandVerificationSolution
Problem:OSPFNeighborStuckinATTEMPTOSPFNeighborStuckinATTEMPT—Cause:MisconfiguredneighborStatement
DebugsandVerificationSolution
OSPFNeighborStuckinATTEMPT—Cause:UnicastConnectivityIsBrokenonNBMADebugsandVerificationSolution
Problem:OSPFNeighborStuckinINIT
OSPFNeighborStuckinINIT—Cause:AccessListonOneSideIsBlockingOSPFHellosDebugsandVerificationSolution
OSPFNeighborStuckinINIT—Cause:MulticastCapabilitiesAreBrokenonOneSide(6500SwitchProblem)
DebugsandVerificationSolution
OSPFNeighborStuckinINIT—Cause:Cause:AuthenticationIsEnabledOnlyonOneSideDebugsandVerificationSolution
OSPFNeighborStuckinINIT—Cause:Theframe-relaymap/dialer-mapStatementonOneSideIsMissingthebroadcastKeyword
DebugsandVerificationSolution
OSPFNeighborStuckinINIT—Cause:HellosAreGettingLostonOneSideatLayer2DebugsandVerificationSolution
Problem:OSPFNeighborStuckin2-WAY—Cause:Priority0IsConfiguredonAllRoutersDebugsandVerificationSolution
Problem:OSPFNeighborStuckinEXSTART/EXCHANGEOSPFNeighborStuckinEXSTART/EXCHANGE—Cause:MismatchedInterfaceMTU
DebugsandVerificationSolutions
OSPFNeighborStuckinEXSTART/EXCHANGE—Cause:DuplicateRouterIDsonNeighbors
DebugsandVerificationSolution
OSPFNeighborStuckinEXSTART/EXCHANGE—Cause:Can’tPingAcrosswithMoreThanCertainMTUSize
DebugsandVerificationSolution
OSPFNeighborStuckinEXSTART/EXCHANGE—Cause:UnicastConnectivityIsBrokenDebugsandVerificationSolutions
OSPFNeighborStuckinEXSTART/EXCHANGE—Cause:NetworkTypeIsPoint-to-PointBetweenPRIandBRI/Dialer
DebugsandVerificationSolution
Problem:OSPFNeighborStuckinLOADINGOSPFNeighborStuckinLOADING—Cause:MismatchedMTUSize
DebugsandVerificationSolution
OSPFNeighborStuckinLOADING—Cause:Link-StateRequestPacketIsCorruptedDebugsandVerificationSolution
TroubleshootingOSPFRouteAdvertisement
Problem:OSPFNeighborIsNotAdvertisingRoutesOSPFNeighborIsNotAdvertisingRoutes—Cause:OSPFNotEnabledontheInterfaceThat
IsSupposedtoBeAdvertisedDebugsandVerificationSolution
OSPFNeighborIsNotAdvertisingRoutes—Cause:AdvertisingInterfaceIsDownDebugsandVerificationSolution
OSPFNeighborIsNotAdvertisingRoutes—Cause:SecondaryInterfaceIsinaDifferentAreaThanthePrimaryInterface
DebugsandVerificationSolution
Problem:OSPFNeighbor(ABR)NotAdvertisingtheSummaryRouteOSPFNeighbor(ABR)NotAdvertisingtheSummaryRoute—Cause:AreaIsConfiguredas
TotallyStubbyAreaDebugsandVerificationSolution
OSPFNeighbor(ABR)NotAdvertisingtheSummaryRoute—Cause:ABRIsNotConnectedtoArea0
DebugsandVerificationSolution
OSPFNeighbor(ABR)NotAdvertisingtheSummaryRoute—Cause:DiscontiguousArea0DebugsandVerificationSolution
Problem:OSPFNeighborIsNotAdvertisingExternalRoutesOSPFNeighborIsNotAdvertisingExternalRoutes—Cause:AreaIsConfiguredasaStub
AreaorNSSADebugsandVerificationSolution
OSPFNeighborIsNotAdvertisingExternalRoutes—Cause:NSSAABRNotTranslatingType7LSAsintoType5LSAs
DebugsandVerificationSolution
Problem:OSPFNeighborNotAdvertisingDefaultRoutesOSPFNeighborNotAdvertisingDefaultRoutes—Cause:Missingdefaultinformation
originateCommandsDebugsandVerificationSolution
OSPFNeighborNotAdvertisingDefaultRoutes—Cause:DefaultRouteMissingfromtheNeighbor’sRoutingTable
DebugsandVerificationSolution
OSPFNeighborNotAdvertisingDefaultRoutes—Cause:NeighborTryingtoInjectaDefaultintoaStubArea
DebugsandVerificationSolution
OSPFNeighborNotAdvertisingDefaultRoutes—Cause:NSSAABR/ASBRNotOriginatingType7Default
DebugsandVerificationSolution
TroubleshootingOSPFRouteInstallationProblem:OSPFNotInstallingAnyRoutesintheRoutingTable
OSPFNotInstallingAnyRoutesintheRoutingTable—Cause:NetworkTypeMismatchDebugsandVerificationSolution
OSPFNotInstallingAnyRoutesintheRoutingTable—Cause:IPAddressesAreFlippedinDualSerial-ConnectedRouters
DebugsandVerificationSolution
OSPFNotInstallingAnyRoutesintheRoutingTable—Cause:OneSideIsaNumberedandtheOtherSideIsanUnnumberedPoint-to-PointLink
DebugsandVerificationSolution
OSPFNotInstallingAnyRoutesintheRoutingTable—Cause:DistributeListIsBlockingtheRouteInstallation
DebugsandVerificationSolution
OSPFNotInstallingAnyRoutesintheRoutingTable—Cause:BrokenPVCinaFullyMeshedFrameRelayNetworkwithBroadcastNetworkType
DebugsandVerification
SolutionProblem:OSPFNotInstallingExternalRoutesintheRoutingTable
OSPFNotInstallingExternalRoutesintheRoutingTable—Cause:ForwardingAddressIsNotKnownThroughtheIntra-AreaorInterareaRoute
DebugsandVerificationSolution
OSPFNotInstallingExternalRoutesintheRoutingTable—Cause:ABRNotGeneratingType4SummaryLSA
DebugsandVerificationSolution
TroubleshootingRedistributionProblemsinOSPFProblem:OSPFNeighborIsNotAdvertisingExternalRoutes
OSPFNeighborIsNotAdvertisingExternalRoutes—Cause:SubnetsKeywordMissingfromtheASBRConfiguration
DebugsandVerificationSolution
OSPFNeighborIsNotAdvertisingExternalRoutes—Cause:distribute-listoutIsBlockingtheRoutes
DebugsandVerificationSolution
TroubleshootingRouteSummarizationinOSPF
Problem:RouterIsNotSummarizingInterareaRoutes—Cause:arearangeCommandIsNotConfiguredonABR
DebugsandVerificationSolution
Problem:RouterIsNotSummarizingExternalRoutes—Cause:summary-addressCommandIsNotConfiguredonASBR
DebugsandVerificationSolution
TroubleshootingCPUHOGProblemsProblem:CPUHOGMessagesDuringAdjacencyFormation—Cause:RouterIsNotRunning
Packet-PacingCodeDebugsandVerificationSolution
Problem:CPUHOGMessagesDuringLSARefreshPeriod—Cause:RouterIsNotRunningLSAGroup-PacingCode
DebugsandVerificationSolution
TroubleshootingDial-on-DemandRoutingIssuesinOSPFProblem:OSPFHellosAreBringingUptheLink—Cause:OSPFHellosArePermittedas
InterestingTrafficDebugsandVerificationSolution
Problem:DemandCircuitKeepsBringingUptheLinkDemandCircuitKeepsBringingUptheLink—Cause:ALinkFlapintheNetwork
DebugsandVerificationSolution
DemandCircuitKeepsBringingUptheLink—Cause:NetworkTypeDefinedasBroadcastDebugsandVerificationSolution
DemandCircuitKeepsBringingUptheLink—Cause:PPPHostRoutesAreGettingRedistributedintotheOSPFDatabase
DebugsandVerificationSolution
DemandCircuitKeepsBringingUptheLink—Cause:OneoftheRoutersIsNotDemandCircuit–Capable
DebugsandVerificationSolution
TroubleshootingSPFCalculationandRouteFlappingSPFRunningConstantly—Cause:InterfaceFlapWithintheNetwork
DebugsandVerificationSolution
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
DebugsandVerificationSolution
DirectlyConnectedExternalBGPNeighborsNotComingUp—Cause:IncorrectNeighborIP
AddressinBGPConfigurationDebugsandVerificationSolution
Problem:NondirectlyConnectedExternalBGPNeighborsNotComingUpNondirectlyConnectedExternalBGPNeighborsNotComingUp—Cause:Routetothe
NondirectlyConnectedPeerAddressIsMissingfromtheRoutingTableDebugsandVerificationSolution
NondirectlyConnectedExternalBGPNeighborsNotComingUp—Cause:ebgpmultihopCommandIsMissinginBGPConfiguration
DebugsandVerificationSolution
NondirectlyConnectedExternalBGPNeighborsNotComingUp—Cause:updatesourceinterfaceCommandIsMissing
DebugsandVerificationSolution
Problem:InternalBGPNeighborsNotComingUp
Problem:BGPNeighbors(ExternalandInternal)NotComingUp—Cause:InterfaceAccessListBlockingBGPPackets
DebugsandVerificationSolution
TroubleshootingBGPRouteAdvertisement/OriginationandReceivingProblem:BGPRouteNotGettingOriginated
BGPRouteNotGettingOriginated—Cause:IPRoutingTableDoesNotHaveaMatchingRoute
DebugsandVerificationSolution
BGPRouteNotGettingOriginated—Cause:ConfigurationErrorDebugsandVerificationSolution
BGPRouteNotGettingOriginated—Cause:BGPIsAutosummarizingtoClassful/NetworkBoundary
DebugsandVerificationSolution
ProbleminPropagating/OriginatingBGPRoutetoIBGP/EBGPNeighbors—Cause:MisconfiguredFilters
DebugsandVerificationSolution
ProbleminPropagatingBGPRoutetoIBGPNeighborbutNottoEBGPNeighbor—Cause:BGPRouteWasfromAnotherIBGPSpeaker
DebugsandVerificationSolution
IBGPFullMeshDesigningaRoute-ReflectorModelDesigningaConfederationModel
ProbleminPropagatingIBGPRoutetoIBGP/EBGPNeighbor—Cause:IBGPRouteWasNotSynchronized
DebugsandVerificationSolution
TroubleshootingBGPRouteNotInstallinginRoutingTableProblem:IBGP-LearnedRouteNotGettingInstalledinIPRoutingTable
IBGP-LearnedRouteNotGettingInstalledinIPRoutingTable—Cause:IBGPRoutesAreNotSynchronized
DebugsandVerificationSolution
IBGP-LearnedRouteNotGettingInstalledinIPRoutingTable—Cause:IBGPNextHopNotReachable
DebugsandVerificationSolution
AnnouncetheEBGPNextHopThroughanIGPUsingaStaticRouteorRedistributionChangetheNextHoptoanInternalPeeringAddress
Problem:EBGP-LearnedRouteNotGettingInstalledinIPRoutingTableEBGP-LearnedRouteNotGettingInstalledinIPRoutingTable—Cause:BGPRoutesAre
DampenedDebugsandVerificationSolution
EBGP-LearnedRouteNotGettingInstalledinIPRoutingTable—Cause:BGPNextHopNotReachableinCaseofMultihopEBGP
DebugsandVerificationSolution
EBGP-LearnedRouteNotGettingInstalledintheRoutingTable—Cause:MultiexitDiscriminator(MED)ValueIsInfinite
DebugsandVerificationTroubleshootingBGPRoute-ReflectionIssues
Problem:ConfigurationMistakes—Cause:FailedtoConfigureIBGPNeighborasaRoute-ReflectorClient
DebugsandVerification
SolutionProblem:Route-ReflectorClientStoresanExtraBGPUpdate—Cause:Client-to-Client
ReflectionDebugsandVerificationSolution
Problem:ConvergenceTimeImprovementforRRandClients—Cause:UseofPeerGroupsDebugsandVerificationSolution
Problem:LossofRedundancyBetweenRouteReflectorsandRoute-ReflectorClient—Cause:ClusterListCheckinRRDropsRedundantRoutefromOtherRR
DebugsandVerificationSolution
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
DebugsandVerificationSolution
Problem:LowestMEDNotSelectedasBestPathDebugsandVerificationSolution
TroubleshootingBGPFilteringProblem:StandardAccessListFailstoCaptureSubnets
DebugsandVerificationSolution
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.
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.
Figure2-10RIP-2PacketFormat
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.
Figure2-11RIP-2PacketFormat
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
R2#showiproute131.108.2.0Routingentryfor131.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:distribute-listinIsBlockingtheRoute
Adistributelistisafilteringmechanismforroutingupdates.Thedistributelistcallsanaccesslistandcheckstoseewhichnetworksaresupposedtobepermitted.Iftheaccesslistdoesn’tcontainanynetwork,theroutingupdatewillbeautomaticallydenied.Adistributelistcanbeappliedoneitherincomingroutingupdatesoroutgoingroutingupdates.Inthisexample,thedistribute-listinisconfigured;however,theaccesslistdoesn’tcontainthepermitstatementfor131.108.0.0,soR2isnotinstallingtheseroutesintheroutingtable.Figure3-4showstheflowcharttofollowtosolvethisproblembasedonthiscause.
Figure3-4FlowcharttoSolveWhyRIPRoutesDon’tShowUpinaRoutingTableDebugsandVerification
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
R2#showiproute131.108.2.0Routingentryfor131.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:AccessListBlockingRIPSourceAddress
Accesslistsareusedtofilterthetrafficbasedonthesourceaddress.Extendedaccesslistsareusedtofilterthetrafficbasedonthesourceordestinationaddress,T-2.Tofiltertheincomingandoutgoingtraffic,theseaccesslistsmaybeappliedontheinterfacewiththisinterface-levelcommand:
ipaccess-groupaccess-listnumber{in|out}
WhentheaccesslistisappliedinaRIPenvironment,alwaysmakesurethatitdoesn’tblockthesourceaddressoftheRIPupdate.Inthisexample,R2isnotinstallingRIProutesintheroutingtablebecauseaccess-list1isnotpermittingthesourceaddressofRIPupdatesfromR1.Figure3-5showstheflowcharttofollowtosolvetheproblembasedonthiscause.
Figure3-5FlowcharttoSolveWhyRIPRoutesDon’tShowUpinaRoutingTableDebugsandVerification
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
R2#showiproute131.108.2.0Routingentryfor131.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:AccessListBlockingRIPBroadcastorMulticast(inCaseofRIP-2)
Accesslistsareusedtofiltercertaintypesofpackets.Whenusingaccesslistsontheinterfaceinbound,alwaysmakesurethattheyarenotblockingtheRIPbroadcastorUDPport520,whichisusedbyRIP-1andRIP-2(ortheRIPmulticastaddress,incasesofRIP-2).Iftheseaddressesarenotpermittedintheaccesslistthatisappliedontheinterfaceinbound,RIPwillnotinstallanyroutesintheroutingtablelearnedonthatinterface.Figure3-6showstheflowcharttofollowtosolvethisproblembasedonthiscause.
Figure3-6FlowcharttoSolveWhyRIPRoutesDon’tShowUpinaRoutingTableDebugsandVerification
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.
Figure3-7FlowcharttoSolveWhyRIPRoutesDon’tShowUpinaRoutingTableDebugsandVerification
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
R2#showiproute131.108.2.0Routingentryfor131.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:MismatchAuthenticationKey(RIP-2)
OneoftheoptionsinRIP-2isthattheRIP-2updatescanbeauthenticatedforincreasedsecurity.Whenauthenticationisused,apasswordmustbeconfiguredonbothsides.Thispasswordiscalledtheauthenticationkey.Ifthiskeydoesnotmatchwiththekeyontheotherside,theRIP-2updateswillbeignoredonbothsides.Figure3-8showstheflowcharttofollowtosolvethisproblembasedonthiscause.
Figure3-8FlowcharttoSolveWhyRIPRoutesDon’tShowUpinaRoutingTableDebugsandVerification
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
R2#showiproute131.108.2.0Routingentryfor131.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:DiscontiguousNetwork
Whenamajornetworkisseparatedbyanothermajornetworkinthemiddle,thisiscalledadiscontiguousnetwork.Chapter2,“UnderstandingRoutingInformationProtocol(RIP),”providesadetailedexplanationofwhyRIPdoesnotsupportdiscontiguousnetworks.EnablingRIPwiththistopologycausesproblems.Figure3-9showsanexampleofadiscontiguousnetworkthatexistswhenamajornetworkisseparatedbyanothermajornetwork.
Figure3-9AnExampleofaDiscontiguousNetwork
Figure3-10showstheflowcharttofollowtosolvethisproblembasedonthiscause.
Figure3-10FlowcharttoSolveWhyRIPRoutesDon’tShowUpinaRoutingTableDebugsandVerification
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
R2#interfaceLoopback0ipaddress137.99.3.2255.255.255.0!
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.
Figure3-12FlowcharttoSolveWhyRIPRoutesDon’tShowUpinaRoutingTableDebugsandVerification
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.
Figure3-14FlowcharttoSolveWhyRIPRoutesDon’tShowUpinaRoutingTableDebugsandVerification
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
Figure3-16showstheflowcharttofollowtosolvethisproblembasedonthiscause.
Figure3-16FlowcharttoSolveWhyRIPRoutesDon’tShowUpinaRoutingTableDebugsandVerification
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
R2#showiproute131.108.6.0Routingentryfor131.108.6.0/24Knownvia"rip",distance120,metric1
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
R2#showiproute131.108.6.0%Subnetnotintable
Figure3-18showstheflowcharttosolvethisproblem.
Figure3-18FlowcharttoSolveWhyRIPRoutesDon’tShowUpinaRoutingTableDebugsandVerification
ThemostlogicalwaytostarttroubleshootingthisproblemistolookatR1anddeterminewhetherR1isreceiving131.108.6.0/24.Example3-57showsthatRouterR1isreceivingRIProutesfor131.108.6.0/24.Example3-57R1’sRoutingTableHas131.108.6.0/24withaMetricof15(MaximumRIPMetric)
R1#showiproute131.108.6.0Routingentryfor131.108.6.0/24Knownvia"rip",distance120,metric15
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
Figure3-20showstheflowcharttofollowtosolvethisproblembasedonthiscause.
Figure3-20FlowcharttoSolveWhyRIPRoutesDon’tShowUpinaRoutingTableDebugsandVerification
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:
routerripnetwork200.1.0.0
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
R1#showinterfaceethernet0Ethernet0isup,lineprotocolisdownHardwareisLance,addressis0000.0c70.d31e(bia0000.0c70.d31e)Internetaddressis131.108.1.1/24
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
R2#showiproute131.108.2.0Routingentryfor131.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
SenderIsNotAdvertisingRIPRoutes—Cause:distribute-listoutIsBlockingtheRoute
distribute-listoutisusedtofilteranyroutesthatwillbesentoutaninterface.Ifareceiveriscomplainingaboutmissingroutesthatshouldbereceived,makesurethattheroutesarenotbeingfilteredthroughdistribute-listout.Ifthisisthecase,youmustmodifytheaccesslist.Figure3-24showstheflowcharttofollowtofixthisproblem.
Figure3-24FlowcharttoSolveWhytheSenderIsNotAdvertisingRIPRoutesDebugsandVerification
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
R2#showiproute131.108.2.0Routingentryfor131.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
SenderIsNotAdvertisingRIPRoutes—Cause:AdvertisedNetworkInterfaceIsDown
Thenetworkthatisbeingadvertisedmightbedown,andtheconnectedroutehasbeenremovedfromtheroutingtable.Inthissituation,RIPwillstartadvertisingthatnetworkwithaninfinitemetricof16;aftertheholddowntimerhasexpired,itwillnolongeradvertisethisnetwork.Assoonastheadvertisednetworkcomesup,RIPwillstartadvertisingitagaininitsupdates.Figure3-25showstheflowcharttofollowtofixthisproblem.
Figure3-25FlowcharttoSolveWhytheSenderIsNotAdvertisingRIPRoutesDebugsandVerification
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
R2#showiproute131.108.2.0Routingentryfor131.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
SenderIsNotAdvertisingRIPRoutes—Cause:OutgoingInterfaceIsDefinedPassive
AsituationmightariseinwhicharouterhasacompleteRIProutingtable,butitisnotadvertisingtootherroutersrunningRIP.ThisoccurswhennotallroutersinaRIPnetworkhavecompleteroutingtables,resultinginlackingIPconnectivityfromonepartofthenetworktotheother.Iftheoutgoinginterfaceisdefinedaspassive,itwillnotadvertiseanyRIPupdatesonthatinterface.Figure3-26showstheflowcharttofollowtofixthisproblem.
Figure3-26FlowcharttoSolveWhytheSenderIsNotAdvertisingRIPRoutesDebugsandVerification
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
routerripnetwork131.108.0.0
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.
Figure3-28FlowcharttoSolveWhytheSenderIsNotAdvertisingRIPRoutesDebugsandVerification
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.
Figure3-29FlowcharttoSolveWhytheSenderIsNotAdvertisingRIPRoutesDebugsandVerification
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
R2#showiproute131.108.2.0Routingentryfor131.108.2.0/24Knownvia"rip",distance120,metric1
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.
Figure3-31FlowcharttoSolveWhytheSenderIsNotAdvertisingRIPRoutesDebugsandVerification
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
R2#showiproute131.108.2.0Routingentryfor131.108.2.0/25Knownvia"rip",distance120,metric1RedistributingviaripLastupdatefrom131.108.1.1onEthernet0,00:00:07agoRoutingDescriptorBlocks:*131.108.1.1,from131.108.1.1,00:00:07ago,viaEthernet0Routemetricis1,trafficsharecountis1
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.
Figure3-34FlowcharttoSolveWhytheSenderIsNotAdvertisingRIPRoutesDebugsandVerification
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.
Figure3-37FlowcharttoSolveWhytheSenderIsNotAdvertisingRIPRoutesDebugsandVerification
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
R2#showiproute131.108.6.0%Subnetnotintable
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
R2#showiproute131.108.6.0Routingentryfor131.108.6.0/24Knownvia"rip",distance120,metric1
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-45showstheflowcharttofollowtofixthisproblem.
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-2showstheflowcharttofollowtosolvethisproblem.
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-3showstheflowcharttofollowtosolvethisproblem.
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
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:distribute-listinIsBlockingtheRoute
Adistributelistisafilteringmechanismforroutingupdates.Adistributelistcallsanaccesslistandcheckswhichnetworksaresupposedtobepermitted.Iftheaccesslistdoesnotcontainanynetwork,it
willbeautomaticallydenied.Adistributelistcanbeappliedonincomingroutingupdatesoroutgoingroutingupdates.Inthisexample,distribute-listinisconfigured,butbecausetheaccesslistdoesnotcontainthepermitstatementfor131.108.0.0,R2isnotinstallingthisrouteintheroutingtable.Figure5-4showstheflowcharttofollowtosolvethisproblem.
Figure5-4Problem-ResolutionFlowchartDebugsandVerification
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.
Figure5-5Problem-ResolutionFlowchartDebugsandVerification
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
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:AccessListBlockingIGRPBroadcast
Accesslistsareusedforthefilteringpurpose.Whenusedontheinboundinterface,alwaysmakesurethatitisnotblockingIGRPbroadcast,whichisusedforIGRProutingupdates.Ifthisbroadcastaddressisnotpermittedintheaccesslistthatisappliedontheinterfaceinbound,IGRPwillnotinstallanyroutesintheroutingtablelearnedonthatinterface.Figure5-6showstheflowcharttofollowtosolvethisproblem.
Figure5-6Problem-ResolutionFlowchartDebugsandVerification
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
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:DiscontiguousNetwork
Thedefinitionofadiscontiguousnetworkisoneinwhichtwosubnetsbelongingtothesamemajornetworkareseparatedbyanetworkorasubnetworkbelongingtoanothermajornetwork.Chapter4,“UnderstandingInteriorGatewayRoutingProtocol(IGRP),”providesadetaileddescriptionofwhydiscontiguousnetworksarenotsupportedinIGRP.
Figure5-7showsanexampleofadiscontiguousnetworkinwhich137.99.0.0isamajornetwork.Thesubnetsofthismajornetworkareseparatedbyanothermajornetwork,131.108.0.0.Thissituationproducesadiscontiguousnetworkproblem.
Figure5-7SampleDiscontiguousNetwork
Figure5-8showstheflowcharttofollowtosolvethisproblem.
Figure5-8Problem-ResolutionFlowchartDebugsandVerification
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
R2#showiproute137.99.2.0Routingentryfor137.99.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:InvalidSource
WhenRIPtellstheroutingtabletoinstalltheroute,itperformsasourcevaliditycheck.Thischeckmakessurethatthesourcewheretheupdateiscomingfromisalsoonthesamesubnetofthelocalreceivinginterface.Ifthesourceisnotonthesamesubnetasthelocalinterface,RIPignorestheupdateandwillnotinstallroutesintheroutingtablecomingfromthissourceaddress.Figure5-9showsthenetworkdiagramfortheinvalidsourceproblem.
Figure5-9NetworkwithanInvalidSource
AsFigure5-9illustrates,Router1’sSerial0interfaceisunnumberedtoLoopback0.Router2’sserialinterfaceisnumbered.WhenRouter2receivesanIGRPupdatefromRouter1,itcomplainsaboutthesourcevalidity.Figure5-10showstheflowcharttofollowtosolvethisproblem.
Figure5-10Problem-ResolutionFlowchartDebugsandVerification
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.
Figure5-12Problem-ResolutionFlowchartDebugsandVerification
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
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:Sender’sASMismatch
IGRPupdatescarrytheASnumber.WhenareceiverreceivesanIGRPupdateandtheASnumberofthesenderdoesnotmatchwithitsownASnumber,IGRPignoresthatupdate.Asaresult,noIGRProutesareinstalledintheroutingtable.MultipleIGRPprocessescanberununderdifferentASnumbers.Theseprocessesareindependentofeachother.Figure5-13showstheflowcharttofollowtosolvethisproblem.
Figure5-13Problem-ResolutionFlowchartDebugsandVerification
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
Figure5-15showstheflowcharttofollowtosolvethisproblem.
Figure5-15Problem-ResolutionFlowchartDebugsandVerification
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.
Figure5-17Problem-ResolutionFlowchartDebugsandVerification
Example5-42showsthecurrentconfigurationforR1.Example5-42CurrentConfigurationforR1inFigure5-16
R1#interfaceLoopback0ipaddress131.108.2.1255.255.255.0!
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.
Figure5-18Problem-ResolutionFlowchartDebugsandVerification
Example5-45verifiesthattheinterfaceEthernet0isdown.Example5-45showinterfaceCommandOutputRevealsThattheInterfaceIsDown
R1#showinterfaceethernet0Ethernet0isup,lineprotocolisdownHardwareisLance,addressis0000.0c70.d31e(bia0000.0c70.d31e)Internetaddressis131.108.1.1/24
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
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
SenderIsNotAdvertisingIGRPRoutes—Cause:distribute-listoutIsBlockingtheRoute
distribute-listoutisusedtofilteranyroutesthataregoingtobesentoutonaninterface.Ifareceiveriscomplainingaboutamissingroutethatshouldhavebeenreceived,makesurethatitisnotbeingfilteredthroughdistribute-listout.Ifitis,theassociatedaccesslistmustbemodified.Figure5-19showstheflowcharttofollowtofixthisproblem.
Figure5-19Problem-ResolutionFlowchartDebugsandVerification
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
R1#interfaceLoopback0ipaddress131.108.2.1255.255.255.0!
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
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:AdvertisedNetworkInterfaceIsDown
Asituationcouldariseinwhichthenetworkthatisbeingadvertisedisdownandtheconnectedroutehasbeenremovedfromtheroutingtable.Inthissituation,IGRPwillstartadvertisingthatnetworkwithaninfinitemetricandaftertheholddowntimerexpires,itwillnolongeradvertisethisnetwork.Assoonastheadvertisednetworkcomesup,IGRPwillstartadvertisingitagaininitsupdates.Figure5-20showstheflowcharttofollowtofixthisproblem.
Figure5-20Problem-ResolutionFlowchartDebugsandVerification
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
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:OutgoingInterfaceIsDefinedasPassive
WhenaninterfaceisdefinedaspassiveunderIGRP,IGRPwillreceiveupdatesonthatinterfacebutwillnotsendanyupdates.Thepassive-interfacecommandisusedtoavoidsendingunnecessaryupdatestoaneighborthatdoesnotneedtoreceiveanyIGRPupdates,suchasasmallroutethatisattheedge.Asimpledefaultgatewayisenoughinformationforthatroutertotalktotheoutsideworld.Besuretousethepassive-interfacecommandwhereneeded;otherwise,undesiredresultsmightoccur.Figure5-21showstheflowcharttofollowtofixthisproblem.
Figure5-21Problem-ResolutionFlowchartDebugsandVerification
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
Figure5-23showstheflowcharttofollowtosolvethisproblem.
Figure5-23Problem-ResolutionFlowchartDebugsandVerification
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
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
SenderIsNotAdvertisingIGRPRoutes—Cause:MisconfiguredneighborStatement
Inanonbroadcastenvironment,IGRPprovidesaunicastmethodofsendingIGRPupdates.TosendunicastIGRPupdates,youmustconfiguretheneighborstatementcarefully.Iftheneighboraddressismisconfiguredintheneighborstatement,IGRPwillnotsendtheunicastupdatetothewrongneighbororanonexistentneighbor.Figure5-24showstheflowcharttofollowtosolvethisproblem.
Figure5-24Problem-ResolutionFlowchartDebugsandVerification
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
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
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
Figure5-26showstheflowcharttofollowtofixthisproblem.
Figure5-26Problem-ResolutionFlowchartDebugsandVerification
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
R1#interfaceLoopback0ipaddress131.108.2.1255.255.255.0!
interfaceEthernet0ipaddress131.108.1.1255.255.255.0!routerigrp1network131.108.0.0
Example5-67showstheroutingtableentryofRouterR2aftercorrectingtheproblem.Example5-67R2’sRoutingTableVerifiesThattheMismatchedSubnetMaskProblemHasBeenResolved
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
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.
Figure5-29Problem-ResolutionFlowchartDebugsandVerification
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
Figure5-31showstheflowcharttofollowtofixthisproblem.
Figure5-31Problem-ResolutionFlowchartDebugsandVerification
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.
Figure5-33Problem-ResolutionFlowchartDebugsandVerification
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
R2#showiproute131.108.6.0%Subnetnotintable
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
Figure5-35showstheflowcharttofollowtofixthisproblem.
Figure5-35Problem-ResolutionFlowchartDebugsandVerification
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
access-list100denytcpanyanyaccess-list100permitipanyanydialer-list1protocoliplist100
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.
Figure5-36Problem-ResolutionFlowchartDebugsandVerification
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
Figure5-38showstheflowcharttofollowtosolvethisproblem.
Figure5-38Problem-ResolutionFlowchartDebugsandVerification
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
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
Figure5-40showstheflowcharttofollowtosolvethisproblem.
Figure5-40Problem-ResolutionFlowchartDebugsandVerification
Example5-97showstheroutingtableentryonR1showingthatR1isusingonlyonepathtoreach155.155.0.0/16.Example5-97R1RoutingTableEntryShowsThatOnlyaSinglePathIsUsedtoReachtheDestinationNetwork
R1#showiproute155.155.0.0Routingentryfor155.155.0.0/16Knownvia"igrp1",distance100,metric8976Redistributingviaigrp1Advertisedbyigrp1(selforiginated)Lastupdatefrom131.108.6.2onSerial2,00:00:03agoRoutingDescriptorBlocks:*131.108.6.2,from131.108.6.2,00:00:03ago,viaSerial2Routemetricis8976,trafficsharecountis1Totaldelayis25000microseconds,minimumbandwidthis1544KbitReliability255/255,minimumMTU1500bytesLoading1/255,Hops0
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
RouterA#interfaceethernet0ipaddress192.168.3.33255.255.255.240interfaceserial0ipaddress10.1.1.1255.255.255.0routereigrp1network192.168.3.0network10.0.0.0
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
RouterA#interfaceethernet0ipaddress172.16.3.1255.255.255.0interfaceserial0ipaddress10.1.1.1255.255.255.0routereigrp1network172.16.0.0network10.0.0.0
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
RouterA#showiproute172.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
RouterA#showiproute172.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
RouterA#showiproute172.16.4.0
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:anotherRouter(point-to-point)(LinkID)NeighboringRouterID:141.108.3.1(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.
Figure9-2Problem-ResolutionFlowchartDebugsandVerification
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.
Figure9-3Problem-ResolutionFlowchartDebugsandVerification
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
R2#showipospfneighbor
NeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/DR00:00:39131.108.1.1Ethernet0
OSPFNeighborListIsEmpty—Cause:InterfaceIsDefinedasPassiveUnderOSPF
WhenaninterfaceisdefinedaspassiveunderrouterOSPF,itsuppressesOSPFHellos.ThismeansthatOSPFdoesnotsendorreceiveanyHellosonsuchinterfaces.Therefore,noadjacencyisformed.Figure9-4showsaflowcharttosolvethisproblem.
Figure9-4Problem-ResolutionFlowchartDebugsandVerification
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
R2#showipospfneighbor
NeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/DR00:00:37131.108.1.1Ethernet0
OSPFNeighborListIsEmpty—Cause:AccessListBlockingOSPFHellosonBothSides
OSPFsendsitsHelloonamulticastaddressof224.0.0.5.AllOSPF-enabledinterfaceslistentothisaddress.Itisverycommontoimplementanaccesslistforsecuritymeasuresattheinterfacelevel.BesuretopermitOSPFmulticastHellos’addressesintheaccesslistinthissituation;otherwise,theaccesslistmightblocktheOSPFmulticastaddressunknowinglyandpreventOSPFfromformingneighborsonthatinterface.ThissituationhappensonlywhentheaccesslistisblockingHellosonbothrouters.IfonlyonesideisblockingOSPFHellos,theoutputofshowipospfneighborwillindicatethattheneighborisstuckintheINITstate.Thiscaseisdiscussedlaterinthischapter.Figure9-5showstheflowcharttofollowtosolvethisproblem.
Figure9-5Problem-ResolutionFlowchartDebugsandVerification
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
R2#showipospfneighbor
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.
Figure9-6Problem-ResolutionFlowchartDebugsandVerification
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
R2#showipospfneighbor
NeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/DR00:00:31131.108.1.1Ethernet0
OSPFNeighborListIsEmpty—Cause:MismatchedHello/DeadIntervals
OSPFneighborsexchangeHellopacketsperiodicallytoformandmaintainneighborrelationships.OSPFadvertisestherouter’sHelloanddeadintervalsintheHellopackets.Theseintervalsmustmatchwiththeneighbor’s;otherwise,anadjacencywillnotform.Figure9-7showstheflowcharttofollowtosolvethisproblem.
Figure9-7Problem-ResolutionFlowchartDebugsandVerification
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
R2#interfaceEthernet0
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
R2#showipospfneighbor
NeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/DR00:00:32131.108.1.1Ethernet0
OSPFNeighborListIsEmpty—Cause:MismatchedAuthenticationType
OSPFusestwotypesofauthentication,plain-text(Type1)andMD5(Type2).Type0iscallednullauthentication.Iftheplain-textauthenticationtypeisenabledononeside,theothersidemustalsohaveplain-textauthentication.OSPFwillnotformanadjacencyunlessbothsidesagreeonthesameauthenticationtype.Inonesituation,onesideisconfiguredforplain-textorMD5authenticationbuttheothersideisnotconfiguredforanyauthentication.ThissituationcreatesacaseofanOSPFneighborbeingstuckinINIT,whichisdiscussedlaterinthischapter.Figure9-8showstheflowcharttofollowtosolvethisproblem.
Figure9-8Problem-ResolutionFlowchartDebugsandVerification
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
R2#showipospfneighbor
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.
Figure9-9Problem-ResolutionFlowchartDebugsandVerification
Example9-27showstheoutputofdebugipospfadj,whichshowsthatthereisanauthenticationkeymismatch.Example9-27DetectinganAuthenticationKeyMismatch
R2#debugipospfadjOSPFadjacencyeventsdebuggingisonR2#OSPF:Rcvpktfrom131.108.1.1,Ethernet0:MismatchAuthenticationKey-ClearText
Example9-28showstheconfigurationofR1andR2.NotethatR2isnotconfiguredforanyauthenticationkey,whereasR1isconfiguredwithanauthenticationkeythatiscausingthisproblem.Example9-28ConfigurationofR1andR2
R2#interfaceEthernet0ipaddress131.108.1.2255.255.255.0
R1#interfaceEthernet0ipaddress131.108.1.1255.255.248.0ipospfauthentication-keyCisco
Solution
Tosolvethisproblem,makesurethatbothsideshavethesamekindofauthenticationkey.Iftheproblemstillexists,retypetheauthenticationkey;thereisapossibilityofanaddedspacecharacterbeforeoraftertheauthenticationkey.Example9-29showstheoutputofshowipospfneighborafterfixingthisproblem.Example9-29VerifyingThatOSPFNeighborsAreUpAfterUsingIdenticalAuthenticationKeys
R2#showipospfneighbor
NeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/DR00:00:32131.108.1.1Ethernet0
OSPFNeighborListIsEmpty—Cause:MismatchedAreaID
OSPFsendsareainformationintheHellopackets.Ifbothsidesdonotagreethattheyaremembersofacommonarea,noOSPFadjacencywillbeformed.TheareainformationisapartoftheOSPFprotocolheader.Figure9-10showstheflowcharttofollowtosolvethisproblem.
Figure9-10Problem-ResolutionFlowchartDebugsandVerification
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
R1#interfaceEthernet0ipaddress131.108.1.1255.255.255.0!routerospf1network131.108.0.00.0.255.255area0
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
R2#showipospfneighbor
NeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/DR00:00:32131.108.1.1Ethernet0
OSPFNeighborListIsEmpty—Cause:MismatchedStub/Transit/NSSAAreaOptions
WhenOSPFexchangesHellopacketswithaneighbor,oneofthethingsthatitexchangesintheHellopacketisanoptionalcapabilityrepresentedby8bits.OneoftheoptionfieldsisfortheEbit,whichistheOSPFstubareaflag.WhentheEbitissetto0,theareawithwhichtherouterisassociatedisastubarea,andnoexternalLSAsareallowedinthisarea.IfonesidehastheEbitsetto0andtheothersidedoesn’t,OSPFadjacencyisnotformed.Thisiscalledanoptionalcapabilitymismatch.Onesidesaysthatitcanallowexternalroutes,andtheothersidesaysthatitcannotallowexternalroutes,soOSPFneighborrelationshipsarenotformed.Figure9-11showstheflowcharttofollowtosolvethisproblem.
Figure9-11Problem-ResolutionFlowchartDebugsandVerification
Example9-35showstheconfigurationofRoutersR1andR2.R2’sconfigurationshowsthatarea1isconfiguredasastub,butR1’sarea1isconfiguredasastandardarea.Example9-35AreaConfigurationforR1andR2
R2#interfaceEthernet0ipaddress131.108.1.2255.255.255.0!routerospf1area1stubnetwork131.108.0.00.0.255.255area1
R1#interfaceEthernet0ipaddress131.108.1.1255.255.255.0!routerospf1network131.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
R2#showipospfneighbor
NeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/DR00:00:32131.108.1.1Ethernet0
OSPFNeighborListIsEmpty—Cause:OSPFAdjacencyOverSecondaryIPAddress
ThisisaverycommonprobleminwhichacustomermighthaveoneClassCaddressonaLANsegment.Whenthecustomerrunsoutofaddressspace,hegetsanotherClassCaddressandassignsthenewaddressasasecondaryaddressunderthesameinterface.EverythingworksfineuntiltworoutersmustexchangeOSPFHellos/updatesandonerouter’sprimaryIPaddressisassignedasthesecondaryIPaddressontheotherside,asdepictedinthenetworkinFigure9-12.ThetworoutersareconnectedthroughaLayer2switch.
Figure9-12TwoRoutersConnectedThroughaSwitch,withOneSide’sPrimaryInterfaceIPAddress
IdenticaltotheOtherSide’sSecondary
Figure9-13showstheflowcharttofollowtosolvethisproblem.
Figure9-13Problem-ResolutionFlowchartDebugsandVerification
Example9-40showstheconfigurationofbothR1andR2.TheconfigurationillustratesthatR2hasaprimaryandasecondaryaddressconfiguredonitsEthernetinterface,andthatthesubnetnumberusedfortheprimaryaddressonR1isforthesecondaryaddressonR2.Example9-40R2’sFastEthernet0/0InterfaceSecondaryAddressConfigurationMatchesR1’sEthernet0InterfacePrimaryAddressConfiguration
R2#interfaceFastEthernet0/0ipaddress131.108.1.2255.255.255.0secondaryipaddress131.108.4.2255.255.255.0
R1#interfaceEthernet0ipaddress131.108.1.1255.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
R2#showipospfneighbor
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
Figure9-16showstheflowcharttofollowtosolvethisproblem.
Figure9-16Problem-ResolutionFlowchartDebugsandVerification
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
R2#showipospfneighbor
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
Figure9-18showstheflowcharttofollowtosolvethisproblem.
Figure9-18Problem-ResolutionFlowchartDebugsandVerification
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
R2#showipospfneighbor
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.
Figure9-19Problem-ResolutionFlowchartDebugsandVerification
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
R2#interfaceSerial0ipaddress131.108.1.2255.255.255.0encapsulationframe-relayframe-relaymapip131.108.1.116
Solution
Example9-53showsthemodifiedconfigurationsforR1andR2thatfixesthisproblem.Again,thekeywordbroadcastmustbeenabledonbothsides.Ifitisenabledononlyoneside,itwillproduceastuckinINITproblem,whichisdiscussedlaterinthischapter.Example9-53AddingthebroadcastKeywordtotheframe-relaymapStatementsforR1andR2
R1#interfaceSerial0ipaddress131.108.1.1255.255.255.0encapsulationframe-relayipospfnetworkbroadcastframe-relaymapip131.108.1.216broadcast
R2#interfaceSerial0ipaddress131.108.1.2255.255.255.0encapsulationframe-relayipospfnetworkbroadcastframe-relaymapip131.108.1.116broadcast
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
R2#showipospfneighbor
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
R2#showipospfneighbor
NeighborIDPriStateDeadTimeAddressInterfaceN/A0ATTEMPT/DROTHER00:01:57131.108.1.1Serial0
OSPFNeighborStuckinATTEMPT—Cause:MisconfiguredneighborStatement
OSPFsendsaunicastpacketonNBMAinterfacesifneighborstatementsmanuallyareconfiguredundertherouterospfconfiguration.ThisneighborstatementdefinesthedestinationIPaddressoftheOSPFpacket.Iftheneighborstatementisnotcorrect,OSPFcannotsendthepackettotherightneighbor.Itisverycommontomakeaconfigurationmistake,soiftheneighbordoesn’tcomeupafterawhile,checktheneighborstatementeitherintheOSPFconfigurationorintheoutputofshowipospfneighbor.IftheneighborshowsinATTEMPTstate,thisrouteristryingtocontactaneighborbysendingtheHellopacket,butithasnotreceivedanyresponsefromtheneighbor.Figure9-21showstheflowcharttofollowtosolvethisproblem.
Figure9-21Problem-ResolutionFlowchartDebugsandVerification
InExample9-57,theoutputofshowipospfneighborindicatesthattheneighborisstuckinATTEMPT.Theneighborstatementisconfigured,buttheneighborIPaddressisnotcorrect.Insteadof131.108.1.1(asshownintheFigure9-20),itshows131.108.1.11.Example9-57showipospfneighborCommandOutputIndicatesThattheNeighborIsStuckinATTEMPT
R2#showipospfneighbor
NeighborIDPriStateDeadTimeAddressInterfaceN/A0ATTEMPT/DROTHER00:01:57131.108.1.11Serial0
Example9-58showstheconfigurationofR2,indicatingthattheneighborstatementalsoiswronglyconfigured.Example9-58R2’sConfigurationHasanIncorrectneighborStatement
R2#routerospf1network131.108.0.00.0.255.255area1neighbor131.108.1.11priority1
Solution
Tofixthisproblem,configuretheproperneighborstatementwiththeproperIPaddress.Example9-59
showsthenewconfigurationofR2thatfixesthisproblem.Example9-59ConfiguringtheProperneighborStatementonR2toCorrecttheProblem
R2#routerospf1network131.108.0.00.0.255.255area1neighbor131.108.1.1priority1
Example9-60showstheoutputofshowipospfneighborafterfixingtheproblem.Example9-60VerifyingThattheNewneighborStatementHasResolvedtheIssue
R2#showipospfneighbor
NeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/DR00:01:42131.108.1.1Serial0
OSPFNeighborStuckinATTEMPT—Cause:UnicastConnectivityIsBrokenonNBMA
OSPFsendsunicastHellosoverNBMAinterfacesifneighborstatementsmanuallyareconfigured.Iftheunicastconnectivityisbroken,OSPFwillneverformanyadjacencies.OSPFtriestocontactneighborseveryHellointerval(thatis,every30seconds)bydefaultoverNBMAinterfaces.Ifitdoesnotreceiveanyreplyfromtheneighbor,itwillshowthattheneighborisstuckinATTEMPT.Manypossiblereasonscanexistforbrokenunicastconnectivity.Youshouldconsiderthefollowingcausesforabrokenunicastconnectivity,assumingthatLayer2isup:•AwrongDLCIorVPI/VCImappingexistsinaFrameRelayorATMswitch,respectively.•Anaccesslistisblockingtheunicast.•NATistranslatingtheunicast.
Figure9-22showstheflowcharttofollowtosolvethisproblem.
Figure9-22Problem-ResolutionFlowchartDebugsandVerification
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
R2#showipospfneighbor
NeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/DR00:01:42131.108.1.1Serial0
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
R2#showipospfneighbor
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.
Figure9-23Problem-ResolutionFlowchartDebugsandVerification
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
R2#showipospfneighbor
NeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/DR00:00:39131.108.1.1Ethernet0
OSPFNeighborStuckinINIT—Cause:MulticastCapabilitiesAreBrokenonOneSide(6500SwitchProblem)
ThisisaspecificsituationthatisvalidonlyinthecaseofaCatalyst6500switchwiththemultilayerswitchfeaturecard(MSFC).TheproblemisthatonesideissendingOSPFHellosthattheothersidedoesnotreceive.ThenetworksetupinFigure9-24showshowthiscanbeaproblem.
Figure9-24NetworkSetupVulnerabletoOSPFNeighborStuckinINITProblemBecauseofBrokenMulticastCapabilities
Thissituationisproducedwhenthecommandsetprotocolfilterenabledisenteredonthe6500switch.Bydefault,theprotocolfilterisdisabled.EnablingthiscommandbeginsalteringthemulticastframetoandfromMSFCandportadapterwithintheFlexWanmoduleofthe6500switch.Figure9-25showstheflowcharttofollowtosolvethisproblem.
Figure9-25Problem-ResolutionFlowchartDebugsandVerification
Example9-68showstheoutputofshowipospfneighbor.TheneighborisstuckinINIT,andtheswitchinthemiddleis6500withMSFC,asshowninFigure9-24.Example9-68OSPFNeighborStuckinINITState
R2#showipospfneighbor
NeighborIDPriStateDeadTimeAddressInterface131.108.2.11xINIT/-00:00:33131.108.1.1FastEthernet0/0
Solution
Tofixthisproblem,disabletheprotocolfilteron6500switchasfollows:CAT6k(enable)setprotocolfilterdisable
Example9-69showstheOSPFneighborsinFULLstateafterfixingthisproblem.Example9-69VerifyingThattheOSPFNeighborsAreUpAftertheProtocolFilteronthe6500SwitchHasBeenDisabled
R2#showipospfneighbor
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.
Figure9-26Problem-ResolutionFlowchartDebugsandVerification
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
R2#showipospfneighbor
NeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/DR00:00:33131.108.1.1Ethernet0
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
Figure9-28showstheflowcharttofollowtosolvethisproblem.
Figure9-28Problem-ResolutionFlowchartDebugsandVerification
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
R1#interfaceSerial0ipaddress131.108.1.1255.255.255.0encapsulationframe-relayframe-relaymapip131.108.1.216
R2#interfaceSerial0ipaddress131.108.1.2255.255.255.0encapsulationframe-relayframe-relaymapip131.108.1.116broadcast
Solution
Tofixthisproblem,makesurethatthebroadcastkeywordisconfiguredinallframe-relaymapordialer-mapstatements.Example9-76showsthenewconfigurationsofR1andR2tofixtheproblem.Example9-76Correctingtheframe-relaymapStatementonR1toIncludethebroadcastKeyword
R1#interfaceSerial0ipaddress131.108.1.1255.255.255.0encapsulationframe-relayipospfnetworkbroadcastframe-relaymapip131.108.1.216broadcast
R2#interfaceSerial0ipaddress131.108.1.2255.255.255.0encapsulationframe-relayipospfnetworkbroadcastframe-relaymapip131.108.1.116broadcast
Example9-77showsthatOSPFadjacencyisformedacrosstheserialinterfaceusingFrameRelayencapsulationafterfixingthisproblem.Example9-77showipospfneighborCommandOutputIndicatesThattheProblemHasBeenResolved
R2#showipospfneighbor
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.
Figure9-29Problem-ResolutionFlowchartDebugsandVerification
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
R2#showipospfneighbor
NeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/DR00:00:32131.108.1.1Serial0
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
Figure9-31showstheflowcharttofollowtosolvethisproblem.
Figure9-31Problem-ResolutionFlowchartDebugsandVerification
Example9-82showstheoutputofshowipospfneighbor.NoneighborsonthisinterfaceareinFULLstatewitheachother.Example9-82showipospfneighborCommandOutputDeterminesThatNeighborsArein2-WAYStatewithEachOther
R2#showipospfneighbor
NeighborIDPriStateDeadTimeAddressInterface131.108.2.102-WAY/DROTHER00:00:32131.108.1.1Ethernet0
Example9-83showsthatbothR1andR2Ethernetinterfacesareconfiguredwithpriority0.Example9-83PrioritySettingsonEthernet0InterfacesofR1andR2
R1#interfaceEthernet0ipaddress131.108.1.1255.255.255.0ipospfpriority0
R2#interfaceEthernet0
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
R2#showipospfneighbor
NeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/DR00:00:32131.108.1.1Ethernet0
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
R2#showipospfneighbor
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.
Figure9-33Problem-ResolutionFlowchartDebugsandVerification
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.
Figure9-35Problem-ResolutionFlowchartDebugsandVerification
Example9-92showstheoutputofshowipospfneighboronR1indicatingthattheneighborisstuckintheEXSTARTstate.Example9-92showipospfneighborCommandOutputShowsThatR1IsintheEXSTARTState
R2#showipospfneighbor
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
Figure9-37showstheflowcharttofollowtosolvethisproblem.
Figure9-37Problem-ResolutionFlowchartDebugsandVerification
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.
Figure9-38showstheflowcharttofollowtosolvethisproblem.
Figure9-38Problem-ResolutionFlowchartDebugsandVerification
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
Typeescapesequencetoabort.Sending5,100-byteICMPEchosto131.108.1.2,timeoutis2seconds:.....Successrateis0percent(0/5)
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
Typeescapesequencetoabort.Sending5,100-byteICMPEchosto131.108.1.1,timeoutis2seconds:.....Successrateis0percent(0/5)
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
Figure9-41showstheflowcharttofollowtosolvethisproblem.
Figure9-41Problem-ResolutionFlowchartDebugsandVerification
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
R2#showipospfneighbor
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.
Figure9-43Problem-ResolutionFlowchartDebugsandVerification
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
R2#showipospfneighborNeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/-00:00:32131.108.1.1Serial0
OSPFNeighborStuckinLOADING—Cause:Link-StateRequestPacketIsCorrupted
Whenalink-staterequestpacketiscorrupted,theneighbordiscardsthepacketandthelocalrouterneverreceivestheresponsefromtheneighbor.ThiscausestheOSPFneighbortobestuckintheLOADINGstate.Link-staterequestpacketsusuallybecomecorruptedbecauseofthefollowingreasons:
•Adevicebetweentheneighbors,suchasaswitch,iscorruptingthepacket.•Thesendingrouter’spacketisinvalid.Inthiscase,eitherthesendingrouter’sinterfaceisbadortheerroriscausedbyasoftwarebug.•Thereceivingrouteriscalculatingthewrongchecksum.Inthiscase,eitherthereceivingrouter’sinterfaceisbadortheerroriscausedbyasoftwarebug.Thisistheleastlikelycauseofthiserrormessage.
Figure9-44showstheflowcharttofollowtosolvethisproblem.
Figure9-44Problem-ResolutionFlowchartDebugsandVerification
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
R2#showipospfneighborNeighborIDPriStateDeadTimeAddressInterface131.108.2.11FULL/-00:00:32131.108.1.1Serial0
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.
Figure9-46Problem-ResolutionFlowchartDebugsandVerification
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
Linkconnectedto:anotherRouter(point-to-point)(LinkID)NeighboringRouterID:131.108.1.2(LinkData)RouterInterfaceaddress:131.108.1.1NumberofTOSmetrics:0TOS0Metrics:64
Linkconnectedto:aStubNetwork(LinkID)Network/subnetnumber:131.108.1.0(LinkData)NetworkMask:255.255.255.0NumberofTOSmetrics:0TOS0Metrics:0
Linkconnectedto:aStubNetwork(LinkID)Network/subnetnumber:131.108.2.0(LinkData)NetworkMask:255.255.255.0NumberofTOSmetrics:0TOS0Metrics:10
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
R1#routerospf1network131.108.1.00.0.0.255area0network131.108.2.00.0.0.255area0
network131.108.3.00.0.0.255area0
Example9-123showstherouterLSAofR1afterfixingthisproblem.TherouterLSAshows131.108.3.0nowasastublink.Example9-123Network131.108.3.0/24NowAppearsintheOSPFDatabase
1#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:48NumberofLinks:2
Linkconnectedto:anotherRouter(point-to-point)(LinkID)NeighboringRouterID:131.108.1.2(LinkData)RouterInterfaceaddress:131.108.1.1NumberofTOSmetrics:0TOS0Metrics:64
Linkconnectedto:aStubNetwork(LinkID)Network/subnetnumber:131.108.1.0(LinkData)NetworkMask:255.255.255.0NumberofTOSmetrics:0TOS0Metrics:0R
Linkconnectedto:aStubNetwork(LinkID)Network/subnetnumber:131.108.2.0(LinkData)NetworkMask:255.255.255.0NumberofTOSmetrics:0TOS0Metrics:10
Linkconnectedto:aStubNetwork(LinkID)Network/subnetnumber:131.108.3.0(LinkData)NetworkMask:255.255.255.0NumberofTOSmetrics:0TOS0Metrics:10
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.
Figure9-47Problem-ResolutionFlowchartDebugsandVerification
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
R2#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:48NumberofLinks:2
Linkconnectedto:anotherRouter(point-to-point)(LinkID)NeighboringRouterID:131.108.1.2(LinkData)RouterInterfaceaddress:131.108.1.1NumberofTOSmetrics:0TOS0Metrics:64
Linkconnectedto:aStubNetwork(LinkID)Network/subnetnumber:131.108.1.0(LinkData)NetworkMask:255.255.255.0NumberofTOSmetrics:0TOS0Metrics:0
Linkconnectedto:aStubNetwork(LinkID)Network/subnetnumber:131.108.2.0(LinkData)NetworkMask:255.255.255.0NumberofTOSmetrics:0TOS0Metrics:10
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
Figure9-49showstheflowcharttofollowtosolvethisproblem.
Figure9-49Problem-ResolutionFlowchartDebugsandVerification
Example9-129showstherouterLSAinformationofR1.TheLSAshowsthat131.108.3.0/24isnotincludedinthedatabase.R1generatestherouterLSAforarea2,butbecausethesecondaryaddressistheonlyaddressinarea2,thenumberofthelinkis0.Thisisbecausethesecondaryinterfaceaddresscannotbeputintoaseparateareathantheprimaryinterfaceaddress.Example9-129DisplayingR1’sRouterLSAInformation
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:48NumberofLinks:2
Linkconnectedto:anotherRouter(point-to-point)(LinkID)NeighboringRouterID:131.108.1.2(LinkData)RouterInterfaceaddress:131.108.1.1NumberofTOSmetrics:0TOS0Metrics:64
Linkconnectedto:aStubNetwork(LinkID)Network/subnetnumber:131.108.1.0(LinkData)NetworkMask:255.255.255.0NumberofTOSmetrics:0TOS0Metrics:0
Linkconnectedto:aStubNetwork(LinkID)Network/subnetnumber:131.108.2.0(LinkData)NetworkMask:255.255.255.0NumberofTOSmetrics:0TOS0Metrics:10
RouterLinkStates(Area2)
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#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#
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
Figure9-51showstheflowcharttofollowtosolvethisproblem.
Figure9-51Problem-ResolutionFlowchartDebugsandVerification
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
OSPFRouterwithID(131.108.3.1)(ProcessID1)
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
Figure9-53showstheflowcharttofollowtosolvethisproblem.
Figure9-53Problem-ResolutionFlowchartDebugsandVerification
Example9-135showsthatR1isnotoriginatingasummary.Example9-135R1IsNotOriginatingaSummaryRoute
R1#showipospfdatabasesummary
OSPFRouterwithID(131.108.3.1)(ProcessID1)
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
R1#routerospf1network131.108.1.00.0.0.255area2network131.108.3.00.0.0.255area0
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
OSPFRouterwithID(131.108.3.1)(ProcessID1)
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
Figure9-55showstheflowcharttofollowtosolvethisproblem.
Figure9-55Problem-ResolutionFlowchartDebugsandVerification
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
OSPFRouterwithID(131.108.4.1)(ProcessID1)
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
OSPFRouterwithID(131.108.3.1)(ProcessID1)
RouterLinkStates(Area0)
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
Linkconnectedto:aStubNetwork(LinkID)Network/subnetnumber:131.108.3.0(LinkData)NetworkMask:255.255.255.0NumberofTOSmetrics:0TOS0Metrics:1
Linkconnectedto:aStubNetwork(LinkID)Network/subnetnumber:131.108.1.0(LinkData)NetworkMask:255.255.255.0NumberofTOSmetrics:0TOS0Metrics:1
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.
Figure9-56Problem-ResolutionFlowchartDebugsandVerification
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
OSPFRouterwithID(131.108.2.1)(ProcessID1)
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
OSPFRouterwithID(131.108.2.1)(ProcessID1)
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#
R1#showipospfdatabasenssa-external132.108.4.0
OSPFRouterwithID(131.108.2.1)(ProcessID1)
Type-7ASExternalLinkStates(Area2)
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
Figure9-58showstheflowcharttofollowtosolvethisproblem.
Figure9-58Problem-ResolutionFlowchartDebugsandVerification
Example9-152showstheoutputofshowipospfdatabasenssa-externalonroute132.108.4.0,indicatingthatR2isgeneratingType7LSAs.Example9-152showipospfdatabasenssa-externalCommandOutputIndicatesThatType7IsBeing
Generated
R2#showipospfdatabasenssa-external132.108.4.0
OSPFRouterwithID(131.108.1.2)(ProcessID1)
Type-7ASExternalLinkStates(Area2)
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
R2#showipospfdatabaseexternal132.108.4.0
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
R1#showipospfdatabaseexternal132.108.3.0
OSPFRouterwithID(131.108.2.1)(ProcessID1)
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#
R1#showipospfdatabaseexternal132.108.4.0
OSPFRouterwithID(131.108.2.1)(ProcessID1)
Type-5ASExternalLinkStates
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
R2#showipospfdatabaseexternal132.108.3.0
OSPFRouterwithID(131.108.1.2)(ProcessID1)
+Type-5ASExternalLinkStates
LSage:1161Options:(NoTOS-capability,DC)LSType:ASExternalLinkLinkStateID:132.108.3.0(ExternalNetworkNumber)AdvertisingRouter:131.108.1.2LSSeqNumber:80000001Checksum:0x550Length:36NetworkMask:/24MetricType:2(Largerthananylinkstatepath)TOS:0Metric:1ForwardAddress:0.0.0.0ExternalRouteTag:1
R1#
R1#showipospfdatabaseexternal132.108.4.0
OSPFRouterwithID(131.108.1.2)(ProcessID1)
Type-5ASExternalLinkStates
LSage:1161Options:(NoTOS-capability,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
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
Figure9-60showstheflowcharttofollowtosolvethisproblem.
Figure9-60Problem-ResolutionFlowchartDebugsandVerification
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#showipospfdatabaseexternal0.0.0.0
OSPFRouterwithID(131.108.2.1)(ProcessID1)
R1#
R1#showipospfdatabaseexternal132.108.3.0
OSPFRouterwithID(131.108.2.1)(ProcessID1)
Type-5ASExternalLinkStates
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#showipospfdatabaseexternal132.108.4.0
OSPFRouterwithID(131.108.2.1)(ProcessID1)
Type-5ASExternalLinkStates
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
R1#showipospfdatabaseexternal0.0.0.0
OSPFRouterwithID(131.108.2.1)(ProcessID1)
Type-5ASExternalLinkStates
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.
Figure9-61Problem-ResolutionFlowchart
DebugsandVerification
Example9-168showsthatR1isnotgeneratingthedefaultrouteinOSPFdatabasebecausenodefaultrouteispresentintheroutingtable.RefertoFigure9-56forthenetworksetup.Example9-168R1IsNotGeneratingtheDefaultRoute
R1#showiproute0.0.0.0%NetworknotintableR1#
R1#showipospfdatabaseexternal0.0.0.0
OSPFRouterwithID(131.108.2.1)(ProcessID1)
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
R1#showipospfdatabaseexternal0.0.0.0
OSPFRouterwithID(131.108.2.1)(ProcessID1)
Type-5ASExternalLinkStates
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
R1#showipospfdatabaseexternal0.0.0.0
OSPFRouterwithID(131.108.2.1)(ProcessID1)
Type-5ASExternalLinkStates
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
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.
Figure9-62NetworkSetupUsedtoProduceThisProblem
Figure9-63showstheflowcharttofollowtosolvethisproblem.
Figure9-63Problem-ResolutionFlowchartDebugsandVerification
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#showipospfdatabaseexternal0.0.0.0
OSPFRouterwithID(131.108.2.1)(ProcessID1)
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.
Figure9-64NetworkSetupUsedtoProduceThisProblem
Figure9-65showstheflowcharttofollowtosolvethisproblem.
Figure9-65Problem-ResolutionFlowchartDebugsandVerification
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#showipospfdatabaseexternal0.0.0.0
OSPFRouterwithID(131.108.2.1)(ProcessID1)
R1#
R1#showipospfdatabasenssa-external0.0.0.0
OSPFRouterwithID(131.108.2.1)(ProcessID1)
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.
Figure9-67Problem-ResolutionFlowchartDebugsandVerification
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
R1#showipospfdatabaserouter131.108.1.2
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
Linkconnectedto:aStubNetwork(LinkID)Network/subnetnumber:131.108.1.0(LinkData)NetworkMask:255.255.255.0NumberofTOSmetrics:0TOS0Metrics:64
Linkconnectedto:aStubNetwork(LinkID)Network/subnetnumber:131.108.0.0(LinkData)NetworkMask:255.255.255.0NumberofTOSmetrics:0TOS0Metrics:10
R2#showipospfdatabaserouter131.108.2.1
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
Linkconnectedto:aStubNetwork(LinkID)Network/subnetnumber:131.108.2.0(LinkData)NetworkMask:255.255.255.0NumberofTOSmetrics:0TOS0Metrics:10
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
R2#showiprouteospfR2#
Figure9-69showstheflowcharttofollowtosolvethisproblem.
Figure9-69Problem-ResolutionFlowchartDebugsandVerification
Example9-191showstheoutputofshowipospfneighbor,whichshowsthatOSPFisformingFULLadjacencyonbothseriallinks.Theaddresscolumnshowsthattheneighboraddressandinterfacedonotmatch.Forexample,inExample9-191,R2hastwoneighbors.BecauseR2’sSerial0addressisintherange131.108.2.0/24,asshowninFigure9-68,theneighboraddressonSerial0alsoshouldbeinthesamerange,butitshows131.108.1.1asaneighboronSerial0.Example9-191showipospfneighborCommandOutputIndicatesOSPFAdjacencyFormationonR1’sSerialLinks
R2#showipospfneighbor
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#showiproute131.108.3.0Routingentryfor131.108.3.0/24Knownvia"ospf1",distance130,metric74,typeintraareaRedistributingviaospf1Lastupdatefrom131.108.1.1onSerial0,01:39:09agoRoutingDescriptorBlocks:*131.108.1.1,from131.108.2.1,14:39:09ago,viaSerial0Routemetricis64,trafficsharecountis1
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
Figure9-71showstheflowcharttofollowtosolvethisproblem.
Figure9-71Problem-ResolutionFlowchartDebugsandVerification
Example9-194showsthediscrepancyintheOSPFdatabase.R1’srouterLSAshowstheMIB-IIIfIndexvalueintheLinkDatafieldforSerial0,whileR2’srouterLSAshowstherouter’sserialinterfaceaddressintheLinkDatafield.Example9-194CheckingtheOSPFDatabaseforaDiscrepancy
R2#showipospfdatabaserouter
OSPFRouterwithID(131.108.1.2)(ProcessID1)
RouterLinkStates(Area0)
AdvRouterisnot-reachableLSage:855Options:(NoTOS-capability,DC)LSType:RouterLinksLinkStateID:131.108.1.1AdvertisingRouter:131.108.1.1LSSeqNumber:8000000DChecksum:0x55ADLength:60NumberofLinks:1
Linkconnectedto:anotherRouter(point-to-point)(LinkID)NeighboringRouterID:131.108.1.2(LinkData)RouterInterfaceaddress:0.0.0.4NumberofTOSmetrics:0TOS0Metrics:64
R1#showipospfdatabaserouter
OSPFRouterwithID(131.108.1.1)(ProcessID1)
RouterLinkStates(Area0)
AdvRouterisnot-reachableLSage:855Options:(NoTOS-capability,DC)LSType:RouterLinksLinkStateID:131.108.1.2AdvertisingRouter:131.108.1.2LSSeqNumber:8000000DChecksum:0x55ADLength:60NumberofLinks:1
Linkconnectedto:anotherRouter(point-to-point)(LinkID)NeighboringRouterID:131.108.1.1(LinkData)RouterInterfaceaddress:131.108.1.2NumberofTOSmetrics:0TOS0Metrics:64
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#showiproute131.108.3.0Routingentryfor131.108.3.0/24Knownvia"ospf1",distance130,metric74,typeintraareaRedistributingviaospf1Lastupdatefrom131.108.1.1onSerial0,01:39:09agoRoutingDescriptorBlocks:*131.108.1.1,from131.108.2.1,14:39:09ago,viaSerial0Routemetricis64,trafficsharecountis1
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
Figure9-73showstheflowcharttofollowtosolvethisproblem.
Figure9-73Problem-ResolutionFlowchartDebugsandVerification
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
R2#showiproute131.108.3.0%NetworknotintableR2#
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#showiproute131.108.3.0Routingentryfor131.108.3.0/24Knownvia"ospf1",distance130,metric74,typeintraareaRedistributingviaospf1Lastupdatefrom131.108.1.1onSerial0,01:09:19agoRoutingDescriptorBlocks:*131.108.1.1,from131.108.2.1,14:39:09ago,viaSerial0Routemetricis64,trafficsharecountis1
R2#
OSPFNotInstallingAnyRoutesintheRoutingTable—Cause:BrokenPVCinaFullyMeshedFrameRelayNetworkwithBroadcastNetworkType
TheOSPFnetworktypebroadcastshouldneverbedefinedonamediumthatisnotfullymeshed.Sometimes,themediumisfullymeshedbuttheLayer2connectivityisnotstable.Inthatcase,whenLayer2isbroken,itcreatesaninconsistencyandthemediumbecomesnon–fullymeshedagain.Figure9-74showsanetworkexperiencingthisproblem.BeforethePVCbetweenR1andR2wasbroken,R2wasaDRandR3wasaBDR.
Figure9-74OSPFNetworkinWhichaBrokenPVCinaFullyMeshedFrameRelayNetworkwithBroadcastNetworkTypeCausesProblems
Example9-201showsthatR1isnotinstallinganyroutesintheroutingtable.Example9-201R1IsNotInstallingAnyRoutes
R1#showiprouteospfR1#
Figure9-75showstheflowcharttofollowtosolvethisproblem.
Figure9-75Problem-ResolutionFlowchartDebugsandVerification
Example9-202showstheconfigurationonR1,R2,andR3.TheconfigurationshowsthatthenetworktypeisbroadcastonallroutersfortheFrameRelaycloud.Example9-202ConfirmingtheNetworkTypeonR1,R2,andR3
R1#!interfaceSerial0.1multipointipaddress131.108.0.1255.255.255.0ipospfnetworkbroadcast
R2#!interfaceSerial0.1multipointipaddress131.108.0.2255.255.255.0ipospfnetworkbroadcast
R3#!interfaceSerial0.1multipointipaddress131.108.0.3255.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
R1#showipospfdatabaserouter
OSPFRouterwithID(131.108.1.1)(ProcessID1)
RouterLinkStates(Area0)
LSage:148Options:(NoTOS-capability,DC)LSType:RouterLinksLinkStateID:131.108.1.1AdvertisingRouter:131.108.1.1LSSeqNumber:8000000BChecksum:0x55ALength:48NumberofLinks:2
Linkconnectedto:aStubNetwork(LinkID)Network/subnetnumber:131.108.0.0(LinkData)NetworkMask:255.255.255.0NumberofTOSmetrics:0TOS0Metrics:64
Linkconnectedto:aStubNetwork(LinkID)Network/subnetnumber:131.108.1.1(LinkData)NetworkMask:255.255.255.255NumberofTOSmetrics:0TOS0Metrics:1
AdvRouterisnot-reachableLSage:1081Options:(NoTOS-capability,DC)LSType:RouterLinks
LinkStateID:131.108.2.1AdvertisingRouter:131.108.2.1LSSeqNumber:80000006Checksum:0x4F72Length:48NumberofLinks:2
Linkconnectedto:aStubNetwork(LinkID)Network/subnetnumber:131.108.2.1(LinkData)NetworkMask:255.255.255.255NumberofTOSmetrics:0TOS0Metrics:1
Linkconnectedto:aTransitNetwork(LinkID)DesignatedRouteraddress:131.108.0.3(LinkData)RouterInterfaceaddress:131.108.0.2NumberofTOSmetrics:0TOS0Metrics:64
AdvRouterisnot-reachableLSage:306Options:(NoTOS-capability,DC)LSType:RouterLinksLinkStateID:131.108.3.1AdvertisingRouter:131.108.3.1LSSeqNumber:80000007Checksum:0xC185Length:48NumberofLinks:2
Linkconnectedto:aStubNetwork(LinkID)Network/subnetnumber:131.108.3.1(LinkData)NetworkMask:255.255.255.255NumberofTOSmetrics:0TOS0Metrics:1
Linkconnectedto:aTransitNetwork(LinkID)DesignatedRouteraddress:131.108.0.3(LinkData)RouterInterfaceaddress:131.108.0.3NumberofTOSmetrics:0TOS0Metrics:64
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
R2#!interfaceSerial0.1multipointipaddress131.108.0.2255.255.255.0ipospfnetworkpoint-to-multipoint
R3#!interfaceSerial0.1multipointipaddress131.108.0.3255.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
R1#showiproute200.200.200.0%NetworknotintableR1#
Figure9-77showstheflowcharttofollowtosolvethisproblem.
Figure9-77Problem-ResolutionFlowchartDebugsandVerification
Example9-208showstheexternalLSAforrouter200.200.200.0.TheexternalLSAexistsintheOSPFdatabase,buttheroutestillisnotbeinginstalledintheroutingtable.Also,thereisaforwardingaddressinvolvedinthisexternalLSA.Example9-208ExternalLSADatabaseforRIPRoute200.200.200.0
R1#showipospfdatabaseexternal200.200.200.0
OSPFRouterwithID(131.108.1.1)(ProcessID1)
Type-5ASExternalLinkStates
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
R1#showiproute200.200.200.0%NetworknotintableR1#
Figure9-79showstheflowcharttofollowtosolvethisproblem.
Figure9-79Problem-ResolutionFlowchartDebugsandVerification
Example9-217showsthattherouteexistsintheexternaldatabase.Example9-217ConfirmingThatRoute200.200.200.0ExistsintheExternalOSPFDatabase
R1#showipospfdatabaseexternal200.200.200.0
OSPFRouterwithID(131.108.2.1)(ProcessID1)
Type-5ASExternalLinkStates
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
OSPFRouterwithID(131.108.2.1)(ProcessID1)
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
OSPFRouterwithID(131.108.2.1)(ProcessID1)
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.
Figure9-81Problem-ResolutionFlowchartDebugsandVerification
Example9-224showstheoutputofshowipospfdatabaseexternalfor132.108.3.0.TheoutputshowsnoLSAinformation,whichmeansthatR1isnotevenoriginatingtheexternalLSAfor132.108.3.0.
Example9-224R1IsNotOriginatinganExternalLSAfor132.108.3.0
R1#showipospfdatabaseexternal132.108.3.0
OSPFRouterwithID(131.108.2.1)(ProcessID1)
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
R1#showipospfdatabaseexternal132.108.3.0
OSPFRouterwithID(131.108.2.1)(ProcessID1)
Type-5ASExternalLinkStates
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#showipospfdatabaseexternal132.108.4.0
OSPFRouterwithID(131.108.2.1)(ProcessID1)
Type-5ASExternalLinkStates
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#
OSPFNeighborIsNotAdvertisingExternalRoutes—Cause:distribute-listoutIsBlockingtheRoutes
Whendistribute-listoutisconfiguredonanASBR,theaccesslistassociatedwiththedistributelistisexaminedandType5externalLSAsareoriginatedfornetworksthatareexplicitlypermittedinthedistributelist.Allothernetworksaredenied,andnoType5externalLSAsaregeneratedforthosenetworks.Figure9-82showstheflowcharttofollowtosolvethisproblem.
Figure9-82Problem-ResolutionFlowchartDebugsandVerification
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#showipospfdatabaseexternal132.108.3.0
OSPFRouterwithID(131.108.1.2)(ProcessID1)
R1#
R1#showipospfdatabaseexternal132.108.4.0
OSPFRouterwithID(131.108.1.2)(ProcessID1)
Type-5ASExternalLinkStates
LSage:1161Options:(NoTOS-capability,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
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#showipospfdatabaseexternal132.108.3.0
OSPFRouterwithID(131.108.1.2)(ProcessID1)
Type-5ASExternalLinkStates
LSage:1161Options:(NoTOS-capability,DC)LSType:ASExternalLinkLinkStateID:132.108.3.0(ExternalNetworkNumber)AdvertisingRouter:131.108.1.2LSSeqNumber:80000001Checksum:0x550Length:36NetworkMask:/24MetricType:2(Largerthananylinkstatepath)TOS:0Metric:1ForwardAddress:0.0.0.0ExternalRouteTag:1
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
Figure9-84showstheflowcharttofollowtosolvethisproblem.
Figure9-84Problem-ResolutionFlowchartDebugsandVerification
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
Figure9-86showstheflowcharttofollowtosolvethisproblem.
Figure9-86Problem-ResolutionFlowchartDebugsandVerification
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.
Figure9-87Problem-ResolutionFlowchartDebugsandVerification
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.
Figure9-88Problem-ResolutionFlowchartDebugsandVerification
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
Figure9-90showstheflowcharttofollowtosolvethisproblem.
Figure9-90Problem-ResolutionFlowchartDebugsandVerification
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
access-list100denytcpanyanyaccess-list100permitipanyanydialer-list1protocoliplist100
TheoutputoftheshowdialercommandinExample9-246indicatesthatthereasonforthelinkcomingupisOSPFmulticastHellos.Example9-246DeterminingWhytheDDRLinkKeepsComingUp
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)Currentcallconnected00:00:08Connectedto57654(R2)
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
Figure9-92showstheflowcharttofollowtosolvethisproblem.
Figure9-92Problem-ResolutionFlowchartDebugsandVerification
Example9-248showstheoutputofshowdialer,whichshowsthelasttimethecallwasconnectedbecauseoftheOSPFHelloandindicatesthatthecallhasbeenconnectedforeightseconds.Example9-248DeterminingCallHistoryontheDialerInterface
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)Currentcallconnected00:00:08Connectedto57654(R2)
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.
Figure9-93Problem-ResolutionFlowchartDebugsandVerification
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.
Figure9-95Problem-ResolutionFlowchartDebugsandVerification
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
R1#showipospfdatabaseexternal131.108.1.2
OSPFRouterwithID(131.108.3.1)(ProcessID1)
Type-5ASExternalLinkStates
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
Figure9-97showstheflowcharttofollowtosolvethisproblem.
Figure9-97Problem-ResolutionFlowchartDebugsandVerification
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
Figure9-100showstheflowcharttofollowtosolvethisproblem.
Figure9-100Problem-ResolutionFlowchartDebugsandVerification
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
Figure9-102showstheflowcharttofollowtosolvethisproblem.
Figure9-102Problem-ResolutionFlowchartDebugsandVerification
Example9-267showsthatSPFisbeingrunconstantlyinarea0.Example9-267DeterminingHowOftenSPFIsRunning
R1#showipospfRoutingProcess"ospf1"withID192.168.254.13SupportsonlysingleTOS(TOS0)routesItisanareaborderSPFscheduledelay5secs,HoldtimebetweentwoSPFs10secsMinimumLSAinterval5secs.MinimumLSAarrival1secsNumberofexternalLSA8.ChecksumSum0x48C3ENumberofDCbitlessexternalLSA0NumberofDoNotAgeexternalLSA0Numberofareasinthisrouteris3.2normal1stub0nssaAreaBACKBONE(0)Numberofinterfacesinthisareais1AreahasnoauthenticationSPFalgorithmexecuted2458times
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.
Figure9-103OSPFNetworkwithDuplicateRouterIDs
Figure9-104showstheflowcharttofollowtosolvethisproblem.
Figure9-104Problem-ResolutionFlowchartDebugsandVerification
WhenthereisaduplicaterouterID,itcausesSPFfrequently,andtheSPFcounterkeepsincrementingunlesstheproblemisfixed.Example9-273showsthatSPFinarea0ran2446times,whichisalargenumber.Example9-273DeterminingHowOftenSPFIsRunning
R1#showipospfRoutingProcess"ospf1"withID192.168.2.129SupportsonlysingleTOS(TOS0)routesItisanareaborderSPFscheduledelay5secs,HoldtimebetweentwoSPFs10secsMinimumLSAinterval5secs.MinimumLSAarrival1secsNumberofexternalLSA8.ChecksumSum0x48C3ENumberofDCbitlessexternalLSA0NumberofDoNotAgeexternalLSA0Numberofareasinthisrouteris4.1normal0stub0nssaAreaBACKBONE(0)Numberofinterfacesinthisareais1AreahasnoauthenticationSPFalgorithmexecuted2446times
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
R1#showipospfdatabaserouter192.168.1.129
OSPFRouterwithID(192.168.2.129)(ProcessID1)
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
Linkconnectedto:aTransitNetwork(LinkID)DesignatedRouteraddress:192.168.254.14(LinkData)RouterInterfaceaddress:192.168.254.14NumberofTOSmetrics:0TOS0Metrics:10
R1#showipospfdatabaserouter192.168.1.129
OSPFRouterwithID(192.168.2.129)(ProcessID1)
RouterLinkStates(Area0.0.0.0)
LSage:7Options:(NoTOS-capability,DC)LSType:RouterLinksLinkStateID:192.168.1.129AdvertisingRouter:192.168.1.129LSSeqNumber:80067683Checksum:0xA7D8Length:60NumberofLinks:3
Linkconnectedto:anotherRouter(point-to-point)(LinkID)NeighboringRouterID:192.168.2.129(LinkData)RouterInterfaceaddress:192.168.252.13NumberofTOSmetrics:0TOS0Metrics:66
Linkconnectedto:aStubNetwork(LinkID)Network/subnetnumber:192.168.252.12(LinkData)NetworkMask:255.255.255.252NumberofTOSmetrics:0TOS0Metrics:66
Linkconnectedto:aTransitNetwork(LinkID)DesignatedRouteraddress:192.168.253.14(LinkData)RouterInterfaceaddress:192.168.253.14NumberofTOSmetrics:0TOS0Metrics:1
R1#
Example9-276showsthatR2andR3haveidenticalrouterIDs.Example9-276DetectingDuplicateRouterIDs
R2#showipospfRoutingProcess"ospf1"withID192.168.1.129
R3#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
R3#showipospfRoutingProcess"ospf1"withID192.168.3.129
Example9-278showsthatafterchangingtherouterIDofR3,theLSagefor192.168.1.129becomesstableintheOSPFdatabase.TheLSagehasreached90seconds,sotheentryisnowstable.Example9-278TheLSAgefortheProblemLSAIsNowStable
R1#showipospfdatabaserouter192.168.1.129
OSPFRouterwithID(192.168.2.129)(ProcessID1)
RouterLinkStates(Area0.0.0.0)
LSage:90Options:(NoTOS-capability,DC)LSType:RouterLinksLinkStateID:192.168.1.129AdvertisingRouter:192.168.1.129LSSeqNumber:80067686Checksum:0xC456Length:36NumberofLinks:1
Linkconnectedto:aTransitNetwork(LinkID)DesignatedRouteraddress:192.168.254.14(LinkData)RouterInterfaceaddress:192.168.254.14NumberofTOSmetrics:0TOS0Metrics:10
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
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
RT2#showclnsneighborsdetail
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.
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
RT1#showclnsneighborsdetail
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
RT1#showclnsneighbors
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
RT1#showclnsneighbors
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
RT2#showclnsneighbors
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
RT1#showclnsneighbors
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
RT2#showclnsneighbors
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
RT1#showclnsneighbors
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
RT2#debugisisadj-packets
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#
RT1#debugisisadj-packets
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
RT1#showclnsneighbors
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
access-list2permitany
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
R2#showipbgp131.108.1.0BGProutingtableentryfor131.108.1.0/24,version10Paths:(1available,best#1)Advertisedtononpeer-grouppeers:1.1.8.31091.1.7.1from1.1.7.1(10.1.1.1)OriginIGP,metric10,localpref100,valid,external,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
R2#showipbgp131.108.1.0BGProutingtableentryfor131.108.1.0/24,version6Paths:(1available,best#1)Advertisedtononpeer-grouppeers:1.1.8.31091.1.7.1from1.1.7.1(10.1.1.1)OriginIGP,metric0,localpref100,valid,external,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
access-list1permit131.108.1.0access-list2permitany
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
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
access-list1permit131.108.1.0access-list2permitany
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
R1#showipbgpBGPtableversionis2,localrouterIDis1.1.1.1Statuscodes:ssuppressed,ddamped,hhistory,*valid,>best,i-internalOrigincodes:i-IGP,e-EGP,?-incomplete
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
R2#showipbgpBGPtableversionis3,localrouterIDis2.2.2.2Statuscodes:ssuppressed,ddamped,hhistory,*valid,>best,i-internalOrigincodes:i-IGP,e-EGP,?-incomplete
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
access-list1permit131.108.1.00.0.0.0
!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
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.
Figure15-2Problem-ResolutionFlowchartDebugsandVerification
Example15-1showstherelevantconfigurationofR1andR2,respectively.Example15-1R1andR2Configuration
R1#routerbgp109neighbor131.108.1.2remote-as110
interfaceEthernet0ipaddress131.108.1.1255.255.255.0
R2#routerbgp110neighbor131.108.1.1remote-as109
interfaceEthernet0ipaddress131.108.1.2255.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
Typeescapesequencetoabort.Sending5,100-byteICMPEchosto131.108.1.2,timeoutis2seconds:.....Successrateis0percent(0/5)
Solution
Inthisexample,thepingfailurefromR1toR2wastheresultofLayer2onR2beingdown.Example15-4showstheoutputindicatingaLayer2problem.Example15-4showinterfaceCommandOutputPinpointsThatThisIsaLayer2Problem
R2#showinterfaceethernet0Ethernet0isdown,lineprotocolisdown
Thismightbebecauseofcableissuesorahardwareproblem.Apartfromtheinterfacebeingdown,asinExample15-4,Layer2encapsulationfailurecanalsocauseIPconnectivitytobreak.Layer2encapsulationfailurecanoccurbecauseofcorruptionintheARPtableincaseofEthernetoranincorrectDLCI–VPI/VCImappingincasesofFrameRelayandATM,respectively.FixingtheseshouldenablebasicIPconnectivity,andtheBGPneighborrelationshipshouldinitialize.DirectlyConnectedExternalBGPNeighborsNotComingUp—Cause:IncorrectNeighborIPAddressinBGPConfiguration
Figure15-3showstheflowcharttofollowtofixthisproblem.
Figure15-3Problem-ResolutionFlowchartDebugsandVerification
Example15-5showstherelevantconfigurationofR1andR2,respectively.Example15-5R1andR2Configuration
R1#routerbgp109neighbor131.108.1.2remote-as110
interfaceEthernet0ipaddress131.108.1.1255.255.255.0
R2#routerbgp110neighbor131.108.1.11remote-as109
interfaceEthernet0ipaddress131.108.1.2255.255.255.0
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
R2#routerbgp110neighbor131.108.1.1remote-as109
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
Figure15-5showstheflowcharttofollowtofixthisproblem.
Figure15-5Problem-ResolutionFlowchart
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
neighbor131.108.10.1remote-as109neighbor131.108.10.1ebgp-multihop2neighbor131.108.10.1update-sourceLoopback0
InExample15-8,RoutersR1andR2areconfiguredtopeerwitheachother’sloopbackIPaddress.ebgp-multihop2meansthatR1andR2peeringaddressescouldbetwohopsaway.update-sourcemeansthatthesourceofBGPpacketsistheLoopbackthe0IPaddressbecausebothroutersacceptonlyBGPpacketssourcedwiththeLoopback0IPaddressofotherrouter.TheoutputinExample15-9showstheneighborrelationshipbetweenR1andR2.Example15-9showipbgpCommandOutputDisplaystheBGPNeighborRelationshipBetweenR1andR2
R1#showipbgpsummaryBGProuteridentifier131.108.10.1,localASnumber109BGPtableversionis1,mainroutingtableversion1
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
Foraddressfamily:IPv4UnicastBGPtableversion1,neighborversion0Index2,Offset0,Mask0x40acceptedprefixesconsume0bytesPrefixadvertised0,suppressed0,withdrawn0
Connectionsestablished1;dropped1Lastreset00:04:21,duetoUserresetExternalBGPneighbormaybeupto2hopsaway.NoactiveTCPconnection
ThehighlightedoutputinExample15-9showsthatR1’sneighborrelationshipwithR2isintheActivestateandthattheBGPrelationshipisnotcomplete.TheconfigurationshowninExample15-8isarequiredconfigurationwhenconfiguringanEBGPconnectiontoanondirectlyconnectedpeer;however,onethingthatisnotcontrolledbyBGPconfigurationisthereachabilitytopeeraddresses.Example15-10showsthatR1cannotreachtheloopbackinterfaceofR2becauseR1doesnothavetheroutetoreachR2.Example15-10R1CannotPingR2’sLoopbackInterfaceandHasNoRoutetoReachR2
R1#ping131.108.10.2
Typeescapesequencetoabort.Sending5,100-byteICMPEchosto131.108.10.2,timeoutis2seconds:.....Successrateis0percent(0/5)
R1#showiproute131.108.10.2%Subnetnotintable
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
Figure15-6showstheflowcharttofollowtofixthisproblem.
Figure15-6Problem-ResolutionFlowchart
Bydefault,inCiscoIOSSoftware,BGPpacketssenttoanexternalBGPneighborhavetheirIPTimeToLive(TTL)setto1.IfanEBGPneighborisnotdirectlyconnected,thefirstdeviceinthepathwilldropBGPpacketswithTTLequalto1tothatEBGPneighbor.
DebugsandVerification
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
R1#showipbgpsummaryBGProuteridentifier131.108.10.1,localASnumber109BGPtableversionis1,mainroutingtableversion1
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
Foraddressfamily:IPv4UnicastBGPtableversion1,neighborversion0Index2,Offset0,Mask0x40acceptedprefixesconsume0bytesPrefixadvertised0,suppressed0,withdrawn0
Connectionsestablished4;dropped4Lastreset00:02:18,duetoUserresetExternalBGPneighbornotdirectlyconnected.NoactiveTCPconnection
ThehighlightedoutputshowsthatBGPneighborisintheIdlestate,inwhichnoresourcesareallocatedtoBGPneighbor.ThismightbebecausetheothersidehasnotreceivedanyBGPnegotiationfromR1orbecauseR1hasnotreceivedanythingfromR2.Solution
Usetheebgp-multihopcommandtoincreasetheIPTTLvaluetothedesirednumber.Example15-13showstherequiredconfigurationonR1tobringuptheEBGPneighborR2.Example15-13Usingebgp-multihoptoIncreasetheIPTTLValue
R1#routerbgp109
neighbor131.108.10.2remote-as110neighbor131.108.10.2ebgp-multihop2neighbor131.108.10.2update-sourceLoopback0
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.
Figure15-7Problem-ResolutionFlowchartDebugsandVerification
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
R1#routerbgp109neighbor131.108.10.2remote-as110neighbor131.108.10.2ebgp-multihop2neighbor131.108.10.2update-sourceLoopback0
R2#routerbgp110neighbor131.108.10.1remote-as109neighbor131.108.10.1ebgp-multihop2neighbor131.108.10.1update-sourceLoopback0
Problem:InternalBGPNeighborsNotComingUpIBGPcanexperienceissuessimilartoEBGPinneighborrelationship.IBGPisanimportantpieceofoverallBGP-runningnetworks.Chapter14discussestheimportanceandusageofIBGP.ThissectionaddressessomecommonlyseenissuesexclusivetoIBGPneighborrelationshipproblems.Thecausesof
thisproblemareidenticaltothepreviousproblemofnondirectlyconnectedexternalBGPneighborsnotcomingup:•TheroutetothenondirectlyconnectedIBGPneighboraddressismissing.•Theupdate-sourceinterfacecommandismissinginBGPconfiguration.
YoucanusethesametroubleshootingandconfigurationtechniquesasthoseusedfortheEBGPproblem.
Problem:BGPNeighbors(ExternalandInternal)NotComingUp—Cause:InterfaceAccessListBlockingBGPPacketsInterfaceaccesslist/filtersareanothercommoncauseofBGPneighboractivationproblems.IfaninterfaceaccesslistunintentionallyblocksTCPpacketsthatcarryBGPprotocolpackets,theBGPneighborwillnotcomeup.Figure15-8showstheflowcharttofollowtofixthisproblem.
Figure15-8Problem-ResolutionFlowchartDebugsandVerification
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.
Figure15-9Problem-ResolutionFlowchartDebugsandVerification
ThissectionassumesthattherearenomistakesinBGPconfiguration.Case1:MatchingRouteDoesNotExistintheRoutingTable
Example15-22showsthatBGPisconfiguredtoadvertise100.100.100.0/24butfailstodosobecausetheroutingtabledoesnotcontainanexactmatchfortheprefixadvertised.Example15-22RoutingTableLackstheExactPrefixThatBGPIsTryingtoAdvertise
routerbgp109nosynchronizationnetwork100.100.100.0mask255.255.255.0neighbor131.108.1.2remote-as109
R1#showiproute100.100.100.0%Networknotintable
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
R1#showipbgp100.100.100.0%Networknotintable
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.
Figure15-10showstheflowcharttofollowtofixthisproblem.
Figure15-10Problem-ResolutionFlowchartDebugsandVerification
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:
R1#showipbgp100.100.100.0%Networknotintable
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.
Figure15-11Problem-ResolutionFlowchartDebugsandVerification
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.
Figure15-12Problem-ResolutionFlowchartDebugsandVerification
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:
access-list1permit100.100.100.0
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
Figure15-14showstheflowcharttofollowtofixthisproblem.
Figure15-14Problem-ResolutionFlowchartDebugsandVerification
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
R2#showipbgp100.100.100.0%Networknotintable
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.
Figure15-17Problem-ResolutionFlowchartDebugsandVerification
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.
Figure15-19Problem-ResolutionFlowchartDebugsandVerification
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-20Problem-ResolutionFlowchart
Figure15-21showsthatNEXTHOPofBGProutesadvertisedtoIBGPneighborsarenotchangedandmightresultinrouteinstallationfailure.
Figure15-21NexthopofBGPRoutesAdvertisedtoIBGPNeighborsIsNotChangedandMightResultinRouteInstallationFailure
DebugsandVerification
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
R2#showiproute100.100.100.0%Networknotintable
Noticethat206.56.89.1isinaccessiblebecauseR2doesnothavearoutetoreachitinitsIProutingtable,asconfirmedbyExample15-48.Example15-48R2’sIPRoutingTableConfirmsanInaccessibleRoute
R2#showiproute206.56.89.1%Networknotintable
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-22showstheflowcharttofollowtoresolvethisproblem.
Figure15-22Problem-ResolutionFlowchartDebugsandVerification
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
Figure15-25showstheflowcharttofollowtoresolvethisproblem.
Figure15-25Problem-ResolutionFlowchartDebugsandVerification
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
R2#showiproute131.108.10.1Routingentryfor131.108.10.1/32Knownvia"bgp110",distance20,metric0Tag109,typeexternalLastupdatefrom131.108.10.100:00:38agoRoutingDescriptorBlocks:*131.108.10.1,from131.108.10.1,00:00:38agoRoutemetricis0,trafficsharecountis1ASHops1
R2#showiproute131.108.10.1Routingentryfor131.108.10.1/32Knownvia"bgp110",distance20,metric0Tag109,typeexternalLastupdatefrom131.108.10.100:00:38agoRoutingDescriptorBlocks:*131.108.10.1,from131.108.10.1,00:00:04agoRoutemetricis0,trafficsharecountis1ASHops1
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.
Figure15-26Problem-ResolutionFlowchartDebugsandVerification
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
Figure15-29showstheflowcharttofollowtoresolvethisproblem.
Figure15-29Problem-ResolutionFlowchartDebugsandVerification
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
Figure15-31showstheflowcharttofollowtoresolvethisproblem.
Figure15-31Problem-ResolutionFlowchartDebugsandVerification
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#routerbgp109nosynchronizationneighbor131.108.10.1remote-as109neighbor131.108.10.2remote-as109
R6#routerbgp109nosynchronizationneighbor131.108.10.1remote-as109neighbor131.108.10.2remote-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.
Figure15-35Problem-ResolutionFlowchart
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
access-list2permitany
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.
Figure15-37Problem-ResolutionFlowchartDebugsandVerification
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
Figure15-39showstheflowcharttofollowtoresolvethisproblem.
Figure15-39Problem-ResolutionFlowchart
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.
DebugsandVerification
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
access-list1permit131.108.1.0
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
R3#showipbgp131.108.1.0BGProutingtableentryfor131.108.1.0/24,version19Paths:(1available,best#1,tableDefault-IP-Routing-Table)Advertisedtononpeer-grouppeers:4.4.4.41091.1.1.1from1.1.1.1(1.1.1.1)OriginIGP,metric0,localpref100,valid,external,best
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
R1#showiproute100.100.100.0Routingentryfor100.100.100.0/24Knownvia"bgp109",distance20,metric0Tag110,typeexternalLastupdatefrom141.108.1.100:32:25agoRoutingDescriptorBlocks:*141.108.1.1,from141.108.1.1,00:32:25agoRoutemetricis0,trafficsharecountis1ASHops1
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
Figure15-44showstheflowcharttofollowtoresolvethisproblem.
Figure15-44Problem-ResolutionFlowchartDebugsandVerification
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
Figure15-47showstheflowcharttofollowtoresolvethisproblem.
Figure15-47Problem-ResolutionFlowchartDebugsandVerification
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
access-list1permit100.100.100.0access-list2permitany
!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
R8#showipbgp100.100.100.0BGProutingtableentryfor100.100.100.0/24,version12Paths:(1available,best#1,tableDefault-IP-Routing-Table)Advertisedtononpeer-grouppeers:172.16.126.6109172.16.28.2from172.16.28.2(172.16.2.2)OriginIGP,metric1,localpref100,valid,external,best
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-49Problem-ResolutionFlowchartDebugsandVerification
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.
Figure15-52Problem-ResolutionFlowchartDebugsandVerification
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.
Figure15-53Problem-ResolutionFlowchartDebugsandVerification
Example15-99showstheBGPconfigurationofR1,withneighborrelationshipsandthedistribute-listcommandusingaccesslist1.Example15-99BGPConfigurationinR1UsingStandardAccessListindistribute-listCommand
R1#routerbgp1neighbor131.108.1.2remote-as2neighbor131.108.1.2distribute-list1in
access-list1permit13.13.0.00.0.255.255
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
R1#showipbgpBGPtableversionis5,localrouterIDis141.108.13.1Statuscodes:ssuppressed,ddamped,hhistory,*valid,>best,i-internalOrigincodes:i-IGP,e-EGP,?-incomplete
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
R1#routerbgp1neighbor131.108.1.2remote-as2neighbor131.108.1.2distribute-list101in
access-list101permitip13.13.0.00.0.255.255255.255.0.00.0.0.0
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
R1#showipbgpBGPtableversionis5,localrouterIDis141.108.13.1Statuscodes:ssuppressed,ddamped,hhistory,*valid,>best,i-internalOrigincodes:i-IGP,e-EGP,?-incomplete
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.
Figure15-55showstheflowcharttofollowtoresolvethisproblem.
Figure15-55Problem-ResolutionFlowchartDebugsandVerification
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
R2#showipbgpBGPtableversionis5,localrouterIDis141.108.13.2Statuscodes:ssuppressed,ddamped,hhistory,*valid,>best,i-internalOrigincodes:i-IGP,e-EGP,?-incomplete
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:
access-list101permitip0.0.0.0255.255.255.255255.255.248.0255.255.248.0
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
R2#routerbgp110neighbor131.108.1.1remote-as109neighbor131.108.1.1distribute-list101in
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
R2#showipbgpBGPtableversionis5,localrouterIDis141.108.13.2Statuscodes:ssuppressed,ddamped,hhistory,*valid,>best,i-internalOrigincodes:i-IGP,e-EGP,?-incomplete
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