IP : Open Shortest Path First (OSPF)

Por qué el circuito de demanda de OSPF continúa activando el link

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Cuando se configura un link del Open Shortest Path First (OSPF) mientras que se suprime el circuito de la demanda, hellos OSPF y las actualizaciones de LSA periódicas no se inundan sobre el link. Estos paquetes sacan a colación el link solamente cuando se intercambian por primera vez, o cuando un cambio ocurre en la información ellos contiene. Esto permite que la capa del link de datos subyacente sea cerrada cuando la topología de red es estable. Un circuito de la demanda que va hacia arriba y hacia abajo indica un problema que necesite ser investigado. Este documento demuestra algunas posibles causas y ofrece las soluciones.

Para más circuito a pedido de la información, refiera a la característica del circuito de demanda OSPF.

prerrequisitos

Requisitos

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 diagram de red y la configuración.

/image/gif/paws/4808/dc1.gif

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: Usted necesita configurar el circuito de la demanda en un extremo del link solamente. Sin embargo, si usted configura este comando en los ambos extremos no causa ningún daño.

En el diagrama arriba, el Routers 1 y 2 está funcionando con el circuito de la demanda OSPF a través del link ISDN. El link entre el Routers 1 y 2 guarda el subir, que derrota el propósito del circuito de la demanda OSPF. La salida del comando show dialer muestra que el link subió debido al paquete de saludo 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 sacar a colación por varias razones. Debajo de los nosotros exploramos varios casos comunes y ofrecemos las soluciones.

Razón 1: Cambio en la tipología de red

Siempre que haya un cambio en una topología de red OSPF, los routeres para OSPF deben ser notificados. En esta situación el circuito de la demanda OSPF debe ser traído encima de modo que los vecinos puedan intercambiar la nueva información. Una vez que la nueva base de datos se intercambia el link puede ir abajo otra vez y sigue habiendo la adyacencia en el estado FULL.

Solución

Para determinar si el link se trae encima de debido a un cambio en topología de red, utilice el comando debug ip ospf monitor. Muestra qué LSA está cambiando, según lo visto abajo:

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

La salida antedicha muestra que había un cambio en el LSA de router con el Router ID de 192.168.246.41, que hace la base de datos ser resincronizado. Si la red es estable, después las demostraciones de esta salida de los debugs nada.

Para reducir la influencia de las aletas del link en el circuito de la demanda, configure el área que contiene el circuito de la demanda como totalmente stub. Si esto no es factible, y hay un flap constante del link dentro de la red, el circuito de la demanda no pudo ser una buena opción para usted.

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

Cuando usted configura el circuito de la demanda en un link, el tipo de link debe ser definido como el Punto a punto o punta a de múltiples puntos. Cualquier otro tipo de link puede hacer el link subir innecesariamente porque el hellos OSPF no se suprime si el tipo de red es cualquier cosa con excepción de Punto a punto o de punta a de múltiples puntos. Lo que sigue es una configuración de muestra para ilustrar este problema en el 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, el hellos OSPF saca a colación el link en cada intervalo de saludo. La salida del marcador de la demostración muestra que la última vez que el link fue traído encima de estaba 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, cambia el tipo de red al Punto a punto o a la punta a de múltiples puntos. Aquí quitamos el broadcast de tipo de red tan por abandono que se configura 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

Cambiando el tipo de red al Punto a punto o a la punta a de múltiples puntos, el hellos OSPF se suprime en el link, y el link del circuito de demanda para el agitar.

Razón 3: Uno o más routers no detectan el circuito de demanda

Cuando los routeres o más en el dominio OSPF no entienden el circuito de la demanda, una actualización de LSA periódica ocurre. ¿Vea cuando es una actualización de LSA periódica enviada sobre un circuito de la demanda OSPF? sección de este documento para aprender cómo resolver este problema.

Razón 4: La ruta host está redistribuida en la base de datos OSPF

Consideremos el siguiente diagram de red como un ejemplo:

/image/gif/paws/4808/dc2.gif

El link entre el Routers 1 y 2 es 131.108.1.0/24, y el circuito de la demanda se configura entre el router1 del Routers 1 y 2. está redistribuyendo las rutas del Routing Information Protocol (RIP) en el 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

Puesto que el tipo de encapsulación del link es PPP, ambo Routers instala una ruta del host para el otro lado del link como se muestra abajo.

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 Interior Gateway Routing Protocol (IGRP) y el RIP son protocolos del classful routing, y por lo tanto la declaración de la red en la configuración está para una red classful de 131.108.0.0. Debido a esto la ruta del host de 131.108.1.2/32 se considera ser originada por el RIP y consigue redistribuida en el OSPF como ruta externo como se muestra abajo.

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 desaparece el link va abajo de /32 y el OSPF entiende esto como cambio en la topología. El circuito de la demanda saca a colación el link otra vez propagar la versión de MAXAGE de la máscara de /32 a su vecino. Cuando sube el link, la máscara de /32 llega a ser válida otra vez así que la edad LSA consigue la restauración. Entonces después de que el temporizador de emergencia del link golpee con el pie adentro, el link va abajo otra vez. Este proceso se relanza y el link del circuito de demanda guarda el agitar. Hay tres maneras de solucionar este problema mostrado abajo.

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

Bajo interfaz BRI que está funcionando con el circuito de la demanda, no configure ningún peer neighbor-route. Esto evita que la máscara de /32 sea instalada. Usted puede utilizar la configuración mostrada abajo en el router1 solamente, pero recomendamos el configurar de este comando en los ambos lados para el estado coherente.

R1# configure terminal
R1(config)# interface BRI1/1
R1(config-if)# no peer neighbor-route

Solución 2: Uso del comando route-map

Al redistribuir del RIP en el OSPF, utilice el comando route-map y niegue /32 así que no consigue inyectado en la base de datos OSPF. Requieren a este comando configuration solamente en el router que está haciendo la redistribución, que en nuestro ejemplo es router1.

Primero tenemos que crear una lista de acceso para hacer juego la máscara de /32. Después aplicamos esta lista de acceso al Route Map y utilizamos el Route Map al aplicar el comando redistribution como se muestra abajo.

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 diversa red principal para el RIP o el dominio OSPF. La idea es tener una diversa red principal en el link del circuito de demanda tan cuando el link sube bajo encapsulación PPP que instala la ruta del host para el otro lado del link. Si la ruta del host está en una diversa red principal que la que está que es utilizada en el RIP, el RIP no posee esta ruta PPP-instalada del host porque no tiene una declaración de la red para la red principal. El diagrama de la red abajo muestra un ejemplo.

/image/gif/paws/4808/dc3.gif

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

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

Cuando usted configura un circuito de la demanda sobre una interfaz asíncrona (del async), después cuando va la capa 2 abajo, la interfaz física real va abajo. Esto acciona un cambio en la base de datos OSPF y la interfaz asincrónica viene salvaguardia otra vez para intercambiar la base de datos. La capa 2 va abajo otra vez, y ésta accionará el cambio en la base de datos otra vez, así que este proceso guarda en relanzarse.

El escenario siguiente se utiliza para reproducir el problema antedicho.

/image/gif/paws/4808/dc4.gif

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

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 del OSPF predeterminado es de punto a punto en una interfaz asincrónica, pero todavía el circuito de la demanda guarda el sacar a colación del 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 que el circuito de la demanda guarda el sacar a colación del link es porque cuando va la capa 2 abajo después de que expire el tiempo de inactividad, va la interfaz del conjunto abajo. Pero en el caso del BRI o del PRI, cuando va uno de los canales abajo, todavía sigue habiendo la interfaz para arriba (en el modo de simulación). Para solucionar el problema usted debe configurar una interfaz del dialer porque nunca va abajo. Sigue habiendo una interfaz del dialer para arriba (en el 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

Puesto que nunca va la interfaz del dialer abajo, no creará el problema se crea que cuando va una interfaz asincrónica abajo.

Razón 6: El circuito de demanda OSPF está configurado sobre un Multilink PPP

La característica del Multilink PPP se puede utilizar para los propósitos del Equilibrio de carga en los casos allí es links de WAN múltiples. Un asunto importante a recordar en términos de OSPF es el ancho de banda del Multilink PPP. Cuando se combinan los links múltiples, el ancho de banda de la interfaz de links múltiples cambiará.

El escenario siguiente se utiliza para reproducir el problema antedicho.

/image/gif/paws/4808/dc5.gif

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

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 producto siguiente muestra que hay tres interfaces seriales liadas juntas en el Multilink PPP.

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 será utilizado en cálculo de costos 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

La salida de la interfaz OSPF del IP de la demostración muestra el costo de 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 va abajo 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 marcamos el ancho de banda otra vez será diferente que lo que vimos previamente. Ahora está mostrando que 3968 y el conjunto tiene solamente dos interfaces en vez de tres porque fue una interfaz abajo. Observe abajo la interfaz todavía está para arriba:

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)

También, el multilink PPP todavía está apareciendo, pero el costo de OSPF ahora se cambia a 25 puesto que un link está abajo

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)

Este qué accionará el cálculo SPF, y OSPF sacará a colación el circuito de la demanda. Si el link guarda el agitar entonces podemos ver que el circuito de la demanda guardar el agitar porque el coste será cambiado cada vez de un link agrega para arriba o que consigue borrado el agrupamiento de PPP de links múltiples.

Solución

El multilink PPP se soporta en el OSPF, pero mientras todo el link dentro del conjunto permanezca para arriba, el circuito de la demanda será estable. Tan pronto como vaya un link abajo, aunque no hay dirección IP asociada a ella, afectará a cálculo de costos de OSPF, y debido a ese, el OSPF ejecutará el SPF para recalcular los mejores trayectos. Para solucionar este problema, la única solución es configurar el costo de 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 aseegurará que cada vez que hay un link que se agrega o se borra en el agrupamiento de PPP de links múltiples, el costo de OSPF no será afectado. Esto voluntad estabiliza el circuito de la demanda OSPF sobre el multilink PPP.


Información Relacionada


Document ID: 4808