Table des matières

Introduction

Conditions préalables

Exigences

Composants utilisés

Conventions

Exemple de réseau

Raison 1 : modification de la topologie du réseau

Solution

Raison 2 : type de réseau défini comme diffusion

Solution

Raison 3 : un ou plusieurs routeurs ne comprennent pas le circuit de demande

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

Solution 1 : utilisez la commande no peer neighbor-route

Solution 2 : utilisez la commande route-map

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

Raison 5 : Le circuit de demande OSPF est configuré sur une interface asynchrone

Solution

Raison 6 : Le circuit de demande OSPF est configuré sur un protocole PPP multiliaison

Solution

Informations connexes

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

- Page de support OSPF

- Support technique - Cisco Systems