¿Tiene una cuenta?
Uno de los aspectos intrigantes de los routers de Cisco, en especial para quienes son nuevos en el routing, es cómo el router elige la mejor ruta entre las presentadas por los protocolos de routing, la configuración manual y demás medios. Si bien la selección de rutas es mucho más simple de lo que imagina, entenderla por completo requiere un cierto conocimiento del funcionamiento de los routers de Cisco.
No hay requisitos previos específicos para este documento.
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.
Existen tres procesos relacionados con la construcción y el mantenimiento de la tabla de ruteo de un router Cisco:
Varios procesos de ruteo, que generalmente ejecutan un protocolo de red (o ruteo), como el protocolo mejorado de ruteo de puerta de enlace interior (EIGRP), protocolo de la puerta de enlace marginal (BGP), sistema intermedio a sistema intermedio (IS-IS) y abrir primero el trayecto más corto (OSPF).
La tabla de ruteo, que acepta la información de procesos de ruteo y también responde las solicitudes de información de procesos de reenvío.
El proceso de reenvío solicita información de la tabla de routing para tomar una decisión de reenvío de paquetes.
Examinemos la interacción entre los protocolos de routing y la tabla de routing para entender cómo se genera la tabla de routing.
A continuación se presentan las consideraciones principales para la creación de la tabla de ruteo:
Distancia administrativa - Es la medida de confiabilidad del origen de la ruta. Si un router se entera sobre un destino desde más de un protocolo de ruteo, la distancia administrativa se compara y se da preferencia a los routers con distancia administrativa menor. En otras palabras, es la credibilidad de la fuente de las rutas.
Métricas - Ésta es una medida utilizada por el protocolo de ruteo para calcular el mejor trayecto hacia un destino si aprende trayectos múltiples hacia el mismo destino. Cada protocolo de routing utiliza una métrica diferente.
Longitud del prefijo
Dado que cada proceso de ruteo recibe actualizaciones junto con otra información, selecciona el mejor trayecto para un determinado destino e intenta instalar este trayecto en la tabla de ruteo. Por ejemplo, si el EIGRP aprende acerca de un trayecto hacia 10.1.1.0/24 y decide que éste es el mejor hacia este destino, intenta instalar el trayecto que ha aprendido dentro de la tabla de ruteo.
El router decide si instala o no las rutas que presentaron los procesos de ruteo en función de la distancia administrativa del router en cuestión. Si esta ruta tiene la menor distancia administrativa a este destino (cuando se compara con las otras rutas en la tabla), se instala en la tabla de ruteo. Si la ruta no coincide con la ruta con la mejor distancia administrativa, se rechaza la ruta.
Para entenderlo mejor, veamos un ejemplo. Supongamos que un router tiene cuatro procesos de routing en ejecución: EIGRP, OSPF, RIP e IGRP. Ahora, los cuatro procesos detectan varias rutas a la red 192.168.24.0/24 y cada uno ha elegido el mejor trayecto a la red conforme a sus métricas internas y sus procesos.
Cada uno de estos cuatro procesos intenta instalar la ruta hacia 192.168.24.0/24 en la tabla de routing. A cada uno de los procesos de ruteo se le asigna una distancia administrativa, que se utiliza para decidir qué ruta se instalará.
Distancias administrativas predeterminadas | |
---|---|
Conectado | 0 |
Estática | 1 |
eBGP | 20 |
EIGRP (interno) | 90 |
IGRP | 100 |
OSPF | 110 |
IS-IS | 115 |
RIP | 120 |
EIGRP (externo) | 170 |
iBGP | 200 |
Ruta de resumen EIGRP | 5 |
Dado que la ruta EIGRP interna tiene la menor distancia administrativa (cuanto menor es la distancia administrativa, mayor es la preferencia), está instalada en la tabla de ruteo.
¿Qué hacen los otros protocolos, RIP, IGRP y OSPF, con las rutas que no fueron instaladas? ¿Qué ocurre si falla el trayecto preferido, obtenido de EIGRP? El software Cisco IOS® utiliza dos métodos para solucionar este problema: El primero es hacer que cada intento de proceso de ruteo instale sus mejores rutas periódicamente. Si la ruta preferida falla, la siguiente mejor ruta (de acuerdo con la distancia administrativa) prosperará en el siguiente intento. La otra solución consiste en que el protocolo de ruteo que no logró instalar su ruta en la tabla sea sostenido por la ruta y le informe al proceso de la tabla de ruteo que notifique las fallas del mejor trayecto.
Para protocolos sin tabla propia de información de ruteo, como IGRP, se usa el primer método. Cada vez que IGRP recibe una actualización sobre una ruta, intenta instalar la información actualizada en la tabla de routing. Si ya hay una ruta en este mismo destino en la tabla de ruteo, la instalación falla.
Para protocolos que tienen su propia base de datos con información de ruteo, como EIGRP, IS-IS, OSPF, BGP y RIP, se registra una ruta de respaldo cuando falla el primer intento de instalar la ruta. Si la ruta instalada en la tabla de routing falla por alguna razón, el proceso de mantenimiento de la tabla de routing invoca cada proceso de protocolo de routing con una ruta de respaldo registrada y solicita la reinstalación de la ruta en la tabla de routing. Si hay protocolos múltiples con rutas de respaldo registradas, la ruta preferida se elige en función de la distancia administrativa.
Puede que la distancia administrativa predeterminada no sea siempre la correcta para su red. Es posible que desee ajustarla para que se prefieran, por ejemplo, las rutas del RIP sobre las rutas del IGRP. Antes de explicar cómo ajustar las distancias administrativas, tenemos que ver lo que implica cambiar la distancia administrativa.
El cambio de la distancia administrativa en los protocolos de ruteo puede ser muy peligroso. Cambiar las distancias predeterminadas puede generar bucles de routing y otras singularidades en la red. Le recomendamos que cambie la distancia administrativa con precaución y sólo después de haber pensado qué es lo que quiere lograr y cuáles serán las secuencias de sus acciones.
Para los protocolos completos, modificar la distancia es relativamente fácil; simplemente configure la distancia utilizando el comando distance en el modo de subconfiguración del proceso de routing. También puede cambiar la distancia para rutas que se conocen sólo de un origen en algunos protocolos, y puede modificar la distancia en sólo algunas rutas. Para obtener más información, consulte Ejemplo de configuración de ajuste de la distancia administrativa para la selección de rutas en routers Cisco IOS.
Para las rutas estáticas, puede modificar la distancia de cada ruta ingresando una distancia después del comando ip route:
ip route network subnet mask next hop distance
No es posible cambiar la distancia administrativa para todas las rutas estáticas en forma simultánea.
Las rutas se eligen y crean en la tabla de ruteo basada en la distancia administrativa del protocolo de ruteo. Las rutas detectadas a partir del protocolo de routing con la mínima distancia administrativa se instalan en la tabla de routing. Si hay trayectos múltiples hacia el mismo destino desde un solo protocolo de ruteo, entonces, los trayectos múltiples tendrían la misma distancia administrativa y se elige el mejor trayecto basándose en las métricas. La métrica son valores asociados con rutas específicas, clasificándolos de los más a los menos preferidos. Los parámetros utilizados para determinar las métricas difieren para los diversos protocolos de routing. Se selecciona el trayecto de menor métrica como trayecto óptimo y se instala en la tabla de ruteo. Si existen múltiples trayectos al mismo destino con métricas iguales, el equilibrio de carga se realiza sobre estos trayectos de igual costo. Para obtener más información sobre el equilibrio de carga, consulte ¿Cómo funciona el equilibrio de carga?
Miremos otro escenario para ver cómo el router maneja otra situación común: las longitudes de prefijo variables. Suponga, de nuevo, que un router está ejecutando cuatro procesos de ruteo y que cada proceso ha recibido estas rutas:
EIGRP (interno): 192.168.32.0/26
RIP: 192.168.32.0/24
OSPF (Abrir la ruta más corta en primer lugar) 192.168.32.0/19
¿Cuál de estas rutas será instalada en la tabla de ruteo? Puesto que las rutas internas de EIGRP tienen la mejor distancia administrativa, es fácil suponer que se instalará la primera. Sin embargo, dado que cada una de estas rutas tiene una longitud de prefijo (máscara de subred) diferente, se las considera destinos distintos y se todas instalan en la tabla de routing.
Veamos cómo el motor de reenvío utiliza la información de la tabla de ruteo para tomar decisiones de reenvío.
Veamos las tres rutas que instalamos recién en la tabla de ruteo y cómo se ven en el router.
router# show ip route .... D 192.168.32.0/26 [90/25789217] via 10.1.1.1 R 192.168.32.0/24 [120/4] via 10.1.1.2 O 192.168.32.0/19 [110/229840] via 10.1.1.3 ....
Si un paquete llega a una interfaz de router destinada para 192.168.32.1, ¿Qué ruta elegiría el router? Depende de la longitud del prefijo o del número de bits establecidos en la máscara de subred. Siempre son preferibles prefijos más largos antes que cortos en el reenvío de un paquete.
En este caso, un paquete destinado a 192.168.32.1 se direcciona a 10.1.1.1 porque 192.168.32.1 está dentro de la red 192.168.32.0/26 (192.168.32.0 a 192.168.32.63). También cae dentro de las otras dos rutas disponibles pero el 192.168.32.0/26 tiene el prefijo más largo dentro de la tabla de ruteo (26 bits frente a 24 o 19 bits).
De la misma manera, si un paquete con destino a 192.168.32.100 llega a una de las interfaces del router, éste es reenviado a 10.1.1.2, porque 192.168.32.100 no entra en 192.168.32.0/26 (192.168.32.0 a 192.168.32.63), pero sí entra en el destino 192.168.32.0/24 (192.168.32.0 a 192.168.32.255). Nuevamente, también cae dentro del alcance abarcado por 192.168.32.0/19, pero 192.168.32.0/24 posee una longitud de prefijo más extensa.
En general, es confuso el momento en que el comando de configuración ip classless entra en los procesos de ruteo y reenvío. En la realidad, el IP sin clase solo afecta el funcionamiento de los procesos de reenvío en IOS; no afecta la manera en que se genera la tabla de routing. Si el IP sin clases no está configurado (con el comando no ip classless), el router no reenviará los paquetes a las superredes. A modo de ejemplo, coloquemos nuevamente tres rutas en la tabla de ruteo y enrutemos paquetes a través del router.
Nota: Si la ruta supernet o predeterminada se aprende a través de IS-IS o OSPF, el comando de configuración no ip classless se ignora. En este caso, el comportamiento de switching de paquetes funciona como si se hubiera configurado como ip classless.
router# show ip route .... 172.30.0.0/16 is variably subnetted, 2 subnets, 2 masks D 172.30.32.0/20 [90/4879540] via 10.1.1.2 D 172.30.32.0/24 [90/25789217] via 10.1.1.1 S* 0.0.0.0/0 [1/0] via 10.1.1.3
Recordando que la red 172.30.32.0/24 incluye las direcciones 172.30.32.0 a 172.30.32.255 y la red 172.30.32.0/20 incluye las direcciones 172.30.32.0 a 172.30.47.255, podemos intentar conmutar tres paquetes a través de esta tabla de routing y ver cuáles son los resultados.
Un paquete destinado a 172.30.32.1 se reenvía a 10.1.1.1, puesto que es el prefijo de máxima longitud coincidente.
Un paquete destinado a 172.30.33.1 se reenvía a 10.1.1.2, porque es la coincidencia con el prefijo de máxima longitud.
Un paquete destinado a 192.168.10.1 se reenvía a 10.1.1.3. debido a que esta red no existe en la tabla de ruteo, este paquete se reenvía a la ruta predeterminada.
Un paquete destinado a 172.30.254.1 se descarta.
La respuesta asombrosa de estos cuatro procesos es la del último paquete, que se descarta. Se suprime porque su destino, 172.30.254.1, está dentro de una red mayor conocida, 172.30.0.0/16, pero el router no conoce esta subred específica dentro de esa red principal.
Esta es la esencia del routing con clase: Si se conoce una parte de la red principal pero se desconoce la subred hacia la que se destinan los paquetes dentro ella, el paquete se descarta.
El aspecto más confuso de esta regla es que el router sólo utiliza la ruta predeterminada si la red de destino principal no existe en la tabla de ruteo.
Esto puede causar problemas en una red donde un sitio remoto, con una conexión con el resto de la red, no ejecuta ningún protocolo de ruteo, según se muestra.
El router del sitio remoto se configura así:
interface Serial 0 ip address 10.1.2.2 255.255.255.0 ! interface Ethernet 0 ip address 10.1.1.1 255.255.255.0 ! ip route 0.0.0.0 0.0.0.0 10.1.2.1 ! no ip classless
Con esta configuración, los hosts en el sitio remoto pueden alcanzar los destinos en Internet (a través de la nube 10.x.x.x) pero no los destinos dentro de la nube 10.x.x.x, que es la red corporativa. Debido a que el router remoto conoce algunas partes de la red 10.0.0.0/8, las dos subredes conectadas directamente y ninguna otra subred de 10.x.x.x, se asume que estas otras subredes no existen y pierden cualquier paquete destinado a ellas. Sin embargo, el tráfico dirigido a Internet no siempre tiene un destino en el rango de direcciones 10.x.x.x y, por lo tanto, es desviado correctamente a través de la ruta predeterminada.
La configuración de ip classless en el router remoto soluciona este problema al permitir que el router ignore los límites con clase de las redes en su tabla de ruteo y que, simplemente, enrute la coincidencia de prefijo de máxima longitud que encuentre.
En resumen, si se toma una decisión de reenvío, en realidad incluye tres conjuntos de procesos: los protocolos de routing, la tabla de routing y el proceso real que toma la decisión de reenvío y conmuta los paquetes. Estos tres conjuntos de procesos están ilustrados debajo, junto con su relación.
La correspondencia de prefijo más extenso siempre prevalece entre las rutas efectivamente instaladas en la tabla de ruteo, mientras que el protocolo de ruteo con la menor distancia administrativa siempre prevalece cuando se instalan rutas en la tabla de ruteo.