Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
EN ESTA PÁGINA
 

Configuración de RSVP

Configuración mínima de RSVP

Para habilitar RSVP en una sola interfaz, incluya la rsvp instrucción y especifique la interfaz mediante la interface instrucción. Esta es la configuración mínima de RSVP. Todas las demás instrucciones de configuración RSVP son opcionales.

Puede incluir estas instrucciones en los siguientes niveles jerárquicos:

  • [edit protocols]

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

Para habilitar RSVP en todas las interfaces, sustituya all por la interface-name variable.

Si ha configurado propiedades de interfaz en un grupo de interfaces y desea deshabilitar RSVP en una de las interfaces, incluya la disable instrucción:

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

  • [edit protocols rsvp interface interface-name ]

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

Configuración de RSVP y MPLS

El propósito principal del software Junos RSVP es admitir la señalización dinámica dentro de rutas conmutadas por etiquetas (LSP). Cuando habilita mpls y RSVP en un enrutador, MPLS se convierte en un cliente de RSVP. No se requiere ninguna configuración adicional para enlazar MPLS y RSVP.

Puede configurar MPLS para configurar rutas señalizadas mediante la label-switched-path instrucción en el [edit protocols mpls] nivel de jerarquía. Cada LSP se traduce en una solicitud de RSVP para iniciar una sesión RSVP. Esta solicitud se pasa a través de la interfaz interna entre la conmutación de etiquetas y el RSVP. Después de examinar la información de la solicitud, comprobar los estados de RSVP y comprobar las tablas de enrutamiento local, RSVP inicia una sesión para cada LSP. La sesión se origina del enrutador local y está destinada al destino del LSP.

Cuando se crea correctamente una sesión RSVP, el LSP se configura a lo largo de las rutas creadas por la sesión RSVP. Si la sesión de RSVP no tiene éxito, RSVP notifica a MPLS su estado. Corresponde a MPLS iniciar rutas de copia de seguridad o continuar reintentar la ruta inicial.

Para pasar información de señalización de conmutación de etiquetas, RSVP admite cuatro objetos adicionales: Objeto Solicitud de etiqueta, objeto Label, objeto Explicit Route y objeto Record Route. Para que un LSP se configure correctamente, todos los enrutadores a lo largo de la ruta deben admitir MPLS, RSVP y los cuatro objetos. De los cuatro objetos, el objeto Registrar ruta no es obligatorio.

Para configurar MPLS y convertirla en un cliente de RSVP, haga lo siguiente:

  • Habilite MPLS en todos los enrutadores que participarán en la conmutación de etiquetas (es decir, en todos los enrutadores que puedan formar parte de una ruta de conmutación de etiquetas).

  • Habilite RSVP en todos los enrutadores y en todas las interfaces de enrutador que forman el LSP.

  • Configure los enrutadores al principio del LSP.

Puede configurar rutas conmutadas de etiquetas (LSP) RSVP para usar una métrica de retraso para calcular la ruta. Para configurar, utilice las opciones de CLI que introdujimos en la [edit protocols mpls label-switched-path name] jerarquía.

Ejemplo: Configuración de RSVP y MPLS

A continuación, se muestra una configuración de ejemplo para un enrutador al principio de un LSP:

A continuación, se muestra una configuración de ejemplo para todos los demás enrutadores que forman el LSP:

Configuración de interfaces RSVP

En las siguientes secciones se describe cómo configurar interfaces RSVP:

Configuración de la reducción de actualización de RSVP

Puede configurar la reducción de actualización de RSVP en cada interfaz incluyendo las siguientes instrucciones en la configuración de la interfaz:

  • aggregate y reliable: habilite todas las funciones de reducción de actualización de RSVP: Agrupación de mensajes RSVP, ID de mensaje RSVP, entrega de mensajes confiable y actualización de resumen.

    Para tener una reducción de actualización y una entrega confiable, debe incluir las aggregate instrucciones y reliable .

  • no-aggregate: desactive la agrupación de mensajes RSVP y la actualización de resumen.

  • no-reliable: desactive el ID de mensaje RSVP, la entrega confiable de mensajes y la actualización de resumen.

Para obtener más información sobre la reducción de actualización de RSVP, consulte Reducción de actualización de RSVP.

Si la no-reliable instrucción está configurada en el enrutador (la entrega de mensajes confiable está deshabilitada), el enrutador acepta mensajes RSVP que incluyen el objeto Message ID, pero ignora el objeto Message ID y continúa realizando el procesamiento de mensajes estándar. En este caso, no se genera ningún error y el RSVP funciona normalmente.

Sin embargo, no todas las combinaciones entre dos vecinos con diferentes capacidades de reducción de actualización funcionan correctamente. Por ejemplo, un enrutador está configurado con la aggregate instrucción y no-reliable la instrucción o con las reliable instrucciones and no-aggregate . Si un vecino de RSVP envía un objeto Summary Refresh a este enrutador, no se genera ningún error, pero no se puede procesar el objeto Summary Refresh. Por lo tanto, los estados de RSVP pueden agotar el tiempo en este enrutador si el vecino solo confía en la actualización de resumen para actualizar esos estados RSVP.

Recomendamos, a menos que haya requisitos específicos, que configure la reducción de actualización de RSVP de manera similar en cada vecino RSVP.

Para habilitar todas las funciones de reducción de actualización de RSVP en una interfaz, incluya la aggregate instrucción:

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

  • [edit protocols rsvp interface interface-name]

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

Para deshabilitar la agrupación de mensajes RSVP y la actualización de resumen, incluya la no-aggregate instrucción:

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

  • [edit protocols rsvp interface interface-name]

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

Para habilitar el ID de mensaje RSVP y la entrega confiable de mensajes en una interfaz, incluya la reliable instrucción:

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

  • [edit protocols rsvp interface interface-name]

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

Para deshabilitar el ID de mensaje RSVP, la entrega confiable de mensajes y la actualización de resumen, incluya la no-reliable instrucción:

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

  • [edit protocols rsvp interface interface-name]

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

Determinación de la capacidad de reducción de actualizaciones de los vecinos de RSVP

Para determinar la capacidad de reducción de actualización de RSVP de un vecino de RSVP, necesita la siguiente información:

  • El bit RR anunciado por el vecino

  • La configuración local de la reducción de actualización de RSVP

  • Los mensajes reales de RSVP recibidos del vecino

Para obtener esta información, puede ejecutar un show rsvp neighbor detail comando. La salida de muestra sigue:

Para obtener más información sobre el show rsvp neighbor detail comando.

Configuración del intervalo de saludo RSVP

RSVP monitorea el estado de los vecinos del protocolo de puerta de enlace interior (IGP) (IS-IS o OSPF) y se basa en los protocolos IGP para detectar cuando un nodo falla. Si un protocolo IGP declara un vecino hacia abajo (porque ya no se reciben paquetes de saludo), RSVP también derriba ese vecino. Sin embargo, los protocolos IGP y RSVP aún actúan de forma independiente cuando se pone en marcha un vecino.

En el caso de los enrutadores de Juniper Networks, la configuración de un intervalo de saludo RSVP más corto o más largo no afecta a si se reduce o no una sesión de RSVP. Las sesiones RSVP se mantienen activas incluso si ya no se reciben paquetes de saludo RSVP. Las sesiones RSVP se mantienen hasta que el enrutador deje de recibir paquetes de saludo IGP o la ruta RSVP y el tiempo de espera de los mensajes de resv. Sin embargo, a partir de la versión 16.1 de Junos OS, cuando el RSVP saludo mensajes de tiempo de salida, las sesiones RSVP se reducen.

El intervalo de saludo RSVP también puede verse afectado cuando el equipo de otro proveedor derriba una sesión de RSVP. Por ejemplo, un enrutador vecino que no es de Juniper Networks puede configurarse para supervisar paquetes de saludo RSVP.

Para modificar la frecuencia con la que RSVP envía paquetes de saludo, incluya la hello-interval instrucción:

Nota:

A partir de la versión 16.1 Junos envía mensajes de saludo RSVP a través de un LSP de bypass cuando uno está disponible. Consulte para obtener no-node-hello-on-bypass información sobre cómo revertir al comportamiento histórico de enviar saludos mediante el salto siguiente de IGP.

Para obtener una lista de niveles jerárquicos en los que puede incluir esta instrucción, consulte la sección resumen de instrucciones.

Configuración de la autenticación RSVP

Todos los intercambios de protocoloSVP se pueden autenticar para garantizar que solo los vecinos de confianza participen en la configuración de reservas. De forma predeterminada, la autenticación RSVP está deshabilitada.

La autenticación RSVP utiliza un resumen basado en mensajes hash de código de autenticación de mensaje (HMAC)-MD5. Este esquema produce un resumen de mensajes basado en una clave de autenticación secreta y el contenido del mensaje. (El contenido del mensaje también incluye un número de secuencia.) El resumen computado se transmite con mensajes RSVP. Una vez que haya configurado la autenticación, todos los mensajes RSVP recibidos y transmitidos con todos los vecinos se autentican en esta interfaz.

La autenticación MD5 proporciona protección contra falsificación y modificación de mensajes. También puede evitar los ataques de repetición. Sin embargo, no proporciona confidencialidad, ya que todos los mensajes se envían en texto sin formato.

De forma predeterminada, la autenticación está deshabilitada. Para habilitar la autenticación, configure una clave en cada interfaz incluyendo la authentication-key instrucción:

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

  • [edit protocols rsvp interface interface-name]

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

Configuración de la suscripción de ancho de banda para tipos de clase

De forma predeterminada, RSVP permite usar el 100 % del ancho de banda para un tipo de clase para reservas de RSVP. Cuando sobrescriba un tipo de clase para un LSP multiclase, se permite que la demanda agregada de todas las sesiones RSVP supere la capacidad real del tipo de clase.

Para obtener instrucciones detalladas sobre cómo configurar la suscripción de ancho de banda para tipos de clase, consulte Configurar el porcentaje de suscripción de ancho de banda para LSP.

Configuración del umbral de actualización de RSVP en una interfaz

Los protocolos de puerta de enlace interior (IGP) mantienen la base de datos de ingeniería de tráfico, pero el ancho de banda disponible actual en los vínculos de base de datos de ingeniería de tráfico se origina en RSVP. Cuando cambia el ancho de banda de un vínculo, RSVP informa a los IGP, que luego pueden actualizar la base de datos de ingeniería de tráfico y reenviar la nueva información de ancho de banda a todos los nodos de red. A continuación, los nodos de red saben cuánto ancho de banda está disponible en el vínculo de base de datos de ingeniería de tráfico (local o remoto), y CSPF puede calcular correctamente las rutas.

Sin embargo, las actualizaciones de IGP pueden consumir recursos excesivos del sistema. Dependiendo de la cantidad de nodos en una red, es posible que no sea conveniente realizar una actualización de IGP para pequeños cambios en el ancho de banda. Al configurar la update-threshold instrucción en el [edit protocols rsvp] nivel de jerarquía, puede ajustar el umbral en el que un cambio en el ancho de banda reservado activa una actualización de IGP.

Puede configurar un valor del 0,001 por ciento al 20 por ciento (el valor predeterminado es del 10 por ciento) para cuándo activar una actualización de IGP. Si el cambio en el ancho de banda reservado es mayor o igual que el porcentaje de umbral configurado del ancho de banda estático en esa interfaz, se produce una actualización de IGP. Por ejemplo, si configuró la update-threshold instrucción como 15 por ciento y el enrutador descubre que el ancho de banda reservado en un vínculo ha cambiado en un 10 por ciento del ancho de banda del vínculo, RSVP no activa una actualización de IGP. Sin embargo, si el ancho de banda reservado de un vínculo cambia en un 20 % del ancho de banda del vínculo, RSVP activa una actualización de IGP.

También puede configurar el umbral como un valor absoluto mediante la threshold-value opción bajo la update-threshold instrucción.

Si el valor de umbral está configurado para superar el 20 % del ancho de banda en ese vínculo, el valor de umbral se limita al 20 % del ancho de banda.

Por ejemplo, si el ancho de banda en una interfaz es de 1 Gbps y el threshold-value está configurado mayor que 200 Mbps, el threshold-value ancho de banda está limitado a 200 Mbps. El umbral por ciento se muestra como 20,000% y threshold-value como 200 Mbps.

Nota:

Las dos opciones, umbral por ciento y threshold-value, son mutuamente excluyentes. Solo puede configurar una opción en un momento dado para generar una actualización de IGP para reservas de ancho de banda inferior. Como resultado, cuando se configura una opción, la otra opción se calcula y se muestra en la CLI.

Por ejemplo, en un vínculo de 1 Gbps, si el umbral por ciento está configurado para el 5 %, el threshold-value se calcula y se muestra como 50 Mbps. De manera similar, si el threshold-value está configurado en 50m, el umbral por ciento se calcula y se muestra como 5%.

Para ajustar el umbral en el que un cambio en el ancho de banda reservado activa una actualización de IGP, incluya la instrucción update-threshold . Debido al umbral de actualización, es posible que la ruta más corta restringida primero (CSPF) calcule una ruta mediante la información de ancho de banda de la base de datos de ingeniería de tráfico desactualizada en un vínculo. Si RSVP intenta establecer un LSP sobre esa ruta, puede encontrar que no hay ancho de banda suficiente en ese vínculo. Cuando esto sucede, RSVP activa una actualización de la base de datos de ingeniería de tráfico IGP, inundando la información actualizada de ancho de banda en la red. Luego, CSPF puede recompute la ruta mediante la información de ancho de banda actualizada e intentar encontrar una ruta diferente, evitando el vínculo congestionado. Tenga en cuenta que esta funcionalidad es la predeterminada y no necesita ninguna configuración adicional.

Puede configurar la rsvp-error-hold-time instrucción en el [edit protocols mpls] nivel jerárquico o en el [edit logical-systems logical-system-name protocols mpls] nivel jerárquico para mejorar la precisión de la base de datos de ingeniería de tráfico (incluida la precisión de las estimaciones de ancho de banda de los LSP) mediante la información proporcionada por los mensajes PathErr. Consulte Mejorar la precisión de la base de datos de ingeniería de tráfico con los mensajes de RSVP PathErr.

Configuración de RSVP para interfaces no numeradas

Junos OS admite ingeniería de tráfico RSVP a través de interfaces no numeradas. La información de ingeniería de tráfico sobre vínculos no numerados se lleva en las extensiones de ingeniería de tráfico IGP para OSPF e IS-IS como se describe en RFC 4203, Extensiones OSPF en soporte de conmutación de etiquetas multi protocolizada generalizada (GMPLS) y RFC 4205, extensiones de sistema intermedio a sistema intermedio (IS-IS) en soporte de conmutación de etiquetas multi protocolizada generalizada (GMPLS). Los vínculos no numerados también se pueden especificar en la señalización de ingeniería de tráfico MPLS como se describe en RFC 3477, Señalización de vínculos no numerados en el protocolo de reeservación de recursos - Ingeniería de tráfico (RSVP-TE). Esta función le permite evitar tener que configurar direcciones IP para cada interfaz que participe en la red señalada por RSVP.

Para configurar RSVP para interfaces no numeradas, debe configurar el enrutador con un ID de enrutador mediante la router-id instrucción especificada en el [edit routing-options] nivel de jerarquía. El ID del enrutador debe estar disponible para el enrutamiento (normalmente puede usar la dirección de circuito cerrado). Los mensajes de control RSVP para los vínculos no numerados se envían mediante la dirección de ID del enrutador (en lugar de una dirección seleccionada aleatoriamente).

Para configurar la protección de vínculos y el reenrutamiento rápido en un enrutador con interfaces no numeradas habilitadas, debe configurar al menos dos direcciones. Le recomendamos que configure una interfaz secundaria en el circuito cerrado, además de configurar el ID del enrutador.

Configuración de saludos de ID de nodo RSVP

Puede configurar saludos RSVP basados en ID de nodo para garantizar que los enrutadores de Juniper Networks puedan interoperar con el equipo de otros proveedores. De forma predeterminada, Junos OS utiliza saludos RSVP basados en interfaz. Los saludos RSVP basados en ID de nodo se especifican en RFC 4558, Protocolo de reserva de recursos basado en ID de nodo (RSVP) Hola: Una instrucción de aclaración. Los saludos de ID de nodo RSVP son útiles si ha configurado BFD para detectar problemas a través de interfaces RSVP, lo que le permite deshabilitar los saludos de interfaz para estas interfaces. También puede usar saludos de ID de nodo para procedimientos de reinicio correctos.

Los saludos de ID de nodo se pueden habilitar globalmente para todos los vecinos RSVP. De forma predeterminada, la compatibilidad con hello de ID de nodo está deshabilitada. Si no ha habilitado los ID de nodo RSVP en el enrutador, Junos OS no acepta ningún paquete de saludo de ID de nodo.

Nota:

A partir de la versión 16.1 Junos envía mensajes de saludo RSVP a través de un LSP de bypass cuando uno está disponible. Consulte para obtener no-node-hello-on-bypass información sobre cómo revertir al comportamiento histórico de enviar saludos mediante el salto siguiente de IGP.

Para habilitar saludos de ID de nodo RSVP globalmente en el enrutador, incluya la instrucción node-hello en los siguientes niveles jerárquicos:

  • [edit protocols rsvp]

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

También puede deshabilitar explícitamente los saludos de interfaz RSVP globalmente. Este tipo de configuración puede ser necesario en redes en las que el enrutador de Juniper Networks tiene numerosas conexiones RSVP con equipos de otros proveedores. Sin embargo, si deshabilita los saludos globales de la interfaz RSVP, también puede configurar un intervalo de saludo en una interfaz RSVP mediante la instrucción hello-interval . Esta configuración deshabilita los saludos globales de la interfaz RSVP, pero habilita saludos de interfaz RSVP en la interfaz especificada (la interfaz RSVP en la que configure la hello-interval instrucción). Esta configuración puede ser necesaria en una red heterogénea en la que algunos dispositivos admiten saludos de ID de nodo RSVP y otros dispositivos admiten saludos de interfaz RSVP.

Para deshabilitar los saludos de interfaz RSVP globalmente en el enrutador, incluya la instrucción no-interface-hello en los siguientes niveles jerárquicos:

  • [edit protocols rsvp]

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

Ejemplo: Configuración de LSP con señal RSVP

En este ejemplo, se muestra cómo crear un LSP entre enrutadores en una red IP mediante RSVP como protocolo de señalización.

Requisitos

Antes de comenzar, elimine los servicios de seguridad del dispositivo. Consulte Ejemplo: Eliminación de servicios de seguridad.

Descripción general y topología

Mediante el uso de RSVP como protocolo de señalización, puede crear LSP entre enrutadores en una red IP. En este ejemplo, configure una red de ejemplo como se muestra en Figura 1.

Topología

Figura 1: LSP típico con señal RSVPLSP típico con señal RSVP

Para establecer un LSP entre enrutadores, debe habilitar individualmente la familia MPLS y configurar RSVP en cada una de las interfaces de tránsito en la red MPLS. En este ejemplo, se muestra cómo habilitar MPLS y configurar RSVP en la interfaz de tránsito ge-0/0/0. Además, debe habilitar el proceso MPLS en todas las interfaces MPLS de la red.

En este ejemplo, se muestra cómo definir un LSP de R1 a R7 en el enrutador de entrada (R1) mediante la dirección de circuito cerrado de R7 (10.0.9.7). La configuración se reserva 10 Mbps de ancho de banda. Además, la configuración deshabilita el algoritmo CSPF, lo que garantiza que los hosts C1 y C2 usen el LSP señalizado por RSVP que corresponda a la ruta más corta de la red del IGP.

Configuración

Procedimiento

Configuración rápida de CLI

Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, luego, copie y pegue los comandos en la CLI en el [edit] nivel de jerarquía.

Procedimiento paso a paso

En el ejemplo siguiente, debe navegar por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración en la Guía del usuario de la CLI.

Para configurar RSVP:

  1. Habilite la familia MPLS en todas las interfaces de tránsito de la red MPLS.

  2. Habilite RSVP en cada interfaz de tránsito en la red MPLS.

  3. Habilite el proceso MPLS en la interfaz de tránsito en la red MPLS.

  4. Defina el LSP en el enrutador de entrada.

  5. Reserve 10 Mbps de ancho de banda en el LSP.

Resultados

Confirme su configuración ingresando el comando desde el show modo de configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones de configuración en este ejemplo para corregirla.

Para la brevedad, este show resultado de comando solo incluye la configuración relevante para este ejemplo. Cualquier otra configuración del sistema se ha reemplazado por puntos suspensivos (...).

Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.

Verificación

Para confirmar que la configuración funciona correctamente, realice estas tareas:

Verificar vecinos de RSVP

Propósito

Verifique que cada dispositivo muestra los vecinos RSVP adecuados, por ejemplo, ese enrutador R1 en Figura 1 enumera tanto el enrutador R3 como el R2 como vecinos RSVP.

Acción

Desde la CLI, ingrese el show rsvp neighbor comando.

El resultado muestra las direcciones IP de los enrutadores vecinos. Compruebe que se enumera cada dirección de circuito cerrado del enrutador RSVP vecino.

Verificar sesiones de RSVP

Propósito

Compruebe que se ha establecido una sesión RSVP entre todos los vecinos RSVP. Además, compruebe que el valor de reserva de ancho de banda está activo.

Acción

Desde la CLI, ingrese el show rsvp session detail comando.

El resultado muestra la información detallada, incluidos los IDs de sesión, la reserva de ancho de banda y las direcciones del próximo salto, para cada sesión de RSVP establecida. Verifique la siguiente información:

  • Cada dirección de vecino RSVP tiene una entrada para cada vecino, enumerada por dirección de circuito cerrado.

  • El estado de cada sesión de LSP es Up.

  • Para Tspec, aparece el valor de ancho de banda adecuado, 10Mbps.

Verificar la presencia de LSP con señal RSVP

Propósito

Verifique que la tabla de enrutamiento del enrutador de entrada (entrada) tenga un LSP configurado para la dirección de circuito cerrado del otro enrutador. Por ejemplo, compruebe que la inet.3 tabla de enrutamiento del enrutador de entrada R1 en Figura 1 tiene un LSP configurado para la dirección de circuito cerrado del enrutador R7.

Acción

Desde la CLI, ingrese el show route table inet.3 comando.

El resultado muestra las rutas RSVP que existen en la tabla de inet.3 enrutamiento. Verifique que un LSP señalizado por RSVP esté asociado con la dirección de circuito cerrado del enrutador de salida (salida), R7, en la red MPLS.

Ejemplo: Configuración de la malla automática RSVP

Los proveedores de servicios suelen usar VPN BGP y MPLS para escalar de manera eficiente la red y, a la vez, ofrecer servicios que generan ingresos. En estos entornos, el BGP se usa para distribuir la información de enrutamiento VPN entre la red del proveedor de servicios, mientras que la MPLS se usa para reenviar ese tráfico VPN de un sitio VPN a otro.

Cuando se agrega un nuevo enrutador de PE que participará en VPN BGP y MPLS, todos los enrutadores de PE existentes anteriormente se deben configurar para emparejarse con el nuevo enrutador de PE para BGP y MPLS. A medida que se agrega cada enrutador de PE nuevo a la red del proveedor de servicios, la carga de configuración pronto se vuelve demasiado para manejar.

Los requisitos de configuración para el emparejamiento bgp se pueden reducir con el uso de reflectores de ruta. En las redes MPLS señaladas por RSVP, la malla automática RSVP puede minimizar la carga de configuración de la parte MPLS de la red. rsvp-te La configuración en todos los enrutadores de PE permite que RSVP cree automáticamente los LSP necesarios cuando se agrega un nuevo enrutador de PE.

Requisitos

En este ejemplo, se utilizan los siguientes componentes de hardware y software:

  • Un enrutador que ejecuta la versión 10.1 o posterior de Junos OS.

  • Una VPN BGP y MPLS que usa RSVP como protocolo de señalización de ruta de conmutación de etiquetas (LSP) MPLS.

Descripción general

En este ejemplo, se muestra cómo configurar la malla automática RSVP en un enrutador de PE mediante la rsvp-te instrucción de configuración. Para que la malla automática RSVP funcione correctamente, todos los enrutadores de PE en la configuración de malla completa deben tener configurada la rsvp-te instrucción. Esto garantiza que los enrutadores de PE nuevos que se agreguen posteriormente también se beneficiarán de la función de malla automática, siempre que también estén configurados con la rsvp-te instrucción.

Dado este requisito, este ejemplo solo muestra la configuración en el enrutador pe recién agregado. Se asume que la malla automática RSVP ya se configuró en los enrutadores de PE existentes.

Topología

En Figura 2, hay tres enrutadores de PE existentes, PE1, PE2 y PE3, en la topología. Se ha agregado PE4 y se configurará la malla automática RSVP. La nube representa la red del proveedor de servicios y la dirección de red, 192.0.2.0/24, se muestra en el centro de la figura.

Figura 2: Red de proveedores de servicios con enrutadores de PERed de proveedores de servicios con enrutadores de PE

Configuración

Configurar la malla automática RSVP implica realizar estas tareas:

  • Habilitación de la rsvp-te instrucción de configuración en el [edit routing-options dynamic-tunnels dynamic-tunnel-name] nivel de jerarquía.

  • Configuración del elemento necesario destination-networks .

    Este elemento de configuración especifica el intervalo de prefijos IPv4 para la red de destino. Solo se pueden crear túneles dentro del intervalo de prefijos especificado.

  • Configuración del elemento necesario label-switched-path-template .

    Este elemento de configuración toma o default-template el nombre de una plantilla LSP preconfigurada como argumento. Es default-template una plantilla definida por el sistema que no requiere configuración de usuario.

Configuración rápida de CLI

Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, luego, copie y pegue los comandos en la CLI en el [edit] nivel de jerarquía.

Enrutador PE4

Configuración de la malla automática RSVP

Procedimiento paso a paso

En el ejemplo siguiente, debe navegar por varios niveles en la jerarquía de configuración. Para obtener instrucciones sobre cómo hacerlo, consulte Uso del editor de CLI en el modo de configuración en la Guía del usuario de cli.

Para habilitar la malla automática RSVP:

  1. Configurar rsvp-te en el nivel jerárquico [edit routing-options dynamic-tunnels] .

  2. Configurar destination-networks en el nivel jerárquico [edit routing-options dynamic-tunnels] .

Resultados

Ejecute el show comando desde el [edit routing-options dynamic-tunnels] nivel de jerarquía para ver los resultados de la configuración:

Verificación

Verificar la existencia de túneles de malla automática RSVP en el enrutador PE4

Propósito

Para comprobar la operación del enrutador PE4 recién configurado, emita el comando desde el show dynamic-tunnels database modo operativo. Este comando mostrará la red de destino a la que se pueden crear túneles dinámicos.

Acción

Verificar la existencia de LSP MPLS en el enrutador PE4

Propósito

Para comprobar la existencia de LSP MPLS en el enrutador PE4, emita el comando desde el show mpls lsp modo operativo. Este comando mostrará el estado de los LSP MPLS.

Acción

Configuración de confirmaciones de saludo para vecinos de RSVP sin sesión

La hello-acknowledgements instrucción controla el comportamiento de confirmación de saludo entre los vecinos de RSVP, independientemente de si están o no en la misma sesión.

Los mensajes de saludo recibidos de los vecinos de RSVP que no forman parte de una sesión RSVP común se descartan. Si configura la hello-acknowledgements instrucción en el [edit protocols rsvp] nivel de jerarquía, los mensajes de saludo de los vecinos que no son de la sesión se reconocen con un mensaje de confirmación de saludo. Cuando se reciben saludos de vecinos que no son de la sesión, se crea una relación de vecino RSVP y ahora se pueden recibir mensajes de saludo periódicos del vecino que no es de la sesión. La hello-acknowledgements instrucción está deshabilitada de forma predeterminada. Configurar esta instrucción permite descubrir enrutadores compatibles con RSVP mediante paquetes de saludo y verifica que la interfaz pueda recibir paquetes RSVP antes de enviar mensajes de configuración MPLS LSP.

Una vez que habilite las confirmaciones de saludo para vecinos de RSVP que no sean de la sesión, el enrutador sigue admitiendo mensajes de saludo de cualquier vecino RSVP que no sea de la sesión, a menos que la propia interfaz se caiga o cambie la configuración. Los vecinos basados en interfaces no se envejecen automáticamente.

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

  • [edit protocols rsvp]

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

Conmutación de LSP lejos de un nodo de red

Puede configurar el enrutador para que cambie los LSP activos de un nodo de red mediante una LSP de derivación habilitada para una interfaz. Esta función se puede utilizar para mantener redes activas cuando un dispositivo necesita ser reemplazado sin interrumpir el tráfico que transita por la red. Los LSP pueden ser estáticos o dinámicos.

  1. Primero debe configurar la protección de vínculo o nodo para el tráfico que debe pasar alrededor del dispositivo de red que tiene la intención de deshabilitar. Para funcionar correctamente, el LSP de derivación debe usar una interfaz lógica diferente a la LSP protegida.
  2. Para preparar el enrutador para comenzar a conmutar el tráfico fuera de un nodo de red, configure la always-mark-connection-protection-tlv instrucción:

    A continuación, el enrutador marca todo el tráfico de OAM que transita por esta interfaz en preparación para cambiar el tráfico a una ruta alternativa según la funcionalidad de OAM.

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

    • [edit protocols mpls interface interface-name]

    • [edit logical-systems logical-system-name protocols mpls interface interface-name]

  3. A continuación, debe configurar la switch-away-lsps instrucción para cambiar el tráfico del LSP protegido a la LSP de derivación, evitando eficazmente el dispositivo de red descendente predeterminado. Esta configuración no derriba el vínculo real.

    Para configurar el enrutador para que cambie el tráfico de un nodo de red, configure la switch-away-lsps instrucción:

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

    • [edit protocols mpls interface interface-name]

    • [edit logical-systems logical-system-name protocols mpls interface interface-name]

Tenga en cuenta las siguientes limitaciones relacionadas con la conmutación de LSP activos lejos de un nodo de red:

  • La función de conmutación se admite solo en enrutadores serie MX.

  • La función de conmutación de distancia no es compatible con el tráfico de conmutación de LSP de punto a multipunto principal para omitir LSP de punto a multipunto. Si configura la switch-away-lsps instrucción para un LSP de punto a multipunto, el tráfico no se cambia al LSP de punto a multipunto de derivación.

  • Si configura la función de conmutación en una interfaz a lo largo de la ruta de un LSP dinámico, no se pueden establecer nuevos LSP dinámicos a través de esa ruta. La función de conmutación evita el comportamiento de hacer antes de la interrupción de los LSP con señal RSVP. El comportamiento de hacer antes de romper normalmente hace que el enrutador intente volver a señalar un LSP dinámico antes de derribar el original.

Configuración de la protección de configuración de RSVP

Puede configurar el mecanismo de reenrutamiento rápido de respaldo de instalaciones para proporcionar protección de configuración para LSP que están en proceso de señalización. Se admiten LSP punto a punto y LSP punto a multipunto. Esta función se aplica en el siguiente caso:

  1. Un vínculo o nodo con errores está presente en la ruta explícita estricta de un LSP antes de que se señale el LSP.

  2. También hay una LSP de omisión que protege el vínculo o el nodo.

  3. RSVP señala el LSP a través del LSP de derivación. El LSP aparece como si se configurara originalmente a lo largo de su ruta principal y, a continuación, no pudo pasar a la LSP de omisión debido a la falla del vínculo o del nodo.

  4. Cuando el vínculo o nodo se ha recuperado, el LSP se puede revertir automáticamente a la ruta principal.

Debe configurar la setup-protection instrucción en cada [edit protocols rsvp] uno de los enrutadores a lo largo de la ruta LSP en la que desea habilitar la protección de configuración de LSP. También debe configurar la ingeniería de tráfico IGP en todos los enrutadores de la ruta LSP. Puede emitir un show rsvp session comando para determinar si el LSP tiene habilitada la protección de configuración en un enrutador que actúa como un punto de reparación local (PLR) o un punto de fusión.

Para habilitar la protección de configuración de RSVP, incluya la setup-protection instrucción

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

  • [edit protocols rsvp]

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

Configuración del equilibrio de carga en los LSP RSVP

De forma predeterminada, cuando haya configurado varios LSP RSVP al mismo enrutador de salida, se selecciona el LSP con la métrica más baja y lleva todo el tráfico. Si todos los LSP tienen la misma métrica, uno de los LSP se selecciona al azar y todo el tráfico se reenvía sobre él.

Como alternativa, puede equilibrar la carga del tráfico en todos los LSP habilitando el equilibrio de carga por paquete.

Para habilitar el equilibrio de carga por paquete en un LSP de entrada, configure la instrucción de la policy-statement siguiente manera:

A continuación, debe aplicar esta instrucción como política de exportación a la tabla de reenvío.

Una vez que se aplica el equilibrio de carga por paquete, el tráfico se distribuye por igual entre los LSP (de forma predeterminada).

Debe configurar el equilibrio de carga por paquete si desea habilitar el reenrutamiento rápido de PFE. Para habilitar el reenrutamiento rápido de PFE, incluya la instrucción para el policy-statement equilibrio de carga por paquete que se muestra en esta sección en la configuración de cada uno de los enrutadores en los que puede tener lugar un reenrutamiento. Consulte también Configuración de reenrutamiento rápido.

También puede equilibrar la carga del tráfico entre los LSP en proporción a la cantidad de ancho de banda configurado para cada LSP. Esta capacidad puede distribuir mejor el tráfico en redes con capacidades de ancho de banda asimétricas entre vínculos externos, ya que el ancho de banda configurado de un LSP suele reflejar la capacidad de tráfico de ese LSP.

Para configurar el equilibrio de carga LSP RSVP, incluya la load-balance instrucción con la bandwidth opción:

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

  • [edit protocols rsvp]

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

Tenga en cuenta la siguiente información cuando use la load-balance instrucción:

  • Si configura la load-balance instrucción, no se modifica el comportamiento de los LSP que se ejecutan actualmente. Para forzar que los LSP en ejecución utilicen el nuevo comportamiento, puede ejecutar un clear mpls lsp comando.

  • La load-balance instrucción solo se aplica a los LSP de entrada que tienen habilitado el equilibrio de carga por paquete.

  • Para los LSP con ingeniería de tráfico con conocimiento de servicios diferenciados, el ancho de banda de un LSP se calcula sumando el ancho de banda de todos los tipos de clase.

Configuración de la malla automática RSVP

Puede configurar RSVP para establecer rutas de conmutación de etiquetas punto a punto (LSP) automáticamente para cualquier enrutador de PE nuevo agregado a una malla completa de LSP. Para habilitar esta función, debe configurar la rsvp-te instrucción en todos los enrutadores de PE en la malla completa.

Nota:

No puede configurar la malla automática RSVP junto con CCC. CCC no puede utilizar los LSP generados dinámicamente.

Para configurar la malla automática RSVP, incluya la rsvp-te instrucción:

Puede configurar estas instrucciones en los siguientes niveles jerárquicos:

  • [edit routing-options dynamic-tunnels tunnel-name]

  • [edit logical-systems logical-system-name routing-options dynamic-tunnels tunnel-name]

También debe configurar las siguientes instrucciones para habilitar la malla automática RSVP:

  • destination-networks: especifique el intervalo de prefijos IP versión 4 (IPv4) para la red de destino. Se pueden iniciar túneles dinámicos dentro del intervalo de prefijos IPv4 especificado.

  • label-switched-path-template (Multicast): puede configurar la plantilla predeterminada explícitamente con la default-template opción o puede configurar una plantilla LSP propia mediante la template-name opción. La plantilla LSP actúa como una configuración de modelo para los LSP generados dinámicamente.

Configuración de temporizadores para mensajes de actualización de RSVP

RSVP utiliza dos parámetros de temporización relacionados:

  • refresh-time: el tiempo de actualización controla el intervalo entre la generación de mensajes de actualización sucesivos. El valor predeterminado para el tiempo de actualización es de 45 segundos. Este número se deriva del valor predeterminado de la refresh-time instrucción de 30, multiplicado por un valor fijo de 1,5. Este cálculo difiere de RFC 2205, que establece que el tiempo de actualización se debe multiplicar por un valor aleatorio en el intervalo de 0,5 a 1,5.

    Los mensajes de actualización incluyen la ruta y los mensajes resv. Los mensajes de actualización se envían periódicamente para que los estados de reserva en los nodos vecinos no se atenuesen. Cada ruta y mensaje resv lleva el valor del temporizador de actualización, y el nodo de recepción extrae este valor de los mensajes.

  • keep-multiplier: el multiplicador keep es un entero pequeño configurado localmente del 1 al 255. El valor predeterminado es 3. Indica la cantidad de mensajes que se pueden perder antes de que un estado determinado se declare obsoleto y se debe eliminar. El multiplicador keep afecta directamente a la vida útil de un estado RSVP.

Para determinar la duración de un estado de reserva, utilice la siguiente fórmula:

En el peor de los casos, (keep-multiplier – 1) se deben perder mensajes de actualización sucesivos antes de eliminar un estado de reserva.

No recomendamos configurar un temporizador de saludo RSVP corto. Si se necesita la detección rápida de un vecino con errores, configure los temporizadores de saludo cortos IGP (OSPF o IS-IS).

De forma predeterminada, el valor del temporizador de actualización es de 30 segundos. Para modificar este valor, incluya la refresh-time instrucción:

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

  • [edit protocols rsvp]

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

El valor predeterminado del multiplicador keep es 3. Para modificar este valor, incluya la keep-multiplier instrucción:

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

  • [edit protocols rsvp]

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

Preferencia de las sesiones de RSVP

Siempre que el ancho de banda no sea suficiente para manejar todas las sesiones de RSVP, puede controlar la preferencia de las sesiones RSVP. De forma predeterminada, una sesión RSVP solo es adelantada por una nueva sesión de mayor prioridad.

Para adelantar siempre una sesión cuando el ancho de banda es insuficiente, incluya la preemption instrucción con la aggressive opción:

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

  • [edit protocols rsvp]

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

Para deshabilitar la preferencia de sesión de RSVP, incluya la preemption instrucción con la disabled opción:

Para volver al valor predeterminado (es decir, adelantar una sesión solo para una nueva sesión de mayor prioridad), incluya la preemption instrucción con la normal opción:

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

  • [edit protocols rsvp]

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

Configuración de la señalización de MTU en RSVP

Para configurar la señalización de unidad de transmisión máxima (MTU) en RSVP, debe configurar MPLS para permitir que los paquetes IP se fragmenten antes de que se encapsulan en MPLS. También debe configurar la señalización de MTU en RSVP. Para fines de solución de problemas, puede configurar la señalización de MTU solo sin habilitar la fragmentación de paquetes.

Para configurar la señalización de MTU en RSVP, incluya la path-mtu instrucción:

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

  • [edit protocols mpls]

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

En las siguientes secciones se describe cómo habilitar la fragmentación de paquetes y la señalización de MTU en RSVP:

Habilitación de la señalización de MTU en RSVP

Para habilitar la señalización de MTU en RSVP, incluya la rsvp mtu-signaling instrucción:

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

  • [edit protocols mpls path-mtu]

  • [edit logical-systems logical-system-name protocols mpls path-mtu]

Una vez que haya confirmado la configuración, los cambios en el comportamiento de señalización de MTU para RSVP surten efecto la próxima vez que se actualice la ruta.

Puede configurar la mtu-signaling instrucción por sí misma en el [edit protocols mpls path-mtu rsvp] nivel de jerarquía. Esto puede ser útil para la solución de problemas. Si configura solo la mtu-signaling instrucción, puede usar el show rsvp session detail comando para determinar cuál es la MTU más pequeña en un LSP. El show rsvp session detail comando muestra el valor de MTU recibido y enviado en el objeto Adspec.

Habilitación de la fragmentación de paquetes

Para permitir que los paquetes IP se fragmenten antes de encapsularse en MPLS, incluya la allow-fragmentation instrucción:

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

  • [edit protocols mpls path-mtu]

  • [edit logical-systems logical-system-name protocols mpls path-mtu]

    Nota:

    No configure la allow-fragmentation instrucción por sí sola. Configure siempre junto con la mtu-signaling instrucción.

Configuración de Ultimate-Hop Popping para LSP

De forma predeterminada, los LSP con señal RSVP utilizan penúltimo salto emergente (PHP). Figura 3 ilustra un penúltimo salto que aparece LSP entre el enrutador PE1 y el enrutador PE2. El enrutador CE1 reenvía un paquete a su próximo salto (enrutador PE1), que también es la entrada LSP. El enrutador PE1 inserta la etiqueta 1 en el paquete y reenvía el paquete etiquetado al enrutador P1. El enrutador P1 completa la operación de intercambio de etiquetas MPLS estándar, intercambia la etiqueta 1 por la etiqueta 2 y reenvía el paquete al enrutador P2. Dado que el enrutador P2 es el penúltimo enrutador de salto para LSP al enrutador PE2, primero extrae la etiqueta y, luego, reenvía el paquete al enrutador PE2. Cuando el enrutador PE2 lo recibe, el paquete puede tener una etiqueta de servicio, una etiqueta explicit-null o simplemente ser un paquete IP o VPLS sin formato. El ENRUTADOR PE2 reenvía el paquete sin etiquetar al enrutador CE2.

Figura 3: Penúltimo salto para una LSPPenúltimo salto para una LSP

También puede configurar ultimate-hop popping (UHP) (como se muestra en Figura 4) para LSP con señal RSVP. Algunas aplicaciones de red pueden requerir que los paquetes lleguen al enrutador de salida (enrutador PE2) con una etiqueta externa no nula. Para un LSP de salto final, el penúltimo enrutador (enrutador P2 in Figura 4) realiza la operación de intercambio de etiquetas MPLS estándar (en este ejemplo, la etiqueta 2 para la etiqueta 3 ) antes de reenviar el paquete al enrutador de salida PE2. El enrutador PE2 extrae la etiqueta externa y realiza una segunda búsqueda de la dirección del paquete para determinar el destino final. A continuación, reenvía el paquete al destino adecuado (ya sea el enrutador CE2 o el enrutador CE4).

Figura 4: Ultimate-Hop Popping para un LSPUltimate-Hop Popping para un LSP

Las siguientes aplicaciones de red requieren que configure LSP UHP:

  • MPLS-TP para monitoreo de rendimiento y OAM en banda

  • Circuitos virtuales de protección de borde

Las siguientes funciones no admiten el comportamiento de UHP:

  • LSP señalizados por LDP

  • LSP estáticos

  • LSP punto a multipunto

  • CCC

  • traceroute Comando

Para obtener más información sobre el comportamiento de UHP, consulte Borrador de Internet draft-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt, Comportamiento no PHP y Asignación fuera de banda para LSP RSVP-TE.

Para los LSP con señal RSVP punto a punto, el comportamiento UHP se señala desde la entrada LSP. Según la configuración del enrutador de entrada, RSVP puede indicar el LSP UHP con el conjunto de indicadores que no sean PHP. Los mensajes de ruta RSVP llevan los dos indicadores en el objeto LSP-ATTRIBUTES. Cuando el enrutador de salida recibe el mensaje PATH, asigna una etiqueta no nula al LSP. RSVP también crea e instala dos rutas en la tabla de enrutamiento mpls.0. S hace referencia al bit S de la etiqueta MPLS, que indica si se ha alcanzado la parte inferior de la pila de etiquetas.

  • Ruta S=0: indica que hay más etiquetas en la pila. El siguiente salto de esta ruta apunta a la tabla de enrutamiento mpls.0, lo que activa una búsqueda de etiquetas MPLS encadenado para descubrir las etiquetas MPLS restantes en la pila.

  • Ruta S=1: indica que no hay más etiquetas. El siguiente salto apunta a la tabla de enrutamiento inet.0 si la plataforma admite búsquedas encadenadas y multifamiliar. Como alternativa, la ruta de etiqueta puede apuntar a una interfaz VT para iniciar el reenvío IP.

Si habilita LSP UHP, las aplicaciones MPLS como VPN de capa 3, VPLS, VPN de capa 2 y circuitos de capa 2 pueden utilizar los LSP UHP. A continuación, se explica cómo los LSP UHP afectan a los diferentes tipos de aplicaciones MPLS:

  • VPN de capa 2 y circuitos de capa 2: un paquete llega al enrutador de PE (salida del LSP UHP) con dos etiquetas. La etiqueta externa (S=0) es la etiqueta UHP y la etiqueta interna (S=1) es la etiqueta VC . Una búsqueda basada en la etiqueta de transporte da como resultado un identificador de tabla para la tabla de enrutamiento mpls.0. Hay una ruta adicional en la tabla de enrutamiento mpls.0 correspondiente a la etiqueta interna. Una búsqueda basada en la etiqueta interna da como resultado el próximo salto del enrutador CE.

  • VPN de capa 3: un paquete llega al enrutador de PE (salida del LSP UHP) con dos etiquetas. La etiqueta externa (S=0) es la etiqueta UHP y la etiqueta interna es la etiqueta VPN (S=1). Una búsqueda basada en la etiqueta de transporte da como resultado el identificador de la tabla para la tabla de enrutamiento mpls.0. Hay dos casos en este caso. De forma predeterminada, las VPN de capa 3 anuncian la etiqueta por salto siguiente. Una búsqueda basada en la etiqueta interna da como resultado el siguiente salto hacia el enrutador CE. Sin embargo, si ha configurado la vrf-table-label instrucción para la instancia de enrutamiento VPN de capa 3, la etiqueta LSI interna apunta a la tabla de enrutamiento VRF. También se completa una búsqueda IP para la tabla de enrutamiento VRF.

    Nota:

    UHP para VPN de capa 3 configuradas con la vrf-table-label instrucción solo se admite en plataformas de enrutamiento universal 5G serie MX.

  • VPLS: un paquete llega al enrutador de PE (salida del LSP UHP) con dos etiquetas. La etiqueta externa es la etiqueta de transporte (S=0) y la etiqueta interna es la etiqueta VPLS (S=1). Una búsqueda basada en la etiqueta de transporte da como resultado el identificador de la tabla para la tabla de enrutamiento mpls.0. Una búsqueda basada en la etiqueta interna en la tabla de enrutamiento mpls.0 da como resultado la interfaz de túnel LSI de la instancia de enrutamiento VPLS si los servicios de túnel no están configurados (o una interfaz VT no está disponible). Los enrutadores serie MX 3D admiten búsqueda en cadena y búsqueda multifamiliar.

    Nota:

    La UHP para VPLS configurada con la no-tunnel-service instrucción solo se admite en enrutadores serie MX 3D.

  • IPv4 a través de MPLS: un paquete llega al enrutador de PE (salida del LSP UHP) con una etiqueta (S=1). Una búsqueda basada en esta etiqueta devuelve una interfaz de túnel VT. Otra búsqueda IP se completa en la interfaz VT para determinar dónde reenviar el paquete. Si la plataforma de enrutamiento admite búsquedas multifamiliar y encadenadas (por ejemplo, enrutadores MX 3D y enrutadores de transporte de paquetes serie PTX), la búsqueda basada en la ruta de etiqueta (S=1) apunta a la tabla de enrutamiento inet.0.

  • IPv6 sobre MPLS: para la tunelización IPv6 a través de MPLS, los enrutadores de PE anuncian rutas IPv6 entre sí con un valor de etiqueta de 2. Esta es la etiqueta null explícita para IPv6. Como resultado, los próximos saltos de reenvío para rutas IPv6 que se aprenden de enrutadores de PE remotos normalmente insertan dos etiquetas. La etiqueta interna es 2 (podría ser diferente si el enrutador de PE publicitario es de otro proveedor) y la etiqueta del enrutador es la etiqueta LSP. Los paquetes llegan al enrutador de PE (salida del LSP UHP) con dos etiquetas. La etiqueta externa es la etiqueta de transporte (S=0) y la etiqueta interna es la etiqueta explicit-null IPv6 (etiqueta 2). La búsqueda basada en la etiqueta interna de la tabla de enrutamiento mpls.0 redirige de nuevo a la tabla de enrutamiento mpls.0. En los enrutadores serie MX 3D, se quita la etiqueta interna (etiqueta 2) y se realiza una búsqueda IPv6 mediante la tabla de enrutamiento inet6.0.

  • Habilitación de LSP PHP y UHP: puede configurar ambos LSP PHP y UHP a través de las mismas rutas de red. Puede separar el tráfico PHP y UHP seleccionando reenviar los próximos saltos de LSP mediante una expresión regular con la install-nexthop instrucción. También puede separar el tráfico simplemente nombrando los LSP adecuadamente.

Las siguientes instrucciones habilitan el salto final para un LSP. Puede habilitar esta función en un LSP específico o para todos los LSP de entrada configurados en el enrutador. Configure estas instrucciones en el enrutador en la entrada LSP.

  1. Para habilitar el salto final, incluya la ultimate-hop-popping instrucción:

    Incluya esta instrucción en el [edit protocols mpls label-switched-path label-switched-path-name] nivel jerárquico para habilitar el salto final en un LSP específico. Incluya esta instrucción en el [edit protocols mpls] nivel jerárquico para habilitar el salto final en todos los LSP de entrada configurados en el enrutador. También puede configurar la ultimate-hop-popping instrucción en los niveles de jerarquía equivalentes [edit logical-routers] .

    Nota:

    Cuando se habilita el salto final, RSVP intenta renunciar a los LSP existentes como LSP de salto final de una manera de hacer antes del descanso. Si un enrutador de salida no admite salto final, el LSP existente se derriba (RSVP envía un mensaje PathTear a lo largo de la ruta de un LSP, quitando el estado de la ruta y el estado de reserva dependiente y liberando los recursos de red asociados).

    Si deshabilita el salto final, RSVP resigna los LSP existentes como penúltimo salto saltando LSP de una manera de hacer antes del descanso.

  2. Si desea habilitar tanto los saltos finales como los próximos saltos encadenados solo en enrutadores serie MX 3D, también debe configurar la enhanced-ip opción para la network-services instrucción:

    Configure esta instrucción en el nivel de [edit chassis] jerarquía. Una vez que haya configurado la network-services instrucción, debe reiniciar el enrutador para habilitar el comportamiento de UHP.

Configuración de RSVP para hacer estallar la etiqueta en el enrutador ultimate-hop

Puede controlar el valor de etiqueta anunciado en el enrutador de salida de un LSP. La etiqueta anunciada predeterminada es la etiqueta 3 (etiqueta Null implícita). Si se anuncia la etiqueta 3, el penúltimo enrutador de salto elimina la etiqueta y envía el paquete al enrutador de salida. Cuando se habilita el salto final, se anuncia la etiqueta 0 (etiqueta IP versión 4 [IPv4] Explicit Null). El salto final garantiza que todos los paquetes que atraviesan una red MPLS incluyan una etiqueta.

Nota:

Los enrutadores de Juniper Networks ponen en cola paquetes basados en la etiqueta entrante. Los enrutadores de otros proveedores pueden poner en cola paquetes de manera diferente. Tenga esto en cuenta cuando trabaje con redes que contienen enrutadores de varios proveedores.

Para configurar ultimate-hop popping para RSVP, incluya la explicit-null instrucción:

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

  • [edit protocols mpls]

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

Habilitación de ultimate-hop popping en LSP de punto a multipunto

De forma predeterminada, para los LSP de punto a punto y punto a multipunto, se utiliza el penúltimo salto emergente para el tráfico MPLS. Las etiquetas MPLS se eliminan de los paquetes del enrutador justo antes del enrutador de salida del LSP. A continuación, los paquetes IP sin formato se reenvían al enrutador de salida. Para el salto final, el enrutador de salida es responsable de eliminar la etiqueta MPLS y procesar el paquete IP sin formato.

Puede ser beneficioso habilitar el salto final en LSP de punto a multipunto, particularmente cuando el tráfico de tránsito está atravesando el mismo dispositivo de salida. Si habilita el salto final, se puede enviar una sola copia del tráfico a través del vínculo entrante, lo que ahorra un ancho de banda significativo. De forma predeterminada, el salto final está deshabilitado.

Configure la tunnel-services instrucción para habilitar el salto final para LSP de punto a multipunto. Cuando habilita el salto final, Junos OS selecciona una de las interfaces de túnel de circuito cerrado virtual (VT) disponibles para devolver los paquetes al PFE para el reenvío IP. De forma predeterminada, el proceso de selección de interfaz VT se realiza automáticamente. El control de admisión de ancho de banda se utiliza para limitar la cantidad de LSP que se pueden utilizar en una interfaz VT. Una vez que se consume todo el ancho de banda en una interfaz, Junos OS selecciona otra interfaz VT con ancho de banda suficiente para el control de admisión.

Si un LSP requiere más ancho de banda del que está disponible en cualquiera de las interfaces VT, no se puede habilitar el salto final y se habilita el penúltimo salto emergente en su lugar.

Para que el salto final aparezca en LSP de punto a multipunto para que funcione correctamente, el enrutador de salida debe tener una PIC que proporcione servicios de túnel, como la PIC de servicios de túnel o la PIC de servicios adaptables. Se necesitan servicios de túnel para hacer estallar la etiqueta MPLS final y para devolver paquetes para búsquedas de direcciones IP.

Puede configurar explícitamente qué interfaces VT manejan el tráfico RSVP incluyendo la devices opción de la tunnel-services instrucción. La devices opción le permite especificar qué interfaces VT debe usar RSVP. Si no configura esta opción, se pueden utilizar todas las interfaces VT disponibles para el enrutador.

Para habilitar el salto final para los LSP de punto a multipunto de salida en un enrutador, configure la tunnel-services instrucción:

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

  • [edit protocols rsvp]

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

Para habilitar el salto final para LSP de punto a multipunto de salida, también debe configurar la interface instrucción con la all opción:

Debe configurar esta instrucción en el nivel de [edit protocols rsvp] jerarquía.

Rastreo del tráfico de protocolo RSVP

Para rastrear el tráfico del protocolo RSVP, incluya la traceoptions instrucción:

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

  • [edit protocols rsvp]

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

Puede especificar los siguientes indicadores específicos de RSVP en la instrucción RSVP traceoptions :

Utilice la file instrucción para especificar el nombre del archivo que recibe el resultado de la operación de rastreo. Todos los archivos se colocan en el directorio /var/log. Recomendamos que coloque la salida de seguimiento RSVP en el archivo rsvp-log.

  • all: todas las operaciones de rastreo.

  • error: todas las condiciones de error detectadas

  • event— Eventos relacionados con RSVP (ayuda a rastrear eventos relacionados con el reinicio correcto de RSVP)

  • lmp— Interacciones del protocolo de administración de vínculos (LMP) RSVP

  • packets— Todos los paquetes RSVP

  • path—Todos los mensajes de ruta

  • pathtear—Mensajes PathTear

  • resv— Mensajes resv

  • resvtear— Mensajes resvTear

  • route— Información de enrutamiento

  • state— Transiciones de estado de sesión, incluso cuando los LSP con señal RSVP suban y bajan.

Nota:

Utilice el indicador de all seguimiento y el modificador de detail marca con precaución, ya que esto puede hacer que la CPU se vuelva muy ocupada.

Para ver el archivo de registro generado cuando se habilitan las opciones de seguimiento RSVP, emita el show log file-name comando, donde file-name está el archivo que especificó mediante la traceoptions instrucción.

Para obtener información general sobre el rastreo y las opciones de rastreo global, consulte la Biblioteca de protocolos de enrutamiento de Junos OS para dispositivos de enrutamiento.

Ejemplos: Rastreo del tráfico de protocolo RSVP

Trace los mensajes de ruta RSVP con detalle:

Trace todos los mensajes RSVP:

Trace todas las condiciones de error de RSVP:

Trace las transiciones de estado RSVP:

Salida del archivo de registro RSVP

El siguiente es un resultado de ejemplo generado mediante la emisión del show log file-name comando en un enrutador en el que se han habilitado las opciones de seguimiento RSVP con el state indicador configurado. El E-D LSP señalizado por RSVP se muestra siendo derribado en mar 11 14:04:36.707092. El 11 de marzo de 14:05:30.101492, se muestra volviendo a subir.

Reinicio agraciado de RSVP

El reinicio correcto de RSVP permite que un enrutador que se someta a un reinicio informe a sus vecinos adyacentes de su condición. El enrutador de reinicio solicita un período de gracia del vecino o del par, que luego puede cooperar con el enrutador de reinicio. El enrutador de reinicio aún puede reenviar tráfico MPLS durante el período de reinicio; la convergencia en la red no se interrumpe. El reinicio no es visible para el resto de la red y el enrutador de reinicio no se elimina de la topología de red. El reinicio correcto de RSVP se puede habilitar tanto en enrutadores de tránsito como en enrutadores de entrada. Está disponible para LSP punto a punto y LSP punto a multipunto.

El reinicio correcto de RSVP se describe en las siguientes secciones:

Terminología de reinicio agraciada del RSVP

Tiempo de reinicio (en milisegundos)

El valor predeterminado es 60 000 milisegundos (1 minuto). La hora de reinicio se anuncia en el mensaje de saludo. El tiempo indica cuánto tiempo debe esperar un vecino para recibir un mensaje de saludo de un enrutador de reinicio antes de declarar que el enrutador está muerto y purgar estados.

Junos OS puede invalidar la hora de reinicio anunciada de un vecino si la hora es mayor que un tercio de la hora de reinicio local. Por ejemplo, dado el tiempo de reinicio predeterminado de 60 segundos, un enrutador esperaría 20 segundos o menos para recibir un mensaje de saludo de un vecino que reiniciaba. Si la hora de reinicio es cero, el vecino que se reinicia se puede declarar inactivo de inmediato.

Tiempo de recuperación (en milisegundos)

Solo se aplica cuando el canal de control está activo (el intercambio de saludos está completo) antes de la hora de reinicio. Solo se aplica a fallas nodal.

Cuando se está llevando a cabo un reinicio correcto, se anuncia el tiempo que falta para completar una recuperación. En otras ocasiones, este valor es cero. El tiempo máximo de recuperación anunciado es de 2 minutos (120 000 milisegundos).

Durante el tiempo de recuperación, un nodo que reinicia intenta recuperar sus estados perdidos con la ayuda de sus vecinos. El vecino del nodo de reinicio debe enviar los mensajes de ruta con las etiquetas de recuperación al nodo de reinicio en un período de la mitad del tiempo de recuperación. El nodo de reinicio considera que el reinicio correcto se completa después de su tiempo de recuperación anunciado.

Operación de reinicio elegante de RSVP

Para que el reinicio correcto de RSVP funcione, la función debe estar habilitada en la instancia de enrutamiento global. El reinicio correcto de RSVP se puede deshabilitar en el nivel de protocolo (solo para RSVP) o a nivel global para todos los protocolos.

El reinicio correcto de RSVP requiere lo siguiente de un enrutador de reinicio y los vecinos del enrutador:

  • Para el enrutador de reinicio, el reinicio correcto de RSVP intenta mantener las rutas instaladas por RSVP y las etiquetas asignadas, de modo que el tráfico continúe reenviado sin interrupción. El reinicio correcto de RSVP se realiza lo suficientemente rápido como para reducir o eliminar el impacto en los nodos vecinos.

  • Los enrutadores vecinos deben tener habilitado el modo de reinicio correcto RSVP, lo que les permite ayudar a un enrutador que intenta reiniciar RSVP.

Un objeto llamado reinicio cap que se envía en mensajes de saludo RSVP anuncia la capacidad de reinicio de un nodo. El nodo vecino envía un objeto Recover Label al nodo de reinicio para recuperar su estado de reenvío. Este objeto es esencialmente la etiqueta antigua que el nodo de reinicio anunciaba antes de que el nodo se cayeran.

A continuación, se enumeran los comportamientos de reinicio correctos de RSVP, que varían según la configuración y en qué características están habilitadas:

  • Si deshabilita el modo auxiliar, Junos OS no intenta ayudar a un vecino a reiniciar RSVP. Cualquier información que llegue con un objeto Restart Cap de un vecino se ignora.

  • Cuando se habilita el reinicio correcto en la configuración de la instancia de enrutamiento, el enrutador puede reiniciarse correctamente con la ayuda de sus vecinos. RSVP anuncia un objeto Restart Cap (RSVP RESTART) en mensajes de saludo en los que se especifican los tiempos de reinicio y recuperación (ninguno de los valores es 0).

  • Si deshabilita explícitamente el reinicio correcto de RSVP en el [protocols rsvp] nivel de jerarquía, el objeto Restart Cap se anuncia con tiempos de reinicio y recuperación especificados como 0. Se admite el reinicio de enrutadores vecinos (a menos que el modo auxiliar esté deshabilitado), pero el propio enrutador no conserva el estado de reenvío RSVP y no puede recuperar su estado de control.

  • Si después de un reinicio RSVP se da cuenta de que no se ha conservado ningún estado de reenvío, el objeto Restart Cap se anuncia con tiempos de reinicio y recuperación especificados como 0.

  • Si el reinicio correcto y el modo auxiliar están deshabilitados, el reinicio correcto de RSVP está completamente deshabilitado. El enrutador no reconoce ni anuncia los objetos de reinicio correctoSVP.

No puede configurar explícitamente los valores para los tiempos de reinicio y recuperación.

A diferencia de otros protocolos, no hay forma de que RSVP determine que ha completado un procedimiento de reinicio, excepto un tiempo de espera fijo. Todos los procedimientos de reinicio correctos de RSVP se basan en el temporizador. Un show rsvp version comando puede indicar que el reinicio sigue en curso, incluso si todas las sesiones de RSVP están en marcha y las rutas se restauran.

Procesamiento del objeto Restart Cap

Las siguientes suposiciones se realizan acerca de un vecino basado en el objeto Restart Cap (suponiendo que una falla de canal de control se pueda distinguir sin ambigüedades de un reinicio de nodo):

  • Un vecino que no anuncia el objeto Restart Cap en sus mensajes de saludo no puede ayudar a un enrutador con recuperación de estado o etiqueta, ni puede realizar un reinicio correcto de RSVP.

  • Después de un reinicio, un vecino que anuncia un objeto Restart Cap con un tiempo de reinicio igual a cualquier valor y un tiempo de recuperación igual a 0 no ha conservado su estado de reenvío. Cuando un tiempo de recuperación es igual a 0, el vecino se considera muerto y cualquier estado relacionado con este vecino se purga, independientemente del valor de la hora de reinicio.

  • Después de un reinicio, un vecino que anuncia su tiempo de recuperación con un valor distinto de 0 puede mantener o ha mantenido el estado de reenvío. Si el enrutador local ayuda a su vecino con procedimientos de reinicio o recuperación, envía un objeto Recover Label a este vecino.

Configuración del reinicio correcto de RSVP

Son posibles las siguientes configuraciones de reinicio con gracia de RSVP:

  • El reinicio correcto y el modo auxiliar están habilitados (el predeterminado).

  • El reinicio correcto está habilitado, pero el modo auxiliar está deshabilitado. Un enrutador configurado de esta manera puede reiniciarse correctamente, pero no puede ayudar a un vecino con sus procedimientos de reinicio y recuperación.

  • El reinicio correcto está deshabilitado, pero el modo auxiliar está habilitado. Un enrutador configurado de esta manera no puede reiniciarse correctamente, pero puede ayudar a un vecino de reinicio.

  • El reinicio correcto y el modo auxiliar están deshabilitados. Esta configuración deshabilita por completo el reinicio correcto de RSVP (incluidos los procedimientos de reinicio y recuperación y el modo de aplicación auxiliar). El enrutador se comporta como un enrutador que no admite un reinicio correcto de RSVP.

Nota:

Para activar el reinicio correcto de RSVP, debe establecer el temporizador de reinicio agraciado global en al menos 180 segundos.

En las siguientes secciones se describe cómo configurar el reinicio correcto de RSVP:

Habilitación del reinicio correcto para todos los protocolos de enrutamiento

Para habilitar el reinicio correcto para RSVP, debe habilitar el reinicio correcto para todos los protocolos que admiten un reinicio correcto en el enrutador. Para obtener más información acerca del reinicio correcto, consulte la biblioteca de protocolos de enrutamiento de Junos OS para dispositivos de enrutamiento.

Para habilitar el reinicio correcto en el enrutador, incluya la graceful-restart instrucción:

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

  • [edit routing-options]

  • [edit logical-systems logical-system-name routing-options]

Deshabilitar el reinicio correcto para RSVP

De forma predeterminada, el reinicio correcto de RSVP y el modo de aplicación auxiliar RSVP se habilitan cuando se habilita el reinicio correcto. Sin embargo, puede deshabilitar una o ambas funciones.

Para deshabilitar el reinicio y la recuperación correctos de RSVP, incluya la disable instrucción en el [edit protocols rsvp graceful-restart] nivel de jerarquía:

Deshabilitar el modo de aplicación auxiliar RSVP

Para deshabilitar el modo auxiliar RSVP, incluya la helper-disable instrucción en el [edit protocols rsvp graceful-restart] nivel de jerarquía:

Configuración del tiempo máximo de recuperación de auxiliar

Para configurar la cantidad de tiempo que el enrutador conserva el estado de sus vecinos RSVP mientras se someten a un reinicio correcto, incluya la maximum-helper-recovery-time instrucción en el [edit protocols rsvp graceful-restart] nivel de jerarquía. Este valor se aplica a todos los enrutadores vecinos, por lo que debe basarse en el tiempo requerido por el vecino RSVP más lento para recuperarse.

Configuración del tiempo máximo de reinicio del asistente

Para configurar el retraso entre cuando el enrutador descubre que un enrutador vecino ha caído y cuando declara el vecino hacia abajo, incluya la maximum-helper-restart-time instrucción en el [edit protocols rsvp graceful-restart] nivel de jerarquía. Este valor se aplica a todos los enrutadores vecinos, por lo que debe basarse en el tiempo requerido por el vecino RSVP más lento para reiniciar.

Descripción general de túneles LSP RSVP

Un túnel de ruta conmutada por etiquetas (LSP) del protocolo de reserva de recursos (RSVP) le permite enviar LSP RSVP dentro de otros LSP RSVP. Esto permite que un administrador de red proporcione ingeniería de tráfico de un extremo de la red al otro. Una aplicación útil para esta función es conectar enrutadores de borde del cliente (CE) con enrutadores de borde de proveedor (PE) mediante el uso de un LSP RSVP y, luego, túnel este LSP de borde dentro de un segundo LSP RSVP que viaja a través del núcleo de la red.

Debe tener una comprensión general de los conceptos de MPLS y conmutación de etiquetas. Para obtener más información acerca de MPLS, consulte la Guía de configuración de aplicaciones MPLS de Junos.

Un túnel LSP RSVP agrega el concepto de adyacencia de reenvío, similar al que se usa para la conmutación de etiquetas multiprotocolo generalizada (GMPLS). (Para obtener más información acerca de GMPLS, consulte Guía del usuario de Junos GMPLS.

La adyacencia de reenvío crea una ruta de túnel para enviar datos entre dispositivos par en una red LSP RSVP. Una vez que se ha establecido un LSP de adyacencia de reenvío (FA-LSP), se pueden enviar otros LSP a través de FA-LSP mediante el uso de la ruta más corta restringida primero (CSPF), el protocolo de administración de vínculos (LMP), la ruta más corta abierta primero (OSPF) y el RSVP.

Para habilitar un túnel LSP RSVP, Junos OS utiliza los siguientes mecanismos:

  • LMP: diseñado originalmente para GMPLS, LMP establece adyacencias de reenvío entre pares de túnel LSVP de RSVP, y mantiene y asigna recursos para vínculos de ingeniería de tráfico.

  • Extensiones OSPF: OSPF se diseñó para enrutar paquetes a interfaces físicas y lógicas relacionadas con una tarjeta de interfaz física (PIC). Este protocolo se ha extendido a paquetes de enrutamiento a interfaces de par virtual definidas en una configuración LMP.

  • Extensiones RSVP-TE: RSVP-TE fue diseñado para indicar la configuración de LSP de paquetes a interfaces físicas. El protocolo se ha extendido para solicitar la configuración de ruta para LSP de paquetes que viajan a interfaces de par virtual definidas en una configuración LMP.

    Nota:

    A partir de Junos OS versión 15.1, la compatibilidad con varias instancias se extiende a MPLS RSVP-TE. Esta compatibilidad solo está disponible para el tipo de instancia de enrutador virtual. Un enrutador puede crear y participar en varias particiones de topología de TE independientes, lo que permite que cada dominio de TE particionado se escale de forma independiente. RSVP-TE de varias instancias ofrece la flexibilidad de elegir a mano las entidades del plano de control que deben ser conscientes de la instancia, por ejemplo, un enrutador puede participar en varias instancias de TE mientras sigue ejecutando una sola instancia bgp.

    La implementación de Junos OS de MPLS RSVP-TE se escala para mejorar la usabilidad, la visibilidad, la configuración y la solución de problemas de los LSP en la versión 16.1 de Junos OS.

    Estas mejoras facilitan la configuración de RSVP-TE a escala:

    • Garantizar la preparación del plano de datos LSP durante la renuncia de LSP antes de que el tráfico atraviese el LSP con el mecanismo de auto ping RSVP-TE LSP.

      Un LSP no debe comenzar a transportar tráfico a menos que se sepa que se programó en el plano de datos. El intercambio de datos en el plano de datos LSP, como solicitudes de ping LSP, ocurre en el enrutador de entrada antes de cambiar el tráfico a un LSP o a su instancia de MBB. En las redes grandes, este tráfico puede sobrecargar un enrutador de salida LSP, ya que el LSP de salida necesita responder a las solicitudes de ping LSP. El mecanismo de auto ping LSP permite que el LER de entrada cree mensajes de respuesta de ping LSP y los envíe a través del plano de datos LSP. Al recibir estos mensajes, el LER de salida los reenvía a la entrada, lo que indica la vida real del plano de datos LSP. Esto garantiza que el LSP no comience a transportar tráfico antes de que se programe el plano de datos.

    • Eliminar el límite duro actual de 64K LSP en un enrutador de entrada y escalar el número total de LSP con LSP señaladas RSVP-TE. Puede haber hasta 64 K LSP configurados por salida. Anteriormente, este límite era el número agregado de LSP que se podían configurar en el LER de entrada.

    • Prevención del derribo abrupto de LSP por el enrutador de entrada debido al retraso en la señalización del LSP en los enrutadores de tránsito.

    • Permitir una vista flexible de los conjuntos de datos LSP para facilitar la visualización de datos característicos de LSP.

    Nota:

    A partir de Junos OS versión 17.4, se introduce un temporizador predeterminado de 1800 segundos para el auto ping.

Existen las siguientes limitaciones para las jerarquías de LSP:

  • No se admiten LSP basados en conexiones cruzadas de circuito (CCC).

  • No se admite un reinicio correcto.

  • La protección de vínculos no está disponible para FA-LSP ni en el punto de salida de la adyacencia de reenvío.

  • Los LSP de punto a multipunto no se admiten en los FA-LSP.

Ejemplo: Configuración de túnel LSP RSVP

Figura 5: Diagrama de topología de túnel LSP RSVPDiagrama de topología de túnel LSP RSVP

Figura 5 muestra un LSP RSVP de extremo a extremo llamado e2e_lsp_r0r5 que se origina en el enrutador 0 y termina en el enrutador 5. En tránsito, este LSP atraviesa la FA-LSP fa_lsp_r1r4. La ruta de retorno está representada por el LSP e2e_lsp_r5r0 RSVP de extremo a extremo que viaja por la FA-LSP fa_lsp_r4r1.

En el enrutador 0, configure el LSP RSVP de extremo a extremo que viaja al enrutador 5. Utilice una ruta estricta que atraviese el enrutador 1 y el vínculo de ingeniería de tráfico LMP que viaja del enrutador 1 al enrutador 4.

Enrutador 0

En el enrutador 1, configure una FA-LSP para llegar al enrutador 4. Establezca un vínculo de ingeniería de tráfico LMP y una relación par LMP con el enrutador 4. Haga referencia al FA-LSP en el vínculo de ingeniería de tráfico y agregue la interfaz par en OSPF y RSVP.

Cuando la ruta de retorno LSP de extremo a extremo llega al enrutador 1, la plataforma de enrutamiento realiza una búsqueda de enrutamiento y puede reenviar tráfico al enrutador 0. Asegúrese de configurar OSPF correctamente entre los enrutadores 0 y 1.

Enrutador 1

En el enrutador 2, configure OSPF, MPLS y RSVP en todas las interfaces que transportan los FA-LSP a través de la red central.

Enrutador 2

En el enrutador 3, configure OSPF, MPLS y RSVP en todas las interfaces que transportan los FA-LSP a través de la red central.

Enrutador 3

En el enrutador 4, configure una ruta de retorno FA-LSP para llegar al enrutador 1. Establezca un vínculo de ingeniería de tráfico LMP y una relación par LMP con el enrutador 1. Haga referencia al FA-LSP en el vínculo de ingeniería de tráfico y agregue la interfaz par en OSPF y RSVP.

Cuando el LSP inicial de extremo a extremo llega al enrutador 4, la plataforma de enrutamiento realiza una búsqueda de enrutamiento y puede reenviar tráfico al enrutador 5. Asegúrese de configurar OSPF correctamente entre el enrutador 4 y el enrutador 5.

Enrutador 4

En el enrutador 5, configure la ruta de retorno de extremo a extremo RSVP LSP que viaja al enrutador 0. Utilice una ruta estricta que atraviese el enrutador 4 y el vínculo de ingeniería de tráfico LMP que viaja del enrutador 4 al enrutador 1.

Enrutador 5

Verificar su trabajo

Para comprobar que el túnel LSP RSVP funciona correctamente, ejecute los siguientes comandos:

  • show ted database (extensive)

  • show rsvp session name (extensive)

  • show link-management

  • show link-management te-link name (detail)

Para ver estos comandos utilizados con el ejemplo de configuración, consulte las siguientes secciones:

Enrutador 0

En el enrutador 0, puede comprobar que los FA-LSP aparecen como rutas válidas en la base de datos de ingeniería de tráfico. En este caso, busque las rutas del enrutador 1 (10.255.41.216) y del enrutador 4 (10.255.41.217) que hacen referencia a las direcciones de vínculo de ingeniería de tráfico LMP de 172.16.30.1 y 172.16.30.2. También puede emitir el show rsvp session extensive comando para buscar la ruta del LSP de extremo a extremo a medida que viaja al enrutador 5 a través del FA-LSP.

Enrutador 1

En el enrutador 1, compruebe que la configuración del vínculo de ingeniería de tráfico LMP funciona y que el LSP de extremo a extremo está atravesando el vínculo de ingeniería de tráfico mediante la emisión del show link-management conjunto de comandos. También puede emitir el show rsvp session extensive comando para confirmar que la FA-LSP está operativa.

Configuración de interfaces par en OSPF y RSVP

Después de establecer pares LMP, debe agregar interfaces par a OSPF y RSVP. Una interfaz par es una interfaz virtual que se utiliza para admitir la adyacencia de control entre dos pares.

El nombre de interfaz del par debe coincidir con la peer peer-name instrucción configurada en LMP en el [edit protocols link-management] nivel jerárquico. Dado que las interfaces par envían y reciben paquetes de protocolo reales, las interfaces par se pueden señalizar y anunciar a pares como cualquier otra interfaz física configurada para OSPF y RSVP. Para configurar el enrutamiento OSPF para pares LMP, incluya la peer-interface instrucción en el [edit protocols ospf area area-number] nivel de jerarquía. Para configurar la señalización RSVP para pares de LMP, incluya la peer-interface instrucción en el [edit protocols rsvp] nivel dehierarchía.

Definición de rutas conmutadas por etiquetas para FA-LSP

A continuación, defina su FA-LSP incluyendo la label-switched-path instrucción en el [edit protocols mpls] nivel de jerarquía. Incluya el ID del enrutador del par en la to instrucción en el [edit protocols mpls label-switched-path] nivel de jerarquía. Dado que los LSP de paquetes son unidireccionales, debe crear un FA-LSP para llegar al par y un segundo FA-LSP para volver del par.

Establecer información de ruta FA-LSP

Cuando configure rutas LSP explícitas para una FA-LSP, debe usar la dirección remota del vínculo de ingeniería de tráfico como dirección de salto siguiente. Cuando se admite CSPF, puede usar cualquier opción de ruta que desee. Sin embargo, cuando CSPF está deshabilitado con la no-cspf instrucción en el [edit protocols mpls label-switched-path lsp-name] nivel de jerarquía, debe usar rutas estrictas.

Nota:

Si el LSP de extremo a extremo se origina en la misma plataforma de enrutamiento que la FA-LSP, debe deshabilitar CSPF y utilizar rutas estrictas.

Opción: Derribar los LSP RSVP con gracia

Puede derribar un LSP RSVP en un proceso de dos pasos que retira con gracia la sesión RSVP utilizada por el LSP. Para todos los vecinos que admiten un desprendimiento elegante, la plataforma de enrutamiento envía una solicitud de desprendimiento al punto de conexión de destino para el LSP y todos los vecinos de RSVP en la ruta. La solicitud se incluye en el ADMIN_STATUS campo del paquete RSVP. Cuando los vecinos reciben la solicitud, se preparan para que se retire la sesión de RSVP. La plataforma de enrutamiento envía un segundo mensaje para completar el desmontaje de la sesión de RSVP. Si un vecino no admite un desgarro elegante, la solicitud se maneja como una desintegración de sesión estándar en lugar de una agraciada.

Para realizar un desmontaje correcto de una sesión RSVP, emita el clear rsvp session gracefully comando. Opcionalmente, puede especificar la dirección de origen y destino de la sesión de RSVP, el identificador LSP del remitente RSVP y el identificador de túnel de la sesión de RSVP. Para usar estos calificadores, incluya las connection-sourceopciones , connection-destination, lsp-idy tunnel-id cuando emita el clear rsvp session gracefully comando.

También puede configurar la cantidad de tiempo que la plataforma de enrutamiento espera a que los vecinos reciban la solicitud de desintegración correcta antes de iniciar la desintegración real mediante la inclusión de la graceful-deletion-timeout instrucción en el [edit protocols rsvp] nivel de jerarquía. El valor predeterminado de tiempo de espera de eliminación elegante es de 30 segundos, con un valor mínimo de 1 segundo y un valor máximo de 300 segundos. Para ver el valor actual configurado para un tiempo de espera de eliminación correcto, ejecute el comando del show rsvp version modo operativo.

Tabla de historial de versiones
Liberación
Descripción
19.4R1
16.1
Sin embargo, a partir de la versión 16.1 de Junos OS, cuando el RSVP saludo mensajes de tiempo de salida, las sesiones RSVP se reducen.