EN ESTA PÁGINA
Configuración de confirmaciones de saludo para vecinos que no sean RSVP de sesión
Configuración de la protección del programa de instalación de RSVP
Configuración de temporizadores para mensajes de actualización de RSVP
Configuración de RSVP para que aparezca la etiqueta en el enrutador de salto final
Habilitación del estallido de salto máximo en LSP de punto a multipunto
Configuración de pares del protocolo de administración de vínculos
Configuración de vínculos de ingeniería de tráfico del protocolo de administración de vínculos
Configuración de RSVP
Configuración mínima de RSVP
Para habilitar RSVP en una sola interfaz, incluya la instrucción y especifique la interfaz mediante la instrucción.rsvpinterface Esta es la configuración mínima de RSVP. Todas las demás instrucciones de configuración RSVP son opcionales.
rsvp { interface interface-name; }
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 la variable.allinterface-name
Si ha configurado propiedades de interfaz en un grupo de interfaces y desea deshabilitar RSVP en una de las interfaces, incluya la instrucción:disable
interface interface-name { disable; }
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
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 instrucción en el nivel de jerarquía.label-switched-path[edit protocols mpls] 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 jerarquía.[edit protocols mpls label-switched-path name]
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:
[edit]
protocols {
mpls {
label-switched-path sf-to-london {
to 192.168.1.4;
}
}
rsvp {
interface so-0/0/0;
}
}
A continuación se muestra un ejemplo de configuración para todos los demás enrutadores que forman el LSP:
[edit]
protocols {
mpls {
interface so-0/0/0;
}
rsvp {
interface so-0/0/0;
}
}
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
- Configuración del intervalo de saludo RSVP
- Configuración de la autenticación RSVP
- Configuración de la suscripción de ancho de banda para tipos de clase
- Configuración del umbral de actualización RSVP en una interfaz
- Configuración de RSVP para interfaces no numeradas
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:
y —Habilitar todas las funciones de reducción de actualización de RSVP:
aggregatereliableAgrupació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 instrucciones y .
aggregatereliableno-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.Reducción de actualización de RSVP
Si la 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.no-reliable 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 la instrucción o con las instrucciones y .aggregateno-reliablereliableno-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 instrucción:aggregate
aggregate;
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 instrucción:no-aggregate
no-aggregate;
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 instrucción:reliable
reliable;
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 instrucción:no-reliable
no-reliable;
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 comando.show rsvp neighbor detail A continuación se muestra el resultado de ejemplo:
user@host> show rsvp neighbor detail
RSVP neighbor: 6 learned
Address: 192.168.224.178 via: fxp1.0 status: Up
Last changed time: 10:06, Idle: 5 sec, Up cnt: 1, Down cnt: 0
Message received: 36
Hello: sent 69, received: 69, interval: 9 sec
Remote instance: 0x60b8feba, Local instance: 0x74bc7a8d
Refresh reduction: not operational
Address: 192.168.224.186 via: fxp2.0 status: Down
Last changed time: 10:17, Idle: 40 sec, Up cnt: 0, Down cnt: 0
Message received: 6
Hello: sent 20, received: 0, interval: 9 sec
Remote instance: 0x0, Local instance: 0x2ae1b339
Refresh reduction: incomplete
Remote end: disabled, Ack-extension: enabled
Address: 192.168.224.188 via: fxp2.0 status: Up
Last changed time: 4:15, Idle: 0 sec, Up cnt: 1, Down cnt: 0
Message received: 55
Hello: sent 47, received: 31, interval: 9 sec
Remote instance: 0x6436a35b, Local instance: 0x663849f0
Refresh reduction: operational
Remote end: enabled, Ack-extension: enabled
Para obtener más información sobre el comando.show rsvp neighbor detail
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 instrucción:hello-interval
hello-interval seconds;
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 para obtener información sobre cómo volver al comportamiento histórico de enviar saludos a través del próximo salto del IGP.no-node-hello-on-bypass
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 instrucción:authentication-key
authentication-key key;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
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 porcentaje de suscripción de ancho de banda para proveedores de servicios lingüísticos (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 instrucción en el nivel de jerarquía, puede ajustar el umbral en el que un cambio en el ancho de banda reservado desencadena una actualización de IGP.update-threshold[edit protocols rsvp]
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 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.update-threshold 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 la instrucción.threshold-valueupdate-threshold
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á configurado de más de 200 Mbps, el límite es de 200 Mbps.threshold-valuethreshold-value El se muestra como 20.000% y el como 200Mbps.threshold-percentthreshold-value
Las dos opciones, y , son mutuamente excluyentes.threshold-percentthreshold-value 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 está configurado al 5%, se calcula y se muestra como 50Mbps.threshold-percentthreshold-value Del mismo modo, si el está configurado en 50 m, entonces el se calcula y se muestra como 5%.threshold-valuethreshold-percent
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 .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 instrucción en el nivel de jerarquía o en 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) mediante la información proporcionada por los mensajes de PathErr.rsvp-error-hold-time[edit protocols mpls][edit logical-systems logical-system-name protocols mpls] Consulte Mejora de la precisión de la base de datos de ingeniería de tráfico con mensajes RSVP PathErr.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 instrucción especificada en el nivel de jerarquía.router-id[edit routing-options] 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.
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 para obtener información sobre cómo volver al comportamiento histórico de enviar saludos a través del próximo salto del IGP.no-node-hello-on-bypass
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.hello-interval (Protocols RSVP) 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 instrucción).hello-interval 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:no-interface-hello
-
[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
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 jerarquía.[edit]
set interfaces ge-0/0/0 unit 0 family mpls set protocols rsvp interface ge-0/0/0.0 set protocols mpls label-switched-path r1-r7 to 10.0.9.7 set protocols mpls label-switched-path r1-r7 bandwidth 10m set protocols mpls interface all
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.Usar el editor de CLI en el modo de configuraciónhttps://www.juniper.net/documentation/en_US/junos15.1/information-products/pathway-pages/junos-cli/junos-cli.html
Para configurar RSVP:
Habilite la familia MPLS en todas las interfaces de tránsito de la red MPLS.
[edit] user@host# set interfaces ge-0/0/0 unit 0 family mpls
Habilite RSVP en cada interfaz de tránsito de la red MPLS.
[edit] user @host# set protocols rsvp interface ge-0/0/0
Habilite el proceso MPLS en la interfaz de tránsito en la red MPLS.
[edit] user@host# set protocols mpls interface ge-0/0/0
Defina el LSP en el enrutador de entrada.
[edit protocols mpls] user@host# set label-switched-path r1-r7 to 10.0.9.7
Reserve 10 Mbps de ancho de banda en el LSP.
[edit protocols mpls] user @host# set label-switched-path r1-r7 bandwidth 10m
Resultados
Confirme la configuración introduciendo el comando desde el modo de configuración.show 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 (...).
user@host# show
...
interfaces {
ge-0/0/0 {
family mpls;
}
}
}
...
protocols {
rsvp {
interface ge-0/0/0.0;
}
mpls {
label-switched-path r1-r7 {
to 10.0.9.7;
bandwidth 10m;
}
interface all;
}
}
...
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
- Verificación de sesiones RSVP
- Comprobación de la presencia de LSP señalados por RSVP
Verificar RSVP Neighbors
Propósito
Verifique que cada dispositivo muestre los vecinos RSVP apropiados, por ejemplo, que el enrutador R1 enumera tanto el enrutador R3 como el enrutador R2 como vecinos de RSVP.Figura 1
Acción
Desde la CLI, ingrese el comando show rsvp neighbor.
user@r1> show rsvp neighbor RSVP neighbor: 2 learned Address Idle Up/Dn LastChange HelloInt HelloTx/Rx 10.0.6.2 0 3/2 13:01 3 366/349 10.0.3.3 0 1/0 22:49 3 448/448
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.
user@r1> show rsvp session detail Ingress RSVP: 1 sessions 10.0.9.7 From: 10.0.6.1, LSPstate: Up, ActiveRoute: 0 LSPname: r1–r7, LSPpath: Primary Bidirectional, Upstream label in: –, Upstream label out: - Suggested label received: -, Suggested label sent: – Recovery label received: -, Recovery label sent: 100000 Resv style: 1 FF, Label in: -, Label out: 100000 Time left: -, Since: Thu Jan 26 17:57:45 2002 Tspec: rate 10Mbps size 10Mbps peak Infbps m 20 M 1500 Port number: sender 3 receiver 17 protocol 0 PATH rcvfrom: localclient PATH sentto: 10.0.4.13 (ge-0/0/1.0) 1467 pkts RESV rcvfrom: 10.0.4.13 (ge-0/0/1.0) 1467 pkts Record route: <self> 10.0.4.13 10.0.2.1 10.0.8.10
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 , aparece el valor de ancho de banda adecuado, , .Tspec10Mbps
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 tabla de enrutamiento del enrutador de entrada R1 en tiene un LSP configurado para la dirección de circuito cerrado del enrutador R7.inet.3Figura 1
Acción
Desde la CLI, ingrese el comando show route table inet.3.
user@r1> show route table inet.3
inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.9.7/32 *[RSVP/7] 00:05:29, metric 10
> to 10.0.4.17 via ge-0/0/0.0, label-switched-path r1–r7
El resultado muestra las rutas RSVP que existen en la tabla de enrutamiento.inet.3 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 en todos los enrutadores PE permite que RSVP cree automáticamente los LSP necesarios cuando se agrega un nuevo enrutador PE.rsvp-te
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 instrucción.rsvp-te 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 instrucción.rsvp-te
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 , hay tres enrutadores PE existentes, PE1, PE2 y PE3, en la topología.Figura 2 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.
Configuración
La configuración de la malla automática RSVP implica realizar estas tareas:
Habilitar la instrucción de configuración en el nivel jerárquico .
rsvp-te[edit routing-options dynamic-tunnels dynamic-tunnel-name]Configuración del elemento necesario .
destination-networksEste 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-templateEste elemento de configuración toma como argumento o el nombre de una plantilla LSP preconfigurada.
default-templateLa es una plantilla definida por el sistema que no requiere configuración de usuario.default-template
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 jerarquía.[edit]
Enrutador PE4
set routing-options dynamic-tunnels dt-1 rsvp-te rsvp-te-1 label-switched-path-template default-template set routing-options dynamic-tunnels dt-1 rsvp-te rsvp-te-1 destination-networks 192.0.2.0/24
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:
Configure en el nivel jerárquico .
rsvp-te[edit routing-options dynamic-tunnels][edit routing-options dynamic-tunnels] user@PE4# set dt-1 rsvp-te rsvp-te-1 label-switched-path-template default-template
Configure en el nivel jerárquico .
destination-networks[edit routing-options dynamic-tunnels][edit routing-options dynamic-tunnels] user@PE4# set dt-1 rsvp-te rsvp-te-1 destination-networks 192.0.2.0/24
Resultados
Emita el comando desde el nivel de jerarquía para ver los resultados de su configuración:show[edit routing-options dynamic-tunnels]
[edit routing-options dynamic-tunnels]
user@PE4#show
dt-1 {
rsvp-te rsvp-te-1 {
label-switched-path-template {
default-template;
}
destination-networks {
192.0.2.0/24;
}
}
}
Verificación
- Verificación de la existencia de túneles de malla automáticos RSVP en el enrutador PE4
- Comprobación de la existencia de LSP MPLS en el enrutador PE4
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 modo operativo.show dynamic-tunnels database Este comando mostrará la red de destino en la que se pueden crear túneles dinámicos.
Acción
user@PE4> show dynamic-tunnels database Table: inet.3 Destination-network: 192.0.2.0/24
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 modo operativo.show mpls lsp Este comando mostrará el estado de los LSP de MPLS.
Acción
user@PE4> show mpls lsp
Ingress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Egress LSP: 3 sessions To From State Rt Style Labelin Labelout LSPname 192.0.2.104 192.0.2.103 Up 0 1 FF 3 - PE2-PE4 192.0.2.104 192.0.2.102 Up 0 1 FF 3 - PE2-PE4 192.0.2.104 192.0.2.101 Up 0 1 FF 3 - PE1-PE4 Total 3 displayed, Up 3, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0
Configuración de confirmaciones de saludo para vecinos que no sean RSVP de sesión
La 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.hello-acknowledgements
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 instrucción en el nivel jerárquico, los mensajes de saludo de vecinos que no son de sesión se confirman con un mensaje de confirmación de saludo.hello-acknowledgements[edit protocols rsvp] 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 instrucción está deshabilitada de forma predeterminada.hello-acknowledgements 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.
hello-acknowledgements;
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.
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 instrucción para un LSP punto a multipunto, el tráfico no se cambia al LSP de omitir punto a multipunto.
switch-away-lspsSi 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:
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.
También hay un LSP de derivación que protege el enlace o nodo.
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.
Cuando el vínculo o nodo se ha recuperado, el LSP se puede revertir automáticamente a la ruta principal.
Debe configurar la instrucción en el 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.setup-protection[edit protocols rsvp] También debe configurar la ingeniería de tráfico IGP en todos los enrutadores de la ruta LSP. Puede emitir un 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.show rsvp session
Para habilitar la protección del programa de instalación de RSVP, incluya la instrucciónsetup-protection
setup-protection;
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 instrucción de la siguiente manera:policy-statement
[edit policy-options] policy-statement policy-name { then { load-balance per-packet; } accept; }
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 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.policy-statement Consulte también Configuración del reenrutamiento rápido.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 instrucción con la opción:load-balancebandwidth
load-balance { bandwidth; }
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 instrucción:load-balance
Si configura la instrucción, no se modifica el comportamiento de los LSP que se ejecutan actualmente.
load-balancePara forzar que los LSP que se ejecutan actualmente usen el nuevo comportamiento, puede emitir un comando.clear mpls lspLa instrucción sólo se aplica a los LSP de entrada que tienen habilitado el equilibrio de carga por paquete.
load-balancePara 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 instrucción en todos los enrutadores PE en la malla completa.rsvp-te
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 instrucción:rsvp-te
rsvp-te { destination-networks network-prefix; label-switched-path-template (Multicast) { default-template; template-name; } }
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.: puede configurar la plantilla predeterminada explícitamente mediante la opción o puede configurar una plantilla LSP propia mediante la opción.
label-switched-path-template (Multicast)default-templatetemplate-nameLa 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 instrucción de 30, multiplicado por un valor fijo de 1,5.refresh-timeEste 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:
lifetime = (keep-multiplier + 0.5) x (1.5 x refresh-time)
En el peor de los casos, ( – 1) los mensajes de actualización sucesivos deben perderse antes de que se elimine un estado de reserva.keep-multiplier
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 instrucción:refresh-time
refresh-time seconds;
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 instrucción:keep-multiplier
keep-multiplier number;
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 instrucción con la opción:preemptionaggressive
preemption aggressive;
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 instrucción con la opción:preemptiondisabled
preemption disabled;
Para volver al valor predeterminado (es decir, tener preferencia sobre una sesión solo para una nueva sesión de mayor prioridad), incluya la instrucción con la opción:preemptionnormal
preemption normal;
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 instrucción:path-mtu
path-mtu { allow-fragmentation; rsvp { mtu-signaling; } }
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 instrucción:rsvp mtu-signaling
rsvp mtu-signaling;
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 instrucción por sí misma en el nivel jerárquico .mtu-signaling[edit protocols mpls path-mtu rsvp] Esto puede ser útil para la solución de problemas. Si configura solo la instrucción, puede usar el comando para determinar cuál es la MTU más pequeña en un LSP.mtu-signalingshow rsvp session detail El comando muestra el valor MTU recibido y enviado en el objeto Adspec.show rsvp session detail
Habilitación de la fragmentación de paquetes
Para permitir que los paquetes IP se fragmenten antes de encapsularlos en MPLS, incluya la instrucción:allow-fragmentation
allow-fragmentation;
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 instrucción solo.
allow-fragmentationSiempre configúrelo junto con la instrucción.mtu-signaling
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.
También puede configurar el estallido de salto máximo (UHP) (como se muestra en ) para los LSP señalados por RSVP.Figura 4 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 ) 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.Figura 4 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).
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
tracerouteComando
Para obtener más información sobre el comportamiento de UHP, consulte Internet draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt, Non PHP behavior and Out-of-Band Mapping for RSVP-TE LSP.
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 instrucción para la instancia de enrutamiento VPN de capa 3, la etiqueta LSI interna apunta a la tabla de enrutamiento VRF.
vrf-table-labelTambié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 plataformas de enrutamiento universal 5G de la serie MX.
vrf-table-labelVPLS: 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 serie MX 3D.
no-tunnel-serviceIPv4 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 instrucción.
install-nexthopTambié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.
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.
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 instrucción:explicit-null
explicit-null;
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 instrucción.tunnel-services 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 opción para la instrucción.devicestunnel-services La opción le permite especificar qué interfaces VT deben ser utilizadas por RSVP.devices 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 instrucción:tunnel-services
tunnel-services { devices device-names; }
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 instrucción con la opción:interfaceall
interface all;
Debe configurar esta instrucción en el nivel de jerarquía.[edit protocols rsvp]
Seguimiento del tráfico del protocolo RSVP
Para realizar un seguimiento del tráfico del protocolo RSVP, incluya la instrucción:traceoptions
traceoptions { file filename <files number> <size size> <world-readable | no-world-readable>; flag flag <flag-modifier> <disable>; }
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 instrucción para especificar el nombre del archivo que recibe el resultado de la operación de seguimiento.file 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 detectadasevent—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 RSVPpath—Todos los mensajes de rutapathtear—Mensajes de PathTearresv—Mensajes Resvresvtear—Mensajes de ResvTearroute—Información de enrutamientostate—Transiciones de estado de sesión, incluso cuando los LSP señalados por RSVP suben y bajan.
Use el indicador de rastreo y el modificador de indicador con precaución, ya que podrían hacer que la CPU se vuelva muy ocupada.alldetail
Para ver el archivo de registro generado al habilitar RSVP traceoptions, ejecute el comando, donde es el archivo que especificó mediante la instrucción.show log file-namefile-nametraceoptions
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.https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/config-guide-routing/index.html
Ejemplos: Seguimiento del tráfico del protocolo RSVP
Rastree los mensajes de ruta RSVP en detalle:
[edit]
protocols {
rsvp {
traceoptions {
file rsvp size 10m files 5;
flag path;
}
}
}
Rastree todos los mensajes RSVP:
[edit]
protocols {
rsvp {
traceoptions {
file rsvp size 10m files 5;
flag packets;
}
}
}
Rastree todas las condiciones de error de RSVP:
[edit]
protocols {
rsvp {
traceoptions {
file rsvp size 10m files 5;
flag error;
}
}
}
Transiciones de estado de RSVP de seguimiento:
[edit]
protocols {
rsvp {
traceoptions {
file rsvp-data;
flag state;
}
}
}
Salida del archivo de registro RSVP
A continuación se muestra un ejemplo de salida generado al emitir el comando en un enrutador en el que se han habilitado traceoptions RSVP con el indicador configurado.show log file-namestate 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.
user@host> show log rsvp-data
Mar 11 13:58:51 trace_on: Tracing to "/var/log/E/rsvp-data" started
Mar 11 13:58:51.286413 rsvp_iflchange for vt ifl vt-1/2/0.69206016
Mar 11 13:58:51.286718 RSVP add interface vt-1/2/0.69206016, ifindex 101, ifaddr (null), family 1, is_appl_vt 0, already known
Mar 11 13:58:51.286818 RSVP Peer vt-1/2/0.69206016 TE-link __rpd:vt-1/2/0.69206016 Up
Mar 11 13:58:51.286978 RSVP add interface vt-1/2/0.69206016, ifindex 101, ifaddr (null), family 3, is_appl_vt 0, already known
Mar 11 13:58:51.287962 RSVP add interface lt-1/2/0.2, ifindex 113, ifaddr (null), family 2, is_appl_vt 0, already known
Mar 11 13:58:51.288629 RSVP add interface lt-1/2/0.2, ifindex 113, ifaddr 10.0.0.2, family 1, is_appl_vt 0, already known
Mar 11 13:58:51.288996 RSVP add interface lt-1/2/0.17, ifindex 114, ifaddr (null), family 2, is_appl_vt 0, already known
Mar 11 13:58:51.289593 RSVP add interface lt-1/2/0.17, ifindex 114, ifaddr (null), family 3, is_appl_vt 0, already known
Mar 11 13:58:51.289949 RSVP add interface lt-1/2/0.17, ifindex 114, ifaddr 10.0.0.17, family 1, is_appl_vt 0, already known
Mar 11 13:58:51.290049 RSVP Peer lt-1/2/0.17 TE-link __rpd:lt-1/2/0.17 Up
Mar 11 13:59:05.042034 RSVP new bypass Bypass->10.0.0.18 on interface lt-1/2/0.17 to 10.0.0.18 avoid 0.0.0.0
Mar 11 14:04:36.707092 LSP "E-D" is Down (Reason: Reservation state deleted)
Session: 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0 Sender: 192.168.0.5(port/lsp ID 1)
Mar 11 14:04:36.707661 RSVP delete resv state, session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0
Mar 11 14:04:36.781185 RSVP delete path state, session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0
Mar 11 14:04:36.781440 RSVP delete session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0
Mar 11 14:05:30.101492 RSVP new Session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0, session ID 3
Mar 11 14:05:30.101722 RSVP new path state, session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0
Mar 11 14:05:30.179124 RSVP new resv state, session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0
Mar 11 14:05:30.179395 RSVP PSB E-D, allocating psb resources for label 4294967295
Mar 11 14:05:30.180353 LSP "E-D" is Up
Session: 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0 Sender: 192.168.0.5(port/lsp ID 2)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 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.
[protocols rsvp]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 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.show rsvp version
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.
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
- Deshabilitar el reinicio correcto para RSVP
- Deshabilitar el modo auxiliar RSVP
- Configuración del tiempo máximo de recuperación auxiliar
- Configuración del tiempo máximo de reinicio auxiliar
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 instrucción:graceful-restart
graceful-restart;
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 instrucción en el nivel jerárquico :disable[edit protocols rsvp graceful-restart]
disable;
Deshabilitar el modo auxiliar RSVP
Para deshabilitar el modo auxiliar RSVP, incluya la instrucción en el nivel de jerarquía:helper-disable[edit protocols rsvp graceful-restart]
helper-disable;
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 instrucción en el nivel de jerarquía.maximum-helper-recovery-time[edit protocols rsvp graceful-restart] 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.
maximum-helper-recovery-time seconds;
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 instrucción en el nivel de jerarquía.maximum-helper-restart-time[edit protocols rsvp graceful-restart] 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.
maximum-helper-restart-time seconds;
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 muestra un LSP RSVP de extremo a extremo llamado que se origina en el enrutador 0 y termina en el enrutador 5. En tránsito, este LSP atraviesa el FA-LSP .e2e_lsp_r0r5fa_lsp_r1r4 La ruta de retorno está representada por el LSP RSVP de extremo a extremo que viaja sobre el FA-LSP .e2e_lsp_r5r0fa_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
[edit]
interfaces {
so-0/0/3 {
unit 0 {
family inet {
address 10.1.2.1/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.41.222/32;
}
family mpls;
}
}
}
routing-options {
forwarding-table {
export pplb;
}
}
protocols {
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
admin-groups {
fa 1;
backup 2;
other 3;
}
label-switched-path e2e_lsp_r0r5 { # An end-to-end LSP traveling to Router 5.
to 10.255.41.221;
bandwidth 30k;
primary path-fa; # Reference the requested path here.
}
path path-fa { # Configure the strict path here.
10.1.2.2 strict;
172.16.30.2 strict; # This traverses the TE link heading to Router 4.
}
interface all;
interface fxp0.0 {
disable;
}
interface so-3/2/1.0 {
admin-group other;
}
interface so-0/0/3.0 {
admin-group other;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface all;
}
}
}
policy-options {
policy-statement pplb {
then {
load-balance per-packet;
}
}
}
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
[edit]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.2.3.1/30;
}
family mpls;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.2.4.1/30;
}
family mpls;
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.1.2.2/30;
}
family mpls;
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.2.5.1/30;
}
family mpls;
}
}
at-1/0/0 {
atm-options {
vpi 1;
}
unit 0 {
vci 1.100;
family inet {
address 10.2.3.5/30;
}
family mpls;
}
}
}
routing-options {
forwarding-table {
export [ pplb choose_lsp ];
}
}
protocols {
rsvp {
interface all;
interface fxp0.0 {
disable;
}
peer-interface r4; # Apply the LMP peer interface here.
}
mpls {
admin-groups {
fa 1;
backup 2;
other 3;
}
label-switched-path fa_lsp_r1r4 { # Configure your FA-LSP to Router 4 here.
to 10.255.41.217;
bandwidth 400k;
primary path_r1r4; # Apply the FA-LSP path here.
}
path path_r1r4 { # Configure the FA-LSP path here.
10.2.4.2;
10.4.5.2;
10.3.5.1;
}
interface so-0/0/3.0 {
admin-group other;
}
interface so-0/0/1.0 {
admin-group fa;
}
interface at-1/0/0.0 {
admin-group backup;
}
interface fe-0/1/2.0 {
admin-group backup;
}
interface so-0/0/2.0 {
admin-group fa;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface all;
peer-interface r4; # Apply the LMP peer interface here.
}
}
link-management { # Configure LMP statements here.
te-link link_r1r4 { # Assign a name to the TE link here.
local-address 172.16.30.1; # Configure a local address for the TE link.
remote-address 172.16.30.2; # Configure a remote address for the TE link.
te-metric 1; # Manually set a metric here if you are not relying on CSPF.
label-switched-path fa_lsp_r1r4; # Reference the FA-LSP here.
}
peer r4 { # Configure LMP peers here.
address 10.255.41.217; # Configure the loopback address of your peer here.
te-link link_r1r4; # Apply the LMP TE link here.
}
}
}
policy-options {
policy-statement choose_lsp {
term A {
from community choose_e2e_lsp;
then {
install-nexthop strict lsp e2e_lsp_r1r4;
accept;
}
}
term B {
from community choose_fa_lsp;
then {
install-nexthop strict lsp fa_lsp_r1r4;
accept;
}
}
}
policy-statement pplb {
then {
load-balance per-packet;
}
}
community choose_e2e_lsp members 1000:1000;
community choose_fa_lsp members 2000:2000;
community set_e2e_lsp members 1000:1000;
community set_fa_lsp members 2000:2000;
}
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
[edit]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.4.5.1/30;
}
family mpls;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.1.4.2/30;
}
family mpls;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.2.4.2/30;
}
family mpls;
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.3.4.2/30;
}
family mpls;
}
}
}
routing-options {
forwarding-table {
export pplb;
}
}
protocols { # OSPF, MPLS, and RSVP form the core backbone for the FA-LSPs.
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
admin-groups {
fa 1;
backup 2;
other 3;
}
path path_r1 {
10.2.4.1;
}
path path_r3r4 {
10.4.5.2;
10.3.5.1;
}
interface all;
interface fxp0.0 {
disable;
}
interface so-0/0/1.0 {
admin-group other;
}
interface fe-0/1/2.0 {
admin-group backup;
}
interface so-0/0/2.0 {
admin-group fa;
}
interface so-0/0/0.0 {
admin-group fa;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface all;
}
}
}
policy-options {
policy-statement pplb {
then {
load-balance per-packet;
}
}
}
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
[edit]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.4.5.2/30;
}
family mpls;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.5.6.1/30;
}
family mpls;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.3.5.2/30;
}
family mpls;
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.2.5.2/30;
}
family mpls;
}
}
}
routing-options {
forwarding-table {
export pplb;
}
}
protocols { # OSPF, MPLS, and RSVP form the core backbone for the FA-LSPs.
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
admin-groups {
fa 1;
backup 2;
other 3;
}
path path_r4 {
10.3.5.1;
}
path path_r2r1 {
10.4.5.1;
10.2.4.1;
}
interface all;
interface fxp0.0 {
disable;
}
interface so-0/0/2.0 {
admin-group fa;
}
interface fe-0/1/2.0 {
admin-group backup;
}
interface so-0/0/1.0 {
admin-group other;
}
interface so-0/0/0.0 {
admin-group fa;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface all;
}
}
}
policy-options {
policy-statement pplb {
then {
load-balance per-packet;
}
}
}
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
[edit]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.3.6.1/30;
}
family mpls;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.2.3.2/30;
}
family mpls;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.3.5.1/30;
}
family mpls;
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.3.4.1/30;
}
family mpls;
}
}
at-1/0/0 {
atm-options {
vpi 1;
}
unit 0 {
vci 1.100;
family inet {
address 10.2.3.6/30;
}
family mpls;
}
}
}
routing-options {
forwarding-table {
export [ pplb choose_lsp ];
}
}
protocols {
rsvp {
interface all;
interface fxp0.0 {
disable;
}
peer-interface r1; # Apply the LMP peer interface here.
}
mpls {
admin-groups {
fa 1;
backup 2;
other 3;
}
label-switched-path fa_lsp_r4r1 { # Configure your FA-LSP here.
to 10.255.41.216;
bandwidth 400k;
primary path_r4r1; # Apply the FA-LSP path here.
}
path path_r4r1 { # Configure the FA-LSP path here.
10.3.5.2;
10.4.5.1;
10.2.4.1;
}
interface all;
interface fxp0.0 {
disable;
}
interface at-1/0/0.0 {
admin-group backup;
}
interface so-0/0/2.0 {
admin-group fa;
}
interface fe-0/1/2.0 {
admin-group backup;
}
interface so-0/0/0.0 {
admin-group other;
}
interface so-0/0/1.0 {
admin-group fa;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface all;
peer-interface r1; # Apply the LMP peer interface here.
}
}
link-management { # Configure LMP statements here.
te-link link_r4r1 { # Assign a name to the TE link here.
local-address 172.16.30.2; # Configure a local address for the TE link.
remote-address 172.16.30.1; # Configure a remote address for the TE link.
te-metric 1; # Manually set a metric here if you are not relying on CSPF.
label-switched-path fa_lsp_r4r1; # Reference the FA-LSP here.
}
peer r1 { # Configure LMP peers here.
address 10.255.41.216; # Configure the loopback address of your peer here.
te-link link_r4r1; # Apply the LMP TE link here.
}
}
}
policy-options {
policy-statement choose_lsp {
term A {
from community choose_e2e_lsp;
then {
install-nexthop strict lsp e2e_lsp_r4r1;
accept;
}
}
term B {
from community choose_fa_lsp;
then {
install-nexthop strict lsp fa_lsp_r4r1;
accept;
}
}
}
policy-statement pplb {
then {
load-balance per-packet;
}
}
community choose_e2e_lsp members 1000:1000;
community choose_fa_lsp members 2000:2000;
community set_e2e_lsp members 1000:1000;
community set_fa_lsp members 2000:2000;
}
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
[edit]
interfaces {
so-0/0/2 {
unit 0 {
family inet {
address 10.3.6.2/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.41.221/32;
}
}
}
}
routing-options {
forwarding-table {
export pplb;
}
}
protocols {
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
admin-groups {
fa 1;
backup 2;
other 3;
}
label-switched-path e2e_lsp_r5r0 { # An end-to-end LSP returning to Router 0.
to 10.255.41.222;
bandwidth 30k;
primary path-fa; # Reference the requested path here.
}
path path-fa { # Configure the strict path here.
10.3.6.1 strict;
172.16.30.1 strict; # This traverses the TE link heading to Router 1.
}
interface all;
interface fxp0.0 {
disable;
}
interface so-0/0/2.0 {
admin-group other;
}
interface so-0/0/1.0 {
admin-group other;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface all;
}
}
}
policy-options {
policy-statement pplb {
then {
load-balance per-packet;
}
}
}
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-managementshow 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 () y del enrutador 4 () que hacen referencia a las direcciones de vínculo de ingeniería de tráfico LMP de y .10.255.41.21610.255.41.217172.16.30.1172.16.30.2 También puede emitir el comando para buscar la ruta del LSP de extremo a extremo a medida que viaja al enrutador 5 a través del FA-LSP.show rsvp session extensive
user@router0> show ted database
TED database: 0 ISIS nodes 8 INET nodes
ID Type Age(s) LnkIn LnkOut Protocol
10.255.41.214 Rtr 486 4 4 OSPF(0.0.0.0)
To: 10.255.41.222, Local: 10.1.4.2, Remote: 10.1.4.1
To: 10.255.41.216, Local: 10.2.4.2, Remote: 10.2.4.1
To: 10.255.41.215, Local: 10.4.5.1, Remote: 10.4.5.2
To: 10.3.4.1-1, Local: 10.3.4.2, Remote: 0.0.0.0
ID Type Age(s) LnkIn LnkOut Protocol
10.255.41.215 Rtr 187 4 4 OSPF(0.0.0.0)
To: 10.255.41.214, Local: 10.4.5.2, Remote: 10.4.5.1
To: 10.255.41.217, Local: 10.3.5.2, Remote: 10.3.5.1
To: 10.255.41.221, Local: 10.5.6.1, Remote: 10.5.6.2
To: 10.2.5.1-1, Local: 10.2.5.2, Remote: 0.0.0.0
ID Type Age(s) LnkIn LnkOut Protocol
10.255.41.216 Rtr 396 6 6 OSPF(0.0.0.0)
To: 10.255.41.222, Local: 10.1.2.2, Remote: 10.1.2.1
To: 10.255.41.214, Local: 10.2.4.1, Remote: 10.2.4.2
To: 10.255.41.217, Local: 10.2.3.1, Remote: 10.2.3.2
To: 10.255.41.217, Local: 172.16.30.1, Remote: 172.16.30.2
To: 10.255.41.217, Local: 10.2.3.5, Remote: 10.2.3.6
To: 10.2.5.1-1, Local: 10.2.5.1, Remote: 0.0.0.0
ID Type Age(s) LnkIn LnkOut Protocol
10.255.41.217 Rtr 404 6 6 OSPF(0.0.0.0)
To: 10.255.41.216, Local: 10.2.3.2, Remote: 10.2.3.1
To: 10.255.41.216, Local: 172.16.30.2, Remote: 172.16.30.1
To: 10.255.41.216, Local: 10.2.3.6, Remote: 10.2.3.5
To: 10.255.41.215, Local: 10.3.5.1, Remote: 10.3.5.2
To: 10.255.41.221, Local: 10.3.6.1, Remote: 10.3.6.2
To: 10.3.4.1-1, Local: 10.3.4.1, Remote: 0.0.0.0
ID Type Age(s) LnkIn LnkOut Protocol
10.255.41.221 Rtr 481 2 2 OSPF(0.0.0.0)
To: 10.255.41.215, Local: 10.5.6.2, Remote: 10.5.6.1
To: 10.255.41.217, Local: 10.3.6.2, Remote: 10.3.6.1
ID Type Age(s) LnkIn LnkOut Protocol
10.255.41.222 Rtr 2883 2 2 OSPF(0.0.0.0)
To: 10.255.41.216, Local: 10.1.2.1, Remote: 10.1.2.2
To: 10.255.41.214, Local: 10.1.4.1, Remote: 10.1.4.2
user@router0> show ted database 10.255.41.216 extensive
TED database: 0 ISIS nodes 8 INET nodes
NodeID: 10.255.41.216
Type: Rtr, Age: 421 secs, LinkIn: 6, LinkOut: 6
Protocol: OSPF(0.0.0.0)
To: 10.255.41.222, Local: 10.1.2.2, Remote: 10.1.2.1
Color: 0x8 other
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.4Mbps [1] 155.4Mbps [2] 155.4Mbps [3] 155.4Mbps
[4] 155.4Mbps [5] 155.4Mbps [6] 155.4Mbps [7] 155.4Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.4Mbps [1] 155.4Mbps [2] 155.4Mbps [3] 155.4Mbps
[4] 155.4Mbps [5] 155.4Mbps [6] 155.4Mbps [7] 155.4Mbps
To: 10.255.41.214, Local: 10.2.4.1, Remote: 10.2.4.2
Color: 0x2 fa
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.12Mbps [1] 155.12Mbps [2] 155.12Mbps [3] 155.12Mbps
[4] 155.12Mbps [5] 155.12Mbps [6] 155.12Mbps [7] 155.12Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.12Mbps [1] 155.12Mbps [2] 155.12Mbps [3] 155.12Mbps
[4] 155.12Mbps [5] 155.12Mbps [6] 155.12Mbps [7] 155.12Mbps
To: 10.255.41.217, Local: 10.2.3.1, Remote: 10.2.3.2
Color: 0x2 fa
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
To: 10.255.41.217, Local: 172.16.30.1, Remote: 172.16.30.2
Metric: 1
Static BW: 400kbps
Reservable BW: 400kbps
Available BW [priority] bps:
[0] 370kbps [1] 370kbps [2] 370kbps [3] 370kbps
[4] 370kbps [5] 370kbps [6] 370kbps [7] 370kbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 370kbps [1] 370kbps [2] 370kbps [3] 370kbps
[4] 370kbps [5] 370kbps [6] 370kbps [7] 370kbps
To: 10.255.41.217, Local: 10.2.3.5, Remote: 10.2.3.6
Color: 0x4 backup
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
To: 10.2.5.1-1, Local: 10.2.5.1, Remote: 0.0.0.0
Color: 0x4 backup
Metric: 1
Static BW: 100Mbps
Reservable BW: 100Mbps
Available BW [priority] bps:
[0] 100Mbps [1] 100Mbps [2] 100Mbps [3] 100Mbps
[4] 100Mbps [5] 100Mbps [6] 100Mbps [7] 100Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 100Mbps [1] 100Mbps [2] 100Mbps [3] 100Mbps
[4] 100Mbps [5] 100Mbps [6] 100Mbps [7] 100Mbps
user@router0> show ted database 10.255.41.217 extensive
TED database: 0 ISIS nodes 8 INET nodes
NodeID: 10.255.41.217
Type: Rtr, Age: 473 secs, LinkIn: 6, LinkOut: 6
Protocol: OSPF(0.0.0.0)
To: 10.255.41.216, Local: 10.2.3.2, Remote: 10.2.3.1
Color: 0x2 fa
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
To: 10.255.41.216, Local: 172.16.30.2, Remote: 172.16.30.1
Metric: 1
Static BW: 400kbps
Reservable BW: 400kbps
Available BW [priority] bps:
[0] 370kbps [1] 370kbps [2] 370kbps [3] 370kbps
[4] 370kbps [5] 370kbps [6] 370kbps [7] 370kbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 370kbps [1] 370kbps [2] 370kbps [3] 370kbps
[4] 370kbps [5] 370kbps [6] 370kbps [7] 370kbps
To: 10.255.41.216, Local: 10.2.3.6, Remote: 10.2.3.5
Color: 0x4 backup
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
To: 10.255.41.215, Local: 10.3.5.1, Remote: 10.3.5.2
Color: 0x2 fa
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.12Mbps [1] 155.12Mbps [2] 155.12Mbps [3] 155.12Mbps
[4] 155.12Mbps [5] 155.12Mbps [6] 155.12Mbps [7] 155.12Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.12Mbps [1] 155.12Mbps [2] 155.12Mbps [3] 155.12Mbps
[4] 155.12Mbps [5] 155.12Mbps [6] 155.12Mbps [7] 155.12Mbps
To: 10.255.41.221, Local: 10.3.6.1, Remote: 10.3.6.2
Color: 0x8 other
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
To: 10.3.4.1-1, Local: 10.3.4.1, Remote: 0.0.0.0
Color: 0x4 backup
Metric: 1
Static BW: 100Mbps
Reservable BW: 100Mbps
Available BW [priority] bps:
[0] 100Mbps [1] 100Mbps [2] 100Mbps [3] 100Mbps
[4] 100Mbps [5] 100Mbps [6] 100Mbps [7] 100Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 100Mbps [1] 100Mbps [2] 100Mbps [3] 100Mbps
[4] 100Mbps [5] 100Mbps [6] 100Mbps [7] 100Mbps
user@router0> show rsvp session name e2e_lsp_r0r5 extensive
Ingress RSVP: 1 sessions
10.255.41.221
From: 10.255.41.222, LSPstate: Up, ActiveRoute: 2
LSPname: e2e_lsp_r0r5, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 101584
Resv style: 1 FF, Label in: -, Label out: 101584
Time left: -, Since: Wed Sep 7 19:02:56 2005
Tspec: rate 30kbps size 30kbps peak Infbps m 20 M 1500
Port number: sender 2 receiver 29458 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: 10.1.2.2 (so-0/0/3.0) 15 pkts
RESV rcvfrom: 10.1.2.2 (so-0/0/3.0) 16 pkts
Explct route: 10.1.2.2 172.16.30.2 10.3.6.2
Record route: <self> 10.1.2.2 172.16.30.2 10.3.6.2
Total 1 displayed, Up 1, Down 0
Egress RSVP: 1 sessions
Total 0 displayed, Up 0, Down 0
Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0
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 conjunto de comandos.show link-management También puede emitir el comando para confirmar que el FA-LSP está operativo.show rsvp session extensive
user@router1> show link-management
Peer name: r4 , System identifier: 10758
State: Up, Control address: 10.255.41.217
TE links:
link_r1r4
TE link name: link_r1r4, State: Up
Local identifier: 16299, Remote identifier: 0, Local address: 172.16.30.1, Remote address: 172.16.30.2,
Encoding: Packet, Switching: Packet, Minimum bandwidth: 0bps, Maximum bandwidth: 400kbps,
Total bandwidth: 400kbps, Available bandwidth: 370kbps
Name State Local ID Remote ID Bandwidth Used LSP-name
fa_lsp_r1r4 Up 22642 0 400kbps Yes e2e_lsp_r0r5
user@router1> show link-management te-link name link_r1r4 detail
TE link name: link_r1r4, State: Up
Local identifier: 16299, Remote identifier: 0, Local address: 172.16.30.1, Remote address: 172.16.30.2,
Encoding: Packet, Switching: Packet, Minimum bandwidth: 0bps, Maximum bandwidth: 400kbps,
Total bandwidth: 400kbps, Available bandwidth: 370kbps
Resource: fa_lsp_r1r4, Type: LSP, System identifier: 2147483683, State: Up, Local identifier: 22642,
Remote identifier: 0
Total bandwidth: 400kbps, Unallocated bandwidth: 370kbps
Traffic parameters: Encoding: Packet, Switching: Packet, Granularity: Unknown
Number of allocations: 1, In use: Yes
LSP name: e2e_lsp_r0r5, Allocated bandwidth: 30kbps
user@router1> show rsvp session name fa_lsp_r1r4 extensive
Ingress RSVP: 1 sessions
10.255.41.217
From: 10.255.41.216, LSPstate: Up, ActiveRoute: 0
LSPname: fa_lsp_r1r4, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 100816
Resv style: 1 FF, Label in: -, Label out: 100816
Time left: -, Since: Wed Sep 7 19:02:33 2005
Tspec: rate 400kbps size 400kbps peak Infbps m 20 M 1500
Port number: sender 2 receiver 5933 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: 10.2.4.2 (so-0/0/2.0) 28 pkts
RESV rcvfrom: 10.2.4.2 (so-0/0/2.0) 26 pkts
Explct route: 10.2.4.2 10.4.5.2 10.3.5.1
Record route: <self> 10.2.4.2 10.4.5.2 10.3.5.1
Total 1 displayed, Up 1, Down 0
Egress RSVP: 1 sessions
Total 0 displayed, Up 0, Down 0
Transit RSVP: 2 sessions
Total 0 displayed, Up 0, Down 0
Configuración de pares del protocolo de administración de vínculos
Después de configurar los vínculos de ingeniería de tráfico, configure los pares de red LMP con la instrucción en el nivel de jerarquía.peer peer-name[edit protocols link-management] Un par es el dispositivo de red con el que su plataforma de enrutamiento se comunica y establece un FA-LSP. Designe un nombre par, configure el ID del enrutador par como la dirección (a menudo una dirección de circuito cerrado) y aplique el vínculo de ingeniería de tráfico que se asociará con este par. Recuerde configurar ambos lados de una relación de emparejamiento para permitir la comunicación bidireccional.
A diferencia de GMPLS, no debe configurar un canal de control para un par Si incluye un canal de control, se producirá un error en la operación de confirmación.
[edit]
protocols {
link-management {
peer peer-name { # Configure the name of your network peer.
address ip-address; # Include the router ID of the peer.
te-link te-link-name; # Assign a TE link to this peer.
}
}
}
Configuración de vínculos de ingeniería de tráfico del protocolo de administración de vínculos
Para comenzar la configuración del túnel RSVP LSP, configure vínculos de ingeniería de tráfico LMP en las plataformas de enrutamiento de entrada y salida. Dado que los vínculos de ingeniería de tráfico definen una conexión unidireccional entre dispositivos pares, debe configurar los vínculos de ingeniería de tráfico en ambas direcciones entre pares para habilitar el transporte bidireccional de paquetes.
Para configurar vínculos de ingeniería de tráfico en LMP, incluya la instrucción en el nivel de jerarquía [].te-link te-link-nameedit protocols link-management Defina las opciones de vínculos de ingeniería de tráfico que se muestran a continuación, especialmente la ruta de conmutación de etiquetas que se utilizará como FA-LSP para llegar al par. Opcionalmente, puede especificar la métrica de ingeniería de tráfico para el vínculo de ingeniería de tráfico (vínculo TE). De forma predeterminada, la métrica de ingeniería de tráfico se deriva del cálculo de CSPF.
[edit]
protocols {
link-management {
te-link te-link-name { # Name of the TE link.
label-switched-path lsp-name; # LSP used for the forwarding adjacency.
local-address ip-address; # Local IP address associated with the TE link.
remote-address ip-address; # Remote IP address mapped to the TE link.
te-metric value; # Traffic engineering metric used for the TE link.
}
}
}
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 instrucción configurada en LMP en el nivel jerárquico .peer peer-name[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 instrucción en el nivel de jerarquía.peer-interface[edit protocols ospf area area-number] Para configurar la señalización RSVP para pares LMP, incluya la instrucción en el nivel dejerarquía.peer-interface [edit protocols rsvp]
[edit]
protocols {
rsvp {
peer-interface peer-name { # Configure the name of your LMP peer.
}
ospf {
area area-number {
peer-interface peer-name { # Configure the name of your LMP peer.
}
}
}
}
}
Definición de rutas conmutadas por etiquetas para el FA-LSP
A continuación, defina su FA-LSP incluyendo la instrucción en el nivel jerárquico .label-switched-path[edit protocols mpls] Incluya el ID de enrutador del par en la instrucción en el nivel de jerarquía.to[edit protocols mpls label-switched-path] 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.
[edit]
protocols {
mpls {
label-switched-path lsp-name {
from ip-address;
to ip-address;
primary path-name;
secondary path-name;
no-cspf; # This statement to disable CSPF is optional.
}
}
}
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 instrucción en el nivel jerárquico , debe utilizar rutas estrictas.no-cspf[edit protocols mpls label-switched-path lsp-name]
[edit]
protocols {
mpls {
path path-name {
next-hop-address (strict | loose);
}
}
}
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 campo del paquete RSVP.ADMIN_STATUS 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 comando.clear rsvp session gracefully 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 opciones , , y cuando ejecute el comando.connection-sourceconnection-destinationlsp-idtunnel-idclear rsvp session gracefully
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 instrucción en el nivel de jerarquía.graceful-deletion-timeout[edit protocols rsvp] 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 modo operativo.show rsvp version
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.