Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Rutas LSP

MPLS y tablas de enrutamiento

Los IGP y el BGP almacenan su información de enrutamiento en la tabla de enrutamiento inet.0, la tabla de enrutamiento IP principal. Si el traffic-engineering bgp comando está configurado, lo que permite que solo el BGP utilice rutas MPLS para reenviar tráfico, la información de ruta MPLS se almacena en una tabla de enrutamiento independiente, inet.3. Solo el BGP tiene acceso a la tabla de enrutamiento inet.3. El BGP utiliza inet.0 e inet.3 para resolver direcciones de salto siguiente. Si el traffic-engineering bgp-igp comando está configurado, lo que permite que los IGP usen 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áficoTablas 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. El BGP utiliza la tabla de enrutamiento inet.3 en el enrutador de entrada para ayudar a resolver direcciones de salto siguiente.

La MPLS también mantiene una tabla de enrutamiento de ruta MPLS (mpls.0), la cual contiene una lista del próximo enrutador conmutado por etiquetas 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.

Por lo general, 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 extrae 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 salida recibe un paquete MPLS, la información de la tabla de reenvío MPLS se utiliza para determinar el próximo enrutador de tránsito en el LSP o para determinar que este enrutador es el enrutador de salida.

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

Figura 2: Tablas de enrutamiento y reenvío, bgp-igp de ingeniería de tráficoTablas de enrutamiento y reenvío, bgp-igp de ingeniería de tráfico

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

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

Descripción general del reenrutamiento rápido

El reenrutamiento rápido proporciona redundancia para una ruta LSP. Cuando se habilita el reenrutamiento rápido, los desvíos se precomputan y se establecen previamente a lo largo del LSP. En caso de una falla de red en la ruta LSP actual, el tráfico se enruta rápidamente a uno de los desvíos. Figura 3 muestra un LSP del enrutador A al enrutador F, mostrando los desvíos establecidos. Cada desvío se establece mediante 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 conmutados por etiquetas (o conmutadores) que no se muestran en la figura.

El reenrutamiento rápido protege el tráfico contra cualquier punto de falla entre los enrutadores (o conmutadores) de entrada y salida. Si hay un error en un escenario de reenrutamiento rápido escalado, los dispositivos pierden la accesibilidad a todos los pares que se conectaron a través del vínculo con errores. Esto conduce a la interrupción del tráfico, a medida que la sesión del BGP entre los dispositivos se cae. Si hay varias fallas a lo largo de un LSP, es posible que se produzca un error en el reenrutamiento rápido. 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 reenrutamiento rápidoDesvíos establecidos para un LSP mediante el reenrutamiento rápido

Si un nodo detecta que un vínculo descendente ha fallado (mediante un mecanismo de detección de vida activa específico de la capa de vínculo) o que un nodo descendente ha fallado (por ejemplo, mediante el protocolo de saludo de vecino RSVP), el nodo conmuta rápidamente el tráfico al desvío y, al mismo tiempo, señala al enrutador de entrada sobre el vínculo o la falla del nodo. Figura 4 ilustra el desvío que se realiza cuando falla el vínculo entre el enrutador B y el enrutador C.

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

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

Tenga en cuenta que después de que el nodo cambie el tráfico al desvío, puede conmutar 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 hacer el reenrutamiento lo más rápido posible, el nodo conmuta el tráfico al desvío inicial sin verificar primero que el desvío sea válido. Una vez que se realiza el conmutador, 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 sobre este desvío. Si el nodo determina que el desvío inicial ya no es válido, vuelve a conmutar el tráfico a un desvío recién calculado.

Nota:

Si emite show comandos después de que el nodo haya cambiado el tráfico al desvío inicial, el nodo puede indicar que el tráfico sigue fluyendo sobre el LSP original. Esta situación es temporal y debe corregirse rápidamente.

El tiempo necesario para que un desvío de desvío rápido entre en vigor depende de dos intervalos de tiempo independientes:

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

  • Cantidad de tiempo necesario para conectar el tráfico hacia el desvío: esta operación la realiza el motor de reenvío de paquetes, que requiere poco tiempo para conectar el tráfico hacia el desvío. El tiempo necesario puede variar según la cantidad 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 la computación de desvío podría no reservar el ancho de banda adecuado, los desvíos podrían introducir congestión en los enlaces 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 encontrar rutas alternativas adecuadas a largo plazo.

Los desvíos se crean mediante el uso de RSVP y, al igual que todas las sesiones de RSVP, requieren un estado adicional y una sobrecarga en la red. Por esta razón, cada nodo establece, como máximo, un desvío para cada LSP que tiene habilitado un 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 del nodo o vínculo con errores. Si puede considerar un LSP que viaja a través n de nodos de enrutador, 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 el enrutador F. La fusió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 se vuelva a fusionar rápidamente en el LSP, los desvíos se fusionan con otros desvíos automáticamente.

Figura 5: Los desvíos se fusionan con otros desvíosLos desvíos se fusionan con otros desvíos

Configuración de reenrutamiento rápido

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

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

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

No es necesario configurar un reenrutamiento rápido en los enrutadores de tránsito y salida (o conmutadores) del LSP. Una vez habilitado el reenrutamiento rápido, el enrutador de entrada (o conmutador) señala 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 un reenrutamiento rápido, ignora la solicitud de configurar desvíos y sigue siendo compatible con el LSP. Un enrutador que no admite el reenrutamiento rápido hará que algunos de los desvíos fallen, pero de lo contrario no tendrá ningún impacto en el LSP.

Nota:

Para habilitar el reenrutamiento rápido de PFE, configure una instrucción de política de enrutamiento con la load-balance per-packet instrucción en el [edit policy-options policy-statement policy-name then] nivel jerárquico de cada uno de los enrutadores en los que se puede redirigir el tráfico. Consulte también Configuración del equilibrio de carga en los LSP RSVP.

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

Cuando se incluye 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. El ancho de banda no debe ser 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 diseñado para el tráfico, consulte Configurar 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 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 de grupo administrativo (coloración) que su LSP principal 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 atributos manualmente 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 encontrado en la lista de grupos. Si especifica la include-all instrucción al configurar el LSP principal, 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 principal, ninguno de los vínculos debe tener un color encontrado en la lista de grupos. Para obtener más información acerca de las restricciones de grupo administrativo, consulte Configurar grupos administrativos para LSP.

Proceso de fusión de desvío

En esta sección se describe el proceso que usa un enrutador para determinar qué LSP seleccionar cuando el enrutador recibe mensajes de ruta desde diferentes interfaces con objetos de plantilla de sesión y remitente idénticos. Cuando esto ocurre, el enrutador debe fusionar los estados de ruta.

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

  • Cuando todos los mensajes de ruta 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 fusión. Los mensajes se procesan según 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 saliente y el enrutador de salto siguiente, el enrutador los considera LSP independientes y no los fusiona.

  • Para todos los mensajes de ruta que comparten la misma interfaz saliente y el enrutador de salto siguiente, el enrutador utiliza el siguiente proceso para seleccionar el LSP final:

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

    • Si solo un LSP contiene un objeto de reenrutamiento rápido, selecciónelo como 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 final de selección LSP.

    • Si quedan varios candidatos LSP finales (es decir, todavía hay un desvío y LSP 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 tengan objetos de desvío. Si todos los LSP tienen objetos de desvío, selecciónelos todos.

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

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

  • Una vez que se ha identificado el LSP final, el enrutador debe transmitir solo los mensajes de ruta que correspondan a este LSP. El resto de los LSP se consideran fusionados en este nodo.

Cálculos de desvío

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 habilitado un reenrutamiento rápido y si se puede identificar un vínculo o nodo descendente, el enrutador realiza un cálculo de ruta más corta restringida primero (CSPF) mediante la información en la base de datos de ingeniería de tráfico local. Por esta razón, los desvíos dependen de su IGP que admite extensiones de ingeniería de tráfico. Sin la base de datos de ingeniería de tráfico, no se pueden establecer desvíos.

CSPF intenta inicialmente encontrar una ruta que omite el siguiente nodo descendente. Intentar encontrar esta ruta proporciona protección contra fallas descendentes en nodos o vínculos. Si una ruta de salto de nodo no está disponible, CSPF intenta encontrar una ruta en un vínculo alternativo al siguiente nodo descendente. Intentar encontrar un vínculo alternativo proporciona protección contra fallas descendentes solo en 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 el desvío 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.

Optimización rápida de ruta de reenrutamiento

Una ruta de protección de reenrutamiento rápido es no 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 varias aletas de vínculo en una red. Incluso en una red pequeña, después de unos pocos vínculos, las rutas de reenrutamiento rápido pueden atravesar una cantidad arbitrariamente grande de nodos y pueden permanecer en ese estado de forma indeterminada. Esto es ineficiente y hace que la red sea menos predecible.

La optimización de reenrutamiento rápido aborda esta deficiencia. Ofrece un temporizador de optimización de ruta global, lo que le permite optimizar todos los LSP que tienen un reenrutamiento rápido habilitado y una ruta de desvío en funcionamiento. El valor del temporizador puede variar según la carga de procesamiento re esperada.

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

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

Configuración del intervalo de optimización para rutas de reenrutamiento rápido

Puede habilitar la optimización de rutas para un reenrutamiento rápido mediante la configuración del temporizador de optimización de reenrutamiento rápido. El temporizador de optimización activa un proceso de optimización periódico que recompute los LSP de desvío rápido para utilizar los recursos de red de manera más eficiente.

Para habilitar la optimización rápida de ruta de reenrutamiento, especifique el número de segundos mediante la opción optimizar temporizador 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]

Agregar rutas relacionadas con LSP a la tabla de enrutamiento inet.3 o inet6.3

De forma predeterminada, se instala una ruta de host hacia el enrutador de salida en la tabla de enrutamiento inet.3 o inet6.3. (La dirección de ruta de host es la que configura en la to instrucción.) La instalación de la ruta del host permite que el BGP realice la resolución del salto siguiente. También evita que la ruta de host interfiera con prefijos aprendidos de 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 al motor de reenvío de paquetes y, por lo tanto, no provocan cambios en la tabla de reenvío del sistema directamente. No puede usar el ping comando o traceroute a través de estas rutas. El único uso para inet.3 o inet6.3 es permitir que el BGP realice la resolución del salto siguiente. 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:

Las rutas especificadas se instalan como alias en la tabla de enrutamiento cuando se establece el LSP. La instalación de rutas adicionales permite al BGP resolver los próximos 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 en cualquier momento en 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.

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

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

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

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

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

Nota:

La install destination-prefix active instrucción no se admite en LSP estáticos. Cuando la install destination-prefix active instrucción está configurada para un LSP estático, las rutas MPLS no se instalan en la tabla de enrutamiento inet.0.