Por qué el circuito de demanda de OSPF continúa activando el link
Contenido
Introducción
Cuando un link OSPF (Open Shortest Path First) se configura como circuito de demanda, los saludos OSPF se suprimen y las actualizaciones LSA periódicas no se inundan sobre el link. Estos paquetes activan el link sólo 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 es estable. Un circuito de demanda que sube y baja indica un problema que debe investigarse. Este documento demuestra algunas posibles causas y ofrece soluciones.
Para obtener más información sobre el circuito de demanda, consulte Función OSPF Demand Circuit.
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 de red y configuración.
| 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 debe configurar el circuito de demanda en un extremo del link. Sin embargo, si configura este comando en ambos extremos no causa 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 contradice el propósito del circuito de demanda OSPF. La salida del comando show dialer muestra que el link se activó debido al paquete Hello de multidifusión 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, exploramos varios casos comunes y ofrecemos soluciones.
Motivo 1: cambio en la topologí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, el circuito de demanda OSPF debe activarse para que los vecinos puedan intercambiar la nueva información. Una vez que se intercambia la nueva base de datos, el link puede caer nuevamente 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 la red, utilice el comando debug ip ospf monitor. Muestra qué LSA está cambiando, como se muestra 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, 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 es factible, y hay una inestabilidad de link constante dentro de la red, el circuito de demanda podría no ser una buena opción para usted.
Motivo 2: tipo de red definido como difusión
Al configurar 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 cualquier cosa que no sea punto a punto o punto a multipunto. A continuación se muestra un ejemplo de configuración 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. El resultado de show dialer muestra que la última vez que se activó el link fue debido a un saludo 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 a punto o punto a multipunto. Aquí eliminamos el tipo de red broadcast para 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 suprimen en el link y el link del circuito de demanda deja de inestabilizarse.
Motivo 3: Uno o más routers no entienden el circuito de demanda
Cuando uno o más routers en el dominio OSPF no entienden el circuito de demanda, se produce una actualización periódica de LSA. Vea la sección ¿Cuándo se envía una actualización periódica de LSA a través de un circuito de demanda OSPF? de este documento para aprender a resolver este problema.
Motivo 4: La ruta del host se redistribuye en la base de datos OSPF
Consideremos 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 de protocolo de información de enrutamiento (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 ruteo de gateway interior (IGRP) y RIP son protocolos de ruteo con clase y, por lo tanto, la sentencia de red en la configuración es para una red con clase de 131.108.0.0. Debido a esto, la ruta de 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 deja de funcionar, /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 aparece el link, la máscara /32 vuelve a ser válida para que se restablezca la página LSA. Luego, después de que el temporizador muerto del link se activa, el link se desactiva nuevamente. Este proceso se repite y el link del circuito de demanda sigue inestable. Hay tres maneras de resolver este problema que se muestra a continuación.
Solución 1: Utilice el comando no peer neighbor-route
En la interfaz BRI que ejecuta 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 se recomienda 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: Utilice el comando route-map
Al redistribuir desde RIP en OSPF, utilice el comando route-map y deniegue /32 para que no se inserte en la base de datos OSPF. Este comando de configuración sólo es necesario 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 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 redistribution 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: Utilice 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 para que cuando el link aparezca bajo encapsulación PPP instale la ruta del host para el otro lado del link. Si la ruta de host está en una red principal diferente de la que se está utilizando en RIP, RIP no es propietario de esta ruta de host instalada en PPP porque no tiene una instrucción de red para la red principal. El siguiente diagrama de red muestra un ejemplo.
El dominio RIP se encuentra ahora en la red 141.108.0.0, mientras que el dominio OSPF (y el enlace de circuito de demanda) se encuentra en la red 131.108.0.0.
Motivo 5: El circuito de demanda OSPF se configura en una interfaz asíncrona
Cuando configura un circuito de demanda sobre una interfaz asíncrona (asíncrona), cuando la Capa 2 deja de funcionar, la interfaz física real deja de funcionar. Esto activa 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 vuelve a caer y esto activará el cambio en la base de datos de nuevo, por lo que este proceso sigue 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 aun así 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 sigue activando el link es porque cuando la Capa 2 se desactiva después de que vence el tiempo de espera inactivo, toda la interfaz se desactiva. Pero en el caso de BRI o PRI, cuando uno de los canales se desactiva, la interfaz sigue activa (en modo de simulació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 deja de funcionar, no creará el problema que se crea cuando una interfaz asíncrona deja de funcionar.
Motivo 6: El circuito de demanda OSPF está configurado sobre un PPP de links múltiples
La función PPP de links múltiples se puede utilizar para fines de balanceo de carga en los casos en que haya links WAN múltiples. Una cosa importante a recordar en términos de OSPF es el ancho de banda del PPP multilink. Cuando se combinan varios links, el ancho de banda de la interfaz de links múltiples 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 multilink.
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 de 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 un link se desactiva y podemos ver eso 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 comprobamos el ancho de banda de nuevo, será diferente de lo que vimos anteriormente. Ahora está mostrando 3968 y el paquete tiene solamente dos interfaces en lugar de tres porque una interfaz se desactivó. 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 es lo que activará el cálculo de SPF, y OSPF activará el circuito de demanda. Si el link sigue inestable, es posible que veamos que el circuito de demanda sigue inestable porque el costo se cambiará cada vez que un link se suma o se elimina del conjunto PPP multilink.
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 deja de funcionar, aunque no haya ninguna dirección IP asociada con él, afectará el cálculo del costo de 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 se agregue o elimine un link en el conjunto 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
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
03-Oct-2001 |
Versión inicial |
Comentarios