Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Convenzioni

Esempio di rete

1. Modifica della topologia di rete

Soluzione

Motivo 2: tipo di rete definito come broadcast

Soluzione

Motivo 3: uno o più router non capiscono il circuito della domanda

Motivo 4: route host ridistribuita nel database OSPF

Soluzione 1: utilizzare il comando no peer neighbors-route

Soluzione 2: utilizzare il comando route-map

Soluzione 3: utilizzare una rete principale diversa

Motivo 5: circuito di richiesta OSPF configurato su un'interfaccia asincrona

Soluzione

Motivo 6: il circuito di richiesta OSPF è configurato su un PPP Multilink

Soluzione

Informazioni correlate

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

- Pagina di supporto del protocollo OSPF

- Supporto tecnico – Cisco Systems