Risoluzione dei problemi relativi ai primi vicini del percorso più breve aperto bloccati nello stato Exstart/Exchange

Introduzione

In questo documento viene descritto come risolvere i problemi relativi a situazioni in cui i router adiacenti Open Shortest Path First (OSPF) sono bloccati negli stati Exstart ed Exchange. 

Prerequisiti

Requisiti

È consigliabile che l'utente abbia familiarità con il funzionamento e la configurazione di base di OSPF, in particolare con gli stati adiacenti di OSPF.

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

• Cisco 2503 router

• Software Cisco IOS^® versione 12.2(24a) da eseguire su entrambi i router

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Premesse

Gli stati OSPF per la formazione delle adiacenze sono Down, Init, 2-way, Exstart, Exchange, Loading e Full. I router adiacenti OSPF (Open Shortest Path First) sono bloccati nello stato Exstart/Exchange per diversi motivi. Nel documento si fa riferimento a una mancata corrispondenza MTU tra router adiacenti OSPF che determina lo stato Exstart/Exchange. Per ulteriori informazioni sulla risoluzione dei problemi relativi a OSPF, vedere Risoluzione dei problemi comuni relativi a OSPF.

Stato Exstart

Dopo che due router adiacenti OSPF hanno stabilito la comunicazione bidirezionale e completato l'elezione di DR/BDR (su reti ad accesso multiplo), i router passano allo stato Exstart. In questo stato, i router adiacenti stabiliscono una relazione primaria/subordinata e determinano il numero di sequenza del descrittore di database iniziale (DBD) da utilizzare durante lo scambio dei pacchetti DBD.

Stato Exchange

Una volta che Primary/Subordinate La relazione è stata negoziata (il router con l'ID più alto diventa il router primario), i router adiacenti passano allo stato Exchange. In questo stato, i router si scambiano i pacchetti DBD che descrivono l'intero database dello stato del collegamento. I router inviano anche pacchetti di richieste allo stato del collegamento, che richiedono annunci allo stato del collegamento (LSA) più recenti dai router adiacenti.

Sebbene i vicini OSPF eseguano la transizione attraverso gli stati Exstart/Exchange durante il normale processo di costruzione delle adiacenze OSPF, non è normale che i vicini OSPF siano bloccati in questo stato. Nella sezione successiva viene descritto il motivo più comune per cui i router adiacenti OSPF rimangono bloccati in questo stato. Per ulteriori informazioni sui diversi stati OSPF, fare riferimento a Descrizione degli stati adiacenti OSPF.

Vicini bloccati nello stato Exstart/Exchange

Il problema si verifica più frequentemente quando si tenta di eseguire OSPF tra un router Cisco e un altro router del fornitore. Il problema si verifica quando le impostazioni MTU (Maximum Transmission Unit) per neighboring le interfacce del router non corrispondono. Se il router con l'MTU più alta invia un pacchetto più grande di quello impostato sul router adiacente, il router adiacente ignora il pacchetto. Quando si verifica questo problema, l'output del show ip ospf neighbor Il comando visualizza un output simile a quello illustrato nella figura.

Router 6 e Router 7 per la connessione tramite Frame Relay

In questa sezione viene descritto come ricreare il problema.

Il router 6 e il router 7 in questa figura sono connessi tramite Frame Relay e il router 6 è stato configurato con 5 route statiche ridistribuite in OSPF. L'interfaccia seriale sul router 6 ha una MTU predefinita di 1500, mentre l'interfaccia seriale sul router 7 ha una MTU di 1450. Nella tabella viene mostrata la configurazione di ciascun router (vengono mostrate solo le informazioni di configurazione necessarie):

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

L'output del comando show ip ospf neighbors per ciascun router è:

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#

Il problema si verifica quando il router 6 invia un pacchetto DBD di dimensioni superiori a 1450 byte (MTU del router 7) nello stato Exchange. Utilizzare il debug ip packet e debug ip ospf adj dei comandi su ciascun router per verificare il processo di adiacenza OSPF man mano che si verifica. L'output dei passaggi da 1 a 14 del router 6 e 7 è:

1. Output debug router 6:

   <<<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. Output debug router 7:

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

3. Output debug router 6:

   <<<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. Output debug router 7:

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

5. Output debug router 7:

   <<<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. Output debug router 6:

   <<<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. Output debug router 6:

   <<<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. Output debug router 7:

   <<<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. Output debug router 7:

   <<<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. Output debug router 6:

    <<<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. Output debug router 6:

    <<<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. Output debug router 7:

    <<<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. Output debug router 6:

    <<<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. Output debug router 7:

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

A questo punto, il router 6 continua a tentare di eseguire il ACK del pacchetto DBD iniziale dal router 7.

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

Il router 7 non riceve mai un ACK dal router 6 perché il pacchetto DBD inviato dal router 7 è troppo grande per l'MTU del router 7. Il router 7 ritrasmette ripetutamente il pacchetto DBD.

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#

Poiché il router 6 ha una MTU più alta, continua ad accettare il pacchetto DBD dal router 7, a tentare di riconoscerlo e a rimanere nello stato EXCHANGE.

Poiché il router 7 ha una MTU inferiore, ignora i pacchetti DBD insieme al pacchetto ACK inviato dal router 6, continua a trasmettere il pacchetto DBD iniziale e rimane nello stato EXSTART.

Nei passaggi 9 e 11, il router 7 e il router 6 inviano i primi pacchetti DBD con il flag 0x7 impostato come parte della negoziazione primaria/subordinata. Dopo Primary/Subordinate Il router 7 viene scelto come principale a causa del suo ID router più elevato. I flag nei passaggi 13 e 14 mostrano chiaramente che il router 7 è primario (flag 0x7) e il router 6 è subordinato (flag 0x2).

Nel passaggio 10, il router 6 riceve il pacchetto DBD iniziale del router 7 e passa il suo stato a 2 vie.

Nel passaggio 12, il router 7 riceve il pacchetto DBD iniziale del router 6 e riconosce una mancata corrispondenza MTU. (Il router 7 è in grado di riconoscere una mancata corrispondenza MTU perché il router 6 include la MTU dell'interfaccia nel campo MTU dell'interfaccia del pacchetto DBD). Il DBD iniziale del router 6 viene rifiutato dal router 7. Il router 7 ritrasmette il pacchetto DBD iniziale.

Il passo 13 mostra che il router 6, come subordinate, adotta il numero di sequenza del router 7 e invia il secondo pacchetto DBD contenente le intestazioni delle LSA, con cui aumentano le dimensioni del pacchetto. Tuttavia, il router 7 non riceve mai questo pacchetto DBD perché è più grande dell'MTU del router 7.

Dopo il passaggio 13, il router 7 continua a trasmettere il pacchetto DBD iniziale al router 6, mentre il router 6 continua a inviare pacchetti DBD che rispettano il numero di sequenza principale. Questo loop continua all'infinito, impedendo a entrambi i router di uscire dallo stato exstart/exchange.

Soluzione

Poiché il problema è causato da MTU non corrispondenti, la soluzione è modificare l'MTU di uno dei router in modo che corrisponda all'MTU dell'altro router.

Nota: il software Cisco IOS versione 12.0(3) ha introdotto il rilevamento della mancata corrispondenza MTU dell'interfaccia. Questo rilevamento coinvolge l'OSPF che annuncia l'MTU dell'interfaccia nei pacchetti DBD, in conformità alla RFC 2178 dell'OSPF, appendice G.9. Quando un router riceve un pacchetto DBD annunciato con una MTU più grande di quella che può ricevere, il router ignora il pacchetto DBD e lo stato del router adiacente rimane in Exstart. Ciò impedisce la formazione di un'adiacenza. Per risolvere il problema, verificare che l'MTU sia la stessa su entrambe le estremità di un collegamento.

Nel software Cisco IOS versione 12.01(3), il comando di configurazione dell'interfaccia ip ospf mtu-ignore è stato introdotto anche per disattivare il rilevamento della mancata corrispondenza MTU. Tuttavia, questa operazione è necessaria solo in rare istanze, come mostrato nel diagramma:

Porta FDDI (Fiber Distributed Data Interface)

Il diagramma precedente mostra una porta FDDI (Fibre Distributed Data Interface) su un Cisco Catalyst 5000 con un Route Switch Module (RSM) collegato a un'interfaccia FDDI sul router 2. La VLAN virtuale (VLAN) sull'RSM è un'interfaccia Ethernet virtuale con una MTU di 1500, mentre l'interfaccia FDDI sul router 2 ha una MTU di 4500. Quando si riceve un pacchetto sulla porta FDDI dello switch, il pacchetto viene inviato al backplane e la conversione/frammentazione da FDDI a Ethernet avviene all'interno dello switch stesso. Si tratta di un'installazione valida, ma con la funzione di rilevamento della mancata corrispondenza MTU, la adiacenza OSPF non viene formata tra il router e l'RSM. Poiché le MTU FDDI ed Ethernet sono diverse, questo comando ip ospf mtu-ignore è utile sull'interfaccia VLAN dell'RSM per arrestare il rilevamento OSPF di MTU non corrispondenti e formare l'adiacenza.

È importante notare che la mancata corrispondenza MTU, sebbene la più comune, non è l'unica ragione per cui i router adiacenti OSPF rimangono bloccati nello stato Exstart/Exchange. Il problema è spesso causato dall'impossibilità di scambiare correttamente i pacchetti DBD. Tuttavia, la causa principale potrebbe essere una delle seguenti:

• MTU non corrispondente

• Unicast interrotto. Nello stato Exstart, il router invia un pacchetto unicast al router adiacente per selezionare il pacchetto primario e quello subordinato. Ciò è vero a meno che non si disponga di un collegamento point-to-point, nel qual caso invia un pacchetto multicast. Queste sono le possibili cause:

  • Mappatura errata del circuito virtuale (VC) in un ambiente ATM (Asynchronous Transfer Mode) o Frame Relay in una rete altamente ridondante.

  • Problema MTU, ossia i router possono eseguire il ping solo su un pacchetto di una determinata lunghezza.

  • L'elenco degli accessi blocca il pacchetto unicast.

  • Il protocollo NAT viene eseguito sul router e converte il pacchetto unicast.

• Vicino tra PRI e BRI/dialer.

• Entrambi i router hanno lo stesso ID router (configurazione errata).

Inoltre, la RFC 2328 dell'OSPF, sezione 10.3, afferma che il processo Exstart/Exchange viene avviato per uno qualsiasi di questi eventi (uno qualsiasi dei quali potrebbe essere causato da problemi interni al software):

• Numero di sequenza non corrispondente.

  • Numero di sequenza DD imprevisto.

  • Il bit "I" è impostato in modo imprevisto.

  • Il campo Option (Opzione) è diverso dall'ultimo campo option (Opzioni) ricevuto nel pacchetto DBD.

• AccodamentoLSRirregolare

  • Il router adiacente invia una LSA non riconosciuta durante il processo di scambio.

  • Il router adiacente ha richiesto una LSA durante il processo di scambio che non è stato trovato.

Quando OSPF non forma un router adiacente, considerare i fattori menzionati in precedenza, ad esempio i supporti fisici e l'hardware di rete, per risolvere il problema.

Informazioni correlate

• Stati router adiacenti OSPF
• Spiegazione dei problemi dei router adiacenti OSPF
• Supporto tecnico e download Cisco