Problemen oplossen met OSPF-buren die vastzitten in Exstart/Exchange-status

Inleiding

In dit document wordt beschreven hoe u problemen kunt oplossen in situaties waarin Open Shortest Path First (OSPF)-buren vastzitten in de status Exstart en Exchange. 

Voorwaarden

Vereisten

Het wordt aanbevolen dat de gebruiker bekend is met de basiswerking en configuratie van OSPF, met name de buurstaten van OSPF.

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

• Cisco 2503-routers

• Cisco IOS^® Software Release 12.2(24a) voor 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.

Conventies

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

Achtergrondinformatie

OSPF stelt voor aangrenzende formatie dat er Down, Init, 2-way, Exstart, Exchange, Loading en Full zijn. Er kunnen een aantal redenen zijn waarom de buren van Open Shortest Path First (OSPF) vastzitten in de status Exstart/Exchange. Dit document richt zich op een MTU mismatch tussen OSPF buren die resulteren in Exstart / Exchange staat. Voor meer informatie over het oplossen van OSPF-problemen, raadpleegt u Problemen met OSPF oplossen.

Exstart-status

Nadat twee aangrenzende OSPF-routers bidirectionele communicatie tot stand hebben gebracht en DR/BDR-selectie hebben voltooid (op netwerken met meerdere toegang), gaan de routers over naar de Exstart-status. In deze toestand stellen de aangrenzende routers een primaire/ondergeschikte relatie vast en bepalen ze het initiële volgnummer van de database descriptor (DBD) dat moet worden gebruikt terwijl de DBD-pakketten worden uitgewisseld.

Wisselstaat

Zodra de Primary/Subordinate relatie is onderhandeld (de router met de hoogste Router-ID wordt de primaire), de buur routers overgang naar de Exchange-status. In deze toestand wisselen de routers DBD-pakketten uit, die hun volledige linkstatusdatabase beschrijven. De routers sturen ook link-state verzoekpakketten, die recentere link-state advertenties (LSA) van buren vragen.

Hoewel OSPF-buren tijdens het normale OSPF-aangrenzende bouwproces door de Exstart / Exchange-staten gaan, is het niet normaal dat OSPF-buren in deze toestand vastzitten. In het volgende gedeelte wordt de meest voorkomende reden beschreven waarom OSPF-buren in deze staat vastlopen. Raadpleeg OSPF-buurstaten begrijpen om meer te weten te komen over de verschillende OSPF-staten.

Buurtbewoners vast in Exstart / Exchange State

Het probleem treedt het vaakst op wanneer u OSPF probeert uit te voeren tussen een Cisco-router en een andere router van de leverancier. Het probleem treedt op wanneer de instellingen voor de maximale transmissie-eenheid (MTU) voor neighboring routerinterfaces niet overeenkomen. Als de router met de hogere MTU een groter pakket verzendt dan de MTU op de naburige router, negeert de buur-router het pakket. Wanneer dit probleem zich voordoet, geeft de uitvoer van deshow ip ospf neighboropdracht een uitvoer weer die vergelijkbaar is met de uitvoer die in deze afbeelding wordt weergegeven.

In dit gedeelte wordt een werkelijke herschepping van dit probleem beschreven.

Router 6 en Router 7 in deze figuur zijn verbonden via Frame Relay en Router 6 is geconfigureerd met 5 statische routes herverdeeld in OSPF. De seriële interface op Router 6 heeft de standaard MTU van 1500, terwijl de seriële interface op Router 7 een MTU van 1450 heeft. Elke routerconfiguratie wordt weergegeven in de tabel (alleen de benodigde configuratie-informatie wordt weergegeven):

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 uitvoer van de opdracht ip ospf 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 treedt op wanneer Router 6 een DBD-pakket verzendt dat groter is dan 1450 bytes (MTU van Router 7) terwijl het zich in de uitwisselingsstatus bevindt. Gebruik de debug ip packet en debug ip ospf adj opdrachten op elke router om het OSPF-aangrenzende proces te zien terwijl het plaatsvindt. De uitvoer van Router 6 en 7 van stap 1 tot en met 14 is:

1. 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

2. Router 7 debug-uitvoer:

   <<<OSPF NOT ENABLED ON ROUTER7 YET>>>

3. 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

4. Router 7 debug-uitvoer:

   <<<OSPF NOT ENABLED ON ROUTER7 YET>>>

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. Router 6 debug-uitvoer:

    <<<ROUTER 6 SENDS DBD PACKET TO ROUTER 7 (PRIMARY/SUBORDINATE NEGOTIATION - ROUTER 6 IS SUBORDINATE)>>>
    
    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 the SLAVE

12. 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 

13. Router 6 debug-uitvoer:

    <<<SINCE ROUTER 6 IS SUBORDINATE 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

14. 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 het oorspronkelijke DBD-pakket van Router 7 te ACK.

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 de Router 7 MTU. Router 7 zendt het DBD-pakket herhaaldelijk opnieuw uit.

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 het DBD-pakket van Router 7 accepteren, probeert het deze te erkennen en blijft het in de EXCHANGE-status.

Omdat Router 7 een lagere MTU heeft, negeert het de DBD-pakketten samen met ACK van Router 6, blijft het het oorspronkelijke DBD-pakket opnieuw verzenden en blijft het in de EXSTART-status.

In stap 9 en 11 verzenden Router 7 en Router 6 hun eerste DBD-pakketten met vlag 0x7 ingesteld als onderdeel van primaire / ondergeschikte onderhandeling. Router 7 wordt Primary/Subordinate gekozen als Primair vanwege zijn hogere Router-ID. De vlaggen in stap 13 en 14 laten duidelijk zien dat Router 7 Primair is (Vlag 0x7) en Router 6 Ondergeschikt is (Vlag 0x2).

In stap 10 ontvangt Router 6 het Router 7 initiële DBD-pakket en gaat de status over naar 2-weg.

In stap 12 ontvangt Router 7 het Router 6 initiële DBD-pakket en herkent een MTU-mismatch. (Router 7 kan een MTU-mismatch herkennen omdat Router 6 zijn interface MTU in het interface MTU-veld van het DBD-pakket bevat). De Router 6 initiële DBD wordt afgewezen door Router 7. Router 7 zendt het oorspronkelijke DBD-pakket opnieuw uit.

Stap 13 laat zien dat Router 6, zoals subordinatehierboven beschreven, het volgnummer van Router 7 gebruikt en zijn tweede DBD-pakket verzendt dat de headers van zijn LSA's bevat, waardoor de grootte van het pakket toeneemt. Router 7 ontvangt dit DBD-pakket echter nooit 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 houden aan het primaire volgnummer. Deze lus gaat voor onbepaalde tijd door, waardoor een van beide routers de overgang uit de exstart / uitwisselingsstatus voorkomt.

Oplossing

Omdat het probleem wordt veroorzaakt door niet-overeenkomende MTU's, is de oplossing om beide router MTU te wijzigen om overeen te komen met de buurman MTU.

Opmerking: Cisco IOS Software Release 12.0(3) introduceerde MTU-mismatchdetectie. Deze detectie omvat de OSPF die de MTU-interface in de DBD-pakketten adverteert, wat in overeenstemming is met de OSPF RFC 2178, bijlage G.9. Wanneer een router een DBD-pakket ontvangt dat wordt geadverteerd, een MTU groter dan de router kan ontvangen, negeert de router het DBD-pakket en blijft de buurstaat in Exstart. Dit voorkomt de vorming van een nabijheid. Om dit probleem op te lossen, moet u ervoor zorgen dat de MTU aan beide uiteinden van een koppeling hetzelfde zijn.

In Cisco IOS Software 10 .01(3), werd ook de ip ospf mtu-ignore interface configuratie commando geïntroduceerd om de MTU mismatch detectie uit te schakelen; dit is echter alleen nodig in zeldzame gevallen, zoals getoond in dit diagram:

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. Het Virtual 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 vindt de FDDI naar Ethernet-conversie / fragmentatie plaats in de switch zelf. Dit is een geldige configuratie, maar met de MTU-detectiefunctie voor mismatches wordt er geen OSPF-nabijheid gevormd tussen de router en de RSM. Omdat FDDI en Ethernet MTU verschillen, is deze ip ospf mtu-ignore opdracht handig op de VLAN interface van de RSM om OSPF detectie van MTU mismatch te stoppen en vormt de nabijheid.

Het is belangrijk op te merken dat MTU-mismatch, hoewel de meest voorkomende, niet de enige reden is dat OSPF-buren vastlopen in de Exstart / Exchange-status. Het probleem wordt meestal veroorzaakt door het onvermogen om DBD-pakketten succesvol uit te wisselen. De hoofdoorzaak kan echter een van de volgende zijn:

• MTU-mismatch

• Unicast is kapot. In de Exstart-status stuurt de router een unicastpakket naar de buurman om Primair en Ondergeschikt te selecteren. Dit is waar, tenzij u een point-to-point link hebt, in welk geval het een multicast-pakket verzendt. Dit zijn de mogelijke oorzaken:

  • Verkeerde toewijzing van virtuele circuits (VC's) in een Asynchronous Transfer Mode (ATM)- of Frame Relay-omgeving 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 unicast-pakket.

  • NAT draait op de router en vertaalt het unicast-pakket.

• Buurman tussen PRI en BRI/dialer.

• Beide routers hebben dezelfde Router-ID (mis-configuratie).

Bovendien wordt in de OSPF RFC 2328, sectie 10.3, vermeld dat het Exstart/Exchange-proces wordt gestart voor elk van deze gebeurtenissen (die allemaal kunnen worden veroorzaakt door interne softwareproblemen):

• Volgnummer komt niet overeen.

  • Onverwacht DD-volgnummer.

  • Het "I"-bit wordt onverwachts ingesteld.

  • Optieveld dat verschilt van het laatste optieveld dat in het DBD-pakket is ontvangen.

• BadLSReq

  • Buurman verzendt niet-erkende LSA tijdens het uitwisselingsproces.

  • Buurman vroeg een LSA aan tijdens het uitwisselingsproces dat niet kan worden gevonden.

Wanneer OSPF geen buren vormt, moet u rekening houden met de eerder genoemde factoren, zoals de fysieke media en netwerkhardware, om het probleem op te lossen.

Gerelateerde informatie

• Begrijp OSPF buurstaten
• Problemen met OSPF-buren oplossen
• Cisco Technical Support en downloads