IP : Protocole OSPF (Open Shortest Path First)

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

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Cette note en tech explique une question avec la formation de la contiguïté OSPF quand les interfaces de numérotation sont configurées en tant que liens point par point.

Conditions préalables

Conditions requises

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

Composants utilisés

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

Conventions

Pour plus d'informations sur les conventions de documents, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Le problème

Le type de réseau OSPF sur l'accès primaire (PRI), accès de base (BRI), et les interfaces de numérotation est point par point, ainsi lui signifie qu'une interface ne peut pas former la contiguïté avec plus d'un voisin. Un problème courant quand un PRI, un BRI, ou un essai d'interfaces de numérotation pour former une contiguïté OSPF est le voisin est bloqué dans l'exstart/processus d'échange. Regardons un exemple.

/image/gif/paws/13691/20a.gif

Utilisant la commande de show ip ospf neighbor, nous pouvons voir que l'état de voisinage 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 affiche que le type de réseau est point par 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 mettre au point cette situation utilisant la commande de debug ip ospf adj. Regardons une certaine sortie témoin prise tout en exécutant 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 0xB41 seq et reçoit le premier DBD de 3.3.3.2 (RTR-A) avec le seq# 0x1D06. La négociation avec les voisins n'est toujours pas complète.

Lignes 4 - 6 : RTR-B reçoit une réponse de 3.3.3.2 (RTR-A) indiquant que RTR-A a reçu le DBD de Rtr-b premier. Puisque RTR-B a l'ID de routeur plus élevé, RTR-A s'élit slave. Après réception de l'accusé de réception de RTR-A, RTR-B se déclare principal et envoie le premier DBD avec des données dans lui. Notez le numéro de séquence, qui est 0xB42. Puisque RTR-B est le maître, seulement il peut incrémenter le numéro de séquence.

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

Ligne 8 : RTR-B envoie un paquet de requête d'état de liaison à 3.3.3.2 (RTR-A). C'est un type de paquet 3. OSPF. Ce paquet est habituellement 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 de l'esclave (RTR-A) avec un numéro de séquence complètement différent et d'un indicateur de 0x7, qui est l'indicateur d'init. Ce DBD a été destiné pour un autre routeur (RTR-C le plus susceptible), mais RTR-B l'a inexactement reçu. RTR-B déclare il y a une anomalie parce qu'un indicateur de 0x7 signifie que l'esclave a changé son état pour maîtriser en plaçant le bit (master/slave) de MS pendant l'échange de contiguïté. RTR-B se plaint également au sujet du numéro de séquence parce qu'il est en panne. L'esclave devrait 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 que c'est un esclave, sans identifier le numéro de séquence du Rtr-b. RTR-B déclare qu'il n'identifie pas ce DBD puisque le maître et asservit négociation n'est pas complet encore. Ce paquet DBD a été destiné pour un autre routeur.

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

Ligne 16 : RTR-B n'identifie pas ce DBD parce qu'il est pour une « vieille » contiguïté, que RTR-B a déjà démolie.

Ce processus répètera sans fin.

La solution

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

Pour résoudre ce problème, changez le type de réseau sur tous les Routeurs à point-à-multipoint. Ceci change le comportement de l'OSPF pour envoyer des paquets monodiffusions après l'état bidirectionnel. Maintenant RTR-B reçoit seulement des paquets destinés pour lui-même et RTR-C reçoit des paquets destinés pour lui-même. Changer le type de réseau s'assure de cette façon que le routeur OSPF formera la contiguïté sur un PRI, un BRI, ou une interface de numérotation.

Pour changer le type de réseau, sélectionnez les commandes suivantes de configuration, finissant chaque ligne en appuyant sur ENTRENT. Nous changerons 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 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


Document ID: 13691