EN ESTA PÁGINA
Configuración de confirmaciones de saludo para vecinos que no sean RSVP de sesión
Configuración de la protección del programa de instalación de RSVP
Configuración de temporizadores para mensajes de actualización de RSVP
Configuración de RSVP para que aparezca la etiqueta en el enrutador de salto final
Habilitación del estallido de salto máximo en LSP de punto a multipunto
Configuración de pares del protocolo de administración de vínculos
Configuración de vínculos de ingeniería de tráfico del protocolo de administración de vínculos
Configuración de RSVP
Configuración mínima de RSVP
Para habilitar RSVP en una sola interfaz, incluya la rsvp instrucción y especifique la interfaz mediante la interface instrucción. Esta es la configuración mínima de RSVP. Todas las demás instrucciones de configuración RSVP son opcionales.
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 objetivo principal del software RSVP de Junos es admitir la señalización dinámica dentro de las rutas de conmutación de etiquetas (LSP). Cuando habilita MPLS y RSVP en un enrutador, MPLS se convierte en un cliente de RSVP. No se requiere ninguna configuración adicional para enlazar MPLS y RSVP.
Puede configurar MPLS para configurar rutas señalizadas mediante la label-switched-path instrucción en el nivel de [edit protocols mpls] jerarquía. Cada LSP se traduce en una solicitud de RSVP para iniciar una sesión RSVP. Esta solicitud se pasa a través de la interfaz interna entre la conmutación de etiquetas y RSVP. Después de examinar la información de la solicitud, comprobar los estados de RSVP y comprobar las tablas de enrutamiento local, RSVP inicia una sesión para cada LSP. La sesión se origina desde el enrutador local y está destinada al destino del LSP.
Cuando una sesión RSVP se crea correctamente, el LSP se configura a lo largo de las rutas creadas por la sesión RSVP. Si la sesión RSVP no se realiza correctamente, RSVP notifica a MPLS su estado. Corresponde a MPLS iniciar rutas de copia de seguridad o continuar reintentando la ruta inicial.
Para pasar la información de señalización de conmutación de etiquetas, RSVP admite cuatro objetos adicionales: Objeto Label Request, objeto Label, objeto Explicit Route y objeto Record Route. Para que un LSP se configure correctamente, todos los enrutadores a lo largo de la ruta deben admitir MPLS, RSVP y los cuatro objetos. De los cuatro objetos, el objeto Record Route no es obligatorio.
Para configurar MPLS y convertirlo en un cliente de RSVP, haga lo siguiente:
Active MPLS en todos los enrutadores que participarán en la conmutación de etiquetas (es decir, en todos los enrutadores que puedan formar parte de una ruta de conmutación de etiquetas).
Habilite RSVP en todos los enrutadores y en todas las interfaces de enrutador que forman el LSP.
Configure los enrutadores al principio del LSP.
Puede configurar las rutas RSVP conmutadas por etiquetas (LSP) para que utilicen una métrica de retraso a fin de calcular la ruta. Para configurar, use las opciones de CLI que hemos introducido en la [edit protocols mpls label-switched-path name] jerarquía.
Ejemplo: Configuración de RSVP y MPLS
A continuación se muestra un ejemplo de configuración para un enrutador al principio de un LSP:
[edit]
protocols {
mpls {
label-switched-path sf-to-london {
to 192.168.1.4;
}
}
rsvp {
interface so-0/0/0;
}
}
A continuación se muestra un ejemplo de configuración para todos los demás enrutadores que forman el LSP:
[edit]
protocols {
mpls {
interface so-0/0/0;
}
rsvp {
interface so-0/0/0;
}
}
Configuración de interfaces RSVP
En las secciones siguientes se describe cómo configurar interfaces RSVP:
- Configuración de la reducción de actualización de RSVP
- Configuración del intervalo de saludo RSVP
- Configuración de la autenticación RSVP
- Configuración de la suscripción de ancho de banda para tipos de clase
- Configuración del umbral de actualización RSVP en una interfaz
- Configuración de RSVP para interfaces no numeradas
Configuración de la reducción de actualización de RSVP
Puede configurar la reducción de actualización de RSVP en cada interfaz incluyendo las siguientes instrucciones en la configuración de la interfaz:
aggregateyreliable—Habilitar todas las funciones de reducción de actualización de RSVP: Agrupación de mensajes RSVP, ID de mensaje RSVP, entrega confiable de mensajes y actualización de resumen.Para tener una reducción de actualización y una entrega confiable, debe incluir las
aggregateinstrucciones yreliable.no-aggregate: desactiva la agrupación de mensajes RSVP y la actualización del resumen.no-reliable: desactiva el ID de mensaje RSVP, la entrega confiable de mensajes y la actualización del resumen.
Para obtener más información sobre la reducción de actualización de RSVP, consulte Reducción de actualización de RSVP.
Si la no-reliable instrucción está configurada en el enrutador (la entrega confiable de mensajes está deshabilitada), el enrutador acepta mensajes RSVP que incluyen el objeto Message ID, pero ignora el objeto Message ID y continúa realizando el procesamiento estándar de mensajes. En este caso, no se genera ningún error y RSVP funciona normalmente.
Sin embargo, no todas las combinaciones entre dos vecinos con diferentes capacidades de reducción de actualización funcionan correctamente. Por ejemplo, un enrutador se configura con la instrucción y no-reliable la aggregate instrucción o con las reliable instrucciones yno-aggregate. Si un vecino RSVP envía un objeto de actualización de resumen a este enrutador, no se genera ningún error, pero no se puede procesar el objeto de actualización de resumen. En consecuencia, los estados de RSVP pueden agotar el tiempo de espera en este enrutador si el vecino confía solo en la actualización de resumen para actualizar esos estados de RSVP.
Recomendamos, a menos que existan requisitos específicos, que configure la reducción de actualización de RSVP de manera similar en cada vecino de RSVP.
Para habilitar todas las funciones de reducción de actualización de RSVP en una interfaz, incluya la aggregate instrucción:
aggregate;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit protocols rsvp interface interface-name][edit logical-systems logical-system-name protocols rsvp interface interface-name]
Para deshabilitar la agrupación de mensajes RSVP y la actualización del resumen, incluya la 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 de 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]
Determinación de la capacidad de reducción de actualización de los vecinos de RSVP
Para determinar la capacidad de reducción de actualización de RSVP de un vecino de RSVP, necesita la siguiente información:
El bit RR anunciado por el vecino
La configuración local de la reducción de actualización de RSVP
Los mensajes RSVP reales recibidos del vecino
Para obtener esta información, puede emitir un show rsvp neighbor detail comando. A continuación se muestra el resultado de ejemplo:
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 supervisa el estado de los vecinos del protocolo de puerta de enlace interior (IGP) (IS-IS u OSPF) y se basa en los protocolos IGP para detectar cuándo falla un nodo. Si un protocolo IGP declara a un vecino caído (porque ya no se reciben paquetes de saludo), RSVP también derriba ese vecino. Sin embargo, los protocolos IGP y RSVP todavía actúan independientemente cuando se acerca a un vecino.
En el caso de los enrutadores de Juniper Networks, configurar un intervalo de saludo RSVP más corto o más largo no afecta a si se interrumpe o no una sesión RSVP. Las sesiones RSVP se mantienen incluso si los paquetes de saludo RSVP ya no se reciben. Las sesiones RSVP se mantienen hasta que el enrutador deja de recibir paquetes de saludo IGP o se agota el tiempo de espera de la ruta RSVP y los mensajes RESV. Sin embargo, a partir de Junos OS versión 16.1, cuando se agota el tiempo de espera de los mensajes de saludo RSVP, las sesiones de RSVP se desactivan.
El intervalo de saludo de RSVP también puede verse afectado cuando el equipo de otro proveedor interrumpe una sesión de RSVP. Por ejemplo, un enrutador vecino que no sea de Juniper Networks podría estar configurado para supervisar los paquetes de saludo RSVP.
Para modificar la frecuencia con la que RSVP envía paquetes de saludo, incluya la hello-interval instrucción:
hello-interval seconds;
A partir de la versión 16.1, Junos envía mensajes de saludo RSVP a través de un LSP de derivación cuando hay uno disponible. Consulte no-node-hello-on-bypass para obtener información sobre cómo volver al comportamiento histórico de enviar saludos a través del próximo salto del IGP.
Para obtener una lista de los niveles jerárquicos en los que puede incluir esta instrucción, consulte la sección Resumen de instrucciones.
Configuración de la autenticación RSVP
Todos los intercambios de protocolos RSVP se pueden autenticar para garantizar que solo los vecinos de confianza participen en la configuración de las reservas. De forma predeterminada, la autenticación RSVP está deshabilitada.
La autenticación RSVP utiliza un resumen basado en mensajes MD5 de código de autenticación de mensajes hash (HMAC). Este esquema genera un resumen del mensaje basado en una clave de autenticación secreta y el contenido del mensaje. (El contenido del mensaje también incluye un número de secuencia). El resumen calculado se transmite con mensajes RSVP. Una vez que haya configurado la autenticación, todos los mensajes RSVP recibidos y transmitidos con todos los vecinos se autenticarán en esta interfaz.
La autenticación MD5 proporciona protección contra la falsificación y la modificación de mensajes. También puede prevenir ataques de reproducción. Sin embargo, no proporciona confidencialidad, porque todos los mensajes se envían en texto claro.
De forma predeterminada, la autenticación está deshabilitada. Para habilitar la autenticación, configure una clave en cada interfaz incluyendo la authentication-key instrucción:
authentication-key key;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
Configuración de la suscripción de ancho de banda para tipos de clase
De forma predeterminada, RSVP permite usar el 100 por ciento del ancho de banda para un tipo de clase para reservas RSVP. Cuando se sobresuscribe un tipo de clase para un LSP multiclase, se permite que la demanda agregada de todas las sesiones RSVP supere la capacidad real del tipo de clase.
Para obtener instrucciones detalladas sobre cómo configurar la suscripción de ancho de banda para tipos de clase, consulte Configuración del porcentaje de suscripción de ancho de banda para LSP.
Configuración del umbral de actualización RSVP en una interfaz
Los protocolos de puerta de enlace interior (IGP) mantienen la base de datos de ingeniería de tráfico, pero el ancho de banda disponible actualmente en los vínculos de base de datos de ingeniería de tráfico se origina en RSVP. Cuando el ancho de banda de un vínculo cambia, RSVP informa a los IGP, que luego pueden actualizar la base de datos de ingeniería de tráfico y reenviar la nueva información de ancho de banda a todos los nodos de la red. Luego, los nodos de la red saben cuánto ancho de banda está disponible en el vínculo de la base de datos de ingeniería de tráfico (local o remoto), y CSPF puede calcular correctamente las rutas.
Sin embargo, las actualizaciones de IGP pueden consumir demasiados recursos del sistema. Dependiendo del número de nodos de una red, puede que no sea deseable realizar una actualización de IGP para pequeños cambios en el ancho de banda. Mediante la configuración de la update-threshold instrucción en el nivel de [edit protocols rsvp] jerarquía, puede ajustar el umbral en el que un cambio en el ancho de banda reservado desencadena una actualización de IGP.
Puede configurar un valor de 0,001 por ciento a 20 por ciento (el valor predeterminado es 10 por ciento) para cuándo activar una actualización de IGP. Si el cambio en el ancho de banda reservado es mayor o igual que el porcentaje de umbral configurado del ancho de banda estático en esa interfaz, se produce una actualización de IGP. Por ejemplo, si ha configurado la instrucción para que sea update-threshold del 15 por ciento y el enrutador descubre que el ancho de banda reservado en un vínculo ha cambiado en un 10 por ciento del ancho de banda del vínculo, RSVP no desencadena una actualización del IGP. Sin embargo, si el ancho de banda reservado en un vínculo cambia en un 20 por ciento del ancho de banda del vínculo, RSVP activa una actualización de IGP.
También puede configurar el umbral como un valor absoluto mediante la opción situada debajo de threshold-value la update-threshold instrucción.
Si el valor de umbral está configurado para ser superior al 20% del ancho de banda en ese vínculo, el valor de umbral se limita al 20% del ancho de banda.
Por ejemplo, si el ancho de banda en una interfaz es de 1 Gbps y está threshold-value configurado de más de 200 Mbps, el threshold-value límite es de 200 Mbps. El threshold-percent se muestra como 20.000% y el threshold-value como 200Mbps.
Las dos opciones, threshold-percent y threshold-value, son mutuamente excluyentes. Solo puede configurar una opción en un momento dado para generar una actualización de IGP para reservas de ancho de banda más bajas. Como resultado, cuando se configura una opción, la otra opción se calcula y se muestra en la CLI.
Por ejemplo, en un enlace de 1 Gbps, si el threshold-percent está configurado al 5%, se threshold-value calcula y se muestra como 50Mbps. Del mismo modo, si el threshold-value está configurado en 50 m, entonces el threshold-percent se calcula y se muestra como 5%.
Para ajustar el umbral en el que un cambio en el ancho de banda reservado desencadena una actualización de IGP, incluya la instrucción update-threshold . Debido al umbral de actualización, es posible que la ruta más corta restringida primero (CSPF) calcule una ruta utilizando información de ancho de banda de base de datos de ingeniería de tráfico obsoleta en un vínculo. Si RSVP intenta establecer un LSP en esa ruta, es posible que no haya suficiente ancho de banda en ese vínculo. Cuando esto sucede, RSVP activa una actualización de la base de datos de ingeniería de tráfico IGP, inundando la información de ancho de banda actualizada en la red. A continuación, CSPF puede volver a calcular la ruta utilizando la información de ancho de banda actualizada e intentar encontrar una ruta diferente, evitando el vínculo congestionado. Tenga en cuenta que esta funcionalidad es la predeterminada y no necesita ninguna configuración adicional.
Puede configurar la rsvp-error-hold-time instrucción en el [edit protocols mpls] nivel de jerarquía o en el [edit logical-systems logical-system-name protocols mpls] nivel de jerarquía para mejorar la precisión de la base de datos de ingeniería de tráfico (incluida la precisión de las estimaciones de ancho de banda para LSP) mediante la información proporcionada por los mensajes de PathErr. Consulte Mejora de la precisión de la base de datos de ingeniería de tráfico con mensajes RSVP PathErr.
Configuración de RSVP para interfaces no numeradas
Junos OS admite la ingeniería de tráfico RSVP en interfaces no numeradas. La información de ingeniería de tráfico sobre vínculos no numerados se transporta en las extensiones de ingeniería de tráfico IGP para OSPF e IS-IS, tal como se describe en RFC 4203, Extensiones OSPF en soporte de conmutación de etiquetas multiprotocolo generalizada (GMPLS) y RFC 4205, Extensiones de sistema intermedio a sistema intermedio (IS-IS) en soporte de conmutación de etiquetas multiprotocolo generalizada (GMPLS). Los vínculos no numerados también se pueden especificar en la señalización de ingeniería de tráfico MPLS como se describe en RFC 3477, Señalización de enlaces no numerados en el protocolo de reserva de recursos - Ingeniería de tráfico (RSVP-TE). Esta característica le permite evitar tener que configurar direcciones IP para cada interfaz que participa en la red señalada RSVP.
Para configurar RSVP para interfaces no numeradas, debe configurar el enrutador con un ID de enrutador utilizando la router-id instrucción especificada en el nivel de [edit routing-options] jerarquía. El ID del enrutador debe estar disponible para el enrutamiento (normalmente puede usar la dirección de circuito cerrado). Los mensajes de control RSVP para los vínculos no numerados se envían utilizando la dirección ID del enrutador (en lugar de una dirección seleccionada aleatoriamente).
Para configurar la protección de vínculos y el reenrutamiento rápido en un enrutador con interfaces no numeradas habilitadas, debe configurar al menos dos direcciones. Se recomienda configurar una interfaz secundaria en el circuito cerrado además de configurar el ID del enrutador.
Configuración de RSVP Node-ID Hellos
Puede configurar saludos RSVP basados en ID de nodo para garantizar que los enrutadores de Juniper Networks puedan interoperar con los equipos de otros proveedores. De forma predeterminada, Junos OS utiliza saludos RSVP basados en interfaz. Los saludos RSVP basados en ID de nodo se especifican en RFC 4558, Protocolo de reserva de recursos basado en ID de nodo (RSVP) Hola: Una declaración aclaratoria. Los saludos de ID de nodo RSVP son útiles si ha configurado BFD para detectar problemas en las interfaces RSVP, lo que le permite deshabilitar los saludos de interfaz para estas interfaces. También puede utilizar node-ID holos para procedimientos de reinicio correctos.
Los saludos de ID de nodo se pueden habilitar globalmente para todos los vecinos de RSVP. De forma predeterminada, la compatibilidad con hola de ID de nodo está deshabilitada. Si no ha habilitado los ID de nodo RSVP en el enrutador, Junos OS no acepta ningún paquete de hola de ID de nodo.
A partir de la versión 16.1, Junos envía mensajes de saludo RSVP a través de un LSP de derivación cuando hay uno disponible. Consulte no-node-hello-on-bypass para obtener información sobre cómo volver al comportamiento histórico de enviar saludos a través del próximo salto del IGP.
Para habilitar los saludos de ID de nodo RSVP globalmente en el enrutador, incluya la instrucción node-hello en los siguientes niveles jerárquicos:
-
[edit protocols rsvp] -
[edit logical-systems logical-systems-name protocols rsvp]
También puede deshabilitar explícitamente los saludos de la interfaz RSVP globalmente. Este tipo de configuración puede ser necesaria en redes donde el enrutador de Juniper Networks tiene numerosas conexiones RSVP con equipos de otros proveedores. Sin embargo, si deshabilita los saludos de interfaz RSVP globalmente, también puede configurar un intervalo de saludo en una interfaz RSVP mediante la instrucción hello-interval. Esta configuración deshabilita los saludos de interfaz RSVP globalmente, pero habilita los saludos de interfaz RSVP en la interfaz especificada (la interfaz RSVP en la que configura la hello-interval instrucción). Esta configuración puede ser necesaria en una red heterogénea en la que algunos dispositivos admiten saludos de ID de nodo RSVP y otros dispositivos admiten saludos de interfaz RSVP.
Para deshabilitar los saludos de interfaz RSVP globalmente en el enrutador, incluya la instrucción no-interface-hello en los siguientes niveles de jerarquía:
-
[edit protocols rsvp] -
[edit logical-systems logical-systems-name protocols rsvp]
Ejemplo: Configuración de LSP señalados por RSVP
En este ejemplo se muestra cómo crear un LSP entre enrutadores de una red IP utilizando RSVP como protocolo de señalización.
Requisitos
Antes de comenzar, elimine los servicios de seguridad del dispositivo. Consulte Ejemplo: Eliminación de servicios de seguridad.
Descripción general y topología
Mediante el uso de RSVP como protocolo de señalización, puede crear LSP entre enrutadores de una red IP. En este ejemplo, se configura una red de ejemplo como se muestra en Figura 1.
Topología
Para establecer un LSP entre enrutadores, debe habilitar individualmente la familia MPLS y configurar RSVP en cada una de las interfaces de tránsito de la red MPLS. En este ejemplo se muestra cómo habilitar MPLS y configurar RSVP en la interfaz de tránsito ge-0/0/0. Además, debe habilitar el proceso MPLS en todas las interfaces MPLS de la red.
En este ejemplo se muestra cómo definir un LSP de R1 a R7 en el enrutador de entrada (R1) utilizando la dirección de circuito cerrado de R7 (10.0.9.7). La configuración reserva 10 Mbps de ancho de banda. Además, la configuración deshabilita el algoritmo CSPF, lo que garantiza que los hosts C1 y C2 utilicen el LSP con señal RSVP que corresponda a la ruta más corta del IGP de red.
Configuración
Procedimiento
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, a continuación, copie y pegue los comandos en la CLI en el nivel de [edit] jerarquía.
set interfaces ge-0/0/0 unit 0 family mpls set protocols rsvp interface ge-0/0/0.0 set protocols mpls label-switched-path r1-r7 to 10.0.9.7 set protocols mpls label-switched-path r1-r7 bandwidth 10m set protocols mpls interface all
Procedimiento paso a paso
En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI.
Para configurar RSVP:
Habilite la familia MPLS en todas las interfaces de tránsito de la red MPLS.
[edit] user@host# set interfaces ge-0/0/0 unit 0 family mpls
Habilite RSVP en cada interfaz de tránsito de la red MPLS.
[edit] user @host# set protocols rsvp interface ge-0/0/0
Habilite el proceso MPLS en la interfaz de tránsito en la red MPLS.
[edit] user@host# set protocols mpls interface ge-0/0/0
Defina el LSP en el enrutador de entrada.
[edit protocols mpls] user@host# set label-switched-path r1-r7 to 10.0.9.7
Reserve 10 Mbps de ancho de banda en el LSP.
[edit protocols mpls] user @host# set label-switched-path r1-r7 bandwidth 10m
Resultados
Confirme la configuración introduciendo el comando desde el show modo de configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones de configuración en este ejemplo para corregirla.
Para fines de brevedad, este resultado del comando show solo incluye la configuración relevante para este ejemplo. Cualquier otra configuración en el sistema se reemplazó por puntos suspensivos (...).
user@host# show
...
interfaces {
ge-0/0/0 {
family mpls;
}
}
}
...
protocols {
rsvp {
interface ge-0/0/0.0;
}
mpls {
label-switched-path r1-r7 {
to 10.0.9.7;
bandwidth 10m;
}
interface all;
}
}
...
Cuando termine de configurar el dispositivo, ingrese commit en el modo de configuración.
Verificación
Para confirmar que la configuración funcione correctamente, realice las siguientes tareas:
- Verificar RSVP Neighbors
- Verificación de sesiones RSVP
- Comprobación de la presencia de LSP señalados por RSVP
Verificar RSVP Neighbors
Propósito
Verifique que cada dispositivo muestre los vecinos RSVP apropiados, por ejemplo, que el enrutador R1 enumera Figura 1 tanto el enrutador R3 como el enrutador R2 como vecinos de RSVP.
Acción
Desde la CLI, ingrese el comando show rsvp neighbor.
user@r1> show rsvp neighbor RSVP neighbor: 2 learned Address Idle Up/Dn LastChange HelloInt HelloTx/Rx 10.0.6.2 0 3/2 13:01 3 366/349 10.0.3.3 0 1/0 22:49 3 448/448
La salida muestra las direcciones IP de los enrutadores vecinos. Verifique que cada dirección de circuito cerrado del enrutador RSVP vecino aparezca en la lista.
Verificación de sesiones RSVP
Propósito
Verifique que se haya establecido una sesión de RSVP entre todos los vecinos de RSVP. Además, compruebe que el valor de reserva de ancho de banda esté activo.
Acción
Desde la CLI, ingrese el comando show rsvp session detail.
user@r1> show rsvp session detail Ingress RSVP: 1 sessions 10.0.9.7 From: 10.0.6.1, LSPstate: Up, ActiveRoute: 0 LSPname: r1–r7, LSPpath: Primary Bidirectional, Upstream label in: –, Upstream label out: - Suggested label received: -, Suggested label sent: – Recovery label received: -, Recovery label sent: 100000 Resv style: 1 FF, Label in: -, Label out: 100000 Time left: -, Since: Thu Jan 26 17:57:45 2002 Tspec: rate 10Mbps size 10Mbps peak Infbps m 20 M 1500 Port number: sender 3 receiver 17 protocol 0 PATH rcvfrom: localclient PATH sentto: 10.0.4.13 (ge-0/0/1.0) 1467 pkts RESV rcvfrom: 10.0.4.13 (ge-0/0/1.0) 1467 pkts Record route: <self> 10.0.4.13 10.0.2.1 10.0.8.10
El resultado muestra la información detallada, incluidos los ID de sesión, la reserva de ancho de banda y las direcciones del próximo salto, para cada sesión RSVP establecida. Verifique la información siguiente:
Cada dirección de vecino RSVP tiene una entrada para cada vecino, enumerada por dirección de circuito cerrado.
El estado de cada sesión LSP es Up.
Para Tspec, aparece el valor de ancho de banda adecuado, 10Mbps, .
Comprobación de la presencia de LSP señalados por RSVP
Propósito
Compruebe que la tabla de enrutamiento del enrutador de entrada (entrada) tenga un LSP configurado para la dirección de circuito cerrado del otro enrutador. Por ejemplo, compruebe que la inet.3 tabla de enrutamiento del enrutador de entrada R1 en Figura 1 tiene un LSP configurado para la dirección de circuito cerrado del enrutador R7.
Acción
Desde la CLI, ingrese el comando show route table inet.3.
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. Compruebe que un LSP con señal RSVP esté asociado a la dirección de circuito cerrado del enrutador de salida R7 en la red MPLS.
Ejemplo: Configuración de la malla automática RSVP
Los proveedores de servicios a menudo usan VPN BGP y MPLS para escalar la red de manera eficiente mientras ofrecen servicios que generan ingresos. En estos entornos, BGP se usa para distribuir la información de enrutamiento VPN a través de la red del proveedor de servicios, mientras que MPLS se usa para reenviar ese tráfico VPN de un sitio VPN a otro.
Al agregar un nuevo enrutador PE que participará en las VPN BGP y MPLS, todos los enrutadores PE existentes anteriormente deben configurarse para emparejarse con el nuevo enrutador PE tanto para BGP como para MPLS. A medida que se agrega cada nuevo enrutador PE a la red del proveedor de servicios, la carga de configuración pronto se vuelve demasiado difícil de manejar.
Los requisitos de configuración para el emparejamiento BGP se pueden reducir con el uso de reflectores de ruta. En las redes MPLS señalizadas RSVP, la malla automática RSVP puede minimizar la carga de configuración para la parte MPLS de la red. La configuración rsvp-te en todos los enrutadores PE permite que RSVP cree automáticamente los LSP necesarios cuando se agrega un nuevo enrutador PE.
Requisitos
En este ejemplo, se utilizan los siguientes componentes de hardware y software:
Un enrutador que ejecute Junos OS versión 10.1 o posterior.
Una VPN BGP y MPLS que utiliza RSVP como protocolo de señalización de ruta de conmutación de etiquetas (LSP) de MPLS.
Descripción general
En este ejemplo se muestra cómo configurar la malla automática RSVP en un enrutador PE mediante la instrucción configuration rsvp-te . Para que la malla automática RSVP funcione correctamente, todos los enrutadores PE en la configuración de malla completa deben tener configurada la rsvp-te instrucción. Esto asegura que cualquier enrutador PE nuevo que se agregue más adelante también se beneficiará de la función de malla automática, siempre que también estén configurados con la rsvp-te instrucción.
Dado este requisito, este ejemplo solo muestra la configuración en el enrutador PE recién agregado. Se supone que la malla automática RSVP ya se ha configurado en los enrutadores PE existentes.
Topología
En Figura 2, hay tres enrutadores PE existentes, PE1, PE2 y PE3, en la topología. Se ha agregado PE4 y se configurará la malla automática RSVP. La nube representa la red del proveedor de servicios, y la dirección de red, 192.0.2.0/24, se muestra en el centro de la figura.
Configuración
La configuración de la malla automática RSVP implica realizar estas tareas:
Habilitar la instrucción de
rsvp-teconfiguración en el nivel jerárquico[edit routing-options dynamic-tunnels dynamic-tunnel-name].Configuración del elemento necesario
destination-networks.Este elemento de configuración especifica el intervalo de prefijos IPv4 para la red de destino. Solo se pueden crear túneles dentro del rango de prefijos especificado.
Configuración del elemento necesario
label-switched-path-template.Este elemento de configuración toma como
default-templateargumento o el nombre de una plantilla LSP preconfigurada. La es una plantilla definida por eldefault-templatesistema que no requiere configuración de usuario.
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, a continuación, copie y pegue los comandos en la CLI en el nivel de [edit] jerarquía.
Enrutador PE4
set routing-options dynamic-tunnels dt-1 rsvp-te rsvp-te-1 label-switched-path-template default-template set routing-options dynamic-tunnels dt-1 rsvp-te rsvp-te-1 destination-networks 192.0.2.0/24
Configuración de la malla automática RSVP
Procedimiento paso a paso
En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener instrucciones sobre cómo hacer eso, consulte Uso del editor de CLI en el modo de configuración de la Guía del usuario de CLI.
Para habilitar la malla automática RSVP:
Configure
rsvp-teen el nivel jerárquico[edit routing-options dynamic-tunnels].[edit routing-options dynamic-tunnels] user@PE4# set dt-1 rsvp-te rsvp-te-1 label-switched-path-template default-template
Configure
destination-networksen el nivel jerárquico[edit routing-options dynamic-tunnels].[edit routing-options dynamic-tunnels] user@PE4# set dt-1 rsvp-te rsvp-te-1 destination-networks 192.0.2.0/24
Resultados
Emita el 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
- Verificación de la existencia de túneles de malla automáticos RSVP en el enrutador PE4
- Comprobación de la existencia de LSP MPLS en el enrutador PE4
Verificación de la existencia de túneles de malla automáticos RSVP en el enrutador PE4
Propósito
Para verificar el funcionamiento del enrutador PE4 recién configurado, emita el comando desde el 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
Comprobación de la existencia de LSP MPLS en el enrutador PE4
Propósito
Para comprobar la existencia de LSP MPLS en el enrutador PE4, emita el comando desde el show mpls lsp modo operativo. Este comando mostrará el estado de los LSP de MPLS.
Acción
user@PE4> show mpls lsp
Ingress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Egress LSP: 3 sessions To From State Rt Style Labelin Labelout LSPname 192.0.2.104 192.0.2.103 Up 0 1 FF 3 - PE2-PE4 192.0.2.104 192.0.2.102 Up 0 1 FF 3 - PE2-PE4 192.0.2.104 192.0.2.101 Up 0 1 FF 3 - PE1-PE4 Total 3 displayed, Up 3, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0
Configuración de confirmaciones de saludo para vecinos que no sean RSVP de sesión
La hello-acknowledgements instrucción controla el comportamiento de confirmación de saludo entre los vecinos de RSVP, independientemente de si están o no en la misma sesión.
Se descartan los mensajes de hola recibidos de vecinos de RSVP que no forman parte de una sesión RSVP común. Si configura la hello-acknowledgements instrucción en el nivel jerárquico, los [edit protocols rsvp] mensajes de saludo de vecinos que no son de sesión se confirman con un mensaje de confirmación de saludo. Cuando se reciben saludos de vecinos que no son de sesión, se crea una relación de vecino RSVP y ahora se pueden recibir mensajes de saludo periódicos del vecino que no es sesión. La hello-acknowledgements instrucción está deshabilitada de forma predeterminada. La configuración de esta instrucción permite descubrir enrutadores compatibles con RSVP mediante paquetes de saludo y comprueba que la interfaz es capaz de recibir paquetes RSVP antes de enviar cualquier mensaje de configuración de LSP MPLS.
Una vez que habilite las confirmaciones de saludo para los vecinos que no sean RSVP de sesión, el enrutador continúa reconociendo los mensajes de saludo de cualquier vecino que no sea RSVP de sesión, a menos que la interfaz deje de funcionar o cambie la configuración. Los vecinos basados en interfaces no se eliminan automáticamente.
hello-acknowledgements;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit protocols rsvp][edit logical-systems logical-system-name protocols rsvp]
Alejar los LSP de un nodo de red
Puede configurar el enrutador para conmutar los LSP activos fuera de un nodo de red mediante un LSP de derivación habilitado para una interfaz. Esta función se puede usar para mantener redes activas cuando un dispositivo necesita ser reemplazado sin interrumpir el tráfico que transita por la red. Los LSP pueden ser estáticos o dinámicos.
Tenga en cuenta las siguientes limitaciones relacionadas con la conmutación de LSP activos fuera de un nodo de red:
La función de cambio solo se admite en los enrutadores de la serie MX.
La función de cambio no se admite para cambiar el tráfico de los LSP primarios de punto a multipunto para omitir los LSP de punto a multipunto. Si configura la
switch-away-lspsinstrucción para un LSP punto a multipunto, el tráfico no se cambia al LSP de omitir punto a multipunto.Si configura la característica de cambio en una interfaz a lo largo de la ruta de un LSP dinámico, no se pueden establecer nuevos LSP dinámicos en esa ruta. La función de desactivación evita el comportamiento de hacer antes de la interrupción de los LSP señalados por RSVP. El comportamiento de hacer antes de romper normalmente hace que el enrutador primero intente volver a señalar un LSP dinámico antes de derribar el original.
Configuración de la protección del programa de instalación de RSVP
Puede configurar el mecanismo de reenrutamiento rápido de la copia de seguridad de las instalaciones para proporcionar protección de instalación para los LSP que están en proceso de señalización. Se admiten tanto los LSP punto a punto como los LSP punto a multipunto. Esta característica es aplicable en el siguiente escenario:
Un nodo o vínculo fallido está presente en la ruta explícita estricta de un LSP antes de que se señale el LSP.
También hay un LSP de derivación que protege el enlace o nodo.
RSVP señala el LSP a través del LSP de derivación. El LSP aparece como si se hubiera configurado originalmente a lo largo de su ruta principal y luego se hubiera conmutado por error al LSP de derivación debido a un error de vínculo o nodo.
Cuando el vínculo o nodo se ha recuperado, el LSP se puede revertir automáticamente a la ruta principal.
Debe configurar la setup-protection instrucción en el [edit protocols rsvp] en cada uno de los enrutadores a lo largo de la ruta de LSP en la que desea habilitar la protección del programa de instalación de LSP. También debe configurar la ingeniería de tráfico IGP en todos los enrutadores de la ruta LSP. Puede emitir un show rsvp session comando para determinar si el LSP tiene habilitada o no la protección de configuración en un enrutador que actúa como punto de reparación local (PLR) o punto de combinación.
Para habilitar la protección del programa de instalación de RSVP, incluya la setup-protection instrucción
setup-protection;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit protocols rsvp][edit logical-systems logical-system-name protocols rsvp]
Configuración del equilibrio de carga entre los LSP de RSVP
De forma predeterminada, cuando haya configurado varios LSP RSVP en el mismo enrutador de salida, se selecciona el LSP con la métrica más baja y transporta todo el tráfico. Si todos los LSP tienen la misma métrica, uno de los LSP se selecciona al azar y todo el tráfico se reenvía a través de él.
Como alternativa, puede equilibrar la carga del tráfico en todos los LSP habilitando el equilibrio de carga por paquete.
Para habilitar el equilibrio de carga por paquete en un LSP de entrada, configure la policy-statement instrucción de la siguiente manera:
[edit policy-options] policy-statement policy-name { then { load-balance per-packet; } accept; }
A continuación, debe aplicar esta instrucción como una política de exportación a la tabla de reenvío.
Una vez que se aplica el equilibrio de carga por paquete, el tráfico se distribuye equitativamente entre los LSP (de forma predeterminada).
Debe configurar el equilibrio de carga por paquete si desea habilitar el reenrutamiento rápido de PFE. Para habilitar el reenrutamiento rápido de PFE, incluya la instrucción para el policy-statement equilibrio de carga por paquete que se muestra en esta sección en la configuración de cada uno de los enrutadores donde puede tener lugar un reenrutamiento. Consulte también Configuración del reenrutamiento rápido.
También puede equilibrar la carga del tráfico entre los LSP en proporción a la cantidad de ancho de banda configurado para cada LSP. Esta capacidad puede distribuir mejor el tráfico en redes con capacidades de ancho de banda asimétrico a través de vínculos externos, ya que el ancho de banda configurado de un LSP normalmente refleja la capacidad de tráfico de ese LSP.
Para configurar el equilibrio de carga del LSP de RSVP, incluya la load-balance instrucción con la bandwidth opción:
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 modifica el comportamiento de los LSP que se ejecutan actualmente. Para forzar que los LSP que se ejecutan actualmente usen el nuevo comportamiento, puede emitir unclear mpls lspcomando.La
load-balanceinstrucción sólo se aplica a los LSP de entrada que tienen habilitado el equilibrio de carga por paquete.Para los LSP de ingeniería de tráfico con reconocimiento de servicios diferenciados, el ancho de banda de un LSP se calcula sumando el ancho de banda de todos los tipos de clase.
Configuración de la malla automática RSVP
Puede configurar RSVP para establecer rutas de conmutación de etiquetas (LSP) punto a punto automáticamente para cualquier enrutador PE nuevo agregado a una malla completa de LSP. Para habilitar esta característica, debe configurar la rsvp-te instrucción en todos los enrutadores PE en la malla completa.
No puede configurar la malla automática RSVP junto con CCC. CCC no puede utilizar los LSP generados dinámicamente.
Para configurar la malla automática RSVP, incluya la rsvp-te instrucción:
rsvp-te { destination-networks network-prefix; label-switched-path-template (Multicast) { default-template; template-name; } }
Puede configurar estas instrucciones en los siguientes niveles jerárquicos:
[edit routing-options dynamic-tunnels tunnel-name][edit logical-systems logical-system-name routing-options dynamic-tunnels tunnel-name]
También debe configurar las instrucciones siguientes para habilitar la malla automática RSVP:
destination-networks: especifique el intervalo de prefijos IP versión 4 (IPv4) para la red de destino. Se pueden iniciar túneles dinámicos dentro del rango de prefijos IPv4 especificado.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 de RSVP
RSVP utiliza dos parámetros de temporización relacionados:
refresh-time: el tiempo de actualización controla el intervalo entre la generación de mensajes de actualización sucesivos. El valor predeterminado para el tiempo de actualización es de 45 segundos. Este número se deriva del valor predeterminado de larefresh-timeinstrucción de 30, multiplicado por un valor fijo de 1,5. Este cálculo difiere de RFC 2205, que establece que el tiempo de actualización debe multiplicarse por un valor aleatorio en el intervalo de 0,5 a 1,5.Los mensajes de actualización incluyen mensajes de ruta y Resv. Los mensajes de actualización se envían periódicamente para que los estados de reserva en los nodos vecinos no agoten el tiempo de espera. Cada ruta y mensaje Resv lleva el valor del temporizador de actualización y el nodo receptor extrae este valor de los mensajes.
keep-multiplier—El multiplicador keep es un pequeño entero configurado localmente del 1 al 255. El valor predeterminado es 3. Indica el número de mensajes que se pueden perder antes de que un estado determinado se declare obsoleto y deba eliminarse. El multiplicador de mantenimiento afecta directamente a la duración de un estado RSVP.
Para determinar la duración de un estado de reserva, utilice la fórmula siguiente:
lifetime = (keep-multiplier + 0.5) x (1.5 x refresh-time)
En el peor de los casos, (keep-multiplier – 1) los mensajes de actualización sucesivos deben perderse antes de que se elimine un estado de reserva.
No recomendamos configurar un temporizador de saludo RSVP corto. Si se necesita un descubrimiento rápido de un vecino fallido, configure temporizadores de saludo cortos de IGP (OSPF o IS-IS).
De forma predeterminada, el valor del temporizador de actualización es de 30 segundos. Para modificar este valor, incluya la refresh-time instrucción:
refresh-time seconds;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit protocols rsvp][edit logical-systems logical-system-name protocols rsvp]
El valor predeterminado del multiplicador de mantenimiento es 3. Para modificar este valor, incluya la 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]
Preferencia sobre las sesiones de RSVP
Siempre que el ancho de banda sea insuficiente para manejar todas las sesiones RSVP, puede controlar la preferencia de las sesiones RSVP. De forma predeterminada, una sesión RSVP solo tiene preferencia sobre una nueva sesión de mayor prioridad.
Para tener preferencia siempre a una sesión cuando el ancho de banda es insuficiente, incluya la preemption instrucción con la aggressive opción:
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, tener preferencia sobre una sesión solo para una nueva sesión de mayor prioridad), incluya la preemption instrucción con la normal opción:
preemption normal;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit protocols rsvp][edit logical-systems logical-system-name protocols rsvp]
Configuración de la señalización MTU en RSVP
Para configurar la señalización de la unidad máxima de transmisión (MTU) en RSVP, debe configurar MPLS para permitir que los paquetes IP se fragmenten antes de encapsularlos en MPLS. También debe configurar la señalización MTU en RSVP. Para solucionar problemas, puede configurar la señalización MTU sola sin habilitar la fragmentación de paquetes.
Para configurar la señalización MTU en RSVP, incluya la 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]
En las secciones siguientes se describe cómo habilitar la fragmentación de paquetes y la señalización MTU en RSVP:
Habilitación de la señalización MTU en RSVP
Para habilitar la señalización MTU en RSVP, incluya la rsvp mtu-signaling instrucción:
rsvp mtu-signaling;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit protocols mpls path-mtu][edit logical-systems logical-system-name protocols mpls path-mtu]
Una vez confirmada la configuración, los cambios en el comportamiento de señalización de MTU para RSVP surtirán efecto la próxima vez que se actualice la ruta.
Puede configurar la mtu-signaling instrucción por sí misma en el nivel jerárquico [edit protocols mpls path-mtu rsvp] . Esto puede ser útil para la solución de problemas. Si configura solo la mtu-signaling instrucción, puede usar el show rsvp session detail comando para determinar cuál es la MTU más pequeña en un LSP. El show rsvp session detail comando muestra el valor MTU recibido y enviado en el objeto Adspec.
Habilitación de la fragmentación de paquetes
Para permitir que los paquetes IP se fragmenten antes de encapsularlos en MPLS, incluya la allow-fragmentation instrucción:
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. Siempre configúrelo junto con lamtu-signalinginstrucción.
Configuración de Ultimate-Hop Popping para LSP
De forma predeterminada, los LSP señalados por RSVP utilizan el estallido de penúltimo salto (PHP). Figura 3 ilustra un LSP de penúltimo salto entre el enrutador PE1 y el enrutador PE2. El enrutador CE1 reenvía un paquete a su siguiente salto (enrutador PE1), que también es la entrada de LSP. El enrutador PE1 inserta la etiqueta 1 en el paquete y reenvía el paquete etiquetado al enrutador P1. El enrutador P1 completa la operación estándar de intercambio de etiquetas MPLS, intercambia la etiqueta 1 por la etiqueta 2 y reenvía el paquete al enrutador P2. Dado que el enrutador P2 es el enrutador de penúltimo salto para el LSP al enrutador PE2, primero abre la etiqueta y luego reenvía el paquete al enrutador PE2. Cuando el enrutador PE2 lo recibe, el paquete puede tener una etiqueta de servicio, una etiqueta explícita nula o simplemente ser un paquete IP o VPLS simple. El enrutador PE2 reenvía el paquete sin etiqueta al enrutador CE2.
También puede configurar el estallido de salto máximo (UHP) (como se muestra en Figura 4) para los LSP señalados por RSVP. Algunas aplicaciones de red pueden requerir que los paquetes lleguen al enrutador de salida (enrutador PE2) con una etiqueta externa no nula. Para un LSP de última salto, el penúltimo enrutador (enrutador P2 en Figura 4) realiza la operación estándar de intercambio de etiquetas MPLS (en este ejemplo, etiqueta 2 para etiqueta 3) antes de reenviar el paquete al enrutador PE2 de salida. El enrutador PE2 abre la etiqueta exterior y realiza una segunda búsqueda de la dirección del paquete para determinar el destino final. A continuación, reenvía el paquete al destino apropiado (ya sea el enrutador CE2 o CE4).
Las siguientes aplicaciones de red requieren que configure LSP de UHP:
MPLS-TP para monitoreo del rendimiento y OAM en banda
Circuitos virtuales de protección de bordes
Las siguientes características no admiten el comportamiento UHP:
LSP señalados por LDP
LSP estáticos
LSP de punto a multipunto
CCC
traceroutemandar
Para obtener más información acerca del comportamiento de UHP, consulte draft-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt de borrador de Internet, Comportamiento no PHP y Asignación fuera de banda para LSP RSVP-TE.
Para los LSP señalados por RSVP punto a punto, el comportamiento de UHP se señala desde la entrada del LSP. Según la configuración del enrutador de entrada, RSVP puede señalar el LSP UHP con el indicador no PHP establecido. Los mensajes RSVP PATH llevan los dos indicadores del objeto LSP-ATTRIBUTES. Cuando el enrutador de salida recibe el mensaje PATH, asigna una etiqueta no nula al LSP. RSVP también crea e instala dos rutas en la tabla de enrutamiento mpls.0. S se refiere al bit S de la etiqueta MPLS, que indica si se ha alcanzado o no la parte inferior de la pila de etiquetas.
Ruta S=0: indica que hay más etiquetas en la pila. El siguiente salto para esta ruta apunta a la tabla de enrutamiento mpls.0, lo que desencadena una búsqueda de etiquetas MPLS encadenadas para descubrir las etiquetas MPLS restantes en la pila.
Ruta S=1: indica que no hay más etiquetas. El siguiente salto apunta a la tabla de enrutamiento inet.0 si la plataforma admite la búsqueda encadenada y multifamiliar. Alternativamente, la ruta de etiqueta puede apuntar a una interfaz VT para iniciar el reenvío de IP.
Si habilita los LSP UHP, las aplicaciones MPLS como VPN de capa 3, VPLS, VPN de capa 2 y circuitos de capa 2 pueden usar los LSP de UHP. A continuación se explica cómo los LSP UHP afectan a los distintos tipos de aplicaciones MPLS:
VPN de capa 2 y circuitos de capa 2: un paquete llega al enrutador PE (salida del LSP UHP) con dos etiquetas. La etiqueta externa (S = 0) es la etiqueta UHP, y la etiqueta interna (S = 1) es la etiqueta VC . Una búsqueda basada en la etiqueta de transporte da como resultado un identificador de tabla para la tabla de enrutamiento mpls.0. Hay una ruta adicional en la tabla de enrutamiento mpls.0 correspondiente a la etiqueta interna. Una búsqueda basada en la etiqueta interna da como resultado el siguiente salto del enrutador CE.
VPN de capa 3: un paquete llega al enrutador PE (salida del LSP UHP) con dos etiquetas. La etiqueta externa (S=0) es la etiqueta UHP, y la etiqueta interna es la etiqueta VPN (S=1). Una búsqueda basada en la etiqueta de transporte da como resultado el identificador de tabla para la tabla de enrutamiento mpls.0. Hay dos casos en este escenario. De forma predeterminada, las VPN de capa 3 anuncian la etiqueta por salto siguiente. Una búsqueda basada en la etiqueta interna da como resultado el siguiente salto hacia el enrutador CE. Sin embargo, si ha configurado la
vrf-table-labelinstrucción para la instancia de enrutamiento VPN de capa 3, la etiqueta LSI interna apunta a la tabla de enrutamiento VRF. También se completa una búsqueda IP para la tabla de enrutamiento VRF.Nota:UHP para VPN de capa 3 configuradas con la instrucción solo es compatible con las
vrf-table-labelplataformas de enrutamiento universal 5G de la serie MX.VPLS: un paquete llega al enrutador PE (salida del UHP LSP) con dos etiquetas. La etiqueta exterior es la etiqueta de transporte (S=0) y la etiqueta interior es la etiqueta VPLS (S=1). Una búsqueda basada en la etiqueta de transporte da como resultado el identificador de tabla para la tabla de enrutamiento mpls.0. Una búsqueda basada en la etiqueta interna de la tabla de enrutamiento mpls.0 da como resultado la interfaz de túnel LSI de la instancia de enrutamiento VPLS si tunnel-services no está configurado (o si no hay una interfaz VT disponible). Los enrutadores de la serie MX 3D admiten la búsqueda encadenada y la búsqueda multifamiliar.
Nota:UHP para VPLS configurado con la instrucción solo se admite en los enrutadores de la
no-tunnel-serviceserie MX 3D.IPv4 a través de MPLS: un paquete llega al enrutador PE (salida del UHP LSP) con una etiqueta (S=1). Una búsqueda basada en esta etiqueta devuelve una interfaz de túnel VT. Se completa otra búsqueda IP en la interfaz VT para determinar dónde reenviar el paquete. Si la plataforma de enrutamiento admite búsquedas multifamiliares y encadenadas (por ejemplo, enrutadores MX 3D y enrutadores de transporte de paquetes de la serie PTX), la búsqueda basada en la ruta de la etiqueta (S=1) apunta a la tabla de enrutamiento inet.0.
IPv6 sobre MPLS: para la tunelización IPv6 a través de MPLS, los enrutadores PE anuncian rutas IPv6 entre sí con un valor de etiqueta de 2. Esta es la etiqueta nula explícita para IPv6. Como resultado, los siguientes saltos de reenvío para las rutas IPv6 que se aprenden de enrutadores de PE remotos normalmente envían dos etiquetas. La etiqueta interna es 2 (podría ser diferente si el enrutador de PE publicitario es de otro proveedor) y la etiqueta del enrutador es la etiqueta LSP. Los paquetes llegan al enrutador PE (salida del UHP LSP) con dos etiquetas. La etiqueta externa es la etiqueta de transporte (S=0) y la etiqueta interna es la etiqueta IPv6 explícita-nula (etiqueta 2). La búsqueda basada en la etiqueta interna de la tabla de enrutamiento mpls.0 redirige a la tabla de enrutamiento mpls.0. En los enrutadores de la serie MX 3D, la etiqueta interna (etiqueta 2) se quita y se realiza una búsqueda IPv6 mediante la tabla de enrutamiento inet6.0.
Habilitación de LSP de PHP y UHP: puede configurar los LSP de PHP y UHP en las mismas rutas de red. Puede separar el tráfico PHP y UHP seleccionando reenviar los próximos saltos de LSP utilizando una expresión regular con la
install-nexthopinstrucción. También puede separar el tráfico simplemente asignando un nombre adecuado a los LSP.
Las siguientes instrucciones permiten el estallido de salto máximo para un LSP. Puede habilitar esta función en un LSP específico o para todos los LSP de entrada configurados en el enrutador. Configure estas instrucciones en el enrutador en la entrada del LSP.
Configuración de RSVP para que aparezca la etiqueta en el enrutador de salto final
Puede controlar el valor de etiqueta anunciado en el enrutador de salida de un LSP. La etiqueta anunciada predeterminada es la etiqueta 3 (etiqueta nula implícita). Si se anuncia la etiqueta 3, el enrutador del penúltimo salto quita la etiqueta y envía el paquete al enrutador de salida. Cuando está habilitado el estallido de salto definitivo, se anuncia la etiqueta 0 (etiqueta IP versión 4 [IPv4] nula explícita). El último salto garantiza que cualquier paquete que atraviese una red MPLS incluya una etiqueta.
Los enrutadores de Juniper Networks ponen en cola los paquetes según la etiqueta entrante. Los enrutadores de otros proveedores pueden poner los paquetes en cola de manera diferente. Tenga esto en cuenta cuando trabaje con redes que contengan enrutadores de varios proveedores.
Para configurar el último salto emergente para RSVP, incluya la 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 estallido de salto máximo en LSP de punto a multipunto
De forma predeterminada, tanto para los LSP punto a punto como para los multipunto, se usa el estallido de penúltimo salto para el tráfico MPLS. Las etiquetas MPLS se quitan de los paquetes del enrutador justo antes del enrutador de salida del LSP. Los paquetes IP simples se reenvían al enrutador de salida. Para la ventana emergente de último salto, el enrutador de salida es responsable tanto de eliminar la etiqueta MPLS como de procesar el paquete IP simple.
Puede ser beneficioso habilitar la aparición de saltos máximos en LSP de punto a multipunto, especialmente cuando el tráfico de tránsito atraviesa el mismo dispositivo de salida. Si habilita el popping, se puede enviar una sola copia del tráfico a través del enlace entrante, lo que ahorra un ancho de banda significativo. De forma predeterminada, el estallido de salto final está deshabilitado.
Para habilitar el estallido de salto máximo para los LSP de punto a multipunto, configure la tunnel-services instrucción. Cuando se habilita la ventana emergente de salto máximo, Junos OS selecciona una de las interfaces de túnel de circuito cerrado virtual (VT) disponibles para devolver los paquetes al PFE para el reenvío de IP. De forma predeterminada, el proceso de selección de la interfaz VT se realiza automáticamente. El control de admisión de ancho de banda se usa para limitar el número de LSP que se pueden usar en una interfaz VT. Una vez consumido todo el ancho de banda en una interfaz, Junos OS selecciona otra interfaz VT con suficiente ancho de banda para el control de admisión.
Si un LSP requiere más ancho de banda del que está disponible en cualquiera de las interfaces de VT, no se puede habilitar el estallido de salto final y, en su lugar, se habilita el estallido de penúltimo salto.
Para que la aparición de salto máximo en los LSP de punto a multipunto funcione correctamente, el enrutador de salida debe tener una PIC que proporcione servicios de túnel, como la PIC de servicios de túnel o la PIC de servicios adaptativos. Los servicios de túnel son necesarios para abrir la etiqueta MPLS final y para devolver paquetes para búsquedas de direcciones IP.
Puede configurar explícitamente qué interfaces VT manejan el tráfico RSVP incluyendo la devices opción para la tunnel-services instrucción. La devices opción le permite especificar qué interfaces VT deben ser utilizadas por RSVP. Si no configura esta opción, se pueden utilizar todas las interfaces VT disponibles para el enrutador.
Para habilitar la aparición de salto máximo para los LSP punto a multipunto de salida de un enrutador, configure la tunnel-services instrucción:
tunnel-services { devices device-names; }
Puede configurar esta instrucción en los siguientes niveles jerárquicos:
[edit protocols rsvp][edit logical-systems logical-system-name protocols rsvp]
Para habilitar el estallido de salto máximo para los LSP punto a multipunto de salida, también debe configurar la interface instrucción con la all opción:
interface all;
Debe configurar esta instrucción en el nivel de [edit protocols rsvp] jerarquía.
Seguimiento del tráfico del protocolo RSVP
Para realizar un seguimiento del tráfico del protocolo RSVP, incluya la traceoptions instrucción:
traceoptions { file filename <files number> <size size> <world-readable | no-world-readable>; flag flag <flag-modifier> <disable>; }
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit protocols rsvp][edit logical-systems logical-system-name protocols rsvp]
Puede especificar los siguientes indicadores específicos de RSVP en la instrucción RSVP traceoptions :
Utilice la file instrucción para especificar el nombre del archivo que recibe el resultado de la operación de seguimiento. Todos los archivos se colocan en el directorio /var/log. Se recomienda colocar el resultado del seguimiento RSVP en el archivo rsvp-log.
all—Todas las operaciones de rastreo.error—Todas las condiciones de error detectadasevent—Eventos relacionados con RSVP (ayuda a rastrear eventos relacionados con el reinicio correcto de RSVP)lmp—Interacciones del protocolo de administración RSVP-Link (LMP)packets—Todos los paquetes RSVPpath—Todos los mensajes de rutapathtear—Mensajes de PathTearresv—Mensajes Resvresvtear—Mensajes de ResvTearroute—Información de enrutamientostate—Transiciones de estado de sesión, incluso cuando los LSP señalados por RSVP suben y bajan.
Use el indicador de rastreo y el all modificador de indicador detail con precaución, ya que podrían hacer que la CPU se vuelva muy ocupada.
Para ver el archivo de registro generado al habilitar RSVP traceoptions, ejecute el show log file-name comando, donde file-name es el archivo que especificó mediante la traceoptions instrucción.
Para obtener información general acerca del seguimiento y las opciones de rastreo global, consulte la Biblioteca de protocolos de enrutamiento de Junos OS para dispositivos de enrutamiento.
Ejemplos: Seguimiento del tráfico del protocolo RSVP
Rastree los mensajes de ruta RSVP en detalle:
[edit]
protocols {
rsvp {
traceoptions {
file rsvp size 10m files 5;
flag path;
}
}
}
Rastree todos los mensajes RSVP:
[edit]
protocols {
rsvp {
traceoptions {
file rsvp size 10m files 5;
flag packets;
}
}
}
Rastree todas las condiciones de error de RSVP:
[edit]
protocols {
rsvp {
traceoptions {
file rsvp size 10m files 5;
flag error;
}
}
}
Transiciones de estado de RSVP de seguimiento:
[edit]
protocols {
rsvp {
traceoptions {
file rsvp-data;
flag state;
}
}
}
Salida del archivo de registro RSVP
A continuación se muestra un ejemplo de salida generado al emitir el show log file-name comando en un enrutador en el que se han habilitado traceoptions RSVP con el state indicador configurado. El LSP E-D con señal RSVP se muestra siendo derribado el Mar 11 14:04:36.707092. El Mar 11 14:05:30.101492, se muestra volviendo a subir.
user@host> show log rsvp-data
Mar 11 13:58:51 trace_on: Tracing to "/var/log/E/rsvp-data" started
Mar 11 13:58:51.286413 rsvp_iflchange for vt ifl vt-1/2/0.69206016
Mar 11 13:58:51.286718 RSVP add interface vt-1/2/0.69206016, ifindex 101, ifaddr (null), family 1, is_appl_vt 0, already known
Mar 11 13:58:51.286818 RSVP Peer vt-1/2/0.69206016 TE-link __rpd:vt-1/2/0.69206016 Up
Mar 11 13:58:51.286978 RSVP add interface vt-1/2/0.69206016, ifindex 101, ifaddr (null), family 3, is_appl_vt 0, already known
Mar 11 13:58:51.287962 RSVP add interface lt-1/2/0.2, ifindex 113, ifaddr (null), family 2, is_appl_vt 0, already known
Mar 11 13:58:51.288629 RSVP add interface lt-1/2/0.2, ifindex 113, ifaddr 10.0.0.2, family 1, is_appl_vt 0, already known
Mar 11 13:58:51.288996 RSVP add interface lt-1/2/0.17, ifindex 114, ifaddr (null), family 2, is_appl_vt 0, already known
Mar 11 13:58:51.289593 RSVP add interface lt-1/2/0.17, ifindex 114, ifaddr (null), family 3, is_appl_vt 0, already known
Mar 11 13:58:51.289949 RSVP add interface lt-1/2/0.17, ifindex 114, ifaddr 10.0.0.17, family 1, is_appl_vt 0, already known
Mar 11 13:58:51.290049 RSVP Peer lt-1/2/0.17 TE-link __rpd:lt-1/2/0.17 Up
Mar 11 13:59:05.042034 RSVP new bypass Bypass->10.0.0.18 on interface lt-1/2/0.17 to 10.0.0.18 avoid 0.0.0.0
Mar 11 14:04:36.707092 LSP "E-D" is Down (Reason: Reservation state deleted)
Session: 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0 Sender: 192.168.0.5(port/lsp ID 1)
Mar 11 14:04:36.707661 RSVP delete resv state, session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0
Mar 11 14:04:36.781185 RSVP delete path state, session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0
Mar 11 14:04:36.781440 RSVP delete session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0
Mar 11 14:05:30.101492 RSVP new Session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0, session ID 3
Mar 11 14:05:30.101722 RSVP new path state, session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0
Mar 11 14:05:30.179124 RSVP new resv state, session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0
Mar 11 14:05:30.179395 RSVP PSB E-D, allocating psb resources for label 4294967295
Mar 11 14:05:30.180353 LSP "E-D" is Up
Session: 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0 Sender: 192.168.0.5(port/lsp ID 2)RSVP Reinicio agraciado
El reinicio correcto RSVP permite que un enrutador que se somete a un reinicio informe a sus vecinos adyacentes de su condición. El enrutador de reinicio solicita un período de gracia al vecino o par, que luego puede cooperar con el enrutador de reinicio. El enrutador que se reinicia aún puede reenviar tráfico MPLS durante el período de reinicio; La convergencia en la red no se interrumpe. El reinicio no es visible para el resto de la red y el enrutador de reinicio no se elimina de la topología de red. El reinicio correcto de RSVP se puede habilitar tanto en enrutadores de tránsito como en enrutadores de entrada. Está disponible tanto para LSP punto a punto como para LSP punto a multipunto.
El reinicio correcto de RSVP se describe en las siguientes secciones:
Terminología de reinicio correcto de RSVP
Tiempo de reinicio (en milisegundos)
El valor predeterminado es 60.000 milisegundos (1 minuto). La hora de reinicio se anuncia en el mensaje de saludo. El tiempo indica cuánto tiempo debe esperar un vecino para recibir un mensaje de saludo de un enrutador que se reinicia antes de declarar ese enrutador muerto y estados de purga.
Junos OS puede anular el tiempo de reinicio anunciado por un vecino si el tiempo es superior a un tercio del tiempo de reinicio local. Por ejemplo, dado el tiempo de reinicio predeterminado de 60 segundos, un enrutador esperaría 20 segundos o menos para recibir un mensaje de saludo de un vecino que se reinicia. Si el tiempo de reinicio es cero, el vecino de reinicio puede ser declarado muerto inmediatamente.
Tiempo de recuperación (en milisegundos)
Solo se aplica cuando el canal de control está activo (el intercambio de saludos se ha completado) antes de la hora de reinicio. Solo se aplica a errores nodales.
Cuando un reinicio correcto está en curso, se anuncia el tiempo restante para completar una recuperación. En otras ocasiones, este valor es cero. El tiempo máximo de recuperación anunciado es de 2 minutos (120 000 milisegundos).
Durante el tiempo de recuperación, un nodo de reinicio intenta recuperar sus estados perdidos con la ayuda de sus vecinos. El vecino del nodo de reinicio debe enviar los mensajes de ruta con las etiquetas de recuperación al nodo de reinicio en un plazo de la mitad del tiempo de recuperación. El nodo de reinicio considera que su reinicio correcto se ha completado después del tiempo de recuperación anunciado.
Operación de reinicio correcto RSVP
Para que el reinicio correcto de RSVP funcione, la función debe estar habilitada en la instancia de enrutamiento global. El reinicio correcto de RSVP se puede deshabilitar a nivel de protocolo (solo para RSVP) o a nivel global para todos los protocolos.
El reinicio correcto de RSVP requiere lo siguiente de un enrutador de reinicio y de los vecinos del enrutador:
Para el enrutador que se reinicia, RSVP correctamente restart intenta mantener las rutas instaladas por RSVP y las etiquetas asignadas, de modo que el tráfico continúe reenviándose sin interrupciones. El reinicio correcto de RSVP se realiza lo suficientemente rápido como para reducir o eliminar el impacto en los nodos vecinos.
Los enrutadores vecinos deben tener habilitado el modo auxiliar de reinicio correcto RSVP, lo que les permite ayudar a un enrutador que intenta reiniciar RSVP.
Un objeto denominado Restart Cap que se envía en mensajes de saludo RSVP anuncia la capacidad de reinicio de un nodo. El nodo vecino envía un objeto Recover Label al nodo de reinicio para recuperar su estado de reenvío. Este objeto es esencialmente la etiqueta antigua que el nodo de reinicio anunciaba antes de que el nodo dejara de funcionar.
A continuación se enumeran los comportamientos de reinicio correcto de RSVP, que varían según la configuración y las características habilitadas:
Si deshabilita el modo auxiliar, Junos OS no intentará ayudar a un vecino a reiniciar su asistencia. Se omite cualquier información que llegue de un vecino con un objeto Restart Cap.
Cuando habilita el reinicio correcto en la configuración de la instancia de enrutamiento, el enrutador puede reiniciarse correctamente con la ayuda de sus vecinos. RSVP anuncia un objeto Restart Cap (RSVP RESTART) en mensajes de saludo en los que se especifican tiempos de reinicio y recuperación (ninguno de los valores es 0).
Si deshabilita explícitamente el reinicio correcto RSVP en el nivel de
[protocols rsvp]jerarquía, el objeto Restart Cap se anuncia con tiempos de reinicio y recuperación especificados como 0. Se admite el reinicio de enrutadores vecinos (a menos que el modo auxiliar esté deshabilitado), pero el enrutador en sí no conserva el estado de reenvío RSVP y no puede recuperar su estado de control.Si después de un RSVP de reinicio se da cuenta de que no se ha conservado ningún estado de reenvío, el objeto Restart Cap se anuncia con tiempos de reinicio y recuperación especificados como 0.
Si el reinicio correcto y el modo auxiliar están desactivados, el reinicio correcto de RSVP está completamente deshabilitado. El enrutador no reconoce ni anuncia los objetos de reinicio correcto RSVP.
No puede configurar explícitamente valores para los tiempos de reinicio y recuperación.
A diferencia de otros protocolos, no hay forma de que RSVP determine que ha completado un procedimiento de reinicio, aparte de un tiempo de espera fijo. Todos los procedimientos de reinicio correcto de RSVP se basan en el temporizador. Un show rsvp version comando puede indicar que el reinicio aún está en curso, incluso si se ha realizado una copia de seguridad de todas las sesiones RSVP y se restauran las rutas.
Procesamiento del objeto Cap de reinicio
Se hacen las siguientes suposiciones sobre un vecino basadas en el objeto Restart Cap (suponiendo que una falla del canal de control se puede distinguir inequívocamente de un reinicio de nodo):
Un vecino que no anuncia el objeto Restart Cap en sus mensajes de saludo no puede ayudar a un enrutador con la recuperación de estado o etiqueta, ni puede realizar un reinicio correcto de RSVP.
Después de un reinicio, un vecino que anuncia un objeto Restart Cap con un tiempo de reinicio igual a cualquier valor y un tiempo de recuperación igual a 0 no ha conservado su estado de reenvío. Cuando un tiempo de recuperación es igual a 0, el vecino se considera muerto y cualquier estado relacionado con este vecino se purga, independientemente del valor del tiempo de reinicio.
Después de un reinicio, un vecino que anuncia su tiempo de recuperación con un valor distinto de 0 puede mantener o ha mantenido el estado de reenvío. Si el enrutador local está ayudando a su vecino con los procedimientos de reinicio o recuperación, envía un objeto Recover Label a este vecino.
Configuración de RSVP Graceful Restart
Son posibles las siguientes configuraciones de reinicio correcto RSVP:
El reinicio elegante y el modo auxiliar están habilitados (predeterminado).
El reinicio correcto está habilitado, pero el modo auxiliar está deshabilitado. Un enrutador configurado de esta manera puede reiniciarse correctamente, pero no puede ayudar a un vecino con sus procedimientos de reinicio y recuperación.
El reinicio correcto está deshabilitado, pero el modo auxiliar está habilitado. Un enrutador configurado de esta manera no puede reiniciarse correctamente, pero puede ayudar a un vecino a reiniciar.
El reinicio elegante y el modo auxiliar están deshabilitados. Esta configuración deshabilita completamente el reinicio correcto de RSVP (incluidos los procedimientos de reinicio y recuperación y el modo auxiliar). El enrutador se comporta como un enrutador que no admite el reinicio correcto de RSVP.
Para activar el reinicio correcto de RSVP, debe establecer el temporizador de reinicio correcto global en al menos 180 segundos.
En las secciones siguientes se describe cómo configurar el reinicio correcto de RSVP:
- Habilitación de un reinicio correcto para todos los protocolos de enrutamiento
- Deshabilitar el reinicio correcto para RSVP
- Deshabilitar el modo auxiliar RSVP
- Configuración del tiempo máximo de recuperación auxiliar
- Configuración del tiempo máximo de reinicio auxiliar
Habilitación de un reinicio correcto para todos los protocolos de enrutamiento
Para habilitar el reinicio correcto para RSVP, debe habilitar el reinicio correcto para todos los protocolos que admiten el reinicio correcto en el enrutador. Para obtener más información acerca del reinicio correcto, consulte la Biblioteca de protocolos de enrutamiento de Junos OS para dispositivos de enrutamiento.
Para habilitar el reinicio correcto en el enrutador, incluya la 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 correcto para RSVP
De forma predeterminada, el reinicio correcto RSVP y el modo auxiliar RSVP están habilitados cuando se habilita el reinicio correcto. Sin embargo, puede deshabilitar una o ambas de estas capacidades.
Para deshabilitar el reinicio y la recuperación correctos de RSVP, incluya la disable instrucción en el nivel jerárquico [edit protocols rsvp graceful-restart] :
disable;
Deshabilitar el modo auxiliar RSVP
Para deshabilitar el modo auxiliar RSVP, incluya la helper-disable instrucción en el nivel de [edit protocols rsvp graceful-restart] jerarquía:
helper-disable;
Configuración del tiempo máximo de recuperación auxiliar
Para configurar la cantidad de tiempo que el enrutador conserva el estado de sus vecinos RSVP mientras se someten a un reinicio correcto, incluya la maximum-helper-recovery-time instrucción en el [edit protocols rsvp graceful-restart] nivel de jerarquía. Este valor se aplica a todos los enrutadores vecinos, por lo que debe basarse en el tiempo requerido por el vecino RSVP más lento para recuperarse.
maximum-helper-recovery-time seconds;
Configuración del tiempo máximo de reinicio auxiliar
Para configurar el retraso entre el momento en que el enrutador descubre que un enrutador vecino ha caído y el momento en que declara que el vecino está inactivo, incluya la maximum-helper-restart-time instrucción en el nivel de [edit protocols rsvp graceful-restart] jerarquía. Este valor se aplica a todos los enrutadores vecinos, por lo que debe basarse en el tiempo requerido por el vecino RSVP más lento para reiniciar.
maximum-helper-restart-time seconds;
Descripción general de los túneles LSP de RSVP
Un túnel de ruta de conmutación de etiquetas (LSP) del Protocolo de reserva de recursos (RSVP) le permite enviar LSP de RSVP dentro de otros LSP de RSVP. Esto permite que un administrador de red proporcione ingeniería de tráfico de un extremo a otro de la red. Una aplicación útil para esta característica es conectar enrutadores perimetrales de cliente (CE) con enrutadores perimetrales de proveedor (PE) mediante un LSP RSVP y, a continuación, tunelizar este LSP de borde dentro de un segundo LSP RSVP que viaja a través del núcleo de la red.
Debe tener una comprensión general de los conceptos de MPLS y conmutación de etiquetas. Para obtener más información acerca de MPLS, consulte la Guía de configuración de aplicaciones MPLS de Junos.
Un túnel RSVP LSP agrega el concepto de una adyacencia de reenvío, similar a la que se usa para la conmutación de etiquetas multiprotocolo generalizada (GMPLS). (Para obtener más información acerca de GMPLS, consulte la Guía del usuario de Junos GMPLS.
La adyacencia de reenvío crea una ruta tunelizada para enviar datos entre dispositivos pares en una red RSVP LSP. Una vez que se ha establecido un LSP de adyacencia de reenvío (FA-LSP), se pueden enviar otros LSP a través del FA-LSP utilizando primero la ruta restringida más corta (CSPF), el Protocolo de administración de vínculos (LMP), la ruta abierta más corta primero (OSPF) y RSVP.
Para habilitar un túnel RSVP LSP, Junos OS utiliza los siguientes mecanismos:
LMP: originalmente diseñado para GMPLS, LMP establece adyacencias de reenvío entre pares de túnel RSVP LSP, y mantiene y asigna recursos para enlaces de ingeniería de tráfico.
Extensiones OSPF: OSPF fue diseñado para enrutar paquetes a interfaces físicas y lógicas relacionadas con una tarjeta de interfaz física (PIC). Este protocolo se ha extendido para enrutar paquetes a interfaces virtuales del mismo nivel definidas en una configuración LMP.
Extensiones RSVP-TE: RSVP-TE fue diseñado para señalar la configuración de LSP de paquetes en interfaces físicas. El protocolo se ha extendido para solicitar la configuración de rutas para paquetes LSP que viajan a interfaces virtuales del mismo nivel definidas en una configuración LMP.
Nota:A partir de Junos OS versión 15.1, la compatibilidad con varias instancias se amplía a MPLS RSVP-TE. Esta compatibilidad solo está disponible para el tipo de instancia de enrutador virtual. Un enrutador puede crear y participar en varias particiones de topología TE independientes, lo que permite que cada dominio TE particionado escale de forma independiente. El RSVP-TE de varias instancias proporciona la flexibilidad para seleccionar manualmente las entidades del plano de control que deben tener en cuenta las instancias; por ejemplo, un enrutador puede participar en varias instancias de TE mientras se ejecuta una sola instancia de BGP.
La implementación de MPLS RSVP-TE de Junos OS se escala para mejorar la usabilidad, visibilidad, configuración y solución de problemas de los LSP en Junos OS versión 16.1.
Estas mejoras facilitan la configuración de RSVP-TE a escala al:
Garantizar la preparación del plano de datos del LSP durante la reseñalización del LSP antes de que el tráfico atraviese el LSP con el mecanismo de autoping del LSP RSVP-TE.
Un LSP no debe comenzar a transportar tráfico a menos que se sepa que ha sido programado en el plano de datos. El intercambio de datos en el plano de datos de LSP, como las solicitudes de ping de LSP, tiene lugar en el enrutador de entrada antes de cambiar el tráfico a un LSP o a su instancia de MBB. En redes grandes, este tráfico puede abrumar a un enrutador de salida de LSP, ya que el LSP de salida necesita responder a las solicitudes de ping de LSP. El mecanismo de autoping LSP permite que el LER de entrada cree mensajes de respuesta ping LSP y los envíe a través del plano de datos LSP. Al recibir estos mensajes, el LER de salida los reenvía a la entrada, lo que indica la vivacidad del plano de datos LSP. Esto garantiza que el LSP no comience a transportar tráfico antes de que se haya programado el plano de datos.
Eliminación del límite rígido actual de LSP de 64K en un enrutador de entrada y escalamiento del número total de LSP con LSP señalados RSVP-TE. Puede haber hasta 64 mil LSP configurados por salida. Anteriormente, este límite era el número agregado de LSP que se podían configurar en el LER de entrada.
Evitar el desmontaje brusco de los LSP por parte del enrutador de entrada debido al retraso en la señalización del LSP en los enrutadores de tránsito.
Permite una vista flexible de los conjuntos de datos de LSP para facilitar la visualización de datos característicos de LSP.
Nota:A partir de Junos OS versión 17.4, se introduce un temporizador predeterminado de 1800 segundos para el autoping.
Existen las siguientes limitaciones para las jerarquías de LSP:
No se admiten los LSP basados en conexión cruzada de circuitos (CCC).
No se admite el reinicio correcto.
La protección de vínculo no está disponible para FA-LSP ni en el punto de salida de la adyacencia de reenvío.
Los LSP de punto a multipunto no son compatibles con los FA-LSP.
Ejemplo: Configuración del túnel RSVP LSP
Figura 5 muestra un LSP RSVP de extremo a extremo llamado e2e_lsp_r0r5 que se origina en el enrutador 0 y termina en el enrutador 5. En tránsito, este LSP atraviesa el FA-LSP fa_lsp_r1r4. La ruta de retorno está representada por el LSP e2e_lsp_r5r0 RSVP de extremo a extremo que viaja sobre el FA-LSP fa_lsp_r4r1.
En el enrutador 0, configure el LSP RSVP de extremo a extremo que viaja al enrutador 5. Utilice una ruta estricta que atraviese el enrutador 1 y el vínculo de ingeniería de tráfico LMP que viaja del enrutador 1 al enrutador 4.
Enrutador 0
[edit]
interfaces {
so-0/0/3 {
unit 0 {
family inet {
address 10.1.2.1/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.41.222/32;
}
family mpls;
}
}
}
routing-options {
forwarding-table {
export pplb;
}
}
protocols {
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
admin-groups {
fa 1;
backup 2;
other 3;
}
label-switched-path e2e_lsp_r0r5 { # An end-to-end LSP traveling to Router 5.
to 10.255.41.221;
bandwidth 30k;
primary path-fa; # Reference the requested path here.
}
path path-fa { # Configure the strict path here.
10.1.2.2 strict;
172.16.30.2 strict; # This traverses the TE link heading to Router 4.
}
interface all;
interface fxp0.0 {
disable;
}
interface so-3/2/1.0 {
admin-group other;
}
interface so-0/0/3.0 {
admin-group other;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface all;
}
}
}
policy-options {
policy-statement pplb {
then {
load-balance per-packet;
}
}
}
En el enrutador 1, configure un FA-LSP para llegar al enrutador 4. Establezca un vínculo de ingeniería de tráfico LMP y una relación par LMP con el enrutador 4. Haga referencia al FA-LSP en el vínculo de ingeniería de tráfico y agregue la interfaz del mismo nivel tanto en OSPF como en RSVP.
Cuando el LSP de extremo a extremo de la ruta de retorno llega al enrutador 1, la plataforma de enrutamiento realiza una búsqueda de enrutamiento y puede reenviar tráfico al enrutador 0. Asegúrese de configurar OSPF correctamente entre los enrutadores 0 y 1.
Enrutador 1
[edit]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.2.3.1/30;
}
family mpls;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.2.4.1/30;
}
family mpls;
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.1.2.2/30;
}
family mpls;
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.2.5.1/30;
}
family mpls;
}
}
at-1/0/0 {
atm-options {
vpi 1;
}
unit 0 {
vci 1.100;
family inet {
address 10.2.3.5/30;
}
family mpls;
}
}
}
routing-options {
forwarding-table {
export [ pplb choose_lsp ];
}
}
protocols {
rsvp {
interface all;
interface fxp0.0 {
disable;
}
peer-interface r4; # Apply the LMP peer interface here.
}
mpls {
admin-groups {
fa 1;
backup 2;
other 3;
}
label-switched-path fa_lsp_r1r4 { # Configure your FA-LSP to Router 4 here.
to 10.255.41.217;
bandwidth 400k;
primary path_r1r4; # Apply the FA-LSP path here.
}
path path_r1r4 { # Configure the FA-LSP path here.
10.2.4.2;
10.4.5.2;
10.3.5.1;
}
interface so-0/0/3.0 {
admin-group other;
}
interface so-0/0/1.0 {
admin-group fa;
}
interface at-1/0/0.0 {
admin-group backup;
}
interface fe-0/1/2.0 {
admin-group backup;
}
interface so-0/0/2.0 {
admin-group fa;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface all;
peer-interface r4; # Apply the LMP peer interface here.
}
}
link-management { # Configure LMP statements here.
te-link link_r1r4 { # Assign a name to the TE link here.
local-address 172.16.30.1; # Configure a local address for the TE link.
remote-address 172.16.30.2; # Configure a remote address for the TE link.
te-metric 1; # Manually set a metric here if you are not relying on CSPF.
label-switched-path fa_lsp_r1r4; # Reference the FA-LSP here.
}
peer r4 { # Configure LMP peers here.
address 10.255.41.217; # Configure the loopback address of your peer here.
te-link link_r1r4; # Apply the LMP TE link here.
}
}
}
policy-options {
policy-statement choose_lsp {
term A {
from community choose_e2e_lsp;
then {
install-nexthop strict lsp e2e_lsp_r1r4;
accept;
}
}
term B {
from community choose_fa_lsp;
then {
install-nexthop strict lsp fa_lsp_r1r4;
accept;
}
}
}
policy-statement pplb {
then {
load-balance per-packet;
}
}
community choose_e2e_lsp members 1000:1000;
community choose_fa_lsp members 2000:2000;
community set_e2e_lsp members 1000:1000;
community set_fa_lsp members 2000:2000;
}
En el enrutador 2, configure OSPF, MPLS y RSVP en todas las interfaces que transportan los FA-LSP a través de la red principal.
Enrutador 2
[edit]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.4.5.1/30;
}
family mpls;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.1.4.2/30;
}
family mpls;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.2.4.2/30;
}
family mpls;
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.3.4.2/30;
}
family mpls;
}
}
}
routing-options {
forwarding-table {
export pplb;
}
}
protocols { # OSPF, MPLS, and RSVP form the core backbone for the FA-LSPs.
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
admin-groups {
fa 1;
backup 2;
other 3;
}
path path_r1 {
10.2.4.1;
}
path path_r3r4 {
10.4.5.2;
10.3.5.1;
}
interface all;
interface fxp0.0 {
disable;
}
interface so-0/0/1.0 {
admin-group other;
}
interface fe-0/1/2.0 {
admin-group backup;
}
interface so-0/0/2.0 {
admin-group fa;
}
interface so-0/0/0.0 {
admin-group fa;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface all;
}
}
}
policy-options {
policy-statement pplb {
then {
load-balance per-packet;
}
}
}
En el enrutador 3, configure OSPF, MPLS y RSVP en todas las interfaces que transportan los FA-LSP a través de la red principal.
Enrutador 3
[edit]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.4.5.2/30;
}
family mpls;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.5.6.1/30;
}
family mpls;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.3.5.2/30;
}
family mpls;
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.2.5.2/30;
}
family mpls;
}
}
}
routing-options {
forwarding-table {
export pplb;
}
}
protocols { # OSPF, MPLS, and RSVP form the core backbone for the FA-LSPs.
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
admin-groups {
fa 1;
backup 2;
other 3;
}
path path_r4 {
10.3.5.1;
}
path path_r2r1 {
10.4.5.1;
10.2.4.1;
}
interface all;
interface fxp0.0 {
disable;
}
interface so-0/0/2.0 {
admin-group fa;
}
interface fe-0/1/2.0 {
admin-group backup;
}
interface so-0/0/1.0 {
admin-group other;
}
interface so-0/0/0.0 {
admin-group fa;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface all;
}
}
}
policy-options {
policy-statement pplb {
then {
load-balance per-packet;
}
}
}
En el enrutador 4, configure una ruta de retorno FA-LSP para llegar al enrutador 1. Establezca un vínculo de ingeniería de tráfico LMP y una relación par LMP con el enrutador 1. Haga referencia al FA-LSP en el vínculo de ingeniería de tráfico y agregue la interfaz del mismo nivel tanto en OSPF como en RSVP.
Cuando el LSP inicial de extremo a extremo llega al enrutador 4, la plataforma de enrutamiento realiza una búsqueda de enrutamiento y puede reenviar tráfico al enrutador 5. Asegúrese de configurar OSPF correctamente entre el enrutador 4 y el enrutador 5.
Enrutador 4
[edit]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.3.6.1/30;
}
family mpls;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.2.3.2/30;
}
family mpls;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.3.5.1/30;
}
family mpls;
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.3.4.1/30;
}
family mpls;
}
}
at-1/0/0 {
atm-options {
vpi 1;
}
unit 0 {
vci 1.100;
family inet {
address 10.2.3.6/30;
}
family mpls;
}
}
}
routing-options {
forwarding-table {
export [ pplb choose_lsp ];
}
}
protocols {
rsvp {
interface all;
interface fxp0.0 {
disable;
}
peer-interface r1; # Apply the LMP peer interface here.
}
mpls {
admin-groups {
fa 1;
backup 2;
other 3;
}
label-switched-path fa_lsp_r4r1 { # Configure your FA-LSP here.
to 10.255.41.216;
bandwidth 400k;
primary path_r4r1; # Apply the FA-LSP path here.
}
path path_r4r1 { # Configure the FA-LSP path here.
10.3.5.2;
10.4.5.1;
10.2.4.1;
}
interface all;
interface fxp0.0 {
disable;
}
interface at-1/0/0.0 {
admin-group backup;
}
interface so-0/0/2.0 {
admin-group fa;
}
interface fe-0/1/2.0 {
admin-group backup;
}
interface so-0/0/0.0 {
admin-group other;
}
interface so-0/0/1.0 {
admin-group fa;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface all;
peer-interface r1; # Apply the LMP peer interface here.
}
}
link-management { # Configure LMP statements here.
te-link link_r4r1 { # Assign a name to the TE link here.
local-address 172.16.30.2; # Configure a local address for the TE link.
remote-address 172.16.30.1; # Configure a remote address for the TE link.
te-metric 1; # Manually set a metric here if you are not relying on CSPF.
label-switched-path fa_lsp_r4r1; # Reference the FA-LSP here.
}
peer r1 { # Configure LMP peers here.
address 10.255.41.216; # Configure the loopback address of your peer here.
te-link link_r4r1; # Apply the LMP TE link here.
}
}
}
policy-options {
policy-statement choose_lsp {
term A {
from community choose_e2e_lsp;
then {
install-nexthop strict lsp e2e_lsp_r4r1;
accept;
}
}
term B {
from community choose_fa_lsp;
then {
install-nexthop strict lsp fa_lsp_r4r1;
accept;
}
}
}
policy-statement pplb {
then {
load-balance per-packet;
}
}
community choose_e2e_lsp members 1000:1000;
community choose_fa_lsp members 2000:2000;
community set_e2e_lsp members 1000:1000;
community set_fa_lsp members 2000:2000;
}
En el enrutador 5, configure la ruta de retorno del LSP RSVP de extremo a extremo que viaja al enrutador 0. Utilice una ruta estricta que atraviese el enrutador 4 y el vínculo de ingeniería de tráfico LMP que viaja del enrutador 4 al enrutador 1.
Enrutador 5
[edit]
interfaces {
so-0/0/2 {
unit 0 {
family inet {
address 10.3.6.2/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.41.221/32;
}
}
}
}
routing-options {
forwarding-table {
export pplb;
}
}
protocols {
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
admin-groups {
fa 1;
backup 2;
other 3;
}
label-switched-path e2e_lsp_r5r0 { # An end-to-end LSP returning to Router 0.
to 10.255.41.222;
bandwidth 30k;
primary path-fa; # Reference the requested path here.
}
path path-fa { # Configure the strict path here.
10.3.6.1 strict;
172.16.30.1 strict; # This traverses the TE link heading to Router 1.
}
interface all;
interface fxp0.0 {
disable;
}
interface so-0/0/2.0 {
admin-group other;
}
interface so-0/0/1.0 {
admin-group other;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fxp0.0 {
disable;
}
interface all;
}
}
}
policy-options {
policy-statement pplb {
then {
load-balance per-packet;
}
}
}
Verificación de su trabajo
Para comprobar que el túnel RSVP LSP funciona correctamente, emita los siguientes comandos:
show ted database (extensive)show rsvp session name (extensive)show link-managementshow link-management te-link name (detail)
Para ver estos comandos utilizados con el ejemplo de configuración, consulte las siguientes secciones:
Enrutador 0
En el enrutador 0, puede comprobar que los FA-LSP aparecen como rutas válidas en la base de datos de ingeniería de tráfico. En este caso, busque las rutas del enrutador 1 (10.255.41.216) y del enrutador 4 (10.255.41.217) que hacen referencia a las direcciones de vínculo de ingeniería de tráfico LMP de 172.16.30.1 y 172.16.30.2. También puede emitir el show rsvp session extensive comando para buscar la ruta del LSP de extremo a extremo a medida que viaja al enrutador 5 a través del FA-LSP.
user@router0> show ted database
TED database: 0 ISIS nodes 8 INET nodes
ID Type Age(s) LnkIn LnkOut Protocol
10.255.41.214 Rtr 486 4 4 OSPF(0.0.0.0)
To: 10.255.41.222, Local: 10.1.4.2, Remote: 10.1.4.1
To: 10.255.41.216, Local: 10.2.4.2, Remote: 10.2.4.1
To: 10.255.41.215, Local: 10.4.5.1, Remote: 10.4.5.2
To: 10.3.4.1-1, Local: 10.3.4.2, Remote: 0.0.0.0
ID Type Age(s) LnkIn LnkOut Protocol
10.255.41.215 Rtr 187 4 4 OSPF(0.0.0.0)
To: 10.255.41.214, Local: 10.4.5.2, Remote: 10.4.5.1
To: 10.255.41.217, Local: 10.3.5.2, Remote: 10.3.5.1
To: 10.255.41.221, Local: 10.5.6.1, Remote: 10.5.6.2
To: 10.2.5.1-1, Local: 10.2.5.2, Remote: 0.0.0.0
ID Type Age(s) LnkIn LnkOut Protocol
10.255.41.216 Rtr 396 6 6 OSPF(0.0.0.0)
To: 10.255.41.222, Local: 10.1.2.2, Remote: 10.1.2.1
To: 10.255.41.214, Local: 10.2.4.1, Remote: 10.2.4.2
To: 10.255.41.217, Local: 10.2.3.1, Remote: 10.2.3.2
To: 10.255.41.217, Local: 172.16.30.1, Remote: 172.16.30.2
To: 10.255.41.217, Local: 10.2.3.5, Remote: 10.2.3.6
To: 10.2.5.1-1, Local: 10.2.5.1, Remote: 0.0.0.0
ID Type Age(s) LnkIn LnkOut Protocol
10.255.41.217 Rtr 404 6 6 OSPF(0.0.0.0)
To: 10.255.41.216, Local: 10.2.3.2, Remote: 10.2.3.1
To: 10.255.41.216, Local: 172.16.30.2, Remote: 172.16.30.1
To: 10.255.41.216, Local: 10.2.3.6, Remote: 10.2.3.5
To: 10.255.41.215, Local: 10.3.5.1, Remote: 10.3.5.2
To: 10.255.41.221, Local: 10.3.6.1, Remote: 10.3.6.2
To: 10.3.4.1-1, Local: 10.3.4.1, Remote: 0.0.0.0
ID Type Age(s) LnkIn LnkOut Protocol
10.255.41.221 Rtr 481 2 2 OSPF(0.0.0.0)
To: 10.255.41.215, Local: 10.5.6.2, Remote: 10.5.6.1
To: 10.255.41.217, Local: 10.3.6.2, Remote: 10.3.6.1
ID Type Age(s) LnkIn LnkOut Protocol
10.255.41.222 Rtr 2883 2 2 OSPF(0.0.0.0)
To: 10.255.41.216, Local: 10.1.2.1, Remote: 10.1.2.2
To: 10.255.41.214, Local: 10.1.4.1, Remote: 10.1.4.2
user@router0> show ted database 10.255.41.216 extensive
TED database: 0 ISIS nodes 8 INET nodes
NodeID: 10.255.41.216
Type: Rtr, Age: 421 secs, LinkIn: 6, LinkOut: 6
Protocol: OSPF(0.0.0.0)
To: 10.255.41.222, Local: 10.1.2.2, Remote: 10.1.2.1
Color: 0x8 other
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.4Mbps [1] 155.4Mbps [2] 155.4Mbps [3] 155.4Mbps
[4] 155.4Mbps [5] 155.4Mbps [6] 155.4Mbps [7] 155.4Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.4Mbps [1] 155.4Mbps [2] 155.4Mbps [3] 155.4Mbps
[4] 155.4Mbps [5] 155.4Mbps [6] 155.4Mbps [7] 155.4Mbps
To: 10.255.41.214, Local: 10.2.4.1, Remote: 10.2.4.2
Color: 0x2 fa
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.12Mbps [1] 155.12Mbps [2] 155.12Mbps [3] 155.12Mbps
[4] 155.12Mbps [5] 155.12Mbps [6] 155.12Mbps [7] 155.12Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.12Mbps [1] 155.12Mbps [2] 155.12Mbps [3] 155.12Mbps
[4] 155.12Mbps [5] 155.12Mbps [6] 155.12Mbps [7] 155.12Mbps
To: 10.255.41.217, Local: 10.2.3.1, Remote: 10.2.3.2
Color: 0x2 fa
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
To: 10.255.41.217, Local: 172.16.30.1, Remote: 172.16.30.2
Metric: 1
Static BW: 400kbps
Reservable BW: 400kbps
Available BW [priority] bps:
[0] 370kbps [1] 370kbps [2] 370kbps [3] 370kbps
[4] 370kbps [5] 370kbps [6] 370kbps [7] 370kbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 370kbps [1] 370kbps [2] 370kbps [3] 370kbps
[4] 370kbps [5] 370kbps [6] 370kbps [7] 370kbps
To: 10.255.41.217, Local: 10.2.3.5, Remote: 10.2.3.6
Color: 0x4 backup
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
To: 10.2.5.1-1, Local: 10.2.5.1, Remote: 0.0.0.0
Color: 0x4 backup
Metric: 1
Static BW: 100Mbps
Reservable BW: 100Mbps
Available BW [priority] bps:
[0] 100Mbps [1] 100Mbps [2] 100Mbps [3] 100Mbps
[4] 100Mbps [5] 100Mbps [6] 100Mbps [7] 100Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 100Mbps [1] 100Mbps [2] 100Mbps [3] 100Mbps
[4] 100Mbps [5] 100Mbps [6] 100Mbps [7] 100Mbps
user@router0> show ted database 10.255.41.217 extensive
TED database: 0 ISIS nodes 8 INET nodes
NodeID: 10.255.41.217
Type: Rtr, Age: 473 secs, LinkIn: 6, LinkOut: 6
Protocol: OSPF(0.0.0.0)
To: 10.255.41.216, Local: 10.2.3.2, Remote: 10.2.3.1
Color: 0x2 fa
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
To: 10.255.41.216, Local: 172.16.30.2, Remote: 172.16.30.1
Metric: 1
Static BW: 400kbps
Reservable BW: 400kbps
Available BW [priority] bps:
[0] 370kbps [1] 370kbps [2] 370kbps [3] 370kbps
[4] 370kbps [5] 370kbps [6] 370kbps [7] 370kbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 370kbps [1] 370kbps [2] 370kbps [3] 370kbps
[4] 370kbps [5] 370kbps [6] 370kbps [7] 370kbps
To: 10.255.41.216, Local: 10.2.3.6, Remote: 10.2.3.5
Color: 0x4 backup
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
To: 10.255.41.215, Local: 10.3.5.1, Remote: 10.3.5.2
Color: 0x2 fa
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.12Mbps [1] 155.12Mbps [2] 155.12Mbps [3] 155.12Mbps
[4] 155.12Mbps [5] 155.12Mbps [6] 155.12Mbps [7] 155.12Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.12Mbps [1] 155.12Mbps [2] 155.12Mbps [3] 155.12Mbps
[4] 155.12Mbps [5] 155.12Mbps [6] 155.12Mbps [7] 155.12Mbps
To: 10.255.41.221, Local: 10.3.6.1, Remote: 10.3.6.2
Color: 0x8 other
Metric: 1
Static BW: 155.52Mbps
Reservable BW: 155.52Mbps
Available BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps
[4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps
To: 10.3.4.1-1, Local: 10.3.4.1, Remote: 0.0.0.0
Color: 0x4 backup
Metric: 1
Static BW: 100Mbps
Reservable BW: 100Mbps
Available BW [priority] bps:
[0] 100Mbps [1] 100Mbps [2] 100Mbps [3] 100Mbps
[4] 100Mbps [5] 100Mbps [6] 100Mbps [7] 100Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 100Mbps [1] 100Mbps [2] 100Mbps [3] 100Mbps
[4] 100Mbps [5] 100Mbps [6] 100Mbps [7] 100Mbps
user@router0> show rsvp session name e2e_lsp_r0r5 extensive
Ingress RSVP: 1 sessions
10.255.41.221
From: 10.255.41.222, LSPstate: Up, ActiveRoute: 2
LSPname: e2e_lsp_r0r5, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 101584
Resv style: 1 FF, Label in: -, Label out: 101584
Time left: -, Since: Wed Sep 7 19:02:56 2005
Tspec: rate 30kbps size 30kbps peak Infbps m 20 M 1500
Port number: sender 2 receiver 29458 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: 10.1.2.2 (so-0/0/3.0) 15 pkts
RESV rcvfrom: 10.1.2.2 (so-0/0/3.0) 16 pkts
Explct route: 10.1.2.2 172.16.30.2 10.3.6.2
Record route: <self> 10.1.2.2 172.16.30.2 10.3.6.2
Total 1 displayed, Up 1, Down 0
Egress RSVP: 1 sessions
Total 0 displayed, Up 0, Down 0
Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0
Enrutador 1
En el enrutador 1, compruebe que la configuración del vínculo de ingeniería de tráfico LMP funciona y que el LSP de extremo a extremo atraviesa el vínculo de ingeniería de tráfico emitiendo el 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 del protocolo de administración de vínculos
Después de configurar los vínculos de ingeniería de tráfico, configure los pares de red LMP con la peer peer-name instrucción en el nivel de [edit protocols link-management] 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 par, configure el ID del enrutador par como la dirección (a menudo una dirección de circuito cerrado) y aplique el vínculo de ingeniería de tráfico que se asociará con este par. Recuerde configurar ambos lados de una relación de emparejamiento para permitir la comunicación bidireccional.
A diferencia de GMPLS, no debe configurar un canal de control para un par Si incluye un canal de control, se producirá un error en la operación de confirmación.
[edit]
protocols {
link-management {
peer peer-name { # Configure the name of your network peer.
address ip-address; # Include the router ID of the peer.
te-link te-link-name; # Assign a TE link to this peer.
}
}
}
Configuración de vínculos de ingeniería de tráfico del protocolo de administración de vínculos
Para comenzar la configuración del túnel RSVP LSP, configure vínculos de ingeniería de tráfico LMP en las plataformas de enrutamiento de entrada y salida. Dado que los vínculos de ingeniería de tráfico definen una conexión unidireccional entre dispositivos pares, debe configurar los vínculos de ingeniería de tráfico en ambas direcciones entre pares para habilitar el transporte bidireccional de paquetes.
Para configurar vínculos de ingeniería de tráfico en LMP, incluya la te-link te-link-name instrucción en el nivel de jerarquía [edit protocols link-management]. Defina las opciones de vínculos de ingeniería de tráfico que se muestran a continuación, especialmente la ruta de conmutación de etiquetas que se utilizará como FA-LSP para llegar al par. Opcionalmente, puede especificar la métrica de ingeniería de tráfico para el vínculo de ingeniería de tráfico (vínculo TE). De forma predeterminada, la métrica de ingeniería de tráfico se deriva del cálculo de CSPF.
[edit]
protocols {
link-management {
te-link te-link-name { # Name of the TE link.
label-switched-path lsp-name; # LSP used for the forwarding adjacency.
local-address ip-address; # Local IP address associated with the TE link.
remote-address ip-address; # Remote IP address mapped to the TE link.
te-metric value; # Traffic engineering metric used for the TE link.
}
}
}
Configuración de interfaces del mismo nivel en OSPF y RSVP
Después de establecer pares LMP, debe agregar interfaces del mismo nivel a OSPF y RSVP. Una interfaz par es una interfaz virtual utilizada para admitir la adyacencia de control entre dos pares.
El nombre de la interfaz del mismo nivel debe coincidir con la peer peer-name instrucción configurada en LMP en el nivel jerárquico [edit protocols link-management] . Dado que las interfaces del mismo nivel envían y reciben paquetes de protocolo reales, las interfaces del mismo nivel se pueden señalar y anunciar a los pares como cualquier otra interfaz física configurada para OSPF y RSVP. Para configurar el enrutamiento OSPF para pares LMP, incluya la peer-interface instrucción en el nivel de [edit protocols ospf area area-number] jerarquía. Para configurar la señalización RSVP para pares LMP, incluya la peer-interface instrucción en el nivel de [edit protocols rsvp] jerarquía.
[edit]
protocols {
rsvp {
peer-interface peer-name { # Configure the name of your LMP peer.
}
ospf {
area area-number {
peer-interface peer-name { # Configure the name of your LMP peer.
}
}
}
}
}
Definición de rutas conmutadas por etiquetas para el FA-LSP
A continuación, defina su FA-LSP incluyendo la label-switched-path instrucción en el nivel jerárquico [edit protocols mpls] . Incluya el ID de enrutador del par en la to instrucción en el [edit protocols mpls label-switched-path] nivel de jerarquía. Dado que los LSP de paquetes son unidireccionales, debe crear un FA-LSP para llegar al par y un segundo FA-LSP para devolver desde el par.
[edit]
protocols {
mpls {
label-switched-path lsp-name {
from ip-address;
to ip-address;
primary path-name;
secondary path-name;
no-cspf; # This statement to disable CSPF is optional.
}
}
}
Establecimiento de información de ruta de FA-LSP
Cuando configure rutas de LSP explícitas para un FA-LSP, debe utilizar la dirección remota del vínculo de ingeniería de tráfico como dirección del próximo salto. Cuando CSPF es compatible, puede usar cualquier opción de ruta que desee. Sin embargo, cuando CSPF está deshabilitado con la no-cspf instrucción en el nivel jerárquico [edit protocols mpls label-switched-path lsp-name] , debe utilizar 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 RSVP LSP con gracia
Puede desactivar un LSP RSVP en un proceso de dos pasos que retira correctamente la sesión RSVP utilizada por el LSP. Para todos los vecinos que admiten el desmontaje correcto, la plataforma de enrutamiento envía una solicitud de desmontaje al extremo de destino para el LSP y todos los vecinos de RSVP en la ruta. La solicitud se incluye dentro del ADMIN_STATUS campo del paquete RSVP. Cuando los vecinos reciben la solicitud, se preparan para que se retire la sesión de RSVP. La plataforma de enrutamiento envía un segundo mensaje para completar el desmontaje de la sesión RSVP. Si un vecino no admite el desmontaje correcto, la solicitud se maneja como un desmontaje de sesión estándar en lugar de uno elegante.
Para realizar un desmontaje correcto de una sesión RSVP, ejecute el clear rsvp session gracefully comando. Opcionalmente, puede especificar la dirección de origen y destino de la sesión RSVP, el identificador LSP del remitente RSVP y el identificador de túnel de la sesión RSVP. Para usar estos calificadores, incluya las connection-sourceopciones , connection-destination, lsp-idy tunnel-id cuando ejecute el clear rsvp session gracefully comando.
También puede configurar la cantidad de tiempo que la plataforma de enrutamiento espera a que los vecinos reciban la solicitud de desmontaje elegante antes de iniciar el desmontaje real incluyendo la graceful-deletion-timeout instrucción en el nivel de [edit protocols rsvp] jerarquía. El valor predeterminado del tiempo de espera de eliminación correcta es de 30 segundos, con un valor mínimo de 1 segundo y un valor máximo de 300 segundos. Para ver el valor actual configurado para el tiempo de espera de eliminación correcta, ejecute el comando de show rsvp version modo operativo.
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice Feature Explorer a fin de determinar si una función es compatible con la plataforma.