Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

Conventions

Exemplo de rede

Motivo 1: Alteração da topologia de rede

Solução

Motivo 2: Tipo de rede definido como broadcast

Solução

Motivo 3: Um ou mais roteadores não entendem o circuito de demanda

Motivo 4: A rota host é redistribuída no banco de dados OSPF

Solução 1: Utilizar o comando no peer neighbor-route

Solução 2: Uso do comando route-map

Solução 3: Use uma rede principal diferente

Motivo 5: O circuito de demanda OSPF está configurado em uma interface assíncrona

Solução

Motivo 6: O circuito de demanda OSPF está configurado sobre um multilink PPP

Solução

Informações Relacionadas

Introduction

Quando um link OSPF (Open Shortest Path First) é configurado como circuito de demanda, os Hellos OSPF são suprimidos e as atualizações periódicas de LSA 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 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 sobe e desce 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 sob demanda, consulte Recurso de Circuito de Demanda OSPF.

Prerequisites

Requirements

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

Observação: você precisa configurar o circuito de demanda somente 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 em operação, o que anula a finalidade do circuito de demanda OSPF. A saída do comando show dialer mostra que o link foi ativado por causa do pacote de saudação 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. A seguir, exploramos vários casos comuns e oferecemos soluções.

Motivo 1: Alteração da 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. Depois que o novo banco de dados é trocado, o link pode ficar inativo novamente e a adjacência permanece 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. 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, o que faz com que o banco de dados seja ressincronizado. Se a rede estiver estável, essa saída de depuração não mostrará nada.

Para reduzir o efeito dos flaps de link no circuito de demanda, configure a área que contém o circuito de demanda como totalmente stub. Se isso não for realizável e houver uma oscilação de link constante na 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 de 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 apareça desnecessariamente porque os Hellos OSPF não são suprimidos se o tipo de rede for 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, as saudações do OSPF ativam o link a cada intervalo de Hello. A saída 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 de modo que por padrão ele é 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 Hellos do OSPF são suprimidos no link e o link do circuito de demanda para 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 periódica do LSA. Consulte Quando uma atualização de LSA periódica é enviada por um circuito de demanda OSPF? deste documento para saber como resolver esse problema.

Motivo 4: A rota host é redistribuída no banco de dados 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 Interior Gateway Routing Protocol (IGRP) 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 desce, o /32 desaparece e o OSPF entende isso como uma alteração na topologia. O circuito de demanda ativa o link novamente para propagar a versão MAXAGE da máscara /32 para seu vizinho. Quando o link é ativado, a máscara /32 se torna válida novamente para que a idade LSA seja redefinida. Depois que o temporizador inoperante do link entrar, o link desliga novamente. Esse processo se repete e o link do circuito de demanda continua oscilando. Há três maneiras de resolver esse problema mostradas abaixo.

Solução 1: Utilizar o comando no peer neighbor-route

Na interface BRI que está executando 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 somente no Roteador 1, mas recomendamos a configuração desse comando em ambos os lados para garantir a consistência.

R1# configure terminal

R1(config)# interface BRI1/1

R1(config-if)# no peer neighbor-route

Solução 2: Uso do 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 no nosso exemplo é o Roteador 1.

Primeiro, temos que 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 redistribuição conforme 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 do circuito de demanda para que, quando o link for ativado sob o encapsulamento PPP, ele instale a rota do host para o outro lado do link. Se a rota de host estiver em uma rede principal diferente da 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 está agora 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 OSPF está configurado em uma interface assíncrona

Quando você configura um circuito de demanda sobre uma interface assíncrona (assíncrona), quando a Camada 2 fica inativa, a interface física real fica inativa. Isso aciona 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 cai novamente, e isso acionará a alteração no banco de dados novamente, portanto 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 ainda assim o circuito de 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 é que quando a Camada 2 fica inativa após o tempo limite de ociosidade expirar, toda a interface fica inativa. Mas no caso da BRI ou PRI, quando um dos canais fica inativo, a interface ainda permanece ativa (no modo de falsificação). 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 falsificação).

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 criado quando uma interface assíncrona fica inativa.

Motivo 6: O circuito de demanda OSPF está configurado sobre um multilink PPP

O recurso PPP multilink pode ser usado para fins de balanceamento de carga nos casos em que há vários links de WAN. Uma coisa importante a lembrar 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 muda.

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 do 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 cai 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 ele está mostrando 3968 e o pacote tem apenas duas interfaces em vez de três porque uma interface ficou inativa. Observação abaixo, 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 do OSPF agora é alterado para 25, já que um link está inativo

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 que acionará o cálculo de SPF, e o OSPF ativará o circuito de demanda. Se o link continuar oscilando, então podemos ver que o circuito de demanda continua 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 será estável. Assim que um link fica 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 que seja 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

- Página de suporte de OSPF

- Suporte Técnico - Cisco Systems