Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Convenciones

Ejemplo de red

Reason 1: Cambio en la tipología de red

Solución

Reason 2: Tipo de red definido como Broadcast (Difusión)

Solución

Reason 3: Uno o más routers no detectan el circuito de demanda

Reason 4: La ruta host está redistribuida en la base de datos OSPF

Solución 1: Utilizar el comando no peer neighbor-route

Solución 2: Uso del comando route-map

Solución 3: Utilización de una red principal diferente

Reason 5: El circuito de demanda de OSPF está configurado en una interfaz asincrónica

Solución

Reason 6: El circuito de demanda OSPF está configurado sobre un PPP Multilink

Solución

Información Relacionada

Introducción

Cuando se configura un enlace Open Shortest Path First (OSPF) como circuito de demanda, se suprimen los saludos OSPF y las actualizaciones LSA periódicas no se inundan sobre el enlace. Estos paquetes sólo activan el link cuando se intercambian por primera vez, o cuando ocurre un cambio en la información que contienen. Esto permite que la capa de link de datos subyacente se cierre cuando la topología de red sea estable. Un circuito de demanda que sube y baja indica un problema que debe investigarse. Este documento demuestra algunas causas posibles y ofrece soluciones.

Para obtener más información sobre el circuito bajo demanda, consulte la Función Circuito de Demanda OSPF.

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.

Ejemplo de red

El problema mencionado anteriormente se describe con el siguiente diagrama y configuración de red.

Router 1

Router 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

Nota: Sólo necesita configurar el circuito de demanda en un extremo del link. Sin embargo, si configura este comando en ambos extremos, no causará ningún daño.

En el diagrama anterior, los Routers 1 y 2 ejecutan el circuito de demanda OSPF a través del link ISDN. El link entre los Routers 1 y 2 sigue apareciendo, lo que frustra el propósito del circuito de demanda OSPF. La salida del comando show dialer muestra que el link se activó debido al paquete 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)

El link se puede activar por varias razones. A continuación, analizamos varios casos comunes y ofrecemos soluciones.

Reason 1: Cambio en la tipología de red

Siempre que haya un cambio en una topología de red OSPF, se debe notificar a los routers OSPF. En esta situación, se debe activar el circuito de demanda OSPF para que los vecinos puedan intercambiar la nueva información. Una vez que se intercambia la nueva base de datos, el link puede caer de nuevo y la adyacencia permanece en el estado FULL.

Solución

Para determinar si el link se activa debido a un cambio en la topología de red, utilice el comando debug ip ospf monitor. Muestra qué LSA está cambiando, como se ve a continuación:

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

El resultado anterior muestra que hubo un cambio en el LSA del router con el ID del router de 192.168.246.41, lo que hace que la base de datos se vuelva a sincronizar. Si la red es estable, este resultado de depuración no muestra nada.

Para reducir el efecto de las inestabilidad de link en el circuito de demanda, configure el área que contiene el circuito de demanda como stub total. Si esto no se puede hacer y hay una inestabilidad constante de link dentro de la red, es posible que el circuito de demanda no sea una buena opción para usted.

Reason 2: Tipo de red definido como Broadcast (Difusión)

Cuando configura el circuito de demanda en un link, el tipo de link debe definirse como punto a punto o punto a multipunto. Cualquier otro tipo de link puede hacer que el link aparezca innecesariamente porque los saludos OSPF no se suprimen si el tipo de red es algo que no sea punto a punto o punto a multipunto. A continuación se muestra una configuración de ejemplo para ilustrar este problema en los Routers 1 y 2.

Router 1

Router 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

Con el tipo de red definido como broadcast, los saludos OSPF activan el link en cada intervalo Hello. La salida show dialer muestra que la última vez que se activó el link fue debido a 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)

Solución

Para solucionar este problema, cambie el tipo de red a punto o punto a multipunto. Aquí eliminamos el tipo de broadcast de red de modo que de forma predeterminada se configure como punto a punto.

Router 1

Router 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

Al cambiar el tipo de red a punto a punto o punto a multipunto, los saludos OSPF se eliminan en el link y el link del circuito de demanda deja de parpadear.

Reason 3: Uno o más routers no detectan el circuito de demanda

Cuando uno o más routers en el dominio OSPF no entienden el circuito de demanda, ocurre una actualización periódica de LSA. Consulte ¿Cuándo se Envía una Actualización LSA Periódica a a través de un Circuito de Demanda OSPF? de este documento para obtener información sobre cómo resolver este problema.

Reason 4: La ruta host está redistribuida en la base de datos OSPF

Veamos el siguiente diagrama de red como ejemplo:

El link entre los Routers 1 y 2 es 131.108.1.0/24, y el circuito de demanda se configura entre los Routers 1 y 2. El router 1 está redistribuyendo las rutas del protocolo de información de routing (RIP) en OSPF.

Router 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

Dado que el tipo de encapsulación de link es PPP, ambos routers instalan una ruta de host para el otro lado del link como se muestra a continuación.

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

El protocolo de routing de gateway interior (IGRP) y RIP son protocolos de routing con clase y, por lo tanto, la instrucción de red de la configuración es para una red con clase de 131.108.0.0. Debido a esto, la ruta del host 131.108.1.2/32 se considera originada por RIP y se redistribuye en OSPF como una ruta externa como se muestra a continuación.

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

Cuando el link cae, el /32 desaparece y OSPF lo entiende como un cambio en la topología. El circuito de demanda vuelve a activar el link para propagar la versión MAXAGE de la máscara /32 a su vecino. Cuando se activa el link, la máscara /32 vuelve a ser válida para que se restablezca la edad de LSA. Luego, después de que el temporizador muerto del link entre en marcha, el link vuelve a caer. Este proceso se repite y el link del circuito de demanda sigue inestable. A continuación se muestran tres maneras de resolver este problema.

Solución 1: Utilizar el comando no peer neighbor-route

Bajo la interfaz BRI que está ejecutando el circuito de demanda, configure no peer neighbor-route. Esto evita que se instale la máscara /32. Puede utilizar la configuración que se muestra a continuación sólo en el Router 1, pero recomendamos configurar este comando en ambos lados para mantener la coherencia.

R1# configure terminal

R1(config)# interface BRI1/1

R1(config-if)# no peer neighbor-route

Solución 2: Uso del comando route-map

Cuando se redistribuye de RIP a OSPF, utilice el comando route-map y deny /32 para que no se inyecte en la base de datos OSPF. Este comando de configuración sólo se requiere en el router que está realizando la redistribución, que en nuestro ejemplo es el Router 1.

Primero, tenemos que crear una lista de acceso para que coincida con la máscara /32. Luego aplicamos esta lista de acceso al route map y usamos el route map cuando aplicamos el comando redistribute como se muestra a continuación.

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

Solución 3: Utilización de una red principal diferente

Utilice una red principal diferente para el dominio RIP o OSPF. La idea es tener una red principal diferente en el link del circuito de demanda de modo que cuando el link aparece bajo encapsulación PPP instale la ruta host para el otro lado del link. Si la ruta del host se encuentra en una red principal diferente a la que se utiliza en RIP, RIP no posee esta ruta de host instalada por PPP porque no tiene una instrucción de red para la red principal. El siguiente diagrama de red muestra un ejemplo.

El dominio RIP está ahora bajo la red 141.108.0.0 mientras que el dominio OSPF (y el link de circuito de demanda) está bajo la red 131.108.0.0.

Reason 5: El circuito de demanda de OSPF está configurado en una interfaz asincrónica

Cuando configura un circuito de demanda sobre una interfaz asíncrona (asíncrona), cuando la Capa 2 se desactiva, la interfaz física real se desactiva. Esto provoca un cambio en la base de datos OSPF y la interfaz asíncrona vuelve a activarse para intercambiar la base de datos. La Capa 2 se desactiva de nuevo y esto activará el cambio en la base de datos de nuevo, por lo que este proceso continúa repitiéndose.

El siguiente escenario se utiliza para reproducir el problema anterior.

La siguiente configuración se utiliza para el escenario anterior.

Router 1

Router 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

El tipo de red predeterminado OSPF es punto a punto en una interfaz asíncrona, pero el circuito de demanda sigue activando el link.

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)

Solución

La razón por la que el circuito de demanda continúa activando el link es porque cuando la Capa 2 se desactiva después de que caduca el tiempo de espera inactivo, toda la interfaz se desactiva. Pero en el caso de BRI o PRI, cuando uno de los canales deja de funcionar, la interfaz sigue activa (en modo de suplantación). Para resolver el problema, debe configurar una interfaz de marcador porque nunca se desactiva. Una interfaz de marcador permanece activa (en modo de simulación).

Router 1

Router 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

Dado que la interfaz del marcador nunca se desactiva, no creará el problema que se crea cuando una interfaz asíncrona se desactiva.

Reason 6: El circuito de demanda OSPF está configurado sobre un PPP Multilink

La función PPP de links múltiples se puede utilizar con fines de balanceo de carga en casos en que haya varios links WAN. Algo importante que se debe recordar en términos de OSPF es el ancho de banda del PPP de links múltiples. Cuando se combinan varios links, el ancho de banda de la interfaz multilink cambiará.

El siguiente escenario se utiliza para reproducir el problema anterior.

La siguiente configuración se utiliza para el escenario anterior.

Router 1

Router 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

El siguiente resultado muestra que hay tres interfaces seriales agrupadas en el PPP de links múltiples.

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

El ancho de banda de la interfaz representará el ancho de banda agregado del link, y este ancho de banda se utilizará en el cálculo del costo 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

El resultado de show ip ospf interface muestra el costo OSPF actual, que es 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)

Ahora se desconecta un link y podemos verlo en el registro:

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 volvemos a comprobar el ancho de banda, será diferente de lo que vimos anteriormente. Ahora está mostrando 3968 y el paquete tiene sólo dos interfaces en lugar de tres porque una interfaz se cayó. Nota a continuación, la interfaz aún está activa:

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)

Además, el multilink PPP sigue apareciendo, pero el costo OSPF ahora se cambia a 25 ya que un link está inactivo

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)

Esto activará el cálculo SPF y OSPF activará el circuito de demanda. Si el link sigue inestable, es posible que el circuito de demanda siga inestable porque el costo se cambiará cada vez que un link se suma o se borra del paquete PPP de links múltiples.

Solución

El multilink PPP se soporta en OSPF, pero mientras todo el link dentro del agrupamiento permanezca activo, el circuito de demanda será estable. Tan pronto como un link se interrumpa, aunque no haya ninguna dirección IP asociada con él, afectará el cálculo del costo OSPF, y debido a eso, OSPF ejecutará el SPF para recalcular las mejores trayectorias. Para resolver este problema, la única solución es configurar el costo OSPF manualmente con el siguiente comando.

Router 1

Router 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

Este comando se asegurará de que cada vez que haya un link agregado o eliminado en el agrupamiento PPP de links múltiples, el costo OSPF no se verá afectado. Esto estabilizará el circuito de demanda OSPF sobre el multilink PPP.

Información Relacionada

- Página de Soporte OSPF

- Soporte Técnico - Cisco Systems