IP : Open Shortest Path First (OSPF)

Por que o circuito de demanda OSPF continua a ativar o enlace

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Quando um link do Open Shortest Path First (OSPF) é configurado enquanto o circuito da procura, hellos OSPF está suprimido e as atualizações de lsa periódicas não estão inundadas sobre o link. Estes pacotes trazem acima o link somente quando estão trocados pela primeira vez, ou quando uma mudança ocorre na informação eles contém. Isto permite que a camada de link de dados subjacente seja fechada quando a topologia de rede é estável. Um circuito da procura que vá para cima e para baixo indica um problema que precise de ser investigado. Este documento demonstra algumas causas possíveis e oferece soluções.

Para mais circuito por encomenda da informação, refira recursos de demanda de circuito 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.

Convenções

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 de rede seguinte e a configuração.

/image/gif/paws/4808/dc1.gif

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 de configurar o circuito da procura em uma extremidade do link somente. Contudo, se você configura este comando no ambas as extremidades não causa nenhum dano.

No diagrama acima, o Roteadores 1 e 2 está executando o circuito da procura OSPF através do enlace de ISDN. O link entre o Roteadores 1 e 2 mantém-se vir acima, que derrota a finalidade do circuito da procura OSPF. A saída do comando show dialer mostra que o link veio acima devido ao pacote de hello de transmissão múltipla 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 trazido acima por vários motivos. Abaixo dos nós exploramos diversos casos comuns e oferecemos soluções.

Razão 1: Alteração da topologia de rede

Sempre que há uma mudança em uma topologia de rede de OSPF, os OSPF Router devem ser notificados. Nesta situação o circuito da procura OSPF deve ser trazido acima de modo que os vizinhos possam trocar a informação nova. Uma vez que o banco de dados novo é trocado o link pode ir para baixo outra vez e a adjacência permanece no estado FULL.

Solução

Para determinar se o link é trazido acima de devido a uma mudança na topologia de rede, use o comando debug ip ospf monitor. Mostra que 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 havia uma mudança no LSA de roteador com o Router ID de 192.168.246.41, que causa o banco de dados ser ressincronizado. Se a rede é estável, a seguir mostras deste resultado do debug nada.

Para reduzir a influência de aletas do link no circuito da procura, configurar a área que contém o circuito da procura como totalmente o stub. Se isto não é doable, e há um flap constante do link dentro da rede, o circuito da procura não pôde ser uma boa escolha para você.

Razão 2: Tipo de rede definido como broadcast

Quando você configura o circuito da procura em um link, o tipo de liink deve ser definido como ponto a ponto ou point-to-multipoint. Qualquer outro tipo de liink pode fazer com que o link venha acima desnecessariamente porque os hellos OSPF não são suprimidos se o tipo de rede é qualquer coisa a não ser ponto a ponto ou point-to-multipoint. Seguir é uma configuração de exemplo para ilustrar este problema no 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 a transmissão, os hellos OSPF trazem o link acima em cada intervalo de hello. A saída do discador da mostra mostra que a última vez onde o link foi trazido acima de era devido a um hello de 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 este problema, muda o tipo de rede a ponto a ponto ou a point-to-multipoint. Aqui nós removemos o tipo de rede broadcast é configurado tão à revelia que 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

Mudando o tipo de rede a ponto a ponto ou a point-to-multipoint, os hellos OSPF são suprimidos no link, e o link de demanda de circuito para de bater.

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

Quando os ou mais roteadores no domínio de OSPF não compreendem o circuito da procura, uma atualização de lsa periódica ocorre. Veja quando é uma atualização de lsa periódica enviada sobre um circuito da procura OSPF? seção deste documento para aprender como resolver esta edição.

Razão 4: A rota host é redistribuída no banco de dados OSPF

Deixe-nos considerar como um exemplo o diagrama de rede seguinte:

/image/gif/paws/4808/dc2.gif

O link entre o Roteadores 1 e 2 é 131.108.1.0/24, e o circuito da procura é configurado entre o roteador1 do Roteadores 1 e 2. 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

Desde que o tipo de encapsulamento do link é PPP, ambo o Roteadores instala uma rota do 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 RASGO são protocolos do roteamento classful, e consequentemente a instrução de rede na configuração é para uma rede de classe completa de 131.108.0.0. Devido a isto a rota do host de 131.108.1.2/32 é considerada ser originada pelo RASGO e obtém 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 vai abaixo de /32 desaparece e o OSPF compreende este como uma mudança na topologia. O circuito da procura traz o link acima outra vez propagar a versão MAXAGE da máscara de /32 a seu vizinho. Quando o link vem acima, a máscara de /32 torna-se válida outra vez assim que a idade LSA obtém a restauração. Então depois que o temporizador inoperante do link retrocede dentro, o link vai para baixo outra vez. Este processo repete-se e o link de demanda de circuito mantém-se bater. Há três maneiras de resolver este problema mostrado abaixo.

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

Sob a interface BRI que está executando o circuito da procura, não configurar nenhum peer neighbor-route. Isto impede que a máscara de /32 esteja instalada. Você pode usar a configuração mostrada abaixo no roteador1 somente, mas nós recomendamos configurar este comando em ambos os lados para 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 RASGO no OSPF, use o comando route-map e negue /32 assim que não obtém injetado na base de dados do OSPF. Este comando configuration é exigido somente no roteador que está fazendo a redistribução, que em nosso exemplo é roteador1.

Primeiramente nós temos que criar uma lista de acessos para combinar a máscara de /32. Então nós aplicamos esta lista de acessos ao mapa de rota e usamos o mapa de rota 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 RASGO ou o domínio de OSPF. A ideia é ter uma rede principal diferente no link de demanda de circuito assim quando o link vem acima sob o encapsulamento PPP que instala a rota do host para o outro lado do link. Se a rota do host está em uma rede principal diferente do que essa que está sendo usado no RASGO, o RASGO não possui esta rota PPP-instalada do host porque não tem uma instrução de rede para a rede principal. O diagrama da rede abaixo mostra um exemplo.

/image/gif/paws/4808/dc3.gif

O domínio do RASGO está agora sob a rede de 141.108.0.0 quando o domínio de OSPF (e o link de demanda de circuito) estiverem sob a rede de 131.108.0.0.

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

Quando você configura um circuito da procura sobre uma relação assíncrona (do async), a seguir quando a camada 2 vai para baixo, a interface física real vai para baixo. Isto provoca uma mudança na base de dados do OSPF e a interface assíncrona vem apoio outra vez para trocar o banco de dados. A camada 2 vai para baixo outra vez, e esta provocará a mudança no banco de dados outra vez, assim que este processo mantém-se em repetir-se.

A seguinte encenação é usada para reproduzir o problema acima.

/image/gif/paws/4808/dc4.gif

A seguinte configuração é usada para a encenação 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 do OSPF padrão é ponto a ponto em uma interface assíncrona, mas ainda o circuito da procura mantém-se trazer acima 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 que o circuito da procura se mantém trazer acima o link é porque quando a camada 2 vai para baixo depois que o idle timeout expira, a relação inteira vai para baixo. Mas no caso do BRI ou do PRI, quando um dos canais vai para baixo, a relação ainda permanece acima (no modo de falsificação). Para resolver o problema você deve configurar uma interface do discador porque nunca vai para baixo. Uma interface do discador permanece acima (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

Desde que a interface do discador nunca vai para baixo, não criará o problema que é criado quando uma interface assíncrona vai para baixo.

Razão 6: O circuito de demanda OSPF está configurado sobre um multilink PPP

A característica do Multilink PPP pode ser usada para finalidades do Balanceamento de carga nos casos lá é link de WAN múltiplo. Um importante a recordar em termos do OSPF é a largura de banda do Multilink PPP. Quando os links múltiplos são combinados, a largura de banda da interface multilink mudará.

A seguinte encenação é usada para reproduzir o problema acima.

/image/gif/paws/4808/dc5.gif

A seguinte configuração é usada para a encenação 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 seguinte saída mostra que há três interfaces serial empacotadas junto no Multilink PPP.

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 de interface representará a largura de banda agregada do link, e esta largura de banda será usada no cálculo de custo de 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 da relação OSPF da mostra IP mostra os custos de OSPF atuais, que são 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 vai para baixo e nós podemos ver aquele no log:

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 nós verificamos a largura de banda outra vez será diferente do que o que nós vimos previamente. Agora está mostrando que 3968 e o pacote têm somente duas relações em vez de três porque uma relação foi para baixo. Note abaixo a relação é ainda acima:

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)

Também, o multilink de PPP ainda está aparecendo, mas os custos de OSPF são mudados agora a 25 desde que um link está para baixo

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)

Este o que provocarão o cálculo SPF, e OSPF trará acima o circuito da procura. Se o link se mantém bater então nós podemos ver que o circuito da procura para se manter bater porque o custo será mudado todas as vezes um link adiciona acima ou obtém suprimido o do conjunto de PPP multilink.

Solução

O multilink de PPP é apoiado no OSPF, mas enquanto todo o link dentro do pacote fica acima, o circuito da procura será estável. Assim que um link for para baixo, mesmo que não haja nenhum endereço IP de Um ou Mais Servidores Cisco ICM NT associado com ele, afetará o cálculo de custo de OSPF, e devido ao esse, o OSPF executará o SPF para voltar a calcular os melhores caminhos. Para resolver este problema, a única solução é configurar manualmente os custos de OSPF com o comando seguinte.

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

Este comando certificar-se-á de que cada vez que há um link que esteja adicionado ou suprimido no conjunto de PPP multilink, os custos de OSPF não serão afetados. Isto vontade estabiliza o circuito da procura OSPF sobre o multilink de PPP.

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 4808