Redistribución de Rutas-Parte 1

ccie r / s ccnp r / s Sep 25, 2018

Introducción a la Redistribución de rutas

Hasta que no haya un protocolo de enrutamiento para gobernarlos a todos, es necesario que coexistan pacíficamente varios protocolos de enrutamiento en la misma red. Tal vez la Compañía A ejecuta OSPF, y la Compañía B ejecuta EIGRP, y las dos compañías se fusionan. Hasta que el personal de TI recién combinado acuerde un protocolo de enrutamiento estándar para usar (si es que lo hace), las rutas conocidas por OSPF deben anunciarse en la parte de la red que ejecuta EIGRP, y viceversa.

Este escenario es posible gracias a la redistribución de rutas, y ese es el enfoque de esta publicación de blog. Otras razones por las que podría necesitar realizar la redistribución de rutas incluyen: diferentes partes de la red de su propia empresa están bajo un control administrativo diferente; desea anunciar rutas a su proveedor de servicios a través de BGP; o tal vez desee conectarse con la red de un socio comercial. Considere la siguiente topología básica.

En la topología simple de mostrar anteriormente, estamos queriendo OSPF y EIGRP para anunciar las rutas que saber sobre el uno al otro. Este concepto se denomina redistribución de rutas mutuas. Dado que el enrutador R2 tiene una interfaz en el sistema autónomo (AS) OSPF y una interfaz en el sistema autónomo EIGRP, tiene la responsabilidad de realizar la redistribución de la ruta.

Métricas semilla

El principal desafío al redistribuir rutas entre diferentes protocolos de enrutamiento son los diferentes enfoques que utilizan los protocolos de enrutamiento para medir sus métricas. Por ejemplo, OSPF utiliza una métrica de costo, que se basa en el ancho de banda, mientras que EIGRP utiliza una métrica basada en el ancho de banda y el retraso, de forma predeterminada, pero también podría considerar la confiabilidad y/o la carga (e incluso usar un valor de Unidad de Transmisión Máxima (MTU) como un interruptor de unión). El problema no es tan simple como convertir monedas entre dos países, porque en ese escenario, hay una relación que describe la relación de las dos monedas. Sin embargo, con la redistribución de rutas, no existe tal relación. Entonces, ¿qué hacemos?

Nosotros, como administradores, podemos configurar la métrica asignada a las rutas que vienen de un AS, que se están redistribuyendo en otro AS. Si no nos molestamos en configurar manualmente una métrica que se utilizará para la redistribución de rutas, se utiliza una métrica de semilla. La siguiente tabla muestra las métricas de inicio utilizadas por varios protocolos de enrutamiento.

el Protocolo de Enrutamiento

Semilla por Defecto Métrica

RIP

el Infinito

EIGRP

el Infinito

OSPF

20 (o 1 cuando la redistribución de rutas BGP)

BGP

Utiliza el valor de la métrica IGP

Basados en la tabla anterior, podemos ver que, por defecto, una ruta se redistribuyen en OSPF se le asignará un métrica de 20, a menos que la ruta se redistribuya en OSPF desde BGP, en cuyo caso se asignaría a la ruta un valor métrico de 1. Curiosamente, tanto RIP como EIGRP tienen métricas de semilla predeterminadas de infinito, lo que significa que cualquier ruta redistribuida en esos protocolos de enrutamiento se considerará inalcanzable, por defecto, y por lo tanto no se anunciará a ningún otro enrutador. BGP, sin embargo, redistribuye una ruta aprendida de un protocolo de puerta de enlace interior (IGP) utilizando la métrica original de esa ruta.

Ejemplo de configuración básica

Ciertamente, hay mucho más que considerar con respecto a la redistribución de rutas, como los bucles de enrutamiento que pueden ocurrir cuando tenemos más de un enrutador interconectando nuestros sistemas autónomos, o cómo filtramos selectivamente rutas específicas para que no se redistribuyan, pero veremos todo eso en próximas publicaciones de blog. Por ahora, vamos a comprender cómo realizar una configuración básica de redistribución de rutas. Considere la topología anterior, esta vez con información de red e interfaz agregada:

En esta topología, el enrutador R2 está aprendiendo rutas de R1 a través de OSPF y de R3 a través de EIGRP, como se muestra en la siguiente salida del comando show ip route emitido en R2:

Sin embargo, ni el enrutador R1 ni el enrutador R3 han aprendido ninguna ruta, porque el enrutador R2 aún no está realizando la redistribución de rutas. Esto se evidencia en la salida del comando show ip route emitido en R1 y R3:

Ahora agreguemos una configuración de redistribución de rutas al enrutador R2. Para reforzar la afirmación anterior de que la métrica semilla para las rutas redistribuidas en EIGRP es infinity, inicialmente no configuraremos ninguna métrica y dejaremos que las métricas semilla surtan efecto.

El comando redistribuir se emitió bajo el modo de configuración del enrutador para cada protocolo de enrutamiento, y no se especificó ninguna métrica. También es interesante notar que cuando ingresamos el comando redistribue eigrp 1 anterior, no incluimos la palabra clave subred en el comando, lo que hace que las redes de clase y sin clase se redistribuyan en OSPF. Sin embargo, como se ve en el resultado a continuación, la palabra clave subred se agregó automáticamente para nosotros:

Si bien este comportamiento de agregar automáticamente la palabra clave subred se observa en las versiones recientes de Cisco IOS, algunas versiones anteriores de Cisco IOS no incluyen automáticamente la palabra clave subred, y es posible que deba agregarla manualmente al comando redistribuir.

Echemos un vistazo a las tablas de enrutamiento IP de los enrutadores R1 y R3 para ver qué rutas han aprendido (y qué no han aprendido).

La salida anterior nos muestra que el enrutador R2 redistribuyó con éxito las rutas conocidas por EIGRP en OSPF, que luego fueron aprendidas por el enrutador R1. Observe que las rutas redistribuidas conocidas por el enrutador R1 tienen una métrica de 20, que es la métrica semilla de OSPF. Sin embargo, el router R3 no aprendió ninguna ruta nueva, porque cuando el router R2 redistribuía rutas en EIGRP, usaba la métrica semilla de EIGRP de infinito (que significa inalcanzable). Como resultado, esas rutas no fueron anunciadas al enrutador R3.

Para resolver este problema, necesitamos asignar una métrica a las rutas que se redistribuyen en EIGRP. Hay tres formas principales de asignar una métrica no predeterminada a las rutas que se redistribuyen en un protocolo de enrutamiento.

  1. Establezca una métrica predeterminada para todos los protocolos de enrutamiento que se redistribuyen en un protocolo de enrutamiento específico.
  2. Establezca una métrica como parte del comando redistribuir.
  3. Establecer una métrica utilizando un mapa de ruta.

Para ilustrar la primera opción, configuremos la métrica para asignarla a todas las rutas que se redistribuyen en EIGRP.

En el ejemplo anterior se utilizó ayuda contextual para mostrar cada componente de la métrica que se asigna a las rutas que se redistribuyen en EIGRP. Sin embargo, el comando final fue predeterminado: métrica 1000000 1 255 1 1500. Si estuviéramos configurando una métrica predeterminada para OSPF, podríamos haber utilizado un comando como default-metric 30, para asignar un costo OSPF de 30 a las rutas que se redistribuyen en OSPF. Sin embargo, en este ejemplo, solo especificamos una métrica predeterminada para EIGRP. Ahora echemos un vistazo a la tabla de enrutamiento IP en el enrutador R3 para ver si las rutas OSPF se han anunciado con éxito en EIGRP.

¡Éxito! El enrutador R3 ha aprendido rutas que se originan en el AS OSPF. Sabemos que las rutas originalmente provenían de fuera del EIGRP debido al código EX que aparece en cada una de esas rutas.

La segunda opción para configurar la métrica en rutas redistribuidas era asignar la métrica como parte del comando redistribuir, que nos permite especificar diferentes métricas para diferentes protocolos de enrutamiento que se redistribuyen en un proceso de enrutamiento. Para ilustrar este enfoque, eliminemos los comandos predeterminados de métrica y redistribución anteriores del enrutador R2 e introduzcamos un comando redistribuir que especifique la métrica que se asignará.

Si ahora volvemos a visitar el router R3, obtenemos el mismo resultado que antes:

La tercera opción para configurar la métrica en rutas redistribuidas era usar un mapa de rutas. Los mapas de ruta son súper potentes y se pueden usar para una variedad de configuraciones. Esencialmente, pueden hacer coincidir el tráfico específico y establecer uno o más parámetros (por ejemplo, una dirección IP de siguiente salto) para ese tráfico. En nuestro contexto, sin embargo, solo vamos a usar un mapa de ruta para especificar un valor de métrica, y luego aplicaremos el mapa de ruta a un comando redistribuir. El siguiente ejemplo muestra cómo podemos eliminar nuestro comando redistribuir anterior del enrutador R2, crear un mapa de ruta y, a continuación, introducir un nuevo comando redistribuir que haga referencia a nuestro mapa de ruta:

En el ejemplo anterior, después de eliminar nuestro comando redistribuir existente, creamos un mapa de ruta llamado SET-METRIC-DEMO. Este era un mapa de ruta muy básico que no necesitaba coincidir con ningún tráfico. Simplemente se usaba para establecer una métrica. Sin embargo, en una próxima publicación de blog, veremos que se puede usar un mapa de rutas para darnos más control sobre nuestra redistribución de rutas. En nuestro ejemplo actual, el mapa de ruta se aplicó a nuestro nuevo comando redistribuir. De nuevo, esto nos da el mismo resultado desde la perspectiva de la tabla de enrutamiento IP del enrutador R3:

Rutas OSPF E1 vs. E2

Antes de concluir esta primera publicación de blog en nuestra serie de Redistribución de rutas, examinemos una vez más la tabla de enrutamiento IP en el enrutador R1:

Observe que cada una de las rutas redistribuidas en OSPF aparece en la tabla de enrutamiento IP del enrutador R1 con un código E2. Sin embargo, también existe la opción de tener un código E1, que indica que la ruta se originó desde fuera del OSPF AS del enrutador. Entonces, ¿cuál es la diferencia entre estos dos códigos?

Un código de E2 indica que una ruta lleva una métrica que fue asignada por el enrutador que realiza la redistribución, que se conoce como Enrutador de Límites del Sistema Autónomo (ASBR). Esto significa que no importa cuántos enrutadores adicionales dentro del OSPF tengamos que cruzar para volver al ASBR, la métrica permanece igual que cuando el ASBR lo redistribuyó. Cuando redistribuimos rutas en OSPF, esas rutas, de forma predeterminada, son rutas externas de tipo 2 (E2).

Un código de E1 indica que la métrica de una ruta se compone del costo original asignado por el ASBR más el costo requerido para llegar al ASBR. Esto sugiere que una ruta E1 es generalmente más precisa, y de hecho lo es. Sin embargo, tener un código de E1 no nos ofrece ninguna ventaja en una topología simple como la que tenemos, donde el enrutador R1 solo tiene una ruta para llegar al ASBR (es decir, R2), y donde solo hay una forma para que las rutas EIGRP se inyecten en nuestro OSPF AS (es decir, a través del enrutador R2).

Si queremos redistribuir rutas E1 en OSPF en lugar de rutas E2, eso se puede lograr con el comando redistribuir. En el siguiente ejemplo, eliminamos nuestro comando redistribuir existente para el proceso de enrutamiento OSPF en el enrutador R2 y, a continuación, volvemos a aplicar el comando redistribuir especificando que queremos que se apliquen métricas externas de tipo 1 (E1) a las rutas redistribuidas.

Echemos un vistazo a la tabla de enrutamiento IP en el enrutador R1 para ver si las cosas han cambiado en función de este nuevo comando redistribuir emitido en el enrutador R2.

En la salida anterior, observe que las rutas redistribuidas en OSPF tienen un código de E1, en lugar del código predeterminado de E2. Además, observe que esto hace que la métrica de estas rutas sea un poco más alta. Específicamente, el enrutador R2 redistribuyó las rutas aprendidas de EIGRP en OSPF utilizando la métrica de semilla de OSPF de 20. Sin embargo, hay un costo OSPF de 1 para pasar del enrutador R1 al enrutador R2. Por lo tanto, dado que las rutas redistribuidas se configuraron como rutas E1, el costo de esas rutas desde la perspectiva del enrutador R1 es el costo asignado originalmente por el enrutador R1, que era 20, más el costo para que R1 llegara a R2, que es 1, para un costo total de 21.

Resumen

En esta entrada de blog, consideramos la necesidad de redistribución de rutas y echamos un vistazo a una configuración básica. Discutimos el impacto de la métrica semilla de un protocolo de enrutamiento (que podría ser infinita) al realizar la redistribución de rutas, y vimos tres formas de asignar administrativamente una métrica a las rutas redistribuidas. Finalmente, contrastamos las rutas Externas de Tipo 1 (E1) y Tipo 2 (E2) de OSPF. En una próxima publicación de blog, nos basaremos en esta topología y consideraremos cómo podemos filtrar selectivamente las rutas que se redistribuyen. Luego, en otra publicación de blog, consideraremos los problemas de diseño que rodean las topologías con múltiples puntos de redistribución entre dos sistemas autónomos.

Espero que hayan disfrutado de este primer vistazo al mundo de la redistribución de rutas. Si lo hiciste, por favor, ayuda a correr la voz compartiendo esta publicación con otros. Aquí está el enlace que puedes compartir:

https://www.kwtrain.com/blog/route-redistribution-part-1

Hasta la próxima,

Kevin Wallace, CCIEx2 (R / S y Colaboración) #7945

Deja una respuesta

Tu dirección de correo electrónico no será publicada.