Detección de reenvío bidireccional (BFD) para MPLS
Configuración de la detección de reenvío bidireccional para MPLS (procedimiento de la CLI)
Puede configurar el protocolo de detección de reenvío bidireccional (BFD) en conmutadores independientes EX8200 y chasis virtual EX8200 para detectar errores en la ruta del conmutador de etiqueta (LSP) de MPLS. El protocolo BFD es un mecanismo de saludo simple que detecta fallas en una red. Los paquetes Hello se envían en un intervalo regular especificado. Un error de vecino se detecta cuando el dispositivo de enrutamiento deja de recibir una respuesta del vecino después de un intervalo especificado. BFD trabaja con una amplia variedad de entornos y topologías de red. Los temporizadores de detección de fallas para BFD tienen límites de tiempo más cortos que los de los mecanismos de detección de fallas para rutas estáticas y, por lo tanto, proporcionan una detección más rápida. Estos temporizadores también son adaptables. Por ejemplo, un temporizador puede adaptarse a un valor mayor si falla una adyacencia, o un vecino puede negociar un valor mayor que el configurado.
En este tema se describe la configuración de los conmutadores perimetral del proveedor (PE) y los conmutadores del proveedor para que sean compatibles con LSP basados en LDP y LSP basados en RSVP.
Este tema incluye:
- Configuración de BFD en perímetro de proveedor y conmutadores de proveedor para un LSP basado en LDP
- Configuración de BFD en perímetro de proveedor y conmutadores de proveedor para un LSP basado en RSVP
Configuración de BFD en perímetro de proveedor y conmutadores de proveedor para un LSP basado en LDP
Puede habilitar BFD para los LSP basados en LDP o los LSP basados en RSVP asociados con una clase de equivalencia de reenvío (FEC) específica. Como alternativa, puede configurar una directiva de entrada de administración y mantenimiento de operaciones (OAM) para habilitar BFD en un rango de direcciones FEC.
Antes de configurar BFD para un LSP basado en LDP, debe configurar los componentes básicos para una red MPLS:
Configure dos conmutadores de PE. Consulte Configuración de MPLS en conmutadores perimetrales de proveedores mediante IP a través de MPLS.
Configure uno o varios conmutadores de proveedor. Consulte Configuración de MPLS en conmutadores de proveedor EX8200 y EX4500.
Para configurar BFD en PE y conmutadores de proveedor:
Configuración de BFD en perímetro de proveedor y conmutadores de proveedor para un LSP basado en RSVP
Cuando BFD está configurado para un LSP basado en RSVP en el conmutador de entrada, se habilita en la ruta principal y en todas las rutas secundarias en espera para ese LSP. Puede habilitar BFD para todos los LSP de un conmutador o para LSP específicos. Si configura BFD para un LSP específico, los valores configurados globalmente para BFD se invalidan en ese LSP. Las sesiones BFD se originan solo en el conmutador de entrada y terminan en el conmutador de salida.
Antes de configurar BFD para un LSP basado en RSVP, debe configurar los componentes básicos para una red MPLS:
Configure dos conmutadores de PE. Consulte Configuración de MPLS en conmutadores perimetrales de proveedores mediante IP a través de MPLS.
Configure uno o varios conmutadores de proveedor. Consulte Configuración de MPLS en conmutadores de proveedor EX8200 y EX4500.
Para configurar BFD en PE y conmutadores de proveedor:
Reparación local activada por BFD para una convergencia rápida
Descripción de la protección local activada por BFD
El tiempo que tarda una red en converger después de una falla de vínculo o nodo puede variar drásticamente en función de una serie de factores, incluido el tamaño de la red, los protocolos utilizados y el diseño de la red. Sin embargo, si bien cada evento de convergencia particular es diferente, el proceso de convergencia es esencialmente consistente. Se detecta el error, se notifica (inunda) el error en la red, se encuentra una ruta alternativa para el tráfico y el plano de reenvío se actualiza para pasar el tráfico por una nueva ruta.
Esta descripción general explica cómo la reparación local desencadenada por la detección de reenvío bidireccional (BFD) contribuye a un tiempo de restauración más rápido para una convergencia rápida en una red MPLS.
- Propósito de la reparación local activada por BFD
- Configuración de la reparación local activada por BFD
- Deshabilitar la reparación local activada por BFD
Propósito de la reparación local activada por BFD
En Junos OS, la protección general del tráfico MPLS para los errores de ruta de conmutación de etiquetas (LSP) señalados por RSVP se proporciona mediante varios mecanismos complementarios. Estos mecanismos de protección incluyen protección local (reenrutamiento rápido, protección de vínculos y protección de nodo-enlace) y protección de rutas (rutas primarias y secundarias). La protección local junto con la protección de ruta de acceso puede proporcionar una pérdida mínima de paquetes para un LSP y controlar la forma en que se reenruta el LSP después de un error. Tradicionalmente, ambos tipos de protección se basan en la detección rápida de fallas de conectividad a nivel físico. Sin embargo, para los medios de transmisión sin detección rápida del nivel físico, Junos OS admite ping BFD y MPLS para una detección rápida de fallos.
Con los vínculos entre enrutadores, cuando una ruta deja de funcionar, el proceso de protocolo de enrutamiento vuelve a calcular la siguiente mejor ruta. Cuando el reenrutamiento rápido (FRR) MPLS está habilitado, los mensajes ifl se inundan a todos los concentradores PIC flexibles (FPC). La FPC de borde habilita el túnel LSP MPLS de derivación. Por último, todas las rutas se reparan y se envían a través del túnel LSP MPLS de derivación. La cantidad de tiempo que se tarda en reparar todas las rutas es proporcional al número de rutas.
Este escenario de reparación se vuelve más difícil cuando un conmutador se encuentra entre dos vínculos. Consulte Figura 1.
Cuando un vínculo deja de funcionar en el extremo remoto, el error no se detecta en el extremo local hasta que el protocolo de puerta de enlace interior (IGP) deja de funcionar. Esperar a que el proceso del protocolo de enrutamiento vuelva a calcular la siguiente mejor ruta lleva demasiado tiempo.
Con la reparación local activada por BFD habilitada, el motor de reenvío de paquetes completa primero la reparación, utilizando el túnel LSP MPLS de derivación (que está preconfigurado e instalado) y, a continuación, informa al proceso del protocolo de enrutamiento para volver a calcular una nueva ruta. De este modo, cuando el túnel LSP MPLS principal deja de funcionar, la FPC puede desviar el tráfico de forma intermitente e inmediata hacia la FPC con el túnel LSP MPLS de derivación.
El uso de la reparación local de esta manera logra un tiempo de restauración más rápido de menos de 50 ms.
Configuración de la reparación local activada por BFD
La reparación local activada por BFD no es configurable, pero forma parte de la configuración predeterminada.
Los trabajos de reparación local activados por BFD dentro del Junos OS heredado cuentan con MPLS-FRR, BFD para IGP y alternativas sin bucles (LFA).
Deshabilitar la reparación local activada por BFD
De forma predeterminada, la reparación local activada por BFD está habilitada para todas las interfaces de enrutamiento. Si lo desea, puede deshabilitar la reparación local activada por BFD en el nivel jerárquico [edit routing-options].
Para deshabilitar explícitamente la reparación local activada por BFD:
Incluya la
no-bfd-triggered-local-repair
instrucción en el nivel jerárquico [edit routing-options]:user@host# set no-bfd-triggered-local-repair
(Opcional) Compruebe las opciones de configuración antes de confirmarlas mediante el
show routing-options
comando.user@host# run show routing-options
Confirme la configuración emitiendo el show routing-options comando.
user@host# show routing-options ... no-bfd-triggered-local-repair; }
Cuando deshabilite esta característica, también debe reiniciar el enrutamiento incluyendo la graceful-restart instrucción para el IGP. Por ejemplo, para OSPF, esto se logra incluyendo la graceful-restart instrucción en el nivel jerárquico [edit protocols ospf]
.
Configuración de BFD para LSP IPv4 MPLS
Puede configurar el protocolo de detección de reenvío bidireccional (BFD) en LSP IPv4 MPLS como se describe en el borrador de draft-ietf-bfd-mpls-02.txt de Internet, BFD para LSP MPLS. BFD se usa como una característica periódica de operación, administración y mantenimiento (OAM) para que los LSP detecten fallas en el plano de datos de LSP. Puede configurar BFD para LSP que utilicen LDP o RSVP como protocolo de señalización.
BFD para MPLS IPv4 LSP se basa en el motor de enrutamiento y no se distribuye. Como resultado, el intervalo mínimo de temporizador BFD admitido es (100 ms * 3) por una sesión LSP, y para sesiones LSP escaladas, el intervalo mínimo de temporizador BFD admitido es (300 ms * 3). A medida que aumenta el número de sesiones de LSP con BFD, también debe aumentar (escalar) los temporizadores de intervalo para admitir la red.
Para las instancias de cambio de motor de enrutamiento compatibles con enrutamiento activo sin interrupciones (NSR), el intervalo mínimo de temporizador BFD admitido es (2,5 segundos * 3).
También puede utilizar los comandos LSP ping
para detectar errores en el plano de datos de LSP. Sin embargo, BFD tiene un par de beneficios: requiere menos procesamiento informático que los comandos LSP ping
y puede detectar rápidamente fallas en un gran número de LSP (los comandos LSP ping
deben emitirse para cada LSP individualmente). Por otro lado, BFD no se puede utilizar para verificar el plano de control con el plano de datos en el LSR de salida, lo que es posible cuando una solicitud de eco LSP ping
está asociada a una clase de equivalencia de reenvío (FEC).
Los temporizadores de detección de fallos BFD son adaptativos y se pueden ajustar para ser más o menos agresivos. Por ejemplo, los temporizadores pueden adaptarse a un valor más alto si falla la adyacencia, o un vecino puede negociar un valor más alto para un temporizador que el valor configurado. Los temporizadores se adaptan a un valor más alto cuando un colgajo de sesión BFD ocurre más de tres veces en un lapso de 15 segundos. Un algoritmo de retroceso aumenta el intervalo de recepción (Rx) en dos si la instancia local de BFD es el motivo de la solapa de sesión. El intervalo de transmisión (Tx) aumenta en dos si la instancia remota de BFD es el motivo de la solapa de sesión. Puede utilizar el comando para devolver los clear bfd adaptation
temporizadores de intervalo BFD a sus valores configurados. El clear bfd adaptation
comando no tiene hits, lo que significa que el comando no afecta al flujo de tráfico en el dispositivo de enrutamiento.
A partir de Junos OS versión 13.2R4, 13.3R2 y 14.1, puede establecer el intervalo de tiempo entre los mensajes ping LSP y el número de respuestas ping LSP, respectivamente, después del cual se interrumpe la sesión de detección de reenvío bidireccional (BFD). Para ello, configure la lsp-ping-interval
instrucción y la lsp-ping-multiplier
instrucción en el nivel jerárquico [edit protocols mpls oam]
.
Para obtener instrucciones de configuración para LSP señalados por LDP, consulte Configuración de BFD para LSP de LDP. Para obtener instrucciones de configuración para los LSP señalados por RSVP, consulte la siguiente sección.
- Configuración de BFD para LSP señalados por RSVP
- Configuración de una acción de error para la sesión BFD en un LSP RSVP
Configuración de BFD para LSP señalados por RSVP
BFD para RSVP admite LSP IPv4 de unidifusión. Cuando BFD está configurado para un LSP RSVP en el enrutador de entrada, se habilita en la ruta principal y en todas las rutas secundarias en espera para ese LSP. La dirección IP de origen para los paquetes BFD salientes desde el lado de salida de una sesión BFD MPLS se basa en la dirección IP de la interfaz saliente. Puede habilitar BFD para todos los LSP en un enrutador o para LSP específicos. Si configura BFD para un LSP específico, se anularán los valores configurados globalmente para BFD. Las sesiones BFD se originan únicamente en el enrutador de entrada y terminan en el enrutador de salida.
Se registra un error cada vez que falla una sesión BFD para una ruta. En el ejemplo siguiente se muestra cómo pueden aparecer los mensajes de registro de BFD para RSVP LSP:
RPD_MPLS_PATH_BFD_UP: MPLS BFD session for path path1 up on LSP R0_to_R3 RPD_MPLS_PATH_BFD_DOWN: MPLS BFD session for path path1 down on LSP R0_to_R3
Puede configurar BFD para todos los LSP RSVP del enrutador, un LSP específico o la ruta principal de un LSP específico. Para configurar BFD para RSVP LSP, incluya las oam
instrucciones y bfd-liveness-detection
.
oam { bfd-liveness-detection { failure-action { make-before-break teardown-timeout seconds; teardown; } failure-action teardown; minimum-interval milliseconds; minimum-receive-interval milliseconds; minimum-transmit-interval milliseconds; multiplier detection-time-multiplier; } lsp-ping-interval time-interval; lsp-ping-multiplier multiplier; }
Puede configurar esta instrucción en los siguientes niveles jerárquicos:
[edit protocols mpls]
[edit protocols mpls label-switched-path lsp-name]
[edit protocols mpls label-switched-path lsp-name primary path-name]
La bfd-liveness-detection
instrucción incluye las siguientes opciones:
minimum-interval
: especifica el intervalo mínimo de transmisión y recepción.minimum-receive-interval
: especifica el intervalo mínimo de recepción. El rango es de 1 a 255,000 milisegundos.minimum-transmit-interval
: especifica el intervalo mínimo de transmisión. El rango es de 1 a 255,000 milisegundos.lsp-ping-multiplier
: especifica el multiplicador de tiempo de detección. El rango es de 1 a 255.Nota:Para evitar desencadenar falsos negativos, configure un tiempo de detección de errores de BFD que sea mayor que el tiempo de reenrutamiento rápido.
También puede configurar la lsp-ping-interval
opción para ajustar el intervalo de tiempo entre pings LSP. El comando ping de LSP para los LSP señalados por RSVP es ping mpls rsvp
. Para obtener más información sobre el ping mpls rsvp
comando, consulte el Explorador de CLI.
Configuración de una acción de error para la sesión BFD en un LSP RSVP
Cuando la sesión BFD para un LSP RSVP deja de funcionar, el LSP se desactiva y se vuelve a señalizar. El tráfico se puede cambiar a un LSP en espera, o simplemente puede desactivar la ruta de LSP. Se registran todas las acciones realizadas.
Cuando una sesión BFD para una ruta RSVP LSP deja de funcionar, puede configurar Junos OS para que vuelva a señalizar la ruta LSP o simplemente para que deshabilite la ruta LSP. Se podría configurar una ruta de LSP en espera para controlar el tráfico mientras la ruta de LSP principal no está disponible. El enrutador puede recuperarse automáticamente de fallas de LSP que pueden ser detectadas por BFD. De forma predeterminada, si se produce un error en una sesión BFD, el evento simplemente se registra.
Para permitir que Junos OS desmonte una ruta de LSP RSVP en caso de que se produzca un evento BFD, incluya la failure-action
instrucción:
failure-action { make-before-break teardown-timeout seconds; teardown; }
Para obtener una lista de los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.
Puede configurar las teardown
opciones o make-before-break
:
teardown
: hace que la ruta LSP se desconecte y se vuelva a señalar inmediatamente.make-before-break
: hace que Junos OS intente señalar una nueva ruta de LSP antes de derribar la antigua ruta de LSP. También puede configurar lateardown-timeout
opción para desactivar automáticamente el LSP después del período de tiempo especificado si se produce un error al intentar reenviar la señal del LSP dentro delteardown-timeout
intervalo. Si especifica un valor de 0 para elteardown-timeout
intervalo, el LSP se desactiva y se vuelve a señalar inmediatamente (el mismo comportamiento que cuando configura lateardown
opción).
Para configurar una acción de error para todos los LSP de RSVP, incluya la failure-action
instrucción en el [edit protocols mpls oam bfd-liveness-detection]
nivel de jerarquía. Para configurar una acción de error para un LSP de RSVP específico, incluya la failure-action
instrucción en el nivel de [edit protocols mpls label-switched-path lsp-name oam bfd-liveness-detection]
jerarquía.
Para configurar una acción de error para una ruta principal específica, incluya la failure-action
instrucción en el nivel de [edit protocols mpls label-switched path lsp-name primary path-name oam bfd-liveness-detection]
jerarquía. Para configurar una acción de error para una ruta de LSP secundaria específica, incluya la failure-action
instrucción en el nivel de [edit protocols mpls label-switched-path lsp-name secondary path-name oam bfd-liveness-detection]
jerarquía.
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.