Probleemoplossing voor OSPF-buren die vastzitten in de status Exstart/Exchange

Inleiding

Dit document beschrijft hoe u problemen kunt oplossen in situaties waarin Open Shortest Path First (OSPF)-buren vastzitten in Exstart- en Exchange-staten. 

Voorwaarden

Vereisten

Men adviseert dat de gebruiker met basisverrichting OSPF en configuratie, in het bijzonder, OSPF buurstaten vertrouwd is.

Gebruikte componenten

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.

Conventies

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

Achtergrondinformatie

OSPF-staten voor nabijheidsvorming zijn Down, Init, 2 way, Exstart, Exchange, Laden en Full. Er kunnen een aantal redenen zijn waarom de Open Kortste Weg Eerste (OSPF) buren in staat Exstart/Exchange vastzitten. 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.

Uitloopstatus

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.

Wisselstaat

Zodra de Primary/Subordinate relatie is onderhandeld (de router met de hoogste router-ID wordt de Primaire), de buurrouters overgang naar de Exchange-staat. 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.

Buren vastgeklemd in Exstart/Exchange State

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 doet zich voor wanneer de instellingen van de maximale transmissie-eenheid (MTU) voor neighboring routerinterfaces niet overeenkomen. 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, toont de output van hetshow ip ospf neighborbevel output gelijkend op wat in dit cijfer wordt getoond.

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):

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:

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 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 bepaling, wordt router 7 verkozen als Primair wegens zijn 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, router 7 opeenvolgingsaantal goedkeurt en zijn tweede pakket DBD verzendt dat de kopballen van zijn LSAs bevat, die 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.

Oplossing

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 wordt geadverteerd, kan een MTU groter dan de router 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:

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.

Gerelateerde informatie

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