Perché OSPF non forma l'adiacenza su un'interfaccia PRI, BRI o Dialer?
Sommario
Introduzione
Questa nota tecnica spiega un problema con la formazione dell'adiacenza OSPF quando le interfacce dialer sono configurate come collegamenti point-to-point.
Prerequisiti
Requisiti
Nessun requisito specifico previsto per questo documento.
Componenti usati
Il documento può essere consultato per tutte le versioni software o hardware.
Convenzioni
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
Il problema
Il tipo di rete OSPF su PRI (Primary Rate Interface), BRI (Basic Rate Interface) e interfacce dialer è point-to-point, il che significa che un'interfaccia non può essere adiacente a più di un router adiacente. Un problema comune quando un'interfaccia PRI, BRI o dialer tenta di formare una adiacenza OSPF è che il router adiacente rimane bloccato nel processo exstart/exchange. Vediamo un esempio.
Utilizzando il comando show ip ospf neighbors, è possibile verificare che lo stato del router adiacente è bloccato in "EXSTART".
RTR-A# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 3.3.3.3 1 EXSTART/ - 00:00:37 3.3.3.3 Serial6/0:23 3.3.3.4 1 EXSTART/ - 00:00:39 3.3.3.4 Serial6/0:23 RTR-B# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 3.3.3.2 1 EXSTART/ - 00:00:36 3.3.3.2 BRI0 RTR-C# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 3.3.3.2 1 EXSTART/ - 00:00:35 3.3.3.2 BRI0
La configurazione RTR-Bs mostra che il tipo di rete è point-to-point:
RTR-B# show ip ospf interface bri0
BRI0 is up, line protocol is up (spoofing)
Internet Address 3.3.3.3/24, Area 2
Process ID 1, Router ID 3.3.3.3, Network Type POINT_TO_POINT, Cost: 1562
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:06
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
Per eseguire il debug della situazione, usare il comando debug ip ospf adj. Di seguito viene riportato un esempio di output generato durante l'esecuzione di questo comando su RTR-B nella figura precedente:
1: Send DBD to 3.3.3.2 on BRI0 seq 0xB41 opt 0x42 flag 0x7 len 32
2: Rcv DBD from 3.3.3.2 on BRI0 seq 0x1D06 opt 0x42 flag 0x7 len 32
mtu 1500 state EXSTART
3: First DBD and we are not SLAVE
4: Rcv DBD from 3.3.3.2 on BRI0 seq 0xB41 opt 0x42 flag 0x2 len 92 mtu
1500 state EXSTART
5: NBR Negotiation Done. We are the MASTER
6: Send DBD to 3.3.3.2 on BRI0 seq 0xB42 opt 0x42 flag 0x3 len 92
7: Database request to 3.3.3.2
8: sent LS REQ packet to 3.3.3.2, length 12
9: Rcv DBD from 3.3.3.2 on BRI0 seq 0x250 opt 0x42 flag 0x7 len 32
mtu 1500 state EXCHANGE
10: EXCHANGE - inconsistent in MASTER/SLAVE
11: Bad seq received from 3.3.3.2 on BRI0
12: Send DBD to 3.3.3.2 on BRI0 seq 0x2441 opt 0x42 flag 0x7 len 32
13: Rcv DBD from 3.3.3.2 on BRI0 seq 0x152C opt 0x42 flag 0x2 len 92
mtu 1500 state EXSTART
14: Unrecognized dbd for EXSTART
15: Rcv DBD from 3.3.3.2 on BRI0 seq 0xB42 opt 0x42 flag 0x0 len 32
mtu 1500 state EXSTART
16: Unrecognized dbd for EXSTART
Righe 1 - 3: RTR-B invia il primo DBD alla versione 3.3.3.2 (RTR-A) con seq 0xB41 e riceve il primo DBD dalla versione 3.3.3.2 (RTR-A) con seq# 0x1D06. La negoziazione con i router adiacenti non è ancora stata completata.
Righe 4 - 6: RTR-B riceve una risposta dalla 3.3.3.2 (RTR-A) indicante che RTR-A ha ricevuto il primo DBD di RTR-B. Poiché RTR-B ha l'ID del router più alto, RTR-A sceglie se stesso come slave. Dopo aver ricevuto la conferma da RTR-A, RTR-B si dichiara master e invia il primo DBD contenente i dati. Notare il numero di sequenza, che è 0xB42. Poiché RTR-B è il master, solo questo può incrementare il numero di sequenza.
Riga 7: RTR-B richiede dati da RTR-A poiché RTR-A ha indicato che ha più dati da inviare (flag impostato su 0x2 nell'ultimo DBD ricevuto da RTR-A).
Riga 8: RTR-B invia un pacchetto di richiesta dello stato del collegamento alla versione 3.3.3.2 (RTR-A). Si tratta di un pacchetto OSPF di tipo 3. Questo pacchetto viene in genere inviato all'indirizzo IP del router adiacente. In questo caso, l'indirizzo IP del router adiacente è l'ID del router.
Righe 9 - 11: RTR-B riceve una risposta dallo slave (RTR-A) con un numero di sequenza completamente diverso e un flag di 0x7, che è il flag di inizializzazione. Questo DBD era destinato a un altro router (molto probabilmente RTR-C), ma RTR-B non lo ha ricevuto correttamente. RTR-B dichiara che esiste una discrepanza perché un flag 0x7 indica che lo slave ha cambiato il proprio stato in master impostando il bit MS (Master/Slave) durante lo scambio di adiacenze. Anche RTR-B si lamenta del numero di sequenza perché non è funzionante. Lo slave deve sempre seguire il numero di sequenza del master.
Riga 12: RTR-B reinizializza l'adiacenza inviando il primo DBD alla versione 3.3.3.2 per selezionare nuovamente master e slave.
Righe 13 - 14: RTR-B riceve un DBD dalla versione 3.3.3.2 (RTR-A), indicando che si tratta di uno slave, senza riconoscere il numero di sequenza di RTR-B. RTR-B dichiara di non riconoscere questo DBD poiché la negoziazione master e slave non è ancora completa. Questo pacchetto DBD era destinato a un altro router.
Riga 15: RTR-B riceve una risposta dalla versione 3.3.3.2 (RTR-A) per il vecchio DBD, ma è troppo tardi perché RTR-B ha già reinizializzato il processo adiacente.
Riga 16: RTR-B non riconosce questo DBD perché è per una "vecchia" adiacenza, che RTR-B ha già demolito.
Questo processo si ripeterà all'infinito.
La soluzione
In base alla sezione 8.1 della RFC 2328 
, l'interfaccia OSPF invia un pacchetto multicast per un tipo di rete point-to-point anche dopo che è stato raggiunto lo stato bidirezionale. Poiché RTR-A sta tentando di creare adiacenze sia con RTR-B che con RTR-C, RTR-B riceve pacchetti DBD destinati a RTR-C e RTR-C riceve pacchetti DBD destinati a RTR-B.
Per risolvere questo problema, modificare il tipo di rete su tutti i router in point-to-multipoint. Ciò modifica il comportamento di OSPF per l'invio di pacchetti unicast dopo lo stato a due vie. Ora RTR-B riceve solo i pacchetti destinati a se stesso e RTR-C riceve i pacchetti destinati a se stesso. Se si modifica il tipo di rete in questo modo, il router OSPF formerà un'adiacenza su un'interfaccia PRI, BRI o dialer.
Per modificare il tipo di rete, immettere i seguenti comandi di configurazione, terminando ogni riga premendo INVIO. Come esempio, cambieremo RTR-B.
RTR-B# configure terminal RTR-B(config)# int bri 0 RTR-B(config-if)# ip ospf network point-to-multipoint RTR-B(config-if)# end
Ora, se guardiamo i comandi show per RTR-B, possiamo verificare che il tipo di rete sia point-to-multipoint e che lo stato sia pieno.
RTR-B# show ip ospf interface bri0
BRI0 is up, line protocol is up (spoofing)
Internet Address 3.3.3.3/24, Area 2
Process ID 1, Router ID 3.3.3.3, Network Type POINT_TO_MULTIPOINT, Cost: 1562
Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT,
Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
Hello due in 00:00:16
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 172.16.141.10
Suppress hello for 0 neighbor(s)
RTR-B# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
172.16.141.10 1 FULL/ - 00:01:36 3.3.3.2 BRI0
Informazioni correlate
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
1.0 |
10-Aug-2005 |
Versione iniziale |
Feedback