CAPITULO 2. CONFIGURANDO EL PROTOCOLO EIGRP

EIGRP SOBRE MPLS

Esta sección proporciona un visión de MPLS y tecnología VPN MPLS de capa 2 y 3; así como se explica cómo se puede desarrollar EIGRP en estos ambientes.

MPLS

MPLS es una arquitectura estándar del IETF (Internet Engineering Task Force), que combina las ventajas de enrutamiento de capa 3, con los beneficios de la conmutación de Capa 2.

Con MPLS, etiquetas de longitud fija cortas se asignan a cada paquete en el borde de la red. En lugar de examinar la información de cabecera del paquete IP, nodos MPLS usan esta etiqueta para determinar cómo procesar los datos.

Este proceso da lugar a una solución WAN más escalable y flexible. Los estándares MPLS evolucionaron a partir de los esfuerzos de muchas empresas, incluida la tecnología de etiquetas de conmutación de Cisco.

MPLS permite VPN escalables y de calidad de servicio de extremo a extremo (QoS), y otros servicios IP que permiten la utilización eficiente de las redes existentes con la configuración más simple, la gestión y la corrección de fallas más rápido.

Operación MPLS

MPLS es una tecnología orientada a la conexión cuyo funcionamiento se basa en una etiqueta fijada a cada paquete a medida que entra la red MPLS. Una etiqueta identifica un flujo de paquetes (por ejemplo, tráfico de voz entre dos nodos), también llamado un FEC (Forwarding Equivalence Class). Un FEC es un conjunto de paquetes. Los paquetes que pertenecen a la misma FEC reciben el mismo tratamiento en la red. El FEC puede ser determinado por varios parámetros, incluyendo la dirección IP de origen y destino o los números de puerto, protocolo IP, precedencia de IP, o identificador de circuito Capa 2. Por lo tanto, la FEC puede definir los requisitos de calidad de servicio del flujo. Además, las políticas de gestión de colas y de descarte apropiados se pueden aplicar para la FEC.

Los nodos de la red MPLS, llamados routers de conmutación de etiquetas (LSR, Label-Switched Routers), utilizan la etiqueta para determinar el siguiente salto del paquete. Los LSRs no necesitan examinar la cabecera IP del paquete; sino que ellos lo reenvíen en base a la etiqueta.

Después de que una ruta de acceso se ha establecido, los paquetes destinados para el mismo punto final, con los mismos requisitos pueden ser enviados sobre la base de estas etiquetas sin una decisión de enrutamiento en cada salto. Las etiquetas suelen corresponder a prefijos de destino Capa 3, lo que convierte a MPLS equivalente al enrutamiento basado en destino.

Un camino de etiquetas conmutadas (LSP, Label-Switched Path) se debe definir para cada FEC antes de que los paquetes se puedan enviar. Es importante tener en cuenta que las etiquetas son localmente significativas sólo a cada nodo MPLS. Por lo tanto, los nodos deben comunicar cuál etiqueta usar para

cada FEC. Uno de los dos protocolos es utilizado para esta comunicación: el Protocolo de distribución de etiquetas (Label Distribution Protocol) o una versión mejorada del protocolo de reserva de recursos (Resource Reservation Protocol). Un protocolo de enrutamiento interior, tal como OSPF o EIGRP también se utiliza dentro de la red MPLS para intercambiar información de enrutamiento.

Una característica única de MPLS es su capacidad para llevar a cabo el apilamiento de etiquetas, en el que varias etiquetas pueden ser transportadas en un paquete. La etiqueta de la parte superior, que es la última, siempre se procesa primero. El apilamiento de etiquetas habilita múltiples LSP's a ser agregados, de este modo creando túneles a través de múltiples niveles de una red MPLS.

Una etiqueta de MPLS es un campo de 32 bits situado entre el encabezado de la capa de enlace de datos de un paquete y su cabecera IP. La figura 2-27 ilustra el flujo de dos paquetes a través de una red MPLS.

Figure 2-27. Labels Are Used to Assign a Path for a Packet Flow Through an MPLS Network.

En la figura 2-27 , cada uno de los nodos MPLS ha comunicado previamente las etiquetas que utiliza para cada una de las clases FEC definidas a sus nodos vecinos. El Paquete A y paquete y B representan diferentes flujos. Por ejemplo, el Paquete A podría ser de una sesión FTP, mientras que los paquetes B es de una conversación de voz. Sin MPLS, estos paquetes podrían tomar la misma ruta a través de la red.

En la figura 2-27, el Router V es el LSR de borde de entrada para los paquetes A y B , el punto en el que los paquetes entran en la red. El Router V examina cada paquete y determina la FEC apropiada. El Paquete A se le asigna la etiqueta 17 y se envía al Router X. El Paquete B se le asigna la etiqueta 18 y se envía al Router W. Como cada LSR recibe un paquete etiquetado, quita la etiqueta, localiza la etiqueta en su tabla, se aplica la etiqueta saliente adecuada y reenvía el paquete al siguiente LSR en el LSP. Cuando los paquetes llegan al router Z (el LSR de borde de salida o el punto en el que los paquetes salen de la red de MPLS), Router Z elimina la etiqueta y reenvía los paquetes de manera apropiada, basado en su tabla de enrutamiento IP .

Es importante tener en cuenta que los paquetes enviados entre los mismos puntos finales pueden pertenecer a diferentes clases FEC de MPLS y por lo tanto pueden fluir a través de diferentes rutas en la red .

OFERTAS DE PROVEEDORES DE SERVICIO

Muchos ISP ofrecen servicios de transporte Capa 2 a sus clientes para interconectar las redes de varias oficinas a través de los equipos routers del cliente (CE, Customer Equipment). Los ISP's ofrecen estos servicios sobre una infraestructura basada en circuitos para construir VPNs de capa 2. Las VPNs iniciales fueron construidas usando líneas arrendadas con encapsulados PPP y HDLC. Más tarde, los proveedores de servicios ofrecieron VPN Capa 2 basadas en la conectividad de capa de enlace de datos punto a punto, utilizando circuitos virtuales ATM o Frame Relay. Los clientes construyeron sus propias redes Capa 3 en la parte superior de estas redes de capa 2 para acomodar el tráfico IP. De este modo, las redes separadas existían para el tráfico de Capa 2 y Capa 3, que eran difíciles y costosas de mantener.

Las VPNs MPLS se introdujeron para proporcionar una red unificada para los servicios VPN de Capa 3. Para los clientes que todavía quieren conexiones Capa 2, los ISP podrían implementar extensiones VLAN Ethernet a través de un área metropolitana o servicios ATM. Atom (Any Transport over MPLS) fue introducido para facilitar esta conectividad de capa 2 a través de una red troncal MPLS.

Atom permite el envío de tramas de nivel 2 a través de una red troncal MPLS. Unifica ofertas Capa 2 y Capa 3 sobre una infraestructura MPLS común. En Atom, VCs representan Layer 2 enlaces y etiquetas MPLS identifican VCs.

Atom permite más ofertas de proveedores de Internet que actualmente ofrecen conectividad capa 2 a los clientes con ofertas tradicionales, tales como ATM, Frame Relay y servicios seriales PPP, y los que se especializan en la conectividad Ethernet en las áreas metropolitanas. Estos servicios VPN Capa 2 atraen a los clientes empresariales del ISP quienes ya pueden gestionar sus propias redes y necesitar sólo conectividad punto a punto entre los sitios.

SOLUCIONES VPN MPS CAPA 2 Y CAPA 3

La figura 2-8 ilustra las diferencias entre un VPN MPLS Capa 2 y una solución backbone VPN Capa 3. Los routers del cliente (R1 y R2 en la figura) están conectados a través de un backbone VPN MPLS.

Figure 2-28. Layer 2 and Layer 3 MPLS VPN Solutions.

VPN MPLS de Capa 2 ofrece un servicio de capa 2 a través del backbone, donde los routers R1 y R2 están conectados entre sí en la misma IP de subred. La Figure 2-28 representa la conectividad a través del backbone como un switch de capa 2.

VPN MPLS de Capa 3 ofrece un servicio de capa 3 a través del backbone, donde los routers R1 y R2 están conectados a los routers de borde ISP. En cada lado, se utiliza una subred IP diferente. La Figura 2-28 representa la conectividad a través del backbone como un router.

Las siguientes secciones describen VPN MPLS de Capa 3 y Capa 2.

VPN MPLS de Capa 3

Como se muestra en la figura 2-29, en la terminología de VPN MPLS, la red es dividida en la parte controlada por el cliente (la red-C) y la parte controlada por el proveedor (la red-P). Porciones contiguas de red-C se denominan sitios y están vinculadas a la red-P a través de routers de borde del cliente (routers CE, Customer Edge). Los routers CE se conectan a los routers PE, que sirven como los dispositivos de borde de la red del proveedor. Los dispositivos de núcleo de la red del proveedor (los routers-P) proporcionan el transporte a través del backbone del proveedor y no transportan rutas de los clientes. El proveedor de servicio conecta a múltiples clientes sobre una red troncal (backbone) MPLS común utilizando VPNs MPLS.

Figure 2-29. Layer 3 MPLS VPN.

La arquitectura de un router PE en una VPN MPLS es similar a la arquitectura de un punto de presencia (POP) en un router dedicado PE del modelo de igual a igual (peer-to-peer); Sin embargo, en una VPN MPLS, toda la arquitectura se condensa en un solo dispositivo físico. En una VPN MPLS, a cada cliente se le asigna una tabla de enrutamiento independiente - la tabla virtual de enrutamiento y

reenvío (VRF, Virtual Routing and Forwarding) en el router PE - que corresponde al router PE dedicado en un modelo tradicional de igual a igual. El enrutamiento a través del backbone del proveedor se lleva a cabo por un proceso de enrutamiento separado que utiliza una tabla global de enrutamiento IP. Este proceso de enrutamiento se corresponde con los P-routers dentro del modelo tradicional peer-to-peer.

El backbone VPN de MPLS en la figura 2-29 es un backbone capa 3. Los routers CE tratan a los routers PE de la misma forma que tratan a otros routers de clientes en la ruta entre sitios. Los Routers PE mantienen tablas de enrutamiento separadas para cada cliente.

La arquitectura VPN de MPLS ofrece ISPs con una arquitectura VPN peer-to-peer que combina las mejores características de una VPN de capa superior (overlay VPN) con las mejores características de una VPN punto a punto (peer-to-peer VPN) , incluyendo las siguientes:

• Routers PE participan en el enrutamiento del cliente, proporcionando enrutamiento óptimo entre los sitios de los clientes. • Routers PE llevan un conjunto separado de rutas para cada cliente, aislando cada cliente de otros clientes.

Perspectivas de clientes de las VPNs MPLS de Capa 3

Como se ilustra en la figura 2-30, el backbone VPN de MPLS se parece a una red troncal corporativa estándar para los routers CE. Los routers CE corren programas de enrutamiento IP estándar e intercambian actualizaciones de enrutamiento con los routers PE, que parecen como routers normales en la red del cliente. Por lo tanto, el cliente y el SP deben estar de acuerdo sobre los parámetros de EIGRP.

Figure 2-30. Customer Perspective of Layer 3 MPLS VPNs.

La topología interna del backbone MPLS es transparente para el cliente. Los routers-P internos están ocultos a la vista del cliente y los routers CE no son conscientes de la VPN MPLS.

En una VPN MPLS de Layer 3, se deben cumplir los siguientes requisitos:

• Los routers de los clientes (routers CE) no deberían estar conscientes de la VPN MPLS. Deberían ejecutar el software estándar de enrutamiento IP. • Los routers de núcleo del proveedor (routers-P del core) no deben llevar rutas del cliente (VPN), para hacer la solución VPN MPLS escalable. • Los routers PE deben soportar los servicios VPN de MPLS y los servicios IP tradicionales.

EIGRP SOBRE VPN MPLS DE CAPA 3

La Fig 2-31 proporciona un ejemplo de EIGRP desarrollado sobre una VPN MPLS de Capa 3. La configuración para los routers R1 y R2 son mostrados en el ejemplo 2-39.

Figure 2-31. EIGRP over a Layer 3 MPLS VPN.

Example 2-39. Configurations of Router R1 and R2 in Figure 2-31R1#interface FastEthernet0/0ip address 192.168.1.2 255.255.255.252!router eigrp 110network 172.16.1.0 0.0.0.255network 192.168.1.0

R2#interface FastEthernet0/0ip address 192.168.2.2 255.255.255.252!router eigrp 110network 172.17.2.0 0.0.0.255network 192.168.2.0

Los routers R1 y R2 están configurados para EIGRP como si no hubiera un núcleo de red corporativa entre ellos. El cliente tiene que ponerse de acuerdo sobre los parámetros EIGRP (como el número de autónomos de sistema, contraseña de autenticación, etc) con el SP para garantizar la conectividad. El SP a menudo gobierna estos parámetros.

Los routers PE reciben actualizaciones de enrutamiento de los routers CE e instalan estas actualizaciones en la tabla VRF correspondiente. Esta parte de la configuración y el funcionamiento es responsabilidad del SP.

El ejemplo 2-40 muestra las tablas de vecinos EIGRP resultantes de los routers R1 y R2. Observe que el Router R1 establece una relación de vecino EIGRP con el router PE1, y el Router R2 establece una relación de vecino EIGRP con el router PE2. Los routers R1 y R2 no establecen una relación de vecino EIGRP entre sí.

Example 2-40. Output on Router R1 and R2 in Figure 2-31

VPNs MPLS DE CAPA 2

Esta sección describe la VPN MPLS de capa 2 y cómo EIGRP se despliega sobre ellos.

Conectividad puerto a puerto Ethernet sobre una VPN MPLS de Capa 2

Con una VPN MPLS de Capa 2, una red troncal (backbone) MPLS proporciona una conexión Puerto a Puerto Ethernet de Capa 2, tal como entre los dos routers clientes R1 y R2 en la figura 2-32 .

Figure 2-32. Ethernet Port-to-Port Connectivity over a Layer 2 MPLS VPN.

En la Figura 2-32, los routers R1 y R2 están intercambiando tramas Ethernet. El router PE1 toma la trama Ethernet recibida desde el router R1 conectado directamente, la encapsula en un paquete MPLS y la envía a través del backbone al router PE2 . El router PE2 desencapsula el paquete MPLS y reproduce la trama Ethernet sobre su enlace Ethernet al router R2. Este proceso es un tipo de AToM llamado EoMPLS. (EoMPLS también se conoce como un tipo de servicio de Metro Ethernet).

AToM y EoMPLS no incluyen ningún aprendizaje ni filtrado de direcciones MAC. Por lo tanto, los routers PE1 y PE2 no filtran ningunas tramas basadas en direcciones MAC. AToM y EoMPLS tampoco utilizan el protocolo Spanning Tree (STP). Las BPDU's son propagadas de forma transparente y no

tratadas, por lo que la detección de bucles LAN deben ser realizadas por otros dispositivos o evitadas por diseño. Un proveedor de servicios puede usar switches LAN en conjunto con AToM y EoMPLS para proporcionar estas características.

En el ejemplo de la Figura 2-33, los routers R1 y R2 se comunican con EIGRP sobre EoMPLS. La configuración para ambos routers se muestra en el Ejemplo 2-41

Figure 2-33. EIGRP over EoMPLS.

Example 2-41. Configurations of Router R1 and R2 in Figure 2-33R1#interface FastEthernet0/0ip address 192.168.1.101 255.255.255.224!router eigrp 110network 172.16.1.0 0.0.0.255network 192.168.1.0

R2#interface FastEthernet0/0ip address 192.168.1.102 255.255.255.224!router eigrp 110network 172.17.2.0 0.0.0.255network 192.168.1.0

Cuando se implementa EIGRP sobre EoMPLS, no hay cambios en la configuración de EIGRP desde la perspectiva del cliente. EIGRP necesita ser habilitado con el número de sistema autónomo correcto (el mismo en ambos routers R1 y R2). Los comandos “network” deben incluir todas las interfaces que ejecutarán EIGRP, incluyendo el enlace hacia los routers PE (routers PE1 y PE2) sobre la que los routers R1 y R2 formarán su relación de vecino. Desde la perspectiva de EIGRP, el backbone MPLS y routers PE1 y PE2 no son visibles. Una relación de vecino es establecida directamente entre los routers R1 y R2 sobre el backbone MPLS, y se visualiza con el comando show ip eigrp neighbors. La salida de este comando se muestra en el ejemplo 2-42.

Example 2-42. Output on Router R1 and R2 in Figure 2-33

CONECTIVIDAD VLAN ETHERNET

La figura 2-34 ilustra un escenario alternativo en el que los dos routers cliente R1 y R2 están conectados a los routers de borde de MPLS PE1 y PE2 a través de subinterfaces VLAN. Diferentes subinterfaces en los routers PE se utilizan para conectarse a diferentes VLAN. La subinterfaz del PE1 a la VLAN donde el router R1 es conectado se utiliza para el reenvío de AToM. La trama Ethernet que llega desde el Router R1 en la subinterfaz VLAN específica es encapsulada en MPLS y reenviadada a través del backbone al Router PE2. El router PE2 desencapsula el paquete y reproduce la trama Ethernet en su subinterfaz VLAN de salida al router R2.

Figure 2-34. EIGRP over EoMPLS.

BALANCEO DE CARGA EIGRP

En esta sección se describe el balanceo de carga en EIGRP de igual costo y de costos desiguales.

Balanceo de Carga de igual costo en EIGRP

El balanceo de carga de igual costo es la capacidad de un router para distribuir el tráfico en todos los routers que tienen la misma métrica para la dirección de destino. Todos los protocolos de enrutamiento IP en los routers de Cisco pueden realizar el balanceo de carga de igual costo.

Note que la terminología es igual costo a pesar de que la métrica utilizada en el protocolo de

enrutamiento no puede ser llamado costo (como es el caso de EIGRP). El balanceo de carga incrementa la utilización de los segmentos de la red, lo que aumenta el ancho de banda efectivo.

Por defecto, el IOS de Cisco balancea entre un máximo de cuatro rutas de igual costo para IP. Con el comando de configuración de router “maximum-paths <maximum-path>”, se puede requerir hasta 16 buenas rutas iguales a ser mantenidas en la tabla de enrutamiento. Establecer el parámetro “maximum-path” a 1 para deshabilitar el equilibrio de carga. Cuando un paquete es un proceso de conmutación, el equilibrio de carga a través de rutas de igual costo se produce en función de cada paquete. Cuando los paquetes se conmutan rápido, el balanceo de carga sobre rutas de igual costo es en función de cada destino.

Nota: El balanceo de carga se realiza sólo en el tráfico que pasa a través del router, no el tráfico generado por el router.

La figura 2-35 ilustra un ejemplo de red con las métricas de muestra indicados (las métricas son más pequeñas que los valores reales de más fácil cálculo en el ejemplo). El ejemplo 2-43 muestra la configuración de EIGRP en el router R1. La Tabla 2-7 muestra el contenido de la tabla de topología del router R1 para la ruta 172.16.2.0/24.

La figura 2-35 ilustra un ejemplo de red con las métricas de muestra indicadas (las métricas son más pequeñas que los valores reales para más fácil cálculo en el ejemplo). El ejemplo 2-43 muestra la configuración de EIGRP en el router R1. La Tabla 2-7 muestra el contenido de la tabla de topología del router R1 para la ruta 172.16.2.0/24.

Figure 2-35. EIGRP Equal-Cost Load Balancing.

El Router R1 está configurado para soportar hasta tres rutas de igual costo. El Router R1 mantendrá las rutas a través de R2, R3 y R4 en su tabla de enrutamiento, ya que los tres caminos tienen la misma métrica de 40 (igual costo), como se muestra en la columna de la FD en la Tabla 2-7. El camino a través del router R5 no se utiliza debido a que la métrica es mayor que 40 (que es 60). Incluso si esta métrica fuea la misma de los otros, sólo tres de las cuatro rutas serían utilizadas por el comando de “maximum-path 3”.

BALANCEO DE CARGA CON COSTO DESIGUAL EN EIGRP

EIGRP también puede equilibrar el tráfico a través de múltiples rutas que tengan diferentes métricas - esto se llama balanceo de carga de costos desiguales.

El grado en que EIGRP realiza el balanceo de carga es controlado por el comando de configuración del router “variance <multiplier>”. El “multiplier” es un valor de varianza, entre 1 y 128, que se utiliza para equilibrar la carga. El valor predeterminado es 1, lo que significa balanceo de carga de igual costo. El multiplicador define el rango de valores de la métrica que son aceptados para el equilibrio de carga. El establecimiento de un valor de varianza mayor que 1 le permite a EIGRP instalar varias rutas libres de bucles con costo desigual en la tabla de enrutamiento. EIGRP siempre instalará sucesores (las mejores rutas) en la tabla de enrutamiento. La varianza permite sucesores factibles que también sean instalados en la tabla de enrutamiento.

Solamente los caminos que son factibles se pueden utilizar para el equilibrio de carga, y la tabla de enrutamiento sólo incluye caminos factibles. Las dos condiciones de factibilidad son las siguientes:

• La ruta debe estar libre de bucle. Como se señaló anteriormente, esto significa que la mejor métrica (AD) aprendida desde el siguiente router debe ser menor que la mejor métrica local (la actual FD). En otras palabras, el siguiente router en el camino debe estar más cerca del destino que el router actual.

• La métrica de la ruta completa (la FD de la ruta alternativa) debe ser menor que la varianza multiplicada por la mejor métrica local (el actual FD). En otras palabras, la métrica para toda la ruta alternativa debe estar dentro de la varianza.

Si estas dos condiciones se cumplen, la ruta se llama factible y se puede añadir a la tabla de enrutamiento.

El valor predeterminado de la varianza EIGRP es 1, lo que indica balanceo de carga de igual costo. En este caso, sólo las rutas con la misma métrica del sucesor se instalan en la tabla de enrutamiento local. El comando “variance” no limita el número máximo de rutas. En su lugar, éste define el rango de valores de la métrica que son aceptados para el balanceo de carga por el proceso EIGRP. Si la varianza se establece en 2, cualquier ruta aprendida por EIGRP con una métrica inferior a dos veces la métrica del sucesor será instalada en la tabla de enrutamiento local. Por ejemplo, si el comando “variance” le permite a EIGRP instalar nueve caminos y el comando “maximum-path” establece el valor máximo a 3 caminos, sólo los primeros tres caminos de los nueve disponibles estarán en la tabla de enrutamiento IP.

Nota: EIGRP en sí no comparte carga entre varias rutas. Sólo instala las rutas en la tabla de enrutamiento local. La tabla de enrutamiento local permite al hardware de conmutación del router o software compartir la carga entre los múltiples caminos.

Para controlar cómo el tráfico es distribuido entre las rutas cuando múltiples rutas existan para la misma red de destino y ellas tengan diferentes métricas, se usa el comando de configuración de ruta “traffic-share [balanced | min across-interfaces]”. Con la palabra clave “balanced” (comportamiento por defecto), el router distribuye el tráfico proporcionalmente a las relaciones de las métricas asociadas con las diferentes rutas. Con la opción “min across-interfaces”, el router utiliza sólo las rutas que tienen costos mínimos (En otras palabras, todas las rutas que sean factibles y dentro de la varianza se mantienen en la tabla de enrutamiento, pero sólo las que tienen el mínimo costo se utilizan). Esta última opción permite rutas factibles de respaldo para estar siempre en la tabla de enrutamiento, pero que sólo sean utilizadas si la ruta principal se vuelve indisponible de manera que ya no esté en la tabla de enrutamiento. La figura 2-36 ilustra la misma red como en la figura 2-35, pero con las métricas modificadas. El ejemplo 2-44 muestra el comando añadido al router R1, estableciendo la varianza a 2. La Tabla 2-8 muestra la nueva tabla de topología en el router R1 para la ruta 172.16.2.0/24.

Figure 2-36. EIGRP Unequal-Cost Load Balancing.

El Router R1 utiliza Router R3 como el sucesor porque su FD es la más baja (20). Con el comando “variance 2” aplicado al router R1, el camino a través del router R2 cumple los criterios para el balanceo de carga. En este caso, la FD a través del router R2 (30) es menor que el doble de la FD a través del router sucesor R3 (2 * 20 = 40).

El Router R4 no es considerado para el balanceo de carga porque la FD a través del router R4 (45) es mayor que el doble de la FD para el Router sucesor R3 (2 * 20 = 40). En este ejemplo, sin embargo, el router R4 nunca sería un FS, no importa cuál es la varianza, debido a que su AD de 25 es mayor que la FD del router R1 de 20. Por lo tanto, para evitar un potencial bucle de enrutamiento, el router R4 no se considera más cerca al destino que el router R1 y no puede ser un FS.

El Router R5 no se considera para balanceo de carga con esta varianza debido a que la FD a través del router R5 (50) es más del doble de la FD para el sucesor a través del router R3 (2 * 20 = 40). En este ejemplo, sin embargo, el router R5 sería un FS porque la AD del router R5 de 10 es menor que la FD del router R3 de 20.

La carga en la figura 2-36 es balanceada proporcional al ancho de banda. La FD de la ruta a través de router R2 es 30 y la FD de la ruta a través de router R3 es 20. La relación de tráfico entre los dos

caminos (vía R2 : vía R3) por lo tanto, es de 3/5 : 2/5.

En otro ejemplo de balanceo de carga desigual, cuatro caminos hacia un destino tienen la siguiente métrica:

• Ruta 1: 1100 • Ruta 2: 1100 • Ruta 3: 2000 • Ruta 4: 4000

Por defecto, el router enruta al destino utilizando las dos rutas 1 y 2, ya que tienen la misma métrica. Suponiendo que no existen potenciales bucles de enrutamiento, el comando “variance 2” balancearía carga sobre los caminos 1, 2 y 3, porque 1100 * 2 = 2200, que es mayor que la métrica a través de Ruta 3. Del mismo modo, el comando “variance 4” también incluiría Ruta 4.

Uso del ancho de banda en EIGRP a través de enlaces WAN

Como se discutió anteriormente, EIGRP opera eficientemente en entornos WAN y es escalable tanto en enlaces punto a punto y multipunto NBMA, como enlaces punto a punto. Debido a las diferencias inherentes en las características operacionales de los enlaces, la configuración por defecto de las conexiones WAN podría no ser óptima. Una comprensión sólida de la operación de EIGRP junto con el conocimiento de las velocidades de enlace puede dar una configuración de router eficiente, confiable y escalable.

En esta sección se introduce por primera vez cómo EIGRP utiliza el ancho de banda en las interfaces y luego se dan ejemplos de EIGRP en diversas redes WAN.

Utilización de enlaces EIGRP

Por defecto, EIGRP utiliza hasta un 50% del ancho de banda declarado en una interfaz o subinterfaz. EIGRP utiliza el ancho de banda de la conexión establecida por el comando “bandwidth”, o el ancho de banda por defecto del enlace si no es configurado, cuando se calcula cuánto ancho de banda utiliza.

Se puede ajustar este porcentaje en una interfaz o subinterfaz con el comando de configuración de interfaz “ip bandwidth-percent eigrp <as-number> <percent>”. El as-number es el número de sistema autónomo EIGRP. El parámetro “percent” es el porcentaje del ancho de banda configurado que EIGRP puede utilizar. Puede establecer el porcentaje a un valor superior a 100, lo que podría ser útil si el ancho de banda está configurado artificialmente bajo por razones de políticas en el encaminamiento. El ejemplo 2-45 muestra una configuración que permite a EIGRP utilizar 40 kbps (200% del ancho de banda configurado, 20 kbps) en la interfaz. Es esencial asegurarse de que la línea está preparada para manejar la capacidad configurada (En la siguiente sección, "Ejemplos de EIGRP en redes WAN" proporciona algunos ejemplos más de cuando este comando es útil).

Example 2-45. Adjusting the EIGRP Link Utilization

Router(config)#interface serial0/0/0Router(config-if)#bandwidth 20Router(config-if)#ip bandwidth-percent eigrp 1 200

El IOS de Cisco asume que las subinterfaces Frame Relay punto a punto están operando a la velocidad por defecto de la interfaz. En muchas implementaciones, sin embargo, sólo velocidades fraccionadas (tales como un T1 fraccional) están disponibles. Por lo tanto, cuando se configuran estas subinterfaces, se establece el ancho de banda para que coincida con el CIR contratado.

Cuando se configuran las interfaces multipunto (especialmente para Frame Relay, pero también para ATM y RDSI PRI), recuerde que el ancho de banda es compartido por igual por todos los vecinos. Es decir, EIGRP utiliza el comando “bandwidth” en la interfaz física dividida por el número de vecinos Frame Relay conectados en esa interfaz física para obtener el ancho de banda atribuida a cada vecino. La configuración de EIGRP debería reflejar el porcentaje correcto del ancho de banda real disponible en la línea.

Cada instalación tiene una topología única, y con eso vienen configuraciones únicas. Valores de CIR divergentes a menudo requieren una configuración híbrida que combina las características de los circuitos punto a punto con circuitos multipunto. Cuando se configuran las interfaces multipunto, configurar el ancho de banda para representar el mínimo CIR mide el número de circuitos. Este enfoque podría totalmente no usar los circuitos de mayor velocidad, pero se asegura de que los circuitos con el CIR más bajo no sean saturados. Si la topología tiene un pequeño número de circuitos de muy baja velocidad, estas interfaces son definidas típicamente como de punto a punto de manera que su ancho de banda se puede ajustar para que coincida con la CIR aprovisionada.

EJEMPLOS DE EIGRP SOBRE WAN

En la Figura 2-37, la interfaz del router C ha sido configurada para un ancho de banda de 224 kbps. Existen cuatro vecinos en esta topología multipunto, por lo que cada circuito se asigna una cuarta parte del ancho de banda configurado en la interfaz, lo que resulta en 224/4 = 56 kbps asignados por circuito. Esta asignación de 56 kbps coincide con el CIR provisto de cada circuito.

Figure 2-37. Frame Relay Multipoint in Which All VCs Share the Bandwidth Evenly.

Ejemplo 2-46 muestra la configuración para la interfaz Serial 0 del Router C.

Example 2-46. Adjusting the bandwidth Command on an Interface on Router C in Figure 2-37

RouterC(config)#interface serial 0RouterC(config-if)#encapsulation frame-relayRouterC(config-if)#bandwidth 224

En la figura 2-38, un circuito ha sido dotado de un CIR 56 kbps, y los otros tres circuitos tienen un mayor CIR de 256 kbps. La interfaz en el Router C ha sido configurado para un ancho de banda igual al CIR más bajo multiplicado por el número de circuitos que está apoyado (56 * 4 = 224), como se muestra en el Ejemplo 2-47. Esta configuración protege contra abrumar al circuito de velocidad más lenta en la topología.

Example 2-47. Adjusting the bandwidth Command on an Interface on Router C in Figure 2-38

RouterC(config)#interface serial 0RouterC(config-if)#encapsulation frame-relayRouterC(config-if)#bandwidth 224

La Fig.2-39 presenta una solución híbrida a esta red.

El ejemplo 2-48 muestra la configuración aplicada al Router C en la Fig. 2-39.

Example 2-48. Adjusting the Bandwidth for a Frame Relay Subinterface on Router C in Figure 2-39

RouterC(config)#interface serial 0.1 multipointRouterC(config-subif)#bandwidth 768RouterC(config-subif)#exitRouterC(config)#interface serial 0.2 point-to-pointRouterC(config-subif)#bandwidth 56

El ejemplo 2-48 muestra el circuito de baja velocidad configurado como punto a punto. Los circuitos restantes son designados como multipunto y sus respectivos CIRs se suman para establecer el ancho de banda de la interfaz (256 + 256 + 256 = 768). En la interfaz multipunto, el ancho de banda se comparte por igual entre todos los circuitos. Por lo tanto, el ancho de banda se dividirá en tres, con 256 kbps asignados a cada circuito.

La figura 2-40 ilustra una topología común hub-and-spoke con 10 VCs a los sitios remotos (Sólo 4 de los 10 sitios remotos se muestran en la figura). El ejemplo 2-49 muestra la configuración utilizada en los Routers C y G de Figura 2-40.

Example 2-49. EIGRP WAN Configuration: Point-to-Point Links on Routers C and G in Figure 2-40

RouterC(config)#interface serial 0.1 point-to-pointRouterC(config-subif)#bandwidth 25RouterC(config-subif)#ip bandwidth-percent eigrp 63 128<output omitted>RouterC(config)#interface serial 0.10 point-to-pointRouterC(config-subif)#bandwidth 25RouterC(config-subif)#ip bandwidth-percent eigrp 63 128

RouterG(config)#interface serial 0RouterG(config-if)#bandwidth 25RouterG(config-if)#ip bandwidth-percent eigrp 63 128

Los circuitos son aprovisionados como enlaces de 64 kbps, pero hay insuficiente ancho de banda en el Router C (el hub) para apoyar la asignación. Por ejemplo, si el hub intenta comunicarse con todos los sitios remotos al mismo tiempo, el ancho de banda que se requiere excede la velocidad del enlace disponible de 256 kbps para el hub - 10 veces el CIR de 64 kbps es igual a 640 kbps. En una topología punto a punto, todos los VCs son tratados por igual y por lo tanto configurados exactamente una décima parte de la velocidad de enlace disponible (25 kbps) (Como alternativa, la interfaz Serial 0 principal podría ser configurada con el comando “bandwidth 256”).

Como se ha mencionado, por defecto EIGRP utiliza un 50% del ancho de banda configurado de un circuito. La configuración EIGRP debería reflejar el porcentaje correcto del ancho de banda real disponible en la línea. Por lo tanto, en un intento para asegurar que los paquetes EIGRP son entregados a través de la red Frame Relay en la Figure 2-40, cada subinterfaz tiene el porcentaje de asignación de EIGRP elevado a 128% del ancho de banda especificado. Este ajuste hace que los paquetes EIGRP reciban aproximadamente 32 kbps de los aprovisionados 64 kbps en cada circuito (porque 128% de 25 kbps es 32 kbps). Esta configuración extra restaura la relación 50-50 que fue alterada cuando el ancho de banda se establece en un valor artificialmente bajo. Si el número de VCs cambia, estos cálculos y configuraciones deben ser hecho de nuevo.

Nota: suprimiendo ACKs de EIGRP también ahorra ancho de banda. Un ACK no se envía si un paquete de datos de unidifusión está listo para la transmisión. El campo ACK en cualquier paquete de unidifusión fiable (paquete RTP) es suficiente para reconocer paquete del vecino, por lo que el paquete ACK se suprime para ahorrar ancho de banda. Esta es una característica importante para los enlaces

punto a punto y redes NBMA, porque en tales medios, todos los paquetes de datos se envían como unicast y, por lo tanto, pueden llevar a un acuse de recibo a sí mismos (esto también se conoce como un ACK de lengüeta). En ese caso, no hay necesidad de un paquete ACK.

CONFIGURANDO Y VERIFICANDO AUTENTICACION EIGRP

Se puede prevenir que el router reciba actualizaciones de rutas fraudulentas; configurando la autenticación del router vecino. Se puede configurar la autenticación del vecino EIGRP (también llamado autenticación del router vecino o autenticación de rutas) de modo que los routers puedan participar en el enrutamiento basado en contraseñas predefinidas.

En esta sección se describe primero la autenticación del router en general, seguido de una discusión sobre cómo configurar y solucionar problemas de autenticación de mensajes digest 5 (MD5) en EIGRP.

Autenticación del Router

Se puede configurar la autenticación del router vecino de tal manera que los routers sólo participen en el enrutamiento basado en contraseñas predefinidas.

De forma predeterminada, no se utiliza la autenticación para los paquetes de protocolo de enrutamiento. Sin autenticación de vecino, las actualizaciones de enrutamiento no autorizadas o deliberadamente malintencionadas podrían comprometer la seguridad del tráfico de la red. Por ejemplo, un router no autorizado conectado a la red (por alguien con intenciones maliciosas o inocentes) podría enviar una actualización de enrutamiento ficticio para convencer a su router de enviar tráfico a un destino incorrecto.

Cuando la autenticación del router vecino ha sido configurada, el router autentifica el origen de cada paquete de protocolo de enrutamiento que recibe. Esto se logra mediante el intercambio de una clave de autenticación (también llamada contraseña) que es conocida tanto por el router transmisor como por el receptor.

Autenticación Simple Versus Autenticación MD5

Los routers usan dos tipos de autenticación:

Autenticación de contrasena simple (también llamado Autenticación de texto plano): soportado por los protocolos IS-IS, OSPF y RIPv2.

Autenticación MD5: Soportado por OSPF, RIPv2, BGP y EIGRP.

Ambas formas de autenticación trabajan de la misma manera, con la excepción de que MD5 envía un mensaje digest en lugar de la clave de autenticación en sí. El “mesagge digest” se crea utilizando la clave (y un id de clave con algunos protocolos) y un mensaje, pero la clave en sí no se envía, evitando que se lea mientras está siendo transmitida. La autenticación de contraseña simple envía la clave de autenticación en sí sobre el cable.

Nota: La autenticación de contraseña simple, no se recomienda para su uso como parte de su estrategia de seguridad, ya que es vulnerable a los ataques pasivos. Cualquier persona con un analizador de enlace

podría ver fácilmente la contraseña en el cable. El principal uso de la autenticación de contraseña simple es evitar cambios accidentales en la infraestructura de enrutamiento. El uso de la autenticación MD5, sin embargo, es una práctica de seguridad recomendada.

Precaución: Al igual que con todas las claves, contraseñas y otros secretos de seguridad, es imperativo que te guarden de cerca las claves utilizadas en la autenticación del vecino. Los beneficios de la seguridad de esta característica dependen en mantener todas las claves de autenticación en confidencial. Además, al realizar las tareas de administración del router a través de Simple Network Management Protocol (SNMP), no ignorar el riesgo asociado con el envío de claves a través de SNMP no cifrada.

Con la autenticación de contraseña simple, a (clave) contraseña es configurado en un router; cada router vecino participante debe configurarse con la misma clave. Cuando se envía un paquete, la contraseña se incluye en texto plano.

La Autenticación MD5, descrito en el RFC 1321, El Message-Digest Algorithm MD5, es una autenticación criptográfica. Una clave (contrasena) y un ID clave son configurados en cada router. El router utiliza un algoritmo basado en el paquete de protocolo de enrutamiento, la clave y el ID clave para generar un mensaje diggest (también llamado hash) que se anexa al paquete. A diferencia de la autenticación simple, la clave no se intercambia sobre el cable-el diggest menssage se envía en lugar de la clave, lo que garantiza que nadie pueda espiar la línea y aprender las claves durante la transmisión.

MD5 proporciona autenticación pero no confidencialidad. Los contenidos de los paquetes del protocolo de enrutamiento no son encriptados.

Autenticación MD5 para EIGRP

De forma predeterminada, ninguna autenticación es utilizada para paquetes EIGRP. Puede configurar EIGRP para utilizar la autenticación MD5.

Cuando la autenticación del vecino EIGRP ha sido configurada en un router, el router autentifica el origen de cada paquete de protocolo de enrutamiento que recibe.

Para la autenticación MD5 de EIGRP, debe configurar una clave de autenticación y un ID clave tanto en el router que envía como en el router receptor. Cada router EIGRP toma el ID de la clave y la clave y genera el “menssage digest” que se adjunta a cada paquete de protocolo de enrutamiento y se envía al vecino. El router receptor calcula el hash MD5 de la información EIGRP recibido. Si el hash coincide con el valor recibido, se acepta el paquete. Si no hay ninguna coincidencia, el paquete se descarta en silencio.

Cada clave tiene su propio ID de la clave, que se almacena localmente. La combinación del ID de la clave y la interfaz asociada con el mensaje identifica de forma única el algoritmo de autenticación y la clave de autenticación MD5 en uso.

Se puede aumentar la seguridad de la autenticación MD5 EIGRP haciendo cambios frecuentes de clave. Se puede definir y activar varias claves basadas en el tiempo, tal como se define en la configuración. La transición entre las claves se implementa de tal manera que permite una operación sin interrupciones de los intercambios EIGRP. Los cambios de clave deben estar bien planificados y soportados por la sincronización de tiempo entre los routers. El rollover a una nueva clave sólo funciona si el tiempo en

los routers adyacentes se sincroniza.

Nota: Los routers EIGRP necesitan saber el tiempo para ser capaz de rotar a través de claves en sincronización con los otros routers que participan, para asegurar que todos los routers están utilizando la misma clave en el mismo momento. Varios mecanismos se pueden utilizar para la sincronización de tiempo; Network Time Protocol (NTP) es el más común.

EIGRP permite múltiples claves a ser administradas usando cadenas de claves (key chains). Cada definición de clave dentro de la cadena de clave puede incluir un intervalo de tiempo para el que se activará esa clave (conocido como su vida útil). Luego, durante el tiempo de vida de una clave determinada, los paquetes de actualización de enrutamiento se envían con esta clave activada. Sólo un paquete de autenticación es enviado, independientemente de cuántas claves válidas existan. Al enviar, el software analiza los números de clave, en orden de menor a mayor, y utiliza la primera clave válida que encuentra. Los paquetes entrantes se comprueban utilizando todas las claves válidas.

Al configurar la autenticación EIGRP, debe especificar el ID de la clave (número), la clave (password), y, opcionalmente, el tiempo de vida de la clave.

La primera (el ID de la clave), la clave válida (de por vida) se utiliza al enviar paquetes. En otras palabras, cuando se envía paquetes EIGRP, se utiliza la clave válida con el número de clave más bajo en la cadena. Cuando se reciben los paquetes, todas las claves actualmente válidas se comprueban hasta que se encuentra una coincidencia.

Las claves no se pueden usar durante períodos de tiempo para los que no están activos. Por lo tanto, se recomienda que para una cadena de claves dada, los tiempos de activación de la clave se superpongan para evitar cualquier periodo de tiempo durante el cual ninguna clave esté activada. Si ocurre que durante un periodo de tiempo no se activa ninguna clave, no se puede producir la autenticación de vecinos, y por lo tanto las actualizaciones de enrutamiento fallarán.

PLANIFICANDO AUTENTICACION EIGRP

Antes de configurar la autenticación en EIGRP, el administrador de la red debe examinar la configuración de EIGRP existente y definir los requisitos de autenticación. Los requisitos de autenticación en EIGRP incluyen el tipo de autenticación (ninguno o MD5), el número de claves que se utilizan, así como los parámetros opcionales de tiempo de vida.

Entonces los parámetros deben estar definidos con suficientes detalles por el operador de red para configurar la autenticación EIGRP. Estos parámetros incluyen lo siguiente: • El número de sistema autónomo EIGRP • El modo de autenticación (MD5) • La definición de una o más claves para autenticar paquetes EIGRP, de acuerdo con el plan de seguridad de la red.• Tiempo de vida de las claves, si se definen varias claves.

A un alto nivel, la configuración de la autenticación MD5 en EIGRP requiere los siguientes pasos:

Paso 1. Configurar el modo de autenticación para EIGRP. Paso 2. Configurar la cadena de claves.

Paso 3. Opcionalmente, configurar los parámetros de tiempo de vida de las claves. Paso 4. Habilitar la autenticación para usar las llaves en la cadena de claves.

Configurando Autenticación MD5 en EIGRP

Autenticación MD5 se debe configurar en todas las interfaces entre dos routers vecinos. Para configurar la autenticación MD5 en EIGRP, siga los siguientes pasos:

Paso 1. Entre en el modo de configuración de la interfaz en la que desea habilitar la autenticación.

Paso 2. Especificar autenticación MD5 para paquetes EIGRP usando el comando de configuración de interfaz “ip authentication mode eigrp <autonomous-system> md5”.

Paso 3. Entrar al modo de configuración de la cadena de claves para la cadena de clave (que se configurará más tarde sobre la interfaz) usando el comando de configuración global “key chain <name-of-chain>”.

Paso 4. Identificar un ID de clave para usar y entrar al modo de configuración de esa clave (el modo de configuración “key-chain-key”) usando el comando de configuración “key <key-id>”. El key-id es el número id de una clave de autenticación en una cadena de clave. El rando de claves es desde 0 hasta 2147483647. Los números de ID de claves necesitan no ser consecutivos.

Paso 5. Identificar el string de la clave (la contrasena) para esta clave usando el comando de configuración key-chain-key “key-string key”. El “key”es el key-string de autenticación que será usado para autenticar paquetes EIGRP enviados y recibidos. El string de la clave puede contener de 1 a 80 caracteres alfanuméricos en mayúsculas y minúsculas, excepto el primer caracter que no puede ser un número. El string de la clave para un ID de clave dado debe ser igual en los routers vecinos y es sensible a mayúsculas y minúsuculas.

Paso 6. Opcionalmente especificar el período de tiempo durante el cual esta clave será aceptada para usar sobre paquetes recibidos usando el comando de configuración de key-chain-key “accept-lifetime <start-time>{infinite | end-time | duration seconds}”. La tabla 2-9 describe los parámetros para este comando.

Paso 7. Opcionalmente especificar el período de tiempo durante el cual esta clave puede ser usada paquetes de envío utilizando el comando de configuración de key-chain-key “send-lifetime <start-time>{infinite | end-time | duration seconds}”. La tabla 2-10 describe los parámetros para este comando.

Paso 8. Habilitar la autenticación de paquetes EIGRP con una clave especificada en una cadena de clave usando el comando de configuración de interfaz “ip authentication key-chain eigrp <autonomous-system> <name-of-chain>”. NOTA: Si el comando “service password-encryption” no es utilizado cuando se implementa autenticación EIGRP, el string de la clave será grabado como texto plano en la configuración del router. Si tu configuras el comando “service password-encryption”, el string de la clave será almacenada y mostrada en una forma encriptada; cuando es mostrado habrá un tipo de encriptación de 7 especificado antes del string de la clave encriptada. Table 2-9. accept-lifetime Command Parameters

Table 2-10. send-lifetime Command Parameters

EJEMPLOS DE CONFIGURACIÓN DE AUTENTICACIÓN MD5

La figura 2-41 muestra la red que se utiliza para ilustrar la configuración, verificación y solución de problemas de autenticación MD5.

Figure 2-41. Network for EIGRP Authentication Configuration Example.

El Ejemplo 2-50 muestra la configuración del Router 1.

Example 2-50. Configuration of Router R1 in Figure 2-41

El sistema autónomo de EIGRP 100 es usado en esta red.

La autenticación MD5 es configurada en la interface serial 0/0/1 con el comando “ip authentication mode eigrp 100 md5”. Cuando la autenticación MD5 es configurada, un “diggest key” es agregado a cada paquete EIGRP enviado y es chequeado en cada paquete EIGRP recibido.

El comando “key chain R1chain” entra el modo de configuración para la cadena de la clave “R1chain”. Dos claves están definidas en esta cadena de clave. Cada clave tiene un string de autenticación y un tiempo de vida especificado. El administrador de red quiere cambiar las claves sobre todos los routers en la red cada mes para mejorar la seguridad. El administrador configura una superposición (overlap) de una semana para cambiar las claves en todos los routers configurando que la clave 2 sea válida una semana antes de que expire la clave 1.

La clave 1 es establecida a “first-key” con el comando “key-string firstkey”. Esta clave es aceptable para usar en paquetes recibidos por R1 desde el 1 de Enero del 2009 en adelante, tal como se especifica en el comando “accept-lifetime 04:00:00 Jan 1 2009 infinite”. Sin embargo, el comando “send-lifetime 04:00:00 Jan 1 2009 04:00:00 Jan 31 2009” especifica que esta clave solo era válida para usar con los paquetes de envío hasta el 31 de enero del 2009. No es válido para utilizar en paquetes de envío más allá de esa fecha.

La clave 2 es establecida en “secondkey” con el comando “key-string secondkey”. Esta clave es aceptable para usar en paquetes recibidos por R1 desde el 25 de enero en adelante como se especifica en el comando “accept-lifetime 04:00:00 Jan 25 2009 infinite”. Esta clave puede ser también usada cuando se envían paquetes desde el 25 de enero del 2009 en adelante como es especificado en el comando “send-lifetime 04:00:00 Jan 25 2009 infinite”.

El comando “ip authentication key-chain eigrp 100 R1chain” configurado en la interface serial 0/0/1 especifica que la cadena de clave eigrp “R1chain” será usada en esta interfaz.

Recuerda que el router usa la primera, por el número de clave, clave válida para enviar los paquetes. Como resultado de esta configuración, Router R1 usará la clave 1 para envío, desde el 1 al 31 de enero del 2009 y usará la clave 2 para envío tal que desde las 4:00 AM del 31 de enero (???????). El Router R1 aceptará la clave 1 para paquetes recibidos desde el 1 de Enero del 2009 y también aceptará la clave 2 para paquetes recibidos desde el 25 de Enero del 2009. Todos los demás paquetes MD5 serán descartados. El ejemplo 2-51 muestra la configuración del Router R2

Example 2-51. Configuration of Router R2 in Figure 2-41

La autenticación MD5 es configurada en la interface serial 0/0/1 con el comando “ ip authentication

mode eigrp 100 md5”.

El comando “key chain R2chain” entra al modo de configuuración para la cadena de clave “R2chain”. Dos claves están definidas. La clave 1 es establecida a “firstkey” con el comando “key-string firstkey”. Esta clave es aceptable para usar en paquetes por R2 desde el 1 de enero del 2009 en adelante, tal como se especifica con el comando “accept-lifetime 04:00:00 Jan 1 2009 infinite”. Esta clave también pude ser usada cuando se envían paquetes desde el 1 de enero del 2009 en adelante, tal como se especifica con el comando “send-lifetime 04:00:00 Jan 1 2009 infinite”.

La clave 2 es establecida a “secondkey” con el comando “key-string secondkey”. Esta clave es aceptable para usar en paquetes recibidos por R2 desde el 25 de enero del 2009 en adelante como se especifica con el comando “accept-lifetime 04:00:00 Jan 25 2009 infinite”. Esta clave también puede ser usada cuando se envían paquetes desde el 25 de Enero del 2009 en adelante, como es especificado en el comando “send-lifetime 04:00:00 Jan 25 2009 infinite”.

Como resultado de esta configuración, el router R2 utilizará la clave 1 para enviar, desde 1 de enero del 2009, ya que es la primera clave válida en la cadena de clave (por supuesto, si la clave 1 es borrada en un futuro, la clave 2 será usada para enviar). El Router R2 aceptará la clave 1 para paquetes recibidos desde el 1 de Enero del 2009 y también aceptará la clave 2 para paquetes recibidos desde el 25 de enero del 2009. Los demás paquetes MD5 serán descartados.

El comando “ip authentication key-chain eigrp 100 R2chain” configurado en la interface serial S0/0/1 especifica que la cadena de clave “R2chain” será usada en esta interfaz.

VERIFICANDO AUTENTICACION MD5 PARA EIGRP

El ejemplo 2-52 proporciona la salida de los comandos “show ip eigrp neighbors” y “show ip route” en el router R1 representado en la red de la Figura 2-41. La tabla de vecinos indica que los dos routers han formado con éxito una adyacencia EIGRP. La tabla de enrutamiento confirma que la red 172.17.0.0 se ha aprendido a través de EIGRP través de la conexión en serie. El ejemplo 2-52 también muestra los resultados de un ping a la dirección de la interfaz Fast Ethernet R2 para ilustrar que el enlace funciona.

Example 2-52. Output on Router R1 in Figure 2-41

Se puede usar el comando de verificación “show key chain [name-of-chain]” para ver la cadena de clave, el string de la clave y el tiempo de vida de las claves bajo la cadena de la clave. El ejemplo 2-53 muestra las claves en el Router R1. Este comando es útil para verificar que las cadenas sean las mismas en ambos vecinos y que el tiempo de vida sea configurado apropiadamente.

Example 2-53. show key chain Command Output on Router R1 in Figure 2-41

La cadena de clave “R1chain” y ambas claves, clave 1 (con cadena de autenticación “firstkey”) y clave 2 (con cadena de autenticación “secondkey”) son mostradas. Bajo cada clave el tiempo de vida de la clave es también mostrada. Observando la misma salida desde el router vecino R2, la configuración puede ser verificada.

El comando “show ip eigrp interface detail” puede también ser usado para mostrar información

detallada sobre las interfaces EIGRP para un proceso EIGRP específico, incluyendo el modo de autenticación y la cadena de clave configurada en la interfaz.

RESOLUCIÓN DE PROBLEMAS EN AUTENTICACION MD5

Como se señaló anteriormente, el comando "debug eigrp packets" muestra información general de depuración y es útil para analizar los mensajes que viajan entre los dispositivos locales y remotos, incluidos los mensajes de autenticación.

El ejemplo 2-54 muestra la salida del comando “debug eigrp packets” en R1, el cual muestra que R1 está recibiendo paquetes EIGRP con autenticación MD5, con una identificación de clave igual a 1, a partir de R2.

Example 2-54. debug eigrp packets Command Output on Router R1 in Figure 2-41

Del mismo modo, la salida del comando “debug eigrp packets” en R2 mostrado en el ejemplo 2-55 ilustra que R2 está recibiendo paquetes EIGRP con autenticación MD5, con una identificación de clave igual a 2, a partir de R1 (El Router R1 está utilizando la clave 2 porque esta salida fue tomada en abril, después de que clave 1 expiró para el envío en router R1).

Example 2-55. debug eigrp packets Command Output on Router R2 in Figure 2-41Ejemplo de resolución de problema de autenticación MD5

Para este ejemplo, el string de la clave para la clave 2 del router R1, la que se utiliza cuando se envían paquetes EIGRP, es cambiada para que sea diferente de la cadena de clave que router R2 está esperando. El ejemplo 2-56 muestra los cambios en la configuración de R1.

Example 2-56. Changes to the Configuration of Router R1 in Figure 2-41R1(config-if)#key chain R1chainR1(config-keychain)#key 2R1(config-keychain-key)#key-string wrongkey

La salida del comando “debug eigrp packets” en R2 mostrado en el ejemplo 2-57, ilustra que R2 está recibiendo paquetes EIGRP con autenticación MD5, con una identificación de clave igual a 2, a partir de R1, pero hay una desajuste de autenticación. Los paquetes EIGRP desde R1 son ignorados, y la relación de vecino se declara estar abajo. El resultado del comando “show ip eigrp neighbors” confirma que R2 no tiene ningún vecinos EIGRP.

Example 2-57. Output on Router R2 in Figure 2-41

Los dos routers siguen tratando de restablecer su relación de vecino. Debido a las diferentes claves que se utilizan por cada router en este escenario, R1 autenticará mensajes “hello” enviados por R2 mediante la clave 1. Cuando R1 envía un mensaje "hello" de vuelta a R2 con la clave 2, existe un desajuste de autenticación. Desde la perspectiva de R1, la relación parece ser por un tiempo, pero luego el tiempo termina, como es ilustrado por los mensajes recibidos en R1 mostrado en el ejemplo 2-58. La salida del comando “show ip eigrp neighbors” en R1 también ilustra que R1 tiene a R2 en su tabla de vecinos por un corto tiempo.

Example 2-58. Output on Router R1 in Figure 2-41

En esta sección abordó la autenticación en EIGRP. La siguiente sección proporciona información sobre otras características que se pueden implementar en EIGRP para optimizar su funcionamiento.

OPTIMIZANDO IMPLEMENTACIONES EIGRP

EIGRP es un protocolo de enrutamiento escalable que asegura que a medida que una red se hace más grande, funcione de manera eficiente y se ajuste rápidamente a los cambios. Esta sección describe las técnicas específicas prácticas de EIGRP para implementar una red empresarial eficaz y escalable.

Escalabilidad EIGRP en grandes redes

La operación de una gran red EIGRP plana no es normalmente escalable. Algunos problemas a considerar incluyen lo siguiente:

• Tablas de enrutamiento grandes que necesitan ser procesadas.

• La demanda de gran cantidad de memoria producto de una tabla de topología grande, un gran número de rutas en una tabla de enrutamiento y en algunos entornos (por ejemplo, en los routers de concentración de sitio central), un gran número de vecinos en la tabla de vecinos.

• Las demandas de gran ancho de banda producto del intercambio de un gran número de actualizaciones de enrutamiento y el envío de muchas consultas y respuestas dentro de un dominio EIGRP grande (que posiblemente incluye enlaces con poco ancho de banda y enlaces con un número significativo de errores de transmisión).

Lo siguiente son algunos de muchas variables que afectan la escalabilidad de la red:

• La cantidad de información intercambiada entre los vecinos: Si se intercambian más información que la necesaria para que el enrutamiento funcione correctamente entre vecinos EIGRP, ocaciona un trabajo innecesario durante el inicio del enrutamiento y los cambios en la topología.

• El número de routers: Cuando se produce un cambio en la topología, la cantidad de recursos consumidos por EIGRP está directamente relacionada con el número de routers que deben estar

involucrados en el cambio.

• La profundidad de la topología (topology's depth): la profundidad de la topología puede afectar el tiempo de convergencia. La profundidad se refiere al número de saltos que la información debe viajar para alcanzar todos los routers. Por ejemplo, una red multinacional sin resumen de ruta tiene una gran profundidad y por lo tanto aumenta el tiempo de convergencia. Un diseño de la red de tres niveles (como se describe en el Capítulo 1) es muy recomendable para todos los entornos de enrutamiento IP. La recomendación es que no debe haber más de siete saltos entre dos dispositivos de enrutamiento en una interred empresarial debido a que el retardo de propagación y el proceso de consulta a través de múltiples saltos cuando se producen cambios pueden reducir la velocidad de la convergencia de la red cuando las rutas son perdidas.

• El número de caminos alternativos a través de la red: Una red debe proporcionar rutas alternativas para evitar puntos únicos de falla. Sin embargo, demasiados caminos alternativos pueden crear problemas con la convergencia de EIGRP, ya que el proceso de enrutamiento EIGRP, usando consultas, necesita explorar todos los caminos posibles para las rutas perdidas. Esta complejidad crea una condición ideal por que un router se convierta en SIA (Sutck-in-Active) - descrito en la siguiente sección - mientras espera una respuesta a las consultas que se están propagando a través de los numerosos caminos alternativos.

Al implementar EIGRP como protocolo de enrutamiento, algunos problemas de diseño deben ser abordados. Tres factores principales son:

• El tamaño de las tablas de topología y enrutamiento, que se ve afectada por el número de routers vecinos. • El número de cambios en la red. • La carga EIGRP en la WAN.

Estos tres factores determinan el diseño de EIGRP y donde los límites de la consulta se deben introducir (mediante el resumen, la redistribución, y así sucesivamente, como se describe más adelante en este capítulo). Sin ningún tipo de límites, las consultas se propagan en todo el dominio EIGRP, y muy a menudo, todos los routers se involucran en un cálculo DUAL, lo que resulta en una alta utilización de ancho de banda y la carga de la CPU. Cálculos DUAL frecuentes tienen un efecto sobre todas las tablas mantenidas por los routers, incluyendo tablas de EIGRP y los cachés construidos durante el proceso de reenvío.

CONSULTAS DE EIGRP Y STUCK-IN-ACTIVE (ATASCADO-EN ACTIVO)

Como un protocolo de enrutamiento de vector distancia avanzado, EIGRP depende de sus vecinos para proporcionar información de enrutamiento. Recordemos que cuando un router pierde una ruta y no tiene un FS en su tabla de topología, busca un camino alternativo hacia el destino. Esto se conoce como ir a activo (going active) sobre una ruta.(Recordemos que una ruta es considerada pasiva cuando un router no está recalculando esa ruta). Recalcular una ruta implica el envío de paquetes de consulta a todos los vecinos en las interfaces distintas de la que se utiliza para llegar a la sucesora anterior (a causa de horizonte dividido), preguntando si tienen una ruta hacia el destino dado. Si un router tiene una ruta alternativa, éste responde a la consulta con un paquete de respuesta y no propaga la consulta más allá. La respuesta incluye la ruta alternativa. Si un vecino no tiene una ruta alternativa, consulta cada uno de sus propios vecinos por un camino alternativo. Las consultas a continuación, se propagan a

través de la red, creando así un árbol de expansión de consultas. Cuando un router responde a una consulta, se detiene la propagación de la consulta a través de esa rama de la red. Sin embargo, la consulta todavía se puede propagar a través de otras partes de la red tal que otros routers intenten encontrar caminos alternativos, que podrían no existir.

La Figura 2-42 presenta un ejemplo de red donde una sola ruta perdida podría dar lugar a un enorme número de consultas enviadas en todo el dominio de EIGRP. La ruta a la red 10.1.1.0 en el router R1 se pierde y el router R1 envía una consulta a todos los routers vecinos en todas las interfaces excepto la interfaz del sucesor (a causa de horizonte dividido). En este caso, la consulta se envía al router R2. El Router R2 cascadea la consulta a sus vecinos, ya que no tiene información sobre la ruta perdida y así sucesivamente. Cada consulta requiere una respuesta por parte del vecino y la cantidad de tráfico EIGRP aumenta. En esta topología de la red, ninguna ruta redundante a la red 10.1.1.0 está disponible, y el proceso de propagación de consultas EIGRP está lejos de ser eficiente. Muchas consultas se envían y cada consulta es seguida por una respuesta. Existen varias soluciones para optimizar el proceso de propagación de consulta y de limitar la cantidad de carga EIGRP innecesaria en los enlaces, incluyendo el resumen, la redistribución y el uso de la función de enrutamiento stub de EIGRP.

Figure 2-42. EIGRP Query Process.

Nota: Las funciones de resumen de EIGRP y enrutamiento stub se exploran más adelante en este capítulo. Los detalles de cómo se redistribuyen las rutas están cubiertas en el Capítulo 4.

Las secciones siguientes describen cómo EIGRP puede atascarse en el estado activo de una ruta, y la forma de evitar que esto suceda.

CONEXIONES STUCK-IN-ACTIVE EN EIGRP

Debido al enfoque de multicast fiable utilizado por EIGRP en la búsqueda de una alternativa a una ruta perdida, es imperativo que una respuesta (reply) sea recibida para cada consulta generada en la red. En otras palabras, cuando una ruta pasa a activa y se inician las consultas, la única forma en que esta ruta puede salir del estado activo y pasar al estado pasivo es mediante recibiendo una respuesta (reply) para cada consulta generada.

Si el router no recibe una respuesta a todas las consultas pendientes dentro de los 3 minutos (el tiempo predeterminado), la ruta va al estado SIA (Stuck-In-Active).

Nota: Se puede cambiar el límite de tiempo del estado activo desde su valor predeterminado de 3 minutos; usando el comando de configuración de router “timers active-time [timelimit | disabled]”. El “timelimit” está en minutos.

Cuando una ruta pasa al estado SIA, el router reiniciará las relaciones de vecindad para los vecinos que no pudieron responder. Esto provoca que el router vuelva a calcular todas las rutas conocidas a través de ese vecino y republique todas las rutas que conoce a ese vecino.

Las razones más comunes para las rutas atascadas en activo (SIA) son las siguientes:

• El router está demasiado ocupado para responder a la consulta: Por lo general resulta de un alto uso de CPU o de problemas de memoria; el router no puede asignar memoria para procesar la consulta o construir el paquete de respuesta.

• El enlace entre los dos routers no es bueno: Este problema produce la pérdida de paquetes entre los routers. El router recibe un número adecuado de paquetes para mantener la relación de vecino, pero no recibe todas las consultas o respuestas.

• Una falla provoca que el tráfico en un enlace fluya en una sola dirección: Esto se llama un enlace unidireccional.

NOTA: Usar el comando “eigrp log-neighbor-changes” para habilitar el logging de los cambios de adyacencias vecinas, monitorea la estabilidad del sistema de enrutamiento y ayuda a detectar problemas relacionados a SIA.

Un enfoque erróneo para disminuir las posibilidades de una ruta de SIA es utilizar múltiples sistemas autónomos EIGRP para delimitar el rango de la consulta. Muchas redes han implementado el uso de varios sistemas autónomos EIGRP (para simular un tanto áreas OSPF), con la redistribución mutua entre los diferentes sistemas autónomos. Aunque este enfoque cambia la forma en que la red se comporta, no siempre logra los resultados previstos. Si una consulta alcanza el borde del sistema autónomo (donde las rutas se redistribuyen en otro sistema autónomo), la consulta original es contestada. Sin embargo, el router de borde inicia entonces una nueva consulta en el otro sistema autónomo. Por lo tanto, el proceso de consulta no se ha detenido y la consulta continúa en el otro sistema autónomo, donde la ruta potencialmente puede ir en SIA .

Otra idea falsa sobre los límites del sistema autónomo es que la implementación de varios sistemas autónomos protege un sistema autónomo de flaps de rutas en otro sistema autónomo. Si las rutas son redistribuidas entre sistemas autónomos, las transiciones de ruta de un sistema autónomo se detectan en los otros sistemas autónomos.

PREVINIENDO CONEXIONES SIA

SIA-Query y SIA-Reply son dos nuevas incorporaciones a la tripleta Tipo, Longitud, Valor (TLV) en el encabezado del paquete EIGRP. Estos paquetes son generados automáticamente con ninguna

configuración requerida, desde el Software IOS de Cisco Release 12.1(5) y más allá, con la característica de mejora de proceso activo (Active Process Enhancement Feature). Esta característica habilita a un router EIGRP para monitorear el progreso de la búsqueda de una ruta del sucesor y asegurarse de que el vecino siga siendo accesible. El resultado es una mayor fiabilidad de la red mediante la reducción de la terminación involuntaria de adyacencia de vecinos .

El diagrama de la izquierda en la figura 2-43 ilustra lo que ocurriría antes de la introducción de esta función. El router A envía una consulta para la red 10.1.1.0/24 al Router B, cuando se pierde la conexión a la red. El router B no tiene ninguna entrada para esta red, por lo que le consulta a Router C. Si existen problemas entre el router B y C, el paquete de respuesta desde el Router C al Router B puede ser retrasado o perdido. El Router A no tiene la visibilidad del progreso aguas abajo y asume que no ninguna respuesta indica problemas con Router B. Una vez que expire el temporizador activo (active timer) de 3 minutos del Router A, el relación de vecindad con el Router B se reinicia, junto con todas las rutas conocidas de Router B.

Figure 2-43. Cisco IOS Active Process Enhancement.

Por el contrario, con la característica de mejora de proceso activo, como se ilustra en el diagrama de la derecha en la figura 2-43, el Router A consulta aguas abajo a Router B (con un SIA-Query) en el punto medio del temporizador activo (1,5 minutos por defecto) sobre el estado de la ruta. El Router B responde (con un SIA-Reply) que él está buscando una ruta de reemplazo. Al recibir este paquete de respuesta SIA-Reply, el Router A valida el estado del router B y no termina la relación de vecino.

Mientras tanto, el router B enviará un máximo de tres SIA-Queries al Router C. Si se quedan sin

respuesta, el router B terminará la relación de vecino con Router C. Router B luego actualizará al Router A con un SIA-Reply indicando que la red 10.1.1.0/24 es inalcanzable. Los Routers A y B eliminarán la ruta activa de sus tablas de topología. La relación de vecino entre los Routers A y B se mantiene intacta.

Rango de Consulta (Query Range) EIGRP

Limitar el alcance de la propagación de consulta a través de la red (el rango de consulta), también conocido como alcance de consulta, ayuda a reducir la incidencia de SIA. Mantener los paquetes de consulta cerca de la fuente reduce la posibilidad de que un falla aislada en otra parte de la red vaya a restringir el proceso de convergencia (query/reply). En esta sección se presenta un ejemplo que examina la forma de gestionar la gama de consultas.

Los routers remotos raramente necesitan saber todas las rutas anunciadas en toda la red. Por lo tanto, es responsabilidad del administrador de la red ver cuál información es necesaria para adecuadamente enrutar el tráfico de usuarios y considerar el uso de una ruta por defecto.

Por ejemplo, en la figura 2-44, el router B se da cuenta de la pérdida de la red 10.1.8.0 y envía una consulta a los Routers A, C, D y E. A su vez, estos routers envían consultas a sus vecinos, en busca de una ruta hacia 10.1.8.0. Cuando se inicia el proceso de consulta, cada ruta recibe consultas duplicadas debido a la topología redundante. Por lo tanto, no sólo son los routers remotos necesarios para responder a las preguntas de las oficinas regionales, pero también continúan la búsqueda reflejando las consultas de vuelta hacia el router de la otra oficina regional. Esto complica significativamente el proceso de convergencia en la red.

Figure 2-44. Effect of the EIGRP Update and Query Process.

En esta red de ejemplo con sólo dos routers regionales y tres routers remotos, el problema no puede ser muy significativo. En una red con cientos de oficinas remotas, el problema puede ser grave.

Examine el proceso de consulta para la subred de 10.1.8.0/24. Inicialmente, el router B anuncia 10.1.8.0/24 a todos los demás routers. El mejor camino para que el Router A llegue a 10.1.8.0/24 es a través del enlace Ethernet al router B. Los routers remotos (C, D y E) utilizan la conexión serie al router B como su ruta preferida para llegar a 10.1.8.0/24 pero aún aprenden sobre un camino alternativo a través de Router A. Para este ejemplo, supongamos que la métrica de EIGRP para Ethernet es de 1000, y la métrica de un enlace serie es 100000. La Tabla 2-11 muestra el contenido de la tabla de topología EIGRP en los routers IP C, D y E para la red 10.1.8.0/24. La Tabla 2-12 muestra el contenido de la tabla de topología EIGRP en IP del Router A para la red 10.1.8.0/24.

Tenga en cuenta que los routers C, D, y E determinan que para la red 10.1.8.0/24, Router B es el sucesor y el Router A es un FS (debido a que la AD es de 2000 a través del router A, que es menor que el FD a través de Router B). Además, tenga en cuenta que el Router A no tiene un FS, ya que todos los caminos a través de los routers remotos tienen un AD más grande que el FD a través del router B.

Cuando el Router B pierde el camino a la red 10.1.8.0/24, éste consulta a todos sus cuatro vecinos. Cuando los sitios remotos reciben esta consulta, ellos automáticamente instalan la ruta a través del router A en sus tablas de enrutamiento y responden al Router B con su supuesta buena trayectoria a través de Router A. También eliminan el mal camino a través de Router B de sus tablas de topología.

El Router B ahora tiene las respuestas a tres de sus cuatro consultas, pero debe esperar hasta que el

Router A responda también.

Cuando el router A recibe la consulta del Router B para la red 10.1.8.0/24, el router A crea una consulta y la envía a Routers C, D, y E, ya que el Router A no tiene un FS pero sabe que existe un camino a través de cada sitio remoto para llegar a 10.1.8.0/24.

Los Routers C, D, y E reciben la consulta desde el Router A. Ahora saben que su camino a través de Router A no es bueno, así que ellos revisan sus tablas de topología de caminos alternativos. Sin embargo, ninguno de estos routers actualmente tiene otro camino, debido a que el router B sólo les ha informado de que no tiene una ruta de acceso a esta red. Debido a que los routers remotos no tienen una respuesta a la pregunta formulada por el Router A; los Routers C, D, y E crean una consulta y la envían a todos los vecinos, salvo el vecino (interfaz) que estos routers recibieron la consulta original. En este caso, los routers remotos enviar la consulta sólo al Router B.

El Router B aprende de estas consultas que ninguno de los routers remotos tiene una ruta a la red 10.1.8.0/24, pero no se puede responder que no se sabe de un camino, porque el router B está esperando por Router A para responder a una consulta. El Router A está a la espera, ya sea para que el Router C, D o E responda a su consulta, y estos sitios remotos están esperando el router B para responder a sus consultas. Debido a que el Router B envía la primera consulta, su temporizador SIA vence primero, y el Router B alcanza primero el estado de SIA para la red 10.1.8.0/24 (en 3 minutos de forma predeterminada). Router B restablece su relación de vecino con el Router A. En cuanto la relación de vecino se cae, el router B puede responder a Routers C, D, y E, inmediatamente, diciendo que el router B no tiene una ruta a 10.1.8.0/24. Routers C, D y E pueden entonces responder a Router A que no tienen un camino.

Después de que la relación de vecino EIGRP entre los Routers A y B se restablece (justo después de que la adyacencia se restablece), el Router B, que ya no tiene una ruta a 10.1.8.0/24, no pasa la red 10.1.8.0/24 a Router A. El Router A se entera de que los sitios remotos no tienen un camino hacia 10.1.8.0/24 y la nueva relación con el router B no incluye una ruta a 10.1.8.0/24, por lo que el Router A elimina la red 10.1.8.0 de su tabla de topología EIGRP IP.

En la red de la figura 2-44, la redundancia es proporcionada con los enlaces dobles desde las oficinas regionales a los sitios remotos. El arquitecto de la red no tiene la intención de que el tráfico vaya de una oficina regional a una oficina remota y volver a una oficina regional, pero lamentablemente esta es la situación.

Si los sitios remotos no suponen actuar como sitios de tránsito entre los sitios regionales, los routers regionales se pueden configurar para anunciar sólo una ruta por defecto a los routers remotos, y los routers remotos pueden ser configurados para anunciar sólo sus redes stub conectadas directamente a los routers regionales, para reducir la complejidad y la tabla de topología EIGRP y el tamaño de la tabla de enrutamiento.

Las siguientes secciones describen otras soluciones para limitar el rango de consulta EIGRP.

Limitando el rango de consultas en EIGRP

El administrador de red debe determinar la información necesaria para enrutar apropiadamente el tráfico de usuarios al destino correcto. La cantidad de información necesaria por los routers remotos

para lograr el nivel deseado de selección de ruta debe ser equilibrado contra el ancho de banda utilizado para propagar esta información. Para lograr la máxima estabilidad y escalabilidad, los routers remotos pueden utilizar una ruta por defecto para llegar al nucleo (core). Si algunas redes específicas necesitan el conocimiento de más rutas para garantizar la selección de la ruta óptima, el administrador debe determinar si los beneficios de propagar la información de enrutamiento adicional superan el ancho de banda adicional que se requiere para lograr este objetivo.

En una red bien diseñada, cada sitio remoto tiene enlaces WAN redundantes para separar a los sitios de distribución. Si ambos sitios de distribución pasan una ruta por defecto a los sitios remotos, los sitios remotos balancean la carga de todas las redes detrás de los routers del sitio de distribución. Esto maximiza la utilización del ancho de banda y permite que el router remoto utilice menos CPU y memoria, lo que significa que un router remoto más pequeño y menos costoso pueda ser utilizado en ese sitio.

Si el sitio remoto puede ver todas las rutas, el router puede seleccionar un camino que es la mejor manera de llegar a una determinada red. Sin embargo, en función del número de rutas en la interconexión de redes y la cantidad de ancho de banda de la conexión del sitio remoto a los sitios de distribución, este enfoque puede significar que se necesitan enlaces de mayor ancho de banda o grandes routers para manejar la sobrecarga adicional.

Después de determinar los requisitos mínimos de enrutamiento, se puede hacer más escalable EIGRP. Dos de las mejores opciones son las siguientes:

Configurar sumarización de rutas usando el comando “ïp summary-address eigrp” en la interface de salida de los routers apropiados.

Configurar los routers remotos como routers stub EIGRP.

Estos métodos se describen en las dos secciones siguientes.

Otros métodos para limitar el rango de consulta incluyen el filtrado de rutas y el filtrado de paquetes de interfaz. Por ejemplo, si las actualizaciones específicas de enrutamiento EIGRP son filtradas a un router y ese router recibe una consulta sobre esas redes filtrada (bloqueadas), el router indica que la red es inalcanzable y no se extiende más allá de la consulta.

Limitando Rango de Consultas con Sumarización

El resumen de ruta es más eficaz con una asignación de dirección conocida. Tener un diseño de red jerárquica de dos o de tres capas, con los routers que resume entre las capas contribuye en gran medida al flujo de tráfico y a la distribución de ruta.

La figura 2-45 muestra la topología de una red interna no escalable en cuyas direcciones (subredes) son o aleatoriamente asignadas o asignadas por requerimientos históricos. En este ejemplo, varias subredes de diferentes redes principales se encuentran en cada nube, requiriendo muchas rutas de subred a ser inyectadas en el núcleo. Además, debido a la asignación aleatoria de direcciones, el tráfico de consulta puede no estar localizada en cualquier parte de la red, aumentando así el tiempo de convergencia. La administración y solución de problemas también son más complejos en este escenario.

Figure 2-45. Nonscalable Internetwork.

La figura 2-46 ilustra una red mejor diseñada. Las direcciones de subred de las principales redes individuales se localizan dentro de cada nube, permitiendo rutas de resumen que se inyecta en el núcleo. Como un beneficio adicional, las rutas de resumen actúan como una frontera para las consultas generadas por un cambio de topología.

Figure 2-46. Scalable Internetwork.

La figura 2-47 muestra una red de ejemplo para ilustrar cómo el resumen de EIGRP puede limitar el rango de la consulta. El Router B envía una ruta resumen de 172.30.0.0/16 a Router A. Cuando la red 172.30.1.0/24 se cae, el router A recibe una consulta desde el Router B sobre esa red. Debido a que el Router A ha recibido sólo una ruta resumen, esa red específica no está en su tabla de enrutamiento y así que Router A responde a la consulta con un mensaje de "red 172.30.1.0/24 inalcanzable" y no se extiende más allá de la consulta. Observe que la consulta se detiene en el router que recibe la ruta resumen (Router A en este ejemplo), no en el router que envía la ruta resumen (Router B en este ejemplo). Un router remoto extiende la consulta sobre una red sólo si tiene una coincidencia exacta para la red en su tabla de enrutamiento.

Figure 2-47. EIGRP Summarization Can Limit Query Range.

La Sumarización minimiza el tamaño de la tabla de enrutamiento, lo que significa menos uso de CPU y memoria para administrar y menos ancho de banda para transmitir la información. La sumarización también reduce la posibilidad de que las redes se vuelvan SIA, ya que reduce el número de routers que ven cada consulta, por lo que la probabilidad de una consulta encontrarse con uno de estos problemas también se reduce.

La figura 2-48 ilustra cómo el resumen de ruta puede afectar a la red que se muestra anteriormente en la Figura 2-44. El comando “ip summary-address eigrp” es configurado en las interfaces de salida de los Routers A y B de manera que los Routers A y B anuncian la ruta de resumen 10.0.0.0/8 a la Routers remotos C, D y E.

Figure 2-48. Limiting Updates and Queries Using Summarization.

La red 10.1.8.0/24 no es publicada a los routers remotos. Por lo tanto, los routers remotos (C, D, y E) no extienden las consultas sobre la red 10.1.8.0/24 de nuevo a los otros routers regionales, la reducción del tráfico de convergencia (preguntas y respuestas) causada por la topología redundante. Cuando los Routers A y B envían la consulta para 10.1.8.0/24 a Routers C, D, y E, estos routers responden inmediatamente que el destino es inalcanzable. Las consultas para las redes perdidas 10.1.8.0/24 no son propagadas más allá de los sitios remotos, evitando que los Routers A y B se convierta en SIA esperando el proceso de consulta para recibir todas las respuestas.

Limitando el rango de Consultas usando Stub

Las topologías de red hub-and-spoke comúnmente utilizan el enrutamiento “stub”. En esta topología, el router remoto reenvía todo el tráfico que no es local a un router hub, por lo que el router remoto no necesita retener una tabla de enrutamiento completa. Generalmente, el router hub necesita enviar sólo una ruta por defecto a los routers remotos.

En una topología hub-and-spoke, teniendo una tabla de enrutamiento completa en los routers remotos no sirve a ningún propósito funcional debido a que la ruta de acceso a la red corporativa e Internet es siempre a través del router hub. Además, tener una tabla de enrutamiento completa en los routers spoke

aumenta la cantidad de memoria necesaria.

El tráfico procedente de un router hub no debería utilizar un router remoto como un camino de tránsito. Una conexión típica desde un router hub a un router remoto tiene significativamente menos ancho de banda que una conexión en el núcleo de la red. El intento de utilizar la conexión a un router remoto como ruta de tránsito por lo general se traduce en congestión excesiva. La función de enrutamiento Stub EIGRP puede evitar este problema restringiendo al router remoto de la publicidad de rutas del router hub de nuevo a otros routers hub. Por ejemplo, en la figura 2-48, las rutas reconocidas por el router remoto desde el Router hub A no son publicadas al hub del Router B. Debido a que el router remoto no publica las rutas hub de nuevo a los routers hub, los routers hub no utilizan la routers remotos como una ruta de tránsito. Usando la función de enrutamiento stub de EIGRP mejora la estabilidad de la red, reduce la utilización de recursos y simplifica la configuración del router stub.

La característica Stub de EIGRP fu primero introducida en el IOS de Cisco Release 12.0(7)T.

Sólo los routers remotos se configuran como stubs. La función de stub no impide que rutas sean anunciadas al router remoto.

Un router stub indica en el paquete de saludo a todos los routers vecinos su estatus como un router stub. Cualquier router que reciba un paquete informandole sobre el estado de stub de su vecino no consulta el router stub para ninguna ruta. Por lo tanto, un router que tenga un par stub no consulta ese par.

Así, es importante tener en cuenta que los routers stub no son consultados. En lugar de ello, los routers hub conectados al router stub responden la consulta en nombre del router stub.

La función de enrutamiento stub EIGRP también simplifica la configuración y mantenimiento de redes de hub-and-spoke, mejora la estabilidad de la red y reduce el uso de recursos. Cuando el enrutamiento stub es activado en configuraciones remotas dual-homed, no se tiene que configurar el filtrado en los routers remotos para evitar que aparezcan como rutas de tránsito a los routers hub.

Precaución: el enrutamiento stub de EIGRP se debe utilizar solamente en los routers stub. Un router Stub es definido como un router conectado al núcleo de la red o capa hub, y a través del cual el tráfico que viaja al nucleo no debería fluir. Un router stub debería tener sólo los routers hub para los vecinos EIGRP. Igonar esta restricción causa comportamientos indeseables.

Al planificar la configuración Stub de EIGRP, siga los siguientes pasos:

• Examine la topología y la configuración existente de EIGRP. • Definir los requisitos, entre ellos que los routers se configuran como routers stub, y si la redistribución y sumarización será desarrollada. • Diseñar la red. • Crear un plan de implementación. • Configurar y verificar la configuración.

Para configurar un router como un stub de EIGRP, use el comando de configuración de router “eigrp stub [receive-only | connected | static | summary | redistributed]”. Un router configurado como un Stub con este comando, comparte información sobre rutas conectadas y resumen con todos los routers vecinos por defecto. La tabla 2-13 describe las cuatro palabras claves opcionales que pueden ser usadas con el comando para modificar este comportamiento.

Table 2-13. eigrp stub Command Parameters

Los parámetros opcionales en este comando pueden ser usados en cualquier combinación, con la excepción de la palabra clave “receive-only”. Si cualquiera de las palabras claves (excepto “receive-only”) es usado individualmente, las rutas conectadas y resumen no son enviadas automáticamente.

En el ejemplo 2-59, el comando “eigrp stub” es usado para configurar al router como un stub que publica rutas conectadas y de resumen.

Example 2-59. eigrp stub Command to Advertise Connected and Summary RoutesRouter(config)#router eigrp 1Router(config-router)#network 10.0.0.0Router(config-router)#eigrp stub

En el Ejemplo 2-60, el comando “eigrp stub receive-only” se utiliza para configurar el router como un stub por el cual rutas conectadas, resumen y estáticas no se envían.

Example 2-60. eigrp stub Command to Receive Only RoutesRouter(config)#router eigrp 1Router(config-router)#network 10.0.0.0 eigrpRouter(config-router)#eigrp stub receive-onlyLa función stub de EIGRP no habilita el resumen de ruta en el router hub. El administrador de red

debería configurar el resumen de rutas en los routers hub si se desea. Cisco recomienda altamente utilizar tanto resumen de ruta EIGRP como características stub EIGRP para proporcionar la mejor escalabilidad.

Si se requiere una red stub verdadera, el router hub se puede configurar para enviar una ruta por defecto a los routers spoke. Este enfoque es el más simple y se ahorra el máximo ancho de banda y memoria en los routers spoke.

Nota: Aunque EIGRP es un protocolo de enrutamiento sin clase, tiene un comportamiento con clase por defecto, como tener el resumen automático de forma predeterminada. Al configurar el router hub para enviar una ruta por defecto al router remoto, asegúrese del comando “ip classless” en el router remoto. Por defecto, el comando “ip classless” está habilitado en todas las imágenes de IOS de Cisco que admiten la función de enrutamiento stub de EIGRP.

La figura 2-49 ilustra cómo el uso de la función de stub de EIGRP afecta a la red que se muestra anteriormente en la Figura 2-44. Cada uno de los routers remotos se configura como un stub. Las consultas para la red 10.1.8.0/24 no se envían a los routers C, D, o E, reduciendo así el ancho de banda utilizado y la oportunidad de las rutas sean SIA (Stuck-In-Active).

Figure 2-49. Limiting Updates and Queries Using the EIGRP Stub Feature.

El uso de la función stub de EIGRP en los sitios remotos permite a los sitios hub (oficinas regionales) inmediatamente responder consultas sin propagar las consultas a los sitios remotos, ahorrando ciclos de CPU y ancho de banda, y disminuyendo tiempos de convergencia, incluso cuando los sitios remotos son de dual-homed para dos o más sitios hub.

La figura 2-50 ilustra otro ejemplo de la red; El ejemplo 2-61 se muestra parte de la configuración del Router B.

Figure 2-50. Network for eigrp stub Command Example.

Example 2-61. Configuration for Router B in Figure 2-50

RouterB#show running-config<output omitted>ip route 10.1.4.0 255.255.255.0 10.1.3.10!interface ethernet 0 ip address 10.1.2.1 255.255.255.0!interface ethernet 1 ip address 10.1.3.1 255.255.255.0! interface serial 0 ip address 10.2.2.3 255.255.255.254 ip summary-address eigrp 100 10.1.2.0 255.255.254.0!router eigrp 100 redistribute static 1000 1 255 1 1500 network 10.2.2.2 0.0.0.1 network 10.1.2.0 0.0.0.255<output omitted>

Usando este ejemplo de red y configuración, considere cuales redes Router B publicará a Router A cuando las opciones varias del comando “eigrp stub” sean también configuradas en Router B:

Con el comando “eigrp stub connected” Router B publicará sólo 10.1.2.0/24 a Router A. Note que aunque 10.1.3.0/24 es también una red conectada, no es publicada a Router A ya que no está anunciada en un comando “network” y las rutas conectadas no son redistribuidas.

Con el comando “eigrp stub summary”, Router B publicará sólo 10.1.2.0/23, la ruta resumen que es configurada en el router, al router A.

Con el comando “eigrp stub static”, Router B publicará sólo 10.1.4.0/24, la ruta estática que es configurada en el router, al router A (note que el comando “redistribute static” es configurado en el Router B). Nota: Sin la opción “static”, EIGRP no enviará las rutas estáticas, incluidas las rutas estáticas internas que normalmente se redistribuyen automáticamente.

Con el comando “eigrp stub receive-only”, Router B no publicará nada al Router A. Con el comando “eigrp stub redistributed”, Router B publicará sólo 10.1.4.0/24, la ruta

estática redistribuida, al Router A.

APAGADO ORDENADO (Graceful Shutdown)

El apagado ordenado, implementado con la característica “goodbye message”, está disenado para mejorar la convergencias de las redes EIGRP.

En la figura 2-51, el Router A está utilizando el router B como el sucesor de varias rutas. Router C es el sucesor factible para las mismas rutas. Router B normalmente no le diría a Router A si el proceso EIGRP en el router B se fuera abajo (por ejemplo, si el router B se está reconfigurando). Router A tendría que esperar a que su temporizador de espera expire antes de que descubriera el cambio y reaccione a éste. Los paquetes enviados durante este tiempo se perderían.

Figure 2-51. Graceful Shutdown Causes the Router to Say Goodbye.

Con “Graceful Shutdown”, se emite un mensaje de adiós (goodbye message) cuando un proceso de enrutamiento EIGRP es apagado, para informar a sus pares adyacentes acerca de dicho cambio en la topología inminente. Esta característica permite el soporte a los pares EIGRP para sincronizar y volver a calcular las relaciones de vecinos de manera más eficiente de lo que ocurriría si los pares descubrieran el cambio en la topología después de expirado el temporizador de espera.

El mensaje “Goodbye” es soportado en el software IOS de Cisco Release 12.3(2), 12.3(3)B y 12.3(2)T y posteriores.

Curiosamente, los mensajes de despedida se envían en paquetes de saludo. EIGRP envía un mensaje de despedida de interfaz con todos los valores K establecidos a 255 cuando se tumban todos los pares sobre una interfaz.

El siguiente mensajes es mostrado por routers que soportan mensajes goodbye cuando uno es recibido:*Apr 26 13:48:42.523: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1(Ethernet0/0) is down: Interface Goodbye received

Un router de Cisco que ejecuta una versión de software que no es compatible con el mensaje de despedida se malinterpreta el mensaje como un valor K desajustado y por lo tanto muestra el siguiente mensaje:

*Apr 26 13:48:41.811: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1(Ethernet0/0) is down: K-value mismatch

Nota: La recepción de un mensaje de despedida por un par no soportado no interrumpe el funcionamiento normal de la red. El par nonsupporting finalizará la sesión cuando el temporizador de espera expira. Los routers de envío y recepción reconvergerán normalmente después de las recargas de remitente.

Nota: Un router EIGRP enviará un mensaje de despedida en una interfaz si el comando “network” (bajo el proceso de EIGRP) que abarca la red sobre esa interfaz es eliminada (con el comando no network). Un router EIGRP envía un mensaje de despedida en todas las interfaces, si el proceso EIGRP está apagado (con el comando no router eigrp). Un router EIGRP no, sin embargo, enviará un mensaje de despedida si una interfaz se apaga o el router se vuelve a cargar.