Inhoud

Inleiding

Voorwaarden

Vereisten

Gebruikte componenten

Conventies

Achtergrondinformatie

Uitloopstatus

Wisselstaat

Buren vastzitten in Exstart/Exchange State

Oplossing

Gerelateerde informatie

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 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 Probleemoplossing 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 te gebruiken opeenvolgingsaantal van de gegevensbestandbeschrijver (DBD) terwijl de pakketten DBD worden geruild.

Wisselstaat

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. Verwijs naar OSPF buurstaten om meer over de verschillende staten te leren OSPF.

Buren vastzitten 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 treedt op wanneer de instellingen van de maximale transmissieeenheid (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 deshow 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 dedebug ip packeten debug ip ospf adjbevelen 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 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 het primaire volgnummer volgen. 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 OSPFRFC 2178, appendix G.9. Wanneer een router een DBD-pakket ontvangt dat een MTU groter is 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 hetzelfde zijn aan beide uiteinden van een link.

In Cisco IOS-softwarerelease 12.01(3)STip ospf mtu-ignorede opdracht voor de interfaceconfiguratie is ook geïntroduceerd om de detectie van mismatch MTU uit te schakelen; dit is echter slechts in zeldzame gevallen nodig, 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 Routeinterfacemodule (RSM) die is aangesloten op een FDDI-Switch op router 2. Virtual LAN (VLAN) op de RSM is een Virtual 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, wordt ditip ospf mtu-ignoreHet bevel is nuttig op de interface van VLAN van RSM om OSPF opsporing van wanverhouding tegen te houden MTU en vormt 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 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 bepaalt OSPFRFC 2328, paragraaf 10.3, dat het Exstart/Exchange-proces wordt gestart voor een van deze gebeurtenissen (waarvan er een 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

- OSPF-buurstaten

- OSPF-buurproblemen toegelicht

- Technische ondersteuning – Cisco Systems