Rutas LSP

Las 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 use rutas MPLS para reenviar tráfico, la información de la ruta MPLS se almacena en una tabla de enrutamiento independiente, inet.3. Solo el BGP accede a la tabla de enrutamiento inet.3. El BGP usa tanto inet.0 como inet.3 para resolver direcciones del siguiente salto. 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 la ruta MPLS se almacena en la tabla de enrutamiento inet.0. (Figura 1 e Figura 2 ilustra 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. El BGP usa 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 rutas 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 enrutador siguiente 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, ya que el penúltimo enrutador en el 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 salida recibe un paquete MPLS, la información de la tabla de reenvío 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 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 del salto siguiente con una preferencia igual en ambas tablas de enrutamiento, el 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, el BGP selecciona las entradas del próximo salto en la tabla de enrutamiento inet.3 porque sus preferencias siempre son menores que las preferencias del salto siguiente de OSPF e IS-IS. Cuando configure LSP, puede invalidar la preferencia predeterminada de los LSP de MPLS, lo que podría alterar el proceso de selección del próximo salto.

Cuando el BGP selecciona una entrada de próximo salto 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 ingresen y viajen a lo largo del LSP. Si se quita o falla el LSP, la ruta se quita 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.

El reenrutamiento rápido proporciona redundancia para una ruta LSP. Cuando habilita el reenrutamiento rápido, los desvíos se precomputan y se establecen de forma preestablecida 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 lo establece un nodo ascendente para evitar el vínculo hacia el nodo descendente inmediato y el propio nodo descendente inmediato. Cada desvío puede atravesar uno o varios enrutadores conmutados por etiquetas (o conmutadores) que no se muestran en la figura.

El reenrutamiento rápido protege el tráfico contra cualquier punto único de falla entre los enrutadores de entrada y salida (o conmutadores). Si se produce un error en un escenario de reenrutamiento rápido a escala, los dispositivos pierden la accesibilidad a todos los pares que se conectaron a través del vínculo fallido. Esto lleva a la interrupción del tráfico, ya que la sesión del BGP entre los dispositivos cae. Si hay varios errores a lo largo de un LSP, es posible que el reenrutamiento rápido en sí mismo falle. 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 reenrutamiento rápido

Si un nodo detecta que un vínculo descendente ha fallado (mediante un mecanismo de detección de liveness 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 cambia rápidamente el tráfico al desvío y, al mismo tiempo, señala al enrutador de entrada acerca del error del vínculo o del nodo. Figura 4 muestra el desvío tomado cuando se produce un error en el vínculo entre el enrutador B y el enrutador C.

Figura 4: Desviación después de que el vínculo del enrutador B al enrutador C falla

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 Figura 3 no puede atravesar el enlace A-B y el enrutador B. Si dicha 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, es posible que vuelva a cambiar el tráfico a un desvío recién calculado poco después. Esto se debe a que la ruta de desvío inicial puede 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 sea válido. Una vez que se realiza el conmutador, el nodo recompute el desvío. Si el nodo determina que el desvío inicial sigue siendo válido, el tráfico seguirá 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 sufra efecto depende de dos intervalos de tiempo independientes:

• Cantidad de tiempo para detectar que se produce un error 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 de Gigabit Ethernet, y ambas son mucho más rápidas que la detección de una falla de 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, lo que requiere poco tiempo para empalmar el tráfico en 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íos puede no reservar un ancho de banda adecuado, los desvíos pueden introducir congestión en los vínculos alternativos. El enrutador de entrada es el único que es completamente consciente de las restricciones de 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 habilitado el reenrutamiento rápido. Crear más de un desvío para cada LSP aumenta la sobrecarga, pero no tiene un propósito práctico.

Para reducir aún más la sobrecarga de red, cada desvío intenta volver a fusionarse en el LSP lo antes posible después de que el nodo o vínculo falló. Si se 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 del enrutador E o el enrutador F. Volver a fusionarse en el LSP hace que el problema de escalabilidad de desvío sea más manejable. Si las limitaciones de la topología impiden que el desvío vuelva a fusionarse rápidamente en el LSP, los desvíos se fusionan con otros desvíos automáticamente.

Figura 5: Desvíos fusionándose en otros desvíos

El reenrutamiento rápido proporciona un mecanismo para reenrutar automáticamente el tráfico de un LSP si falla un nodo o vínculo en un LSP, lo que reduce 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 (o conmutador) de entrada 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 el reenrutamiento rápido, ignora la solicitud de configuración de desvíos y sigue siendo compatible con el LSP. Un enrutador que no admita el reenrutamiento rápido causará que algunos de los desvíos fallen, pero de lo contrario no tendrá ningún impacto en el LSP.

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 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. El ancho de banda no tiene que 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 por tráfico. Para obtener más información acerca de cómo configurar el ancho de banda para un LSP diseñado por tráfico, consulte Configuración de LSP diseñados por tráfico.

Las restricciones de límite de saltos definen cuántos enrutadores más se permite recorrer un desvío en comparación con el LSP en sí. De forma predeterminada, el límite de salto se establece en 6. Por ejemplo, si un LSP atraviesa 4 enrutadores, cualquier desvío para el LSP puede ser de hasta 10 saltos de enrutador (es decir, 4 + 6), 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. Los grupos administrativos, también conocidos como coloración de vínculos o clase de recurso, se 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 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 encontrados 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 grupos administrativos, consulte Configurar grupos administrativos para LSP.

En esta sección se describe el proceso que utiliza un enrutador para determinar qué LSP seleccionar cuando el enrutador recibe mensajes de ruta de diferentes interfaces con objetos de sesión y plantilla de remitente idénticos. Cuando esto ocurre, el enrutador debe combinar los estados de la 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 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 de entrada. Si los mensajes de ruta no comparten la misma interfaz de salida y el enrutador del próximo salto, el enrutador los considera como LSP independientes y no los fusiona.

• Para todos los mensajes de ruta que comparten la misma interfaz de salida y 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 el LSP final.

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

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

  • Del resto de los candidatos de LSP, elimine de consideración los que atraviesan nodos que otros LSP evitan.

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

• Una vez identificado el LSP final, el enrutador debe transmitir solo 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 realizan de forma independiente en cada nodo. En un nodo, si un LSP ha habilitado el reenrutamiento rápido y si se puede identificar un vínculo o un nodo descendente, el enrutador realiza un cálculo de ruta más corta restringida (CSPF) mediante 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.

CspF inicialmente intenta encontrar una ruta que omite el siguiente nodo descendente. Intentar encontrar esta ruta ofrece protección contra errores descendentes en nodos o vínculos. Si una ruta de omisión de nodos no está disponible, CSPF intenta encontrar una ruta en un vínculo alternativo al siguiente nodo descendente. El intento de encontrar un vínculo alternativo ofrece protección contra errores 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 descomponerse aproximadamente una vez en cada intervalo de actualización hasta que el cálculo tenga éxito. 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 varios flaps de vínculo en una red. Incluso en una red pequeña, después de algunos flaps de vínculo, 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. Proporciona un temporizador de optimización de rutas global, lo que le permite optimizar todos los LSP que tienen habilitado el reenrutamiento rápido y una ruta de desvío en funcionamiento. El valor del temporizador puede variar según la carga de procesamiento de RE esperada.

El algoritmo de optimización de reenrutamiento rápido se basa solo 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 del CSPF, incluso si la nueva ruta puede estar más congestionada (mayor utilización de ancho de banda) o si 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, el desvío existente se destruye primero 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 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 recomputa los LSP de desvío rápido para usar los recursos de red de manera más eficiente.

Para habilitar la optimización de rutas 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, 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 de host permite que el 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 al motor de reenvío de paquetes y, por lo tanto, no causan 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:

• [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 que el BGP resuelva los próximos saltos dentro del prefijo especificado y dirigir tráfico adicional para estos próximos saltos a un LSP en particular.

Si se incluye 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.

Se usan rutas de alias para enrutadores que tienen varias direcciones que se utilizan como próximos saltos de 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". Luego, el LSP termina en el enrutador de borde y, desde ese enrutador, el reenvío de capa 3 lleva el paquete al enrutador de próximo salto verdadero.

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 establece el BGP siguiente salto 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 todo el POP y puede inyectar un conjunto de prefijos que cubran el POP. Por lo tanto, todos los enrutadores dentro del POP pueden anunciarse como BGP interiores próximos saltos, 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 las rutas de la tabla de enrutamiento inet.3 o inet6.3.

Para la resolución del salto siguiente del BGP, no hace ninguna diferencia 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 combinación, se elige la que tiene el valor de preferencia más alto.