Por qué el circuito de demanda de OSPF continúa activando el link
Contenido
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.
Comentarios