De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
Dit document beschrijft hoe u problemen kunt oplossen in situaties waarin Open Shortest Path First (OSPF)-buren vastzitten in Exstart- en Exchange-staten.
Men adviseert dat de gebruiker met basisverrichting OSPF en configuratie, in het bijzonder, OSPF buurstaten vertrouwd is.
De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:
Cisco 2503 routers
Cisco IOS®softwarerelease 12.2(24a) voor gebruik op beide routers
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.
Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.
OSPF-staten voor nabijheidsvorming zijn Down, Init, 2-way, Exstart, Exchange, Laden en Full. Er kunnen een aantal redenen zijn waarom de Open Shortest Path First (OSPF)-buren vastzitten in de Exstart/Exchange-staat. Dit document concentreert zich op een MTU wanverhouding tussen buren OSPF die in staat Exstart/Exchange resulteren. Voor meer informatie over het oplossen van problemen met OSPF raadpleegt u Problemen oplossen met OSPF.
Nadat twee OSPF-naburige routers bidirectionele communicatie tot stand hebben gebracht en de DR/BDR-selectie hebben voltooid (op multi-access netwerken), gaat de routerovergang naar de Exstart-status. In deze staat, vestigen de naburige routers een Primaire/Ondergeschikte verhouding en bepalen het aanvankelijke de opeenvolgingsaantal van de gegevensbestandbeschrijver (DBD) te gebruiken terwijl de pakketten DBD worden geruild.
Zodra de Primary/Subordinate
De verhouding is besproken (de router met hoogste router-ID wordt Primair), de overgang van buurrouters in de staat van de Uitwisseling. In deze staat, ruilen de routers DBD pakketten, die hun volledige verbinding-staat gegevensbestand beschrijven. De routers verzenden ook link-state verzoekpakketten, die om recentere link-state reclame (LSA) van buren verzoeken.
Hoewel OSPF-burenovergang door de staten Exstart/Exchange tijdens het normale OSPF-proces van nabijheidsopbouw is, is het niet normaal dat OSPF-buren in deze staat vastzitten. De volgende sectie beschrijft de meest voorkomende reden dat de buren OSPF vast komen te zitten in deze staat. Raadpleeg OSPF-buurstaten begrijpen om meer te weten te komen over de verschillende OSPF-staten.
Het probleem komt het vaakst voor wanneer u probeert om OSPF tussen een router van Cisco en een andere verkopersrouter in werking te stellen. Het probleem treedt op wanneer de instellingen van de maximale transmissie-eenheid (MTU) voor neighboring
de router interfaces passen niet aan. Als de router met de hogere MTU een pakket verzendt groter dat MTU op de naburige router wordt geplaatst, negeert de buurrouter het pakket. Wanneer dit probleem zich voordoet, verschijnt de uitvoer van de show ip ospf neighbor
Het bevel toont output gelijkend op wat in dit cijfer wordt getoond.
Router 6 en router 7 Connect via Frame Relay
In dit gedeelte wordt een feitelijke herhaling van dit probleem beschreven.
Router 6 en router 7 in dit cijfer worden aangesloten via Frame Relay en router 6 is geconfigureerd met 5 statische routes die in OSPF zijn herverdeeld. De seriële interface op router 6 heeft standaard MTU van 1500, terwijl de seriële interface op router 7 een MTU van 1450 heeft. Elke routerconfiguratie wordt in de tabel weergegeven (alleen de benodigde configuratieinformatie wordt weergegeven):
Routerconfiguratie 6 | Configuratie router 7 |
---|---|
interface Serial2 !--- MTU is set to its default value of 1500. no ip address no ip directed-broadcast encapsulation frame-relay no ip mroute-cache frame-relay lmi-type ansi ! interface Serial2.7 point-to-point ip address 10.170.10.6 255.255.255.0 no ip directed-broadcast frame-relay interface-dlci 101 ! router ospf 7 redistribute static subnets network 10.170.10.0 0.0.0.255 area 0 ! ip route 192.168.0.10 255.255.255.0 Null0 ip route 192.168.10.10 255.255.255.0 Null0 ip route 192.168.10.0 255.255.255.0 Null0 ip route 192.168.37.10 255.255.255.0 Null0 ip route 192.168.38.10 255.255.255.0 Null0 |
interface Serial0 mtu 1450 no ip address no ip directed-broadcast encapsulation frame-relay frame-relay lmi-type ANSI ! interface Serial0.6 point-to-point ip address 172.16.7.11 255.255.255.0 no ip directed-broadcast frame-relay interface-dlci 110 ! router ospf 7 network 172.16.11.6 0.0.0.255 area 0 |
De showip ospf buurbeveloutput voor elke router is:
router-6#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 172.16.7.11 1 EXCHANGE/ - 00:00:36 172.16.7.11 Serial2.7 router-6# router-7#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 10.170.10.6 1 EXSTART/ - 00:00:33 10.170.10.6 Serial0.6 router-7#
Het probleem doet zich voor wanneer router 6 een DBD-pakket verstuurt dat groter is dan 1450 bytes (router 7’s MTU) terwijl het zich in de uitwisselingsstatus bevindt. Gebruik de debug ip packet
en debug ip ospf adj
bevelen op elke router om het OSPF nabijheidsproces te zien aangezien het plaatsvindt. De output van router 6 en 7 van stap 1 tot en met 14 is:
Router 6 debug uitvoer:
<<<ROUTER 6 IS SENDING HELLOS BUT HEARS NOTHING, STATE OF NEIGHBOR IS DOWN>>>
00:03:53: OSPF: 172.16.7.11 address 172.16.7.11 on Serial2.7 is dead 00:03:53: OSPF: 172.16.7.11 address 172.16.7.11 on Serial2.7 is dead, state DOWN
Router 7 debug-uitvoer:
<<<OSPF NOT ENABLED ON ROUTER7 YET>>>
Router 6 debug uitvoer:
<<<ROUTER 6 SENDING HELLOS>>>
00:03:53: IP: s=10.170.10.6 (local), d=224.0.0.5 (Serial2.7), len 64, sending broad/multicast, proto=89 00:04:03: IP: s=10.170.10.6 (local), d=224.0.0.5 (Serial2.7), Len 64, sending broad/multicast, proto=89
Router 7 debug-uitvoer:
<<<OSPF NOT ENABLED ON ROUTER7 YET>>>
Router 7 debug-uitvoer:
<<<OSPF ENABLED ON ROUTER 7, BEGINS SENDING HELLOS AND BUILDING A ROUTER LSA>>>
00:17:44: IP: s=172.16.7.11 (local), d=224.0.0.5 (Serial0.6), Len 64, sending broad/multicast, proto=89 00:17:44: OSPF: Build router LSA for area 0, router ID 172.16.7.11, seq 0x80000001
Router 6 debug uitvoer:
<<<RECEIVE HELLO FROM ROUTER7>>>
00:04:04: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5, Len 64, rcvd 0, proto=89 00:04:04: OSPF: Rcv hello from 172.16.7.11 area 0 from Serial2.7 172.16.7.11 00:04:04: OSPF: End of hello processing
Router 6 debug uitvoer:
<<<ROUTER 6 SEND HELLO WITH ROUTER7 ROUTERID IN THE HELLO PACKET>>>
00:04:13: IP: s=10.170.10.6 (local), d=224.0.0.5 (Serial2.7), Len 68, sending broad/multicast, proto=89
Router 7 debug-uitvoer:
<<<ROUTER 7 RECEIVES HELLO FROM ROUTER6 CHANGES STATE TO 2WAY>>>
00:17:53: IP: s=10.170.10.6 (Serial0.6), d=224.0.0.5, Len 68, rcvd 0, proto=89 00:17:53: OSPF: Rcv hello from 10.170.10.6 area 0 from Serial0.6 10.170.10.6 00:17:53: OSPF: 2 Way Communication to 10.170.10.6 on Serial0.6, state 2WAY
Router 7 debug-uitvoer:
<<<ROUTER 7 SENDS INITIAL DBD PACKET WITH SEQ# 0x13FD>>>
00:17:53: OSPF: Send DBD to 10.170.10.6 on Serial0.6 seq 0x13FD opt 0x2 flag 0x7 Len 32 00:17:53: IP: s=172.16.7.11 (local), d=224.0.0.5 (Serial0.6), Len 52, sending broad/multicast, proto=89 00:17:53: OSPF: End of hello processing
Router 6 debug uitvoer:
<<<ROUTER 6 RECEIVES ROUTER7'S INITIAL DBD PACKET CHANGES STATE TO 2-WAY>>>
00:04:13: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5, Len 52, rcvd 0, proto=89 00:04:13: OSPF: Rcv DBD from 172.16.7.11 on Serial2.7 seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state INIT 00:04:13: OSPF: 2 Way Communication to 172.16.7.11 on Serial2.7, state 2WAY
Router 6 debug uitvoer:
<<<ROUTER 6 SENDS DBD PACKET TO ROUTER 7 (PRIMARY/SUBORDINATE
NEGOTIATION - ROUTER 6 ISSUBORDINATE
)>>>
00:04:13: OSPF: Send DBD to 172.16.7.11 on Serial2.7
seq 0xE44 opt 0x2 flag 0x7 Len 32
00:04:13: IP: s=10.170.10.6 (local), d=224.0.0.5 (Serial2.7),
Len 52, sending broad/multicast, proto=89
00:04:13: OSPF: NBR Negotiation Done. We are theSLAVE
Router 7 debug-uitvoer:
<<<RECEIVE ROUTER 6'S INITIAL DBD PACKET (MTU MISMATCH IS RECOGNIZED)>>>
00:17:53: IP: s=10.170.10.6 (Serial0.6), d=224.0.0.5, Len 52, rcvd 0, proto=89 00:17:53: OSPF: Rcv DBD from 10.170.10.6 on Serial0.6 seq 0xE44 opt 0x2 flag 0x7 Len 32 mtu 1500 state EXSTART 00:17:53: OSPF: Nbr 10.170.10.6 has larger interface MTU
Router 6 debug uitvoer:
<<<SINCE ROUTER 6 ISSUBORDINATE
SEND DBD PACKET WITH LSA HEADERS, SAME SEQ# (0x13FD) TO ACK ROUTER 7'S DBD. (NOTE SIZE OF PKT)>>>
00:04:13: OSPF: Send DBD to 172.16.7.11 on Serial2.7
seq 0x13FD opt 0x2 flag 0x2 Len 1472
00:04:13: IP: s=10.170.10.6 (local), d=224.0.0.5 (Serial2.7),
Len 1492, sending broad/multicast, proto=89
Router 7 debug-uitvoer:
<<<NEVER RECEIVE ACK TO ROUTER7'S INITIAL DBD, RETRANSMIT>>>
00:17:54: IP: s=172.16.7.11 (local), d=224.0.0.5 (Serial0.6), Len 68, sending broad/multicast, proto=89 00:18:03: OSPF: Send DBD to 10.170.10.6 on Serial0.6 seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: Retransmitting DBD to 10.170.10.6 on Serial0.6 [1]
Op dit punt blijft router 6 proberen om het eerste DBD-pakket van router 7 te ACC.
00:04:13: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5, Len 68, rcvd 0, proto=89 00:04:13: OSPF: Rcv hello from 172.16.7.11 area 0 from Serial2.7 172.16.7.11 00:04:13: OSPF: End of hello processing 00:04:18: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5, Len 52, rcvd 0, proto=89 00:04:18: OSPF: Rcv DBD from 172.16.7.11 on Serial2.7 seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state EXCHANGE 00:04:18: OSPF: Send DBD to 172.16.7.11 on Serial2.7 seq 0x13FD opt 0x2 flag 0x2 Len 1472 00:04:18: IP: s=10.170.10.6 (local), d=224.0.0.5 (Serial2.7), Len 1492, sending broad/multicast, proto=89 00:04:23: IP: s=10.170.10.6 (local), d=224.0.0.5 (Serial2.7), Len 68, sending broad/multicast, proto=89 00:04:23: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5, Len 52, rcvd 0, proto=89 00:04:23: OSPF: Rcv DBD from 172.16.7.11 on Serial2.7 seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state EXCHANGE
Router 7 krijgt nooit een ACK van router 6 omdat het DBD-pakket van router 7 te groot is voor router 7 MTU. Router 7 brengt herhaaldelijk het DBD pakket opnieuw over.
0:17:58: IP: s=172.16.7.11 (local), d=224.0.0.5 (Serial0.6), Len 52, sending broad/multicast, proto=89 00:18:03: OSPF: Send DBD to 10.170.10.6 on Serial0.6 seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: Retransmitting DBD to 10.170.10.6 on Serial0.6 [2] 00:18:03: IP: s=172.16.7.11 (local), d=224.0.0.5 (Serial0.6), Len 52, sending broad/multicast, proto=89 00:18:03: IP: s=10.170.10.6 (Serial0.6), d=224.0.0.5, Len 68, rcvd 0, proto=89 00:18:03: OSPF: Rcv hello from 10.170.10.6 area 0 from Serial0.6 10.170.10.6 00:18:03: OSPF: End of hello processing 00:18:04: IP: s=172.16.7.11 (local), d=224.0.0.5 (Serial0.6), Len 68, sending broad/multicast, proto=89 00:18:03: OSPF: Send DBD to 10.170.10.6 on Serial0.6 seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: Retransmitting DBD to 10.170.10.6 on Serial0.6 [3] 00:18:08: IP: s=172.16.7.11 (local), d=224.0.0.5 (Serial0.6), Len 52, sending broad/multicast, proto=89 router-7#
Omdat router 6 een hogere MTU heeft, blijft het DBD-pakket van router 7 accepteren, probeert ze te erkennen en blijft het in de Exchange-staat.
Omdat router 7 een lagere MTU heeft, negeert het de DBD-pakketten samen met ACK van router 6, blijft het het eerste DBD-pakket opnieuw verzenden en blijft het in de EXSTART-staat.
In stap 9 en 11 verzenden router 7 en router 6 hun eerste DBD-pakketten met vlag 0x7 als deel van Primaire/Ondergeschikte onderhandeling. Na Primary/Subordinate
In de meeste gevallen is router 7 gekozen als primair vanwege de hogere router-ID. De vlaggen in stap 13 en 14 tonen duidelijk aan dat router 7 primair is (vlag 0x7) en router 6 ondergeschikt is (vlag 0x2).
In stap 10, ontvangt router 6 het router 7 eerste pakket DBD en overweegt zijn staat aan 2-way.
In stap 12, ontvangt router 7 het router 6 eerste DBD pakket en herkent een MTU wanverhouding. (Router 7 kan een MTU mismatch herkennen omdat router 6 zijn interface MTU in het interface MTU veld van het DBD pakket omvat). Router 6 aanvankelijke DBD wordt verworpen door router 7. Router 7 brengt het aanvankelijke DBD pakket opnieuw over.
Stap 13 toont aan dat router 6, zoals subordinate
, keurt router 7 opeenvolgingsaantal goed en verzendt zijn tweede pakket DBD dat de kopballen van zijn LSAs bevat, dat de grootte van het pakket verhoogt. Router 7 ontvangt echter nooit dit DBD-pakket omdat het groter is dan de router 7 MTU.
Na stap 13 blijft router 7 het eerste DBD-pakket opnieuw verzenden naar router 6, terwijl router 6 DBD-pakketten blijft verzenden die zich aan het primaire volgnummer houden. Deze lijn gaat voor onbepaalde tijd door, wat beide router verhindert om uit de exstart/uitwisselingsstaat over te gaan.
Aangezien het probleem wordt veroorzaakt door slecht afgestemde MTUs, is de oplossing om één van beide router MTU te veranderen om buurMTU aan te passen.
Opmerking: Cisco IOS-softwarerelease 12.0(3) introduceerde detectie van mismatch van interface-MTU. Deze detectie omvat de OSPF die de interface MTU in de DBD-pakketten adverteert, wat in overeenstemming is met de OSPF RFC 2178, appendix G.9. Wanneer een router een DBD pakket ontvangt dat een MTU groter is geadverteerd dan de router kan ontvangen, negeert de router het DBD pakket en de buurstaat blijft in Exstart. Dit voorkomt de vorming van een nabijheid. Om dit probleem op te lossen, zorg ervoor dat de MTU aan beide uiteinden van een verbinding het zelfde zijn.
In Cisco IOS-softwarerelease 12.01(3) is de opdracht ip ospf mtu-ignore interfaceconfiguratie ook geïntroduceerd om de MTU-detectie van mismatches uit te schakelen; dit is echter alleen nodig in zeldzame gevallen, zoals in dit diagram wordt getoond:
Fibre Distributed Data Interface (FDDI)-poort
Het vorige diagram toont een Fibre Distributed Data Interface (FDDI)-poort op een Cisco Catalyst 5000 met een Route Switch Module (RSM) die is aangesloten op een FDDI-interface op router 2. Virtuele LAN (VLAN) op de RSM is een virtuele Ethernet-interface met een MTU van 1500 en de FDDI-interface op router 2 heeft een MTU van 4500. Wanneer een pakket wordt ontvangen op de FDDI-poort van de switch, gaat het naar de backplane en gebeurt de FDDI naar Ethernet conversie/fragmentatie binnen de switch zelf. Dit is een geldige opstelling, maar met de eigenschap van de mismatch MTU, wordt de nabijheid OSPF niet gevormd tussen de router en RSM. Aangezien FDDI en Ethernet MTU verschillend zijn, is deze ip ospf mtu-negeer opdracht nuttig op de VLAN-interface van de RSM om OSPF-detectie van MTU-mismatch te stoppen en vormt deze de nabijheid.
Het is belangrijk om op te merken dat MTU wanverhouding, hoewel de meest voorkomende, is niet de enige reden dat OSPF buren vast komen te zitten in de Exstart/Exchange staat. Het probleem wordt het vaakst veroorzaakt door het onvermogen om DBD-pakketten met succes uit te wisselen. De diepere oorzaak kan echter een van de volgende zijn:
MTU-wanverhouding
Unicast is kapot. In de staat Exstart stuurt de router een unicastpakket naar de buur om Primair en Ondergeschikt te selecteren. Dit is waar tenzij u een point-to-point link hebt, in welk geval het een multicast pakket verstuurt. Dit zijn de mogelijke oorzaken:
Verkeerde VC-toewijzing (Virtual Circuit) in een ATM-omgeving (Asynchronous Transfer Mode) of Frame Relay in een zeer redundant netwerk.
MTU probleem, wat betekent dat de routers alleen een pakket van een bepaalde lengte kunnen pingen.
De toegangslijst blokkeert het unicastpakket.
NAT wordt op de router uitgevoerd en het unicastpakket vertaald.
Buren tussen PRI en BRI/dialer.
Beide routers hebben dezelfde router-ID (fout-configuratie).
Daarnaast verklaart de OSPF RFC 2328, sectie 10.3, dat het Exstart/Exchange-proces is gestart voor een van deze gebeurtenissen (waarvan een van deze kan worden veroorzaakt door interne softwareproblemen):
Mismatch van volgnummer.
Onverwacht DD-volgnummer.
"I" bit is onverwacht ingesteld.
Optieveld anders dan het laatste optieveld dat in het DBD-pakket is ontvangen.
BadLSReq
De buur verzendt niet-herkende LSA tijdens uitwisselingsproces.
De buur vroeg een LSA tijdens uitwisselingsproces aan dat niet kan worden gevonden.
Wanneer OSPF geen buren vormt, overweeg de eerder vermelde factoren, zoals de fysieke media en netwerkhardware, om het probleem problemen op te lossen.
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
2.0 |
18-Sep-2023 |
Hercertificering |
1.0 |
10-Dec-2001 |
Eerste vrijgave |