EN ESTA PÁGINA
Configurar reconocimientos de saludo para vecinos de RSVP de no sesión
Configuración de temporizadores para mensajes de actualización RSVP
Configuración de RSVP para abrir la etiqueta en el enrutador Ultimate-Hop
Configuración de pares de protocolo de administración de vínculos
Configurar 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 rsvp instrucción y especifique la interfaz mediante la interface instrucción. Esta es la configuración de RSVP mínima. El resto de 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 all la interface-name variable.
Si ha configurado propiedades de interfaz en un grupo de interfaces y desea deshabilitar RSVP en una de las interfaces, incluya la disable instrucción:
interface interface-name { disable; }
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
Configuración de RSVP y MPLS
El propósito principal del software Junos RSVP es admitir la señalización dinámica dentro de rutas conmutadas por etiquetas (LSP). Cuando habilita MPLS y RSVP en un enrutador, MPLS se convierte en cliente de RSVP. No se requiere ninguna configuración adicional para enlazar MPLS y RSVP.
Puede configurar MPLS para configurar rutas señalizadas mediante la label-switched-path instrucción en el [edit protocols mpls] nivel de jerarquía. Cada LSP se traduce en una solicitud de RSVP para iniciar una sesión de 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 obtiene del enrutador local y está destinada al destino del LSP.
Cuando se crea correctamente una sesión RSVP, el LSP se configura a lo largo de las rutas creadas por la sesión RSVP. Si la sesión RSVP no funciona correctamente, RSVP notifica a MPLS su estado. Le corresponde a MPLS iniciar rutas de copia de seguridad o continuar reintentar la ruta inicial.
Para pasar la información de señalización de conmutación de etiquetas, RSVP admite cuatro objetos adicionales: Label Request objeto, Label objeto, 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 convertirla en un cliente de RSVP, haga lo siguiente:
Habilite MPLS en todos los enrutadores que participarán en la conmutación de etiquetas (es decir, en todos los enrutadores que puedan formar parte de una ruta de conmutación de etiquetas).
Habilite RSVP en todos los enrutadores y en todas las interfaces de enrutador que forman el LSP.
Configure los enrutadores al principio del LSP.
Puede configurar rutas RSVP conmutadas por etiquetas (LSP) para usar una métrica de retraso para calcular la ruta. Para configurar, utilice las opciones de CLI que hemos introducido en la [edit protocols mpls label-switched-path name] jerarquía.
Ejemplo: Configuración de RSVP y MPLS
A continuación se muestra una configuración de ejemplo 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 una configuración de ejemplo 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 siguientes secciones 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
- Configurar la suscripción de ancho de banda para tipos de clase
- Configuración del umbral de actualización de 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 interfaz:
aggregateyreliable—Habilite todas las funciones de reducción de actualización de RSVP: Agrupación de mensajes RSVP, ID de mensaje RSVP, entrega confiable de mensajes y actualización de resumen.Para tener una reducción de actualización y una entrega confiable, debe incluir las
aggregatedeclaraciones yreliable.no-aggregate—Desactive la agrupación de mensajes RSVP y la actualización de resumen.no-reliable—Desactive el ID del mensaje RSVP, la entrega confiable de mensajes y la actualización de resumen.
Para obtener más información sobre la reducción de actualización de RSVP, consulte Reducción de actualización de RSVP.
Si la no-reliable instrucción está configurada en el enrutador (la entrega confiable de mensajes está deshabilitada), el enrutador acepta mensajes RSVP que incluyen el objeto Message ID, pero ignora el objeto Message ID y continúa realizando el procesamiento estándar de mensajes. En este caso, no se genera ningún error y RSVP funciona con normalidad.
Sin embargo, no todas las combinaciones entre dos vecinos con diferentes capacidades de reducción de actualización funcionan correctamente. Por ejemplo, un enrutador está configurado con la instrucción y no-reliable la aggregate instrucción o con las reliable instrucciones yno-aggregate. Si un vecino RSVP envía un objeto Summary Refresh a este enrutador, no se genera ningún error, pero no se puede procesar el objeto Summary Refresh. En consecuencia, los estados RSVP pueden tener tiempo de descanso 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 haya requisitos específicos, que configure la reducción de actualización de RSVP de manera similar en cada vecino de RSVP.
Para habilitar todas las funciones de reducción de actualización de RSVP en una interfaz, incluya la aggregate instrucción:
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 de resumen, incluya la no-aggregate instrucción:
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 reliable instrucción:
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 del mensaje RSVP, la entrega confiable de mensajes y la actualización de resumen, incluya la no-reliable instrucción:
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]
Determinar la capacidad de reducción de actualización de los vecinos de RSVP
Para determinar la capacidad de reducción de actualización de RSVP de un vecino de RSVP, necesita la siguiente información:
El bit RR anunciado por el vecino
La configuración local de la reducción de actualización de RSVP
Los mensajes RSVP reales recibidos del vecino
Para obtener esta información, puede emitir un show rsvp neighbor detail comando. A continuación, se muestra el resultado:
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 show rsvp neighbor detail comando.
Configuración del intervalo de saludo RSVP
RSVP monitorea el estado de los vecinos del protocolo de puerta de enlace interior (IGP) (IS-IS u OSPF) y confía en los protocolos IGP para detectar cuando un nodo falla. Si un protocolo IGP declara a un vecino inactivo (porque ya no se reciben paquetes de saludo), RSVP también hace descender a ese vecino. Sin embargo, los protocolos IGP y RSVP aún actúan de forma independiente 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 influye en si se cae o no una sesión RSVP. Las sesiones de RSVP se mantienen al día incluso si ya no se reciben paquetes de saludo RSVP. Las sesiones de RSVP se mantienen hasta que el enrutador deja de recibir paquetes de saludo de IGP o el tiempo de espera de la ruta RSVP y los mensajes de Resv. Sin embargo, a partir de Junos OS versión 16.1, cuando el tiempo de espera de los mensajes de saludo de RSVP, las sesiones de RSVP se reducen.
El intervalo de saludo de RSVP también podría verse afectado cuando el equipo de otro proveedor hace caer una sesión RSVP. Por ejemplo, un enrutador vecino que no sea de Juniper Networks podría estar configurado para supervisar los paquetes de saludo RSVP.
Para modificar la frecuencia con la que RSVP envía paquetes de saludo, incluya la hello-interval instrucción:
hello-interval seconds;
A partir de la versión 16.1 Junos envía mensajes de saludo de RSVP a través de un LSP de omisión cuando uno está disponible. Consulte no-node-hello-on-bypass para obtener más información sobre cómo revertir al comportamiento histórico de enviar saludos durante el próximo salto del IGP.
Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción.
Configuración de la autenticación RSVP
Todos los intercambios de protocolo 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 usa un código de autenticación de mensaje hash (HMAC)-MD5 síntesis basada en mensajes. Este esquema produce 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 autentican en esta interfaz.
La autenticación MD5 ofrece protección contra falsificaciones y modificaciones de mensajes. También puede evitar ataques de repetición. Sin embargo, no proporciona confidencialidad, ya que todos los mensajes se envían en texto sin formato.
De forma predeterminada, la autenticación está deshabilitada. Para habilitar la autenticación, configure una clave en cada interfaz incluyendo la authentication-key instrucción:
authentication-key key;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
Configurar la suscripción de ancho de banda para tipos de clase
De forma predeterminada, RSVP permite usar el 100 % del ancho de banda de un tipo de clase para reservas de RSVP. Cuando se sobresuscribe un tipo de clase para un LSP multiclase, la demanda agregada de todas las sesiones RSVP puede superar la capacidad real del tipo de clase.
Para obtener instrucciones detalladas sobre cómo configurar la suscripción de ancho de banda para tipos de clase, consulte Configuración del porcentaje de suscripción de ancho de banda para LSP.
Configuración del umbral de actualización de RSVP en una interfaz
Los protocolos de puerta de enlace interior (IGP) mantienen la base de datos de ingeniería de tráfico, pero el ancho de banda disponible actual en los enlaces de la 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 las 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 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 remota), y CSPF puede calcular correctamente las rutas.
Sin embargo, las actualizaciones de IGP pueden consumir recursos del sistema en exceso. Según la cantidad de nodos de una red, es posible que no sea conveniente realizar una actualización de IGP para pequeños cambios en el ancho de banda. Al configurar la update-threshold instrucción en el [edit protocols rsvp] nivel de jerarquía, puede ajustar el umbral en el que un cambio en el ancho de banda reservado desencadena una actualización de IGP.
Puede configurar un valor del 0,001 % al 20 % (el valor predeterminado es el 10 %) para cuándo activar una actualización de IGP. Si el cambio en el ancho de banda reservado es mayor o igual que el porcentaje de umbral configurado del ancho de banda estático en esa interfaz, se produce una actualización de IGP. Por ejemplo, si configuró la instrucción para que sea al update-threshold 15 % y el enrutador descubre que el ancho de banda reservado en un vínculo ha cambiado en un 10 % del ancho de banda del vínculo, RSVP no activa una actualización de IGP. Sin embargo, si el ancho de banda reservado en un vínculo cambia en un 20 % del ancho de banda del vínculo, RSVP activa una actualización de IGP.
También puede configurar el umbral como un valor absoluto mediante la threshold-value opción en la update-threshold instrucción.
Si el valor del umbral se configura para más del 20 % del ancho de banda en ese vínculo, el valor del umbral se limita al 20 % del ancho de banda.
Por ejemplo, si el ancho de banda en una interfaz es de 1 Gbps y la threshold-value configuración es mayor que 200 Mbps, el threshold-value límite es de 200 Mbps. El threshold-percent se muestra como 20.000% y el threshold-value como 200 Mbps.
Las dos opciones, threshold-percent y threshold-value, son mutuamente excluyentes. Solo puede configurar una opción en un momento dado para generar una actualización de IGP para reservas de ancho de banda más bajas. Como resultado, cuando se configura una opción, la otra opción se calcula y se muestra en la CLI.
Por ejemplo, en un vínculo de 1 Gbps, si el threshold-percent está configurado al 5 %, el threshold-value se calcula y se muestra como 50 Mbps. De manera similar, si el threshold-value está configurado a 50 m, entonces el threshold-percent se calcula y se muestra como 5%.
Para ajustar el umbral en el que un cambio en el ancho de banda reservado desencadena una actualización de IGP, incluya la instrucción update-threshold . Debido al umbral de actualización, es posible que la ruta más corta restringida (CSPF) calcule una ruta mediante la información obsoleta de ancho de banda de la base de datos de ingeniería de tráfico en un vínculo. Si RSVP intenta establecer un LSP a través de esa ruta, es posible que encuentre que no hay 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 de IGP, lo que inunda la información actualizada de ancho de banda en la red. Luego, CSPF puede recompute la ruta mediante el uso de la información actualizada del ancho de banda e intentar encontrar una ruta diferente, evitando el congestionado vínculo. Tenga en cuenta que esta funcionalidad es la predeterminada y no necesita ninguna configuración adicional.
Puede configurar la rsvp-error-hold-time instrucción en el [edit protocols mpls] nivel de jerarquía o nivel de jerarquía para mejorar la [edit logical-systems logical-system-name protocols mpls] precisión de la base de datos de ingeniería de tráfico (incluida la precisión de las estimaciones de ancho de banda para LSP) mediante la información proporcionada por los mensajes de PathErr. Consulte Mejora de la precisión de la base de datos de ingeniería de tráfico con mensajes pathErr RSVP.
Configuración de RSVP para interfaces no numeradas
Junos OS admite la ingeniería de tráfico de RSVP a través de interfaces no numeradas. La información de ingeniería de tráfico de enlaces no numerados se lleva a cabo en las extensiones de ingeniería de tráfico de IGP para OSPF e IS-IS, tal como se describe en RFC 4203, Extensiones de OSPF en soporte de conmutación de etiquetas multiprotocolo generalizado (GMPLS) y RFC 4205, extensiones de sistema intermedio a sistema intermedio (IS-IS) en soporte de conmutación de etiquetas multiprotocolo (GMPLS) generalizada. Los vínculos no numerados también se pueden especificar en la señalización de ingeniería de tráfico de MPLS, tal como se describe en EL RFC 3477, Señalización de enlaces no numerados en el protocolo de reservación de recursos - ingeniería de tráfico (RSVP-TE). Esta función le permite evitar tener que configurar direcciones IP para cada interfaz que participe en la red señalizadas RSVP.
Para configurar RSVP para interfaces no numeradas, debe configurar el enrutador con un ID de enrutador mediante la router-id instrucción especificada en el [edit routing-options] nivel de jerarquía. El ID de enrutador debe estar disponible para el enrutamiento (normalmente puede usar la dirección de circuito cerrado). Los mensajes de control RSVP de los vínculos no numerados se envían mediante la dirección de ID del enrutador (en lugar de una dirección seleccionada aleatoriamente).
Para configurar la protección de vínculos y el reenrutamiento rápido en un enrutador con interfaces no numeradas habilitadas, debe configurar al menos dos direcciones. Recomendamos que configure una interfaz secundaria en el circuito cerrado, además de configurar el ID del enrutador.
Configurar saludos de ID de nodo RSVP
Puede configurar los saludos de RSVP basados en id de nodo para asegurarse de que los enrutadores de Juniper Networks puedan interoperar con el equipo de otros proveedores. De forma predeterminada, Junos OS usa saludos de RSVP basados en interfaz. Los saludos de RSVP basados en node-ID se especifican en RFC 4558, Protocolo de reserva de recursos basado en ID de nodos (RSVP) Hola: Una declaración de aclaración. Los saludos del ID de nodo RSVP son útiles si ha configurado el BFD para detectar problemas mediante interfaces RSVP, lo que le permite deshabilitar los saludos de interfaz para estas interfaces. También puede usar saludos de ID de nodo para procedimientos de reinicio agraciados.
Los saludos de NODE-ID se pueden habilitar globalmente para todos los vecinos RSVP. De forma predeterminada, el soporte hola id del nodo está deshabilitado. Si no ha habilitado los ID de nodo RSVP en el enrutador, Junos OS no acepta ningún paquete de saludo con ID de nodo.
A partir de la versión 16.1 Junos envía mensajes de saludo de RSVP a través de un LSP de omisión cuando uno está disponible. Consulte no-node-hello-on-bypass para obtener más información sobre cómo revertir al comportamiento histórico de enviar saludos durante el próximo salto del IGP.
Para habilitar los saludos de ID de nodo RSVP de forma global 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 las saludos de interfaz RSVP globalmente. Este tipo de configuración puede ser necesario en redes en las que el enrutador de Juniper Networks tiene numerosas conexiones RSVP con equipos de otros proveedores. Sin embargo, si deshabilita las saludos de interfaz RSVP globalmente, también puede configurar un intervalo de saludo en una interfaz RSVP mediante la instrucción hello-interval . Esta configuración deshabilita los saludos de interfaz RSVP globalmente, pero habilita los saludos de interfaz RSVP en la interfaz especificada (la interfaz RSVP en la que configure la hello-interval instrucción). Esta configuración puede ser necesaria en una red heterogénea en la que algunos dispositivos admiten saludos de ID de nodo RSVP y otros dispositivos admiten saludos de interfaz RSVP.
Para deshabilitar los saludos de interfaz RSVP globalmente en el enrutador, incluya la instrucción no-interfaz-hola en los siguientes niveles jerárquicos:
-
[edit protocols rsvp] -
[edit logical-systems logical-systems-name protocols rsvp]
Ejemplo: Configuración de LSP señalizadas por RSVP
En este ejemplo, se muestra cómo crear un LSP entre enrutadores de una red IP mediante RSVP como protocolo de señalización.
Requisitos
Antes de comenzar, elimine los servicios de seguridad del dispositivo. Vea el ejemplo: Eliminar servicios de seguridad.
Descripción general y topología
Con RSVP como protocolo de señalización, puede crear LSP entre enrutadores en una red IP. En este ejemplo, configure una red de ejemplo como se muestra en Figura 1.
Topología
Para establecer un LSP entre enrutadores, debe habilitar individualmente la familia MPLS y configurar RSVP en cada una de las interfaces de tránsito en la red MPLS. En este ejemplo, se muestra cómo habilitar MPLS y configurar RSVP en la interfaz de tránsito ge-0/0/0. Además, debe habilitar el proceso MPLS en todas las interfaces MPLS de la red.
En este ejemplo, se muestra cómo definir un LSP de R1 a R7 en el enrutador de entrada (R1) mediante la dirección de circuito cerrado de R7 (10.0.9.7). La configuración reserva 10 Mbps de ancho de banda. Además, la configuración deshabilita el algoritmo CSPF, lo que garantiza que los hosts C1 y C2 usen la LSP señal de RSVP que corresponde a la ruta más corta del IGP de la 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, luego, copie y pegue los comandos en la CLI en el [edit] nivel de jerarquía.
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
El siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración en la Guía del usuario de CLI.
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 de 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
Para confirmar la configuración, ingrese el comando desde el show modo de configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones de configuración en este ejemplo para corregirla.
Para mayor brevedad, el resultado de este show comando solo incluye la configuración relevante para este ejemplo. Cualquier otra configuración del sistema se ha reemplazado 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;
}
}
...
Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.
Verificación
Para confirmar que la configuración funciona correctamente, realice estas tareas:
- Verificar vecinos de RSVP
- Verificar sesiones de RSVP
- Verificar la presencia de LSP señalizadas por RSVP
Verificar vecinos de RSVP
Propósito
Compruebe que cada dispositivo muestra los vecinos RSVP adecuados; por ejemplo, el enrutador R1 en enumera tanto al Figura 1 enrutador R3 como al R2 como vecinos RSVP.
Acción
Desde la CLI, escriba el show rsvp neighbor comando.
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
El resultado muestra las direcciones IP de los enrutadores vecinos. Compruebe que se muestra la dirección de circuito cerrado de cada enrutador RSVP vecino.
Verificar sesiones de RSVP
Propósito
Compruebe que se ha establecido una sesión RSVP entre todos los vecinos de RSVP. Además, verifique que el valor de reserva de ancho de banda esté activo.
Acción
Desde la CLI, escriba el show rsvp session detail comando.
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, incluyendo los identificaciones de la sesión, la reserva de ancho de banda y las direcciones del próximo salto, para cada sesión RSVP establecida. Compruebe la siguiente información:
Cada dirección de vecino RSVP tiene una entrada para cada vecino, listada por dirección de circuito cerrado.
El estado de cada sesión LSP es Up.
Para Tspec, aparece el valor de ancho de banda adecuado, 10Mbps.
Verificar la presencia de LSP señalizadas por RSVP
Propósito
Compruebe que la tabla de enrutamiento del enrutador de entrada (entrada) tiene un LSP configurado para la dirección de circuito cerrado del otro enrutador. Por ejemplo, compruebe que la inet.3 tabla de enrutamiento del enrutador de entrada R1 en Figura 1 tiene un LSP configurado para la dirección de circuito cerrado del enrutador R7.
Acción
Desde la CLI, escriba el show route table inet.3 comando.
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 inet.3 enrutamiento. Verifique que un LSP señal de RSVP esté asociado con la dirección de circuito cerrado del enrutador de salida (salida) R7, en la red MPLS.
Ejemplo: Configuración de malla automática RSVP
Los proveedores de servicios a menudo usan VPN de BGP y MPLS para escalar la red de manera eficiente mientras ofrecen servicios que generan ingresos. En estos entornos, BGP se utiliza para distribuir la información de enrutamiento VPN a través de la red del proveedor de servicios, mientras que MPLS se utiliza para reenviar ese tráfico VPN de un sitio VPN a otro.
Al agregar un nuevo enrutador de PE que participará en VPN de BGP y MPLS, todos los enrutadores de PE existentes anteriormente deben configurarse para que se paren con el nuevo enrutador de PE tanto para BGP como para MPLS. A medida que se agrega cada enrutador pe nuevo a la red del proveedor de servicios, la carga de configuración pronto se vuelve demasiado para manejar.
Los requisitos de configuración para el emparejamiento de 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 rsvp-te configuración en todos los enrutadores de PE permite que RSVP cree automáticamente los LSP necesarios cuando se agrega un nuevo enrutador de PE.
Requisitos
En este ejemplo, se utilizan los siguientes componentes de hardware y software:
Un enrutador que ejecuta la versión 10.1 o posterior de Junos OS.
Una VPN de BGP y MPLS que usa RSVP como el protocolo de señalización de ruta conmutada por etiquetas (LSP) de MPLS.
Descripción general
En este ejemplo, se muestra cómo configurar la malla automática RSVP en un enrutador de PE mediante la rsvp-te instrucción de configuración. Para que la malla automática RSVP funcione correctamente, todos los enrutadores de PE en la configuración de malla completa deben tener la rsvp-te instrucción configurada. Esto garantiza que los enrutadores de PE nuevos que se agreguen más tarde también se beneficiarán de la función de malla automática, siempre que también estén configurados con la rsvp-te instrucción.
Dado este requisito, en este ejemplo solo se muestra la configuración en el enrutador de PE recién agregado. Se supone que la malla automática RSVP ya se configuró en los enrutadores de PE existentes.
Topología
En Figura 2, hay tres enrutadores de PE existentes, PE1, PE2 y PE3, en la topología. Se agregó 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:
Habilitación de la
rsvp-teinstrucción de configuración en el[edit routing-options dynamic-tunnels dynamic-tunnel-name]nivel de jerarquía.Configurar el elemento necesario
destination-networks.Este elemento de configuración especifica el rango de prefijo IPv4 para la red de destino. Solo se pueden crear túneles dentro del rango de prefijo especificado.
Configurar el elemento necesario
label-switched-path-template.Este elemento de configuración toma uno de los argumentos
default-templateo el nombre de una plantilla LSP preconfigurada como argumento. Esdefault-templateuna plantilla definida por el sistema que no requiere configuración de usuario.
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, luego, copie y pegue los comandos en la CLI en el [edit] nivel de jerarquía.
Enrutador PE4
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 malla automática RSVP
Procedimiento paso a paso
El siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener instrucciones sobre cómo hacerlo, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI.
Para habilitar la malla automática RSVP:
Configure
rsvp-teen el[edit routing-options dynamic-tunnels]nivel de jerarquía.[edit routing-options dynamic-tunnels] user@PE4# set dt-1 rsvp-te rsvp-te-1 label-switched-path-template default-template
Configure
destination-networksen el[edit routing-options dynamic-tunnels]nivel de jerarquía.[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 show comando desde el [edit routing-options dynamic-tunnels] nivel de jerarquía para ver los resultados de su configuración:
[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
- Verificar la existencia de túneles de malla automáticos RSVP en el enrutador PE4
- Verificar la existencia de LSP MPLS en el enrutador PE4
Verificar la existencia de túneles de malla automáticos RSVP en el enrutador PE4
Propósito
Para comprobar el funcionamiento del enrutador PE4 recién configurado, emita el comando desde el show dynamic-tunnels database modo operativo. Este comando mostrará la red de destino en la que se pueden crear túneles dinámicos.
Acción
user@PE4> show dynamic-tunnels database Table: inet.3 Destination-network: 192.0.2.0/24
Verificar la existencia de LSP MPLS en el enrutador PE4
Propósito
Para verificar la existencia de LSP MPLS en el enrutador PE4, emita el comando desde el show mpls lsp modo operativo. Este comando mostrará el estado de los LSP MPLS.
Acción
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
Configurar reconocimientos de saludo para vecinos de RSVP de no sesión
La hello-acknowledgements instrucción controla el comportamiento de reconocimiento de saludo entre los vecinos de RSVP independientemente de si están o no en la misma sesión.
Los mensajes de saludo recibidos de vecinos de RSVP que no forman parte de una sesión de RSVP común se descartan. Si configura la hello-acknowledgements instrucción en el [edit protocols rsvp] nivel de jerarquía, los mensajes de saludo de los vecinos que no están en sesión se reconocen con un mensaje de confirmación de saludo. Cuando se reciben saludos de los vecinos que no están en sesión, se crea una relación de vecino RSVP y ahora se pueden recibir mensajes periódicos de saludo del vecino que no está en sesión. La hello-acknowledgements instrucción está deshabilitada de forma predeterminada. La configuración de esta instrucción permite descubrir enrutadores compatibles con RSVP mediante paquetes hola y verifica que la interfaz pueda recibir paquetes RSVP antes de enviar cualquier mensaje de configuración de LSP MPLS.
Una vez que habilite los reconocimientos de saludo para los vecinos de RSVP de no sesión, el enrutador continúa reconociendo los mensajes de saludo de cualquier vecino RSVP de no sesión, a menos que la interfaz en sí falla o cambie la configuración. Los vecinos basados en interfaces no están automáticamente envejecidos.
hello-acknowledgements;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit protocols rsvp][edit logical-systems logical-system-name protocols rsvp]
Cambiar los LSP desde un nodo de red
Puede configurar el enrutador para que cambie los LSP activos lejos de un nodo de red mediante un LSP de omisión habilitado para una interfaz. Esta función se puede utilizar para mantener las redes activas cuando es necesario reemplazar un dispositivo 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 lejos de un nodo de red:
La función de distancia del conmutador solo se admite en enrutadores de la serie MX.
La función de conmutación fuera no es compatible con el tráfico de conmutación de LSP de punto a multipunto primario para omitir los LSP de punto a multipunto. Si configura la
switch-away-lspsinstrucción para un LSP de punto a multipunto, el tráfico no se conmuta a la LSP de omisión de punto a multipunto.Si configura la función de conmutación fuera 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 conmutación de distancia evita el comportamiento de marca antes de la interrupción de los LSP con señal de RSVP. El comportamiento de marca antes de la interrupción normalmente hace que el enrutador intente primero re-señalizar un LSP dinámico antes de derribar el original.
Configuración de la protección de instalación de RSVP
Puede configurar el mecanismo de reenrutamiento rápido de respaldo de la instalación para proporcionar protección de configuración para los LSP que están en proceso de señalización. Se admiten LSP de punto a punto y LSP de punto a multipunto. Esta característica se aplica 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 omisión que protege el vínculo o el nodo.
El RSVP envía señales al LSP a través del LSP de bypass. El LSP aparece como si se hubiera configurado originalmente a lo largo de su ruta principal y, luego, se produjo un error en el LSP de omisión debido al error del vínculo o del nodo.
Cuando el vínculo o nodo se ha recuperado, el LSP se puede revertir automáticamente a la ruta principal.
Debe configurar la setup-protection instrucción en el [edit protocols rsvp] en cada uno de los enrutadores a lo largo de la ruta LSP en la que desea habilitar la protección de configuración de LSP. También debe configurar la ingeniería de tráfico de IGP en todos los enrutadores de la ruta LSP. Puede emitir un show rsvp session comando para determinar si el LSP tiene o no habilitada la protección de configuración en un enrutador que actúa como un punto de reparación local (PLR) o como un punto de fusión.
Para habilitar la protección de configuración de RSVP, incluya la setup-protection instrucción
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 en los LSP de RSVP
De forma predeterminada, cuando haya configurado varios LSP RSVP en el mismo enrutador de salida, el LSP con la métrica más baja se selecciona 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.
Alternativamente, puede equilibrar el tráfico de carga en todos los LSP mediante la habilitación del equilibrio de carga por paquete.
Para habilitar el equilibrio de carga por paquete en un LSP de entrada, configure la instrucción de la policy-statement siguiente manera:
[edit policy-options] policy-statement policy-name { then { load-balance per-packet; } accept; }
A continuación, debe aplicar esta instrucción como política de exportación a la tabla de reenvío.
Una vez que se aplica el equilibrio de carga por paquete, el tráfico se distribuye por igual entre los LSP (de forma predeterminada).
Debe configurar el equilibrio de carga por paquete si desea habilitar el reenrutamiento rápido de PFE. Para habilitar el reenrutamiento rápido de PFE, incluya la instrucción para el policy-statement equilibrio de carga por paquete que se muestra en esta sección en la configuración de cada uno de los enrutadores en los que podría tener lugar un reenrutamiento. Consulte también Configurar el reenrutamiento rápido.
También puede equilibrar la carga del tráfico entre los LSP en proporción con 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étrica entre enlaces 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 de LSP RSVP, incluya la load-balance instrucción con la bandwidth opción:
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 load-balance instrucción:
Si configura la
load-balanceinstrucción, no se altera el comportamiento de los LSP que se ejecutan actualmente. Para obligar a los LSP en ejecución a usar el nuevo comportamiento, puede emitir unclear mpls lspcomando.La
load-balanceinstrucción solo se aplica a los LSP de entrada que tengan habilitado el equilibrio de carga por paquete.En el caso de los LSP diseñados para el tráfico consciente de los servicios diferenciados, el ancho de banda de un LSP se calcula sumando el ancho de banda de todos los tipos de clase.
Configuración de malla automática RSVP
Puede configurar RSVP para establecer rutas conmutadas por etiquetas (LSP) de punto a punto de forma automática para cualquier enrutador de PE nuevo agregado a una malla completa de LSP. Para habilitar esta función, debe configurar la rsvp-te instrucción en todos los enrutadores de PE en la malla completa.
No puede configurar la malla automática RSVP junto con CCC. CCC no puede usar los LSP generados dinámicamente.
Para configurar la malla automática RSVP, incluya la rsvp-te instrucción:
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 siguientes instrucciones para habilitar la malla automática RSVP:
destination-networks— Especifique el intervalo de prefijos IP versión 4 (IPv4) para la red de destino. Se pueden iniciar túneles dinámicos dentro del rango de prefijo IPv4 especificado.label-switched-path-template (Multicast)— Puede configurar la plantilla predeterminada explícitamente mediante ladefault-templateopción o puede configurar una plantilla LSP propia mediante latemplate-nameopción. La plantilla LSP actúa como una configuración de modelo para los LSP generados dinámicamente.
Configuración de temporizadores para mensajes de actualización RSVP
RSVP utiliza dos parámetros de tiempo 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 larefresh-timeinstrucción de 30, multiplicado por un valor fijo de 1,5. Este cálculo difiere del 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 la ruta y los mensajes de Resv. Los mensajes de actualización se envían periódicamente para que los estados de reserva en los nodos vecinos no esperen tiempo. Cada ruta y mensaje de Resv lleva el valor del temporizador de actualización, y el nodo receptor extrae este valor de los mensajes.
keep-multiplier— El multiplicador de mantención es un entero pequeño y configurado localmente del 1 al 255. El valor predeterminado es 3. Indica la cantidad de mensajes que se pueden perder antes de que un estado determinado se declare obsoleto y debe eliminarse. El multiplicador de mantención afecta directamente a la vida útil de un estado RSVP.
Para determinar la duración de un estado de reserva, utilice la siguiente fórmula:
lifetime = (keep-multiplier + 0.5) x (1.5 x refresh-time)
En el peor de los casos, (keep-multiplier – 1) se deben perder mensajes de actualización sucesivos antes de eliminar el estado de la reserva.
No recomendamos configurar un temporizador de saludo RSVP corto. Si es necesario descubrir rápidamente un vecino fallido, configure los temporizadores de saludo de IGP cortos (OSPF o IS-IS).
De forma predeterminada, el valor del temporizador de actualización es de 30 segundos. Para modificar este valor, incluya la refresh-time instrucción:
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 mantención es 3. Para modificar este valor, incluya la keep-multiplier instrucción:
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]
Adelantarse a las sesiones de RSVP
Siempre que el ancho de banda no sea suficiente para manejar todas las sesiones de RSVP, puede controlar la preferencia de las sesiones de RSVP. De forma predeterminada, una sesión RSVP solo se antepone a una nueva sesión de mayor prioridad.
Para adelantar siempre una sesión cuando el ancho de banda no es suficiente, incluya la preemption instrucción con la aggressive opción:
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 preemption instrucción con la disabled opción:
preemption disabled;
Para volver al valor predeterminado (es decir, anteponer una sesión solo para una nueva sesión de mayor prioridad), incluya la preemption instrucción con la normal opción:
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 de 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 que se encapsulan en MPLS. También debe configurar la señalización de MTU en RSVP. Para solucionar problemas, puede configurar la señalización de MTU sola sin habilitar la fragmentación de paquetes.
Para configurar la señalización de MTU en RSVP, incluya la path-mtu instrucción:
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]
Las siguientes secciones describen cómo habilitar la fragmentación de paquetes y la señalización de MTU en RSVP:
Habilitación de la señalización de MTU en RSVP
Para habilitar la señalización de MTU en RSVP, incluya la rsvp mtu-signaling instrucción:
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 tendrán efecto la próxima vez que se actualice la ruta.
Puede configurar la mtu-signaling instrucción por sí misma en el [edit protocols mpls path-mtu rsvp] nivel de jerarquía. Esto puede ser útil para la resolución de problemas. Si configura solo la mtu-signaling instrucción, puede usar el show rsvp session detail comando para determinar cuál es la MTU más pequeña en un LSP. El show rsvp session detail comando muestra el valor de MTU recibido y enviado en el objeto Adspec.
Habilitación de la fragmentación de paquetes
Para permitir que los paquetes IP se fragmenten antes de encapsularse en MPLS, incluya la allow-fragmentation instrucción:
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
allow-fragmentationinstrucción solo. Configure siempre junto con lamtu-signalinginstrucción.
Configuración del ultimate-hop popping para LSP
De forma predeterminada, los LSP con señal de RSVP usan un salto de penúltimo salto (PHP). Figura 3 muestra un LSP emergente 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 empuja 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, intercambiando la etiqueta 1 por la etiqueta 2, y reenvía el paquete al enrutador P2. Dado que el enrutador P2 es el penúltimo enrutador de salto para el LSP al enrutador PE2, primero extrae la etiqueta y luego reenvía el paquete al enrutador PE2. Cuando el enrutador PE2 lo recibe, el paquete puede tener una etiqueta de servicio, una etiqueta explicit-null o simplemente ser un paquete IP o VPLS sin formato. El enrutador PE2 reenvía el paquete sin etiqueta al enrutador CE2.
También puede configurar el salto final (UHP) (como se muestra en Figura 4) para los LSP señalados por RSVP. Algunas aplicaciones de red pueden requerir que los paquetes lleguen al enrutador de salida (enrutador PE2) con una etiqueta externa no null. Para un LSP de salto final, el penúltimo enrutador (enrutador P2 en Figura 4) realiza la operación estándar de intercambio de etiquetas MPLS (en este ejemplo, etiqueta 2 por etiqueta 3 ) antes de reenviar el paquete al enrutador de salida PE2. El ENRUTADOR PE2 abre la etiqueta externa y realiza una segunda búsqueda de la dirección del paquete para determinar el destino final. Luego, reenvía el paquete al destino adecuado (ya sea el enrutador CE2 o el enrutador CE4).
Las siguientes aplicaciones de red requieren que configure LSP UHP:
MPLS-TP para monitoreo de rendimiento y OAM en banda
Circuitos virtuales de protección de borde
Las siguientes funciones no admiten el comportamiento de UHP:
LSP señalizadas por LDP
LSP estáticos
LSP de punto a multipunto
CCC
tracerouteComando
Para obtener más información acerca del comportamiento de la UHP, consulte Draft de Internet draft-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt, Comportamiento no PHP y asignación fuera de banda para LSP RSVP-TE.
Para los LSP señalizadas de punto a punto por RSVP, 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 al LSP UHP con el conjunto de marca que no es PHP. Los mensajes DE RUTA RSVP llevan los dos indicadores en el objeto LSP-ATTRIBUTES. Cuando el enrutador de salida recibe el mensaje PATH, asigna una etiqueta no null al LSP. RSVP también crea e instala dos rutas en la tabla de enrutamiento mpls.0. S hace referencia a la bit S de la etiqueta MPLS, que indica si se alcanzó 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 de esta ruta apunta a la tabla de enrutamiento mpls.0, lo que activa una búsqueda de etiquetas MPLS encadenada para descubrir las etiquetas MPLS restantes en la pila.
Ruta S=1: indica que ya no hay etiquetas. El siguiente salto apunta a la tabla de enrutamiento inet.0 si la plataforma admite búsqueda encadenada y multifamiliar. Alternativamente, la ruta de la etiqueta puede apuntar a una interfaz VT para iniciar el reenvío de IP.
Si habilita LSP UHP, las aplicaciones MPLS, como VPN de capa 3, VPLS, VPN de capa 2 y circuitos de capa 2 pueden usar los LSP UHP. A continuación se explica cómo los LSP de UHP afectan a los diferentes tipos de aplicaciones MPLS:
VPN de capa 2 y circuitos de capa 2: un paquete llega al enrutador de PE (salida del LSP UHP) con dos etiquetas. La etiqueta externa (S=0) es la etiqueta UHP, y la etiqueta interna (S=1) es la etiqueta VC . Una búsqueda basada en la etiqueta de transporte da como resultado un controlador 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 de PE (salida del LSP UHP) con dos etiquetas. La etiqueta externa (S=0) es la etiqueta UHP y la etiqueta interna es la etiqueta vpn (S=1). Una búsqueda basada en la etiqueta de transporte da como resultado el controlador de la tabla de enrutamiento mpls.0. Hay dos casos en esta situación. 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 configuró la instrucción para la
vrf-table-labelinstancia de enrutamiento VPN de capa 3, la etiqueta LSI interna apunta a la tabla de enrutamiento VRF. También se completa una búsqueda de IP para la tabla de enrutamiento VRF.Nota:El UHP para VPN de capa 3 configuradas con la
vrf-table-labelinstrucción solo se admite en plataformas de enrutamiento universal 5G serie MX.VPLS: un paquete llega al enrutador de PE (salida del LSP UHP) con dos etiquetas. La etiqueta externa es la etiqueta de transporte (S=0) y la etiqueta interna es la etiqueta VPLS (S=1). Una búsqueda basada en la etiqueta de transporte da como resultado el controlador de 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 los servicios de túnel no están configurados (o una interfaz VT no disponible). Los enrutadores de la serie MX 3D admiten búsqueda encadenada y búsqueda multifamiliar.
Nota:El UHP para VPLS configurado con la
no-tunnel-serviceinstrucción solo se admite en enrutadores serie MX 3D.IPv4 a través de MPLS: un paquete llega al enrutador de PE (salida del LSP UHP) con una etiqueta (S=1). Una búsqueda basada en esta etiqueta devuelve una interfaz de túnel VT. Se completa otra búsqueda de IP en la interfaz de VT para determinar dónde reenviar el paquete. Si la plataforma de enrutamiento admite búsquedas en cadena y varias familias (por ejemplo, enrutadores MX 3D y enrutadores de transporte de paquetes serie PTX), la búsqueda basada en la ruta de etiquetas (S=1) apunta a la tabla de enrutamiento inet.0.
IPv6 a través de 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 null explícita para IPv6. Como resultado, los próximos saltos de reenvío para rutas IPv6 que se aprenden de enrutadores de PE remotos normalmente insertan dos etiquetas. La etiqueta interna es 2 (podría ser diferente si el enrutador de PE publicitario es de otro proveedor) y la etiqueta del enrutador es la etiqueta LSP. Los paquetes llegan al enrutador pe (salida del LSP UHP) con dos etiquetas. La etiqueta externa es la etiqueta de transporte (S=0) y la etiqueta interna es la etiqueta explicit-null IPv6 (etiqueta 2). La búsqueda basada en la etiqueta interna de la tabla de enrutamiento mpls.0 redirige de nuevo a la tabla de enrutamiento mpls.0. En los enrutadores serie MX 3D, se elimina la etiqueta interna (etiqueta 2) 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 php y UHP a través de las mismas rutas de red. Puede separar el tráfico de PHP y UHP seleccionando reenvío de próximos saltos de LSP mediante una expresión regular con la
install-nexthopinstrucción. También puede separar el tráfico simplemente nombrando los LSP de manera adecuada.
Las siguientes instrucciones permiten el salto final para un LSP. Puede habilitar esta función en un LSP específico o para todos los LSP de entrada configurados en el enrutador. Configure estas instrucciones en el enrutador en la entrada de LSP.
Configuración de RSVP para abrir la etiqueta en el enrutador Ultimate-Hop
Puede controlar el valor de etiqueta anunciado en el enrutador de salida de un LSP. La etiqueta anunciada por defecto es la etiqueta 3 (etiqueta Null implícita). Si se anuncia la etiqueta 3, el enrutador de penúltimo salto elimina la etiqueta y envía el paquete al enrutador de salida. Cuando se habilite el popping de último salto, se anuncia la etiqueta 0 (IP versión 4 [IPv4] Etiqueta Explicit Null). El salto final garantiza que cualquier paquete que atraviesa una red MPLS incluya una etiqueta.
Los enrutadores de Juniper Networks hacen colas de paquetes basados en la etiqueta entrante. Los enrutadores de otros proveedores pueden poner en cola los paquetes de manera diferente. Tenga esto en cuenta cuando trabaje con redes que contengan enrutadores de varios proveedores.
Para configurar el popping de último salto para RSVP, incluya la explicit-null instrucción:
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 salto final en LSP de punto a multipunto
De forma predeterminada, tanto para los LSP de punto a punto como para los de punto a multipunto, el penúltimo salto se utiliza para el tráfico de MPLS. Las etiquetas MPLS se eliminan de los paquetes del enrutador justo antes del enrutador de salida del LSP. Luego, los paquetes IP simples se reenvían al enrutador de salida. Para el estallido de máxima esperanza, el enrutador de salida es responsable de eliminar la etiqueta MPLS y procesar el paquete IP sin formato.
Puede ser beneficioso habilitar el salto final en los LSP de punto a multipunto, particularmente cuando el tráfico de tránsito atraviesa el mismo dispositivo de salida. Si habilita el salto final, 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 salto final está deshabilitado.
Mediante la configuración de la tunnel-services instrucción, puede activar el salto final para los LSP de punto a multipunto. Cuando habilita el popping de salto final, Junos OS selecciona una de las interfaces disponibles del túnel de circuito cerrado virtual (VT) para devolver los paquetes al PFE para el reenvío de IP. De forma predeterminada, el proceso de selección de interfaz VT se realiza automáticamente. El control de admisión de ancho de banda se utiliza para limitar la cantidad de LSP que se pueden usar en una interfaz VT. Una vez que se consume 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 popping de último salto y, en su lugar, se habilita el penúltimo salto.
Para que los LSP de punto a multipunto funcionen correctamente, el enrutador de salida debe tener una PIC que proporcione servicios de túnel, como la PIC de servicios de túnel o la PIC de servicios adaptables. Los servicios de túnel son necesarios para hacer aparecer la etiqueta final de MPLS y para devolver paquetes para las búsquedas de direcciones IP.
Puede configurar explícitamente qué interfaces VT manejan el tráfico RSVP incluyendo la devices opción de la tunnel-services instrucción. La devices opción le permite especificar qué interfaces VT deben usar RSVP. Si no configura esta opción, se pueden usar todas las interfaces VT disponibles para el enrutador.
Para habilitar el popping de último salto para los LSP de punto a multipunto de salida en un enrutador, configure la tunnel-services instrucción:
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 popping de último salto para LSP de punto a multipunto de salida, también debe configurar la instrucción con la interfaceall opción:
interface all;
Debe configurar esta instrucción en el [edit protocols rsvp] nivel de jerarquía.
Rastreo de tráfico de protocolo RSVP
Para rastrear el tráfico de protocolo RSVP, incluya la traceoptions instrucción:
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 las siguientes marcas específicas de RSVP en la instrucción RSVP traceoptions :
Utilice la file instrucción para especificar el nombre del archivo que recibe el resultado de la operación de seguimiento. Todos los archivos se colocan en el directorio /var/log. Recomendamos que coloque la salida de seguimiento RSVP en el archivo rsvp-log.
all: todas las operaciones de rastreo.error— Todas las condiciones de error detectadasevent—Eventos relacionados con RSVP (ayuda a rastrear eventos relacionados con el reinicio agraciado de RSVP)lmp—Interacciones del protocolo de administración de vínculos RSVP (LMP)packets— Todos los paquetes RSVPpath— Todos los mensajes de rutapathtear—Mensajes PathTearresv—Mensajes de Resvresvtear—Mensajes de ResvTearroute—Información de enrutamientostate— Transiciones de estado de sesión, incluso cuando los LSP con señal de RSVP suban y bajan.
Utilice el all indicador de seguimiento y el detail modificador de marca con precaución, ya que esto podría causar que la CPU se vuelva muy ocupada.
Para ver el archivo de registro generado al habilitar las operaciones de seguimiento de RSVP, emita el show log file-name comando, donde file-name está el archivo que especificó mediante la traceoptions instrucción.
Para obtener información general acerca del rastreo y las opciones de rastreo global, consulte la biblioteca de protocolos de enrutamiento de Junos OS para dispositivos de enrutamiento.
Ejemplos: Rastreo de tráfico de 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;
}
}
}
Rastreo de transiciones de estado de RSVP:
[edit]
protocols {
rsvp {
traceoptions {
file rsvp-data;
flag state;
}
}
}
Salida del archivo de registro RSVP
El siguiente es un resultado de ejemplo que se genera al emitir el show log file-name comando en un enrutador en el que se han habilitado las operaciones de seguimiento de RSVP con la state marca configurada. El LSP E-D señal de RSVP se muestra siendo derribado el 11 de mar 14:04:36.707092. El 11 de marzo, 14:05:30.101492, se muestra que vuelve 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 elegante
El reinicio agraciado del RSVP permite que un enrutador en proceso de reinicio informe a sus vecinos adyacentes de su estado. 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 de reinicio aún puede reenviar tráfico MPLS durante el período de reinicio; la convergencia en la red no se interrumpe. El reinicio no es visible para el resto de la red y el enrutador de reinicio no se quita de la topología de red. El reinicio agraciado del RSVP se puede habilitar tanto en enrutadores de tránsito como en enrutadores de entrada. Está disponible tanto para LSP de punto a punto como para LSP de punto a multipunto.
El reinicio agraciado del RSVP se describe en las siguientes secciones:
Terminología de reinicio agraciado del RSVP
Tiempo de reinicio (en milisegundos)
El valor predeterminado es 60 000 milisegundos (1 minuto). El tiempo de reinicio se anuncia en el mensaje de saludo. El tiempo indica cuánto tiempo debe esperar un vecino para recibir un mensaje de saludo de un enrutador que reinicia antes de declarar que el enrutador está muerto y está purgando.
Junos OS puede anular el tiempo de reinicio anunciado por un vecino si el tiempo es mayor que 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 está reiniciando. Si el tiempo de reinicio es cero, el vecino que está reiniciando puede declararse muerto de inmediato.
Tiempo de recuperación (en milisegundos)
Solo se aplica cuando el canal de control está activo (el intercambio de saludo está completo) antes de la hora de reinicio. Se aplica solo a errores nodales.
Cuando un reinicio agraciado está en curso, se anuncia el tiempo que falta para completar una recuperación. En otras ocasiones, este valor es cero. El tiempo de recuperación máximo 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 agraciado se completó después de su tiempo de recuperación anunciado.
RSVP operación de reinicio elegante
Para que el reinicio agraciado del RSVP funcione, la función debe estar habilitada en la instancia de enrutamiento global. El reinicio agraciado del RSVP se puede deshabilitar a nivel de protocolo (solo para RSVP) o a nivel global para todos los protocolos.
El reinicio agraciado de RSVP requiere lo siguiente de un enrutador que se reinicia y los vecinos del enrutador:
Para el enrutador de reinicio, RSVP intenta mantener las rutas instaladas por RSVP y las etiquetas asignadas, de modo que el tráfico continúe reenviado sin interrupciones. El reinicio agraciado del RSVP se realiza lo suficientemente rápido como para reducir o eliminar el impacto en los nodos vecinos.
Los enrutadores vecinos deben tener habilitado el modo de asistente de reinicio agraciado RSVP, lo que les permite asistir a un enrutador que intenta reiniciar RSVP.
Un objeto llamado 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 cayese.
A continuación, se enumeran los comportamientos de reinicio agraciado del RSVP, que varían según la configuración y en qué características están habilitadas:
Si deshabilita el modo de ayuda, Junos OS no intenta ayudar a un vecino a reiniciar el RSVP. Cualquier información que llegue con un objeto Restart Cap de un vecino se ignora.
Cuando habilite el reinicio agraciado bajo la configuración de la instancia de enrutamiento, el enrutador puede reiniciar con elegancia con la ayuda de sus vecinos. RSVP anuncia un objeto Restart Cap (RSVP RESTART) en mensajes de saludo en los que se especifican los tiempos de reinicio y recuperación (ninguno de los valores es 0).
Si deshabilita explícitamente el reinicio agraciado RSVP en el
[protocols rsvp]nivel de jerarquía, el objeto Restart Cap se anuncia con tiempos de reinicio y recuperación especificados como 0. Se admite el reinicio de enrutadores vecinos (a menos que el modo auxiliar esté deshabilitado), pero el enrutador no conserva el estado de reenvío RSVP y no puede recuperar su estado de control.Si después de un reinicio RSVP se da cuenta de que no se ha preservado 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 agraciado y el modo de ayuda están deshabilitados, el reinicio agraciado RSVP está completamente deshabilitado. El enrutador no reconoce ni anuncia los objetos de reinicio agraciado 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 haya completado un procedimiento de reinicio, aparte de un tiempo de espera fijo. Todos los procedimientos de reinicio agraciado de RSVP están basados en temporizadores. Un show rsvp version comando puede indicar que el reinicio sigue en curso, incluso si se copia de seguridad de todas las sesiones RSVP y se restauran las rutas.
Procesamiento del objeto de límite de reinicio
Las siguientes suposiciones se realizan sobre un vecino según el objeto Restart Cap (suponiendo que una falla de canal de control se puede distinguir sin ambigüedad de un reinicio de nodos):
Un vecino que no anuncie 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 Agraciado RSVP.
Después de un reinicio, un vecino que anuncie un objeto Restart Cap con un tiempo de reinicio igual a cualquier valor y un tiempo de recuperación igual a 0 no ha preservado 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 anuncie su tiempo de recuperación con un valor distinto a 0 puede mantener o ha mantenido el estado de reenvío. Si el enrutador local ayuda a su vecino con procedimientos de reinicio o recuperación, envía un objeto Recover Label a este vecino.
Configuración de RSVP de reinicio elegante
Son posibles las siguientes configuraciones de reinicio agraciado de RSVP:
El reinicio agraciado y el modo de ayuda están habilitados (el valor predeterminado).
El reinicio agraciado está habilitado, pero el modo auxiliar está deshabilitado. Un enrutador configurado de esta manera puede reiniciarse con elegancia, pero no puede ayudar a un vecino con sus procedimientos de reinicio y recuperación.
El reinicio agraciado está deshabilitado, pero el modo auxiliar está habilitado. Un enrutador configurado de esta manera no puede reiniciarse con elegancia, pero puede ayudar a un vecino que está reiniciando.
El reinicio agraciado y el modo de ayuda están deshabilitados. Esta configuración deshabilita completamente el reinicio agraciado del RSVP (incluidos los procedimientos de reinicio y recuperación y el modo auxiliar). El enrutador se comporta como un enrutador que no admite un reinicio agraciado RSVP.
Para activar el reinicio Agraciado RSVP, debe establecer el temporizador global de reinicio agraciado en al menos 180 segundos.
En las siguientes secciones se describe cómo configurar el reinicio agraciado de RSVP:
- Permitir un reinicio elegante para todos los protocolos de enrutamiento
- Deshabilitar el reinicio agraciado para RSVP
- Deshabilitar el modo de ayuda de RSVP
- Configuración del tiempo máximo de recuperación del ayudante
- Configuración del tiempo máximo de reinicio del ayudante
Permitir un reinicio elegante para todos los protocolos de enrutamiento
Para habilitar el reinicio agraciado para RSVP, debe habilitar el reinicio agraciado para todos los protocolos que admiten un reinicio agraciado en el enrutador. Para obtener más información acerca del reinicio agraciado, consulte la biblioteca de protocolos de enrutamiento de Junos OS para dispositivos de enrutamiento.
Para habilitar el reinicio agraciado en el enrutador, incluya la graceful-restart instrucción:
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 agraciado para RSVP
De forma predeterminada, el reinicio agraciado de RSVP y el modo de ayuda de RSVP se activan cuando se habilita el reinicio agraciado. Sin embargo, puede deshabilitar una de estas capacidades o ambas.
Para deshabilitar el reinicio y la recuperación agraciados de RSVP, incluya la disable instrucción en el [edit protocols rsvp graceful-restart] nivel jerárquico:
disable;
Deshabilitar el modo de ayuda de RSVP
Para deshabilitar el modo de ayuda RSVP, incluya la helper-disable instrucción en el [edit protocols rsvp graceful-restart] nivel jerárquico:
helper-disable;
Configuración del tiempo máximo de recuperación del ayudante
Para configurar la cantidad de tiempo que el enrutador conserva el estado de sus vecinos RSVP mientras se someten a un reinicio agraciado, incluya la maximum-helper-recovery-time instrucción en el [edit protocols rsvp graceful-restart] nivel de jerarquía. Este valor se aplica a todos los enrutadores vecinos, por lo que debe basarse en el tiempo que requiere el vecino RSVP más lento para recuperarse.
maximum-helper-recovery-time seconds;
Configuración del tiempo máximo de reinicio del ayudante
Para configurar el retraso entre cuando el enrutador descubra que un enrutador vecino se ha caído y cuando lo declare vecino, incluya la maximum-helper-restart-time instrucción en el [edit protocols rsvp graceful-restart] nivel de jerarquía. Este valor se aplica a todos los enrutadores vecinos, por lo que debe basarse en el tiempo que requiere el vecino RSVP más lento para reiniciar.
maximum-helper-restart-time seconds;
Descripción general de túneles LSP RSVP
Un túnel de ruta conmutada por etiquetas (LSP) del Protocolo de reserva de recursos (RSVP) le permite enviar LSP RSVP dentro de otros LSP RSVP. Esto permite que un administrador de red proporcione ingeniería de tráfico de un extremo a otro de la red. Una aplicación útil para esta función es conectar los enrutadores de borde del cliente (CE) con enrutadores de borde de proveedor (PE) mediante el uso de un LSP RSVP y, luego, túnel de 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 MPLS y conceptos de conmutación de etiquetas. Para obtener más información acerca de MPLS, consulte la Guía de configuración de aplicaciones de Junos MPLS.
Un túnel LSP RSVP agrega el concepto de adyacencia de reenvío, similar al utilizado para la conmutación de etiquetas multiprotocolo generalizado (GMPLS). (Para obtener más información acerca de GMPLS, consulte la Guía del usuario de Junos GMPLS.
La adyacencia de reenvío crea una ruta de túnel para enviar datos entre dispositivos pares en una red LSP RSVP. Una vez que se ha establecido un LSP de adyacencia de reenvío (FA-LSP), se pueden enviar otros LSP a través de FA-LSP mediante el uso de la ruta más corta restringida primero (CSPF), el Protocolo de administración de vínculos (LMP), la ruta abierta más corta primero (OSPF) y la RSVP.
Para habilitar un túnel LSP RSVP, Junos OS utiliza los siguientes mecanismos:
LMP: diseñado originalmente para GMPLS, la LMP establece adyacencias de reenvío entre los pares de túnel LSP RSVP, y mantiene y asigna recursos para vínculos de ingeniería de tráfico.
Extensiones de OSPF: el OSPF se diseñó para enrutar paquetes a interfaces físicas y lógicas relacionadas con una tarjeta de interfaz física (PIC). Este protocolo se ha extendido a enrutar paquetes a interfaces par virtuales definidas en una configuración LMP.
Extensiones RSVP-TE: RSVP-TE se diseñó para indicar la configuración de LSP de paquetes a interfaces físicas. El protocolo se ha extendido para solicitar la configuración de ruta de los LSP de paquetes que viajan a interfaces par virtuales definidas en una configuración de LMP.
Nota:A partir de Junos OS versión 15.1, la compatibilidad con varias instancias se extiende al RSVP-TE de MPLS. Esta compatibilidad solo está disponible para el tipo de instancia de enrutador virtual. Un enrutador puede crear y participar en varias particiones de topología de TE independientes, lo que permite que cada dominio de TE particionado escala de forma independiente. El RSVP-TE de varias instancias ofrece la flexibilidad para elegir manualmente las entidades del plano de control que deben ser conscientes de la instancia; por ejemplo, un enrutador puede participar en varias instancias de TE mientras se ejecuta una sola instancia de BGP.
La implementación de Junos OS de MPLS RSVP-TE se escala para mejorar la usabilidad, la visibilidad, la configuración y la resolución de problemas de LSP en la versión 16.1 de Junos OS.
Estas mejoras facilitan la configuración de RSVP-TE a escala de la siguiente manera:
Garantizar la preparación del plano de datos de LSP durante la renuncia de LSP antes de que el tráfico atraviese el LSP con el mecanismo de auto ping de LSP RSVP-TE.
Un LSP no debe comenzar a transportar tráfico a menos que se sepa que se ha programado en el plano de datos. El intercambio de datos en el plano de datos LSP, como las solicitudes de ping de LSP, ocurre en el enrutador de entrada antes de cambiar el tráfico a un LSP o a su instancia MBB. En redes grandes, este tráfico puede abrumar a un enrutador de salida de LSP, ya que el LSP de salida debe responder a las solicitudes de ping de LSP. El mecanismo de auto ping LSP permite que el LER de entrada cree mensajes de respuesta de ping de 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 viva voz del plano de datos LSP. Esto garantiza que el LSP no comience a transportar tráfico antes de que se programe el plano de datos.
Eliminación del límite actual de LSP de 64K en un enrutador de entrada y escalabilidad del número total de LSP con LSP señalizadas RSVP-TE. Puede haber hasta 64K 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 la caída abrupta de LSP por el enrutador de entrada debido al retraso en la señalización del LSP en los enrutadores de tránsito.
Habilitación de 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 auto ping.
Existen las siguientes limitaciones para las jerarquías de LSP:
No se admiten LSP basados en conexiones cruzadas de circuito (CCC).
No se admite el reinicio agraciado.
La protección de vínculo no está disponible para LOSP FA-LSP ni en el punto de salida de la adyacencia de reenvío.
Los LSP de punto a multipunto no se admiten en los FA-LSP.
Ejemplo: Configuración del túnel LSP RSVP
Figura 5 muestra un LSP RSVP de extremo a extremo llamado e2e_lsp_r0r5 que se origina en el enrutador 0 y termina en el enrutador 5. En tránsito, este LSP atraviesa el FA-LSP fa_lsp_r1r4. La ruta de retorno está representada por el LSP e2e_lsp_r5r0 RSVP de extremo a extremo que viaja por el FA-LSP fa_lsp_r4r1.
En el enrutador 0, configure el LSP RSVP de extremo a extremo que viaje al enrutador 5. Utilice una ruta estricta que atraviese el enrutador 1 y el vínculo de ingeniería de tráfico de LMP que viaja del enrutador 1 al 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 de LMP y una relación de par de LMP con el enrutador 4. Consulte el FA-LSP en el vínculo de ingeniería de tráfico y agregue la interfaz par en OSPF y RSVP.
Cuando la ruta de retorno de extremo a extremo LSP llega al enrutador 1, la plataforma de enrutamiento realiza una búsqueda de enrutamiento y puede reenviar el tráfico al enrutador 0. Asegúrese de configurar 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 central.
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 central.
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 de LMP y una relación de par de LMP con el enrutador 1. Consulte el FA-LSP en el vínculo de ingeniería de tráfico y agregue la interfaz par en OSPF y RSVP.
Cuando el LSP inicial de extremo a extremo llega al enrutador 4, la plataforma de enrutamiento realiza una búsqueda de enrutamiento y puede reenviar tráfico al enrutador 5. Asegúrese de configurar OSPF correctamente entre el enrutador 4 y el enrutador 5.
Enrutador 4
[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 de extremo a extremo RSVP LSP que viaja al enrutador 0. Utilice una ruta estricta que atraviese el enrutador 4 y el vínculo de ingeniería de tráfico de 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;
}
}
}
Verificar su trabajo
Para comprobar que el túnel LSP RSVP 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 (10.255.41.216) y el enrutador 4 (10.255.41.217) que hacen referencia a las direcciones de vínculo de ingeniería de tráfico LMP de 172.16.30.1 y 172.16.30.2. También puede emitir el show rsvp session extensive comando para buscar la ruta del LSP de extremo a extremo a medida que viaja al enrutador 5 a través de la FA-LSP.
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, verifique que la configuración del vínculo de ingeniería de tráfico de la LMP funciona y que el LSP de extremo a extremo atraviesa el vínculo de ingeniería de tráfico mediante la emisión del show link-management conjunto de comandos. También puede emitir el show rsvp session extensive comando para confirmar que el FA-LSP está operativo.
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 de 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 peer peer-name instrucción en el [edit protocols link-management] nivel de jerarquía. Un par es el dispositivo de red con el que su plataforma de enrutamiento se comunica y establece un FA-LSP. Designe un nombre de par, configure el ID del enrutador del 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 habilitar 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 produce 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.
}
}
}
Configurar vínculos de ingeniería de tráfico del protocolo de administración de vínculos
Para comenzar la configuración del túnel LSP RSVP, configure los vínculos de ingeniería de tráfico de 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 par, debe configurar vínculos de ingeniería de tráfico en ambas direcciones entre pares para permitir el transporte bidireccional de paquetes.
Para configurar vínculos de ingeniería de tráfico en LMP, incluya la te-link te-link-name instrucción en el nivel de jerarquía [edit protocols link-management]. Defina las opciones de vínculo de ingeniería de tráfico que se muestran a continuación, especialmente la ruta conmutada por etiquetas que se utilizará como FA-LSP para llegar al par. De forma opcional, 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 par en OSPF y RSVP
Después de establecer pares de LMP, debe agregar interfaces de par a OSPF y RSVP. Una interfaz par es una interfaz virtual que se utiliza para admitir la adyacencia de control entre dos pares.
El nombre de interfaz del par debe coincidir con la peer peer-name instrucción configurada en LMP en el [edit protocols link-management] nivel jerárquico. Dado que las interfaces par envían y reciben paquetes de protocolo reales, las interfaces de pares 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 de LMP, incluya la peer-interface instrucción en el [edit protocols ospf area area-number] nivel jerárquico. Para configurar la señalización RSVP para los pares de LMP, incluya la peer-interface instrucción en el [edit protocols rsvp] nivel de jerarquía.
[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 la FA-LSP
A continuación, defina su FA-LSP incluyendo la label-switched-path instrucción en el [edit protocols mpls] nivel de jerarquía. Incluya el ID de enrutador del par en la to instrucción en el [edit protocols mpls label-switched-path] nivel de jerarquía. Dado que los LSP de paquetes son unidireccionales, debe crear un FA-LSP para llegar al par y un segundo FA-LSP para devolver del 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.
}
}
}
Establecer información de ruta FA-LSP
Cuando configure rutas LSP explícitas para una FA-LSP, debe usar la dirección remota del vínculo de ingeniería de tráfico como dirección del siguiente salto. Cuando se admite CSPF, puede usar cualquier opción de ruta que desee. Sin embargo, cuando CSPF se deshabilita con la no-cspf instrucción en el [edit protocols mpls label-switched-path lsp-name] nivel de jerarquía, debe usar rutas estrictas.
[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 LSP de RSVP con gracia
Puede derribar un LSP RSVP en un proceso de dos pasos que retire con gracia la sesión de RSVP utilizada por el LSP. Para todos los vecinos que admiten el desmontaje agraciado, la plataforma de enrutamiento envía una solicitud para el desmontaje al punto de conexión de destino para el LSP y todos los vecinos RSVP en la ruta. La solicitud se incluye dentro del ADMIN_STATUS campo del paquete RSVP. Cuando los vecinos reciben la solicitud, se preparan para que se retire la sesión de RSVP. La plataforma de enrutamiento envía un segundo mensaje para completar el desmontaje de la sesión RSVP. Si un vecino no admite la lágrima agraciada, la solicitud se maneja como una sesión estándar en lugar de como una agraciada.
Para realizar un desmontaje agraciado de una sesión RSVP, emita el clear rsvp session gracefully comando. Opcionalmente, puede especificar la dirección de origen y destino de la sesión RSVP, el identificador LSP del remitente del RSVP y el identificador de túnel de la sesión RSVP. Para usar estos calificadores, incluya las connection-source, connection-destination, lsp-id, y tunnel-id las opciones cuando se emita el clear rsvp session gracefully comando.
También puede configurar la cantidad de tiempo que la plataforma de enrutamiento espera a que los vecinos reciban la solicitud de desglose agraciada antes de iniciar el desglose real mediante la inclusión de la graceful-deletion-timeout instrucción en el [edit protocols rsvp] nivel de jerarquía. El valor predeterminado de tiempo de espera de eliminación agracia 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 agraciado, emita el comando de show rsvp version modo operativo.