You are on page 1of 7

6/11/2017 OSPFNeighborProblemsExplainedCisco

Adjacencies
Thefactthatroutersareneighborsisnotsufficienttoguaranteean
exchangeoflinkstateupdatestheymustformadjacenciestoexchange
linkstateupdates.Adjacencyisanadvancedformofneighborship
formedbyroutersthatarewillingtoexchangeroutinginformationafter
negotiatingparametersofsuchanexchange.Routersreach
aFULLstateofadjacencywhentheyhavesynchronizedviewsonalink
statedatabase.
Interfacetypeplaysamajorroleinhowtheadjacenciesareformed.For
example,neighborsonpointtopointlinksalwaystrytobecome
adjacent,whileroutersattachedtobroadcastmediasuchasEthernet
canchoosetobecomeadjacentonlywithasubsetofneighboring
routersontheinterface.
Oncearouterdecidestoformanadjacencywithaneighbor,itstartsby
exchangingafullcopyofitslinkstatedatabase.Theneighbor,inturn,
exchangesafullcopyofitslinkstatedatabasewiththerouter.After
passingthroughseveralneighborstates,theroutersbecomefully
adjacent.

NeighborStates
Youcanusetheshowipospfneighborcommandinordertodetermine
thestateoftheOSPFneighbororneighbors.Theoutputofthis
commandwillmostlikelyrevealoneofthese:
nothingatall
state=down
state=init
state=exstart
state=exchange
state=2way
state=loading
http://www.cisco.com/c/en/us/support/docs/ip/openshortestpathfirstospf/1369929.html 1/7
6/11/2017 OSPFNeighborProblemsExplainedCisco

state=loading

ThereareotherOSPFstates,butthoseshownherearethemost
commononesseeninshowipospfneighborcommandoutput.Refer
toOSPFNeighborStatesformoreinformationandanexplanationofall
theOSPFneighborstates.

NoStateRevealed
Iftheshowipospfneighborcommandrevealsnothingatallor
revealsnothingabouttheparticularneighboryouareanalyzingthen
thisrouterhasnotseenany"valid"OSPFHELLOsfromthatneighbor.
ThismeansthatOSPFeitherdidnotreceiveanyHELLOpacketsfrom
theneighbororreceivedHELLOpacketsthatfailedverybasicsanity
checks.
Checkthese:
Istheinterfaceuponthelocalrouterandneighboringrouter,withline
protocolup?Entertheshowinterfacecommandinordertocheck.

CheckforIPconnectivitybetweentheneighboringrouters,asshown
here:
Doestheneighborrespondtoapingcommand?PingtheIPaddress
assignedtotheinterfaceinquestionontheneighboringrouter.Enter
thetraceroutecommandtothesameIPaddressandcheckthatit
takesnomorethanonehoptoreachthedestination.
Doestheneighborrespondifyouenteraping224.0.0.5command?
(224.0.0.5istheaddresstowhichOSPFHELLOsaresent.)
Checkforanyinboundaccesslistsorotherdevices(suchasa
switch)thatmightprohibitthesendingofIPpacketsfromone
neighbortotheother.

IsOSPFenabledonbothyourinterfaceandtheinterfaceofthe
http://www.cisco.com/c/en/us/support/docs/ip/openshortestpathfirstospf/1369929.html 2/7
IsOSPFenabledonbothyourinterfaceandtheinterfaceofthe
6/11/2017 OSPFNeighborProblemsExplainedCisco

neighboringrouter?Entertheshowipospfinterfacecommandin
ordertocheck.
IsOSPFconfiguredaspassivefortheinterfaceofthelocalor
neighboringrouter?Entertheshowipospfinterfacecommandin
ordertoverifythatHELLOpacketsareduetobesentoutofthe
interface.AnactiveOSPFinterfacedisplaysalinesimilartothis:
Helloduein00:00:07

VerifythatneighboringroutershavedifferentRouterIDs.RouterIDs
areusedinordertoidentifyeachrouterinanOSPFnetwork.Routers
withthesameRouterIDwillignoreHELLOssentbyeachother,which
preventsthemfromformingadjacency.Thefirstlineofshowip
ospfcommandoutputdisplaysthecurrentRouterIDofeachrouter.
VerifythattheseHELLOparametersmatchontheneighboring
interfaces:
OSPFareanumberEntertheshowipospfinterfaceinterface
namecommandinordertocheck.

OSPFareatype,suchasstuborNSSAEntertheshowip
ospfcommandinordertocheck.
SubnetandsubnetmaskEntertheshowinterfacecommandin
ordertocheck.
OSPFHELLOandDeadtimervaluesEntertheshowipospf
interfaceinterfacenamecommandinordertocheck.

Iftheproblemisonpointtopointlink(suchasPPPorHighLevelData
LinkControl[HDLC])andthereismorethanoneparallellinkbetween
thispairofrouters,verifythatlinesareproperlyconnected.Suppose
youplannedtoconnectinterfaceSerial0/0ononerouterwithinterface
Serial0/0onitsneighborandSerial1/0withSerial1/0onitsneighbor,
butyouaccidentallycrossedthemandconnectedSerial0/0ofeach
routerwithSerial1/0ontheother.Thepingcommandmightnot
http://www.cisco.com/c/en/us/support/docs/ip/openshortestpathfirstospf/1369929.html 3/7
6/11/2017 OSPFNeighborProblemsExplainedCisco

routerwithSerial1/0ontheother.Thepingcommandmightnot
discoversuchaproblem,butOSPFwillfailtoestablishadjacency.Use
informationprovidedbyCiscoDiscoveryProtocol(CDP)inorderto
verifyproperdeviceinterconnection.Entertheshowcdp
neighborinterfacenamecommandinordertoverifythatthename
andPortIDofaremotedevicematchthenetworkdesign.

Note:OSPFadjacenciesonlyformoverprimarynetworks,not
secondarynetworks.

Ifallofthesechecksareverifiedandtheshowipospf
neighborcommandstillrevealsnothing,thenyourproblemisnotvery
commonandyoumightneedtoContactCiscoforassistance.

NeighborindownState
AneighborthatisdiscovereddynamicallythroughreceptionofHELLO
packetscanfallbacktoadownstateifitisbeingdeleted,forexample
whenOSPFdoesnotreceiveHELLOpacketsfromtheneighborfor
periodoftimelongerthantheDeadtimerinterval.Therefore,

thedownstateistransientforsuchneighborstheywilleitheradvanceto
higherstatesorbecompletelydeletedfromthetableofknown
neighbors.Thisisknownasbeing"forgotten".
Usually,neighborsthatareseeninthedownstateweremanually
configuredwiththeneighborcommand.Manuallyconfiguredneighbors
arealwayspresentintheOSPFneighbortable.IfOSPFhasnever
receivedHELLOpacketsfromthemanuallyconfiguredneighbor,orifno
HELLOpacketswereheardfromtheneighborduringthepreviousDead
timerinterval,thenthemanuallyconfiguredneighborwillbelisted
asdown.

Note:Theneighborcommandcanonlybeconfiguredfordirectly
attachedneighborsonthesetypesofnetworks:
http://www.cisco.com/c/en/us/support/docs/ip/openshortestpathfirstospf/1369929.html 4/7
6/11/2017 OSPFNeighborProblemsExplainedCisco

NonBroadcastMultiAccess(NBMA)networksInterfaces
configuredwiththeipospfnetworknonbroadcastcommand.
NonBroadcastPointtoMultipointnetworksInterfacesconfigured
withtheipospfnetworkpointtomultipointnon
broadcastcommand.

Ifyouseeaneighborinthedownstate,verifythattheneighborrouteris
up,isrunning,andisproperlyconfiguredforOSPFonthisinterface.Test
connectivitybetweenrouterswiththepingandtraceroutecommands.
ChecktheOSPFneighbortableontheneighboringrouterwiththeshow
ipospfneighborcommand,andperformthesameconfiguration
verificationactionslistedintheNoStateRevealedsection.

NeighborininitState
TheinitstateindicatesthatarouterseesHELLOpacketsfromthe
neighbor,buttwowaycommunicationhasnotbeenestablished.ACisco
routerincludestheRouterIDsofallneighborsintheinit(orhigher)state
intheNeighborfieldofitsHELLOpackets.Fortwowaycommunication

tobeestablishedwithaneighbor,arouteralsomustseeitsownRouter
IDintheNeighborfieldoftheneighbor'sHELLOpackets.Foramore
detailedexampleandexplanation,refertoWhyDoestheshowipospf
neighborCommandRevealNeighborsintheInitState?

Neighborin2wayState
The2waystateindicatesthattherouterhasseenitsownRouterIDin
theNeighborfieldoftheneighbor'sHELLOpacket.Receivinga
DatabaseDescriptor(DBD)packetfromaneighborintheinitstatewill
alsoacauseatransitionto2waystate.TheOSPFneighbor2waystate
isnotacauseforconcern.Foranexplanationofthe2waystate,refer
toWhyDoestheshowipospfneighborCommandRevealNeighbors
Stuckin2WayState?

NeighborinexstartorexchangeState
http://www.cisco.com/c/en/us/support/docs/ip/openshortestpathfirstospf/1369929.html 5/7
6/11/2017 OSPFNeighborProblemsExplainedCisco

NeighborinexstartorexchangeState
OSPFneighborsthatareinexstartorexchangestatearetryingto
exchangeDBDpackets.Therouteranditsneighborformamasterand
slaverelationship.Theadjacencyshouldcontinuepastthisstate.Ifit
doesnot,thereisaproblemwiththeDBDexchange,suchasa
maximumtransmissionunit(MTU)mismatchorthereceiptofan
unexpectedDBDsequencenumber.Formoreinformation,refertoWhy
AreOSPFNeighborsStuckinExstart/ExchangeState?

NeighborinloadingState
Intheloadingstate,routerssendlinkstaterequestpackets.Duringthe
adjacency,ifarouterreceivesanoutdatedormissinglinkstate
advertisement(LSA),itrequeststhatLSAbysendingalinkstaterequest
packet.Neighborsthatdonottransitionbeyondthisstatearemostlikely
exchangingcorruptedLSAs.Thisproblemisusuallyaccompaniedby
a%OSPF4BADLSAconsolemessage.Becausethisproblemisnot
common,ContactCiscoforassistance.

TypicalReasonsforOSPFNeighborProblems
ThistablelistsreasonswhyOSPFneighborshaveproblemsformingan
adjacencyandlistssomeofthecommandsyoucanuseinordertoverify
theproblem.
ReasonforNeighborAdjacencyProblem Commands
for
Diagnosing
theProblem
OSPFisnotconfiguredononeoftherouters. showipospf
OSPFisnotenabledonaninterfacewhereitis showipospf
needed. interface
OSPFHELLOorDeadtimerintervalvaluesare showipospf
mismatched. interface
ipospfnetworktypemismatchontheadjoining showipospf
interfaces. interface
MTUmismatchbetweenneighboringinterfaces. show
interface
<inttype>
<intnum>

http://www.cisco.com/c/en/us/support/docs/ip/openshortestpathfirstospf/1369929.html 6/7
6/11/2017 OSPFNeighborProblemsExplainedCisco

OSPFareatypeisstubononeneighbor,butthe show
adjoiningneighborinthesameareaisnotconfigured running
forstub. configshow
ipospf
interface
OSPFneighborshaveduplicateRouterIDs. showip
ospfshowip
ospf
interface
OSPFisconfiguredonthesecondarynetworkofthe showipospf
neighbor,butnotontheprimarynetwork.Thisisan interfacesho
illegalconfigurationwhichpreventsOSPFfrombeing wrunning
enabledontheinterface. config
OSPFHELLOsarenotprocessedduetoalackof show
resources,suchashighCPUutilizationornot memory
enoughmemory. summarysho
wmemory
processor
AnunderlyingLayerproblempreventsOSPF
HELLOsfrombeingreceived.

http://www.cisco.com/c/en/us/support/docs/ip/openshortestpathfirstospf/1369929.html 7/7

You might also like