Perché il circuito di richiesta OSPF continua a richiamare il collegamento
Sommario
Introduzione
Quando un collegamento OSPF (Open Shortest Path First) viene configurato come circuito a richiesta, gli hellol OSPF vengono eliminati e gli aggiornamenti LSA periodici non vengono trasmessi attraverso il collegamento. Questi pacchetti fanno apparire il link solo quando vengono scambiati per la prima volta o quando si verifica un cambiamento nelle informazioni che contengono. In questo modo, il livello di collegamento dati sottostante viene chiuso quando la topologia di rete è stabile. Un circuito di domanda che va su e giù indica un problema che deve essere esaminato. In questo documento vengono indicate alcune possibili cause e vengono fornite soluzioni.
Per ulteriori informazioni sul circuito a richiesta, vedere Funzione del circuito a richiesta OSPF.
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.
Esempio di rete
Il problema sopra descritto è descritto con il diagramma di rete e la configurazione seguenti.
| Router 1 | Router 2 |
|---|---|
interface BRI1/1 ip address 192.158.254.13 255.255.255.252 ip ospf demand-circuit router ospf 20 network 192.158.254.0 0.0.0.255 area 0 |
interface BRI1/0 ip address 192.158.254.14 255.255.255.252 router ospf 20 network 192.158.254.0 0.0.0.255 area 0 |
Nota: è necessario configurare il circuito della domanda solo a un'estremità del collegamento. Tuttavia, se si configura questo comando su entrambe le estremità, non vi sono danni.
Nel diagramma riportato sopra, i router 1 e 2 eseguono un circuito di richiesta OSPF sul collegamento ISDN. Il collegamento tra i router 1 e 2 continua a salire, vanificando lo scopo del circuito di richiesta OSPF. L'output del comando show dialer visualizza il collegamento come attivato a causa del pacchetto Hello multicast OSPF.
Router1# show dialer BRI1/1:1 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (2 secs) Dialer state is data link layer up Dial reason: ip (s=192.168.254.13, d=224.0.0.5)
Il link può essere richiamato per diversi motivi. Di seguito vengono esaminati diversi casi comuni e vengono fornite soluzioni.
1. Modifica della topologia di rete
Ogni volta che si verifica una modifica nella topologia di una rete OSPF, è necessario informare i router OSPF. In questa situazione il circuito di domanda OSPF dovrebbe essere sollevato in modo che i vicini possano scambiarsi le nuove informazioni. Una volta scambiato il nuovo database, il collegamento può tornare inattivo e l'adiacenza rimane nello stato FULL.
Soluzione
Per determinare se il collegamento viene attivato a causa di una modifica nella topologia di rete, utilizzare il comando debug ip ospf monitor. Viene mostrato quale LSA sta cambiando, come mostrato di seguito:
Router1# debug ip ospf monitor
OSPF: Schedule SPF in area 0.0.0.0
Change in LS ID 192.168.246.41, LSA type R,
OSPF: schedule SPF: spf_time 1620348064ms wait_interval 10s
L'output sopra riportato mostra una modifica nell'LSA del router con ID 192.168.246.41, che determina la risincronizzazione del database. Se la rete è stabile, l'output del comando debug non visualizza nulla.
Per ridurre l'effetto dei link flap sul circuito di richiesta, configurare l'area che contiene il circuito di richiesta come completamente stub. Se questo non è fattibile, e c'è un link flap costante all'interno della rete, il circuito della domanda potrebbe non essere una buona scelta per voi.
Motivo 2: tipo di rete definito come broadcast
Quando si configura un circuito a richiesta su un collegamento, il tipo di collegamento deve essere definito come point-to-point o point-to-multipoint. Qualsiasi altro tipo di collegamento può causare l'attivazione non necessaria del collegamento, in quanto gli hop OSPF non vengono soppressi se il tipo di rete è diverso da point-to-point o point-to-multipoint. Di seguito è riportata una configurazione di esempio per illustrare il problema sui router 1 e 2.
| Router 1 | Router 2 |
|---|---|
interface BRI1/1 ip address 192.158.254.13 255.255.255.252 ip ospf network broadcast router ospf 20 network 192.158.254.0 0.0.0.255 area 0 |
interface BRI1/0 ip address 192.158.254.14 255.255.255.252 ip ospf network broadcast router ospf 20 network 192.158.254.0 0.0.0.255 area 0 |
Con il tipo di rete definito come broadcast, gli hellol OSPF attivano il collegamento a ogni intervallo Hello. L'output del comando show dialer mostra che l'ultima volta in cui il collegamento è stato attivato è stato generato da un oggetto OSPF Hello.
Router1# show dialer BRI1/1:1 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (2 secs) Dialer state is data link layer up Dial reason: ip (s=192.168.254.13, d=224.0.0.5) Interface bound to profile Di1 Current call connected 00:00:08 Connected to 57654 (R2)
Soluzione
Per risolvere questo problema, modificare il tipo di rete in point-to-point o point-to-multipoint. In questa procedura viene rimosso il tipo di rete broadcast in modo che per impostazione predefinita sia configurato come point-to-point.
| Router 1 | Router 2 |
|---|---|
interface BRI1/1 ip address 192.158.254.13 255.255.255.252 router ospf 20 network 192.158.254.0 0.0.0.255 area 0 |
interface BRI1/0 ip address 192.158.254.14 255.255.255.252 router ospf 20 network 192.158.254.0 0.0.0.255 area 0 |
Modificando il tipo di rete in point-to-point o point-to-multipoint, gli hop OSPF vengono eliminati sul collegamento e il collegamento del circuito di richiesta smette di lampeggiare.
Motivo 3: uno o più router non capiscono il circuito della domanda
Quando uno o più router nel dominio OSPF non comprendono il circuito di richiesta, viene eseguito un aggiornamento LSA periodico. Per informazioni su come risolvere il problema, vedere la sezione Quando viene inviato un aggiornamento LSA periodico su un circuito di richiesta OSPF? di questo documento.
Motivo 4: route host ridistribuita nel database OSPF
Prendiamo ad esempio il diagramma di rete seguente:
Il collegamento tra i router 1 e 2 è 131.108.1.0/24, quindi il circuito della domanda è configurato tra i router 1 e 2. Il router 1 sta ridistribuendo le route RIP (Routing Information Protocol) in OSPF.
| Router 1 |
|---|
router ospf 1 redistribute rip subnets network 131.108.1.0 0.0.0.255 area 1 ! router rip network 131.108.0.0 |
Poiché il tipo di incapsulamento del collegamento è PPP, entrambi i router installano un percorso host per l'altro lato del collegamento, come mostrato di seguito.
Router1# show ip route 131.108.1.2
Routing entry for 131.108.1.2/32
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via BRI1/1
Route metric is 0, traffic share count is 1
IGRP (Interior Gateway Routing Protocol) e RIP sono protocolli di routing classful, quindi l'istruzione di rete nella configurazione è per una rete classful di 131.108.0.0. Per questo motivo, la route host 131.108.1.2/32 viene considerata originata da RIP e viene ridistribuita in OSPF come route esterna, come mostrato di seguito.
Router1# show ip ospf database external 131.108.1.2
OSPF Router with ID (131.108.3.1) (Process ID 1)
Type-5 AS External Link States
LS age: 298
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 131.108.1.2 (External Network Number )
Advertising Router: 131.108.3.1
LS Seq Number: 80000001
Checksum: 0xDC2B
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
Quando il collegamento si interrompe, /32 scompare e OSPF riconosce che si tratta di una modifica della topologia. Il circuito di richiesta riporta il collegamento al livello superiore per propagare la versione MAXAGE della maschera /32 al router adiacente. Quando il collegamento viene visualizzato, la maschera /32 diventa nuovamente valida in modo che la pagina LSA venga reimpostata. Dopo che il timer inattivo del link è entrato, il link si interrompe di nuovo. Questo processo si ripete e il collegamento del circuito della domanda continua a lampeggiare. Di seguito sono illustrati tre metodi per risolvere il problema.
Soluzione 1: utilizzare il comando no peer neighbors-route
Nell'interfaccia BRI che esegue il circuito a richiesta, configurare no peer neighbors-route. In questo modo la maschera /32 non verrà installata. È possibile usare la configurazione mostrata di seguito solo sul router 1, ma si consiglia di configurare il comando su entrambi i lati per una maggiore coerenza.
R1# configure terminal R1(config)# interface BRI1/1 R1(config-if)# no peer neighbor-route
Soluzione 2: utilizzare il comando route-map
Durante la ridistribuzione da RIP a OSPF, utilizzare il comando route-map e negare /32 in modo che non venga inserito nel database OSPF. Questo comando di configurazione è richiesto solo sul router che sta eseguendo la ridistribuzione, nell'esempio riportato da Router 1.
Innanzitutto è necessario creare un elenco degli accessi che corrisponda alla maschera /32. Quindi, applichiamo questo elenco degli accessi alla mappa dei percorsi e utilizziamo la mappa dei percorsi quando si applica il comando redistribution, come mostrato di seguito.
R1# configure terminal R1(config)# access-list 1 deny host 131.108.1.2 R1(config)# access-list 1 permit any R1# configure terminal R1(config)# route-map rip-ospf R1(config-route-map)# match ip address 1 R1(config)# router ospf 1 R1(config-router)# redistribute rip subnets route-map rip-ospf
Soluzione 3: utilizzare una rete principale diversa
Utilizzare una rete principale diversa per il dominio RIP o OSPF. L'idea è di avere una rete principale diversa sul collegamento del circuito della domanda in modo che quando il collegamento viene attivato con l'incapsulamento PPP, installa il percorso host per l'altro lato del collegamento. Se la route host si trova in una rete principale diversa da quella utilizzata in RIP, RIP non è proprietario della route host installata tramite PPP in quanto non dispone di un'istruzione di rete per la rete principale. Il diagramma di rete seguente mostra un esempio.
Il dominio RIP è ora sotto la rete 141.108.0.0, mentre il dominio OSPF (e il collegamento del circuito di domanda) è sotto la rete 131.108.0.0.
Motivo 5: circuito di richiesta OSPF configurato su un'interfaccia asincrona
Quando si configura un circuito a richiesta su un'interfaccia asincrona (asincrona), quando il layer 2 diventa inattivo, l'interfaccia fisica effettiva diventa inattiva. In questo modo viene attivata una modifica nel database OSPF e l'interfaccia asincrona viene ripristinata per lo scambio del database. Il layer 2 diventa nuovamente inattivo e ciò attiverà di nuovo la modifica nel database, in modo che questo processo continui a ripetersi.
Lo scenario seguente viene utilizzato per riprodurre il problema sopra indicato.
Per lo scenario sopra descritto viene utilizzata la configurazione seguente.
| Router 1 | Router 2 |
|---|---|
interface Async 1 ip address 192.158.254.13 255.255.255.252 encapsulation ppp ip ospf demand-circuit dialer in-band async default routing async mode dedicated ppp authentication chap ppp chap hostname Router1 ppp chap password 7 13061E010803 ! router ospf 20 network 192.158.254.0 0.0.0.255 area 1 |
interface Async 1 ip address 192.158.254.14 255.255.255.252 encapsulation ppp ip ospf demand-circuit dialer in-band dialer map ip 192.158.254.13 broadcast 12345 dialer-group 2 async default routing async mode dedicated ppp authentication chap callin ! dialer-list 2 protocol ip permit ! router ospf 20 network 192.158.254.0 0.0.0.255 area 1 |
Il tipo di rete predefinito OSPF è point-to-point su un'interfaccia asincrona, ma il circuito a richiesta continua a richiamare il collegamento.
Rouer1# show ip ospf interface Async1
Async1 is up, line protocol is up (spoofing)
Internet Address 192.158.254.13/32, Area 1
Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost:869
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:02
Index 1/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
Soluzione
Il motivo per cui il circuito della domanda continua a richiamare il collegamento è che quando il layer 2 si blocca dopo la scadenza del timeout di inattività, l'intera interfaccia si blocca. Ma nel caso di BRI o PRI, quando uno dei canali si interrompe, l'interfaccia rimane attiva (in modalità spoofing). Per risolvere il problema, è necessario configurare un'interfaccia di connessione telefonica in quanto non si interrompe mai. L'interfaccia di connessione remota rimane attiva (in modalità spoofing).
| Router 1 | Router 2 |
|---|---|
interface Async 1 no ip address encapsulation ppp async default routing async mode dedicated dialer in-band dialer rotary-group 0 ! interface Dialer0 ip address 192.158.254.13 255.255.255.252 encapsulation ppp ip ospf demand-circuit ppp authentication chap ppp chap hostname Router1 ppp chap password 7 13061E010803 ! router ospf 20 network 192.158.254.0 0.0.0.255 area 0 |
interface Async 1 no ip address encapsulation ppp async default routing async mode dedicated dialer in-band dialer rotary-group 0 ! interface Dialer0 ip address 192.158.254.14 255.255.255.252 encapsulation ppp ip ospf demand-circuit dialer map ip 192.158.254.13 broadcast 12345 dialer-group 2 ppp authentication callin ! dialer-list 2 protocol ip permit ! router ospf 20 network 192.158.254.0 0.0.0.255 area 0 |
Poiché l'interfaccia dialer non si interrompe mai, non crea il problema che si verifica quando un'interfaccia asincrona si interrompe.
Motivo 6: il circuito di richiesta OSPF è configurato su un PPP Multilink
La funzione Multilink PPP può essere utilizzata per il bilanciamento del carico in caso di più collegamenti WAN. Un elemento importante da ricordare in termini di OSPF è la larghezza di banda del Multilink PPP. Quando si combinano più collegamenti, la larghezza di banda dell'interfaccia a connessione multipla cambia.
Lo scenario seguente viene utilizzato per riprodurre il problema sopra indicato.
Per lo scenario sopra descritto viene utilizzata la configurazione seguente.
| Router 1 | Router 2 |
|---|---|
interface Multilink1 ip address 192.158.254.1 255.255.255.0 no cdp enable ppp multilink no ppp multilink fragmentation multilink-group 1 ! interface Serial0/1/0:0 no ip address ip route-cache distributed encapsulation ppp tx-queue-limit 26 no fair-queue ppp multilink multilink-group 1 ! interface Serial0/1/1:0 no ip address ip route-cache distributed encapsulation ppp tx-queue-limit 26 no fair-queue ppp multilink multilink-group 1 ! interface Serial0/1/2:0 no ip address ip route-cache distributed encapsulation ppp tx-queue-limit 26 no fair-queue ppp multilink multilink-group 1 ! router ospf 20 network 192.158.254.0 0.0.0.255 area 1 |
interface Multilink1 ip address 192.158.254.2 255.255.255.0 no cdp enable ppp multilink no ppp multilink fragmentation multilink-group 1 ! interface Serial0/1/0:0 no ip address ip route-cache distributed encapsulation ppp tx-queue-limit 26 no fair-queue ppp multilink multilink-group 1 ! interface Serial0/1/1:0 no ip address ip route-cache distributed encapsulation ppp tx-queue-limit 26 no fair-queue ppp multilink multilink-group 1 ! interface Serial0/1/2:0 no ip address ip route-cache distributed encapsulation ppp tx-queue-limit 26 no fair-queue ppp multilink multilink-group 1 ! router ospf 20 network 192.158.254.0 0.0.0.255 area 1 |
L'output seguente mostra che il protocollo Multilink PPP include tre interfacce seriali.
Router1# show ppp multilink
Multilink1, bundle name is Router2
Bundle up for 00:05:35
Bundle is Distributed
0 lost fragments, 0 reordered, 0 unassigned
0 discarded, 0 lost received, 3/255 load
0x1226 received sequence, 0x1226 sent sequence
Member links: 3 active, 0 inactive (max not set, min not set)
Serial1/0/0:0, since 00:05:35, no frags rcvd
Serial1/0/1:0, since 00:05:35, no frags rcvd
Serial1/0/2:0, since 00:05:35, no frags rcvd
La larghezza di banda dell'interfaccia rappresenterà la larghezza di banda aggregata del collegamento e verrà utilizzata nel calcolo del costo OSPF.
Router1# show interface multilink 1
Multilink1 is up, line protocol is up
Hardware is multilink group interface
Internet address is 192.168.254.1/24
MTU 1500 bytes, BW 5952 Kbit, DLY 100000 usec,
reliability 255/255, txload 3/255, rxload 3/255
Encapsulation PPP, loopback not set
Keepalive set (10 sec)
DTR is pulsed for 2 seconds on reset
LCP Open, multilink Open
Open: IPCP
Last input 00:00:00, output never, output hang never
Last clearing of "show interface" counters 00:06:39
Input queue: 1/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue :0/40 (size/max)
5 minute input rate 241000 bits/sec, 28 packets/sec
5 minute output rate 241000 bits/sec, 28 packets/sec
6525 packets input, 9810620 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
6526 packets output, 9796112 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
L'output del comando show ip ospf interface visualizza il costo OSPF corrente, pari a 16.
Router1# show ip ospf interface multilink 1
Multilink1 is up, line protocol is up
Internet Address 192.158.254.13/24, Area 1
Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost:16
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:02
Index 1/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
A questo punto il collegamento si interrompe e nel log viene visualizzato quanto segue:
Router1# show log | include down %LINK-3-UPDOWN: Interface Serial1/0/0:0, changed state to down %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0/0:0, changed state to down
Controllando di nuovo la larghezza di banda sarà diversa da quella che abbiamo visto in precedenza. Ora è visualizzato il numero 3968 e il bundle ha solo due interfacce invece di tre perché un'interfaccia si è interrotta. Nota: l'interfaccia è ancora attiva:
Router1# show ppp multilink
Multilink1, bundle name is Router2
Bundle up for 00:05:35
Bundle is Distributed
0 lost fragments, 0 reordered, 0 unassigned
0 discarded, 0 lost received, 3/255 load
0x1226 received sequence, 0x1226 sent sequence
Member links: 2 active, 1 inactive (max not set, min not set)
Serial1/0/1:0, since 00:05:35, no frags rcvd
Serial1/0/2:0, since 00:05:35, no frags rcvd
Serial1/0/0:0 (inactive)
Inoltre, il collegamento multiplo PPP è ancora visibile, ma il costo OSPF è ora passato a 25 poiché un collegamento è inattivo
Router1# show ip ospf interface multilink 1
Multilink1 is up, line protocol is up
Internet Address 192.158.254.13/24, Area 1
Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost:25
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:02
Index 1/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
In questo modo verrà attivato il calcolo dell'SPF e l'OSPF attiverà il circuito della domanda. Se il collegamento continua a lampeggiare, è possibile che il circuito della domanda continui a lampeggiare perché il costo verrà modificato ogni volta che un collegamento viene aggiunto o eliminato dal bundle PPP a connessione multipla.
Soluzione
Il collegamento multiplo PPP è supportato in OSPF, ma finché tutto il collegamento all'interno del bundle rimane attivo, il circuito della domanda sarà stabile. Non appena un collegamento si interrompe, anche se non è associato ad alcun indirizzo IP, influirà sul calcolo del costo OSPF. Per questo motivo, OSPF eseguirà l'SPF per ricalcolare i percorsi migliori. Per risolvere questo problema, l'unica soluzione è configurare manualmente il costo OSPF con il comando seguente.
| Router 1 | Router 2 |
|---|---|
interface Multilink1 ip address 192.158.254.1 255.255.255.0 no cdp enable ip ospf cost 10 ppp multilink no ppp multilink fragmentation multilink-group 1 ! router ospf 20 network 192.158.254.0 0.0.0.255 area 1 |
interface Multilink1 ip address 192.158.254.2 255.255.255.0 no cdp enable ip ospf cost 10 ppp multilink no ppp multilink fragmentation multilink-group 1 ! router ospf 20 network 192.158.254.0 0.0.0.255 area 1 |
Questo comando garantisce che ogni volta che viene aggiunto o eliminato un collegamento nel bundle PPP multilink, il costo OSPF non venga influenzato. Ciò stabilizzerà il circuito di domanda OSPF sul collegamento multiplo PPP.
Informazioni correlate
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
1.0 |
03-Oct-2001 |
Versione iniziale |
Feedback