Por que o circuito de demanda OSPF continua a ativar o enlace
Contents
Introdução
Quando um link Open Shortest Path First (OSPF) é configurado como circuito de demanda, os pacotes Hello do OSPF são suprimidos e as atualizações LSA periódicas não são inundadas pelo link. Esses pacotes ativam o link somente quando são trocados pela primeira vez ou quando ocorre uma alteração nas informações que eles contêm. Isso permite que a camada de enlace de dados subjacente seja fechada quando a topologia de rede estiver estável. Um circuito de demanda que aumenta ou diminui indica um problema que precisa ser investigado. Este documento demonstra algumas causas possíveis e oferece soluções.
Para obter mais informações sobre circuito de demanda, consulte Recurso Circuito de Demanda OSPF.
Pré-requisitos
Requisitos
Não existem requisitos específicos para este documento.
Componentes Utilizados
Este documento não se restringe a versões de software e hardware específicas.
Conventions
Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.
Exemplo de rede
O problema mencionado acima é descrito com o diagrama e a configuração de rede a seguir.
| Roteador 1 | Roteador 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: Você precisa configurar o circuito de demanda apenas em uma extremidade do link. No entanto, se você configurar esse comando em ambas as extremidades, ele não causará nenhum dano.
No diagrama acima, os Roteadores 1 e 2 estão executando o circuito de demanda OSPF através do link ISDN. O link entre os Roteadores 1 e 2 continua surgindo, o que anula a finalidade do circuito de demanda OSPF. A saída do comando show dialer mostra que o link surgiu devido ao pacote Hello de multicast do 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)
O link pode ser ativado por vários motivos. Abaixo, exploramos vários casos comuns e oferecemos soluções.
Motivo 1: alteração na topologia de rede
Sempre que houver uma alteração em uma topologia de rede OSPF, os roteadores OSPF devem ser notificados. Nessa situação, o circuito de demanda OSPF deve ser ativado para que os vizinhos possam trocar as novas informações. Quando o novo banco de dados for trocado, o link poderá ser desativado novamente e a adjacência permanecerá no estado FULL.
Solução
Para determinar se o link é ativado devido a uma alteração na topologia da rede, use o comando debug ip ospf monitor. Ele mostra qual LSA está mudando, como visto abaixo:
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
A saída acima mostra que houve uma alteração no LSA do roteador com o ID do roteador 192.168.246.41, que faz com que o banco de dados seja ressincronizado. Se a rede estiver estável, a saída de depuração não mostrará nada.
Para reduzir o efeito de oscilações de link no circuito de demanda, configure a área que contém o circuito de demanda como totalmente stub. Se isso não for possível e houver um flap de link constante dentro da rede, o circuito de demanda pode não ser uma boa escolha para você.
Motivo 2: tipo de rede definido como broadcast
Quando você configura um circuito sob demanda em um link, o tipo de link deve ser definido como ponto a ponto ou ponto a multiponto. Qualquer outro tipo de link pode fazer com que o link seja ativado desnecessariamente porque os pacotes Hello do OSPF não são suprimidos se o tipo de rede for qualquer coisa diferente de ponto-a-ponto ou ponto-a-multiponto. Veja a seguir um exemplo de configuração para ilustrar esse problema nos Roteadores 1 e 2.
| Roteador 1 | Roteador 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 |
Com o tipo de rede definido como broadcast, o Hello do OSPF ativa o link a cada intervalo de Hello. A saída do comando show dialer mostra que a última vez que o link foi ativado foi devido a um Hello do 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) Interface bound to profile Di1 Current call connected 00:00:08 Connected to 57654 (R2)
Solução
Para resolver esse problema, altere o tipo de rede para ponto a ponto ou ponto a multiponto. Aqui removemos o tipo de rede broadcast para que, por padrão, ele seja configurado como ponto a ponto.
| Roteador 1 | Roteador 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 |
Ao alterar o tipo de rede para ponto-a-ponto ou ponto-a-multiponto, os pacotes de hello do OSPF são suprimidos no link e o link de circuito de demanda pára de oscilar.
Motivo 3: Um ou mais roteadores não entendem o circuito de demanda
Quando um ou mais roteadores no domínio OSPF não entendem o circuito de demanda, ocorre uma atualização LSA periódica. Consulte a seção Quando uma atualização de LSA periódica é enviada em um circuito de demanda OSPF? deste documento para saber como resolver esse problema.
Motivo 4: a rota do host é redistribuída no banco de dados do OSPF
Vamos considerar o diagrama de rede a seguir como um exemplo:
O link entre os Roteadores 1 e 2 é 131.108.1.0/24 e o circuito de demanda é configurado entre os Roteadores 1 e 2. O roteador 1 está redistribuindo rotas do Routing Information Protocol (RIP) no OSPF.
| Roteador 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 |
Como o tipo de encapsulamento do link é PPP, ambos os roteadores instalam uma rota de host para o outro lado do link, como mostrado abaixo.
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
O IGRP (Interior Gateway Routing Protocol) e o RIP são protocolos de roteamento de classe completa e, portanto, a instrução de rede na configuração é para uma rede de classe completa de 131.108.0.0. Por causa disso, a rota de host 131.108.1.2/32 é considerada originada pelo RIP e é redistribuída no OSPF como uma rota externa, como mostrado abaixo.
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 o link fica inativo, o /32 desaparece e o OSPF entende isso como uma alteração na topologia. O circuito de demanda ativa novamente o link para propagar a versão MAXAGE da máscara /32 para seu vizinho. Quando o link é ativado, a máscara /32 torna-se válida novamente para que a idade do LSA seja redefinida. Depois que o temporizador de Dead do enlace é acionado, o enlace é desativado novamente. Esse processo se repete e o link de circuito de demanda continua oscilando. Há três maneiras de resolver esse problema mostradas abaixo.
Solução 1: Use o comando no peer neighbor-route
Na interface BRI que está executando o circuito de demanda, configure no peer neighbor-route. Isso impede que a máscara /32 seja instalada. Você pode usar a configuração mostrada abaixo apenas no Roteador 1, mas recomendamos a configuração desse comando em ambos os lados para fins de consistência.
R1# configure terminal R1(config)# interface BRI1/1 R1(config-if)# no peer neighbor-route
Solução 2: use o comando route-map
Ao redistribuir do RIP para o OSPF, use o comando route-map e negue /32 para que ele não seja injetado no banco de dados do OSPF. Esse comando de configuração é necessário apenas no roteador que está fazendo a redistribuição, que em nosso exemplo é o Roteador 1.
Primeiro, precisamos criar uma lista de acesso para corresponder à máscara /32. Em seguida, aplicamos essa lista de acesso ao mapa de rotas e usamos o mapa de rotas ao aplicar o comando redistribution, como mostrado abaixo.
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
Solução 3: use uma rede principal diferente
Use uma rede principal diferente para o domínio RIP ou OSPF. A ideia é ter uma rede principal diferente no link de circuito sob demanda para que, quando o link for ativado no encapsulamento PPP, ele instale a rota de host para o outro lado do link. Se a rota de host estiver em uma rede principal diferente daquela que está sendo usada no RIP, o RIP não possui essa rota de host instalada pelo PPP porque não tem uma instrução de rede para a rede principal. O diagrama de rede abaixo mostra um exemplo.
O domínio RIP agora está na rede 141.108.0.0, enquanto o domínio OSPF (e o link de circuito de demanda) está na rede 131.108.0.0.
Motivo 5: o circuito de demanda do OSPF está configurado em uma interface assíncrona
Quando você configura um circuito de demanda em uma interface assíncrona (assíncrona), quando a Camada 2 fica inativa, a interface física real fica inativa. Isso dispara uma alteração no banco de dados OSPF e a interface assíncrona volta a funcionar para trocar o banco de dados. A camada 2 fica inativa novamente e isso acionará a alteração no banco de dados novamente, de modo que esse processo continua se repetindo.
O cenário a seguir é usado para reproduzir o problema acima.
A configuração a seguir é usada para o cenário acima.
| Roteador 1 | Roteador 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 |
O tipo de rede padrão do OSPF é ponto-a-ponto em uma interface assíncrona, mas o circuito sob demanda continua ativando o link.
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)
Solução
A razão pela qual o circuito de demanda continua ativando o link é porque quando a Camada 2 fica inativa após o timeout de ociosidade expirar, toda a interface fica inativa. Mas, no caso de BRI ou PRI, quando um dos canais fica inativo, a interface ainda permanece ativa (no modo de spoofing). Para resolver o problema, você deve configurar uma interface de discador porque ela nunca fica inativa. Uma interface de discador permanece ativa (no modo de spoofing).
| Roteador 1 | Roteador 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 |
Como a interface do discador nunca fica inativa, ela não criará o problema que é criado quando uma interface assíncrona fica inativa.
Motivo 6: O circuito de demanda do OSPF está configurado em um PPP Multilink
O recurso PPP multilink pode ser usado para fins de balanceamento de carga nos casos em que houver vários links de WAN. Uma coisa importante a ser lembrada em termos de OSPF é a largura de banda do PPP multilink. Quando vários links são combinados, a largura de banda da interface multilink será alterada.
O cenário a seguir é usado para reproduzir o problema acima.
A configuração a seguir é usada para o cenário acima.
| Roteador 1 | Roteador 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 |
A saída a seguir mostra que há três interfaces seriais agrupadas no PPP multilink.
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
A largura de banda da interface representará a largura de banda agregada do link e essa largura de banda será usada no cálculo de custo do 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
A saída de show ip ospf interface mostra o custo atual do OSPF, que é 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)
Agora um link fica inativo e podemos ver isso no registro:
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
Se verificarmos a largura de banda novamente, ela será diferente do que vimos anteriormente. Agora está mostrando 3968 e o pacote tem apenas duas interfaces em vez de três porque uma interface foi desativada. Observe abaixo que a interface ainda está ativa:
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)
Além disso, o multilink PPP ainda está sendo exibido, mas o custo OSPF agora é alterado para 25, já que um link está inoperante
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)
Isso acionará o cálculo de SPF e o OSPF ativará o circuito de demanda. Se o link continuar oscilando, podemos ver o circuito de demanda continuar oscilando porque o custo será alterado toda vez que um link for adicionado ou excluído do pacote PPP multilink.
Solução
O multilink PPP é suportado no OSPF, mas enquanto todo o link dentro do pacote permanecer ativo, o circuito de demanda ficará estável. Assim que um link se torna inativo, mesmo que não haja nenhum endereço IP associado a ele, ele afetará o cálculo de custo do OSPF e, por causa disso, o OSPF executará o SPF para recalcular os melhores caminhos. Para resolver esse problema, a única solução é configurar o custo do OSPF manualmente com o seguinte comando.
| Roteador 1 | Roteador 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 |
Esse comando garantirá que sempre que houver um link adicionado ou excluído no pacote PPP multilink, o custo do OSPF não será afetado. Isso estabilizará o circuito de demanda OSPF sobre o multilink PPP.
Informações Relacionadas
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
1.0 |
03-Oct-2001 |
Versão inicial |
Feedback