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 del 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. Ésta es la configuración mínima de RSVP. Todas las demás instrucciones de configuración de RSVP son opcionales.

Estas instrucciones se pueden incluir en los siguientes niveles jerárquicos:

  • [edit protocols]

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

Para activar RSVP en todas las interfaces, all sustitúyala por interface-name la 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 de jerarquía:

  • [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 de la Junos el software RSVP es admitir la señalización dinámica dentro de rutas con conmutación de etiqueta (LSP). Cuando habilita tanto MPLS como RSVP en un enrutador, MPLS se convierte en un cliente de RSVP. No es necesaria ninguna configuración adicional para enlazar MPLS y RSVP.

Puede configurar MPLS para configurar rutas señalizadas mediante el uso de la label-switched-path instrucción en el [edit protocols mpls] nivel de la jerarquía. Cada LSP se traduce en una solicitud de RSVP para iniciar una sesión RSVP. Esta solicitud se transmite a través de la interfaz interna entre 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 por cada LSP. El origen de la sesión se encuentra en el enrutador local y se destina al destino del LSP.

Cuando se crea una sesión RSVP con éxito, el LSP se configura a lo largo de los paths creados por la sesión RSVP. Si la sesión de RSVP no tiene éxito, RSVP notifica a MPLS su estado. Es MPLS iniciar rutas de copia de seguridad o continuar reintentando la ruta de acceso inicial.

Para pasar información de señalización de conmutación de etiquetas, RSVP admite cuatro objetos adicionales: Label request objeto, Label Object, objeto Route explícito y objeto Route de registro. Para que un LSP se configure correctamente, todos los enrutadores que se encuentran en la ruta deben ser compatibles con MPLS, RSVP y los cuatro objetos. De los cuatro objetos, el objeto de ruta de registro no es obligatorio.

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

  • Habilite MPLS en todos los enrutadores que vayan a participar en la conmutación de etiquetas (esto es, en todos los enrutadores que puedan formar parte de una ruta de acceso de etiqueta).

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

  • Configure los enrutadores al principio del LSP.

Ejemplo Configuración de RSVP y MPLS

A continuación se muestra una configuración de ejemplo para un enrutador al inicio 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 Actualizar RSVP

Puede configurar la reducción de la 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 del RSVP: La agrupación de mensajes RSVP, el identificador de mensajes RSVP, la entrega de mensajes confiable y el Resumen de actualización.

    Para tener una reducción de actualización y una entrega confiable, debe incluir los aggregate Estados reliable de cuenta y.

  • 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 acerca de la reducción de la actualización de RSVP, consulte la reducción de actualizar RSVP.

Si la no-reliable instrucción se configura en el enrutador (se deshabilita la entrega de mensajes de forma confiable), el enrutador acepta mensajes RSVP que incluyan el objeto ID del mensaje, pero ignora el objeto ID del mensaje y sigue realizando un procesamiento estándar de los mensajes. En este caso, no se genera ningún error y RSVP funciona con normalidad.

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

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

Para habilitar todas las características de reducción de la actualización RSVP en una aggregate interfaz, incluya la siguiente instrucción:

Puede incluir esta instrucción en los siguientes niveles de jerarquía:

  • [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 no-aggregate conjunta, incluya la siguiente instrucción:

Puede incluir esta instrucción en los siguientes niveles de jerarquía:

  • [edit protocols rsvp interface interface-name]

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

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

Puede incluir esta instrucción en los siguientes niveles de jerarquía:

  • [edit protocols rsvp interface interface-name]

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

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

Puede incluir esta instrucción en los siguientes niveles de jerarquía:

  • [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 Actualizar de los vecinos de RSVP

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

  • El bit RR anunciado por el vecino

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

  • Los mensajes RSVP reales recibidos desde el vecino

Para obtener esta información, puede emitir un show rsvp neighbor detail comando. El resultado de ejemplo es el siguiente:

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

Configuración del intervalo de saludo de RSVP

RSVP supervisa el estado de los vecinos del Protocolo de puerta de enlace interior (IGP) (IS-IS o OSPF) y confía en los protocolos IGP para detectar cuándo se produce un error en un nodo. Si un protocolo de IGP declara un vecino hacia abajo (ya que no se reciben paquetes de saludo), RSVP también deja al otro vecino. Sin embargo, los IGP protocolos y RSVP siguen funcionando de manera independiente cuando se pone un vecino en la proximidad.

Para los enrutadores Juniper Networks, la configuración de un intervalo de saludo más corto o más largo no tiene ningún impacto sobre si se ha desactivado o no una sesión de RSVP. Las sesiones RSVP se mantienen, incluso si ya no se reciben los paquetes de saludo RSVP. Las sesiones RSVP se mantienen hasta que el enrutador deja de recibir IGP paquetes de saludo o la ruta de acceso RSVP y los mensajes RESV agotan el tiempo de espera. Sin embargo, a partir de Junos OS versión 16,1, cuando se agota el tiempo de espera de los mensajes de saludo de RSVP, se desactivan las sesiones RSVP.

El intervalo de saludo del RSVP también se podría ver afectado cuando el equipo de otro proveedor derriba una sesión de RSVP. Por ejemplo, un enrutador vecino que no sea de Juniper Networks podría configurarse para supervisar paquetes de saludo de RSVP.

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

Para obtener una lista de los niveles de jerarquía 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 del protocolo RSVP pueden autenticarse para garantizar que solo los vecinos de confianza participan en la configuración de reservas. De forma predeterminada, la autenticación RSVP está deshabilitada.

La autenticación RSVP utiliza un compendio basado en mensajes hash de código de autenticación de mensajes (HMAC) MD5. Este esquema produce una síntesis del mensaje basada 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 algoritmo implícito calculado se transmite con mensajes RSVP. Una vez configurada 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 la falsificación y la modificación de mensajes. También puede impedir ataques de reproducción. Sin embargo, no ofrece confidencialidad, ya que todos los mensajes se envían en texto no cifrado.

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

Puede incluir esta instrucción en los siguientes niveles de jerarquía:

  • [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, el RSVP permite el 100 por ciento del ancho de banda para un tipo de clase que se utilizará para reservas de RSVP. Cuando sobresuscribe un tipo de clase para un LSP de multiclase, se permite que la demanda total de todas las sesiones RSVP pueda superar la capacidad real del tipo de clase.

Para obtener instrucciones detalladas acerca de cómo configurar la suscripción de ancho de banda para los 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 (IGPs) mantienen la base de datos de ingeniería de tráfico, pero el ancho de banda disponible actualmente en los vínculos de la base de datos de ingeniería de tráfico procede de RSVP. Cuando cambia el ancho de banda de un vínculo, el RSVP informa a los IPV, los cuales 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. A continuación, los nodos de red saben la cantidad de ancho de banda disponible en el vínculo de la base de datos de ingeniería de tráfico (local o remota) y CSPF pueden calcular correctamente las rutas.

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

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

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

Si el valor umbral se configura en más del 20% del ancho de banda del enlace, el valor de umbral se limita al 20% del ancho de banda.

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

Nota:

Las dos opciones, umbral por ciento y , son threshold-value mutuamente exclusivas. Solo puede configurar una opción en un momento dado para generar una IGP actualización para reservas de ancho de banda inferiores. Como resultado, cuando se configura una opción, se calcula la otra opción 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 se calcula y se muestra threshold-value como 50 Mbps. De manera similar, si threshold-value el está configurado en 50m, entonces el umbral-porcentaje se calcula y se muestra como 5 %.

Para ajustar el umbral en el que un cambio en el ancho de banda reservado activa una IGP actualización, incluya la instrucción Update-Threshold . Debido al umbral de actualización, es posible que la ruta de acceso más corta primero restringida (CSPF) calcule una ruta usando información obsoleta de ancho de banda de la base de datos de ingeniería de tráfico en un vínculo. Si RSVP intenta establecer un LSP a través de esa ruta de acceso, es posible que no haya suficiente ancho de banda en ese vínculo. Cuando esto ocurre, 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 el path utilizando la información actualizada del ancho de banda 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 [edit logical-systems logical-system-name protocols mpls] el 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) con la información proporcionada por el Message. Consulte mejorar la precisión de la base de datos de ingeniería de tráfico con mensajesdel apartado del apartado de RSVP.

Configuración de RSVP para interfaces no numeradas

El Junos OS es compatible con la ingeniería de tráfico RSVP a través de interfaces no numeradas. La información de ingeniería de tráfico de vínculos no numerados se lleva en las extensiones de ingeniería de tráfico de IGP para OSPF y SI-SI según lo descrito en RFC 4203, extensiones de OSPF compatibles con conmutación de etiquetas de varios protocolos (GMPLS)y RFC 4205, Sistema intermedio a sistema intermedio (SI-SI) en compatibilidad con conmutación de etiquetas de varios protocolos (GMPLS)generalizada. Los vínculos no numerados también se pueden especificar en la señalización de ingeniería de tráfico MPLS tal como se describe en RFC 3477, Señalización de vínculos no numerados en el Protocolo de reeserción de recursos - Ingeniería de tráfico (RSVP-ING-T). Esta característica le permite evitar tener que configurar direcciones IP para cada interfaz que participa en la red señalizada con RSVP.

Para configurar RSVP para interfaces no numeradas, debe configurar el enrutador con un identificador de enrutador utilizando router-id la [edit routing-options] instrucción especificada en el nivel de la jerarquía. El identificador de enrutador debe estar disponible para enrutamiento (normalmente, puede utilizar la dirección de bucle de retroceso). Los mensajes de control de RSVP para los vínculos sin numerar se envían mediante la dirección de ID de enrutador (en lugar de una dirección seleccionada al azar).

Para configurar la protección de vínculos y la reenrutación rápida en un enrutador con interfaces no numeradas habilitadas, debe configurar al menos dos direcciones. Recomendamos que configure una interfaz secundaria en el bucle invertido, además de configurar el ID del enrutador.

Configuración de los saludo del ID del nodo RSVP

Puede configurar los saludos de RSVP basados en los IDENTIFICADOres de nodo para asegurarse de que Juniper Networks enrutadores puedan interoperar con el equipo de otros proveedores. De forma predeterminada, Junos OS utiliza los saludos de RSVP basados en la interfaz. Los saludos de 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 saludo del identificador de nodo RSVP son útiles si ha configurado BFD para detectar problemas con respecto a las interfaces RSVP, lo que le permite deshabilitar las saludos de la interfaz para estas interfaces. También puede utilizar los saludos del identificador de nodo para los procedimientos de reinicio correctos.

Los saludo del identificador de nodo se pueden habilitar globalmente para todos los vecinos RSVP. De forma predeterminada, se deshabilita la compatibilidad con el identificador de nodo de Hello. Si no ha habilitado los ID de nodo RSVP en el enrutador, el Junos OS no aceptará paquetes de saludo del ID del nodo.

Para activar los saludo del ID del nodo RSVP globalmente en el enrutador, incluya la instrucción node-Hello en los siguientes niveles de jerarquía:

  • [edit protocols rsvp]

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

También puede deshabilitar de forma explícita la interfaz RSVP Hello globalmente. Este tipo de configuración puede ser necesario en redes en las que el enrutador de Juniper Networks tiene varias conexiones RSVP con equipos de otros proveedores. Sin embargo, si desactiva la interfaz RSVP Hola a todos de forma global, también puede configurar un intervalo de saludo en una interfaz RSVP mediante la instrucción Hello-Interval . Esta configuración deshabilita la interfaz RSVP hellos globalmente, pero activa la interfaz RSVP Hola en la interfaz especificada (la interfaz RSVP en la hello-interval que configure la instrucción). Esta configuración podría ser necesaria en una red heterogénea en la que algunos dispositivos admitan los saludo de ID. de nodo RSVP y otros dispositivos admitan los saludo de la interfaz RSVP.

Para desactivar los saludo de la interfaz RSVP de forma global 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ñalizados con RSVP

Este ejemplo muestra cómo crear un LSP entre enrutadores en una red IP que utiliza RSVP como protocolo de señalización.

Aplicables

Antes de empezar, elimine los servicios de seguridad del dispositivo. Consulte ejemplo: Eliminando serviciosde seguridad.

Descripción general y topología

Si utiliza RSVP como protocolo de señalización, puede crear un LSP entre enrutadores en una red IP. En este ejemplo, puede configurar una red de ejemplo como se Figura 1muestra en la.

Topología

Figura 1: LSP de señal de RSVP típicoLSP de señal de RSVP típico

Para establecer un LSP entre enrutadores, debe activar individualmente el MPLS familia y configurar RSVP en cada una de las interfaces de tránsito de la red MPLS. En este ejemplo se muestra cómo activar MPLS y configurar RSVP en la interfaz de tránsito GE-0/0/0. Además, debe habilitar el MPLS proceso 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 de CSPF, lo que garantiza que los hosts C1 y C2 usen el LSP con señal de RSVP que corresponda a la ruta más corta de IGP de red.

Automática

Modalidades

Configuración rápida de CLI

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

Procedimiento paso a paso

El ejemplo siguiente requiere que se exploren varios niveles en la jerarquía de configuración. Para obtener más información sobre Cómo desplazarse por la CLI, consulte uso del editor de CLI en el 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. Active RSVP en cada interfaz de tránsito de la red MPLS.

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

  4. Defina el LSP en el enrutador de entrada.

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

Resultados

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

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

Si ha terminado de configurar el dispositivo, entre commit en el modo de configuración.

Comproba

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

Comprobar los vecinos de RSVP

Purpose

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

Intervención

Desde la CLI, escriba el show rsvp neighbor comando.

El resultado muestra las direcciones IP de los enrutadores vecinos. Compruebe que se muestra cada dirección de bucle de retroceso de RSVP de enrutador adyacente.

Verificación de las sesiones RSVP

Purpose

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

Intervención

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

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

  • Cada dirección de RSVP vecino tiene una entrada para cada vecino, ordenada por dirección de bucle de retroceso.

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

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

Verificación de la presencia de LSP señalizados con RSVP

Purpose

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

Intervención

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

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

Ejemplo Configuración de una malla automática de RSVP

Los proveedores de servicios utilizan a menudo BGP e MPLS VPN para escalar de manera eficiente la red mientras proporcionan servicios de generación de ingresos. En estos entornos, BGP se utiliza para distribuir la información de enrutamiento VPN a través de la red del proveedor de servicios, mientras MPLS se utiliza para reenviar ese tráfico VPN de un sitio VPN a otro.

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

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

Aplicables

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

  • Enrutador que se ejecuta Junos OS versión 10,1 o posterior.

  • Una BGP y MPLS VPN utilizando RSVP como el protocolo de señalización MPLS Label-conmutate Path (LSP).

Descripción general

En este ejemplo se muestra cómo configurar una malla automática de RSVP en un enrutador PE mediante la instrucción de rsvp-te configuración. Para que la malla automática de RSVP funcione correctamente, todos los enrutadores de PE del 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 beneficien de la característica de malla automática, siempre y cuando rsvp-te también estén configurados con la instrucción.

Dado este requisito, este ejemplo solo muestra la configuración del enrutador PE que se acaba de agregar. Se supone que RSVP Automatic Mesh ya se configuró en los enrutadores de 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á RSVP automático de la malla. 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 ilustración.

Figura 2: Red Operador de Telecomunicaciones con enrutadores PERed Operador de Telecomunicaciones con enrutadores PE

Automática

La configuración de la malla automática de RSVP implica llevar a cabo estas tareas:

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

  • Configurando destination-networks el elemento requerido.

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

  • Configurando label-switched-path-template el elemento requerido.

    Este elemento de configuración toma default-template o bien el nombre de una plantilla de LSP preconfigurada como un argumento. La default-template es 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, quite los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, a continuación, copie y [edit] pegue los comandos en la CLI en el nivel de jerarquía.

Enrutador PE4

Configuración de una malla automática de RSVP

Procedimiento paso a paso

El ejemplo siguiente requiere que se exploren 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 activar la malla automática de RSVP:

  1. Configure rsvp-te en [edit routing-options dynamic-tunnels] el nivel de jerarquía.

  2. Configure destination-networks en [edit routing-options dynamic-tunnels] el nivel de jerarquía.

Resultados

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

Comproba

Verificación de la existencia de túneles automáticos de mallas de RSVP en enrutadores PE4

Purpose

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

Intervención

Verificación de la existencia de MPLS LSP en enrutadores PE4

Purpose

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

Intervención

Configuración de confirmaciones de saludo para los vecinos RSVP que no son de sesión

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

Se descartan los mensajes de saludo recibidos de los vecinos RSVP que no forman parte de una sesión común de RSVP. Si configura la hello-acknowledgements instrucción en el nivel [edit protocols rsvp] de la jerarquía, los mensajes de saludo de los vecinos sin sesión se confirmarán con un mensaje de confirmación de saludo. Cuando se reciben los mensajes de los vecinos que no son de sesión, se crea una relación de RSVP Neighbor y es posible que se reciban a partir de ese vecino que no sea de sesión. La hello-acknowledgements instrucción está deshabilitada de forma predeterminada. La configuración de esta instrucción permite detectar enrutadores compatibles con RSVP mediante paquetes de saludo y verifica que la interfaz pueda recibir paquetes RSVP antes de enviar cualquier mensaje de instalación del MPLS LSP.

Una vez que haya habilitado las confirmaciones de saludo para los vecinos que no son de sesión, el enrutador continúa acusar mensajes de saludo de cualquier vecino sin sesión de RSVP a menos que la propia interfaz falle o cambie la configuración. Los vecinos basados en interfaz no se agotan automáticamente.

Puede incluir esta instrucción en los siguientes niveles de jerarquía:

  • [edit protocols rsvp]

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

Cómo cambiar LSP de un nodo de red

Puede configurar el enrutador para que cambie de LSP activos de un nodo de red mediante un LSP de derivación habilitado para una interfaz. Esta característica puede usarse para mantener las redes activas cuando es necesario reemplazar un dispositivo sin interrumpir el tráfico en tránsito de la red. Los LSP pueden ser estáticos o dinámicos.

  1. Primero debe configurar la protección de nodo o vínculo para el tráfico que necesita pasar por el dispositivo de red que desea deshabilitar. Para funcionar correctamente, el LSP de derivación debe usar una interfaz lógica diferente a la del LSP protegido.
  2. Para preparar el enrutador con el fin de empezar a cambiar el tráfico lejos always-mark-connection-protection-tlv de un nodo de red, configure la instrucción:

    A continuación, el enrutador marca todo el tráfico mantenimiento seguros que atraviesa esta interfaz como preparación para cambiar el tráfico a una ruta alternativa basada en la funcionalidad mantenimiento seguros.

    Puede configurar esta instrucción en los siguientes niveles de jerarquía:

    • [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 de manera eficaz el dispositivo de red predeterminado downstream. Esta configuración no deja que se interrumpa el propio vínculo actual.

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

    Puede configurar esta instrucción en los siguientes niveles de jerarquía:

    • [edit protocols mpls interface interface-name]

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

Tenga en cuenta las limitaciones siguientes relacionadas con el cambio de LSP activos de un nodo de red:

  • La característica de conmutación solo se admite en enrutadores de la serie MX.

  • La función de conmutación no es compatible para el tráfico de conmutación de los LSP de punto a multipunto principales para eludir los 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 conmuta al LSP de punto a multipunto de bypass.

  • Si configura la función de ubicación de ubicador 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 ubicación impide que se produzca el comportamiento de "antes de interrumpir" de los LSP señalizados con RSVP. El comportamiento de hacer antes de interrumpir normalmente hace que el enrutador intente primero volver a señalizar un LSP dinámico antes de anular el original.

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

Puede configurar el mecanismo de redireccionamiento de instalaciones-copia de seguridad rápidamente para proporcionar protección de configuración a los LSP que se encuentran en proceso de señalización. Se admiten los LSP de punto a punto y los LSP de punto a multipunto. Esta característica se aplica en la siguiente situación de ejemplo:

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

  2. También existe un LSP de derivación que protege el vínculo o el nodo.

  3. RSVP señala al LSP a través de un LSP de derivación. Parece que el LSP se configuró originalmente junto con su ruta de acceso principal y luego la conmutación por error al LSP de derivación debido al fallo en el nodo o en el vínculo.

  4. Cuando se recupera el enlace o nodo, el LSP puede revertir automáticamente a la ruta principal.

Debe configurar la setup-protection instrucción en cada uno [edit protocols rsvp] de los enrutadores de la ruta de acceso de LSP en la que desea activar 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 de LSP. Puede emitir un show rsvp session comando para determinar si el LSP ha habilitado o no la protección de configuración en un enrutador que actúa como punto de reparación local (PLR) o de un punto de combinación.

Para activar la protección de la instalación de setup-protection RSVP, incluya la instrucción

Puede incluir esta instrucción en los siguientes niveles de jerarquía:

  • [edit protocols rsvp]

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

Configuración del equilibrio de carga en LSP de RSVP

De forma predeterminada, cuando se han configurado varios LSP de 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 proveedores de idiomas tienen la misma métrica, uno de los LSP se selecciona aleatoriamente y todo el tráfico se envía a través de él.

De manera alternativa, puede equilibrar la carga de tráfico en todos los LSP si habilita el equilibrio de carga por paquete.

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

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

Una vez aplicado el equilibrio de carga por paquetes, el tráfico se distribuye equitativamente entre los LSP (de forma predeterminada).

Debe configurar el equilibrio de carga por paquete si desea habilitar PFE reenrutamiento rápido de la misma. Para activar la reenrutamiento rápido de PFE policy-statement , incluya la instrucción del 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 una reruta. Consulte también configurar la reenrutación rápida.

También puede equilibrar la carga de tráfico entre los LSP de forma proporcional a la cantidad de ancho de banda configurada 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 refleja normalmente la capacidad de tráfico de ese LSP.

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

Puede configurar esta instrucción en los siguientes niveles de jerarquía:

  • [edit protocols rsvp]

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

Al utilizar la load-balance instrucción, tenga en cuenta la siguiente información:

  • Si configura la load-balance instrucción, el comportamiento de los LSP actualmente en ejecución no se alterará. Para forzar que el LSP que se esté ejecutando utilice el nuevo comportamiento, clear mpls lsp puede emitir un 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 de ingeniería de tráfico compatibles con los 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 una malla automática de RSVP

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

Nota:

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

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

Estas instrucciones pueden configurarse en los siguientes niveles de jerarquía:

  • [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 de 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 del prefijo IPv4 especificado.

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

Configuración de temporizadores para mensajes de Actualizar 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 consecutivos. El valor predeterminado para el tiempo de actualización es de 45 segundos. Este número se deriva del valor predeterminado de la instrucción de 30, multiplicado por un valor fijo refresh-time de 1,5. Este cálculo difiere del RFC 2205, el cual establece que el tiempo de actualización se debe multiplicar por un valor aleatorio en el intervalo del 0,5 al 1,5.

    Actualizar mensajes incluyen los mensajes de ruta y RESV. Actualizar mensajes se envían periódicamente para que no se supere el tiempo de espera de los Estados de reserva en los nodos vecinos. Cada uno de los mensajes path y RESV incluye el valor de temporizador de actualización, y el nodo receptor 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 el número de mensajes que se pueden perder antes de que un determinado Estado se declare obsoleto y debe eliminarse. El multiplicador de Keep 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, ( – 1) los mensajes de actualización consecutivos se deben perder antes de keep-multiplier eliminar un estado de reserva.

No se recomienda configurar un breve temporizador de saludo de RSVP. Si es necesario el descubrimiento rápido de un vecino con errores, configure los temporizadores Short IGP (OSPF o IS 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 de jerarquía:

  • [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 de jerarquía:

  • [edit protocols rsvp]

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

Adelantamiento de las sesiones RSVP

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

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

Puede incluir esta instrucción en los siguientes niveles de jerarquía:

  • [edit protocols rsvp]

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

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

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

Puede incluir esta instrucción en los siguientes niveles de jerarquía:

  • [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 unidad máxima de transmisión (MTU) en RSVP, debe configurar MPLS de permitir que los paquetes IP se fragmenten antes de que se encapsulen en MPLS. También debe configurar la señalización de MTU en RSVP. Con fines de solución de problemas, puede configurar la señalización de MTU únicamente sin activar la fragmentación de paquetes.

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

Puede incluir esta instrucción en los siguientes niveles de jerarquía:

  • [edit protocols mpls]

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

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

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

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

Puede incluir esta instrucción en los siguientes niveles de jerarquía:

  • [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 surten efecto la siguiente vez que se actualiza la ruta de acceso.

Puede configurar la mtu-signaling instrucción por sí sola 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 MTU recibido y enviado en el objeto Adspec.

Habilitar la fragmentación de paquetes

Para permitir la fragmentación de paquetes IP antes de encapsularlos en MPLS, incluya la allow-fragmentation instrucción:

Puede incluir esta instrucción en los siguientes niveles de jerarquía:

  • [edit protocols mpls path-mtu]

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

    Nota:

    No configure la allow-fragmentation instrucción de forma independiente. Configúrelo siempre junto con la mtu-signaling instrucción.

Configuración del complemento de saltos finales para LSPs

De forma predeterminada, los LSP señalizados con RSVP utilizan un comando de reactivación de penúltimo salto (php). Figura 3 ilustra un segmento de LSP de un penúltimo salto entre PE1 de enrutadores y PE2 de enrutador. El enrutador CE1 reenvía un paquete al siguiente salto (enrutador PE1), que también es la entrada del 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, cambiando la etiqueta 1 por 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 de enrutador PE2, primero extrae la etiqueta y, a continuación, reenvía el paquete al enrutador PE2. Cuando la PE2 de enrutador la recibe, el paquete puede tener una etiqueta de servicio, una etiqueta explícitamente nula o simplemente un paquete de IP o de VPLS. Enrutador PE2 reenvía el paquete sin etiqueta al CE2 enrutador.

Figura 3: La desaparecieron en un LSP con un penúltimo saltoLa desaparecieron en un LSP con un penúltimo salto

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

Figura 4: La expropiación del salto final para un LSPLa expropiación del salto final para un LSP

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

  • MPLS-TP para monitoreo de la performance y mantenimiento seguros dentro de banda

  • Circuitos virtuales de protección de borde

Las siguientes características no admiten el comportamiento de UHP:

  • LSP señalizados con LDP

  • LSP estáticos

  • LSP de punto a multipunto

  • traceroutemando

Para obtener más información sobre el comportamiento de la 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 RSVP-ING-T LSP.

Para los LSP señalizados punto a punto de RSVP, el comportamiento de UHP se señaliza a partir de la entrada del LSP. En función de la configuración del enrutador de entrada, RSVP puede señalizar al LSP con el conjunto de marcas no PHP. Los mensajes de ruta RSVP contienen los dos indicadores en el objeto LSP: atributos. 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 o no la parte inferior de la pila de rótulos.

  • Ruta S=0: indica que hay más etiquetas en la pila. El siguiente salto de este enrutamiento apunta a MPLS. 0 tabla de enrutamiento, que activa una búsqueda encadenada de MPLS de etiquetas para descubrir el resto de las etiquetas de MPLS 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 varias familias. De manera alternativa, la ruta de etiqueta puede apuntar a una interfaz de VT para iniciar el reenvío de IP.

Si habilita, MPLS aplicaciones como las VPN de capa 3, VPLS, VPN de capa 2 y los circuitos de capa 2 pueden usar el LSP de UHP. A continuación, se explica cómo los LSP de UHP afectan a los distintos tipos de aplicaciones de 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 exterior (S = 0) es la etiqueta UHP y la etiqueta interior (S = 1) es la etiqueta del VC . Una búsqueda basada en la etiqueta de transporte da como resultado un identificador de tabla para MPLS. 0 tabla de enrutamiento. Hay una ruta adicional en la tabla de enrutamiento MPLS. 0 que corresponde a la etiqueta interna. Una búsqueda basada en la etiqueta interna da como resultado el siguiente salto del enrutador de 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 tabla de la tabla de enrutamiento MPLS. 0. Existen dos casos en este escenario. De forma predeterminada, las VPN de capa 3 anuncian la etiqueta del salto por siguiente. Una búsqueda basada en la etiqueta interna da lugar al siguiente salto hacia el enrutador de CE. Sin embargo, si ha configurado la vrf-table-label instrucción para la instancia de enrutamiento VPN de capa 3, la etiqueta interna de LSI apunta a la tabla de enrutamiento VRF. También se ha completado una búsqueda de IP para la tabla de enrutamiento VRF.

    Nota:

    UHP para las VPN de capa 3 configuradas con la instrucción sólo se admite en las vrf-table-label 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 tabla de la tabla de enrutamiento MPLS. 0. Una búsqueda basada en la etiqueta interna en MPLS. 0 tabla de enrutamiento da como resultado la interfaz de túnel LSI de la instancia de enrutamiento VPLS si no se configura el Tunnel-Services (o una interfaz VT no disponible). Los enrutadores MX serie 3D admiten búsqueda encadenada y búsqueda de varias familias.

    Nota:

    Solo se admite UHP para VPLS no-tunnel-service configurado con la instrucción en enrutadores mx series.

  • 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. Se completa otra búsqueda de IP en la interfaz de VT para determinar a dónde debe reenviar el paquete. Si la plataforma de enrutamiento admite búsquedas encadenadas y varias familias (por ejemplo, enrutadores de 3D MX 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 a través de MPLS: para túneles 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 explicit null para IPv6. Como resultado, los siguientes saltos de reenvío para rutas de IPv6 que se aprenden de enrutadores de PE remotos normalmente presionan dos etiquetas. La etiqueta interna es 2 (podría ser diferente si el enrutador de Advertising PE proviene de otro proveedor) y la etiqueta del enrutador es la etiqueta de LSP. Los paquetes llegan al enrutador de PE (salida del LSP de UHP) con dos etiquetas. La etiqueta externa es la etiqueta de transporte (S = 0), mientras que la etiqueta interna es la etiqueta nula explícita IPv6 (etiqueta 2). Búsqueda basada en la etiqueta interna de la tabla de enrutamiento MPLS. 0 redirecciona de vuelta a la tabla de enrutamiento MPLS. 0. En los enrutadores MX serie 3D, se quita la etiqueta interna (etiqueta 2) y se realiza una búsqueda IPv6 a través de la tabla de enrutamiento inet 6.0.

  • Habilitar tanto PHP como LSP UHP: puede configurar los LSP PHP y UHP a través de las mismas rutas de red. Puede separar el tráfico de PHP y UHP si selecciona reenviar próximos saltos de LSP utilizando una expresión install-nexthop regular con la instrucción. También puede separar el tráfico si simplemente denomina los LSP adecuadamente.

Las siguientes instrucciones permiten una expropiación del salto de última fin para un LSP. Puede habilitar esta característica en un LSP específico o en todos los proveedores de idiomas de entrada configurados en el enrutador. Configure estas sentencias en el enrutador en la entrada del LSP.

  1. Para activar la expropiación del salto final, ultimate-hop-popping incluya la siguiente instrucción:

    Incluya esta declaración en el [edit protocols mpls label-switched-path label-switched-path-name] nivel de jerarquía para posibilitar la expulsación de último salto en un LSP específico. Incluya esta instrucción en el [edit protocols mpls] nivel jerárquico para permitir la exgresión de saltos de última inclusión en todos los LSP de entrada configurados en el enrutador. También puede configurar el ultimate-hop-popping enunciado bajo los niveles [edit logical-routers] jerárquicos equivalentes.

    Nota:

    Cuando se habilita la extrusión de último salto, RSVP intenta reasignar LSP existentes como LSP de última hora en el modo de creación, antes de interrumpir. Si un enrutador de salida no admite el salto final, el LSP existente se derriba (el RSVP envía un mensaje PathTear a lo largo de la ruta de un LSP, lo que elimina el estado de la ruta y el estado de reserva dependiente y libera los recursos de red asociados).

    Si deshabilita la extrusión de último salto, RSVP realiza el reenvío de LSP existentes como LSPs de un penúltimo salto, en un modo de inicio antes de interrumpir.

  2. Si quieres activar los próximos saltos encadenados y de salto único solo en los enrutadores MX series, también tienes que configurar la enhanced-ip opción para la network-services instrucción:

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

Configuración de RSVP para que abra 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 etiqueta 3 (etiqueta nula implícita). Si se anuncia la etiqueta 3, el enrutador de penúltimo salto quitará la etiqueta y enviará el paquete al enrutador de salida. Cuando se habilita el salto definitivo, se anuncia la etiqueta 0 (etiqueta IP versión 4 [IPv4] Explicit Null). El emergemiento de saltos de última fin garantiza que cualquier paquete que atraviese una red MPLS incluirá una etiqueta.

Nota:

Juniper Networks enrutadores envían paquetes en cola en función de la etiqueta entrante. Los enrutadores de otros proveedores pueden poner en cola los paquetes de manera diferente. Tenga esto en cuenta cuando trabaje con redes que contengan enrutadores de varios proveedores.

Para configurar la expropiación de saltos finales para RSVP explicit-null , incluya la siguiente instrucción:

Puede incluir esta instrucción en los siguientes niveles de jerarquía:

  • [edit protocols mpls]

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

Cómo permitir el salto de última fin en LSP de punto a multipunto

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

Puede ser beneficioso permitir un salto de última hora en LSP de punto a multipunto, especialmente cuando el tráfico de tránsito atraviesa el mismo dispositivo de salida. Si habilita la expropiación del salto final, puede enviarse una sola copia del tráfico a través del vínculo entrante, lo que ahorra un ancho de banda significativo. De forma predeterminada, la expropiación del salto final está deshabilitada.

Puede habilitar la exclamación de saltos de última fin para LSP de punto a tunnel-services multipunto si configura la instrucción. Cuando se habilita la expropiación del salto final, el Junos OS selecciona una de las interfaces de túnel de bucle virtual (VT) disponibles para volver a recorrer los paquetes PFE para el reenvío IP. De forma predeterminada, el proceso de selección de interfaz VT se realiza de forma automática. El control de admisión del ancho de banda se utiliza para limitar el número de proveedores de idiomas que pueden utilizarse en una interfaz de VT. Una vez que se consume todo el ancho de banda en una interfaz, el Junos OS selecciona otra interfaz de VT con suficiente ancho de banda para el control de admisión.

Si un LSP requiere más ancho de banda del disponible en cualquiera de las interfaces VT, la expropiación de salto final no se podrá activar y en su lugar se habilitará la expropiaización del penúltimo salto.

Para que un LSP de punto a multipunto pueda funcionar de manera óptima, el enrutador de salida debe tener un PIC que proporcione servicios de túnel, tales como PIC Services o el PIC de los servicios adaptables. Los servicios de túnel son necesarios para extraer la etiqueta de MPLS final y para devolver los paquetes para las búsquedas de direcciones IP.

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

Para permitir la exposición de último salto para el LSP de punto a multipunto de salida en un enrutador, tunnel-services configure la instrucción:

Puede configurar esta instrucción en los siguientes niveles de jerarquía:

  • [edit protocols rsvp]

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

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

Esta instrucción debe configurarse en [edit protocols rsvp] el nivel de jerarquía.

Seguimiento del tráfico de protocolo RSVP

Para realizar el seguimiento del tráfico de protocolo traceoptions RSVP, incluya la siguiente instrucción:

Puede incluir esta instrucción en los siguientes niveles de jerarquía:

  • [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 /var/logen el directorio. Recomendamos que coloque el resultado de seguimiento RSVP en el rsvp-log archivo.

  • all: todas las operaciones de rastreo.

  • error: todas las condiciones de error detectadas

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

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

  • packets: todos los paquetes RSVP

  • path: todos los mensajes de ruta

  • pathtear—PathTear messages (Mensajes de PathTear)

  • resv: mensajes de resv

  • resvtear— Mensajes resvTear

  • route: Información de enrutamiento

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

Nota:

Utilice el all indicador de traza y detail el modificador de indicador con precaución, ya que podrían hacer que la CPU esté muy ocupada.

Para ver el archivo de registro generado cuando se habilita RSVP TraceOptions, ejecute show log file-name el comando, file-name donde es el archivo que especificó traceoptions utilizando la instrucción.

Para obtener información general acerca de las opciones de seguimiento y seguimiento global, consulte la biblioteca de Junos OS de protocolos de enrutamientopara dispositivos de enrutamiento .

Cita Seguimiento del tráfico de protocolo RSVP

Rastrear detalladamente los mensajes de ruta RSVP:

Rastrear todos los mensajes RSVP:

Realizar un seguimiento de todas las condiciones de error RSVP:

Seguimiento de las transiciones de estado RSVP:

Salida del archivo de registro de RSVP

El siguiente es un resultado de ejemplo generado mediante la show log file-name emisión del comando en un enrutador en el que se han state habilitado RSVP TraceOptions con la marca configurada. La E-D del LSP señalado con RSVP se ha visto interrumpida el 11 14 de marzo: 04:36.707092. El 11 de marzo 14:05:30.101492, se muestra la próxima vez que lo volvió a hacer.

Reinicio correcto de RSVP

El reinicio correcto de RSVP permite que un enrutador se esté reiniciando para informar a sus vecinos adyacentes de su condición. El enrutador que se está reiniciando solicita un periodo de gracia a un vecino o un interlocutor que, a su vez, puede cooperar con el enrutador que reinicia. El enrutador de reinicio puede seguir reenviando MPLS tráfico durante el periodo de reinicio; la convergencia en la red no se interrumpe. El reinicio no está visible para el resto de la red y el enrutador que se está reiniciando no se quita de la topología de red. El reinicio correcto de RSVP puede habilitarse tanto en enrutadores de tránsito como enrutadores de entrada. Está disponible para proveedores de proveedores de punto a punto y LSP de punto a multipunto.

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

Terminología de reinicio correcto de RSVP

Tiempo de reinicio (en milisegundos)

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

El Junos OS anular el tiempo de reinicio anunciado de un vecino si la hora es mayor que un tercio de la hora de reinicio local. Por ejemplo, dado el tiempo predeterminado de reinicio 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 que se está reiniciando puede declararse inmediatamente como inactivo.

Tiempo de recuperación (en milisegundos)

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

Cuando se está realizando un reinicio normal, 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 que se reinicia intenta recuperar sus Estados perdidos con ayuda de sus vecinos. El vecino del nodo que va a reiniciar debe enviar los mensajes path con las etiquetas de recuperación al nodo que se va a reiniciar en un periodo de mitad del tiempo de recuperación. El nodo que se está reiniciando considera que el reinicio correcto se ha completado tras su tiempo de recuperación anunciado.

Operación de reinicio correcto RSVP

Para que funcione el reinicio correcto de RSVP, la característica debe estar habilitada en la instancia de enrutamiento global. El reinicio correcto de RSVP puede deshabilitarse en el nivel de protocolo (sólo para RSVP) o en el nivel global para todos los protocolos.

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

  • En el caso del enrutador que vuelve a iniciarse, RSVP correcto reinicio intenta mantener las rutas instaladas por RSVP y por las etiquetas asignadas, de modo que el tráfico se sigue reenviando sin interrupciones. El reinicio correcto de RSVP se realiza con la suficiente rapidez como para reducir o eliminar el impacto sobre los nodos vecinos.

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

Un objeto llamado Tapa de reinicio 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 que se está reiniciando para recuperar su estado de reenvío. Este objeto es esencialmente la etiqueta antigua que el nodo de reinicio anunció antes de que se desactivara el nodo.

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

  • Si deshabilita el modo de aplicación auxiliar, el Junos OS no intenta ayudar a reiniciarse a través de RSVP. Cualquier información que llegue con un objeto del Cap de reinicio de un vecino se pasará por alto.

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

  • Si deshabilita explícitamente el reinicio correcto de [protocols rsvp] RSVP bajo el nivel de jerarquía, el objeto de extremo de reinicio se anuncia con el reinicio y los tiempos de recuperación especificados como 0. El reinicio de los enrutadores vecinos se admite (a menos que el modo de aplicación 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 reiniciar RSVP se da cuenta de que no se ha conservado ningún estado de reenvío, el objeto de la Cap de reinicio se anuncia con el reinicio y los tiempos de recuperación especificados como 0.

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

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

A diferencia de otros protocolos, RSVP no permite determinar que ha finalizado un procedimiento de reinicio distinto de un tiempo de espera fijo. Todos los procedimientos de reinicio correctos de RSVP se basan en temporizador. Un show rsvp version comando podría indicar que el reinicio sigue en curso aunque se realicen copias de seguridad de todas las sesiones RSVP y se restauren las rutas.

Procesando el objeto de Cap de reinicio

Los siguientes supuestos se suponen sobre un vecino basado en el objeto del Cap de reinicio (suponiendo que un fallo del canal de control se pueda distinguir sin ambigüedad de un reinicio de nodo):

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

  • Después de un reinicio, un vecino anunciando un objeto de extremo de reinicio con una hora de reinicio igual a cualquier valor y un tiempo de recuperación igual a 0 no preserva 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 depura, independientemente del valor de la hora de reinicio.

  • Después de un reinicio, un vecino que anuncie su hora de recuperación con un valor distinto de 0 puede mantener o conservar el estado de reenvío. Si el enrutador local ayuda a su vecino con los procedimientos de reinicio o recuperación, envía un objeto recuperar etiqueta a este vecino.

Configurando reinicio correcto de RSVP

Son posibles las siguientes configuraciones de reinicio correcto de RSVP:

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

  • El reinicio correcto está habilitado pero el modo de ayuda está deshabilitado. Un enrutador configurado de este modo 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 de ayuda está habilitado. Un enrutador configurado de esta manera no puede reiniciarse correctamente, pero puede ayudar a reiniciar el vecino.

  • El reinicio correcto y el modo de ayuda están deshabilitados. Esta configuración deshabilita completamente 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 el reinicio correcto de RSVP.

Nota:

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

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

Habilitar el reinicio normal para todos los protocolos de enrutamiento

Para habilitar el reinicio normal de RSVP, debe activar el reinicio normal de todos los protocolos que admitan el reinicio normal en el enrutador. Para obtener más información sobre el reinicio correcto, consulte la biblioteca de Junos OS de protocolos de enrutamiento para dispositivos de enrutamiento.

Para activar el reinicio normal en el enrutador, incluya la graceful-restart siguiente instrucción:

Puede incluir esta instrucción en los siguientes niveles de jerarquía:

  • [edit routing-options]

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

Deshabilitando el reinicio correcto para RSVP

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

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

Deshabilitando el modo de aplicación auxiliar de RSVP

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

Configurar el tiempo máximo de recuperación de la ayuda

Para configurar la cantidad de tiempo durante la que el enrutador retiene el estado de sus vecinos RSVP mientras se reinician correctamente, incluya la maximum-helper-recovery-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 que necesita el vecino RSVP más lento para recuperarse.

Configurar el tiempo máximo de reinicio de la ayuda

Para configurar el retraso entre el momento en el que el enrutador descubre que un enrutador vecino ha dejado de funcionar y cuándo declara el maximum-helper-restart-time vecino hacia abajo [edit protocols rsvp graceful-restart] , incluya la instrucción en el nivel jerárquico. Este valor se aplica a todos los enrutadores vecinos, por lo que debe estar basado en el tiempo que necesita el vecino RSVP más lento para reiniciarse.

Introducción a los túneles de LSP de RSVP

Un túnel de etiqueta de protocolo de reserva de recursos (de RSVP) para la ruta de acceso conmutada (LSP) le permite enviar LSP de RSVP dentro de otros LSP de RSVP. Esto permite a un administrador de red proporcionar ingeniería de tráfico de un extremo de la red al otro. Una aplicación útil para esta característica consiste en conectar enrutadores perimetrales del cliente (CE) con enrutadores perimetrales de proveedor (PE) mediante un LSP de RSVP y, a continuación, canalizar el LSP de este perímetro dentro de un segundo LSP que viajan por el núcleo de la red.

Debe tener conocimientos generales sobre MPLS y conceptos de conmutación de etiquetas. Para obtener más información acerca de MPLS, consulte la Guía de configuración de aplicaciones MPLS Junos.

Un túnel LSP de RSVP agrega el concepto de una adyacencia de reenvío, similar al usado para el conmutación de etiquetas multiprotocolo generalizado (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 de acceso de túnel para enviar datos entre dispositivos del mismo nivel en una red de LSP de RSVP. Una vez que se ha establecido un LSP de reenvío (FA-LSP), se pueden enviar otros LSP a través del LSP de AF con la ruta más corta primero (CSPF), el protocolo de administración de vínculos (LMP), el Primera trayectoria abierta más corta (Open Shortest Path First) (OSPF) y RSVP.

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

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

  • OSPF de red: 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 ampliado para enrutar paquetes a interfaces del mismo nivel virtual definidas en una configuración de LMP.

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

    Nota:

    A partir de Junos OS versión 15,1, la compatibilidad de 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 independientes de TE de la TI, lo que permite escalar cada dominio de TE particionado de forma independiente. Multi-Instance RSVP-TE proporciona flexibilidad a mano elegir las entidades de plano de control que deben tener en cuenta las instancias, por ejemplo, un enrutador puede participar en varias instancias de TE mientras se sigue ejecutando una sola instancia de BGP.

    La implementación Junos OS de MPLS RSVP-TE se amplía para mejorar la facilidad de uso, la visibilidad, la configuración y la solución de problemas de LSP en la versión 16,1 de Junos OS.

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

    • Garantizar la preparación del plano de datos del LSP durante la Reseñalización del LSP antes de que el tráfico recorra al LSP con el mecanismo de ping automático RSVP-TE LSP.

      Un LSP no debe empezar a transportar tráfico a menos que se sepa que se ha programado en el plano de datos. El intercambio de datos en el plano de datos del 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 MBB. En redes de gran tamaño, este tráfico puede saturar un enrutador de salida de LSP, ya que el LSP de salida debe responder a las solicitudes de ping de LSP. El mecanismo de auto-ping de LSP permite que los LER de entrada creen mensajes de respuesta de ping LSP y los envíen a través del avión de datos del LSP. Al recibir estos mensajes, la salida LER los reenvía a la entrada, indicando el liveliness del plano de datos del LSP. Esto garantiza que el LSP no comience a transportar tráfico antes de que se haya programado el plano de datos.

    • Quitando el límite de hardware actual de 64K LSP en un enrutador de entrada y escalar el número total de LSP con LSP señalizados de RSVP-TE. Puede haber hasta 64 KB de LSP configurados para cada salida. Anteriormente, este límite era el número agregado de proveedores de idiomas que podían configurarse en el LER de entrada.

    • Impedir que el enrutador de entrada recorte abruptamente los LSP debido a un retraso en la señalización del LSP en los enrutadores de tránsito.

    • Habilitación de una vista flexible de conjuntos de datos de LSP para facilitar la visualización de datos característico de LSP.

    Nota:

    A partir de Junos OS versión 17,4, se introduce un cronómetro predeterminado de 1800 segundos para el ping automático.

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

  • No se admiten LSP con conexión cruzada de circuito (CCC).

  • No se admite el reinicio correcto.

  • La protección de enlaces no está disponible para los proveedores de inactivos de AF ni en el punto de salida de la adyacencia de reenvío.

  • No se admiten LSP de punto a multipunto en todos los proveedores de LSP de FA.

Ejemplo Configuración de túnel de LSP de RSVP

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

Figura 5muestra un RSVP LSP de extremo a extremo llamado que se origina en el enrutador 0 y e2e_lsp_r0r5 termina en el enrutador 5. En tránsito, este LSP atraviesa la FA-LSP. fa_lsp_r1r4 La ruta de devolución está representada por el LSP e2e_lsp_r5r0 de extremo a extremo que se transmite sobre el 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 de LMP que viaja del enrutador 1 al 4.

Enrutador 0

En el enrutador 1, configure un FA-LSP para comunicarse con el 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 tanto en OSPF como en el 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 el tráfico al enrutador 0. Asegúrese de configurar las 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 transporten el LSP-FA en toda 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 tanto en OSPF como en el 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 el tráfico al enrutador 5. Asegúrese de configurar las OSPF correctamente entre el enrutador 4 y el 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 1.

Enrutador 5

Verificación de su trabajo

Para comprobar que el túnel de LSP de RSVP 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 que se utilizan con el ejemplo de configuración, consulte las secciones siguientes:

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 ( ) y 4 ( ) que hacen referencia a las direcciones de vínculo de ingeniería de tráfico 10.255.41.21610.255.41.217 LMP de 172.16.30.1 y 172.16.30.2 . También puede ejecutar el comando para buscar la ruta del LSP de extremo a extremo mientras viaja al enrutador 5 a través del show rsvp session extensive FA-LSP.

Enrutador 1

En el enrutador 1, compruebe que la configuración de 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 conjunto de show link-management comandos. También puede emitir el show rsvp session extensive comando para confirmar que FA-LSP está operativo.

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

Después de establecer el establecimiento de los punto de conexión de sistemas LMP, debe agregar interfaces del mismo nivel a OSPF y RSVP. Una interfaz del mismo nivel es una interfaz virtual utilizada para admitir la adyacencia del control entre dos elementos del mismo nivel.

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

Definición de rutas de conmutación de etiqueta para FA-LSP

A continuación, defina el LSP-FA incluyendo el label-switched-path extracto en el [edit protocols mpls] nivel de la jerarquía. Incluye el identificador del enrutador del elemento to homólogo en la [edit protocols mpls label-switched-path] instrucción en el nivel jerárquico. Debido a que los LSP de paquetes son unidireccionales, debe crear un LSP-FA para llegar al interlocutor y un segundo FA-LSP para que regresen del interlocutor.

Establecimiento de la información de ruta FA-LSP

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

Nota:

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

, Anulación correcta de los LSP de RSVP

Puede deshacer un LSP de RSVP en un proceso de dos pasos que retire correctamente la sesión RSVP utilizada por el LSP. En todos los vecinos que admiten la destrucción correcta, la plataforma de enrutamiento envía una solicitud para el desmontaje al extremo de destino para el LSP y todos los vecinos RSVP de la ruta. La solicitud se incluye en el ADMIN_STATUS campo del paquete RSVP. Cuando los vecinos reciben la solicitud, se preparan para que la sesión RSVP se retire. La plataforma de enrutamiento envía un segundo mensaje para completar la destrucción de la sesión RSVP. Si un vecino no admite la destrucción correcta, la solicitud se tratará como una destrucción estándar de la sesión, en lugar de una sin ninguna.

Para llevar a cabo una destrucción correcta de una sesión de RSVP clear rsvp session gracefully , ejecute el comando. Opcionalmente, puede especificar la dirección de origen y de 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-id, y 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 destrucción correcta antes de iniciar la destrucción real incluyendo graceful-deletion-timeout la instrucción en [edit protocols rsvp] el 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 el tiempo de espera de eliminación show rsvp version sin problemas, emita el comando modo de funcionamiento.

Tabla de historial de versiones
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 de RSVP, se desactivan las sesiones RSVP.