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 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 objetivo principal del software RSVP de Junos es admitir la señalización dinámica dentro de las rutas de conmutación de 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 nivel de [edit protocols mpls] 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 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 desde el enrutador local y está destinada al destino del LSP.

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

Para pasar la información de señalización de conmutación de etiquetas, RSVP admite cuatro objetos adicionales: Objeto Label Request, 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 Record Route no es obligatorio.

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

  • Active 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 las rutas RSVP conmutadas por etiquetas (LSP) para que utilicen una métrica de retraso a fin de calcular la ruta. Para configurar, use las opciones de CLI que hemos introducido en la [edit protocols mpls label-switched-path name] jerarquía.

Ejemplo: Configuración de RSVP y MPLS

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

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

Configuración de interfaces RSVP

En las secciones siguientes 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—Habilitar todas las funciones de reducción de actualización de RSVP: Agrupación de mensajes RSVP, ID de mensaje RSVP, entrega confiable de mensajes 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: desactiva la agrupación de mensajes RSVP y la actualización del resumen.

  • no-reliable: desactiva el ID de mensaje RSVP, la entrega confiable de mensajes y la actualización del 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 confiable de mensajes 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 estándar de mensajes. En este caso, no se genera ningún error y 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 se configura con la instrucción y no-reliable la aggregate instrucción o con las reliable instrucciones yno-aggregate. Si un vecino RSVP envía un objeto de actualización de resumen a este enrutador, no se genera ningún error, pero no se puede procesar el objeto de actualización de resumen. En consecuencia, los estados de RSVP pueden agotar el tiempo de espera en este enrutador si el vecino confía solo en la actualización de resumen para actualizar esos estados de RSVP.

Recomendamos, a menos que existan requisitos específicos, que configure la reducción de actualización de RSVP de manera similar en cada vecino de 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 del 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 actualización 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 RSVP reales recibidos del vecino

Para obtener esta información, puede emitir un show rsvp neighbor detail comando. A continuación se muestra el resultado de ejemplo:

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

Configuración del intervalo de saludo RSVP

RSVP supervisa el estado de los vecinos del protocolo de puerta de enlace interior (IGP) (IS-IS u OSPF) y se basa en los protocolos IGP para detectar cuándo falla un nodo. Si un protocolo IGP declara a un vecino caído (porque ya no se reciben paquetes de saludo), RSVP también derriba ese vecino. Sin embargo, los protocolos IGP y RSVP todavía actúan independientemente cuando se acerca a un vecino.

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

El intervalo de saludo de RSVP también puede verse afectado cuando el equipo de otro proveedor interrumpe una sesión de RSVP. Por ejemplo, un enrutador vecino que no sea de Juniper Networks podría estar configurado para supervisar los 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 derivación cuando hay uno disponible. Consulte no-node-hello-on-bypass para obtener información sobre cómo volver al comportamiento histórico de enviar saludos a través del próximo salto del IGP.

Para obtener una lista de los 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 protocolos RSVP se pueden autenticar para garantizar que solo los vecinos de confianza participen en la configuración de las reservas. De forma predeterminada, la autenticación RSVP está deshabilitada.

La autenticación RSVP utiliza un resumen basado en mensajes MD5 de código de autenticación de mensajes hash (HMAC). Este esquema genera un resumen del mensaje 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 calculado 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 autenticarán en esta interfaz.

La autenticación MD5 proporciona protección contra la falsificación y la modificación de mensajes. También puede prevenir ataques de reproducción. Sin embargo, no proporciona confidencialidad, porque todos los mensajes se envían en texto claro.

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 por ciento del ancho de banda para un tipo de clase para reservas RSVP. Cuando se sobresuscribe 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 Configuración del porcentaje de suscripción de ancho de banda para LSP.

Configuración del umbral de actualización 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 actualmente en los vínculos de base de datos de ingeniería de tráfico se origina en RSVP. Cuando el ancho de banda de un vínculo cambia, 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 la red. Luego, los nodos de la red saben cuánto ancho de banda está disponible en el vínculo de la 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 demasiados recursos del sistema. Dependiendo del número de nodos de una red, puede que no sea deseable realizar una actualización de IGP para pequeños cambios en el ancho de banda. Mediante la configuración de la update-threshold instrucción en el nivel de [edit protocols rsvp] jerarquía, puede ajustar el umbral en el que un cambio en el ancho de banda reservado desencadena una actualización de IGP.

Puede configurar un valor de 0,001 por ciento a 20 por ciento (el valor predeterminado es 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 ha configurado la instrucción para que sea update-threshold del 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 desencadena una actualización del IGP. Sin embargo, si el ancho de banda reservado en un vínculo cambia en un 20 por ciento 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 opción situada debajo de threshold-value la update-threshold instrucción.

Si el valor de umbral está configurado para ser superior al 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 está threshold-value configurado de más de 200 Mbps, el threshold-value límite es de 200 Mbps. El threshold-percent se muestra como 20.000% y el threshold-value como 200Mbps.

Nota:

Las dos opciones, threshold-percent 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 más bajas. Como resultado, cuando se configura una opción, la otra opción se calcula y se muestra en la CLI.

Por ejemplo, en un enlace de 1 Gbps, si el threshold-percent está configurado al 5%, se threshold-value calcula y se muestra como 50Mbps. Del mismo modo, si el threshold-value está configurado en 50 m, entonces el threshold-percent se calcula y se muestra como 5%.

Para ajustar el umbral en el que un cambio en el ancho de banda reservado desencadena 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 utilizando información de ancho de banda de base de datos de ingeniería de tráfico obsoleta en un vínculo. Si RSVP intenta establecer un LSP en esa ruta, es posible que no haya suficiente ancho de banda 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 de ancho de banda actualizada en la red. A continuación, CSPF puede volver a calcular la ruta utilizando 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 de jerarquía o en el [edit logical-systems logical-system-name protocols mpls] nivel de jerarquía 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 para LSP) mediante la información proporcionada por los mensajes de PathErr. Consulte Mejora de la precisión de la base de datos de ingeniería de tráfico con mensajes RSVP PathErr.

Configuración de RSVP para interfaces no numeradas

Junos OS admite la ingeniería de tráfico RSVP en interfaces no numeradas. La información de ingeniería de tráfico sobre vínculos no numerados se transporta en las extensiones de ingeniería de tráfico IGP para OSPF e IS-IS, tal como se describe en RFC 4203, Extensiones OSPF en soporte de conmutación de etiquetas multiprotocolo generalizada (GMPLS) y RFC 4205, Extensiones de sistema intermedio a sistema intermedio (IS-IS) en soporte de conmutación de etiquetas multiprotocolo 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 enlaces no numerados en el protocolo de reserva de recursos - Ingeniería de tráfico (RSVP-TE). Esta característica le permite evitar tener que configurar direcciones IP para cada interfaz que participa en la red señalada RSVP.

Para configurar RSVP para interfaces no numeradas, debe configurar el enrutador con un ID de enrutador utilizando la router-id instrucción especificada en el nivel de [edit routing-options] 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 utilizando la dirección 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. Se recomienda configurar una interfaz secundaria en el circuito cerrado además de configurar el ID del enrutador.

Configuración de RSVP Node-ID Hellos

Puede configurar saludos RSVP basados en ID de nodo para garantizar que los enrutadores de Juniper Networks puedan interoperar con los equipos 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 declaración aclaratoria. Los saludos de ID de nodo RSVP son útiles si ha configurado BFD para detectar problemas en las interfaces RSVP, lo que le permite deshabilitar los saludos de interfaz para estas interfaces. También puede utilizar node-ID holos para procedimientos de reinicio correctos.

Los saludos de ID de nodo se pueden habilitar globalmente para todos los vecinos de RSVP. De forma predeterminada, la compatibilidad con hola 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 hola 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 derivación cuando hay uno disponible. Consulte no-node-hello-on-bypass para obtener información sobre cómo volver al comportamiento histórico de enviar saludos a través del próximo salto del IGP.

Para habilitar los 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 la interfaz RSVP globalmente. Este tipo de configuración puede ser necesaria en redes donde el enrutador de Juniper Networks tiene numerosas conexiones RSVP con equipos de otros proveedores. Sin embargo, si deshabilita los saludos de interfaz RSVP globalmente, también puede configurar un intervalo de saludo en una interfaz RSVP mediante la instrucción hello-interval. Esta configuración deshabilita los saludos de interfaz RSVP globalmente, pero habilita los saludos de interfaz RSVP en la interfaz especificada (la interfaz RSVP en la que configura 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 de jerarquía:

  • [edit protocols rsvp]

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

Ejemplo: Configuración de LSP señalados por RSVP

En este ejemplo se muestra cómo crear un LSP entre enrutadores de una red IP utilizando 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 de una red IP. En este ejemplo, se configura una red de ejemplo como se muestra en Figura 1.

Topología

Figura 1: LSP típico con señal de RSVPLSP típico con señal de 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 de 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) utilizando la dirección de circuito cerrado de R7 (10.0.9.7). La configuración 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 utilicen el LSP con señal RSVP que corresponda a la ruta más corta del IGP de red.

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, a continuación, copie y pegue los comandos en la CLI en el nivel de [edit] jerarquía.

Procedimiento paso a paso

En el ejemplo siguiente, debe explorar 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 modo de configuración en la Guía del usuario de 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 de 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 la configuración introduciendo 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 fines de brevedad, este resultado del comando show solo incluye la configuración relevante para este ejemplo. Cualquier otra configuración en el sistema se reemplazó por puntos suspensivos (...).

Cuando termine de configurar el dispositivo, ingrese commit en el modo de configuración.

Verificación

Para confirmar que la configuración funcione correctamente, realice las siguientes tareas:

Verificar RSVP Neighbors

Propósito

Verifique que cada dispositivo muestre los vecinos RSVP apropiados, por ejemplo, que el enrutador R1 enumera Figura 1 tanto el enrutador R3 como el enrutador R2 como vecinos de RSVP.

Acción

Desde la CLI, ingrese el comando show rsvp neighbor.

La salida muestra las direcciones IP de los enrutadores vecinos. Verifique que cada dirección de circuito cerrado del enrutador RSVP vecino aparezca en la lista.

Verificación de sesiones RSVP

Propósito

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

Acción

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

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

  • 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 LSP es Up.

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

Comprobación de la presencia de LSP señalados por RSVP

Propósito

Compruebe 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 comando show route table inet.3.

El resultado muestra las rutas RSVP que existen en la tabla de inet.3 enrutamiento. Compruebe que un LSP con señal RSVP esté asociado a la dirección de circuito cerrado del enrutador de salida R7 en la red MPLS.

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

Los proveedores de servicios a menudo usan VPN BGP y MPLS para escalar la red de manera eficiente mientras ofrecen servicios que generan ingresos. En estos entornos, BGP se usa para distribuir la información de enrutamiento VPN a través de la red del proveedor de servicios, mientras que MPLS se usa para reenviar ese tráfico VPN de un sitio VPN a otro.

Al agregar un nuevo enrutador PE que participará en las VPN BGP y MPLS, todos los enrutadores PE existentes anteriormente deben configurarse para emparejarse con el nuevo enrutador PE tanto para BGP como para MPLS. A medida que se agrega cada nuevo enrutador PE a la red del proveedor de servicios, la carga de configuración pronto se vuelve demasiado difícil de 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ñalizadas RSVP, la malla automática RSVP puede minimizar la carga de configuración para la parte MPLS de la red. La configuración rsvp-te en todos los enrutadores PE permite que RSVP cree automáticamente los LSP necesarios cuando se agrega un nuevo enrutador PE.

Requisitos

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

  • Un enrutador que ejecute Junos OS versión 10.1 o posterior.

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

Descripción general

En este ejemplo se muestra cómo configurar la malla automática RSVP en un enrutador PE mediante la instrucción configuration rsvp-te . Para que la malla automática RSVP funcione correctamente, todos los enrutadores PE en la configuración de malla completa deben tener configurada la rsvp-te instrucción. Esto asegura que cualquier enrutador PE nuevo que se agregue más adelante también se beneficiará 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 supone que la malla automática RSVP ya se ha configurado en los enrutadores PE existentes.

Topología

En Figura 2, hay tres enrutadores 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

La configuración de la malla automática RSVP implica realizar estas tareas:

  • Habilitar la instrucción de rsvp-te configuración en el nivel jerárquico [edit routing-options dynamic-tunnels dynamic-tunnel-name] .

  • 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 rango de prefijos especificado.

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

    Este elemento de configuración toma como default-template argumento o el nombre de una plantilla LSP preconfigurada. La es una plantilla definida por el default-template 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, a continuación, copie y pegue los comandos en la CLI en el nivel de [edit] jerarquía.

Enrutador PE4

Configuración de la malla automática RSVP

Procedimiento paso a paso

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

Para habilitar la malla automática RSVP:

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

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

Resultados

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

Verificación

Verificación de la existencia de túneles de malla automáticos RSVP en el enrutador PE4

Propósito

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

Acción

Comprobación de 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 de MPLS.

Acción

Configuración de confirmaciones de saludo para vecinos que no sean RSVP de 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.

Se descartan los mensajes de hola recibidos de vecinos de RSVP que no forman parte de una sesión RSVP común. Si configura la hello-acknowledgements instrucción en el nivel jerárquico, los [edit protocols rsvp] mensajes de saludo de vecinos que no son de sesión se confirman con un mensaje de confirmación de saludo. Cuando se reciben saludos de vecinos que no son de 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 sesión. La hello-acknowledgements instrucción está deshabilitada de forma predeterminada. La configuración de esta instrucción permite descubrir enrutadores compatibles con RSVP mediante paquetes de saludo y comprueba que la interfaz es capaz de recibir paquetes RSVP antes de enviar cualquier mensaje de configuración de LSP MPLS.

Una vez que habilite las confirmaciones de saludo para los vecinos que no sean RSVP de sesión, el enrutador continúa reconociendo los mensajes de saludo de cualquier vecino que no sea RSVP de sesión, a menos que la interfaz deje de funcionar o cambie la configuración. Los vecinos basados en interfaces no se eliminan automáticamente.

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

  • [edit protocols rsvp]

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

Alejar los LSP de un nodo de red

Puede configurar el enrutador para conmutar los LSP activos fuera de un nodo de red mediante un LSP de derivación habilitado para una interfaz. Esta función se puede usar 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 por el dispositivo de red que desea deshabilitar. Para funcionar correctamente, el LSP de derivación debe utilizar una interfaz lógica diferente a la del LSP protegido.
  2. Para preparar el enrutador para comenzar a cambiar 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 OAM que transita por esta interfaz como preparación para cambiar el tráfico a una ruta alternativa basada en 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 al LSP de derivación, omitiendo efectivamente el dispositivo de red descendente predeterminado. El vínculo real en sí no se reduce por esta configuración.

    Para configurar el enrutador de modo que cambie el tráfico fuera 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 fuera de un nodo de red:

  • La función de cambio solo se admite en los enrutadores de la serie MX.

  • La función de cambio no se admite para cambiar el tráfico de los LSP primarios de punto a multipunto para omitir los LSP de punto a multipunto. Si configura la switch-away-lsps instrucción para un LSP punto a multipunto, el tráfico no se cambia al LSP de omitir punto a multipunto.

  • Si configura la característica de cambio en una interfaz a lo largo de la ruta de un LSP dinámico, no se pueden establecer nuevos LSP dinámicos en esa ruta. La función de desactivación evita el comportamiento de hacer antes de la interrupción de los LSP señalados por RSVP. El comportamiento de hacer antes de romper normalmente hace que el enrutador primero intente volver a señalar un LSP dinámico antes de derribar el original.

Configuración de la protección del programa de instalación de RSVP

Puede configurar el mecanismo de reenrutamiento rápido de la copia de seguridad de las instalaciones para proporcionar protección de instalación para los LSP que están en proceso de señalización. Se admiten tanto los LSP punto a punto como los LSP punto a multipunto. Esta característica es aplicable en el siguiente escenario:

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

  2. También hay un LSP de derivación que protege el enlace o nodo.

  3. RSVP señala el LSP a través del LSP de derivación. El LSP aparece como si se hubiera configurado originalmente a lo largo de su ruta principal y luego se hubiera conmutado por error al LSP de derivación debido a un error de vínculo o 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 el [edit protocols rsvp] en cada uno de los enrutadores a lo largo de la ruta de LSP en la que desea habilitar la protección del programa de instalació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 o no la protección de configuración en un enrutador que actúa como punto de reparación local (PLR) o punto de combinación.

Para habilitar la protección del programa de instalació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 entre los LSP de RSVP

De forma predeterminada, cuando haya configurado varios LSP RSVP en el mismo enrutador de salida, se selecciona el LSP con la métrica más baja y transporta 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 a través de é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 policy-statement instrucción de la siguiente manera:

A continuación, debe aplicar esta instrucción como una 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 equitativamente 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 donde puede tener lugar un reenrutamiento. Consulte también Configuración del 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étrico a través de vínculos externos, ya que el ancho de banda configurado de un LSP normalmente refleja la capacidad de tráfico de ese LSP.

Para configurar el equilibrio de carga del LSP de 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 utilice 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 que se ejecutan actualmente usen el nuevo comportamiento, puede emitir un clear mpls lsp comando.

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

  • Para los LSP de ingeniería de tráfico con reconocimiento 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 (LSP) punto a punto automáticamente para cualquier enrutador PE nuevo agregado a una malla completa de LSP. Para habilitar esta característica, debe configurar la rsvp-te instrucción en todos los enrutadores 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 instrucciones siguientes 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 rango de prefijos IPv4 especificado.

  • label-switched-path-template (Multicast): puede configurar la plantilla predeterminada explícitamente mediante 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 debe multiplicarse por un valor aleatorio en el intervalo de 0,5 a 1,5.

    Los mensajes de actualización incluyen mensajes de ruta y Resv. Los mensajes de actualización se envían periódicamente para que los estados de reserva en los nodos vecinos no agoten el tiempo de espera. Cada ruta y mensaje Resv lleva el valor del temporizador de actualización y el nodo receptor extrae este valor de los mensajes.

  • keep-multiplier—El multiplicador keep es un pequeño entero configurado localmente del 1 al 255. El valor predeterminado es 3. Indica el número de mensajes que se pueden perder antes de que un estado determinado se declare obsoleto y deba eliminarse. El multiplicador de mantenimiento afecta directamente a la duración de un estado RSVP.

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

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

No recomendamos configurar un temporizador de saludo RSVP corto. Si se necesita un descubrimiento rápido de un vecino fallido, configure temporizadores de saludo cortos de 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 de mantenimiento 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 sobre las sesiones de RSVP

Siempre que el ancho de banda sea insuficiente para manejar todas las sesiones RSVP, puede controlar la preferencia de las sesiones RSVP. De forma predeterminada, una sesión RSVP solo tiene preferencia sobre una nueva sesión de mayor prioridad.

Para tener preferencia siempre a 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 RSVP, incluya la preemption instrucción con la disabled opción:

Para volver al valor predeterminado (es decir, tener preferencia sobre 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 MTU en RSVP

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

Para configurar la señalización 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 secciones siguientes se describe cómo habilitar la fragmentación de paquetes y la señalización MTU en RSVP:

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

Para habilitar la señalización 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 confirmada la configuración, los cambios en el comportamiento de señalización de MTU para RSVP surtirán efecto la próxima vez que se actualice la ruta.

Puede configurar la mtu-signaling instrucción por sí misma en el nivel jerárquico [edit protocols mpls path-mtu rsvp] . 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 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 encapsularlos 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 solo. Siempre configúrelo junto con la mtu-signaling instrucción.

Configuración de Ultimate-Hop Popping para LSP

De forma predeterminada, los LSP señalados por RSVP utilizan el estallido de penúltimo salto (PHP). Figura 3 ilustra un LSP de penúltimo salto entre el enrutador PE1 y el enrutador PE2. El enrutador CE1 reenvía un paquete a su siguiente salto (enrutador PE1), que también es la entrada de 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 estándar de intercambio de etiquetas MPLS, intercambia la etiqueta 1 por la etiqueta 2 y reenvía el paquete al enrutador P2. Dado que el enrutador P2 es el enrutador de penúltimo salto para el LSP al enrutador PE2, primero abre 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 explícita nula o simplemente ser un paquete IP o VPLS simple. El enrutador PE2 reenvía el paquete sin etiqueta al enrutador CE2.

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

También puede configurar el estallido de salto máximo (UHP) (como se muestra en Figura 4) para los LSP señalados por 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 última salto, el penúltimo enrutador (enrutador P2 en Figura 4) realiza la operación estándar de intercambio de etiquetas MPLS (en este ejemplo, etiqueta 2 para etiqueta 3) antes de reenviar el paquete al enrutador PE2 de salida. El enrutador PE2 abre la etiqueta exterior 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 apropiado (ya sea el enrutador CE2 o CE4).

Figura 4: Ultimate-hop popping para un LSPUltimate-hop popping para un LSP

Las siguientes aplicaciones de red requieren que configure LSP de UHP:

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

  • Circuitos virtuales de protección de bordes

Las siguientes características no admiten el comportamiento UHP:

  • LSP señalados por LDP

  • LSP estáticos

  • LSP de punto a multipunto

  • CCC

  • traceroute mandar

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

Para los LSP señalados por RSVP punto a punto, el comportamiento de UHP se señala desde la entrada del LSP. Según la configuración del enrutador de entrada, RSVP puede señalar el LSP UHP con el indicador no PHP establecido. Los mensajes RSVP PATH llevan los dos indicadores del 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 se refiere al bit S de la etiqueta MPLS, que indica si se ha alcanzado o no la parte inferior de la pila de etiquetas.

  • Ruta S=0: indica que hay más etiquetas en la pila. El siguiente salto para esta ruta apunta a la tabla de enrutamiento mpls.0, lo que desencadena una búsqueda de etiquetas MPLS encadenadas 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 la búsqueda encadenada y multifamiliar. Alternativamente, la ruta de etiqueta puede apuntar a una interfaz VT para iniciar el reenvío de IP.

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

  • VPN de capa 2 y circuitos de capa 2: un paquete llega al enrutador 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 siguiente salto del enrutador CE.

  • VPN de capa 3: un paquete llega al enrutador 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 tabla para la tabla de enrutamiento mpls.0. Hay dos casos en este escenario. 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 instrucción solo es compatible con las vrf-table-label plataformas de enrutamiento universal 5G de la serie MX.

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

    Nota:

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

  • IPv4 a través de MPLS: un paquete llega al enrutador PE (salida del UHP LSP) con una etiqueta (S=1). Una búsqueda basada en esta etiqueta devuelve una interfaz de túnel VT. Se completa otra búsqueda IP en la interfaz VT para determinar dónde reenviar el paquete. Si la plataforma de enrutamiento admite búsquedas multifamiliares y encadenadas (por ejemplo, enrutadores MX 3D y enrutadores de transporte de paquetes de la serie PTX), la búsqueda basada en la ruta de la 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 PE anuncian rutas IPv6 entre sí con un valor de etiqueta de 2. Esta es la etiqueta nula explícita para IPv6. Como resultado, los siguientes saltos de reenvío para las rutas IPv6 que se aprenden de enrutadores de PE remotos normalmente envían 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 PE (salida del UHP LSP) con dos etiquetas. La etiqueta externa es la etiqueta de transporte (S=0) y la etiqueta interna es la etiqueta IPv6 explícita-nula (etiqueta 2). La búsqueda basada en la etiqueta interna de la tabla de enrutamiento mpls.0 redirige a la tabla de enrutamiento mpls.0. En los enrutadores de la serie MX 3D, la etiqueta interna (etiqueta 2) se quita y se realiza una búsqueda IPv6 mediante la tabla de enrutamiento inet6.0.

  • Habilitación de LSP de PHP y UHP: puede configurar los LSP de PHP y UHP en las mismas rutas de red. Puede separar el tráfico PHP y UHP seleccionando reenviar los próximos saltos de LSP utilizando una expresión regular con la install-nexthop instrucción. También puede separar el tráfico simplemente asignando un nombre adecuado a los LSP.

Las siguientes instrucciones permiten el estallido de salto máximo 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 del LSP.

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

    Incluya esta instrucción en el nivel jerárquico para habilitar el [edit protocols mpls label-switched-path label-switched-path-name] estallido de salto máximo en un LSP específico. Incluya esta instrucción en el nivel jerárquico para habilitar el [edit protocols mpls] estallido de salto máximo 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 habilita el popping-ultimate-hop, RSVP intenta volver a señalar los LSP existentes como LSP de ultimate-hop de forma que se produzca antes de la ruptura. Si un enrutador de salida no admite la aparición de saltos finales, el LSP existente se desactiva (RSVP envía un mensaje PathTear a lo largo de la ruta de un LSP, eliminando el estado de la ruta y el estado de reserva dependiente y liberando los recursos de red asociados).

    Si deshabilita el popping de último salto, RSVP vuelve a indicar los LSP existentes como LSP de estallido de penúltimo salto de forma que se preparen antes de la pausa.

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

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

Configuración de RSVP para que aparezca la etiqueta en el enrutador de salto final

Puede controlar el valor de etiqueta anunciado en el enrutador de salida de un LSP. La etiqueta anunciada predeterminada es la etiqueta 3 (etiqueta nula implícita). Si se anuncia la etiqueta 3, el enrutador del penúltimo salto quita la etiqueta y envía el paquete al enrutador de salida. Cuando está habilitado el estallido de salto definitivo, se anuncia la etiqueta 0 (etiqueta IP versión 4 [IPv4] nula explícita). El último salto garantiza que cualquier paquete que atraviese una red MPLS incluya una etiqueta.

Nota:

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

Para configurar el último salto emergente 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 del estallido de salto máximo en LSP de punto a multipunto

De forma predeterminada, tanto para los LSP punto a punto como para los multipunto, se usa el estallido de penúltimo salto para el tráfico MPLS. Las etiquetas MPLS se quitan de los paquetes del enrutador justo antes del enrutador de salida del LSP. Los paquetes IP simples se reenvían al enrutador de salida. Para la ventana emergente de último salto, el enrutador de salida es responsable tanto de eliminar la etiqueta MPLS como de procesar el paquete IP simple.

Puede ser beneficioso habilitar la aparición de saltos máximos en LSP de punto a multipunto, especialmente cuando el tráfico de tránsito atraviesa el mismo dispositivo de salida. Si habilita el popping, se puede enviar una sola copia del tráfico a través del enlace entrante, lo que ahorra un ancho de banda significativo. De forma predeterminada, el estallido de salto final está deshabilitado.

Para habilitar el estallido de salto máximo para los LSP de punto a multipunto, configure la tunnel-services instrucción. Cuando se habilita la ventana emergente de salto máximo, 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 de IP. De forma predeterminada, el proceso de selección de la interfaz VT se realiza automáticamente. El control de admisión de ancho de banda se usa para limitar el número de LSP que se pueden usar en una interfaz VT. Una vez consumido todo el ancho de banda en una interfaz, Junos OS selecciona otra interfaz VT con suficiente ancho de banda para el control de admisión.

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

Para que la aparición de salto máximo en los LSP de punto a multipunto 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 adaptativos. Los servicios de túnel son necesarios para abrir 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 para la tunnel-services instrucción. La devices opción le permite especificar qué interfaces VT deben ser utilizadas por RSVP. Si no configura esta opción, se pueden utilizar todas las interfaces VT disponibles para el enrutador.

Para habilitar la aparición de salto máximo para los LSP punto a multipunto de salida de 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 estallido de salto máximo para los LSP 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.

Seguimiento del tráfico del protocolo RSVP

Para realizar un seguimiento del 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 seguimiento. Todos los archivos se colocan en el directorio /var/log. Se recomienda colocar el resultado del 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 RSVP-Link (LMP)

  • packets—Todos los paquetes RSVP

  • path—Todos los mensajes de ruta

  • pathtear—Mensajes de PathTear

  • resv—Mensajes Resv

  • resvtear—Mensajes de ResvTear

  • route—Información de enrutamiento

  • state—Transiciones de estado de sesión, incluso cuando los LSP señalados por RSVP suben y bajan.

Nota:

Use el indicador de rastreo y el all modificador de indicador detail con precaución, ya que podrían hacer que la CPU se vuelva muy ocupada.

Para ver el archivo de registro generado al habilitar RSVP traceoptions, ejecute el show log file-name comando, donde file-name es el archivo que especificó mediante la traceoptions instrucción.

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

Ejemplos: Seguimiento del tráfico del protocolo RSVP

Rastree los mensajes de ruta RSVP en detalle:

Rastree todos los mensajes RSVP:

Rastree todas las condiciones de error de RSVP:

Transiciones de estado de RSVP de seguimiento:

Salida del archivo de registro RSVP

A continuación se muestra un ejemplo de salida generado al emitir el show log file-name comando en un enrutador en el que se han habilitado traceoptions RSVP con el state indicador configurado. El LSP E-D con señal RSVP se muestra siendo derribado el Mar 11 14:04:36.707092. El Mar 11 14:05:30.101492, se muestra volviendo a subir.

RSVP Reinicio agraciado

El reinicio correcto RSVP permite que un enrutador que se somete a un reinicio informe a sus vecinos adyacentes de su condición. El enrutador de reinicio solicita un período de gracia al vecino o par, que luego puede cooperar con el enrutador de reinicio. El enrutador que se reinicia 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 tanto para LSP punto a punto como para LSP punto a multipunto.

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

Terminología de reinicio correcto de 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 que se reinicia antes de declarar ese enrutador muerto y estados de purga.

Junos OS puede anular el tiempo de reinicio anunciado por un vecino si el tiempo es superior a un tercio del tiempo 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 se reinicia. Si el tiempo de reinicio es cero, el vecino de reinicio puede ser declarado muerto inmediatamente.

Tiempo de recuperación (en milisegundos)

Solo se aplica cuando el canal de control está activo (el intercambio de saludos se ha completado) antes de la hora de reinicio. Solo se aplica a errores nodales.

Cuando un reinicio correcto está en curso, se anuncia el tiempo restante 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 de reinicio 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 plazo de la mitad del tiempo de recuperación. El nodo de reinicio considera que su reinicio correcto se ha completado después del tiempo de recuperación anunciado.

Operación de reinicio correcto 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 a 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 de los vecinos del enrutador:

  • Para el enrutador que se reinicia, RSVP correctamente restart intenta mantener las rutas instaladas por RSVP y las etiquetas asignadas, de modo que el tráfico continúe reenviándose sin interrupciones. 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 auxiliar de reinicio correcto RSVP, lo que les permite ayudar a un enrutador que intenta reiniciar RSVP.

Un objeto denominado Restart 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 dejara de funcionar.

A continuación se enumeran los comportamientos de reinicio correcto de RSVP, que varían según la configuración y las características habilitadas:

  • Si deshabilita el modo auxiliar, Junos OS no intentará ayudar a un vecino a reiniciar su asistencia. Se omite cualquier información que llegue de un vecino con un objeto Restart Cap.

  • Cuando 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 tiempos de reinicio y recuperación (ninguno de los valores es 0).

  • Si deshabilita explícitamente el reinicio correcto RSVP en el nivel de [protocols rsvp] 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 enrutador en sí no conserva el estado de reenvío RSVP y no puede recuperar su estado de control.

  • Si después de un RSVP de reinicio 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 desactivados, el reinicio correcto de RSVP está completamente deshabilitado. El enrutador no reconoce ni anuncia los objetos de reinicio correcto RSVP.

No puede configurar explícitamente 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, aparte de un tiempo de espera fijo. Todos los procedimientos de reinicio correcto de RSVP se basan en el temporizador. Un show rsvp version comando puede indicar que el reinicio aún está en curso, incluso si se ha realizado una copia de seguridad de todas las sesiones RSVP y se restauran las rutas.

Procesamiento del objeto Cap de reinicio

Se hacen las siguientes suposiciones sobre un vecino basadas en el objeto Restart Cap (suponiendo que una falla del canal de control se puede distinguir inequívocamente 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 la 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 del tiempo 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 está ayudando a su vecino con los procedimientos de reinicio o recuperación, envía un objeto Recover Label a este vecino.

Configuración de RSVP Graceful Restart

Son posibles las siguientes configuraciones de reinicio correcto RSVP:

  • El reinicio elegante y el modo auxiliar están habilitados (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 a reiniciar.

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

Nota:

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

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

Habilitación de un 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 el 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 RSVP y el modo auxiliar RSVP están habilitados cuando se habilita el reinicio correcto. Sin embargo, puede deshabilitar una o ambas de estas capacidades.

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

Deshabilitar el modo auxiliar RSVP

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

Configuración del tiempo máximo de recuperación 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 auxiliar

Para configurar el retraso entre el momento en que el enrutador descubre que un enrutador vecino ha caído y el momento en que declara que el vecino está inactivo, incluya la maximum-helper-restart-time instrucción en el nivel de [edit protocols rsvp graceful-restart] 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 los túneles LSP de RSVP

Un túnel de ruta de conmutación de etiquetas (LSP) del Protocolo de reserva de recursos (RSVP) le permite enviar LSP de RSVP dentro de otros LSP de RSVP. Esto permite que un administrador de red proporcione ingeniería de tráfico de un extremo a otro de la red. Una aplicación útil para esta característica es conectar enrutadores perimetrales de cliente (CE) con enrutadores perimetrales de proveedor (PE) mediante un LSP RSVP y, a continuación, tunelizar 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 RSVP LSP agrega el concepto de una adyacencia de reenvío, similar a la que se usa para la conmutación de etiquetas multiprotocolo generalizada (GMPLS). (Para obtener más información acerca de GMPLS, consulte la Guía del usuario de Junos GMPLS.

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

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

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

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

  • Extensiones RSVP-TE: RSVP-TE fue diseñado para señalar la configuración de LSP de paquetes en interfaces físicas. El protocolo se ha extendido para solicitar la configuración de rutas para paquetes LSP que viajan a interfaces virtuales del mismo nivel definidas en una configuración LMP.

    Nota:

    A partir de Junos OS versión 15.1, la compatibilidad con varias instancias se amplía 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 TE independientes, lo que permite que cada dominio TE particionado escale de forma independiente. El RSVP-TE de varias instancias proporciona la flexibilidad para seleccionar manualmente las entidades del plano de control que deben tener en cuenta las instancias; por ejemplo, un enrutador puede participar en varias instancias de TE mientras se ejecuta una sola instancia de BGP.

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

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

    • Garantizar la preparación del plano de datos del LSP durante la reseñalización del LSP antes de que el tráfico atraviese el LSP con el mecanismo de autoping del LSP RSVP-TE.

      Un LSP no debe comenzar a transportar tráfico a menos que se sepa que ha sido programado en el plano de datos. El intercambio de datos en el plano de datos de LSP, como las solicitudes de ping de LSP, tiene lugar en el enrutador de entrada antes de cambiar el tráfico a un LSP o a su instancia de MBB. En redes grandes, este tráfico puede abrumar a un enrutador de salida de LSP, ya que el LSP de salida necesita responder a las solicitudes de ping de LSP. El mecanismo de autoping LSP permite que el LER de entrada cree mensajes de respuesta 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 vivacidad del plano de datos LSP. Esto garantiza que el LSP no comience a transportar tráfico antes de que se haya programado el plano de datos.

    • Eliminación del límite rígido actual de LSP de 64K en un enrutador de entrada y escalamiento del número total de LSP con LSP señalados RSVP-TE. Puede haber hasta 64 mil 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.

    • Evitar el desmontaje brusco de los LSP por parte del enrutador de entrada debido al retraso en la señalización del LSP en los enrutadores de tránsito.

    • Permite una vista flexible de los conjuntos de datos de 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 autoping.

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

  • No se admiten los LSP basados en conexión cruzada de circuitos (CCC).

  • No se admite el reinicio correcto.

  • La protección de vínculo 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 son compatibles con los FA-LSP.

Ejemplo: Configuración del túnel RSVP LSP

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 el FA-LSP fa_lsp_r1r4. La ruta de retorno está representada por el LSP e2e_lsp_r5r0 RSVP de extremo a extremo que viaja sobre el 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 un 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 del mismo nivel tanto en OSPF como en RSVP.

Cuando el LSP de extremo a extremo de la ruta de retorno 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 principal.

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 principal.

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 del mismo nivel tanto en OSPF como en 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 del LSP RSVP de extremo a extremo 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

Verificación de su trabajo

Para comprobar que el túnel RSVP LSP funciona correctamente, emita 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 atraviesa el vínculo de ingeniería de tráfico emitiendo el show link-management conjunto de comandos. También puede emitir el show rsvp session extensive comando para confirmar que el FA-LSP está operativo.

Configuración de interfaces del mismo nivel en OSPF y RSVP

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

El nombre de la interfaz del mismo nivel debe coincidir con la peer peer-name instrucción configurada en LMP en el nivel jerárquico [edit protocols link-management] . Dado que las interfaces del mismo nivel envían y reciben paquetes de protocolo reales, las interfaces del mismo nivel se pueden señalar y anunciar a los 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 nivel de [edit protocols ospf area area-number] jerarquía. Para configurar la señalización RSVP para pares LMP, incluya la peer-interface instrucción en el nivel de [edit protocols rsvp] jerarquía.

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

A continuación, defina su FA-LSP incluyendo la label-switched-path instrucción en el nivel jerárquico [edit protocols mpls] . Incluya el ID de 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 devolver desde el par.

Establecimiento de información de ruta de FA-LSP

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

Nota:

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

Opción: Derribar los RSVP LSP con gracia

Puede desactivar un LSP RSVP en un proceso de dos pasos que retira correctamente la sesión RSVP utilizada por el LSP. Para todos los vecinos que admiten el desmontaje correcto, la plataforma de enrutamiento envía una solicitud de desmontaje al extremo de destino para el LSP y todos los vecinos de RSVP en la ruta. La solicitud se incluye dentro del 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 RSVP. Si un vecino no admite el desmontaje correcto, la solicitud se maneja como un desmontaje de sesión estándar en lugar de uno elegante.

Para realizar un desmontaje correcto de una sesión RSVP, ejecute el clear rsvp session gracefully comando. Opcionalmente, puede especificar la dirección de origen y destino de la sesión RSVP, el identificador LSP del remitente RSVP y el identificador de túnel de la sesión RSVP. Para usar estos calificadores, incluya las connection-sourceopciones , connection-destination, lsp-idy tunnel-id cuando ejecute 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 desmontaje elegante antes de iniciar el desmontaje real incluyendo la graceful-deletion-timeout instrucción en el nivel de [edit protocols rsvp] jerarquía. El valor predeterminado del tiempo de espera de eliminación correcta 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 el tiempo de espera de eliminación correcta, ejecute el comando de show rsvp version modo operativo.

Tabla de historial de cambios

La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice Feature Explorer a fin de determinar si una función es compatible con la plataforma.

Liberación
Descripción
19.4R1
16.1
Sin embargo, a partir de Junos OS versión 16.1, cuando se agota el tiempo de espera de los mensajes de saludo RSVP, las sesiones de RSVP se desactivan.