Pourquoi l'OSPF ne forme-t-il pas une contiguïté sur une interface PRI, BRI ou de numéroteur ?

Introduction

Cette note technique explique un problème lié à la formation de contiguïté OSPF lorsque les interfaces de numérotation sont configurées en tant que liaisons point à point.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Components Used

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Conventions

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

Le problème

Le type de réseau OSPF sur les interfaces PRI (Primary Rate Interface), BRI (Basic Rate Interface) et de numérotation est point à point, ce qui signifie qu'une interface ne peut pas former de contiguïté avec plusieurs voisins. Un problème courant lorsqu'une interface PRI, BRI ou de numérotation tente de former une contiguïté OSPF est que le voisin est coincé dans le processus exstart/exchange. Examinons un exemple .

À l'aide de la commande show ip ospf neighbor, nous pouvons voir que l'état du voisin est coincé dans EXSTART.

RTR-A# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3           1   EXSTART/  -     00:00:37    3.3.3.3         Serial6/0:23
3.3.3.4           1   EXSTART/  -     00:00:39    3.3.3.4         Serial6/0:23

RTR-B# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.2           1   EXSTART/  -     00:00:36    3.3.3.2         BRI0

RTR-C# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.2           1   EXSTART/  -     00:00:35    3.3.3.2         BRI0

La configuration RTR-Bs indique que le type de réseau est point à point :

RTR-B# show ip ospf interface bri0 
     BRI0 is up, line protocol is up (spoofing) 
       Internet Address 3.3.3.3/24, Area 2 
       Process ID 1, Router ID 3.3.3.3, Network Type POINT_TO_POINT, Cost: 1562 
       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:06 
       Index 1/1, flood queue length 0 
       Next 0x0(0)/0x0(0) 
       Last flood scan length is 1, maximum is 1 
       Last flood scan time is 0 msec, maximum is 0 msec 
       Neighbor Count is 1, Adjacent neighbor count is 0 
       Suppress hello for 0 neighbor(s) 

Nous pouvons déboguer cette situation à l'aide de la commande debug ip ospf adj. Examinons un exemple de résultat pris lors de l'exécution de cette commande sur RTR-B dans la figure ci-dessus :

1: Send DBD to 3.3.3.2 on BRI0 seq 0xB41 opt 0x42 flag 0x7 len 32 
2: Rcv DBD from 3.3.3.2 on BRI0 seq 0x1D06 opt 0x42 flag 0x7 len 32 
   mtu 1500 state EXSTART 
3: First DBD and we are not SLAVE 
4: Rcv DBD from 3.3.3.2 on BRI0 seq 0xB41 opt 0x42 flag 0x2 len 92 mtu 
   1500 state EXSTART 
5: NBR Negotiation Done. We are the MASTER 
6: Send DBD to 3.3.3.2 on BRI0 seq 0xB42 opt 0x42 flag 0x3 len 92 
7: Database request to 3.3.3.2 
8: sent LS REQ packet to 3.3.3.2, length 12 
9: Rcv DBD from 3.3.3.2 on BRI0 seq 0x250 opt 0x42 flag 0x7 len 32 
   mtu 1500 state EXCHANGE 
10: EXCHANGE - inconsistent in MASTER/SLAVE 
11: Bad seq received from 3.3.3.2 on BRI0 
12: Send DBD to 3.3.3.2 on BRI0 seq 0x2441 opt 0x42 flag 0x7 len 32 
13: Rcv DBD from 3.3.3.2 on BRI0 seq 0x152C opt 0x42 flag 0x2 len 92 
    mtu 1500 state EXSTART 
14: Unrecognized dbd for EXSTART 
15: Rcv DBD from 3.3.3.2 on BRI0 seq 0xB42 opt 0x42 flag 0x0 len 32 
    mtu 1500 state EXSTART 
16: Unrecognized dbd for EXSTART 

Lignes 1 à 3 : RTR-B envoie le premier DBD à 3.3.3.2 (RTR-A) avec seq 0xB41 et reçoit le premier DBD de 3.3.3.2 (RTR-A) avec seq# 0x1D06. La négociation de voisinage n'est toujours pas terminée.

Lignes 4 à 6 : RTR-B reçoit une réponse du 3.3.3.2 (RTR-A) indiquant que RTR-A a reçu le premier DBD de RTR-B. Puisque RTR-B a l'ID de routeur le plus élevé, RTR-A se choisit comme esclave. Après avoir reçu l'accusé de réception de RTR-A, RTR-B se déclare maître et envoie le premier DBD contenant des données. Notez le numéro de séquence, qui est 0xB42. Puisque RTR-B est le maître, seul il peut incrémenter le numéro de séquence.

Ligne 7 : RTR-B demande des données à RTR-A puisque RTR-A a indiqué qu'il a plus de données à envoyer (indicateur défini sur 0x2 dans le dernier DBD reçu de RTR-A).

Ligne 8 : RTR-B envoie un paquet de requête d’état de liens à 3.3.3.2 (RTR-A). Il s’agit d’un paquet OSPF de type 3. Ce paquet est généralement envoyé à l'adresse IP du voisin. Dans ce cas, l'adresse IP du voisin est son ID de routeur.

Lignes 9 à 11 : RTR-B reçoit une réponse d'esclave (RTR-A) avec un numéro de séquence complètement différent et un indicateur de 0x7, qui est l'indicateur init. Ce DBD était destiné à un autre routeur (probablement RTR-C), mais RTR-B l'a reçu de manière incorrecte. RTR-B déclare qu'il y a une différence car un indicateur de 0x7 signifie que l'esclave a modifié son état en maître en définissant le bit MS (Master/Slave) pendant l'échange de contiguïté. RTR-B se plaint également du numéro de séquence, car il est en panne. L'esclave doit toujours suivre le numéro de séquence du maître.

Ligne 12 : RTR-B réinitialise la contiguïté en envoyant le premier DBD à 3.3.3.2 pour réélire le maître et l'esclave.

Lignes 13 à 14 : RTR-B reçoit un DBD de 3.3.3.2 (RTR-A), indiquant qu'il s'agit d'un esclave, sans reconnaître le numéro de séquence de RTR-B. RTR-B déclare qu'il ne reconnaît pas ce DBD car la négociation maître et esclave n'est pas encore terminée. Ce paquet DBD était destiné à un autre routeur.

Ligne 15 : RTR-B reçoit une réponse de 3.3.3.2 (RTR-A) pour l'ancien DBD, mais il est trop tard car RTR-B a déjà réinitialisé le processus de contiguïté.

Ligne 16 : RTR-B ne reconnaît pas ce DBD parce qu'il s'agit d'une « ancienne » contiguïté, que RTR-B a déjà désactivée.

Ce processus se répétera sans fin.

La solution

Selon la section 8.1 de RFC 2328 , OSPF envoie un paquet de multidiffusion pour un type de réseau point à point, même après que l'interface ait atteint l'état bidirectionnel. Puisque RTR-A tente de former des contiguïtés avec RTR-B et RTR-C, RTR-B reçoit des paquets DBD destinés à RTR-C et RTR-C reçoit des paquets DBD destinés à RTR-B.

Pour résoudre ce problème, modifiez le type de réseau sur tous les routeurs en point à multipoint. Cela modifie le comportement d'OSPF pour envoyer des paquets de monodiffusion après l'état 2. Maintenant, RTR-B reçoit uniquement les paquets destinés à lui-même et RTR-C reçoit les paquets destinés à lui-même. La modification du type de réseau de cette manière garantit que le routeur OSPF formera une contiguïté sur une interface PRI, BRI ou de numérotation.

Pour modifier le type de réseau, entrez les commandes de configuration suivantes, en terminant chaque ligne en appuyant sur ENTRÉE. Nous allons changer RTR-B comme exemple.

RTR-B# configure terminal 
RTR-B(config)# int bri 0 
RTR-B(config-if)# ip ospf network point-to-multipoint 
RTR-B(config-if)# end 

Maintenant, si nous regardons les commandes show pour RTR-B, nous pouvons vérifier que le type de réseau est point à multipoint et que l'état est plein.

RTR-B# show ip ospf interface bri0 
BRI0 is up, line protocol is up (spoofing) 
  Internet Address 3.3.3.3/24, Area 2 
  Process ID 1, Router ID 3.3.3.3, Network Type POINT_TO_MULTIPOINT, Cost: 1562 
  Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT, 
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 
    Hello due in 00:00:16 
  Index 1/1, flood queue length 0 
  Next 0x0(0)/0x0(0) 
  Last flood scan length is 1, maximum is 1 
  Last flood scan time is 0 msec, maximum is 0 msec 
  Neighbor Count is 1, Adjacent neighbor count is 1 
    Adjacent with neighbor 172.16.141.10 
  Suppress hello for 0 neighbor(s) 
  
RTR-B# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
172.16.141.10     1   FULL/  -        00:01:36    3.3.3.2         BRI0 

Informations connexes

• Configuration de l'accès commuté de BRI à BRI à l'aide du routage DDR (Dialer Maps)
• Page de support OSPF
• Support technique - Cisco Systems