Diseño de Redes Stub a Gran Escala con ODR
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 de Cisco IOS® que se ejecuta en el dispositivo Cisco vecino, las capacidades del dispositivo vecino, etc. 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, a menudo es muy costoso ejecutar un protocolo de ruteo 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.
ODR no es un protocolo de ruteo y no debe tratarse 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 de ODR con otros protocolos de IP Routing 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 no hay información que pase por la red, se trata de 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 a otro router además del router hub.
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. Las cajas de gama baja normalmente tienen una 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 en la que haya una gran actualización de 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 casos especiales, puede haber más de un hub, ya sea para redundancia o para soportar radios adicionales a través de un hub separado. 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 
Radios con un solo punto de salida
En la figura 1 anterior, los radios están conectados a un hub para que puedan confiar en el gateway predeterminado en lugar de recibir toda la información de ruteo para el hub con un punto de salida. No es necesario pasar toda la información a los radios, ya que un spoke no tendrá que tomar una decisión de ruteo inteligente. Un spoke siempre enviará el tráfico al hub, por lo que los spokes sólo necesitan una ruta predeterminada que apunte hacia un hub.
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. Sin embargo, al utilizar ODR, no es necesario habilitar los protocolos de ruteo en el lado radial. Con ODR, sólo se necesitan Cisco IOS 11.2 y una ruta estática predeterminada que apunte a un hub 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.
Los radios deben ser punto a punto; de lo contrario, la ruta estática predeterminada 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 en día, no hay otro método en el lado radial para preferir un link sobre el otro en una única situación hub, 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 anula automáticamente las rutas predeterminadas que vienen en los radios a través de 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 
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. Todos los hubs deben estar completamente mallados para que si uno de los links de los spokes falla, se pueda alcanzar el destino a través de un segundo hub. Consulte la sección ODR vs. Otros Protocolos de Ruteo de este documento para obtener una explicación más detallada. De manera similar, en el caso de varios hubs, si IOS 12.0.5T o posterior está en uso, los hubs envían las rutas predeterminadas ODR a spokes y spokes instalan 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 ruta estática predeterminada definida en el router del spoke y el uso de la distancia administrativa en el comando static route para preferir un hub 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 
ODR frente a otros protocolos de routing
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. Los spokes de link lento desperdician ancho de banda en actualizaciones de ruteo y en mantener relaciones de vecinos. 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 en día, tenemos una nueva función en EIGRP que amplía EIGRP mucho mejor en una situación radial y de hub. Consulte Enhanced IGRP Stub Routing para obtener más información sobre la función EIGRP stub.
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, OSPF se habilita en 100 spokes conectados por una configuración punto a punto. 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, una inestabilidad en un área stub todavía activará a SPF para que se ejecute en los radios, por lo que esta sobrecarga no se puede curar haciendo un pequeño área stub sin resumen y sin externales.
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.
Actualizar a una plataforma mejor no es una solución permanente; sin embargo, 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.
La tormenta Hello
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. El hub OSPF envía y recibe paquetes hello compuestos por 20 bytes de encabezado IP, 24 bytes de encabezado OSPF, 20 bytes de parámetros hello y 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 de saludo OSPF para 100 vecinos| Encabezado IP de 20 bytes |
| Encabezado OSPF de 24 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. Estos tipos de conexiones pueden pasar muy poco o ningún tráfico de datos durante el funcionamiento normal.
El comportamiento periódico del RIP ocasiona problemas en estos circuitos. RIP tiene problemas con interfaces punto a punto de ancho de banda bajo. 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 desencadenado
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.
-
El router se enciende 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 trigger se debe configurar en la interfaz del router hub que se conecta a los radios.
Al comparar RIPv2 con ODR, ODR es una mejor opción porque RIPv2 funciona en la capa 3 y ODR 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
ODR funciona mejor en una red a gran escala que cualquier otro protocolo de ruteo. 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 hub y los spokes para que esos links no se incluyan en el dominio EIGRP porque no colocará declaraciones de 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 se pierden rutas específicas de uno de los radios, envíe las consultas a todos los vecinos en los routers de 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. Siempre y cuando el link entre los dos hubs no esté en la misma red principal que los spokes, la configuración debería funcionar correctamente.
Figura 4: Redundancia y producción de resumen: El núcleo está recibiendo rutas resumidas 
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 el link entre un hub y spoke se desactiva, es posible alcanzar el destino a través del segundo hub.
ODR con OSPF en concentradores
En este escenario, el OSPF no tiene que estar deshabilitado en el link que conecta las radios. En un escenario normal, si OSPF se habilita en el link y un link específico se inestable constantemente, puede causar varios problemas, incluyendo la ejecución SPF, la regeneración de LSA del router, la regeneración de LSA de resumen, etc. Cuando ejecute ODR, no incluya el link serial conectado en el dominio OSPF. La principal preocupación es recibir la información del segmento LAN de los radios. 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 se puede detectar si se resume la información del router principal.
Figura 5: Redundancia y producción de resumen: El router del núcleo está recibiendo rutas resumidas 
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 mejoras futuras
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.
A continuación se muestra un ejemplo de configuración que utiliza 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, se recibe información más específica de ambos hubs. Dado que la distancia OSPF es 110 y la distancia ODR es 160, la información interfiere con ODR cuando se recibe del otro hub alrededor de la misma subred. 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 siempre se prefiera la ruta ODR sobre la ruta OSPF. Si la ruta ODR falla, la ruta externa OSPF se instalará en la tabla de ruteo desde 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 demanda
El circuito de demanda es una función Cisco IOS 11.2 que también se puede utilizar en redes hub-and-spoke. 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 radios que un hub podía soportar era de 300 debido a los límites IDB. Si una red requería más de 300 spokes, la configuración punto a punto no era una buena opción. Además, se generó un paquete CDP distinto para cada link. La complejidad de tiempo para enviar actualizaciones CDP en 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 de hub y spoke de gran tamaño, la configuración de una interfaz punto a multipunto es una mejor solución que una interfaz punto a punto.
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, se genera un paquete CDP 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 punto a multipunto, puede asignar sólo una subred a todos los radios.
ODR y proveedores múltiples
Un concepto erróneo común es que ODR no funcionará si se utilizan varios proveedores. 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 
El router hub conectado a los 98 routers Cisco recibirá actualizaciones de subred a través de ODR y recibirá actualizaciones de protocolo de ruteo de los dos routers diferentes restantes. 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 ejecuta ODR en 100 radios, es posible que finalmente desee 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 
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 sobrecarga de cambio de protocolos. 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. Según estos requisitos, vea la plantilla de configuración siguiente 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. Se recomienda el tiempo máximo de retención de 255 segundos de modo que si el PVC del hub se desactiva y vuelve en cuatro minutos, no se necesita ninguna nueva adyacencia CDP porque se puede utilizar la entrada de la tabla antigua.
A continuación se muestra un ejemplo de una plantilla de 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 varias redes hub, los radios pueden anunciar la interfaz conectada que es el link a otro hub.
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 consume mucha 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 se realizó con un procesador de 150 MHz 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 significativamente. Cuando el salto siguiente se interrumpe, el spoke lo detecta rápidamente a través de ODR y converge. Esta función se agrega en 12.0.5T a través del error 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/disminuir la distancia ODR en los radios para que puedan preferir un hub sobre el otro, se ha hecho una sugerencia que se está rastreando a través de CSCdr35460. El código ya se ha probado y pronto estará disponible para los clientes.
Comentarios