IP : On-Demand Routing (ODR)

Diseño de las redes Stub a gran escala con el ODR

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


Contenido


Introducción

El Ruteo a pedido (ODR) es una mejora del Protocolo de detección de Cisco (CDP), un protocolo que se usa para detectar otros dispositivos de Cisco tanto en medios de transmisión como en los de no transmisión. Con la ayuda del CDP, es posible encontrar el tipo de dispositivo, la dirección IP, la versión del � del Cisco IOS que se ejecuta en el dispositivo de Cisco vecino, las capacidades del dispositivo vecino, y así sucesivamente. En la versión 11.2 de Cisco IOS Software, se agregó ODR al CDP para anunciar el prefijo IP conectado de un router stub a través del CDP. Esta característica requiere cinco bytes adicionales para cada red o subred, cuatro bytes para la dirección IP y un byte para anunciar la máscara de subred junto con la IP. ODR puede llevar información de Máscara de Subred de Longitud Variable (VLSM).

ODR fue diseñado para clientes de empresas minoristas que no desean utilizar el ancho de banda de la red para actualizaciones del protocolo de ruteo. En un entorno X.25, por ejemplo, es a menudo muy costoso funcionar con un Routing Protocol sobre ese link. El ruteo estático es una buena opción, pero hay demasiados costos operativos para el mantenimiento manual de las rutas estáticas. ODR no hace un uso intensivo de la CPU y se usa para propagar rutas IP en forma dinámica a través de la capa 2.

El ODR no es un Routing Protocol y no se debe tratar como tal al configurarlo. Las configuraciones tradicionales para protocolos de IP Routing diferentes no funcionarán en ODR ya que ODR usa CDP en el Layer 2. Para configurar el ODR, utilice el comando router odr sobre el router concentrador. El diseño, la implementación, y la interacción del ODR con otros IP Routing Protocol pueden ser difíciles.

El ODR no se ejecutará en los Cisco 700 Series Routers o en los links ATM con excepción de LAN Emulation (LANE).

Redes “Stub” vs. redes de tránsito

Cuando ninguna información está pasando a través de la red, es una red Stub. La topología hub y spoke es un buen ejemplo de una red stub. Las grandes empresas con diversos sitios conectados a un centro de datos utilizan este tipo de tipología.

Los routers de menor capacidad como los de las series Cisco 2500, 1600 y 1000 se utilizan del lado del radio. Si la información pasa por routers radiales para llegar a alguna otra red, ese router stub se convierte en un router de tránsito. Esta configuración ocurre cuando un spoke está conectado con otro router además del router de eje de conexión.

Un problema común es desconocer cuán extensa puede ser la actualización ODR que puede enviar un spoke. Comúnmente, los spokes están conectados solamente a un hub. Si los routers radiales están conectados a otros routers, dejan de ser fragmentos y se convierten en una red de tránsito. Los cuadros de menor capacidad tienen generalmente uno o dos interfaces LAN. Por ejemplo, Cisco 2500 puede admitir dos interfaces LAN. En situaciones normales, se envía un paquete de 10 bytes (en caso de que existan dos LAN en el lado del spoke) como parte del CDP. CDP está habilitado en forma predeterminada, por lo tanto, no existen problemas de tara adicional. Nunca habrá una situación donde hay una actualización grande ODR. El tamaño de las actualizaciones ODR no será un problema en un entorno radial verdadero.

Redes radiales y ODR

Una red radial es una red típica donde un hub (router de mayor capacidad) sirve a varios spokes (routers de menor capacidad). En los casos especiales, allí puede ser más de un concentrador, para los propósitos de la redundancia o soportar el spokes adicional vía un eje de conexión aparte. En esta situación, habilite ODR en ambos hubs. También es necesario contar con un protocolo de ruteo para intercambiar información de ruteo ODR entre los dos hubs.

Figura 1: Topología radial

odrhs.jpg

Radios con un solo punto de salida

En el cuadro 1 antedicho, el spokes está conectado con un concentrador de modo que él pueda confiar en el default gateway en vez de recibir toda la información de ruteo para el concentrador con un punto de salida. No es necesario pasar toda la información al spokes, puesto que un spoke no tendrá que tomar una decisión de ruteo inteligente. Un spoke enviará siempre el tráfico al concentrador, así que la necesidad del spokes solamente una ruta predeterminado que apunta en la dirección de un concentrador.

Debe haber una manera para enviar la información de subred del radio al eje de conexión. Antes de a la versión 11.2 del IOS de Cisco, la única forma de lograr esto era habilitando un protocolo de ruteo en el spoke. Usando el ODR, sin embargo, los Routing Protocol no necesitan ser habilitados en el lado radial. Con el ODR, solamente el Cisco IOS 11.2 y una Static Default ruta que apunta en la dirección de un concentrador se necesitan en el spoke.

Radios con múltiples puntos de salida

Un radio puede tener conexiones múltiples al hub a efectos de redundancia o copia de respaldo en caso de fallas en el link principal. Con frecuencia, se necesita un eje de conexión aparte para esta redundancia. En este caso, los spokes tienen puntos múltiples de salida. ODR también funciona bien en esta red.

El spokes debe ser de punto a punto, si no la ruta predeterminado de la estática flotante no funcionará. En una configuración multipunto, no hay forma de detectar una falla del next hop, al igual que en un medio de difusión.

Balance de carga o respaldo con un solo concentrador

Para lograr el balance de carga, defina dos rutas estáticas predeterminadas en spokes con la misma distancia y el spoke realizará el balance de carga entre esos dos trayectos. Si existen dos trayectos hacia el destino, el ODR mantendrá ambas rutas en la tabla de ruteo y realizará un equilibrio de carga en el hub.

Para las copias de seguridad, defina dos rutas estáticas predeterminadas con una distancia de una mejor que la otra. El radial usará el link primario y, cuando el link primario descienda, funcionará la ruta flotante. En el router de eje de conexión, use el comando distance para cada dirección de vecino CDP y haga que esta distancia sea mejor que la otra. Con esta configuración, se preferirán las rutas ODR aprendidas mediante un link a las demás. Esta configuración es útil en un entorno en donde hay links primarios rápidos y links de respaldo lentos (ancho de banda bajo) y también en aquellos en donde no se quiere el equilibrio de carga.

Nota: Hoy, no hay otro método en el lado radial para preferir un link sobre el otro en hub único una situación, excepto como se describe anteriormente. Si está utilizando IOS 12.0.5T o posterior, el concentrador envía automáticamente la ruta predeterminada a través de ambos links y la radio no puede distinguir entre los dos trayectos e instalará ambos en la tabla de ruteo. La única razón para preferir una ruta predeterminada a otra es para utilizar una ruta estática predeterminada, en el radial que tiene un trayecto con una distancia admin inferior por la cual usted prefiere optar. Esto reemplaza automáticamente las rutas predeterminado que están viniendo en el spokes vía el ODR. Actualmente, se está considerando la idea de proporcionarle un botón al spoke en los casos en que pueda preferir un link a otro.

Figura 2: Radios con varios puntos de salida y un sólo eje de conexión

/image/gif/paws/13710/odr3.jpg

Balance de carga o de respaldo con varios concentradores

Estas configuraciones también pueden utilizarse para el equilibrio de carga o de respaldo cuando existen hubs múltiples. Todo el Hubs debe ser enredado completamente para si uno de los links del spokes falla, poder todavía alcanzar el destino a través de un segundo concentrador. Vea el ODR contra. La otra sección de los Routing Protocol de este documento para una más explicación detallada. Semejantemente, en el caso de los hub múltiple, si el IOS está 12.0.5T o más adelante en utilizado, el Hubs envía las rutas predeterminado ODR al spokes y el spokes instala ambos en la tabla de ruteo. Una mejora futura permitirá que un radio prefiera un concentrador en lugar de otro. Actualmente, esto se puede hacer a través de una Static Default ruta definida en el uso del rayo el router y de la distancia administrativa en el comando de la Static ruta de preferir un concentrador sobre el otro. Esto no afecta las situaciones de equilibrio de carga.

Figura 3: Radios con varios puntos de salida y varios ejes de conexión

/image/gif/paws/13710/odr4.jpg

ODR contra. Otros protocolos de ruteo

La mayor ventaja de ODR frente al IP Routing es que el router hub aprenderá los prefijos IP sin activar los Routing Protocols en el Layer 3. Las actualizaciones ODR son parte del CDP en la Capa 2.

ODR versus EIGRP

En un verdadero entorno de hub y spoke, no es necesario pasar toda la información de ruteo a todos los spoke. Ancho de banda de la basura del spokes del link lento en las actualizaciones de ruteo y las relaciones de vecino que mantienen. Al activar el protocolo mejorado de ruteo de puerta de enlace interior (EIGRP) en los radios, se envían actualizaciones del ruteo a los radios. En redes grandes, estas actualizaciones se hacen enormes, desperdician ancho de banda de la CPU y es probable que requieran más memoria en los routers spoke.

Una estrategia más adecuada EIGRP es aplicarle filtros al hub. La información de ruteo está controlada de modo que los ejes de conexión sólo envían una ruta predeterminada dinámica a las radios. Estos filtros ayudan a reducir el tamaño de la tabla de ruteo del lado del spoke, pero si el hub pierde un vecino, le enviará consultas a todos los otros vecinos. Estas consultas son innecesarias debido a que el hub nunca obtendrá una respuesta de un vecino.

El mejor enfoque es eliminar las tareas generales de las consultas EIGRP y el mantenimiento de vecinos mediante ODR. El ajuste de los temporizadores ODR puede aumentar el tiempo de convergencia.

Hoy, tenemos una nueva función en el EIGRP que escale el EIGRP mucho mejor en una situación del hub and spoke. Refiera al ruteo de stub del IGRP mejorado para más información sobre la característica del stub del EIGRP.

ODR vs. OSPF

Open Shortest Path First (OSPF) (Abrir el trayecto más corto primero) ofrece varias opciones para entornos radiales y la opción stub no summary tiene el de menos sobrecarga.

Puede encontrar problemas al ejecutar OSPF en redes grandes radiales. Los ejemplos de esta sección usan Frame Relay ya que se trata de la topología de hub y spoke más frecuente.

Redes "stub" punto a punto OSPF

En este ejemplo, el OSPF se habilita en 100 spokes conectados por una configuración Point-to-Point. Primero, hay muchas direcciones IP desperdiciadas, aún si nos conectamos con una subred con una máscara de red /30. Segundo, si incluimos esos 100 radios en un área y un radio es inestable, se ejecutará el algoritmo del trayecto más corto primero (SPF) y es posible que provoque un funcionamiento intensivo de la CPU. Esta situación es especialmente verdadera para los routers radiales si el link es inestable. En lo que respecta a los routers radiales, una mayor cantidad de vecinos inestables puede causar problemas.

En OSPF, el área está fragmentada, pero no así la interfaz. Si hay 100 routers en una red de centro, se necesitará más memoria en los spokes para contener la gran base de datos. Este problema puede solucionarse al dividir un área Stub grande en áreas pequeñas. Sin embargo, un flap en una zonas fragmentadas todavía accionará el SPF para ejecutarse en el spokes, así que estos gastos indirectos no pueden ser curados haciendo las pequeñas zonas fragmentadas sin el resumen y ningunos externos.

Otra opción es incluir cada link en una sola área. Con esta opción, el router del hub tendrá que ejecutar un algoritmo SPF individual para cada área y crear un Aviso de estado de links resumido (LSA) para las rutas del área. Esta opción puede dañar el rendimiento del router hub.

El actualizar a una mejor plataforma no es una solución permanente; sin embargo, el ODR proporciona una solución. Las rutas aprendidas vía ODR pueden ser redistribuidas en OSPF para informarle esas rutas a otros routers hubs.

Redes Stub punto a multipunto OSPF

En las redes de punto a multipunto, el espacio para la dirección IP se almacena ingresando cada radio en la misma subred. Además, el tamaño del hub LSA del router que se genera se dividirá en dos ya que producirá sólo un link stub para todos los links punto a punto. Una red de punto a multipunto forzará la inclusión de una subred completa en un área. En el caso de una sacudida del link, el radio ejecutará SPF, lo que puede provocar el funcionamiento intensivo de la CPU.

Hola la tormenta

Los paquetes de saludo OSPF son pequeños, pero si hay demasiados vecinos, su tamaño puede aumentarse. Debido a que los hellos son de multidifusión, el router procesa los paquetes. Hub OSPF envía y recibe los paquetes de saludo comprendidos de 20 bytes de encabezado IP, de 24 encabezados de los bytes OSPF, de 20 bytes de los parámetros de saludo, y de 4 bytes para cada vecino visto. Un paquete OSPF de saludo desde un hub en una red de punto a multipunto con 100 vecinos puede alcanzar una extensión de 464 bytes y se distribuirán a todas las radios cada 30 segundos.

Tabla 1: Paquete OSPF de saludo para 100 vecinos

Encabezado IP de 20 bytes
24 encabezados OSPF de los bytes
Parámetros de saludo de 20 bytes
4 bytes cada ID de router (RID) de vecino
….
….
….
….
….

El exceso se resuelve en ODR dado que no se envía información extra del concentrador a los routers radiales. Los spokes envían el prefijo de IP de 5 bytes por subred al router concentrador. Teniendo en cuenta el tamaño del paquete de saludo, compare los 5 bytes del ODR (la información de envío de radio de la subred conectada cne) con los 68 bytes de OSPF (el paquete de saludo de menor tamaño que incluye un encabezado IP enviado desde una radio al eje de conexión) más 68 bytes (el paquete de saludo de menor tamaño enviado desde el eje de conexión a la radio) durante un intervalo de 30 segundos. Además, los saludos OSPF tienen lugar en la Capa 3 mientras que las actualizaciones ODR tienen lugar en la Capa 2. Con ODR se envía mucho menos información, de modo que se puede utilizar el link de ancho de banda para datos importantes.

ODR versus RIPv2

La versión 2 del Protocolo de información de ruteo (RIPv2) también es una buena opción para entornos de eje de conexión-radios. Para diseñar un RIPv2, envíe la ruta predeterminada desde el eje de conexión a los radios. Los spokes anuncian luego su interfaz conectada a través de RIP. RIPv2 se puede usar cuando hay direcciones secundarias en los spoke que deben anunciarse, si se usan varios routers del proveedor o si la situación no es verdaderamente una de hub y spoke.

RIPv2 sobre circuito de demanda

La versión 2 tiene pocas modificaciones, pero no cambia drásticamente el protocolo. Esta sección hace referencia a algunas mejoras del RIP para circuitos de pedido.

Las redes de Internet de hoy en día se mueven en dirección a las redes de marcación o de respaldos de sitios primarios para que provean conexiones a un gran número de sitios remotos. Tales tipos de conexión pueden pasar cualquiera muy poco o nada de tráfico de datos durante el funcionamiento normal.

El comportamiento periódico del RIP ocasiona problemas en estos circuitos. El RIP tiene problemas con el ancho de banda baja, las interfaces Point-to-Point. Las actualizaciones son enviadas cada 30 segundos con grandes tablas de ruteo que usan un ancho de banda alto. En esta situación, se recomienda utilizar el RIP activado.

RIP activado

El RIP activado está diseñado para los routers que intercambian toda la información de ruteo con su vecino. Si se producen cambios en el ruteo, sólo los cambios son propagados al vecino. En router de recepción aplica los cambios inmediatamente.

Las actualizaciones de RIP disparado se envían sólo cuando:

  • Se recibe una solicitud de actualización de ruteo.

  • Se recibe nueva información.

  • El destino ha cambiado de un circuito inactivo a un circuito activo.

  • Giran al router primero.

A continuación se muestra un ejemplo de configuración para el RIP accionado:

Spoke# configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z. 
Spoke(config)# int s0.1 
Spoke(config-if)# ip rip triggered 
Spoke(config)# int s0.2 
Spoke(config-if)# ip rip triggered 
       
interface serial 0 
encapsulation frame-relay 
       
interface serial 0.1 point            /* Primary PVC */ 
ip address 10.x.x.x 255.255.255.0 
ip rip triggered 
frame-relay interface-dlci XX 
       
interface serial 0.2 point       /* Secondary PVC */ 
ip address 10.y.y.y 255.255.255.0 
ip rip triggered 
frame-relay interface-dlci XX 

router rip 
  network 10.0.0.0 
       

Spoke# show ip protocol 
Routing Protocol is "rip" 
  Sending updates every 30 seconds, next due in 23 seconds 
  Invalid after 180 seconds, hold down 180, flushed after 240 
  Outgoing update filter list for all interfaces is not set 
  Incoming update filter list for all interfaces is not set 
  Redistributing: rip 
  Default version control: send version 1, receive any version 
    Interface        Send  Recv    Triggered RIP    Key-chain 
    Ethernet0           1        1 2 
    Serial0.1             1        1 2               Yes 
    Serial0.2             1        1 2               Yes 
  Routing for Networks: 
    10.0.0.0 
  Routing Information Sources: 
    Gateway         Distance      Last Update 
  Distance: (default is 120) 

El comando ip rip triggered debe ser configurado en la interfaz del router de eje de conexión que conecta con el spokes.

Al comparar el RIPv2 al ODR, el ODR es una mejor opción porque el RIPv2 trabaja en la capa 3 y el ODR ocurre en la capa 2. Cuando un concentrador envía las actualizaciones de RIPv2 a más de 1000 radios, tiene que replicar el paquete en la Capa 3 para cada radio. ODR no envía nada desde el eje de conexión excepto la actualización habitual del CDP que se realiza a cada minuto en la Capa 2, la cual no resulta intensiva en absoluto para la CPU. El envío de información de subred conectada en la Capa 2 desde el spoke exige mucho menos a la CPU que el envío de RIPv2 en la Capa 3.

Diseño de red en gran escala con ODR

El ODR trabaja mejor en una red a gran escala que cualquier otro Routing Protocol. La mayor ventaja de ODR es que los protocolos de ruteo no necesitan estar activados en los links seriales conectados. Actualmente, no existen protocolos de ruteo capaces de enviar información de ruteo sin habilitarlos en la interfaz conectada.

ODR con EIGRP funcionando en los Hubs

Al ejecutar EIGRP, realice una conexión de la interfaz pasiva a la red hub-y-spoke a fin de que no envíe saludos EIGRP innecesarios en el link. Si es posible, es mejor no colocar declaraciones de red para redes entre el concentrador y los radios porque, si el link deja de funcionar, EIGRP no enviará las consultas innecesarias a los vecinos centrales. Elija siempre una red falsa entre el concentrador y el spokes así que esos links no serán incluidos en el dominio EIGRP porque usted no pondrá las declaraciones de la red en las configuraciones.

Redundancia y producción de resumen

En una situación de hub único, no se necesitan configuraciones adicionales. Resuma las subredes específicas conectadas de las radios y fíltrelas en el núcleo. Las taras de las consultas, sin embargo, siempre estarán allí. Si las rutas específicas se pierden a partir de la una del spokes, envíe las interrogaciones a todos los vecinos en los routeres del núcleo.

En el caso de concentradores múltiples, es muy importante que ambos concentradores estén conectados y que se esté ejecutando el EIGRP entre ellos. Si es posible, este link debería ser una red principal única para que no interfiera con otros links que van hacia los spokes. Esta configuración es necesaria ya que no es posible habilitar EIGRP en una interfaz específica, de modo que aun si convertimos la interfaz en pasiva, ésta se publicará a través de EIGRP. Si se resume la interfaz, las consultas igualmente se enviarán aunque se pierda un spoke. Mientras el link entre el dos Hubs no esté en la misma red principal que el spokes, la configuración debe trabajar correctamente.

Figura 4: Redundancia y producción de resumen: El núcleo está recibiendo rutas resumidas

/image/gif/paws/13710/odr7.jpg

Una ventaja de EIGRP es que puede resumir a nivel de interfaz, por lo que la ruta resumida de subredes spoke será enviada al núcleo y enviará una ruta más específica al otro hub. Si va el link entre un hub and spoke abajo, es posible alcanzar el destino vía el segundo concentrador.

ODR con OSPF en concentradores

En este escenario, el OSPF no tiene que estar deshabilitado en el link que conecta las radios. En las circunstancias normales, si el OSPF se habilita en el link, y un link específico está agitando constantemente, él puede causar varios problemas, incluyendo la ejecución de SPF, regeneración del LSA de router, regeneración del LSA de resumen, y así sucesivamente. Al ejecutar el ODR, no incluya el link serial conectado en el dominio OSPF. La preocupación principal es recibir la información del segmento LAN del spokes. Puede obtener esta información a través de ODR. Si un link es inestable, no interferirá con el protocolo de ruteo en el router de eje de conexión.

Redundancia y producción de resumen

Todos los links específicos pueden resumirse antes de que se fuguen dentro del núcleo para evitar el cálculo de ruta si se desactiva una de las interfaces conectadas del spoke. No puede ser detectada si se resume la información del router del núcleo.

Figura 5: Redundancia y producción de resumen: El router del núcleo está recibiendo rutas resumidas

/image/gif/paws/13710/odr6.jpg

En este ejemplo, es muy importante que los hubs estén conectados entre sí para fines de redundancia. Esta conexión también resumirá las subredes conectadas con spokes antes de filtrarse dentro del núcleo OSPF.

NSSA con la mejora futura

Eventualmente existirá una función OSPF de Área no tan segmentada (NSSA) que le permitirá obtener no sólo datos del núcleo, sino también información más específica a lo largo del hub a través del link NSSA. La ventaja de ejecutar NSSA es que las rutas resumidas pueden enviarse en el núcleo. Luego, el núcleo puede enviar el tráfico a cualquier concentrador para alcanzar el destino del radio. Si falla el link entre un hub y un spoke, habrá un LSA de tipo 7 más específico en ambos hubs para llegar al destino por medio de otro hub.

Lo que sigue es un ejemplo de configuración usando el NSSA:

N2507: Hub 1 

router odr 
  timers basic 8 24 0 1 
! 
router ospf 1 
  redistribute odr subnets 
  network 1.0.0.0 0.255.255.255 area 1 
  area 1 nssa 
       

N2504: Hub 2 

router odr
  timers basic 8 24 0 1 
! 
router ospf 1 
  redistribute odr subnets 
  network 1.0.0.0 0.255.255.255 area 1 
  area 1 nssa 

N2507# show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
       U - per-user static route, o - ODR 
       
Gateway of last resort is not set 
       
C    1.0.0.0/8 is directly connected, Serial0 
C    2.0.0.0/8 is directly connected, Serial1 
     3.0.0.0/24 is subnetted, 1 subnets 
C       3.3.3.0 is directly connected, Ethernet0 
o    150.0.0.0/16 [160/1] via 3.3.3.2, 00:00:23, Ethernet0 
o    200.1.1.0/24 [160/1] via 3.3.3.2, 00:00:23, Ethernet0 
o    200.1.2.0/24 [160/1] via 3.3.3.2, 00:00:23, Ethernet0

N2504# show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
       U - per-user static route, o - ODR 
       
Gateway of last resort is not set 
       
C    1.0.0.0/8 is directly connected, Serial0 
C    2.0.0.0/8 is directly connected, Serial1 
     3.0.0.0/24 is subnetted, 1 subnets 
C       3.3.4.0 is directly connected, TokenRing0 
C    5.0.0.0/8 is directly connected, Loopback0 
C    6.0.0.0/8 is directly connected, Loopback1 
O N2 150.0.0.0/16 [110/20] via 1.0.0.1, 00:12:06, Serial0 
O N2 200.1.1.0/24 [110/20] via 1.0.0.1, 00:12:06, Serial0 
O N2 200.1.2.0/24 [110/20] via 1.0.0.1, 00:12:06, Serial0 

Resumen y mejora futura con NSSA

Asigne un bloque contiguo de subredes a las radios para que esas subredes se puedan resumir de manera correcta en el núcleo de OSPF, como se muestra en el siguiente ejemplo. Si las subredes no están resumidas y una subred conectada deja de funcionar, todo el núcleo lo detectará y volverá a calcular las rutas. Al enviar la ruta de resumen a un bloque contiguo, si la subred radial se torna inestable, el núcleo no la detectará.

N2504# configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z. 
N2504(config)# router ospf 1 
N2504(config-router)# summary-address 200.1.0.0 255.255.0.0 
       

N2504# show ip ospf database external 
       
       OSPF Router with ID (6.0.0.1) (Process ID 1) 
       
       
                Type-5 AS External Link States 
       
  LS age: 1111 
  Options: (No TOS-capability, DC) 
  LS Type: AS External Link 
  Link State ID: 200.1.0.0 (External Network Number ) 
  Advertising Router: 6.0.0.1 
  LS Seq Number: 80000001 
  Checksum: 0x2143 
  Length: 36 
  Network Mask: /16 
        Metric Type: 2 (Larger than any link state path) 
        TOS: 127 
        Metric: 16777215 
        Forward Address: 0.0.0.0 
        External Route Tag: 0

Problema de distancia

En este ejemplo, una información más específica se recibe de ambo Hubs. Puesto que la distancia OSPF es 110 y la distancia ODR es 160, la información interferirá con el ODR cuando se recibe de la otra subred casi igual del concentrador. Siempre será preferible el otro hub para llegar al destino spoke, lo cual causará un ruteo subóptimo. Para remediar la situación, disminuya la distancia ODR a menos de 110 con el comando distance, de modo que la ruta ODR sea preferida siempre sobre la OSPF ruta. Si la ruta ODR falla, la ruta externo OSPF será instalada en la tabla de ruteo de la base de datos.

N2504(config)# router odr 
N2504(config-router)# distance 100 
N2504(config-router)# end 

N2504# show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
       U - per-user static route, o - ODR 
       
Gateway of last resort is not set 
       
C    1.0.0.0/8 is directly connected, Serial0 
C    2.0.0.0/8 is directly connected, Serial1 
     3.0.0.0/24 is subnetted, 1 subnets 
C       3.3.4.0 is directly connected, TokenRing0 
C    5.0.0.0/8 is directly connected, Loopback0 
C    6.0.0.0/8 is directly connected, Loopback1 
o    150.0.0.0/16 [100/1] via 3.3.4.1, 00:00:39, TokenRing0 
o    200.1.1.0/24 [100/1] via 3.3.4.1, 00:00:39, TokenRing0 
o    200.1.2.0/24 [100/1] via 3.3.4.1, 00:00:39, TokenRing0 
O    200.1.0.0/16 is a summary, 00:04:38, Null0 

Las rutas N2 están aún en la base de datos y se volverán activas si se desactiva el link del hub principal hacia el spoke.

N2504# show ip ospf database nssa 
       
       OSPF Router with ID (6.0.0.1) (Process ID 1) 
       
       
                Type-7 AS External Link States (Area 1) 
       

  LS age: 7 
  Options: (No TOS-capability, Type 7/5 translation, DC) 
  LS Type: AS External Link 
  Link State ID: 150.0.0.0 (External Network Number ) 
  Advertising Router: 6.0.0.1 
  LS Seq Number: 80000002 
  Checksum: 0x965E 
  Length: 36 
  Network Mask: /16 
        Metric Type: 2 (Larger than any link state path) 
        TOS: 0 
        Metric: 20 
        Forward Address: 1.0.0.2 
        External Route Tag: 0 

Con la mejora a NSSA, el LSA más específico de Tipo 7 estará en la base de datos NSSA. El resultado de la base de datos NSSA aparecerá como se muestra a continuación en vez de una ruta resumida:

LS age: 868 
Options: (No TOS-capability, Type 7/5 translation, DC) 
LS Type: AS External Link 
Link State ID: 200.1.1.0 (External Network Number) 
Advertising Router: 3.3.3.1 
LS Seq Number: 80000001 
Checksum: 0xDFE0 
Length: 36 
Network Mask: /24 
        Metric Type: 2 (Larger than any link state path) 
        TOS: 0 
        Metric: 20 
        Forward Address: 1.0.0.1 
        External Route Tag: 0 
       
LS age: 9 
Options: (No TOS-capability, Type 7/5 translation, DC) 
LS Type: AS External Link 
Link State ID: 200.1.2.0 (External Network Number) 
Advertising Router: 3.3.3.1 
LS Seq Number: 80000002 
Checksum: 0xFDC3 
Length: 36 
Network Mask: /24 
        Metric Type: 2 (Larger than any link state path) 
        TOS: 0 
        Metric: 20 
        Forward Address: 1.0.0.2 
        External Route Tag: 0 

Circuito de la demanda

El circuito de la demanda es una característica del Cisco IOS 11.2 que se puede también utilizar en las redes radiales. Normalmente, esta característica es útil en escenarios de respaldo de marcado y en entornos de circuitos virtuales conmutados (SVC) X.25 o Frame Relay. A continuación, se puede apreciar un ejemplo de configuración de un circuito de demanda:

router ospf 1 
network 1.1.1.0 0.0.0.255 area 1 
area 1 stub no-summary 

interface Serial0                   /* Link to the hub router  */ 
  ip address 1.1.1.1 255.255.255.0 
  ip ospf demand-circuit 
  clockrate 56000 

Spoke#show ip o int s0 
Serial0 is up, line protocol is up 
  Internet Address 1.1.1.1/24, Area 1 
  Process ID 1, Router ID 141.108.4.2, Network Type POINT_TO_POINT, Cost: 64 
  Configured as demand circuit. 
  Run as demand circuit. 
  DoNotAge LSA not allowed (Number of DCbitless LSA is 1). 
  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:06 
  Neighbor Count is 1, Adjacent neighbor count is 1 
    Adjacent with neighbor 130.2.4.2 
  Suppress hello for 0 neighbor(s) 

La utilización de la función de circuito de demanda en una red de hub y spoke activará el circuito y formará una nueva adyacencia si se produce cualquier cambio en la topología. Por ejemplo, si hay una subred en un radio que es inestable, el circuito de demanda activará la adyacencia e inundará esta información. En un entorno de zona congestionada, esta información saturará toda la zona congestionada. Para solucionar este problema, ODR no transmite esta información a las otras radios. Refiérase al comando "Abrir la ruta más corta en primer lugar" (OSPF) de la función de circuito de pedido para más información.

ODR con redes de punto a punto

El estado actual del IOS 12.0 de Cisco en el bloque descriptor de la interfaz (IDB) se limita según se describe a continuación:

Router Límite
1000 300
2600 300
3600 800
4x00 300
5200 300
5300 700
5800 3000
7200 3000
RSP 1000

Antes de IOS 12.0, el número máximo de Spoke que un concentrador podría soportar era 300 debido a los límites del IDB. Si una red requirió más de 300 spokes, después la configuración Point-to-Point no era una buena opción. Además, se generó un paquete CDP distinto para cada link. La complejidad del tiempo para enviar las actualizaciones de CDP en los links punto a punto es n2. La tabla anterior nos da los límites de IDB para las distintas plataformas. La cantidad máxima de spokes que cada plataforma admite varía, pero la tara de creación de un paquete CDP separado para cada link es aún un problema. Por lo tanto, en una situación grande del hub and spoke, configurar una interfaz punto a multipunto es una mejor solución que una interfaz Point-to-Point.

ODR con redes de punto a multipunto

En redes punto a multipunto en donde un concentrador es compatible con varios spokes, hay tres cuestiones muy importantes:

  • El hub puede soportar fácilmente más de 300 spokes. Por ejemplo, una red 10.10.0.0/22 sería capaz de admitir spokes 1024-2 con una interfaz de multipunto.

  • En un entorno multipunto, un paquete CDP se genera para todos los vecinos y se replica en la capa 2. La complejidad del tiempo de la actualización de CDP se reduce a n.

  • En una configuración de punto a multipunto, usted puede asignar solamente una subred a todo el spokes.

ODR y proveedores múltiples

Un concepto erróneo común es que el ODR no trabajará si utilizan a los proveedores múltiples. ODR funcionará siempre y cuando la red sea una verdadera red radial. Por ejemplo, si hay 100 radios y dos de las radios son rutas de un proveedor diferente, es posible habilitar un protocolo de ruteo en esos links que conectan a los diferentes routers y aún ejecutar ODR en las 98 radios Cisco restantes.

Figura 6: ODR con varios proveedores

odr10.jpg

El router de eje de conexión conectado con los 98 routeres Cisco recibirá las actualizaciones de la subred con el ODR y recibirá las actualizaciones del Routing Protocol del dos diverso Routers restante. Los links que conectan los distintos routers deben estar en subredes punto-a-punto o punto-a-multipunto.

Cuestiones de futuro crecimiento

Si una organización está ejecutando el ODR en 100 spokes, pueden querer eventual cambiar su topología de una red radial. Por ejemplo, puede decidir actualizar un spoke a una plataforma más grande y, de esta forma, convertir a ese spoke en un hub para otros 20 nuevos spokes.

Figura 7: Crecimiento futuro

/image/gif/paws/13710/odr9.jpg

Es posible ejecutar un protocolo de ruteo en el hub nuevo y aún mantener el diseño del ODR intacto. Si el nuevo hub admite 20 o más nuevos spokes, ODR puede ejecutarse en el nuevo hub. El nuevo hub puede aprender acerca de esas nuevas subredes spoke mediante ODR y redistribuir esta información al hub original mediante otro protocolo de ruteo.

Esta situación es similar a lo que sucede cuando ODR se inicia con dos concentradores. No hay tara de protocolos cambiantes. Básicamente, ODR puede ejecutarse siempre que el router sea un stub.

Rendimiento

Pueden ajustarse diversas configuraciones para tener una convergencia más rápida y mejor rendimiento cuando se ejecuta ODR.

Ajuste de los temporizadores para lograr una convergencia más rápida

En un entorno ODR de gran tamaño, ajuste los temporizadores ODR para una convergencia más rápida y aumente los temporizadores de la actualización de CDP desde el hub al spoke para minimizar el rendimiento de la CPU del hub.

Router del eje de conexión

El temporizador de actualización CDP debe configurarse en forma predeterminada en 60 segundos para disminuir la cantidad de tráfico desde el hub hacia los spokes. El tiempo de espero debería aumentar al máximo (255 segundos). Dado que el router hub debe mantener demasiadas tablas de adyacencia de CDP, y en caso de que se desactiven algunos vecinos, no borre las entradas CDP de la memoria durante 255 segundos (el tiempo de espera máximo permitido). Esta configuración le otorgará flexibilidad al router hub porque si el vecino regresa dentro de cuatro minutos, no será necesario recrear la adyacencia CDP. La entrada de tabla antigua puede utilizarse y el temporizador de retención puede actualizarse.

A continuación, se encuentra un ejemplo de una plantilla de configuración IP para un router central:

cdp holdtime 255 
       
      router odr 
        timers basic 8 24 0 1  /* odr timer's are update, invalid, hold down, flush 
       
        router eigrp 1 
        network 10.0.0.0 
        redistribute odr 
        default-metric 1 1 1 1 1

De cada sitio remoto surgen tres circuitos virtuales permanentes (PVC) (almacén, región y depósito). Dos de los PVC van a dos routers centrales separados. El tercer PVC va a un router de Punto de pago. Se solicita que el PVC a la ruta PayPoint sea utilizado para el tráfico destinado a la red PayPoint. Los otros dos PVC cumplen funciones primarias y de respaldo para todo el resto del tráfico. De acuerdo con estos requisitos, vea la plantilla de configuración abajo para cada router remoto.

Es muy importante ajustar los temporizadores de ODR tales como inválido, retención y descarga para lograr una convergencia más rápida. A pesar de que la CPU no envía un prefijo IP una vez que se configuró el odr del router, el temporizador de actualización del ODR debería coincidir con el del CDP vecino, ya que el temporizador de convergencia sólo puede configurarse si hay un temporizador de actualización. Este temporizador es diferente del temporizador CDP y sólo puede ser utilizado para una convergencia más rápida.

Router spoke

Dado que los radios envían actualizaciones ODR en paquetes CDP, el temporizador para las actualizaciones CDP debería mantenerse en un valor muy bajo para una convergencia más rápida. En un verdadero entorno radial, no existen restricciones sobre el tiempo de retención para el vecino CDP, dado que hay sólo algunas entradas para que el radio almacene en su tabla CDP. El tiempo de retención máximo de 255 segundos se recomienda de modo que si el concentrador PVC va abajo y se vuelve en el plazo de cuatro minutos, no hay nueva adyacencia CDP necesaria porque la vieja entrada de tabla puede ser utilizada.

Lo que sigue es un ejemplo de una plantilla de la configuración IP para un sitio remoto:

cdp timer 8 
cdp holdtime 255 
       
interface serial 0 
encapsulation frame-relay 
cdp enable 
            
interface serial 0.1 point                      /* Primary PVC */ 
ip address 10.x.x.x 255.255.255.0 
frame-relay interface-dlci XX 
      
interface serial 0.2 point                      /* Secondary PVC */ 
ip address 10.y.y.y 255.255.255.0 
frame-relay interface-dlci XX 
      
       
interface bri 0 
interface BRI0 
description Backup ISDN for frame-relay 
ip address 10.c.d.e 255.255.255.0 
encapsulation PPP 
dialer idle-timeout 240 
dialer wait-for-carrier-time 60 
dialer map IP 10.x.x.x name ROUTER2 broadcast xxxxxxxxx 
ppp authentication chap 
dialer-group 1 
isdn spid1 xxxxxxx 
isdn spid2 xxxxxxx 
      
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 
dialer-list 1 LIST 101 
       
       
/* following are the static routes that need to be configured on the remote routers 
       
ip route 0.0.0.0 0.0.0.0 10.x.x.x 
ip route 0.0.0.0 0.0.0.0 10.y.y.y 
ip route 0.0.0.0 0.0.0.0 bri 0 100 
ip classless 

Las rutas predeterminadas estáticas no son necesarias si usted está usando el IOS 12.0.5T o posterior ya que el router del hub envía la ruta predeterminada automáticamente hacia todos los spokes.

Filtrado y resumen de rutas ODR

Las rutas ODR pueden ser filtradas antes de que se fuguen hacia el núcleo. Utilice el comando distribute-list in. Todas las subredes conectadas de los spokes deben resumirse cuando se filtran hacia el núcleo. Si no es posible realizar un resumen, entonces las rutas innecesarias se pueden filtrar en el router hub. En las redes del hub múltiple, el spokes puede hacer publicidad de la interfaz conectada que es el link a otro concentrador.

En esta situación, el comando distribute-list debe ser aplicado para que el concentrador no coloque esas rutas en la tabla de ruteo. Cuando se vuelve a distribuir ODR en el hub, esa información no se filtra en el núcleo.

Ajuste del temporizador Telco

Es importante ajustar el temporizador de la compañía telefónica para aumentar el tiempo de convergencia para los radios. Si la PVC del lado del eje de conexión baja, las radios deberían poder detectarlo rápidamente para cambiar al segundo eje de conexión.

Rendimiento del CPU

El proceso ODR no toma la porción de utilización de la CPU. Se han realizado pruebas de ODR en alrededor de 1000 vecinos con una utilización de la CPU del tres o cuatro por ciento. La configuración agresiva del temporizador de ODR en el concentrador ayuda para una convergencia más rápida. Si se usan los parámetros predeterminados, la utilización de la CPU se mantiene entre cero y uno por ciento.

Aún con los temporizadores CDP y ODR agresivos, el siguiente resultado muestra que no había una gran utilización de la CPU. Esta prueba fue realizada con un procesador MHz 150 en un Cisco 7206.

Hub# show proc cpu 
CPU utilization for five seconds: 4%/0%; one minute: 3%; five minutes: 3% 
PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
   . 
   . 
  18    11588036  15783316   734   0.73%  1.74%  1.95%   0 CDP Protocol 
   . 
   . 
  48    3864      5736        673  0.00%  0.00%  0.00%   0 ODR Router 
     

Hub# show proc cpu 
CPU utilization for five seconds: 3%/0%; one minute: 3%; five minutes: 3% 
PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
    . 
    . 
   18    11588484  15783850    734   2.21%  1.83%  1.96%   0 CDP Protocol 
    . 
    . 
   48        3864     5736     673   0.00%  0.00%  0.00%   0 ODR Router 

Hub# show proc cpu 
CPU utilization for five seconds: 2%/0%; one minute: 3%; five minutes: 3% 
PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
  . 
  . 
 18    11588676  15784090    734   1.31%  1.79%  1.95%   0 CDP Protocol 
  . 
  . 
 48        3864      5736    673   0.00%  0.00%  0.00%   0 ODR Router 
       

Hub# show proc cpu 
CPU utilization for five seconds: 1%/0%; one minute: 3%; five minutes: 3% 
PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
  . 
  . 
 18    11588824  15784283    734   0.65%  1.76%  1.94%   0 CDP Protocol 
  . 
  . 
 48        3864      5737    673   0.00%  0.00%  0.00%   0 ODR Router 

Hub# show proc cpu 
CPU utilization for five seconds: 3%/0%; one minute: 3%; five minutes: 3% 
PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
  . 
  . 
 18    11589004  15784473    734   1.96%  1.85%  1.95%   0 CDP Protocol 
  . 
  . 
 48        3864      5737    673   0.00%  0.00%  0.00%   0 ODR Router 
       

Hub# show proc cpu 
CPU utilization for five seconds: 3%/0%; one minute: 3%; five minutes: 3% 
PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
  . 
  . 
 18    11589188  15784661    734   1.63%  1.83%  1.94%   0 CDP Protocol 
  . 
  . 
 48        3864      5737    673   0.00%  0.00%  0.00%   0 ODR Router

Ampliaciones

La versión de ODR anterior al IOS 12.0.5T de Cisco tenía algunas limitaciones. A continuación se encuentra la lista de actualizaciones en el IOS 12.0.5T de Cisco y superiores.

  • Antes de CSCdy48736, las subredes secundarias se anunciaban como /32 en una actualización CDP. Esto se fija en 12.2.13T y posterior.

  • Los hubs de los CDP ahora propagan rutas predeterminadas a los spokes, por lo que no se necesitan rutas predeterminadas estáticas en los spokes. El tiempo de convergencia aumenta perceptiblemente. Cuando va el salto siguiente abajo, el spoke lo detecta rápidamente vía el ODR y converge. Esta característica se agrega en 12.0.5T a través del bug CSCdk91586.

  • Si el link entre el hub y el spoke no tiene numeración IP, la ruta predeterminada que envía el hub puede no aparecer en los spokes. Este error de funcionamiento, CSCdx66917, se reparó en el IOS 12.2.14, 12.2.14T y en versiones posteriores.

  • Para aumentar/disminuya la distancia ODR en el spokes así que pueden preferir un concentrador sobre el otro, una sugerencia se han hecho que se esté siguiendo vía CSCdr35460. El código se ha probado y estará ya disponible pronto para los clientes.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 13710