Protocolos de enrutamiento interno (IGP). EGP: protocolos de puerta de enlace externa
Enrutamiento dinámico. Primer conocido.
Para comprender el tema de la conversación, primero debe leer los artículos sobre enrutadores y enrutamiento que se encuentran cerca, de lo contrario corre el riesgo de no ingresar.
Digamos que tenemos una cuadrícula simple como esta:
Dos enrutadores y cinco redes
De forma predeterminada, dada una topología de red determinada, el enrutador "izquierdo" tendrá entradas en su tabla de enrutamiento solo para tres redes conectadas directamente a él: 192.168.1.0/24 , 172.20.0.0/16 Y 192.168.100.0/30 . Del mismo modo, el enrutador "correcto" sólo conocerá las redes: 192.168.2.0/24 , 10.0.0.0/8 Y 192.168.100.0/30 . Y si intentamos desde la red 172.20.0.0/16 acceder a la red 192.168.2.0/24, no obtendremos respuesta. Por supuesto, podemos proporcionar a los enrutadores rutas estáticas o rutas estándar (también conocidas como rutas predeterminadas).
Parece una gran solución, ¿verdad? Pero ¿qué pasa si tenemos frente a nosotros esta topología de red?
Topología de red más compleja
Si en el ejemplo anterior era posible agregar rutas predeterminadas en una línea, o agregar dos rutas estáticas con dos comandos, hacer esto en cada dispositivo y todo funcionaría, entonces la situación aquí es más complicada. Las rutas predeterminadas son de poca utilidad aquí, y si resuelve el problema de enrutamiento utilizando rutas estáticas, necesitará registrar seis rutas estáticas en cada dispositivo, lo cual no es tan poco.
¿Qué pasa si tenemos una red de varias docenas de enrutadores, cada uno con una docena de redes? ¿Registrar un montón de rutas estáticas? Por supuesto que no. Aquí es donde se deben utilizar protocolos de enrutamiento dinámico.
Los protocolos de enrutamiento dinámico distribuyen periódicamente información almacenada en la tabla de enrutamiento de un enrutador a través de sus interfaces a otros enrutadores de la red, y también reciben y procesan mensajes similares de otros enrutadores de la red. Una vez recibidos dichos mensajes, el enrutador extrae de ellos rutas desconocidas y las agrega a su tabla de enrutamiento.
Además del hecho de que los protocolos de enrutamiento dinámico liberan a los ingenieros de redes de tener que conectar manualmente cientos de rutas estáticas, los protocolos de enrutamiento dinámico también permiten aumentar la tolerancia a fallas de la red al tener rutas de respaldo. Por ejemplo, si tenemos una red como la de la imagen de arriba. Y no fuimos perezosos y agregamos 6 rutas estáticas en cada dispositivo, entonces todo funcionará. Pero antes del primer accidente, si alguno de los enlaces entre los enrutadores desaparece, inmediatamente notaremos un mal funcionamiento en la red. Si utiliza enrutamiento dinámico, este problema no surgirá. En caso de accidente se utilizarán rutas de respaldo.
Ahora un poco de teoría. Todos los protocolos de enrutamiento dinámico se pueden dividir en protocolos de enrutamiento externos ( Protocolo de puerta de enlace interior, IGP) y puerta de enlace interna ( Protocolo de puerta de enlace exterior, E.G.P.). Los protocolos de puerta de enlace internos están diseñados para el enrutamiento dentro de sistemas autónomos, los protocolos de puerta de enlace externos están diseñados para el enrutamiento entre sistemas autónomos. En este caso, un sistema autónomo significa algo gran red, bajo control unificado. Por ejemplo, la red de una gran empresa.
Aplicación de IGP y EGP
Representantes de la familia de protocolos. IGP son los protocolos: RIP-1, RIP-2, IGRP, OSPF, EIGRP. A E.G.P. hay un protocolo - BGP.
Cuando se utilizan protocolos de enrutamiento dinámico, todas las rutas ubicadas en la tabla de enrutamiento reciben información adicional llamada métrica. La métrica permite a los enrutadores calcular la ruta más corta a la red deseada. De acuerdo con cómo se calcula la métrica, todos los protocolos de enrutamiento dinámico se pueden dividir en vector de distancia ( Vector de distancia), protocolos teniendo en cuenta el estado de los canales ( Estado de enlace) e híbrido.
En los pinchazos de enrutamiento por vector de distancia, el número de nodos intermedios. Cuantos menos nodos intermedios, más preferible será la ruta.
Alguna topología de red
Tengamos esta topología de red. De la red 1 a la red 2 hay dos rutas diferentes, la roja y la verde. En el caso de utilizar un protocolo de enrutamiento por vector de distancia, será más preferible una ruta dedicada verde, ya que contiene menos nodos intermedios en el camino hacia la red de destino. Ejemplos clásicos de protocolos de enrutamiento por vector de distancia son los RIP-1 Y RIP-2.
Los protocolos que tienen en cuenta el estado de los canales en su funcionamiento, por extraño que parezca, tienen en cuenta los estados de los canales y, en función de estos estados, calculan los valores de las métricas.
Veamos dos protocolos de enrutamiento dinámico: el Protocolo de puerta de enlace interior (IGP) y el Protocolo de puerta de enlace exterior (EGP).
Un sistema autónomo (AS), también conocido como dominio de enrutamiento, es un conjunto de enrutadores bajo una administración común. Ejemplos típicos son red interna empresas y red de proveedores de Internet. Dado que Internet se basa en el concepto de sistema autónomo, se requieren dos tipos de protocolos de enrutamiento: protocolos de enrutamiento internos y externos. Estos protocolos:
Protocolos de puerta de enlace interna ( IGP) utilizado para el enrutamiento del sistema intraautónomo - enrutamiento del sistema intraautónomo.
Protocolos de puerta de enlace externa ( E.G.P.) Se utiliza para el enrutamiento de sistemas interautónomos: una guía entre sistemas autónomos.
La figura es una representación simplificada de la diferencia entre IGP y EGP. El concepto de sistema autónomo se explicará con más detalle más adelante en esta sección.
Características de los protocolos de enrutamiento IGP y EGP
Los IGP se utilizan para realizar enrutamiento dentro de un dominio de enrutamiento, es decir. aquellas redes que están bajo el control de una única organización. Un sistema autónomo normalmente consta de muchas redes separadas, propiedad de empresas, escuelas y otras instituciones. IGP se utiliza para realizar enrutamiento dentro de un sistema autónomo y también para enrutar el tráfico dentro de las propias redes individuales. Por ejemplo, CENIC opera un sistema autónomo de escuelas, colegios y universidades de California. CENIC utiliza IGP para realizar enrutamiento dentro de su sistema autónomo para interconectar todas estas instituciones. Cada institución educativa también utiliza un IGP para enrutar el tráfico dentro de su propia red independiente. El IGP utilizado por cada entidad proporciona una mejor definición de rutas dentro de sus propios dominios de enrutamiento, al igual que el IGP utilizado por CENIC proporciona mejores rutas dentro del propio sistema autónomo. Los IGP para IP incluyen RIP, IGRP, EIGRP, OSPF e IS-IS.
Los protocolos de enrutamiento, o más precisamente los algoritmos utilizados por esos protocolos de enrutamiento, utilizan una métrica para determinar la mejor manera a la red. La métrica utilizada por el protocolo de enrutamiento RIP es el recuento de saltos, que es la cantidad de enrutadores que debe atravesar un paquete para llegar a otra red. OSPF utiliza ancho de banda para determinar la ruta más corta.
Los EGP, por otro lado, están diseñados para su uso entre diferentes sistemas autónomos que están bajo el control de diferentes administraciones. BGP es el único EGP viable actualmente y es el protocolo de enrutamiento utilizado por Internet. BGP es un protocolo de vector de ruta que puede utilizar muchos atributos diferentes para medir rutas. A nivel de ISP, a menudo hay cuestiones más importantes que simplemente elegir el camino más rápido. BGP se utiliza normalmente entre ISP y, a veces, entre una empresa y un ISP.
Protocolos de enrutamiento interno (IGP)
Los protocolos dinámicos se dividen en dos grupos:
- 1) EGP (Protocolo de puerta de enlace externa): protocolo de enrutamiento externo para uso entre sistemas autónomos (AS).
- 2) IGP (Protocolo de puerta de enlace interior): protocolo de enrutamiento interno para uso dentro del AS.
Los protocolos de enrutamiento internos analizados en esta subsección garantizan la sincronización de los enrutadores y las rutas configuradas entre ellos dentro de red local. La decisión de formular la mejor ruta se basa en métricas recopiladas mediante el intercambio de información con puertas de enlace de red vecinas. Dependiendo de las métricas y principios de construcción de rutas, los protocolos IGP se dividen a su vez en protocolos de vector de distancia (DVA) y protocolos de estado de enlace (LSP).
Protocolos de vector de distancia (DVA)
En los algoritmos de vector de distancia, cada enrutador transmite periódicamente un vector a través de la red, cuyos componentes son las distancias (medidas en una métrica particular) desde un enrutador determinado a todas las redes que conoce. Los paquetes de protocolo de enrutamiento se denominan comúnmente anuncios a distancia porque un enrutador los utiliza para anunciar a otros enrutadores lo que sabe sobre la configuración de la red.
Habiendo recibido de un determinado vecino un vector de distancias a las redes que conoce, el enrutador aumenta los componentes del vector en la distancia desde él hasta este vecino. Además, complementa el vector con información sobre otras redes que conoce y que conoció directamente (si están conectadas a sus puertos) o mediante anuncios similares de otros enrutadores. El enrutador envía el valor del vector actualizado a sus vecinos. En última instancia, cada enrutador aprende a través de los enrutadores vecinos información sobre todas las redes presentes en la red compuesta y las distancias a ellas.
La desventaja de los algoritmos de vectores de distancia es que sólo funcionan bien en espacios relativamente pequeños. redes informáticas. Dado que los enrutadores intercambian constantemente vectores de distancia, lo que provoca la obstrucción de las líneas de comunicación. tráfico de difusión V grandes redes. Otra desventaja de este algoritmo La razón es que no siempre responde correctamente a los cambios en la configuración de la red, ya que los enrutadores solo transmiten información generalizada, un vector de distancias, lo que lleva al hecho de que los enrutadores no contienen una idea específica de la topología de las conexiones. .
Protocolos basados en algoritmo de vector distancia:
- 1) RIP es un protocolo que opera en secciones de tránsito como métrica de enrutamiento. Cantidad máxima Los saltos permitidos en RIP son 15 (la métrica 16 significa "métrica infinitamente grande"). Cada enrutador RIP transmite por defecto su propio mesa completa enrutamiento una vez cada 30 segundos, cargando bastante las líneas de comunicación de baja velocidad;
- 2) EIGRP es un protocolo de enrutamiento desarrollado por Cisco basado en el protocolo IGRP de la misma empresa. Al calcular la métrica, se utiliza el ancho de banda mínimo para una ruta determinada (y no la suma de precios (costo) como en el caso de OSPF), lo que permite determinar con mayor precisión la ruta (ruta) más rentable.
Así que comencemos.
Artículos y vídeos sobre cómo configurar montañas OSPF. Hay muchas menos descripciones de principios operativos. En general, lo que pasa aquí es que OSPF se puede configurar simplemente según los manuales, sin siquiera conocer los algoritmos SPF y los LSA incomprensibles. Y todo funcionará e incluso, muy probablemente, funcionará perfectamente: para eso está diseñado. Es decir, no es como con las VLAN, donde había que conocer la teoría hasta el formato del encabezado.
Pero lo que distingue a un ingeniero de un informático es que comprende por qué su red funciona como lo hace y sabe, no peor que el propio OSPF, qué ruta elegirá el protocolo.
En el marco del artículo, que en este momento ya tiene 8.000 caracteres, no podremos profundizar en la teoría, pero sí consideraremos los puntos fundamentales.
Es muy simple y claro, por cierto, está escrito sobre OSPF en xgu.ru o en la Wikipedia en inglés.
Entonces, OSPFv2 funciona sobre IP y, específicamente, está diseñado solo para IPv4 (OSPFv3 no depende de protocolos de capa 3 y, por lo tanto, puede funcionar con IPv6).
Veamos cómo funciona usando el ejemplo de esta red simplificada:
Para empezar hay que decir que para que se desarrolle una amistad (relación de adyacencia) entre routers se deben cumplir las siguientes condiciones:
1) se deben configurar los mismos ajustes en OSPF Hola intervalo en aquellos enrutadores que están conectados entre sí. De forma predeterminada, son 10 segundos en redes de transmisión como Ethernet. Este es un tipo de mensaje KeepAlive. Es decir, cada 10 segundos, cada enrutador envía un paquete de saludo a su vecino para decir: "Oye, estoy vivo".
2) Debe ser el mismo Intervalo muerto sobre ellos. Normalmente son 4 intervalos de saludo: 40 segundos. Si no se recibe ningún saludo del vecino durante este tiempo, se considera inalcanzable y PANIC comienza el proceso de reconstruir la base de datos local y enviar actualizaciones a todos los vecinos.
3) Las interfaces conectadas entre sí deben estar en una subred,
4) OSPF le permite reducir la carga en la CPU de los enrutadores dividiendo el Sistema Autónomo en zonas. Así que aquí está números de zona también debe coincidir
5) Cada enrutador que participa en el proceso OSPF tiene su propio único identificador - ID del enrutador. Si no lo cuida, el enrutador lo seleccionará automáticamente en función de la información sobre las interfaces conectadas (la dirección más alta se selecciona de las interfaces activas en el momento en que comienza el proceso OSPF). Pero nuevamente, un buen ingeniero tiene todo bajo control, por lo que generalmente se crea una interfaz Loopback, a la que se le asigna una dirección con una máscara /32 y esto es lo que se asigna al ID del enrutador. Esto puede resultar útil para el mantenimiento y la resolución de problemas.
6) El tamaño de MTU debe coincidir
1) Calma. Estado OSPF - ABAJO
En este breve momento, no sucede nada en la red: todos guardan silencio.
2) El viento está aumentando: el enrutador envía paquetes de saludo a la dirección de multidifusión 224.0.0.5 desde todas las interfaces donde se ejecuta OSPF. El TTL de dichos mensajes es uno, por lo que solo los recibirán los enrutadores ubicados en el mismo segmento de red. R1 entra en estado INICIAR.
Los paquetes contienen la siguiente información:
- ID del enrutador
- Hola intervalo
- Intervalo muerto
- Vecinos
- Máscara de subred
- ID de área
- Prioridad del enrutador
- Direcciones de enrutadores DR y BDR
- Contraseña de autenticación
El mensaje de saludo del enrutador R1 lleva su ID de enrutador y no contiene vecinos porque aún no los tiene.
Después de recibir este mensaje de multidifusión, el enrutador R2 agrega R1 a su tabla de vecinos (si todos los parámetros necesarios coinciden).
Y envía un nuevo mensaje de saludo al R1 como unidifusión, que contiene el ID del enrutador de este enrutador y la lista de vecinos enumera todos sus vecinos. Entre otros vecinos de esta lista se encuentra el Router ID R1, es decir, el R2 ya lo considera vecino.
3) Amistad. Cuando R1 recibe este mensaje de saludo de R2, se desplaza por la lista de vecinos y encuentra su propio ID de enrutador en ella, agrega R2 a su lista de vecinos.
Ahora R1 y R2 son vecinos mutuos; esto significa que se ha establecido una relación de adyacencia entre ellos y el enrutador R1 entra en estado DOS VÍAS.
Consejos generales para todas las tareas:
Incluso si no sabes inmediatamente la respuesta y la solución, intenta pensar a qué se refiere la condición del problema:
- ¿Qué características y configuración de protocolo?
- ¿Estas configuraciones son globales o están vinculadas a una interfaz específica?
Si no conoce o ha olvidado el comando, estas reflexiones probablemente le llevarán al contexto correcto, donde podrá simplemente, con la ayuda de una pista en línea de comando, puede adivinar o recordar cómo configurar lo que se requiere en la tarea.
Intente pensar de esta manera antes de ir a Google o a cualquier sitio en busca de comandos.
En una red real, al elegir la gama de subredes anunciadas, es necesario guiarse por las regulaciones y las necesidades inmediatas.
Antes de pasar a probar la velocidad y los enlaces de respaldo, hagamos una cosa más útil.
Si tuviéramos la oportunidad de captar tráfico en la interfaz FE0/0.2 msk-arbat-gw1, que está frente a los servidores, entonces veríamos que los mensajes de saludo vuelan hacia lo desconocido cada 10 segundos. No hay nadie con quien responder Hola, no hay nadie con quien establecer relaciones de adyacencia, por lo que no tiene sentido intentar enviar mensajes desde aquí.
Desactivarlo es muy sencillo:
msk-arbat-gw1(config)#enrutador OSPF 1
msk-arbat-gw1(config-router)#interfaz pasiva fastEthernet 0/0.2
Este comando debe darse para todas las interfaces que definitivamente no tienen vecinos OSPF (incluidas aquellas orientadas a Internet).
Como resultado, tendrás una imagen como esta:
*No puedo imaginar cómo no te has confundido todavía*
Además, este comando aumenta la seguridad: nadie de esta red se hará pasar por un enrutador y no intentará rompernos por completo.
Pasemos ahora a la parte más interesante: las pruebas.
No hay nada complicado en configurar OSPF en todos los enrutadores del Anillo Siberiano; puede hacerlo usted mismo.
Y después de eso la imagen debería ser la siguiente:
msk-arbat-gw1#sh IP vecino OSPF
172.16.255.32 1 COMPLETO/DR 00:00:31 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 COMPLETO/DR 00:00:31 172.16.2.18 FastEthernet0/1.5
172.16.255.80 1 COMPLETO/BDR 00:00:36 172.16.2.130 FastEthernet0/1.8
172.16.255.112 1 COMPLETO/BDR 00:00:37 172.16.2.197 FastEthernet1/0.911
San Petersburgo, Kemerovo, Krasnoyarsk y Vladivostok están conectados directamente.
msk-arbat-gw1#sh ruta IP172.16.0.0/16 tiene subredes variables, 25 subredes, 6 máscaras
S 172.16.2.4/30 vía 172.16.2.2
O 172.16.2.160/30 a través de 172.16.2.130, 00:05:53, FastEthernet0/1.8
O 172.16.2.192/30 vía 172.16.2.197, 00:04:18, FastEthernet1/0.911
S 172.16.16.0/21 vía 172.16.2.2
S 172.16.24.0/22 vía 172.16.2.18
O 172.16.24.0/24 vía 172.16.2.18, 00:24:03, FastEthernet0/1.5
O 172.16.128.0/24 vía 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.129.0/26 vía 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.255.32/32 vía 172.16.2.2, 00:24:03, FastEthernet0/1.4
O 172.16.255.48/32 vía 172.16.2.18, 00:24:03, FastEthernet0/1.5
O 172.16.255.80/32 vía 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.255.96/32 vía 172.16.2.130, 00:04:18, FastEthernet0/1.8
vía 172.16.2.197, 00:04:18, FastEthernet1/0.911
O 172.16.255.112/32 vía 172.16.2.197, 00:04:28, FastEthernet1/0.911
Todos saben todo sobre todos.
¿Qué ruta se distribuye el tráfico de Moscú a Krasnoyarsk? La tabla muestra que krs-stolbi-gw1 está conectado directamente y lo mismo se puede ver en el seguimiento:
1 172.16.2.130 35 ms 8 ms 5 ms
Ahora rompemos la interfaz entre Moscú y Krasnoyarsk y vemos cuánto tiempo lleva restablecer el enlace.
No pasaron ni 5 segundos antes de que todos los enrutadores se enteraran del incidente y recalcularan sus tablas de enrutamiento:
msk-arbat-gw1(config-subif)#do sh ip ro 172.16.128.0
Conocido vía "OSPF 1", distancia 110, métrica 4, tipo intraárea
Última actualización de 172.16.2.197 en FastEthernet1/0.911, hace 00:00:53
Bloques de descriptores de enrutamiento:
* 172.16.2.197, desde 172.16.255.80, hace 00:00:53, vía FastEthernet1/0.911
La métrica de ruta es 4, el recuento de tráfico compartido es 1Vld-gw1#sh ruta IP 172.16.128.0
Entrada de enrutamiento para 172.16.128.0/24
Conocido vía "OSPF 1", distancia 110, métrica 3, tipo intraárea
Última actualización de 172.16.2.193 en FastEthernet1/0, hace 00:01:57
Bloques de descriptores de enrutamiento:
* 172.16.2.193, desde 172.16.255.80, hace 00:01:57, vía FastEthernet1/0
La métrica de ruta es 3, el recuento de tráfico compartido es 1Msk-arbat-gw1#traceroute 172.16.128.1
Escriba la secuencia de escape al aborto.
Seguimiento de la ruta hasta 172.16.128.11 172.16.2.197 4 ms 10 ms 10 ms
2 172.16.2.193 8 ms 11 ms 15 ms
3 172.16.2.161 15 ms 13 ms 6 ms
Es decir, ahora el tráfico llega a Krasnoyarsk de esta manera:
Tan pronto como se establece el enlace, los enrutadores se comunican nuevamente, intercambian sus bases de datos, recalculan las rutas más cortas y las ingresan en la tabla de enrutamiento.
El vídeo deja todo esto más claro. recomiendo familiarizarse.
Como cualquiera buen protocolo OSPF admite autenticación: dos vecinos pueden verificar la autenticidad de los mensajes OSPF recibidos antes de establecer relaciones de vecindad. Déjalo encendido autoestudio- bastante simple.
EIGRP
Ahora pasemos a otro protocolo muy importante.Entonces, ¿qué tiene de bueno EIGRP?
- fácil de configurar
- cambio rápido a calculado de antemano ruta alternativa
- requiere menos recursos del enrutador (en comparación con OSPF)
- resumen de rutas en cualquier enrutador (en OSPF solo en ABR\ASBR)
- equilibrio de tráfico en rutas desiguales (OSPF solo en rutas iguales)
Decidimos traducir una de las entradas del blog de Ivan Pepelnyak, que aborda una serie de mitos populares sobre EIGRP:
- "EIGRP es un protocolo de enrutamiento híbrido". Si mal no recuerdo, esto comenzó con la primera presentación de EIGRP hace muchos años y generalmente se entiende como "EIGRP tomó lo mejor de los protocolos de estado de enlace y vector de distancia". Esto es absolutamente falso. EIGRP no tiene características distintivas estado de enlace. Sería correcto decir "EIGRP es un protocolo avanzado de enrutamiento por vector de distancia".- “EIGRP es un protocolo de vector distancia”. No está mal, pero tampoco del todo cierto. EIGRP se diferencia de otros DV en la forma en que maneja rutas huérfanas (o rutas con métricas crecientes). Todos los demás protocolos esperan pasivamente actualizaciones de información de un vecino (algunos, como RIP, incluso bloquean la ruta para evitar bucles de enrutamiento), mientras que EIGRP es más activo y solicita información por sí mismo.
- “EIGRP es difícil de implementar y mantener”. No es cierto. Hubo un tiempo en que EIGRP en redes grandes con enlaces de baja velocidad era difícil de implementar correctamente, pero solo hasta que se introdujeron los enrutadores auxiliares. Con ellos (además de varias correcciones al algoritmo DUAL), es casi peor que OSPF.
- “Al igual que los protocolos LS, EIGRP mantiene una tabla de la topología de las rutas que se intercambian”. Es sorprendente lo equivocado que está esto. EIGRP no tiene idea alguna de lo que hay más allá de sus vecinos inmediatos, mientras que los protocolos LS conocen exactamente la topología de toda el área a la que están conectados.
- "EIGRP es un protocolo DV que actúa como LS". Buen intento, pero sigue siendo completamente incorrecto. Los protocolos LS crean una tabla de enrutamiento siguiendo los siguientes pasos:
- cada enrutador describe la red en función de la información disponible localmente (sus enlaces, las subredes en las que se encuentra, los vecinos que ve) a través de un paquete (o varios) llamado LSA (en OSPF) o LSP (IS-IS)
- Los LSA se propagan por toda la red. Cada enrutador debe recibir cada LSA creado en su red. La información recibida del LSA se ingresa en la tabla de topología.
- Cada enrutador analiza de forma independiente su tabla de topología y ejecuta el algoritmo SPF para calcular las mejores rutas a cada uno de los demás enrutadores.
El comportamiento de EIGRP ni siquiera se acerca a estos pasos, por lo que no está claro por qué diablos "actúa como LS".Lo único que hace EIGRP es almacenar información recibida de un vecino (RIP olvida inmediatamente lo que no se puede utilizar en en este momento). En este sentido, es similar a BGP, que también almacena todo en una tabla BGP y selecciona mejor ruta de eso. La tabla de topología (que contiene toda la información recibida de los vecinos) le da a EIGRP una ventaja sobre RIP: puede contener información sobre una ruta de respaldo (no utilizada actualmente).
Ahora un poco más cerca de la teoría del trabajo:
Cada proceso EIGRP mantiene 3 tablas:
- Una tabla de vecinos, que contiene información sobre "vecinos", es decir. otros enrutadores conectados directamente al actual y participando en el intercambio de rutas. Puedes verlo usando el comando mostrar vecinos ip eigrp
- Tabla de topología de red, que contiene información de ruta recibida de los vecinos. Miremos en equipo mostrar topología ip eigrp
- La tabla de enrutamiento, a partir de la cual el enrutador toma decisiones sobre la redirección de paquetes. Ver vía mostrar ruta ipMétrica.
Para evaluar la calidad de una ruta en particular, los protocolos de enrutamiento utilizan un número determinado que refleja sus diversas características o un conjunto de características: una métrica. Las características que se tienen en cuenta pueden ser diferentes, desde la cantidad de enrutadores en una ruta determinada hasta el promedio aritmético de la carga en todas las interfaces a lo largo de la ruta. Respecto a la métrica EIGRP, citando a Jeremy Cioara: “Tuve la impresión de que los creadores de EIGRP, al observar críticamente su creación, decidieron que todo era demasiado simple y funcionaba bien. Y luego se les ocurrió una fórmula métrica para que todos dijeran "GUAU, esto es realmente complicado y parece profesional". Vea la fórmula completa para calcular la métrica EIGRP: (K1 * bw + (K2 * bw) / (256 - carga) + K3 * retraso) * (K5 / (confiabilidad + K4)), en la que:
- bw no es solo ancho de banda, sino (10000000/ancho de banda más pequeño a lo largo de la ruta en kilobits) * 256
- el retraso no es solo un retraso, sino la suma de todos los retrasos en el camino hacia decenas de microsegundos* 256 (¡el retraso en los comandos show interface, show ip eigrp topology y otros se muestra en microsegundos!)
- K1-K5 son coeficientes que sirven para asegurar que uno u otro parámetro esté “incluido” en la fórmula.¿Aterrador? lo sería si todo funcionara como está escrito. De hecho, de los 4 términos posibles de la fórmula, solo se usan dos por defecto: bw y retraso (coeficientes K1 y K3 = 1, el resto son cero), lo que lo simplifica enormemente: simplemente sumamos estos dos números (aunque no olvidando que todavía se calculan según sus propias fórmulas). Es importante recordar lo siguiente: la métrica se calcula según el peor indicador ancho de banda a lo largo de toda la ruta.
Algo interesante sucedió con MTU: muy a menudo puedes encontrar información de que MTU está relacionada con la métrica EIGRP. De hecho, los valores de MTU se transmiten al intercambiar rutas. Pero, como podemos ver en fórmula completa, allí no se menciona MTU. El caso es que este indicador se tiene en cuenta en casos bastante concretos: por ejemplo, si un router debe descartar una de las rutas equivalentes en otras características, elegirá la que tenga menor MTU. Aunque no todo es tan sencillo (ver comentarios).Definamos los términos utilizados dentro de EIGRP. Cada ruta en EIGRP se caracteriza por dos números: Distancia factible y Distancia anunciada (en lugar de Distancia anunciada, a veces puede ver Distancia informada, esto es lo mismo). Cada uno de estos números representa una métrica o costo (cuanto más, peor) de una ruta determinada con diferentes puntos dimensiones: FD es “de mí al destino”, y AD es “del vecino que me habló de esta ruta al destino”. La respuesta a la pregunta lógica "¿Por qué necesitamos saber el costo de un vecino si ya está incluido en el DF?" es un poco menor (por ahora, si lo desea, puede detenerse y devanarse los sesos).
Para cada subred que EIGRP conoce, en cada enrutador hay un enrutador sucesor entre sus vecinos, a través del cual pasa la mejor ruta (con una métrica más baja), según el protocolo, a esta subred. Además, una subred también puede tener una o más rutas de respaldo (el enrutador vecino a través del cual pasa dicha ruta se denomina sucesor factible). EIGRP es el único protocolo de enrutamiento que recuerda rutas de respaldo (OSPF las tiene, pero están contenidas, por así decirlo, en "forma cruda" en la tabla de topología; aún deben ser procesadas por el algoritmo SPF), lo que le da una Ventaja de rendimiento: tan pronto como el protocolo determina que la ruta principal (a través del sucesor) no está disponible, cambia inmediatamente a la ruta de respaldo. Para que un enrutador se convierta en un sucesor factible de una ruta, su AD debe ser menor que el FD sucesor de esta ruta (es por eso que necesitamos conocer AD). Esta regla se utiliza para evitar bucles de enrutamiento.
¿El párrafo anterior te dejó boquiabierto? El material es difícil, así que usaré un ejemplo nuevamente. Tenemos esta red:
Desde el punto de vista del R1, el R2 es el sucesor de la subred 192.168.2.0/24. Para convertirse en un FS para esta subred, R4 requiere que su AD sea menor que el FD para esta ruta. Tenemos FD ((10000000/1544)*256)+(2100*256) =2195456, R4 tiene AD (desde su punto de vista esto es FD, es decir, cuánto le cuesta llegar a esta red) = (( 10000000/100000 )*256)+(100*256)=51200. Todo converge, el AD de R4 es menor que el FD de la ruta, se convierte en FS. *entonces el cerebro dice: “BDASH”*. Ahora miramos a R3: anuncia su red 192.168.1.0/24 a su vecino R1, quien, a su vez, se lo cuenta a sus vecinos R2 y R4. R4 no sabe que R2 conoce esta subred y decide decírselo. R2 transmite la información a la que tiene acceso a través de R4 a la subred 192.168.1.0/24 y luego a R1. R1 mira estrictamente el FD de la ruta y el AD, del que se jacta R2 (que, como se desprende del diagrama, será claramente más grande que el FD, ya que también lo incluye a él) y lo ahuyenta para no interferir con todo tipo de tonterías. Esta situación es bastante improbable, pero puede ocurrir en determinadas circunstancias, por ejemplo, cuando el mecanismo de horizonte dividido está desactivado. Y ahora a una situación más probable: imagine que R4 está conectado a la red 192.168.2.0/24 no a través de FastEthernet, sino a través de un módem de 56k (el retraso para el acceso telefónico es de 20,000 usec), respectivamente, le cuesta ((10000000/56 )*256 )+(2000*256)= 46226176. Esto es más que el FD para esta ruta, por lo que R4 no se convertirá en un sucesor factible. Pero esto no significa que EIGRP no utilizará esta ruta en absoluto. Simplemente tomará más tiempo cambiar a él (más sobre esto más adelante).
vecindario
Los enrutadores no hablan de rutas con cualquiera: deben establecer relaciones de adyacencia antes de poder intercambiar información. Luego de encender el proceso con el comando router eigrp, indicando el número del sistema autónomo, nosotros, con el comando network, decimos qué interfaces participarán y al mismo tiempo, información sobre qué redes queremos distribuir. Inmediatamente, los paquetes de saludo comienzan a enviarse a través de estas interfaces a la dirección de multidifusión 224.0.0.10 (de forma predeterminada, cada 5 segundos para Ethernet). Todos los enrutadores con EIGRP habilitado reciben estos paquetes, luego cada enrutador receptor hace lo siguiente:
- comprueba la dirección del remitente del paquete de saludo con la dirección de la interfaz desde la que se recibió el paquete y se asegura de que sean de la misma subred
- compara los valores de los coeficientes K obtenidos del paquete (en otras palabras, qué variables se utilizan para calcular la métrica) con los suyos propios. Está claro que si difieren, las métricas de las rutas se calcularán según reglas diferentes, lo cual es inaceptable.
- comprueba el número del sistema autónomo
- opcional: si la autenticación está configurada, verifica la coherencia de su tipo y claves.Si el destinatario está satisfecho con todo, agrega al remitente a la lista de sus vecinos y le envía (ya en Unicast) un paquete de actualización, que contiene una lista de todas las rutas que conoce (también conocida como actualización completa). El remitente, al recibir dicho paquete, a su vez, hace lo mismo. Para intercambiar rutas, EIGRP utiliza el Protocolo de transporte confiable (RTP, que no debe confundirse con el Protocolo de transporte en tiempo real, que se usa en telefonía IP), lo que implica una confirmación de entrega, por lo que cada uno de los enrutadores, habiendo recibido un paquete de actualización, responde con un paquete de confirmación (abreviatura de acuse de recibo - confirmación). Entonces, se ha establecido la relación de vecindad, los enrutadores han aprendido unos de otros información completa sobre las rutas, ¿qué sigue? Luego continuarán enviando paquetes de saludo de multidifusión para confirmar que están conectados y, si la topología cambia, actualizarán paquetes que contengan información solo sobre los cambios (actualización parcial).
Ahora volvamos al esquema anterior con el módem.
Por alguna razón, R2 perdió contacto con 192.168.2.0/24. No tiene rutas de respaldo a esta subred (es decir, no tiene FS). Como cualquier enrutador EIGRP responsable, quiere restablecer la conectividad. Para ello, comienza a enviar mensajes especiales (paquetes de consulta) a todos sus vecinos, quienes, a su vez, al no encontrar por sí mismos la ruta deseada, preguntan a todos sus vecinos, y así sucesivamente. Cuando la ola de solicitudes llega a R4, dice “¡espera un minuto, tengo una ruta a esta subred! Malo, pero al menos algo. Todos se olvidaron de él, pero yo lo recuerdo”. Empaqueta todo esto en un paquete de respuesta y lo envía al vecino de quien recibió la solicitud (consulta), y más adelante en la cadena. Por supuesto, todo esto lleva más tiempo que simplemente cambiar a Feasible Successor, pero al final conseguimos comunicarnos con la subred.
Y ahora es un momento peligroso: tal vez ya lo hayas notado y te hayas vuelto cauteloso después de leer sobre este correo de fans. La falla de una interfaz causa algo similar a una tormenta de transmisión en la red (no en tal escala, por supuesto, pero aún así), y cuantos más enrutadores haya, más recursos se gastarán en todas estas solicitudes y respuestas. Pero eso no es tan malo. Es posible una situación peor: imagine que los enrutadores que se muestran en la imagen son solo parte de un gran y red distribuida, es decir. algunos pueden estar situados a muchos miles de kilómetros de nuestro R2, en malos canales, etc. Entonces, el problema es que, al enviar una consulta a un vecino, el enrutador debe esperar su respuesta. No importa cuál sea la respuesta, pero debe llegar. Incluso si el enrutador ya recibió una respuesta positiva, como en nuestro caso, no puede poner en funcionamiento esta ruta hasta que espere respuesta a todas sus solicitudes. Y tal vez todavía haya solicitudes en algún lugar de Alaska. Este estado de ruta se denomina atascado en activo. Aquí necesitamos familiarizarnos con los términos que reflejan el estado de la ruta en EIGRP: ruta activa\pasiva. Suelen ser engañosos. El sentido común dicta que activo significa que la ruta está “activa”, habilitada y en ejecución. Sin embargo, aquí todo es al revés: pasivo significa "todo está bien" y activo significa que esta subred no está disponible y el enrutador está buscando activamente otra ruta, enviando una consulta y esperando una respuesta. Por lo tanto, ¡el estado de estancamiento activo puede durar hasta 3 minutos! Una vez transcurrido este período, el enrutador rompe la relación de vecino con el vecino del cual no puede esperar una respuesta y puede usar una nueva ruta a través de R4.
Una historia que le hiela la sangre a un ingeniero de redes. 3 minutos de inactividad no son una broma. ¿Cómo podemos evitar el infarto de esta situación? Hay dos salidas: resumir rutas y la llamada configuración stub.
En términos generales, hay otra salida: se llama filtrado de rutas. Pero este es un tema tan voluminoso que sería mejor escribir un artículo aparte, pero esta vez ya tenemos medio libro. Así que depende de ti.Como ya mencionamos, en EIGRP el resumen de rutas se puede realizar en cualquier enrutador. Para ilustrar, imaginemos que las subredes de 192.168.0.0/24 a 192.168.7.0/24 están conectadas a nuestro sufrido R2, que muy convenientemente suma 192.168.0.0/21 (recuerde las matemáticas binarias). El enrutador anuncia esta ruta resumida y todos los demás lo saben: si la dirección de destino comienza con 192.168.0-7, entonces es para él. ¿Qué pasa si una de las subredes desaparece? El enrutador enviará paquetes de consulta con la dirección de esta red (específica, por ejemplo, 192.168.5.0/24), pero los vecinos, en lugar de continuar con el envío de correos viciosos por su cuenta, responderán inmediatamente con repeticiones aleccionadoras, diciendo que esto es tu subred, lo averiguas.
La segunda opción es la configuración de código auxiliar. En sentido figurado, stub significa "final del camino", "callejón sin salida" en EIGRP, es decir, ingresar a alguna subred que no está conectada directamente a dicho enrutador, tendrá que regresar. Un enrutador configurado como stub no reenviará tráfico entre subredes que conoce de EIGRP (en otras palabras, que están marcadas con la letra D en show ip route). Además, sus vecinos no le enviarán paquetes de consultas. El caso de uso más común son las topologías hub-and-spoke, especialmente con enlaces redundantes. Tomemos esta red: a la izquierda están las sucursales, a la derecha está el sitio principal, la oficina principal, etc. Para tolerancia a fallos, enlaces redundantes. EIGRP se ejecuta con la configuración predeterminada.
Y ahora “atención, pregunta”: ¿qué pasará si R1 pierde conexión con R4 y R5 pierde LAN? El tráfico desde la subred R1 a la subred de la oficina principal seguirá la ruta R1->R5->R2 (o R3)->R4. ¿Será efectivo? No. No sólo se verá afectada la subred detrás de R1, sino también la subred detrás de R2 (o R3), debido al aumento en los volúmenes de tráfico y sus consecuencias. Es para tales situaciones que se inventó el stub. Detrás de los enrutadores en las sucursales no hay otros enrutadores que conduzcan a otras subredes, este es el "final del camino", luego solo de regreso. Por lo tanto, con tranquilidad, podemos configurarlos como stubs, lo que, en primer lugar, nos salvará del problema descrito anteriormente con la "ruta torcida" y, en segundo lugar, de la avalancha de paquetes de consulta en caso de que se pierda la ruta.
Hay varios modos operación del enrutador stub, se configuran con el comando eigrp stub:
R1(config)#enrutador eigrp 1
¿R1(config-router)#eigrp trozo?
conectado Anunciar rutas conectadas
mapa de fugas Permitir prefijos dinámicos basados en el mapa de fugas
solo recepción Establecer IP-EIGRP como vecino de solo recepción
redistribuido Anuncie rutas redistribuidas
estático Anunciar rutas estáticas
resumen Anunciar rutas resumidas
De forma predeterminada, si simplemente ejecuta el comando eigrp stub, se habilitan los modos conectado y resumen. De interés es el modo de solo recepción, en el que el enrutador no anuncia ninguna red, solo escucha lo que le dicen sus vecinos (en RIP hay un comando de interfaz pasivo que hace lo mismo, pero en EIGRP desactiva completamente el protocolo en la interfaz seleccionada, que no permite establecer una vecindad).Puntos importantes de la teoría EIGRP que no se incluyeron en el artículo:
- La autenticación de vecinos se puede configurar en EIGRP
- Concepto de cierre elegante
Práctica EIGRP
Lift mi Up compró una fábrica en Kaliningrado. Allí se fabrican los cerebros de los ascensores: microcircuitos, software. La fábrica es muy grande: tres puntos alrededor de la ciudad, tres enrutadores conectados en anillo.
Pero mala suerte: ya tienen EIGRP ejecutándose como protocolo de enrutamiento dinámico. Además, el direccionamiento de los nodos finales se realiza desde una subred completamente diferente: 10.0.0.0/8. Cambiamos todos los demás parámetros (direcciones de enlace, direcciones de interfaz loopback), pero varios miles de direcciones de red local con servidores, impresoras, puntos de acceso (ni un trabajo durante un par de horas) se pospusieron para más tarde, y en el plan IP reservamos el Subred 172.16 para el futuro para Kaliningrado .32.0/20.
Actualmente utilizamos las siguientes redes:
¿Cómo se configura este milagro? Sencillo a primera vista:
enrutador eigrp 1
red 172.16.0.0 0.0.255.255
red 10.0.0.0
En EIGRP, se puede especificar la máscara inversa, lo que indica un alcance más limitado, o no se especifica, luego se seleccionará la máscara estándar para esta clase (16 para la clase B - 172.16.0.0 y 8 para la clase 8 - 10.0.0.0)Estos comandos se dan en todos los enrutadores. Sistema Autónomo. El AC está determinado por el número en el comando router eigrp, es decir, en nuestro caso tenemos el AC N°1. Esta cifra debería ser la misma en todos los enrutadores (a diferencia de OSPF).
Pero hay un problema grave en EIGRP: de forma predeterminada, el resumen automático de rutas en forma de clase está habilitado (en versiones de IOS hasta 15).
Comparemos las tablas de enrutamiento de tres enrutadores de Kaliningrado:La red 10.0.0.1/24 está conectada a klgr-center-gw1 y él lo sabe:
klgr-centro-gw1:
10.0.0.0/8 tiene subredes variables, 2 subredes, 2 máscaras
D 10.0.0.0/8 es un resumen, 00:35:23, Null0
C 10.0.0.0/24 está conectado directamente, FastEthernet1/0
Pero no sabe acerca de 10.0.1.0/24 y 10.0.2.0/24/Klgr-balt-gw1 conoce sus dos redes 10.0.1.0/24 y 10.0.2.0/24, pero ocultó la red 10.0.0.0/24 en algún lugar.
10.0.0.0/8 tiene subredes variables, 3 subredes, 2 máscaras
D 10.0.0.0/8 es un resumen, 00:42:05, Null0
C 10.0.1.0/24 está conectado directamente, FastEthernet1/1.2
C 10.0.2.0/24 está conectado directamente, FastEthernet1/1.3
Ambos crearon la ruta 10.0.0.0/8 con la dirección del siguiente salto Null0.Pero klgr-center-gw2 sabe que las subredes 10.0.0.0/8 están ubicadas detrás de sus dos interfaces WAN.
D 10.0.0.0/8 vía 172.16.2.41, 00:42:49, FastEthernet0/1
vía 172.16.2.45, 00:38:05, FastEthernet0/0
Algo muy extraño está sucediendo.
Pero, si revisas la configuración de este enrutador, probablemente notarás:enrutador eigrp 1
red 172.16.0.0
red 10.0.0.0
resumen automático
La suma automática tiene la culpa de todo. Este es el mayor mal de EIGRP. Echemos un vistazo más de cerca a lo que está sucediendo. klgr-center-gw1 y klgr-balt-gw1 tienen subredes de 10.0.0.0/8, las resumen de forma predeterminada cuando las pasan a sus vecinos.
Es decir, por ejemplo, msk-balt-gw1 no transmite dos redes 10.0.1.0/24 y 10.0.2.0/24, sino una generalizada: 10.0.0.0/8. Es decir, su vecino pensará que toda esta red se encuentra detrás de msk-balt-gw1.
Pero, ¿qué pasa si de repente balt-gw1 recibe un paquete con destino 10.0.50.243, del que no sabe nada? Para este caso se crea la ruta denominada Blackhole:
10.0.0.0/8 es un resumen, 00:42:05, Null0
El paquete resultante será arrojado a este agujero negro. Esto se hace para evitar bucles de enrutamiento.
Entonces, ambos enrutadores crearon sus propias rutas de agujeros negros e ignoraron los anuncios de otras personas. En realidad, en una red de este tipo, estos tres dispositivos no podrán comunicarse entre sí hasta... hasta que desactive el resumen automático.Lo primero que debes hacer al configurar EIGRP es:
enrutador eigrp 1
sin resumen automático
En todos los dispositivos. Y todos estarán bien:Klgr-centro-gw1:
C 10.0.0.0 está conectado directamente, FastEthernet1/0
D 10.0.1.0 vía 172.16.2.37, 00:03:11, FastEthernet0/0
D 10.0.2.0 a través de 172.16.2.37, 00:03:11, FastEthernet0/0
klgr-balt-gw110.0.0.0/24 está dividido en subredes, 3 subredes
D 10.0.0.0 a través de 172.16.2.38, 00:08:16, FastEthernet0/1
C 10.0.1.0 está conectado directamente, FastEthernet1/1.2
C 10.0.2.0 está conectado directamente, FastEthernet1/1.3
klgr-centro-gw2:10.0.0.0/24 está dividido en subredes, 3 subredes
D 10.0.0.0 a través de 172.16.2.45, 00:11:50, FastEthernet0/0
D 10.0.1.0 vía 172.16.2.41, 00:11:48, FastEthernet0/1
D 10.0.2.0 vía 172.16.2.41, 00:11:48, FastEthernet0/1Configurar la transferencia de rutas entre diferentes protocolos
Nuestra tarea es organizar la transferencia de rutas entre estos protocolos: de OSPF a EIGRP y viceversa, para que todos conozcan la ruta a cualquier subred.
Esto se llama redistribución de rutas.Para implementarlo, necesitamos al menos un punto de unión donde se lanzarán dos protocolos simultáneamente. Podría ser msk-arbat-gw1 o klgr-balt-gw1. Elijamos el segundo.
De EIGRP a OSPF:
klgr-gw1(config)#enrutador ospf 1
klgr-gw1(config-router)#redistribuir subredes eigrp 1
Miramos las rutas en msk-arbat-gw1:msk-arbat-gw1#sh ruta IP
Códigos: C - conectado, S - estático, I - IGRP, R - RIP, M - móvil, B - BGP
D - EIGRP, EX - EIGRP externo, O - OSPF, IA - OSPF entre áreas
N1 - OSPF NSSA externo tipo 1, N2 - OSPF NSSA externo tipo 2
E1 - OSPF externo tipo 1, E2 - OSPF externo tipo 2, E - EGP
i - IS-IS, L1 - IS-IS nivel-1, L2 - IS-IS nivel-2, ia - IS-IS entre áreas
* - candidato predeterminado, U - ruta estática por usuario, o - ODR
P - ruta estática descargada periódicamenteLa puerta de enlace de último recurso es 198.51.100.1 a la red 0.0.0.0
10.0.0.0/8 tiene subredes variables, 3 subredes, 2 máscaras
O E2 10.0.0.0/8 vía 172.16.2.34, 00:25:11, FastEthernet0/1.7
O E2 10.0.1.0/24 vía 172.16.2.34, 00:25:11, FastEthernet0/1.7
O E2 10.0.2.0/24 vía 172.16.2.34, 00:24:50, FastEthernet0/1.7
172.16.0.0/16 tiene subredes variables, 30 subredes, 5 máscaras
O E2 172.16.0.0/16 vía 172.16.2.34, 00:25:11, FastEthernet0/1.7
C 172.16.0.0/24 está conectado directamente, FastEthernet0/0.3
C 172.16.1.0/24 está conectado directamente, FastEthernet0/0.2
C 172.16.2.0/30 está conectado directamente, FastEthernet0/1.4
C 172.16.2.16/30 está conectado directamente, FastEthernet0/1.5
C 172.16.2.32/30 está conectado directamente, FastEthernet0/1.7
O E2 172.16.2.36/30 vía 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.2.40/30 vía 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.2.44/30 vía 172.16.2.34, 01:00:55, FastEthernet0/1.7
C 172.16.2.128/30 está conectado directamente, FastEthernet0/1.8
172.16.2.160/30 a través de 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.2.192/30 vía 172.16.2.197, 00:13:21, FastEthernet1/0.911
C 172.16.2.196/30 está conectado directamente, FastEthernet1/0.911
C 172.16.3.0/24 está conectado directamente, FastEthernet0/0.101
C 172.16.4.0/24 está conectado directamente, FastEthernet0/0.102
C 172.16.5.0/24 está conectado directamente, FastEthernet0/0.103
C 172.16.6.0/24 está conectado directamente, FastEthernet0/0.104
O 172.16.24.0/24 vía 172.16.2.18, 01:00:55, FastEthernet0/1.5
O 172.16.128.0/24 vía 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.129.0/26 vía 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.144.0/24 vía 172.16.2.130, 00:13:21, FastEthernet0/1.8
O 172.16.160.0/24 vía 172.16.2.197, 00:13:31, FastEthernet1/0.911
C 172.16.255.1/32 está conectado directamente, Loopback0
O 172.16.255.48/32 vía 172.16.2.18, 01:00:55, FastEthernet0/1.5
O E2 172.16.255.64/32 vía 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.255.65/32 vía 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.255.66/32 vía 172.16.2.34, 01:00:55, FastEthernet0/1.7
O 172.16.255.80/32 vía 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.255.96/32 vía 172.16.2.130, 00:13:21, FastEthernet0/1.8
vía 172.16.2.197, 00:13:21, FastEthernet1/0.911
O 172.16.255.112/32 vía 172.16.2.197, 00:13:31, FastEthernet1/0.911
198.51.100.0/28 está dividido en subredes, 1 subred
C 198.51.100.0 está conectado directamente, FastEthernet0/1.6
S* 0.0.0.0/0 vía 198.51.100.1Aquí están los que tienen la etiqueta E2: nuevas rutas importadas. E2: significa que estas son rutas externas del segundo tipo (externas), es decir, se introdujeron en el proceso OSPF desde el exterior.
Ahora de OSPF a EIGRP. Esto es un poco más complicado:
klgr-gw1(config)#enrutador eigrp 1
klgr-gw1(config-router)#redistribuir ospf 1 métrica 100000 20 255 1 1500
Sin especificar la métrica (este largo conjunto de números), el comando se ejecutará, pero no se producirá la redistribución.Las rutas importadas reciben una etiqueta EX en la tabla de enrutamiento y una distancia administrativa de 170, en lugar de 90 para las internas:
klgr-gw2#sh ruta IPLa puerta de enlace de último recurso no está configurada
172.16.0.0/16 tiene subredes variables, 30 subredes, 4 máscaras
D EX 172.16.0.0/24 [170 /33280] a través de 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.1.0/24 a través de 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.0/30 a través de 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.4/30 a través de 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.16/30 a través de 172.16.2.37, 00:00:07, FastEthernet0/0
D 172.16.2.32/30 [ 90 /30720] a través de 172.16.2.37, 00:38:59, FastEthernet0/0
C 172.16.2.36/30 está conectado directamente, FastEthernet0/0
D 172.16.2.40/30 vía 172.16.2.37, 00:38:59, FastEthernet0/0
vía 172.16.2.46, 00:38:59, FastEthernet0/1
….Así es como parece hacerse de una manera simple, pero la simplicidad es superficial: la redistribución está plagada de muchos momentos sutiles y desagradables cuando se agrega al menos un vínculo redundante entre dos dominios diferentes.
Consejo general: trate de evitar la redistribución si es posible. Aquí funciona la regla principal de la vida: cuanto más simple, mejor.Ruta predeterminada
Ahora es el momento de comprobar su acceso a Internet. Funciona bien desde Moscú, pero si marca, por ejemplo, desde San Petersburgo (recuerde que eliminamos todos rutas estáticas):PC>ping linkmeup.ruHaciendo ping a 192.0.2.2 con 32 bytes de datos:
Respuesta de 172.16.2.5: Host de destino inalcanzable.
Respuesta de 172.16.2.5: Host de destino inalcanzable.
Respuesta de 172.16.2.5: Host de destino inalcanzable.Estadísticas de ping para 192.0.2.2:
Paquetes: enviados = 4, recibidos = 0, perdidos = 4 (pérdida del 100%),
Esto se debe a que ni spb-ozerki-gw1, ni spb-vsl-gw1, ni nadie más en nuestra red conocen la ruta predeterminada, excepto msk-arbat-gw1, en la que está configurada estáticamente.
Para corregir esta situación, basta con dar una orden en Moscú:msk-arbat-gw1(config)#enrutador ospf 1
msk-arbat-gw1 (config-router) # origen de información predeterminada
Después de esto, la información sobre dónde se encuentra la puerta de enlace de último recurso se propaga por la red.Internet ya está disponible:
PC>tracert linkmeup.ruRuta de seguimiento a 192.0.2.2 en un máximo de 30 saltos:
1 3 ms 3 ms 3 ms 172.16.17.1
2 4 ms 5 ms 12 ms 172.16.2.5
3 14 ms 20 ms 9 ms 172.16.2.1
4 17 ms 17 ms 19 ms 198.51.100.1
5 22 ms 23 ms 19 ms 192.0.2.2Comandos útiles para solucionar problemas
1) La lista de vecinos y el estado de comunicación con ellos se llama mediante el comando. mostrar ip ospf vecino
msk-arbat-gw1:ID de vecino Pri Estado Tiempo muerto Dirección Interfaz
172.16.255.32 1 COMPLETO/DROTHER 00:00:33 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 COMPLETO/DR 00:00:34 172.16.2.18 FastEthernet0/1.5
172.16.255.64 1 COMPLETO/DR 00:00:33 172.16.2.34 FastEthernet0/1.7
172.16.255.80 1 COMPLETO/DR 00:00:33 172.16.2.130 FastEthernet0/1.8
172.16.255.112 1 COMPLETO/DR 00:00:33 172.16.2.197 FastEthernet1/0.911
2) O para EIGRP: mostrar vecinos ip eigrpVecinos IP-EIGRP para el proceso 1
H Dirección Interfaz Tiempo de actividad SRTT RTO Q Seq
(seg) (ms) Núm Cnt
0 172.16.2.38 Fa0/1 12 00:04:51 40 1000 0 54
1 172.16.2.42 Fa0/0 13 00:04:51 40 1000 0 58
3) Usando el comando mostrar protocolos ip Puede ver información sobre la ejecución de protocolos de enrutamiento dinámico y sus relaciones.Klgr-balt-gw1:
El protocolo de enrutamiento es "EIGRP 1"
Redes predeterminadas marcadas en actualizaciones salientes
Redes predeterminadas aceptadas de actualizaciones entrantes
Peso métrico EIGRP K1=1, K2=0, K3=1, K4=0, K5=0
Número máximo de saltos de EIGRP 100
Varianza métrica máxima de EIGRP 1
Redistribución: EIGRP 1, OSPF 1
El resumen automático de red está en vigor.
Resumen automático de direcciones:
Ruta máxima: 4
Enrutamiento para redes:
172.16.0.0
172.16.2.42 90 4
172.16.2.38 90 4
Distancia: interna 90 externa 170El protocolo de enrutamiento es "OSPF 1"
La lista de filtros de actualización saliente para todas las interfaces no está configurada
La lista de filtros de actualización entrante para todas las interfaces no está configurada
ID del enrutador 172.16.255.64
Es un enrutador de límites de sistema autónomo.
Redistribuir rutas externas desde,
EIGRP 1
El número de áreas en este enrutador es 1. 1 normal 0 stub 0 nssa
Ruta máxima: 4
Enrutamiento para redes:
172.16.2.32 0.0.0.3 área 0
Fuentes de información de rutas:
Distancia de puerta de enlace Última actualización
172.16.255.64 110 00:00:23
Distancia: (el valor predeterminado es 110)
4) Para depurar y comprender el funcionamiento de los protocolos, será útil utilizar los siguientes comandos:
depurar eventos IP OSPF
depurar IP OSPF adj.
depurar paquetes EIGRPIntenta temblar diferentes interfaces y ver qué está sucediendo en la depuración, qué mensajes están volando.
Problema número 7
En fin, un problema complejo.
En la última reunión de Lift mi Up se decidió que la red de Kaliningrado también debería transferirse a OSPF.
La transición debe completarse sin romper la conexión. Se decidió que la mejor opción sería elevar OSPF a tres enrutadores Kaliningrado y después de que se haya verificado que toda la información sobre las rutas de Kaliningrado se ha difundido por el resto de la red y viceversa, desactive EIGRP. para el logotipo del sitio.
Agregar etiquetas
La red Lift mi Up, junto con su personal, está creciendo a lo largo y ancho. El mantenimiento de la infraestructura de TI se transfirió a una organización separada especialmente creada "Link Me Up".
Precisamente el otro día se compraron cuatro sucursales más en diferentes ciudades y los inversores descubrieron nuevas dimensiones del movimiento de los ascensores. Y la red creció de cuatro enrutadores a diez a la vez. Al mismo tiempo, el número de subredes ha aumentado de 9 a 20, sin contar los enlaces punto a punto entre enrutadores. Y aquí surge la cuestión de gestionar toda esta economía. De acuerdo, agregar rutas manualmente a todas las redes en cada nodo no es muy divertido.
La situación se complica por el hecho de que la red en Kaliningrado ya tiene su propio direccionamiento y en ella se ejecuta el protocolo de enrutamiento dinámico EIGRP.
- Entonces hoy:
- Entendamos la teoría de los protocolos de enrutamiento dinámico. Introducimos “Lift mi Up” en la red
- protocolo OSPF
- Configurar la transferencia (redistribución) de rutas entre OSPF y EIGRP
El nivel de dificultad variará. Todos los problemas tendrán respuestas que se pueden ver en. En algunos de ellos necesitarás pensar, en otros necesitarás leer la documentación, en otros necesitarás entender la topología y tal vez incluso mirar la información de depuración. Si una tarea no se puede implementar en RT, haremos una nota especial al respecto.
Primero, comprendamos el concepto de "enrutamiento dinámico". Hasta ahora, utilizábamos el llamado enrutamiento estático, es decir, escribíamos manualmente una tabla de enrutamiento en cada enrutador. El uso de protocolos de enrutamiento nos permite evitar este proceso tedioso, monótono y errores humanos. Como su nombre lo indica, estos protocolos están diseñados para construir ellos mismos tablas de enrutamiento, automáticamente, según la configuración de red actual. En general, esto es algo necesario, especialmente cuando su red no tiene 3 enrutadores, sino 30, por ejemplo.Hay otros aspectos además de la conveniencia. Por ejemplo, tolerancia a fallas. Tener una red con enrutamiento estático, te resultará extremadamente difícil organizarte canales de respaldo- no hay nadie que controle la disponibilidad de un segmento en particular.
Por ejemplo, si en una red de este tipo se rompe el enlace entre R2 y R3, los paquetes de R1 continuarán yendo a R2, donde serán destruidos porque no hay ningún lugar donde enviarlos.
Los protocolos de enrutamiento dinámico detectan problemas en la red en unos pocos segundos (o incluso milisegundos) y reconstruyen sus tablas de enrutamiento y, en el caso descrito anteriormente, los paquetes se enviarán a lo largo de la ruta actual.
Otro punto importante - equilibrio de tráfico. Los protocolos de enrutamiento dinámico admiten esta función casi desde el primer momento y no es necesario agregar rutas redundantes manualmente calculándolas.
Bueno, la implementación del enrutamiento dinámico lo hace mucho más fácil. escalamiento de red. Cuando agrega un nuevo elemento a una red o subred en un enrutador existente, solo necesita realizar unos pocos pasos para que todo funcione, con una mínima posibilidad de error, y la información sobre los cambios se comparte instantáneamente en todos los dispositivos. Se puede decir exactamente lo mismo sobre los cambios de topología global.
Todos los protocolos de enrutamiento se pueden dividir en dos grupos grandes: externo ( E.G.P.- Protocolo de puerta de enlace exterior) e interno ( IGP- Protocolo de Pasarela Interior). Para explicar las diferencias entre ellos, necesitamos el término "sistema autónomo". EN en un sentido general, un sistema autónomo (dominio de enrutamiento) es un grupo de enrutadores bajo administración común.
En el caso de nuestra red AS actualizada será así:
Entonces, los protocolos de enrutamiento internos se utilizan dentro de un sistema autónomo y los externos se utilizan para conectar sistemas autónomos entre sí. A su vez, los protocolos de enrutamiento interno se dividen en Vector de distancia(RIP, EIGRP) y Estado del enlace(OSPF, IS-IS). En este artículo no patearemos cadáveres, ni tocaremos los protocolos RIP e IGRP por su venerable antigüedad, así como IS-IS por su ausencia en PT.
Las diferencias fundamentales entre estos dos tipos son las siguientes:
1) el tipo de información que los enrutadores intercambian: tablas de enrutamiento para el vector de distancia y tablas de topología para el estado del enlace,
2) el proceso de elección de la mejor ruta,
3) la cantidad de información sobre la red que cada enrutador “guarda en su cabeza”: Distance-Vector solo conoce a sus vecinos, Link State tiene una idea de toda la red.
Como podemos ver, la cantidad de protocolos de enrutamiento es pequeña, pero aún no son uno o dos. ¿Qué sucede si ejecuta varios protocolos en el enrutador al mismo tiempo? Puede ser que cada protocolo tenga su propia opinión sobre la mejor manera de llegar a una red en particular. ¿Y si también tenemos configuradas rutas estáticas? ¿A quién le dará preferencia el enrutador y qué ruta agregará a la tabla de enrutamiento? La respuesta a esta pregunta va asociada a un nuevo término: distancia administrativa (para nuestro gusto, una copia bastante mediocre del inglés Distancia administrativa, pero no se les ocurrió uno mejor). La distancia administrativa es un número entero de 0 a 255 y expresa la "medida de confianza" del enrutador en esta ruta. Cuanto más pequeño sea el AD, más confianza. He aquí una señal de dicha confianza desde el punto de vista de Cisco:
| Protocolo | Distancia administrativa |
|---|---|
| Interfaz conectada | 0 |
| Ruta estática | 1 |
| Ruta resumida del Protocolo de enrutamiento de puerta de enlace interior mejorado (EIGRP) | 5 |
| Protocolo de puerta de enlace de frontera externa (BGP) | 20 |
| EIGRP interno | 90 |
| IGRP | 100 |
| OSPF | 110 |
| Sistema intermedio a sistema intermedio (IS-IS) | 115 |
| Protocolo de información de enrutamiento (RIP) | 120 |
| Protocolo de puerta de enlace exterior (EGP) | 140 |
| Enrutamiento bajo demanda (ODR) | 160 |
| EIGRP externo | 170 |
| BGP interno | 200 |
| Desconocido | 255 |
En el artículo de hoy veremos OSPF y EIGRP. Verá el primero en todas partes y todo el tiempo, y el segundo es muy bueno en redes donde solo hay equipos Cisco.
Cada uno de ellos tiene sus propias ventajas y desventajas. Podemos decir que EIGRP es superior a OSPF, pero todas las ventajas se ven compensadas por su naturaleza patentada. EIGRP es un protocolo propietario de Cisco y nadie más lo admite.
De hecho, EIGRP tiene muchas desventajas, pero esto no se analiza particularmente en artículos populares. Este es sólo uno de los problemas: SIA
Así que comencemos.
OSPF
Artículos y vídeos sobre cómo configurar montañas OSPF. Hay muchas menos descripciones de principios operativos. En general, lo que pasa aquí es que OSPF se puede configurar simplemente según los manuales, sin siquiera conocer los algoritmos SPF y los LSA incomprensibles. Y todo funcionará e incluso, muy probablemente, funcionará perfectamente: para eso está diseñado. Es decir, no es como con las VLAN, donde había que conocer la teoría hasta el formato del encabezado.Pero lo que distingue a un ingeniero de un informático es que comprende por qué su red funciona como lo hace y sabe, no peor que el propio OSPF, qué ruta elegirá el protocolo.
En el marco del artículo, que en este momento ya tiene 8.000 caracteres, no podremos profundizar en la teoría, pero sí consideraremos los puntos fundamentales.
Es muy simple y claro, por cierto, está escrito sobre OSPF en xgu.ru o en la Wikipedia en inglés.
Entonces, OSPFv2 funciona sobre IP y, específicamente, está diseñado solo para IPv4 (OSPFv3 no depende de protocolos de capa 3 y, por lo tanto, puede funcionar con IPv6).
Veamos cómo funciona usando el ejemplo de esta red simplificada:
Para empezar hay que decir que para que se desarrolle una amistad (relación de adyacencia) entre routers se deben cumplir las siguientes condiciones:
1) se deben configurar los mismos ajustes en OSPF Hola intervalo en aquellos enrutadores que están conectados entre sí. De forma predeterminada, son 10 segundos en redes de transmisión como Ethernet. Este es un tipo de mensaje KeepAlive. Es decir, cada 10 segundos, cada enrutador envía un paquete de saludo a su vecino para decir: "Oye, estoy vivo".
2) Debe ser el mismo Intervalo muerto sobre ellos. Normalmente son 4 intervalos de saludo: 40 segundos. Si no se recibe ningún saludo del vecino durante este tiempo, se considera inalcanzable y PANIC comienza el proceso de reconstruir la base de datos local y enviar actualizaciones a todos los vecinos.
3) Las interfaces conectadas entre sí deben estar en una subred,
4) OSPF le permite reducir la carga en la CPU de los enrutadores dividiendo el Sistema Autónomo en zonas. Así que aquí está números de zona también debe coincidir
5) Cada enrutador que participa en el proceso OSPF tiene su propio único identificador - ID del enrutador. Si no lo cuida, el enrutador lo seleccionará automáticamente en función de la información sobre las interfaces conectadas (la dirección más alta se selecciona de las interfaces activas en el momento en que comienza el proceso OSPF). Pero nuevamente, un buen ingeniero tiene todo bajo control, por lo que generalmente se crea una interfaz Loopback, a la que se le asigna una dirección con una máscara /32 y esto es lo que se asigna al ID del enrutador. Esto puede resultar útil para el mantenimiento y la resolución de problemas.
6) El tamaño de MTU debe coincidir
1) Calma. Estado OSPF - ABAJO
En este breve momento, no sucede nada en la red: todos guardan silencio.
2) El viento está aumentando: el enrutador envía paquetes de saludo a la dirección de multidifusión 224.0.0.5 desde todas las interfaces donde se ejecuta OSPF. El TTL de dichos mensajes es uno, por lo que solo los recibirán los enrutadores ubicados en el mismo segmento de red. R1 entra en estado INICIAR.
Los paquetes contienen la siguiente información:
- ID del enrutador
- Hola intervalo
- Intervalo muerto
- Vecinos
- Máscara de subred
- ID de área
- Prioridad del enrutador
- Direcciones de enrutadores DR y BDR
- Contraseña de autenticación
El mensaje de saludo del enrutador R1 lleva su ID de enrutador y no contiene vecinos porque aún no los tiene.
Después de recibir este mensaje de multidifusión, el enrutador R2 agrega R1 a su tabla de vecinos (si todos los parámetros necesarios coinciden).
Y envía un nuevo mensaje de saludo al R1 como unidifusión, que contiene el ID del enrutador de este enrutador y la lista de vecinos enumera todos sus vecinos. Entre otros vecinos de esta lista se encuentra el Router ID R1, es decir, el R2 ya lo considera vecino.
3) Amistad. Cuando R1 recibe este mensaje de saludo de R2, se desplaza por la lista de vecinos y encuentra su propio ID de enrutador en ella, agrega R2 a su lista de vecinos.
Ahora R1 y R2 son vecinos mutuos; esto significa que se ha establecido una relación de adyacencia entre ellos y el enrutador R1 entra en estado DOS VÍAS.
Consejos generales para todas las tareas:
Incluso si no sabes inmediatamente la respuesta y la solución, intenta pensar a qué se refiere la condición del problema:En una red real, al elegir la gama de subredes anunciadas, es necesario guiarse por las regulaciones y las necesidades inmediatas.
- ¿Qué características y configuración de protocolo?
- ¿Estas configuraciones son globales o están vinculadas a una interfaz específica?
Si no conoce o ha olvidado un comando, estas reflexiones probablemente le llevarán al contexto correcto, donde podrá simplemente adivinar o recordar cómo configurar lo que se requiere en la tarea utilizando una pista en la línea de comando.
Intente pensar de esta manera antes de ir a Google o a cualquier sitio en busca de comandos.
Antes de pasar a probar la velocidad y los enlaces de respaldo, hagamos una cosa más útil.
Si tuviéramos la oportunidad de captar tráfico en la interfaz FE0/0.2 msk-arbat-gw1, que está frente a los servidores, entonces veríamos que los mensajes de saludo vuelan hacia lo desconocido cada 10 segundos. No hay nadie con quien responder Hola, no hay nadie con quien establecer relaciones de adyacencia, por lo que no tiene sentido intentar enviar mensajes desde aquí.
Desactivarlo es muy sencillo:
msk-arbat-gw1(config)#enrutador OSPF 1
msk-arbat-gw1(config-router)#interfaz pasiva fastEthernet 0/0.2
Este comando debe darse para todas las interfaces que definitivamente no tienen vecinos OSPF (incluidas aquellas orientadas a Internet).
Como resultado, tendrás una imagen como esta:
*No puedo imaginar cómo no te has confundido todavía*
Además, este comando aumenta la seguridad: nadie de esta red se hará pasar por un enrutador y no intentará rompernos por completo.
Pasemos ahora a la parte más interesante: las pruebas.
No hay nada complicado en configurar OSPF en todos los enrutadores del Anillo Siberiano; puede hacerlo usted mismo.
Y después de eso la imagen debería ser la siguiente:
msk-arbat-gw1#sh IP vecino OSPF
172.16.255.32 1 COMPLETO/DR 00:00:31 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 COMPLETO/DR 00:00:31 172.16.2.18 FastEthernet0/1.5
172.16.255.80 1 COMPLETO/BDR 00:00:36 172.16.2.130 FastEthernet0/1.8
172.16.255.112 1 COMPLETO/BDR 00:00:37 172.16.2.197 FastEthernet1/0.911
San Petersburgo, Kemerovo, Krasnoyarsk y Vladivostok están conectados directamente.
msk-arbat-gw1#mostrar ruta ipTodos saben todo sobre todos.172.16.0.0/16 tiene subredes variables, 25 subredes, 6 máscaras
S 172.16.2.4/30 vía 172.16.2.2
O 172.16.2.160/30 a través de 172.16.2.130, 00:05:53, FastEthernet0/1.8
O 172.16.2.192/30 vía 172.16.2.197, 00:04:18, FastEthernet1/0.911
S 172.16.16.0/21 vía 172.16.2.2
S 172.16.24.0/22 vía 172.16.2.18
O 172.16.24.0/24 vía 172.16.2.18, 00:24:03, FastEthernet0/1.5
O 172.16.128.0/24 vía 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.129.0/26 vía 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.255.32/32 vía 172.16.2.2, 00:24:03, FastEthernet0/1.4
O 172.16.255.48/32 vía 172.16.2.18, 00:24:03, FastEthernet0/1.5
O 172.16.255.80/32 vía 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.255.96/32 vía 172.16.2.130, 00:04:18, FastEthernet0/1.8
vía 172.16.2.197, 00:04:18, FastEthernet1/0.911
O 172.16.255.112/32 vía 172.16.2.197, 00:04:28, FastEthernet1/0.911
¿Qué ruta se distribuye el tráfico de Moscú a Krasnoyarsk? La tabla muestra que krs-stolbi-gw1 está conectado directamente y lo mismo se puede ver en el seguimiento:
msk-arbat-gw1#traceroute 172.16.128.1
1 172.16.2.130 35 ms 8 ms 5 ms
Ahora rompemos la interfaz entre Moscú y Krasnoyarsk y vemos cuánto tiempo lleva restablecer el enlace.
No pasaron ni 5 segundos antes de que todos los enrutadores se enteraran del incidente y recalcularan sus tablas de enrutamiento:
msk-arbat-gw1(config-subif)#do sh ip ro 172.16.128.0
Conocido vía "OSPF 1", distancia 110, métrica 4, tipo intraárea
Última actualización de 172.16.2.197 en FastEthernet1/0.911, hace 00:00:53
Bloques de descriptores de enrutamiento:
* 172.16.2.197, desde 172.16.255.80, hace 00:00:53, vía FastEthernet1/0.911
La métrica de ruta es 4, el recuento de tráfico compartido es 1
Vld-gw1#sh ruta IP 172.16.128.0
Entrada de enrutamiento para 172.16.128.0/24
Conocido vía "OSPF 1", distancia 110, métrica 3, tipo intraárea
Última actualización de 172.16.2.193 en FastEthernet1/0, hace 00:01:57
Bloques de descriptores de enrutamiento:
* 172.16.2.193, desde 172.16.255.80, hace 00:01:57, vía FastEthernet1/0
La métrica de ruta es 3, el recuento de tráfico compartido es 1
Msk-arbat-gw1#traceroute 172.16.128.1
Escriba la secuencia de escape al aborto.
Seguimiento de la ruta hasta 172.16.128.1
1 172.16.2.197 4 ms 10 ms 10 ms
2 172.16.2.193 8 ms 11 ms 15 ms
3 172.16.2.161 15 ms 13 ms 6 ms
Es decir, ahora el tráfico llega a Krasnoyarsk de esta manera:
Tan pronto como se establece el enlace, los enrutadores se comunican nuevamente, intercambian sus bases de datos, recalculan las rutas más cortas y las ingresan en la tabla de enrutamiento.
El vídeo deja todo esto más claro. recomiendo familiarizarse.
Después de configurar OSPF en los enrutadores del anillo siberiano, todas las redes ubicadas detrás del enrutador en oficina central en Moscú (msk-arbat-gw1), para Khabarovsk están disponibles en dos rutas (vía Krasnoyarsk y vía Vladivostok). Pero, dado que el canal a través de Krasnoyarsk es mejor, es necesario cambiar la configuración predeterminada para que Khabarovsk utilice el canal a través de Krasnoyarsk cuando esté disponible. Y se mudó a Vladivostok solo si algo le sucedía al canal a Krasnoyarsk.
Como cualquier buen protocolo, OSPF admite la autenticación: dos vecinos pueden verificar la autenticidad de los mensajes OSPF recibidos antes de establecer relaciones de adyacencia. Te dejamos que estudies por tu cuenta: es bastante sencillo.
EIGRP
Ahora pasemos a otro protocolo muy importante.Entonces, ¿qué tiene de bueno EIGRP?
- fácil de configurar
- cambio rápido a calculado de antemano ruta alternativa
- requiere menos recursos del enrutador (en comparación con OSPF)
- resumen de rutas en cualquier enrutador (en OSPF solo en ABR\ASBR)
- equilibrio de tráfico en rutas desiguales (OSPF solo en rutas iguales)
Decidimos traducir una de las entradas del blog de Ivan Pepelnyak, que aborda una serie de mitos populares sobre EIGRP:
- "EIGRP es un protocolo de enrutamiento híbrido". Si mal no recuerdo, esto comenzó con la primera presentación de EIGRP hace muchos años y generalmente se entiende como "EIGRP tomó lo mejor de los protocolos de estado de enlace y vector de distancia". Esto es absolutamente falso. EIGRP no tiene ninguna característica distintiva de estado de enlace. Sería correcto decir "EIGRP es un protocolo avanzado de enrutamiento por vector de distancia".
- “EIGRP es un protocolo de vector distancia”. No está mal, pero tampoco del todo cierto. EIGRP se diferencia de otros DV en la forma en que maneja rutas huérfanas (o rutas con métricas crecientes). Todos los demás protocolos esperan pasivamente actualizaciones de información de un vecino (algunos, como RIP, incluso bloquean la ruta para evitar bucles de enrutamiento), mientras que EIGRP es más activo y solicita información por sí mismo.
- “EIGRP es difícil de implementar y mantener”. No es cierto. Hubo un tiempo en que EIGRP en redes grandes con enlaces de baja velocidad era difícil de implementar correctamente, pero solo hasta que se introdujeron los enrutadores auxiliares. Con ellos (además de varias correcciones al algoritmo DUAL), es casi peor que OSPF.
- “Al igual que los protocolos LS, EIGRP mantiene una tabla de la topología de las rutas que se intercambian”. Es sorprendente lo equivocado que está esto. EIGRP no tiene idea alguna de lo que hay más allá de sus vecinos inmediatos, mientras que los protocolos LS conocen exactamente la topología de toda el área a la que están conectados.
- "EIGRP es un protocolo DV que actúa como LS". Buen intento, pero sigue siendo completamente incorrecto. Los protocolos LS crean una tabla de enrutamiento siguiendo los siguientes pasos:
- cada enrutador describe la red en función de la información disponible localmente (sus enlaces, las subredes en las que se encuentra, los vecinos que ve) a través de un paquete (o varios) llamado LSA (en OSPF) o LSP (IS-IS)
- Los LSA se propagan por toda la red. Cada enrutador debe recibir cada LSA creado en su red. La información recibida del LSA se ingresa en la tabla de topología.
- Cada enrutador analiza de forma independiente su tabla de topología y ejecuta el algoritmo SPF para calcular las mejores rutas a cada uno de los demás enrutadores.
El comportamiento de EIGRP ni siquiera se acerca a estos pasos, por lo que no está claro por qué diablos "actúa como LS".Lo único que hace EIGRP es almacenar la información recibida de un vecino (RIP olvida inmediatamente lo que no se puede utilizar en este momento). En este sentido, es similar a BGP, que también almacena todo en una tabla BGP y elige la mejor ruta a partir de ahí. La tabla de topología (que contiene toda la información recibida de los vecinos) le da a EIGRP una ventaja sobre RIP: puede contener información sobre una ruta de respaldo (no utilizada actualmente).
Ahora un poco más cerca de la teoría del trabajo:
Cada proceso EIGRP mantiene 3 tablas:
- Una tabla de vecinos, que contiene información sobre "vecinos", es decir. otros enrutadores conectados directamente al actual y participando en el intercambio de rutas. Puedes verlo usando el comando mostrar vecinos ip eigrp
- Tabla de topología de red, que contiene información de ruta recibida de los vecinos. Miremos en equipo mostrar topología ip eigrp
- La tabla de enrutamiento, a partir de la cual el enrutador toma decisiones sobre la redirección de paquetes. Ver vía mostrar ruta ip
Métrica.
Para evaluar la calidad de una ruta en particular, los protocolos de enrutamiento utilizan un número determinado que refleja sus diversas características o un conjunto de características: una métrica. Las características que se tienen en cuenta pueden ser diferentes, desde la cantidad de enrutadores en una ruta determinada hasta el promedio aritmético de la carga en todas las interfaces a lo largo de la ruta. Respecto a la métrica EIGRP, citando a Jeremy Cioara: “Tuve la impresión de que los creadores de EIGRP, al observar críticamente su creación, decidieron que todo era demasiado simple y funcionaba bien. Y luego se les ocurrió una fórmula métrica para que todos dijeran "GUAU, esto es realmente complicado y parece profesional". Vea la fórmula completa para calcular la métrica EIGRP: (K1 * bw + (K2 * bw) / (256 - carga) + K3 * retraso) * (K5 / (confiabilidad + K4)), en la que:
- bw no es solo ancho de banda, sino (10000000/ancho de banda más pequeño a lo largo de la ruta en kilobits) * 256
- el retraso no es solo un retraso, sino la suma de todos los retrasos en el camino hacia decenas de microsegundos* 256 (¡el retraso en los comandos show interface, show ip eigrp topology y otros se muestra en microsegundos!)
- K1-K5 son coeficientes que sirven para asegurar que uno u otro parámetro esté “incluido” en la fórmula.
¿Aterrador? lo sería si todo funcionara como está escrito. De hecho, de los 4 términos posibles de la fórmula, solo se usan dos por defecto: bw y retraso (coeficientes K1 y K3 = 1, el resto son cero), lo que lo simplifica enormemente: simplemente sumamos estos dos números (aunque no olvidando que todavía se calculan según sus propias fórmulas). Es importante recordar lo siguiente: la métrica se calcula según el peor indicador de rendimiento a lo largo de toda la ruta.
Si K5=0, entonces se utiliza la siguiente fórmula: Métrica = (K1 * bw + (K2 * bw) / (256 - carga) + (K3 * retraso)
Algo interesante sucedió con MTU: muy a menudo puedes encontrar información de que MTU está relacionada con la métrica EIGRP. De hecho, los valores de MTU se transmiten al intercambiar rutas. Pero, como podemos ver en la fórmula completa, allí no se menciona MTU. El caso es que este indicador se tiene en cuenta en casos bastante concretos: por ejemplo, si un router debe descartar una de las rutas equivalentes en otras características, elegirá la que tenga menor MTU. Aunque no todo es tan sencillo (ver comentarios).
Definamos los términos utilizados dentro de EIGRP. Cada ruta en EIGRP se caracteriza por dos números: Distancia factible y Distancia anunciada (en lugar de Distancia anunciada, a veces puede ver Distancia informada, esto es lo mismo). Cada uno de estos números representa una métrica, o costo (cuanto más, peor) de una ruta determinada desde diferentes puntos de medición: FD es “de mí al destino”, y AD es “del vecino que me habló de esta ruta hasta las citas del lugar." La respuesta a la pregunta lógica "¿Por qué necesitamos saber el costo de un vecino si ya está incluido en el DF?" es un poco menor (por ahora, si lo desea, puede detenerse y devanarse los sesos).
Para cada subred que EIGRP conoce, en cada enrutador hay un enrutador sucesor entre sus vecinos, a través del cual pasa la mejor ruta (con una métrica más baja), según el protocolo, a esta subred. Además, una subred también puede tener una o más rutas de respaldo (el enrutador vecino a través del cual pasa dicha ruta se denomina sucesor factible). EIGRP es el único protocolo de enrutamiento que recuerda rutas de respaldo (OSPF las tiene, pero están contenidas, por así decirlo, en "forma cruda" en la tabla de topología; aún deben ser procesadas por el algoritmo SPF), lo que le da una Ventaja de rendimiento: tan pronto como el protocolo determina que la ruta principal (a través del sucesor) no está disponible, cambia inmediatamente a la ruta de respaldo. Para que un enrutador se convierta en un sucesor factible de una ruta, su AD debe ser menor que el FD sucesor de esta ruta (es por eso que necesitamos conocer AD). Esta regla se utiliza para evitar bucles de enrutamiento.
¿El párrafo anterior te dejó boquiabierto? El material es difícil, así que usaré un ejemplo nuevamente. Tenemos esta red:
Desde el punto de vista del R1, el R2 es el sucesor de la subred 192.168.2.0/24. Para convertirse en un FS para esta subred, R4 requiere que su AD sea menor que el FD para esta ruta. Tenemos FD ((10000000/1544)*256)+(2100*256) =2195456, R4 tiene AD (desde su punto de vista esto es FD, es decir, cuánto le cuesta llegar a esta red) = (( 10000000/100000 )*256)+(100*256)=51200. Todo converge, el AD de R4 es menor que el FD de la ruta, se convierte en FS. *entonces el cerebro dice: “BDASH”*. Ahora miramos a R3: anuncia su red 192.168.1.0/24 a su vecino R1, quien, a su vez, se lo cuenta a sus vecinos R2 y R4. R4 no sabe que R2 conoce esta subred y decide decírselo. R2 transmite la información a la que tiene acceso a través de R4 a la subred 192.168.1.0/24 y luego a R1. R1 mira estrictamente el FD de la ruta y el AD, del que se jacta R2 (que, como se desprende del diagrama, será claramente más grande que el FD, ya que también lo incluye a él) y lo ahuyenta para no interferir con todo tipo de tonterías. Esta situación es bastante improbable, pero puede ocurrir en determinadas circunstancias, por ejemplo, cuando el mecanismo de horizonte dividido está desactivado. Y ahora a una situación más probable: imagine que R4 está conectado a la red 192.168.2.0/24 no a través de FastEthernet, sino a través de un módem de 56k (el retraso para el acceso telefónico es de 20,000 usec), respectivamente, le cuesta ((10000000/56 )*256 )+(2000*256)= 46226176. Esto es más que el FD para esta ruta, por lo que R4 no se convertirá en un sucesor factible. Pero esto no significa que EIGRP no utilizará esta ruta en absoluto. Simplemente tomará más tiempo cambiar a él (más sobre esto más adelante).
Vecindario
Los enrutadores no hablan de rutas con cualquiera: deben establecer relaciones de adyacencia antes de poder intercambiar información. Luego de encender el proceso con el comando router eigrp, indicando el número del sistema autónomo, nosotros, con el comando network, decimos qué interfaces participarán y al mismo tiempo, información sobre qué redes queremos distribuir. Inmediatamente, los paquetes de saludo comienzan a enviarse a través de estas interfaces a la dirección de multidifusión 224.0.0.10 (de forma predeterminada, cada 5 segundos para Ethernet). Todos los enrutadores con EIGRP habilitado reciben estos paquetes, luego cada enrutador receptor hace lo siguiente:- comprueba la dirección del remitente del paquete de saludo con la dirección de la interfaz desde la que se recibió el paquete y se asegura de que sean de la misma subred
- compara los valores de los coeficientes K obtenidos del paquete (en otras palabras, qué variables se utilizan para calcular la métrica) con los suyos propios. Está claro que si difieren, las métricas de las rutas se calcularán según reglas diferentes, lo cual es inaceptable.
- comprueba el número del sistema autónomo
- opcional: si la autenticación está configurada, verifica la coherencia de su tipo y claves.
Si el destinatario está satisfecho con todo, agrega al remitente a la lista de sus vecinos y le envía (ya en Unicast) un paquete de actualización, que contiene una lista de todas las rutas que conoce (también conocida como actualización completa). El remitente, al recibir dicho paquete, a su vez, hace lo mismo. Para intercambiar rutas, EIGRP utiliza el Protocolo de transporte confiable (RTP, que no debe confundirse con el Protocolo de transporte en tiempo real, que se usa en telefonía IP), lo que implica una confirmación de entrega, por lo que cada uno de los enrutadores, habiendo recibido un paquete de actualización, responde con un paquete de confirmación (abreviatura de acuse de recibo - confirmación). Entonces, se ha establecido la relación de vecindad, los enrutadores han aprendido unos de otros información completa sobre las rutas, ¿qué sigue? Luego continuarán enviando paquetes de saludo de multidifusión para confirmar que están conectados y, si la topología cambia, actualizarán paquetes que contengan información solo sobre los cambios (actualización parcial).
Ahora volvamos al esquema anterior con el módem.
Por alguna razón, R2 perdió contacto con 192.168.2.0/24. No tiene rutas de respaldo a esta subred (es decir, no tiene FS). Como cualquier enrutador EIGRP responsable, quiere restablecer la conectividad. Para ello, comienza a enviar mensajes especiales (paquetes de consulta) a todos sus vecinos, quienes, a su vez, al no encontrar por sí mismos la ruta deseada, preguntan a todos sus vecinos, y así sucesivamente. Cuando la ola de solicitudes llega a R4, dice “¡espera un minuto, tengo una ruta a esta subred! Malo, pero al menos algo. Todos se olvidaron de él, pero yo lo recuerdo”. Empaqueta todo esto en un paquete de respuesta y lo envía al vecino de quien recibió la solicitud (consulta), y más adelante en la cadena. Por supuesto, todo esto lleva más tiempo que simplemente cambiar a Feasible Successor, pero al final conseguimos comunicarnos con la subred.
Y ahora es un momento peligroso: tal vez ya lo hayas notado y te hayas vuelto cauteloso después de leer sobre este correo de fans. La falla de una interfaz causa algo similar a una tormenta de transmisión en la red (no en tal escala, por supuesto, pero aún así), y cuantos más enrutadores haya, más recursos se gastarán en todas estas solicitudes y respuestas. Pero eso no es tan malo. Es posible una situación peor: imagine que los enrutadores que se muestran en la imagen son solo una parte de una red grande y distribuida, es decir. algunos pueden estar situados a muchos miles de kilómetros de nuestro R2, en malos canales, etc. Entonces, el problema es que, al enviar una consulta a un vecino, el enrutador debe esperar su respuesta. No importa cuál sea la respuesta, pero debe llegar. Incluso si el enrutador ya recibió una respuesta positiva, como en nuestro caso, no puede poner en funcionamiento esta ruta hasta que espere respuesta a todas sus solicitudes. Y tal vez todavía haya solicitudes en algún lugar de Alaska. Este estado de ruta se denomina atascado en activo. Aquí necesitamos familiarizarnos con los términos que reflejan el estado de la ruta en EIGRP: ruta activa\pasiva. Suelen ser engañosos. El sentido común dicta que activo significa que la ruta está “activa”, habilitada y en ejecución. Sin embargo, aquí todo es al revés: pasivo significa "todo está bien" y activo significa que esta subred no está disponible y el enrutador está buscando activamente otra ruta, enviando una consulta y esperando una respuesta. Por lo tanto, ¡el estado de estancamiento activo puede durar hasta 3 minutos! Una vez transcurrido este período, el enrutador rompe la relación de vecino con el vecino del cual no puede esperar una respuesta y puede usar una nueva ruta a través de R4.
Una historia que le hiela la sangre a un ingeniero de redes. 3 minutos de inactividad no son una broma. ¿Cómo podemos evitar el infarto de esta situación? Hay dos salidas: resumir rutas y la llamada configuración stub.
En términos generales, hay otra salida: se llama filtrado de rutas. Pero este es un tema tan voluminoso que sería mejor escribir un artículo aparte, pero esta vez ya tenemos medio libro. Así que depende de ti.
Como ya mencionamos, en EIGRP el resumen de rutas se puede realizar en cualquier enrutador. Para ilustrar, imaginemos que las subredes de 192.168.0.0/24 a 192.168.7.0/24 están conectadas a nuestro sufrido R2, que muy convenientemente suma 192.168.0.0/21 (recuerde las matemáticas binarias). El enrutador anuncia esta ruta resumida y todos los demás lo saben: si la dirección de destino comienza con 192.168.0-7, entonces es para él. ¿Qué pasa si una de las subredes desaparece? El enrutador enviará paquetes de consulta con la dirección de esta red (específica, por ejemplo, 192.168.5.0/24), pero los vecinos, en lugar de continuar con el envío de correos viciosos por su cuenta, responderán inmediatamente con repeticiones aleccionadoras, diciendo que esto es tu subred, lo averiguas.
La segunda opción es la configuración de código auxiliar. En sentido figurado, stub significa "final del camino", "callejón sin salida" en EIGRP, es decir, ingresar a alguna subred que no está conectada directamente a dicho enrutador, tendrá que regresar. Un enrutador configurado como stub no reenviará tráfico entre subredes que conoce de EIGRP (en otras palabras, que están marcadas con la letra D en show ip route). Además, sus vecinos no le enviarán paquetes de consultas. El caso de uso más común son las topologías hub-and-spoke, especialmente con enlaces redundantes. Tomemos esta red: a la izquierda están las sucursales, a la derecha está el sitio principal, la oficina principal, etc. Para tolerancia a fallos, enlaces redundantes. EIGRP se ejecuta con la configuración predeterminada.
Y ahora “atención, pregunta”: ¿qué pasará si R1 pierde conexión con R4 y R5 pierde LAN? El tráfico desde la subred R1 a la subred de la oficina principal seguirá la ruta R1->R5->R2 (o R3)->R4. ¿Será efectivo? No. No sólo se verá afectada la subred detrás de R1, sino también la subred detrás de R2 (o R3), debido al aumento en los volúmenes de tráfico y sus consecuencias. Es para tales situaciones que se inventó el stub. Detrás de los enrutadores en las sucursales no hay otros enrutadores que conduzcan a otras subredes, este es el "final del camino", luego solo de regreso. Por lo tanto, con tranquilidad, podemos configurarlos como stubs, lo que, en primer lugar, nos salvará del problema descrito anteriormente con la "ruta torcida" y, en segundo lugar, de la avalancha de paquetes de consulta en caso de que se pierda la ruta.
Hay diferentes modos de operación de un enrutador stub; se configuran con el comando eigrp stub:
R1(config)#enrutador eigrp 1De forma predeterminada, si simplemente ejecuta el comando eigrp stub, se habilitan los modos conectado y resumen. De interés es el modo de solo recepción, en el que el enrutador no anuncia ninguna red, solo escucha lo que le dicen sus vecinos (en RIP hay un comando de interfaz pasivo que hace lo mismo, pero en EIGRP desactiva completamente el protocolo en la interfaz seleccionada, que no permite establecer una vecindad).
¿R1(config-router)#eigrp trozo?
conectado Anunciar rutas conectadas
mapa de fugas Permitir prefijos dinámicos basados en el mapa de fugas
solo recepción Establecer IP-EIGRP como vecino de solo recepción
redistribuido Anuncie rutas redistribuidas
estático Anunciar rutas estáticas
resumen Anunciar rutas resumidas
Puntos importantes de la teoría EIGRP que no se incluyeron en el artículo:
- La autenticación de vecinos se puede configurar en EIGRP
- Concepto de cierre elegante
Práctica EIGRP
Lift mi Up compró una fábrica en Kaliningrado. Allí se fabrican los cerebros de los ascensores: microcircuitos, software. La fábrica es muy grande: tres puntos alrededor de la ciudad, tres enrutadores conectados en anillo.
Pero mala suerte: ya tienen EIGRP ejecutándose como protocolo de enrutamiento dinámico. Además, el direccionamiento de los nodos finales se realiza desde una subred completamente diferente: 10.0.0.0/8. Cambiamos todos los demás parámetros (direcciones de enlace, direcciones de interfaz loopback), pero varios miles de direcciones de red local con servidores, impresoras, puntos de acceso (ni un trabajo durante un par de horas) se pospusieron para más tarde, y en el plan IP reservamos el Subred 172.16 para el futuro para Kaliningrado .32.0/20.
Actualmente utilizamos las siguientes redes:
¿Cómo se configura este milagro? Sencillo a primera vista:
enrutador eigrp 1
red 172.16.0.0 0.0.255.255
red 10.0.0.0
En EIGRP, se puede especificar la máscara inversa, lo que indica un alcance más limitado, o no se especifica, luego se seleccionará la máscara estándar para esta clase (16 para la clase B - 172.16.0.0 y 8 para la clase A - 10.0.0.0)
Estos comandos se emiten en todos los enrutadores del sistema autónomo. El AC está determinado por el número en el comando router eigrp, es decir, en nuestro caso tenemos el AC N°1. Esta cifra debería ser la misma en todos los enrutadores (a diferencia de OSPF).
Pero hay un problema grave en EIGRP: de forma predeterminada, el resumen automático de rutas en forma de clase está habilitado (en versiones de IOS hasta 15).
Comparemos las tablas de enrutamiento de tres enrutadores de Kaliningrado:
La red 10.0.0.1/24 está conectada a klgr-center-gw1 y él lo sabe:
klgr-centro-gw1:
10.0.0.0/8 tiene subredes variables, 2 subredes, 2 máscaras
D 10.0.0.0/8 es un resumen, 00:35:23, Null0
C 10.0.0.0/24 está conectado directamente, FastEthernet1/0
Pero no sabe acerca de 10.0.1.0/24 y 10.0.2.0/24/
Klgr-balt-gw1 conoce sus dos redes 10.0.1.0/24 y 10.0.2.0/24, pero ocultó la red 10.0.0.0/24 en algún lugar.
10.0.0.0/8 tiene subredes variables, 3 subredes, 2 máscaras
D 10.0.0.0/8 es un resumen, 00:42:05, Null0
C 10.0.1.0/24 está conectado directamente, FastEthernet1/1.2
C 10.0.2.0/24 está conectado directamente, FastEthernet1/1.3
Ambos crearon la ruta 10.0.0.0/8 con la dirección del siguiente salto Null0.
Pero klgr-center-gw2 sabe que las subredes 10.0.0.0/8 están ubicadas detrás de sus dos interfaces WAN.
D 10.0.0.0/8 vía 172.16.2.41, 00:42:49, FastEthernet0/1
vía 172.16.2.45, 00:38:05, FastEthernet0/0
Algo muy extraño está sucediendo.
Pero, si revisas la configuración de este enrutador, probablemente notarás:
enrutador eigrp 1
red 172.16.0.0
red 10.0.0.0
resumen automático
La suma automática tiene la culpa de todo. Este es el mayor mal de EIGRP. Echemos un vistazo más de cerca a lo que está sucediendo. klgr-center-gw1 y klgr-balt-gw1 tienen subredes de 10.0.0.0/8, las resumen de forma predeterminada cuando las pasan a sus vecinos.
Es decir, por ejemplo, klgr-balt-gw1 no transmite dos redes 10.0.1.0/24 y 10.0.2.0/24, sino una generalizada: 10.0.0.0/8. Es decir, su vecino pensará que detrás de klgr-balt-gw1 se encuentra toda esta red.
Pero, ¿qué pasa si de repente balt-gw1 recibe un paquete con destino 10.0.50.243, del que no sabe nada? Para este caso se crea la ruta denominada Blackhole:
10.0.0.0/8 es un resumen, 00:42:05, Null0
El paquete resultante será arrojado a este agujero negro. Esto se hace para evitar bucles de enrutamiento.
Entonces, ambos enrutadores crearon sus propias rutas de agujeros negros e ignoraron los anuncios de otras personas. En realidad, en una red de este tipo, estos tres dispositivos no podrán comunicarse entre sí hasta... hasta que desactive el resumen automático.
Lo primero que debes hacer al configurar EIGRP es:
enrutador eigrp 1
sin resumen automático
En todos los dispositivos. Y todos estarán bien:
Klgr-centro-gw1:
C 10.0.0.0 está conectado directamente, FastEthernet1/0
D 10.0.1.0 vía 172.16.2.37, 00:03:11, FastEthernet0/0
D 10.0.2.0 a través de 172.16.2.37, 00:03:11, FastEthernet0/0
klgr-balt-gw1
10.0.0.0/24 está dividido en subredes, 3 subredes
D 10.0.0.0 a través de 172.16.2.38, 00:08:16, FastEthernet0/1
C 10.0.1.0 está conectado directamente, FastEthernet1/1.2
C 10.0.2.0 está conectado directamente, FastEthernet1/1.3
klgr-centro-gw2:
10.0.0.0/24 está dividido en subredes, 3 subredes
D 10.0.0.0 a través de 172.16.2.45, 00:11:50, FastEthernet0/0
D 10.0.1.0 vía 172.16.2.41, 00:11:48, FastEthernet0/1
D 10.0.2.0 vía 172.16.2.41, 00:11:48, FastEthernet0/1
Configurar la transferencia de rutas entre diferentes protocolos
Nuestra tarea es organizar la transferencia de rutas entre estos protocolos: de OSPF a EIGRP y viceversa, para que todos conozcan la ruta a cualquier subred.Esto se llama redistribución de rutas.
Para implementarlo, necesitamos al menos un punto de unión donde se lanzarán dos protocolos simultáneamente. Podría ser msk-arbat-gw1 o klgr-balt-gw1. Elijamos el segundo.
De a EIGRP d OSPF:
klgr-gw1(config)#enrutador ospf 1
klgr-gw1(config-router)#redistribuir subredes eigrp 1
Miramos las rutas en msk-arbat-gw1:
msk-arbat-gw1#sh ruta IP
Códigos: C - conectado, S - estático, I - IGRP, R - RIP, M - móvil, B - BGP
D - EIGRP, EX - EIGRP externo, O - OSPF, IA - OSPF entre áreas
N1 - OSPF NSSA externo tipo 1, N2 - OSPF NSSA externo tipo 2
E1 - OSPF externo tipo 1, E2 - OSPF externo tipo 2, E - EGP
i - IS-IS, L1 - IS-IS nivel-1, L2 - IS-IS nivel-2, ia - IS-IS entre áreas
* - candidato predeterminado, U - ruta estática por usuario, o - ODR
P - ruta estática descargada periódicamenteLa puerta de enlace de último recurso es 198.51.100.1 a la red 0.0.0.0
10.0.0.0/8 tiene subredes variables, 3 subredes, 2 máscaras
O E2 10.0.0.0/8 vía 172.16.2.34, 00:25:11, FastEthernet0/1.7
O E2 10.0.1.0/24 vía 172.16.2.34, 00:25:11, FastEthernet0/1.7
O E2 10.0.2.0/24 vía 172.16.2.34, 00:24:50, FastEthernet0/1.7
172.16.0.0/16 tiene subredes variables, 30 subredes, 5 máscaras
O E2 172.16.0.0/16 vía 172.16.2.34, 00:25:11, FastEthernet0/1.7
C 172.16.0.0/24 está conectado directamente, FastEthernet0/0.3
C 172.16.1.0/24 está conectado directamente, FastEthernet0/0.2
C 172.16.2.0/30 está conectado directamente, FastEthernet0/1.4
C 172.16.2.16/30 está conectado directamente, FastEthernet0/1.5
C 172.16.2.32/30 está conectado directamente, FastEthernet0/1.7
O E2 172.16.2.36/30 vía 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.2.40/30 vía 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.2.44/30 vía 172.16.2.34, 01:00:55, FastEthernet0/1.7
C 172.16.2.128/30 está conectado directamente, FastEthernet0/1.8
172.16.2.160/30 a través de 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.2.192/30 vía 172.16.2.197, 00:13:21, FastEthernet1/0.911
C 172.16.2.196/30 está conectado directamente, FastEthernet1/0.911
C 172.16.3.0/24 está conectado directamente, FastEthernet0/0.101
C 172.16.4.0/24 está conectado directamente, FastEthernet0/0.102
C 172.16.5.0/24 está conectado directamente, FastEthernet0/0.103
C 172.16.6.0/24 está conectado directamente, FastEthernet0/0.104
O 172.16.24.0/24 vía 172.16.2.18, 01:00:55, FastEthernet0/1.5
O 172.16.128.0/24 vía 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.129.0/26 vía 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.144.0/24 vía 172.16.2.130, 00:13:21, FastEthernet0/1.8
O 172.16.160.0/24 vía 172.16.2.197, 00:13:31, FastEthernet1/0.911
C 172.16.255.1/32 está conectado directamente, Loopback0
O 172.16.255.48/32 vía 172.16.2.18, 01:00:55, FastEthernet0/1.5
O E2 172.16.255.64/32 vía 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.255.65/32 vía 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.255.66/32 vía 172.16.2.34, 01:00:55, FastEthernet0/1.7
O 172.16.255.80/32 vía 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.255.96/32 vía 172.16.2.130, 00:13:21, FastEthernet0/1.8
vía 172.16.2.197, 00:13:21, FastEthernet1/0.911
O 172.16.255.112/32 vía 172.16.2.197, 00:13:31, FastEthernet1/0.911
198.51.100.0/28 está dividido en subredes, 1 subred
C 198.51.100.0 está conectado directamente, FastEthernet0/1.6
S* 0.0.0.0/0 vía 198.51.100.1
Aquí están los que tienen la etiqueta E2: nuevas rutas importadas. E2: significa que estas son rutas externas del segundo tipo (externas), es decir, se introdujeron en el proceso OSPF desde el exterior.
Ahora de OSPF a EIGRP. Esto es un poco más complicado:
klgr-gw1(config)#enrutador eigrp 1
klgr-gw1(config-router)#redistribuir ospf 1 métrica 100000 20 255 1 1500
Sin especificar la métrica (este largo conjunto de números), el comando se ejecutará, pero no se producirá la redistribución.
Las rutas importadas reciben una etiqueta EX en la tabla de enrutamiento y una distancia administrativa de 170, en lugar de 90 para las internas:
klgr-gw2#sh ruta IPLa puerta de enlace de último recurso no está configurada
172.16.0.0/16 tiene subredes variables, 30 subredes, 4 máscaras
D EX 172.16.0.0/24 [170 /33280] a través de 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.1.0/24 a través de 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.0/30 a través de 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.4/30 a través de 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.16/30 a través de 172.16.2.37, 00:00:07, FastEthernet0/0
D 172.16.2.32/30 [ 90 /30720] a través de 172.16.2.37, 00:38:59, FastEthernet0/0
C 172.16.2.36/30 está conectado directamente, FastEthernet0/0
D 172.16.2.40/30 vía 172.16.2.37, 00:38:59, FastEthernet0/0
vía 172.16.2.46, 00:38:59, FastEthernet0/1
….
Así es como parece hacerse de una manera simple, pero la simplicidad es superficial: la redistribución está plagada de muchos momentos sutiles y desagradables cuando se agrega al menos un vínculo redundante entre dos dominios diferentes.
Consejo general: trate de evitar la redistribución si es posible. Aquí funciona la regla principal de la vida: cuanto más simple, mejor.
Ruta predeterminada
Ahora es el momento de comprobar su acceso a Internet. Funciona bien desde Moscú, pero si marca, por ejemplo, desde San Petersburgo (recuerde que eliminamos todas las rutas estáticas):ordenador>ping
Haciendo ping a 192.0.2.2 con 32 bytes de datos:
Respuesta de 172.16.2.5: Host de destino inalcanzable.
Respuesta de 172.16.2.5: Host de destino inalcanzable.
Respuesta de 172.16.2.5: Host de destino inalcanzable.
Estadísticas de ping para 192.0.2.2:
Paquetes: enviados = 4, recibidos = 0, perdidos = 4 (pérdida del 100%),
Esto se debe a que ni spb-ozerki-gw1, ni spb-vsl-gw1, ni nadie más en nuestra red conocen la ruta predeterminada, excepto msk-arbat-gw1, en la que está configurada estáticamente.
Para corregir esta situación, basta con dar una orden en Moscú:
msk-arbat-gw1(config)#enrutador ospf 1
msk-arbat-gw1 (config-router) # origen de información predeterminada
Después de esto, la información sobre dónde se encuentra la puerta de enlace de último recurso se propaga por la red.
Internet ya está disponible:
PC>tracert
Ruta de seguimiento a 192.0.2.2 en un máximo de 30 saltos:
1 3 ms 3 ms 3 ms 172.16.17.1
2 4 ms 5 ms 12 ms 172.16.2.5
3 14 ms 20 ms 9 ms 172.16.2.1
4 17 ms 17 ms 19 ms 198.51.100.1
5 22 ms 23 ms 19 ms 192.0.2.2
Comandos útiles para solucionar problemas
1) La lista de vecinos y el estado de comunicación con ellos se llama mediante el comando. mostrar ip ospf vecinomsk-arbat-gw1:
ID de vecino Pri Estado Tiempo muerto Dirección Interfaz
172.16.255.32 1 COMPLETO/DROTHER 00:00:33 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 COMPLETO/DR 00:00:34 172.16.2.18 FastEthernet0/1.5
172.16.255.64 1 COMPLETO/DR 00:00:33 172.16.2.34 FastEthernet0/1.7
172.16.255.80 1 COMPLETO/DR 00:00:33 172.16.2.130 FastEthernet0/1.8
172.16.255.112 1 COMPLETO/DR 00:00:33 172.16.2.197 FastEthernet1/0.911
2) O para EIGRP: mostrar vecinos ip eigrp
Vecinos IP-EIGRP para el proceso 1
H Dirección Interfaz Tiempo de actividad SRTT RTO Q Seq
(seg) (ms) Núm Cnt
0 172.16.2.38 Fa0/1 12 00:04:51 40 1000 0 54
1 172.16.2.42 Fa0/0 13 00:04:51 40 1000 0 58
3) Usando el comando mostrar protocolos ip Puede ver información sobre la ejecución de protocolos de enrutamiento dinámico y sus relaciones.
Klgr-balt-gw1:
El protocolo de enrutamiento es "EIGRP 1"
Redes predeterminadas marcadas en actualizaciones salientes
Redes predeterminadas aceptadas de actualizaciones entrantes
Peso métrico EIGRP K1=1, K2=0, K3=1, K4=0, K5=0
Número máximo de saltos de EIGRP 100
Varianza métrica máxima de EIGRP 1
Redistribución: EIGRP 1, OSPF 1
El resumen automático de red está en vigor.
Resumen automático de direcciones:
Ruta máxima: 4
Enrutamiento para redes:
172.16.0.0
172.16.2.42 90 4
172.16.2.38 90 4
Distancia: interna 90 externa 170
El protocolo de enrutamiento es "OSPF 1"
La lista de filtros de actualización saliente para todas las interfaces no está configurada
La lista de filtros de actualización entrante para todas las interfaces no está configurada
ID del enrutador 172.16.255.64
Es un enrutador de límites de sistema autónomo.
Redistribuir rutas externas desde,
EIGRP 1
El número de áreas en este enrutador es 1. 1 normal 0 stub 0 nssa
Ruta máxima: 4
Enrutamiento para redes:
172.16.2.32 0.0.0.3 área 0
Fuentes de información de rutas:
Distancia de puerta de enlace Última actualización
172.16.255.64 110 00:00:23
Distancia: (el valor predeterminado es 110)
4) Para depurar y comprender el funcionamiento de los protocolos, será útil utilizar los siguientes comandos:
depurar eventos IP OSPF
depurar IP OSPF adj.
depurar paquetes EIGRP
Intente probar diferentes interfaces y vea qué sucede en la depuración, qué mensajes aparecen.
Autores
marat eucarioteMaxim también conocido como gluck
Me gustaría expresar mi gratitud a Dmitry JDima por las ediciones y los valiosos comentarios, y a la irresistible Natasha Samoilenko por las tareas realizadas. Anton Avtushko por programar el sitio del blog. Y a la chica con el glorioso nombre Nina por el logo del sitio.
PD
Nuestro próximo podcast LinkMiAp necesita un jingle y música de fondo. Estaremos encantados de ayudarle y el nombre del compositor será glorificado durante siglos.
PPS
Ya no tenemos suficientes capacidades de Packet Tracer. El siguiente paso es pasar a algo más serio. ¿Alguna sugerencia? Propongo organizar un holivar en los comentarios sobre el tema IOU vs GNS.
