IP : Protocole OSPF (Open Shortest Path First)

Pourquoi la fonction OSPF Demand Circuit continue à activer la liaison

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


Contenu


Introduction

Quand un lien de Protocole OSPF (Open Shortest Path First) est configuré pendant que le circuit de demande, OSPF Hellos sont supprimés et le LSA périodique régénère ne sont pas inondés au-dessus du lien. Ces paquets évoquent le lien seulement quand ils sont permutés pour la première fois, ou quand une modification se produit dans les informations ils contiennent. Ceci laisse la couche liaison de données sous-jacente à fermer quand la topologie du réseau est stable. Un circuit de demande qui va en haut et en bas indique un problème qui doit être étudié. Ce document explique quelques causes possibles et offre des solutions.

Le circuit sur demande de pour en savoir plus, se rapportent à la caractéristique d'OSPF Demand Circuit.

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 des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.

Réseau témoin

Le problème mentionné ci-dessus est décrit avec le schéma de réseau et la configuration suivants.

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

Routeur 1 Routeur 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

Remarque: Vous devez configurer le circuit de demande à une fin du lien seulement. Cependant, si vous configurez cette commande sur les deux extrémités il n'entraîne aucun mal.

Dans le diagramme ci-dessus, les Routeurs 1 et 2 exécutent le circuit de demande OSPF à travers la liaison RNIS. Le lien entre les Routeurs 1 et 2 continue à être soulevé, qui défait le but du circuit de demande OSPF. La sortie de la commande de show dialer prouve que le lien a été soulevé en raison du paquet HELLO multicast 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)

Le lien peut être évoqué pour plusieurs raisons. Au-dessous de nous explorons plusieurs cas communs et offrons des solutions.

Raison 1 : Changement de la topologie du réseau

Toutes les fois qu'il y a un changement d'une topologie du réseau OSPF, on doit annoncer les Routeurs OSPF. Dans cette situation le circuit de demande OSPF devrait être amené de sorte que les voisins puissent permuter les nouvelles informations. Une fois que la nouvelle base de données est permutée le lien peut descendre de nouveau et la contiguïté demeure dans le PLEIN énoncent.

Solution

Pour déterminer si le lien est amené en raison d'un changement de topologie du réseau, utilisez la commande de moniteur OSPF d'IP de débogage. Il affiche quel LSA change, comme vu ci-dessous :

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

La sortie ci-dessus affiche qu'il y avait un changement du LSA du routeur avec l'ID de routeur de 192.168.246.41, qui cause la base de données d'être resynchronisée. Si le réseau est stable, alors des expositions de cette sortie de débogage rien.

Pour réduire l'affect des instabilités de lien sur le circuit de demande, configurez la zone qui contient le circuit de demande en tant que totalement stub. Si ce n'est pas faisable, et il y a une instabilité constante de lien dans le réseau, le circuit de demande ne pourrait pas être un bon choix pour vous.

Raison 2 : Type de réseau défini comme émission

Quand vous configurez le circuit de demande sur un lien, le type de lien doit être défini en tant que point par point ou point-à-multipoint. N'importe quel autre type de lien peut causer le lien d'être soulevé inutilement parce que l'OSPF Hellos ne sont pas supprimés si le type de réseau est quelque chose autre que point par point ou point-à-multipoint. Être suit une configuration d'échantillon pour illustrer ce problème sur les Routeurs 1 et 2.

Routeur 1 Routeur 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

Le type de réseau étant défini comme émission, l'OSPF Hellos évoquent le lien à chaque intervalle entre deux paquets Hello. La sortie de show dialer prouve que la dernière fois où le lien a été amené était en raison d'un OSPF bonjour.

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)

Solution

Pour résoudre ce problème, changent le type de réseau à point par point ou à point-à-multipoint. Ici nous retirons la diffusion du type de réseau ainsi par défaut il est configuré comme Point à point.

Routeur 1 Routeur 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

En changeant le type de réseau à point par point ou à point-à-multipoint, l'OSPF Hellos sont supprimés sur le lien, et la liaison de circuit à la demande cesse le battement.

Raison 3 : Un ou plusieurs Routeurs ne comprennent pas le circuit de demande

Quand un ou plusieurs Routeurs dans le domaine OSPF ne comprennent pas le circuit de demande, un LSA périodique régénèrent se produit. Voyez que quand est un LSA périodique régénérez envoyé au-dessus d'un OSPF Demand Circuit ? section de ce document pour apprendre comment résoudre ce problème.

Raison 4 : La route hôte est redistribuée dans la base de données OSPF

Considérons comme exemple le schéma de réseau suivant :

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

Le lien entre les Routeurs 1 et 2 est 131.108.1.0/24, et le circuit de demande est configuré entre les Routeurs 1 et 2. que le routeur 1 redistribue des artères de Protocole RIP (Routing Information Protocol) dans l'OSPF.

Routeur 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

Puisque le type d'encapsulation de lien est PPP, les deux Routeurs installent une route hôte pour l'autre côté du lien comme affiché ci-dessous.

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

Le Protocole IGRP (Interior Gateway Routing Protocol) et le RIP sont des protocoles de routage de par classe, et donc la déclaration de réseau dans la configuration est pour un réseau par classe de 131.108.0.0. Pour cette raison la route hôte de 131.108.1.2/32 est considérée pour être lancée par le RIP et obtient redistribué dans l'OSPF comme artère externe comme affiché ci-dessous.

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

Quand le lien descend /32 disparaît et l'OSPF comprend ceci comme changement de topologie. Le circuit de demande évoque le lien de nouveau propager la version MAXAGE du masque de /32 à son voisin. Quand le lien est soulevé, le masque de /32 devient valide de nouveau ainsi l'âge LSA obtient la remise. Alors après que le temporisateur mort du lien donne un coup de pied dedans, le lien descend de nouveau. Ce processus se répète et la liaison de circuit à la demande continue le battement. Il y a trois manières de résoudre ce problème affiché ci-dessous.

Solution 1 : N'utilisez l'aucune commande de voisin-artère de pair

Sous l'interface BRI qui exécute le circuit de demande, ne configurez aucune voisin-artère de pair. Ceci empêche le masque de /32 d'être installé. Vous pouvez utiliser la configuration illustrée ci-dessous sur le routeur 1 seulement, mais nous recommandons configurer cette commande des deux côtés pour la cohérence.

R1# configure terminal
R1(config)# interface BRI1/1
R1(config-if)# no peer neighbor-route

Solution 2 : Utilisez la commande de route-map

En redistribuant du RIP dans l'OSPF, utilisez la commande de route-map et refusez /32 ainsi il n'obtient pas injecté dans la base de données OSPF. Cette commande de configuration est exigée seulement sur le routeur qui fait la redistribution, qui dans notre exemple est le routeur 1.

D'abord nous devons créer une liste d'accès pour apparier le masque de /32. Alors nous appliquons cette liste d'accès au mappage de route et utilisons le mappage de route en appliquant la commande de redistribution comme affiché ci-dessous.

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

Solution 3 : Utilisez un réseau principal différent

Utilisez un réseau principal différent pour le RIP ou le domaine OSPF. L'idée est d'avoir un réseau principal différent sur la liaison de circuit à la demande ainsi quand le lien est soulevé sous l'encapsulation PPP qu'il installe la route hôte pour l'autre côté du lien. Si la route hôte est en réseau principal différent que celui étant utilisé dans le RIP, le RIP ne possède pas cette route hôte Ppp-installée parce qu'il n'a pas une déclaration de réseau pour le réseau principal. Le schéma de réseau ci-dessous affiche un exemple.

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

Le domaine de RIP est maintenant sous le réseau de 141.108.0.0 tandis que le domaine OSPF (et la liaison de circuit à la demande) est sous le réseau de 131.108.0.0.

Raison 5 : L'OSPF Demand Circuit est configuré au-dessus d'une interface asynchrone

Quand vous configurez un circuit de demande au-dessus d'une interface (async) asynchrone, alors quand la couche 2 descend, l'interface physique réelle descend. Ceci déclenche un changement de la base de données OSPF et l'interface asynchrone se réactive de nouveau pour permuter la base de données. La couche 2 descend de nouveau, et ceci déclenchera le changement de la base de données de nouveau, ainsi ce processus continue à se répéter.

Le scénario suivant est utilisé pour reproduire le problème ci-dessus.

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

La configuration suivante est utilisée pour le scénario ci-dessus.

Routeur 1 Routeur 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

Le type de réseau d'OSPF par défaut est point par point sur une interface asynchrone, mais le circuit de demande continue toujours à évoquer le lien.

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)

Solution

La raison que le circuit de demande continue à évoquer le lien est parce que quand la couche 2 descend après que le délai d'attente de veille expire, l'interface entière descend. Mais dans le cas de BRI ou de PRI, quand un des canaux descend, l'interface demeure toujours (en mode de mystification). Pour résoudre le problème vous devez configurer une interface de numérotation parce qu'elle ne descend jamais. Une interface de numérotation demeure (en mode de mystification).

Routeur 1 Routeur 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

Puisque l'interface de numérotation ne descend jamais, elle ne créera pas le problème qui est créé quand une interface asynchrone descend.

Raison 6 : L'OSPF Demand Circuit est configuré au-dessus d'un PPP à liaisons multiples

La caractéristique de PPP à liaisons multiples peut être utilisée pour l'Équilibrage de charge dans des cas là sont des plusieurs liaisons WAN. Une chose importante à se souvenir en termes d'OSPF est la bande passante du PPP à liaisons multiples. Quand de plusieurs liens sont combinés, la bande passante de l'interface multiliaison changera.

Le scénario suivant est utilisé pour reproduire le problème ci-dessus.

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

La configuration suivante est utilisée pour le scénario ci-dessus.

Routeur 1 Routeur 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

La sortie suivante prouve qu'il y a trois interfaces série empaquetées ensemble dans le PPP à liaisons multiples.

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

La bande passante d'interface représentera la bande passante agrégée du lien, et cette bande passante sera utilisée dans le calcul de coût 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

La sortie du show ip ospf interface affiche le coût OSPF en cours, qui est 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)

Maintenant un lien va vers le bas et nous pouvons voir cela dans le 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

Si nous vérifions la bande passante de nouveau elle sera différente que ce que nous avons vu précédemment. Maintenant il affiche que 3968 et le paquet a seulement deux interfaces au lieu de trois parce qu'une interface est descendue. La note ci-dessous l'interface est toujours :

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)

En outre, le ppp multilink apparaît toujours, mais le coût OSPF est maintenant changé à 25 puisqu'un lien est en baisse

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)

Ce ce qui déclencheront le calcul SPF, et OSPF évoquera le circuit de demande. Si le lien continue à s'agiter alors nous pouvons voir que le circuit de demande continuer à agiter parce que le coût sera changé chaque fois un lien ajoute ou obtient supprimé le de l'ensemble Multilink PPP.

Solution

Le ppp multilink est pris en charge dans l'OSPF, mais tant que tout le lien dans le paquet reste, le circuit de demande sera stable. Dès qu'un lien descendra, quoiqu'il n'y ait aucune adresse IP associée avec elle, elle affectera le calcul de coût OSPF, et en raison du ce, l'OSPF exécutera la SPF pour recalculer les meilleurs chemins. Pour résoudre ce problème, la seule solution est de configurer le coût OSPF manuellement avec la commande suivante.

Routeur 1 Routeur 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

Cette commande s'assurera que chaque fois qu'il y a un lien qui est ajouté ou supprimé dans l'ensemble Multilink PPP, le coût OSPF ne sera pas affecté. Ceci volonté stabilise le circuit de demande OSPF au-dessus du ppp multilink.


Informations connexes


Document ID: 4808