Problèmes d'exécution d'OSPF en mode NBMA et Diffusion sur relais de trame

Mis à jour:29 décembre 2005
ID du document:13696

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

Introduction

Cette note technique décrit un problème lié aux routes OSPF qui apparaissent dans la base de données d'état de lien, mais qui n'apparaissent pas dans la table de routage dans un environnement Frame Relay entièrement maillé. Pour voir d'autres exemples, consultez le document Pourquoi certaines routes OSPF se trouvent dans la base de données, mais sont absentes de la table de routage?

Conditions préalables

Conditions requises

Les lecteurs de ce document devraient avoir connaissance des sujets suivants :

  • OSPF

  • Relais de trames

Components Used

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques. Cependant, la configuration de ce document est testée et mise à jour à l'aide des versions logicielles et matérielles suivantes :

  • Routeur de la gamme 2500 de Cisco

  • Cisco IOS® version 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.

Théorie générale

L’exemple ci-dessous utilise un environnement Frame Relay entièrement maillé. Le schéma et les configurations du réseau sont présentés ci-dessous :

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

Sommeil 
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

Éternué 
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

Problème

Initialement, tous les routeurs ont toutes les routes dans leurs tables de voisinage. Un événement se produit qui entraîne la suppression de Doc et Sleepy l'un de l'autre de leurs tables de voisinage respectives. À partir des tables de voisinage indiquées dans cette section, nous pouvons voir que la table de voisinage Doc n'a pas l'entrée 70.70.70.70 et que la table de voisinage endormie n'a pas l'entrée 50.50.50.50.

Table de voisinage 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
Table de voisinage endormie 
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
Table de voisinage éternuante 
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

En outre, Doc perd toutes les routes OSPF de sa table de routage, et Sleepy et Sneezy n'ont plus 50.50.50.0 (sous-réseau LAN de Doc) dans leurs tables de routage.

Table de routage de document 
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
Table de routage endormie 
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
Table de routage éternuante 
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

Bien que Doc n’ait aucune route OSPF dans sa table de routage, nous pouvons voir d’après le résultat ci-dessous qu’il possède une base de données OSPF complète.

Base de données Doc 
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

L’état de liaison du réseau est un état de liaison généré par le routeur désigné (DR) qui décrit tous les routeurs connectés au réseau. Dans le résultat ci-dessous, nous voyons que le routeur désigné ne répertorie pas l’ID de routeur Doc (50.50.50.50) comme routeur connecté, ce qui brise le modèle de diffusion. Par conséquent, Doc n’installe aucune route OSPF apprise via le réseau Frame Relay.

État de la liaison réseau 
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

Une autre façon de voir cela est que Doc déclare Sneezy comme DR et attend de Sneezy qu'il génère un état de liaison réseau. Cependant, comme Sneezy n’est pas un routeur désigné, il ne génère pas d’état de liaison réseau, ce qui à son tour ne permet pas à Doc d’installer des routes dans sa table de routage.

Table de voisinage 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

Causes

Selon la base de données, le routeur désigné du nuage Frame Relay est Sleepy. Cependant, Sleepy ne voit pas Doc comme voisin OSPF. Comme le montre cet exemple, la requête ping de Sleepy vers Doc échoue :

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)

D'après la sortie de la commande show frame-relay map dans Sleepy, nous pouvons voir que l'identificateur DLCI allant à Doc est inactif. Cela explique pourquoi Sleepy ne peut pas envoyer de requête ping à Doc, et pourquoi ils ne se voient pas comme des voisins. Il s'agit de l'événement qui a déclenché le problème :

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

Comme le circuit virtuel permanent entre Doc et Sleepy est rompu et que la liaison de Doc au routeur désigné (DR) est rompue, Doc déclare toutes les LSA de Sneezy (qui n'est pas un DR) inaccessibles. Le modèle de diffusion sur Frame Relay fonctionne correctement si le nuage Frame Relay est entièrement maillé. Si des circuits virtuels permanents (PVC) sont rompus, cela peut créer des problèmes dans la base de données OSPF, ce qui ressort clairement du résultat de la commande show ip ospf database router ci-dessous, qui affiche le message Adv router is not-reachable.

Table de voisinage 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

Solution

Lorsque vous configurez le protocole OSPF pour qu'il s'exécute sur un réseau à accès multiple prenant en charge la diffusion ou non, tous les périphériques doivent pouvoir communiquer directement avec (au minimum) le routeur désigné. Le modèle de diffusion et de NBMA repose sur le fait que le nuage Frame Relay est entièrement maillé. Si un circuit virtuel permanent (PVC) tombe en panne, le cloud n'est plus entièrement maillé et OSPF ne fonctionne pas correctement.

Dans un environnement Frame Relay, si la couche 2 est instable, comme dans notre exemple, nous ne recommandons pas un type de réseau de diffusion OSPF. Utilisez plutôt OSPF point à multipoint.

Informations connexes

Historique de révision

Révision Date de publication Commentaires
1.0
29-Dec-2005
Première publication

Ce document vous est-il utile?

FeedbackCommentaires

Contacter Cisco

Ce document s’applique à ces produits