Pourquoi la fonction OSPF Demand Circuit continue à activer la liaison
Table des matières
Introduction
Lorsqu’une liaison OSPF (Open Shortest Path First) est configurée en tant que circuit de demande, les Hello OSPF sont supprimés et les actualisations périodiques des LSA ne sont pas diffusées sur la liaison. Ces paquets n'activent la liaison que lorsqu'ils sont échangés pour la première fois ou lorsqu'une modification se produit dans les informations qu'ils contiennent. Cela permet de fermer la couche liaison de données sous-jacente lorsque la topologie du réseau est stable. Un circuit de demande qui monte et descend indique un problème qui doit être étudié. Ce document présente quelques causes possibles et propose des solutions.
Pour plus d'informations sur le circuit de demande, référez-vous à Fonctionnalité de circuit de demande OSPF.
Conditions préalables
Exigences
Aucune exigence spécifique n'est associée à 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 utilisées dans ce document, consultez Conventions relatives aux conseils techniques Cisco.
Exemple de réseau
Le problème mentionné ci-dessus est décrit avec le schéma et la configuration de réseau suivants.
| 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 extrémité de la liaison uniquement. Cependant, si vous configurez cette commande aux deux extrémités, elle ne cause aucun dommage.
Dans le schéma ci-dessus, les routeurs 1 et 2 exécutent un circuit de demande OSPF sur la liaison RNIS. La liaison entre les routeurs 1 et 2 continue de s’établir, ce qui va à l’encontre de l’objectif du circuit de demande OSPF. Le résultat de la commande show dialer montre que la liaison est apparue à cause du paquet Hello de multidiffusion 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)
La liaison peut être activée pour plusieurs raisons. Ci-dessous, nous explorons plusieurs cas courants et proposons des solutions.
Raison 1 : modification de la topologie du réseau
En cas de modification de la topologie d’un réseau OSPF, les routeurs OSPF doivent être avertis. Dans cette situation, le circuit de demande OSPF doit être activé afin que les voisins puissent échanger les nouvelles informations. Une fois la nouvelle base de données échangée, la liaison peut s'arrêter à nouveau et la contiguïté reste à l'état FULL.
Solution
Pour déterminer si la liaison est établie en raison d'une modification de la topologie du réseau, utilisez la commande debug ip ospf monitor. Elle indique quelle LSA est en train de changer, comme indiqué 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
Le résultat ci-dessus montre qu'une modification a été apportée à la LSA du routeur avec l'ID de routeur 192.168.246.41, ce qui entraîne la resynchronisation de la base de données. Si le réseau est stable, alors cette sortie de débogage n'affiche rien.
Pour réduire l'impact des battements de liaison sur le circuit de demande, configurez la zone qui contient le circuit de demande comme totalement stub. Si cela n'est pas possible et qu'il y a un battement de liaison constant au sein du réseau, le circuit de demande peut ne pas être un bon choix pour vous.
Raison 2 : type de réseau défini comme diffusion
Lorsque vous configurez un circuit de demande sur une liaison, le type de liaison doit être défini comme point à point ou point à multipoint. Tout autre type de liaison peut provoquer l'activation inutile de la liaison, car les HELLO OSPF ne sont pas supprimés si le type de réseau est autre que point à point ou point à multipoint. Voici un exemple de configuration 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 |
Lorsque le type de réseau est défini comme broadcast, les HELLO OSPF activent la liaison à chaque intervalle Hello. Le résultat de la commande show dialer montre que la dernière fois que la liaison a été établie était à cause d'un Hello 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) Interface bound to profile Di1 Current call connected 00:00:08 Connected to 57654 (R2)
Solution
Pour résoudre ce problème, modifiez le type de réseau en point à point ou point à multipoint. Ici, nous supprimons le type de réseau broadcast afin qu'il soit configuré par défaut 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 en point à point ou point à multipoint, les HELLO OSPF sont supprimés sur la liaison et la liaison du circuit de demande cesse de basculer.
Raison 3 : un ou plusieurs routeurs ne comprennent pas le circuit de demande
Lorsqu’un ou plusieurs routeurs du domaine OSPF ne comprennent pas le circuit de demande, une actualisation périodique de la LSA se produit. Consultez la section Quand une actualisation périodique de LSA est-elle envoyée sur un circuit de demande OSPF ? 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
Prenons l’exemple du schéma de réseau suivant :
La liaison 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. Le routeur 1 redistribue les routes RIP (Routing Information Protocol) dans 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 |
Comme le type d’encapsulation de la liaison est PPP, les deux routeurs installent une route hôte pour l’autre côté de la liaison, comme indiqué 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 protocole RIP sont des protocoles de routage par classe. Par conséquent, l’instruction network de la configuration concerne 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 comme étant issue du protocole RIP et est redistribuée dans OSPF en tant que route externe, comme indiqué 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
Lorsque la liaison est interrompue, /32 disparaît et OSPF comprend qu’il s’agit d’un changement de topologie. Le circuit de demande réactive la liaison pour propager la version MAXAGE du masque /32 à son voisin. Lorsque la liaison est établie, le masque /32 redevient valide et l’âge de la LSA est réinitialisé. Une fois que le minuteur d’arrêt de la liaison est activé, la liaison est de nouveau interrompue. Ce processus se répète et la liaison du circuit de demande continue de battre. Il existe trois façons de résoudre ce problème, présentées ci-dessous.
Solution 1 : utilisez la commande no peer neighbor-route
Sous l'interface BRI qui exécute le circuit de demande, configurez no peer neighbor-route. Cela empêche l'installation du masque /32. Vous pouvez utiliser la configuration ci-dessous sur le routeur 1 uniquement, mais nous vous recommandons de configurer cette commande des deux côtés pour des raisons de cohérence.
R1# configure terminal R1(config)# interface BRI1/1 R1(config-if)# no peer neighbor-route
Solution 2 : utilisez la commande route-map
Lors de la redistribution à partir de RIP dans OSPF, utilisez la commande route-map et deny /32 afin qu'il ne soit pas injecté dans la base de données OSPF. Cette commande de configuration est requise uniquement sur le routeur qui effectue la redistribution, qui dans notre exemple est le routeur 1.
Tout d'abord, nous devons créer une liste d'accès correspondant au masque /32. Ensuite, nous appliquons cette liste d'accès à la carte de route et utilisons la carte de route lors de l'application de la commande redistribution comme montré 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 : Utiliser un réseau principal différent
Utilisez un réseau principal différent pour le domaine RIP ou OSPF. L’idée est d’avoir un réseau principal différent sur la liaison du circuit de demande, de sorte que lorsque la liaison passe sous encapsulation PPP, elle installe la route hôte pour l’autre côté de la liaison. Si la route hôte se trouve dans un réseau principal différent de celui utilisé dans le protocole RIP, le protocole RIP ne possède pas cette route hôte installée par le protocole PPP, car il n’a pas d’instruction réseau pour le réseau principal. Le schéma de réseau ci-dessous présente un exemple.
Le domaine RIP se trouve désormais sous le réseau 141.108.0.0 tandis que le domaine OSPF (et la liaison de circuit de demande) se trouve sous le réseau 131.108.0.0.
Raison 5 : Le circuit de demande OSPF est configuré sur une interface asynchrone
Lorsque vous configurez un circuit de demande sur une interface asynchrone (asynchrone), lorsque la couche 2 est inactive, l’interface physique réelle est inactive. Cela déclenche une modification de la base de données OSPF et l'interface asynchrone est de nouveau activée pour échanger la base de données. La couche 2 est à nouveau désactivée, ce qui déclenche à nouveau la modification de la base de données. Ce processus continue donc de se répéter.
Le scénario suivant est utilisé pour reproduire le problème ci-dessus.
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 OSPF par défaut est point à point sur une interface asynchrone, mais le circuit de demande continue à activer la liaison.
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 pour laquelle le circuit de demande continue d'activer la liaison est que lorsque la couche 2 tombe en panne après l'expiration du délai d'inactivité, l'interface entière tombe en panne. Mais dans le cas de BRI ou PRI, quand l'un des canaux tombe en panne, l'interface reste toujours active (en mode mystification). Pour résoudre le problème, vous devez configurer une interface de numérotation car elle ne s'arrête jamais. Une interface de numérotation reste active (en mode 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 |
Comme l’interface de numérotation ne s’arrête jamais, elle ne crée pas le problème qui se pose lorsqu’une interface asynchrone s’arrête.
Raison 6 : Le circuit de demande OSPF est configuré sur un protocole PPP multiliaison
La fonction PPP multiliaison peut être utilisée à des fins d’équilibrage de charge dans le cas où il existe plusieurs liaisons WAN. Une chose importante à retenir en termes d'OSPF est la bande passante du protocole PPP multiliaison. Lorsque plusieurs liaisons sont combinées, la bande passante de l'interface multiliaison change.
Le scénario suivant est utilisé pour reproduire le problème ci-dessus.
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 |
Le résultat suivant montre que trois interfaces série sont regroupées dans le protocole PPP multiliaison.
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 de l’interface représente la bande passante agrégée de la liaison et cette bande passante sera utilisée dans le calcul du 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
Le résultat de show ip ospf interface montre le coût OSPF actuel, qui est de 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 s'arrête et nous pouvons voir que dans le journal :
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 à nouveau la bande passante, elle sera différente de ce que nous avons vu précédemment. Le numéro 3968 est maintenant affiché et le bundle ne comporte que deux interfaces au lieu de trois, car une interface est tombée en panne. Remarque : l'interface est toujours active :
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, la multiliaison PPP est toujours activée, mais le coût OSPF passe maintenant à 25, car une liaison est désactivée
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)
C'est ce qui déclenchera le calcul SPF, et OSPF activera le circuit de demande. Si la liaison continue de battre, alors nous pouvons voir le circuit de demande continuer à battre parce que le coût sera changé chaque fois qu'une liaison s'ajoute ou est supprimée du bundle PPP multiliaison.
Solution
La multiliaison PPP est prise en charge dans le protocole OSPF, mais tant que toute la liaison au sein du regroupement reste active, le circuit de demande reste stable. Dès qu’une liaison est interrompue, même si aucune adresse IP ne lui est associée, cela affecte le calcul du coût OSPF et, pour cette raison, OSPF exécute le SPF pour recalculer les meilleurs chemins. Pour résoudre ce problème, la seule solution consiste à configurer manuellement le coût OSPF à l'aide de 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 permet de s'assurer que chaque fois qu'une liaison est ajoutée ou supprimée dans le bundle PPP multiliaison, le coût OSPF n'est pas affecté. Cela stabilise le circuit de demande OSPF sur la multiliaison PPP.
Informations connexes
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
03-Oct-2001 |
Première publication |
Commentaires