Problemas com a execução do OSPF no NBMA e no modo de broadcast no Frame Relay

Opções de download

  • PDF     (222.6 KB)
    Ver no Adobe Reader em vários dispositivos
  • ePub     (104.1 KB)
    Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
  • Mobi (Kindle)     (121.5 KB)
    Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos
Atualizado:29 de dezembro de 2005
ID do documento:13696

Linguagem imparcial

O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.

Sobre esta tradução

A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.

Introduction

Esta Nota Técnica explica um problema relacionado às rotas de OSPF que aparecem na base de dados de estado do link, mas não na tabela de roteamento em um ambiente Frame Relay totalmente em malha. Para mais cenários, veja Por que algumas rotas OSPF estão no banco de dados mas não na tabela de roteamento?.

Prerequisites

Requirements

Os leitores deste documento devem estar cientes destes tópicos:

  • OSPF

  • Frame Relay

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas. No entanto, a configuração neste documento é testada e atualizada pelo uso destas versões de software e hardware:

  • Cisco 2500 Series Router

  • Cisco IOS® versão 12.2(24a)

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Material de Suporte

O exemplo abaixo usa um ambiente de Frame Relay totalmente em malha. O diagrama de rede e as configurações são mostrados abaixo:

24a.gif

Doc 
interface Ethernet0 
 ip address 50.50.50.50 255.255.255.0 

interface Serial0 
 encapsulation frame-relay 

!--- Enables Frame Relay encapsulation on the interface.

interface Serial0.1 multipoint 

!--- The subinterface is configured as a multipoint link.

 ip address 10.10.10.5 255.255.255.0 
 ip ospf network broadcast 

!--- This command is used to define the network type as broadcast.


!--- The network type is defined on nonbroadcast networks to
 

!--- avoid configuring the neighbors explicitly.

 frame-relay map ip 10.10.10.6 101 broadcast 
 frame-relay map ip 10.10.10.10 100 broadcast 

!--- To define the mapping between a destination protocol address


!--- and the data-link connection identifier (DLCI) used to
 

!--- connect to the destination address.
  

!--- The broadcast keyword is used to forward broadcasts to
 

!--- this address when broadcast/multicast is
 

!--- disabled because of non-broadcast medium.

router ospf 1 
 network 0.0.0.0 255.255.255.255 area 0

Sonolência 
interface Ethernet0 
  ip address 70.70.70.70 255.255.255.0 

 interface Serial0 
  encapsulation frame-relay

!--- Enables Frame Relay encapsulation on the interface. 
interface Serial0.1 multipoint 

!--- The subinterface is configured as a multipoint link. 
  ip address 10.10.10.6 255.255.255.0 
  ip ospf network broadcast

!--- This command is used to define the network type as broadcast. 
!--- The network type is defined on nonbroadcast networks to 

!--- avoid configuring the neighbors explicitly. 
  frame-relay map ip 10.10.10.5 101 broadcast 
  frame-relay map ip 10.10.10.10 102 broadcast 

!--- To define the mapping between a destination protocol address !--- and the DLCI used to connect to the destination address. !--- The broadcast keyword is used to forward broadcasts to !--- this address when broadcast/multicast is !--- disabled because of non-broadcast medium.

 router ospf 1 
  network 0.0.0.0 255.255.255.255 area 0

espirro 
interface Ethernet0 
  ip address 60.60.60.60 255.255.255.0 

 interface Serial0 
  encapsulation frame-relay 

!--- Enables Frame Relay encapsulation on the interface.

 interface Serial0.1 multipoint

!--- The subinterface is configured as a multipoint link. 

  ip address 10.10.10.10 255.255.255.0 
  ip ospf network broadcast

!--- This command is used to define the network type as broadcast. !--- The network type is defined on nonbroadcast networks to !--- avoid configuring the neighbors explicitly.
 


  frame-relay map ip 10.10.10.5 100 broadcast 
  frame-relay  map ip 10.10.10.6 102 broadcast 

!--- To define the mapping between a destination protocol address !--- and the DLCI used to connect to the destination address. !--- The broadcast keyword is used to forward broadcasts to !--- this address when broadcast/multicast is !--- disabled because of non-broadcast medium.

 router ospf 1 
  network 0.0.0.0 255.255.255.255 area 0

Problema

Inicialmente, todos os roteadores têm todas as rotas em suas tabelas de vizinhos. Ocorre um evento que faz com que o Doc e o Sleepy se soltem das respectivas tabelas de vizinhos. Nas tabelas de vizinhos desta seção, podemos ver que a tabela de vizinhos Doc não tem a entrada 70.70.70.70 e a tabela de vizinhos Sleepy não tem a entrada 50.50.50.50.

Tabela de vizinho Doc 
doc# 
show ip ospf neighbor

  
 Neighbor ID Pri State        Dead Time Address     Interface
 60.60.60.60 1   FULL/DR      00:00:33 10.10.10.10  Serial0.1
Tabela de vizinho Sleepy 
sleepy# show ip ospf neighbor

 Neighbor ID Pri State        Dead Time Address     Interface
 60.60.60.60 1   FULL/BDR     00:00:32 10.10.10.10  Serial0.1
Tabela de vizinhos desprezíveis 
sneezy# show ip ospf neighbor

 Neighbor ID Pri State        Dead Time Address     Interface
 50.50.50.50 1   FULL/DROTHER 00:00:36  10.10.10.5  Serial0.1
 70.70.70.70 1   FULL/DR      00:00:31  10.10.10.6  Serial0.1

Além disso, o Doc perde todas as rotas OSPF de sua tabela de roteamento e o Sleepy e o Sneezy não têm mais 50.50.50.0 (sub-rede LAN do Doc) em suas tabelas de roteamento.

Tabela de Roteamento de Doc 
doc# 
show ip route

 Gateway of last resort is not set
      10.0.0.0 255.255.255.0 is subnetted, 1 subnets
 C       10.10.10.0 is directly connected, Serial0.1
      50.0.0.0 255.255.255.0 is subnetted, 1 subnets
 C       50.50.50.0 is directly connected, Ethernet0
Tabela de Roteamento Sonora 
sleepy# show ip route
 Gateway of last resort is not set
      10.0.0.0/ 24 is subnetted, 1 subnets
 C       10.10.10.0 is directly connected, Serial0.1
      60.0.0.0/ 24 is subnetted, 1 subnets
 O       60.60.60.0 [110/ 11175] via 10.10.10.10, 00: 07: 25, Serial0.1
      70.0.0.0/ 24 is subnetted, 1 subnets
 C    70.70.70.0 is directly connected, Ethernet0
Sneezy Routing Table 
sneezy# show ip route
 Gateway of last resort is not set
      10.0.0.0/ 24 is subnetted, 1 subnets
 C       10.10.10.0 is directly connected, Serial0.1
      60.0.0.0/ 24 is subnetted, 1 subnets
 C       60.60.60.0 is directly connected, Ethernet0
      70.0.0.0/ 24 is subnetted, 1 subnets
 O       70.70.70.0 [110/ 11175] via 10.10.10.6, 00: 07: 53, Serial0.1

Embora Doc não tenha rotas de OSPF em sua tabela de roteamento, podemos ver na saída abaixo que ele tem um banco de dados de OSPF completo.

Banco de Dados de Documentos 
doc# 
show ip ospf database


                               OSPF Router with ID (50.50.50.50) (Process ID 1)

                                          Router Link States (Area 0)

 Link ID       ADV Router    Age    Seq#        Checksum Link count
 50.50.50.50   50.50.50.50   169    0x80000030  0x3599   2
 60.60.60.60   60.60.60.60   1754   0x8000002F  0xD26D   2
 70.70.70.70   70.70.70.70   1681   0x8000002D  0xFDD9   2

                                           Net Link States (Area 0)

 Link ID       ADV Router    Age    Seq#        Checksum
 10.10.10.6    70.70.70.70   569    0x8000002B  0x8246

O estado de vínculo de rede é um estado de vínculo gerado pelo DR (Roteador designado) que descreve todos os roteadores anexados à rede. Na saída abaixo, vemos que o DR não lista o ID do roteador Doc (50.50.50.50) como um roteador conectado, o que quebra o modelo de broadcast. Portanto, Doc não instala nenhuma rota OSPF aprendida por meio da rede de Frame Relay.

Network Link-State 
doc# 
show ip ospf database network 10.10.10.6


                                           Net Link States (Area 0)

 LS Type: Network Links
 Link State ID: 10.10.10.6 (address of Designated Router)
 Advertising Router: 70.70.70.70

 Network Mask: 255.255.255.0
       Attached Router: 70.70.70.70
       Attached Router: 60.60.60.60

Outra interpretação possível é que o Doc declara o Sneezy como um DR e espera que o Sneezy gere um link-state de rede. No entanto, não sendo o Sneezy um DR, ele não gera um estado de enlace de rede, que, por sua vez, não permite que o Doc instale nenhum roteador em sua tabela de roteamento.

Tabela de vizinho Doc 
doc# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
60.60.60.60       1   FULL/DR         00:00:29    10.10.10.10     Serial0.1

Causas

De acordo com o banco de dados, o DR da perturbação de Frame Relay está Inativo. Contudo, o Sleepy não considera o Doc como um vizinho de OSPF. Como visto nesse exemplo, o ping de Sleepy to Doc falha:

sleepy# ping 10.10.10.5

Type escape sequence to abort.
Sending 5, 100- byte ICMP Echos to 10.10.10.5, timeout is 2 seconds:
.....
Success rate is 0 percent (0/ 5)

A partir da saída do comando show frame-relay map em Sleepy, podemos ver que o DLCI que está indo para Doc está inativo. Isso explica porque o Sleepy não pode fazer ping no Doc e porque eles não se vêem como vizinhos. Este é o evento que desencadeou o problema:

sleepy# show frame-relay map
Serial0.1 (up): ip 10.10.10.5 dlci 101( 0x65,0x1850), static,
              broadcast,
              CISCO, status defined, inactive

Serial0.1 (up): ip 10.10.10.10 dlci 102( 0x66,0x1860), static,
              broadcast,
              CISCO, status defined, active

Como o PVC entre Doc e Sleepy está quebrado e o link do Dok para o roteador designado (DR) está quebrado, o Doc declara que todos os LSAs do Sneezy (que não é um DR) são inalcançáveis. Este modelo de transmissão sobre Frame Relay funciona corretamente quando a perturbação de Frame Relay está totalmente combinada. Se qualquer circuito virtual permanente (PVCs) for interrompido, ele poderá criar problemas no banco de dados OSPF, o que será evidente a partir da saída do comando show ip ospf database router mostrada a seguir—que exibe a mensagem na qual o roteador Adv não pode ser acessado.

Tabela de vizinho Doc 
doc# 
show ip ospf database router

             OSPF Router with ID (50.50.50.50) (Process ID 1)

                Router Link States (Area 0)

  LS age: 57
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 50.50.50.50
  Advertising Router: 50.50.50.50
  LS Seq Number: 800000D4
  Checksum: 0x355D
  Length: 48
  Number of Links: 2

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.10.10.10
     (Link Data) Router Interface address: 10.10.10.5
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 50.50.50.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 10


  Adv Router is not-reachable
  LS age: 367
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 60.60.60.60
  Advertising Router: 60.60.60.60
  LS Seq Number: 800000C9
  Checksum: 0xC865
  Length: 48
  Number of Links: 2

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.10.10.6
     (Link Data) Router Interface address: 10.10.10.10
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 60.60.60.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 10


  Adv Router is not-reachable
  LS age: 53
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 70.70.70.70
  Advertising Router: 70.70.70.70
  LS Seq Number: 800000CA
  Checksum: 0xEDD4
  Length: 48
  Number of Links: 2

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.10.10.6
     (Link Data) Router Interface address: 10.10.10.6
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 70.70.70.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

Solução

Quando você configura o OSPF para ser executado em uma rede de multiacesso capacitada para broadcast e não-broadcast, todos os dispositivos devem poder se comunicar diretamente com o roteador designado (no mínimo). O modelo de difusão e NBMA depende de a rede de Frame Relay ser totalmente em malha. Se um circuito virtual permanente (PVC) for desativado, a nuvem não estará mais totalmente engrenada e o protocolo OSPF não funcionará corretamente.

Em um ambiente de Frame Relay, se a camada 2 estiver instável, como no exemplo, não recomendamos um tipo de rede de transmissão OSPF. Em vez disso, use o OSPF ponto-a-multiponto.

Informações Relacionadas

Histórico de revisões

Revisão Data de publicação Comentários
1.0
29-Dec-2005
Versão inicial

Este documento lhe foi útil?

FeedbackFeedback

Contate a Cisco

Este documento se refere a estes produtos