Rutas LSP

Los IGP y BGP almacenan su información de enrutamiento en la tabla de enrutamiento inet.0, la tabla de enrutamiento IP principal. Si el comando está configurado, lo que permite que solo BGP use rutas MPLS para reenviar tráfico, la información de traffic-engineering bgp la ruta MPLS se almacena en una tabla de enrutamiento independiente, inet.3. Sólo BGP tiene acceso a la tabla de enrutamiento inet.3. BGP utiliza inet.0 e inet.3 para resolver las direcciones del próximo salto. Si el traffic-engineering bgp-igp comando está configurado, permitiendo así que los IGP utilicen rutas MPLS para reenviar tráfico, la información de ruta MPLS se almacena en la tabla de enrutamiento inet.0. Figura 1 ( e Figura 2 ilustrar las tablas de enrutamiento en las dos configuraciones de ingeniería de tráfico.)

Figura 1: Tablas de enrutamiento y reenvío, bgp de ingeniería de tráfico

La tabla de enrutamiento inet.3 contiene la dirección de host del enrutador de salida de cada LSP. Esta tabla de enrutamiento se utiliza en enrutadores de entrada para enrutar paquetes al enrutador de salida de destino. BGP utiliza la tabla de enrutamiento inet.3 del enrutador de entrada para ayudar a resolver las direcciones del próximo salto.

MPLS también mantiene una tabla de enrutamiento de ruta MPLS (mpls.0), que contiene una lista del siguiente enrutador conmutado por etiqueta en cada LSP. Esta tabla de enrutamiento se utiliza en enrutadores de tránsito para enrutar paquetes al siguiente enrutador a lo largo de un LSP.

Normalmente, el enrutador de salida en un LSP no consulta la tabla de enrutamiento mpls.0. (Este enrutador no necesita consultar mpls.0 porque el penúltimo enrutador del LSP cambia la etiqueta del paquete a un valor de 0 o abre la etiqueta). En cualquier caso, el enrutador de salida lo reenvía como un paquete IPv4, consultando la tabla de enrutamiento IP, inet.0, para determinar cómo reenviar el paquete.

Cuando un enrutador de tránsito o de salida recibe un paquete MPLS, la información de la tabla de reenvío de MPLS se utiliza para determinar el siguiente enrutador de tránsito en el LSP o para determinar que este enrutador es el enrutador de salida.

Cuando BGP resuelve un prefijo de salto siguiente, examina las tablas de enrutamiento inet.0 e inet.3 y busca el siguiente salto con la preferencia más baja. Si encuentra una entrada del salto siguiente con la misma preferencia en ambas tablas de enrutamiento, BGP prefiere la entrada de la tabla de enrutamiento inet.3.

Figura 2: Tablas de enrutamiento y reenvío, ingeniería de tráfico BGP-IGP

Generalmente, BGP selecciona entradas del próximo salto en la tabla de enrutamiento inet.3 porque sus preferencias son siempre inferiores a las preferencias del siguiente salto OSPF e IS-IS. Al configurar LSP, puede invalidar la preferencia predeterminada de los LSP MPLS, lo que podría alterar el proceso de selección del siguiente salto.

Cuando BGP selecciona una entrada del próximo salto de la tabla de enrutamiento inet.3, instala ese LSP en la tabla de reenvío del motor de reenvío de paquetes, lo que hace que los paquetes destinados al siguiente salto entren y viajen a lo largo del LSP. Si se quita el LSP o se produce un error, la ruta se quita de la tabla de enrutamiento inet.3 y de la tabla de reenvío, y BGP vuelve a usar un salto siguiente de la tabla de enrutamiento inet.0.

El reenrutamiento rápido proporciona redundancia para una ruta LSP. Cuando se habilita el reenrutamiento rápido, los desvíos se calculan y preestablecen a lo largo del LSP. En caso de que se produzca un fallo de red en la ruta LSP actual, el tráfico se enruta rápidamente a uno de los desvíos. Figura 3 ilustra un LSP del enrutador A al enrutador F, mostrando los desvíos establecidos. Cada desvío es establecido por un nodo ascendente para evitar el vínculo hacia el nodo descendente inmediato y el nodo descendente inmediato en sí. Cada desvío puede atravesar uno o más enrutadores (o conmutadores) con conmutación de etiquetas que no se muestran en la figura.

El reenrutamiento rápido protege el tráfico contra cualquier punto único de falla entre los enrutadores (o conmutadores) de entrada y salida. Si se produce un error en un escenario de reenrutamiento rápido escalado, los dispositivos pierden la accesibilidad de todos los pares que se conectaron a través del vínculo con errores. Esto provoca la interrupción del tráfico, ya que la sesión BGP entre los dispositivos deja de funcionar. Si hay varios errores a lo largo de un LSP, el reenrutamiento rápido podría fallar. Además, el reenrutamiento rápido no protege contra fallas de los enrutadores de entrada o salida.

Figura 3: Desvíos establecidos para un LSP mediante el redireccionamiento rápido

Si un nodo detecta que un vínculo descendente ha fallado (utilizando un mecanismo de detección de vida específico de la capa de enlace) o que un nodo descendente ha fallado (por ejemplo, usando el protocolo RSVP neighbor hello), el nodo cambia rápidamente el tráfico al desvío y, al mismo tiempo, señala al enrutador de entrada sobre el error del vínculo o nodo. Figura 4 ilustra el desvío que se toma cuando falla el vínculo entre el enrutador B y el enrutador C.

Figura 4: Desvío después de que falle el vínculo del enrutador B al enrutador C

Si la topología de red no es lo suficientemente rica (no hay suficientes enrutadores con suficientes vínculos a otros enrutadores), es posible que algunos de los desvíos no tengan éxito. Por ejemplo, el desvío del enrutador A al enrutador C en Figura 3 no puede atravesar el vínculo A-B y el enrutador B. Si tal camino no es posible, el desvío no ocurre.

Tenga en cuenta que después de que el nodo cambie el tráfico al desvío, podría cambiar el tráfico de nuevo a un desvío recién calculado poco después. Esto se debe a que la ruta de desvío inicial podría no ser la mejor ruta. Para que el reenrutamiento sea lo más rápido posible, el nodo cambia el tráfico al desvío inicial sin verificar primero que el desvío es válido. Una vez realizado el cambio, el nodo vuelve a calcular el desvío. Si el nodo determina que el desvío inicial sigue siendo válido, el tráfico continúa fluyendo por este desvío. Si el nodo determina que el desvío inicial ya no es válido, vuelve a cambiar el tráfico a un desvío recién calculado.

El tiempo necesario para que un desvío de reenrutamiento rápido surta efecto depende de dos intervalos de tiempo independientes:

• Cantidad de tiempo para detectar que hay un fallo de vínculo o nodo: este intervalo depende en gran medida de la capa de vínculo en uso y de la naturaleza del error. Por ejemplo, la detección de fallas en un vínculo SONET/SDH suele ser mucho más rápida que en un vínculo Gigabit Ethernet, y ambas son mucho más rápidas que la detección de una falla del enrutador.

• Cantidad de tiempo necesario para empalmar el tráfico en el desvío: esta operación la realiza el motor de reenvío de paquetes, que requiere poco tiempo para empalmar el tráfico en el desvío. El tiempo necesario puede variar dependiendo del número de LSP que se cambien a desvíos.

El reenrutamiento rápido es un parche a corto plazo para reducir la pérdida de paquetes. Dado que el cálculo de desvíos podría no reservar un ancho de banda adecuado, los desvíos podrían introducir congestión en los vínculos alternativos. El enrutador de entrada es el único enrutador que es plenamente consciente de las restricciones de la política de LSP y, por lo tanto, es el único enrutador capaz de crear rutas alternativas adecuadas a largo plazo.

Los desvíos se crean mediante el uso de RSVP y, como todas las sesiones de RSVP, requieren un estado y una sobrecarga adicionales en la red. Por esta razón, cada nodo establece como máximo un desvío para cada LSP que tenga habilitada la reenrutamiento rápido. Crear más de un desvío para cada LSP aumenta la sobrecarga, pero no sirve para ningún propósito práctico.

Para reducir aún más la sobrecarga de la red, cada desvío intenta fusionarse de nuevo en el LSP tan pronto como sea posible después de que el nodo o vínculo falle. Si puede considerar un LSP que viaja a través n de nodos enrutadores, es posible crear n – 1 desvíos. Por ejemplo, en Figura 5, el desvío intenta fusionarse de nuevo en el LSP en el enrutador D en lugar de en el enrutador E o F. La combinación de nuevo en el LSP hace que el problema de escalabilidad del desvío sea más manejable. Si las limitaciones de topología impiden que el desvío vuelva a fusionarse rápidamente con el LSP, los desvíos se fusionan con otros desvíos automáticamente.

Figura 5: Desvíos que se fusionan con otros desvíos

El reenrutamiento rápido proporciona un mecanismo para reenrutar automáticamente el tráfico en un LSP si falla un nodo o vínculo en un LSP, reduciendo así la pérdida de paquetes que viajan a través del LSP.

Para configurar el reenrutamiento rápido en un LSP, incluya la fast-reroute instrucción en el enrutador (o conmutador) de entrada:

Puede incluir esta instrucción en los siguientes niveles jerárquicos:

• [edit protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

No es necesario configurar el reenrutamiento rápido en los enrutadores (o conmutadores) de tránsito y salida del LSP. Una vez que se habilita el reenrutamiento rápido, el enrutador de entrada (o conmutador) indica a todos los enrutadores descendentes (o conmutadores) que el reenrutamiento rápido está habilitado en el LSP, y cada enrutador descendente hace todo lo posible para configurar desvíos para el LSP. Si un enrutador descendente no admite el reenrutamiento rápido, ignora la solicitud para configurar desvíos y sigue admitiendo el LSP. Un enrutador que no admite el reenrutamiento rápido hará que algunos de los desvíos fallen, pero por lo demás no tiene ningún impacto en el LSP.

De forma predeterminada, no se reserva ancho de banda para la ruta reenrutada. Para asignar ancho de banda para la ruta de acceso reenrutada, incluya la bandwidth instrucción o la bandwidth-percent instrucción. Solo puede incluir una de estas declaraciones a la vez. Si no incluye ni la instrucción ni la bandwidthbandwidth-percent instrucción, la configuración predeterminada es no reservar ancho de banda para la ruta de desvío.

Cuando incluya la bandwidth instrucción, puede especificar la cantidad específica de ancho de banda (en bits por segundo [bps]) que desea reservar para la ruta de desvío. No es necesario que el ancho de banda sea idéntico al asignado para el LSP.

Cuando se especifica un porcentaje de ancho de banda mediante la bandwidth-percent instrucción, el ancho de banda de la ruta de desvío se calcula multiplicando el porcentaje de ancho de banda por el ancho de banda configurado para el LSP principal diseñado para el tráfico. Para obtener información acerca de cómo configurar el ancho de banda para un LSP de ingeniería de tráfico, consulte Configuración de LSP de ingeniería de tráfico.

Las restricciones de límite de salto definen cuántos enrutadores más puede atravesar un desvío en comparación con el propio LSP. De forma predeterminada, el límite de saltos se establece en 6. Por ejemplo, si un LSP atraviesa 4 enrutadores, cualquier desvío para el LSP puede ser de hasta 10 (es decir, 4 + 6) saltos de enrutador, incluidos los enrutadores de entrada y salida.

De forma predeterminada, un desvío hereda las mismas restricciones administrativas (de color) de grupo que su LSP primario cuando CSPF determina la ruta alternativa. A los grupos administrativos, también conocidos como color de vínculo o clase de recurso, se les asignan manualmente atributos que describen el "color" de los vínculos, de modo que los vínculos con el mismo color pertenecen conceptualmente a la misma clase. Si especifica la include-any instrucción al configurar el LSP principal, todos los vínculos atravesados por la sesión alternativa deben tener al menos un color en la lista de grupos. Si especifica la include-all instrucción al configurar el LSP primario, todos los vínculos atravesados por la sesión alternativa deben tener todos los colores que se encuentran en la lista de grupos. Si especifica la exclude instrucción al configurar el LSP primario, ninguno de los vínculos debe tener un color en la lista de grupos. Para obtener más información acerca de las restricciones de grupos administrativos, consulte Configuración de grupos administrativos para LSP.

En esta sección se describe el proceso utilizado por un enrutador para determinar qué LSP seleccionar cuando el enrutador recibe mensajes de ruta de acceso de diferentes interfaces con objetos idénticos de plantilla de sesión y remitente. Cuando esto ocurre, el enrutador necesita combinar los estados de la ruta.

El enrutador emplea el siguiente proceso para determinar cuándo y cómo combinar los estados de ruta:

• Cuando todos los mensajes de ruta de acceso no incluyen un reenrutamiento rápido o un objeto de desvío, o cuando el enrutador es la salida del LSP, no se requiere ninguna combinación. Los mensajes se procesan de acuerdo con la ingeniería de tráfico RSVP.

• De lo contrario, el enrutador debe registrar el estado de la ruta además de la interfaz entrante. Si los mensajes de ruta no comparten la misma interfaz de salida y el mismo enrutador del próximo salto, el enrutador los considera LSP independientes y no los combina.

• Para todos los mensajes de ruta que comparten la misma interfaz de salida y el mismo enrutador del próximo salto, el enrutador utiliza el siguiente proceso para seleccionar el LSP final:

  • Si solo se origina un LSP en este nodo, selecciónelo como el LSP final.

  • Si sólo un LSP contiene un objeto de reenrutamiento rápido, selecciónelo como el LSP final.

  • Si hay varios LSP y algunos de ellos tienen un objeto de desvío, elimine aquellos que contengan un objeto de desvío del proceso de selección de LSP final.

  • Si quedan varios candidatos a LSP finales (es decir, todavía hay LSP de desvío y protegidos), seleccione los LSP con objetos de reenrutamiento rápido.

  • Si ninguno de los LSP tiene objetos de reenrutamiento rápido, seleccione los que no tienen objetos de desvío. Si todos los LSP tienen objetos de desvío, selecciónelos todos.

  • De los candidatos a LSP restantes, elimine de la consideración aquellos que atraviesan nodos que otros LSP evitan.

  • Si aún quedan varios LSP candidatos, seleccione el que tenga la longitud de ruta de acceso de objeto de ruta explícita (ERO) más corta. Si más de un LSP tiene la misma longitud de ruta, seleccione uno al azar.

• Una vez identificado el LSP final, el router debe transmitir únicamente los mensajes de ruta que correspondan a este LSP. Todos los demás LSP se consideran fusionados en este nodo.

La computación y la configuración de desvíos se realiza de forma independiente en cada nodo. En un nodo, si un LSP tiene habilitada el reenrutamiento rápido y si se puede identificar un nodo o un vínculo descendente, el enrutador realiza un cálculo de la ruta más corta restringida primero (CSPF) utilizando la información de la base de datos de ingeniería de tráfico local. Por esta razón, los desvíos dependen de que su IGP admita extensiones de ingeniería de tráfico. Sin la base de datos de ingeniería de tráfico, no se pueden establecer desvíos.

Inicialmente, CSPF intenta encontrar una ruta que omita el siguiente nodo descendente. Intentar encontrar esta ruta proporciona protección contra errores posteriores en nodos o vínculos. Si no hay disponible una ruta de omisión de nodo, CSPF intenta encontrar una ruta en un vínculo alternativo al siguiente nodo descendente. Intentar encontrar un vínculo alternativo proporciona protección contra errores posteriores solo en los vínculos. Es posible que los cálculos de desvío no tengan éxito la primera vez. Si se produce un error en un cálculo, el enrutador vuelve a calcular los desvíos aproximadamente una vez cada intervalo de actualización hasta que el cálculo se realice correctamente. La métrica RSVP para cada desvío se establece en un valor en el intervalo de 10.000 a 19.999.

Una ruta de protección de reenrutamiento rápido no es determinista. La ruta de protección real de un nodo determinado depende del historial del LSP y de la topología de red cuando se calculó la ruta de reenrutamiento rápido. La falta de comportamiento determinista puede dar lugar a dificultades operativas y rutas mal optimizadas después de múltiples aletas de enlace en una red. Incluso en una red pequeña, después de unos pocos flaps de enlace, las rutas de reenrutamiento rápidas pueden atravesar un número arbitrariamente grande de nodos y pueden permanecer en ese estado indefinidamente. Esto es ineficiente y hace que la red sea menos predecible.

La optimización de reenrutamiento rápido soluciona esta deficiencia. Proporciona un temporizador de optimización de ruta global, lo que le permite optimizar todos los LSP que tienen habilitada la reruta rápida y una ruta de desvío en funcionamiento. El valor del temporizador se puede variar en función de la carga de procesamiento de RE esperada.

El algoritmo de optimización de reenrutamiento rápido se basa únicamente en la métrica IGP. Siempre que la métrica IGP de la nueva ruta sea inferior a la de la ruta anterior, se acepta el resultado de CSPF, incluso si la nueva ruta puede estar más congestionada (mayor utilización del ancho de banda) o atraviesa más saltos.

De conformidad con RFC 4090, Extensiones de reenrutamiento rápido a RSVP-TE para túneles LSP, cuando se calcula una nueva ruta y se acepta para la optimización de reenrutamiento rápido, primero se destruye el desvío existente y luego se establece el nuevo desvío. Para evitar la pérdida de tráfico, los desvíos que protegen activamente el tráfico no están optimizados.

Puede habilitar la optimización de rutas para el reenrutamiento rápido configurando el temporizador de optimización de reenrutamiento rápido. El temporizador de optimización activa un proceso de optimización periódico que recalcula los LSP de desvío de reenrutamiento rápido para usar los recursos de red de manera más eficiente.

Para habilitar la optimización de ruta de reenrutamiento rápido, especifique el número de segundos mediante la opción optimize-timer para la fast-reroute instrucción:

Puede incluir esta instrucción en los siguientes niveles jerárquicos:

• [edit protocols rsvp]

• [edit logical-systems logical-system-name protocols rsvp]

De forma predeterminada, una ruta de host hacia el enrutador de salida se instala en la tabla de enrutamiento inet.3 o inet6.3. (La dirección de ruta del host es la que configura en la to instrucción). La instalación de la ruta de host permite que BGP realice la resolución del siguiente salto. También impide que la ruta de host interfiera con los prefijos aprendidos de los protocolos de enrutamiento dinámico y almacenados en la tabla de enrutamiento inet.0 o inet6.0.

A diferencia de las rutas de la tabla inet.0 o inet6.0, las rutas de la tabla inet.3 o inet6.3 no se copian en el motor de reenvío de paquetes y, por lo tanto, no provocan cambios directamente en la tabla de reenvío del sistema. No puede usar el comando o traceroute a través de ping estas rutas. El único uso para inet.3 o inet6.3 es permitir que BGP realice la resolución del siguiente salto. Para examinar la tabla inet.3 o inet6.3, utilice el show route table inet.3 comando o show route table inet6.3 .

Para insertar rutas adicionales en la tabla de enrutamiento inet.3 o inet6.3, incluya la install instrucción:

Puede incluir esta instrucción en los siguientes niveles jerárquicos:

• [edit protocols mpls label-switched-path lsp-name]

• [edit protocols mpls static-label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls static-label-switched-path lsp-name]

Las rutas especificadas se instalan como alias en la tabla de enrutamiento cuando se establece el LSP. La instalación de rutas adicionales permite a BGP resolver los siguientes saltos dentro del prefijo especificado y dirigir tráfico adicional para estos próximos saltos a un LSP determinado.

Al incluir la active opción con la install instrucción, se instala el prefijo especificado en la tabla de enrutamiento inet.0 o inet6.0, que es la tabla de reenvío principal. El resultado es una ruta que se instala en la tabla de reenvío cada vez que se establece el LSP, lo que significa que puede hacer ping o rastrear la ruta. Utilice esta opción con cuidado, ya que este tipo de prefijo es muy similar a una ruta estática.

Las rutas de alias se utilizan para enrutadores que tienen varias direcciones que se utilizan como saltos siguientes de BGP o para enrutadores que no son compatibles con MPLS. En cualquiera de estos casos, el LSP se puede configurar en otro sistema compatible con MPLS dentro del dominio local, que luego actúa como un enrutador de "borde". Luego, el LSP termina en el enrutador de borde y, desde ese enrutador, el reenvío de capa 3 lleva el paquete al verdadero enrutador del siguiente salto.

En el caso de una interconexión, el enrutador de borde del dominio puede actuar como enrutador proxy y puede anunciar el prefijo para la interconexión si el enrutador de borde no está configurando el próximo salto BGP para sí mismo.

En el caso de un punto de presencia (POP) que tiene enrutadores que no admiten MPLS, un enrutador (por ejemplo, un enrutador central) que admita MPLS puede actuar como un proxy para todo el POP y puede inyectar un conjunto de prefijos que cubren el POP. Por lo tanto, todos los enrutadores dentro del POP pueden anunciarse como próximos saltos de BGP interior (IBGP), y el tráfico puede seguir al LSP para llegar al enrutador central. Esto significa que el enrutamiento normal de IGP prevalecería dentro del POP.

No puede utilizar los ping comandos o traceroute en rutas de la tabla de enrutamiento inet.3 o inet6.3.

Para la resolución del próximo salto BGP, no importa si una ruta está en inet.0/inet6.0 o inet.3/inet6.3; Se elige la ruta con la mejor coincidencia (máscara más larga). Entre las múltiples rutas de mejor coincidencia, se elige la que tiene el valor de preferencia más alto.