Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
EN ESTA PÁGINA
 

Configuración de LDP

Configuración mínima de LDP

Para habilitar LDP con una configuración mínima:

  1. Habilite todas las interfaces relevantes bajo la familia MPLS. En el caso de LDP dirigido, la interfaz de circuito cerrado debe habilitarse con la familia MPLS.

  2. (Opcional) Configure las interfaces relevantes en el [edit protocol mpls] nivel de jerarquía.

  3. Habilite LDP en una sola interfaz, incluya la ldp instrucción y especifique la interfaz mediante la interface instrucción.

Esta es la configuración de LDP mínima. El resto de instrucciones de configuración de LDP son opcionales.

Para habilitar LDP en todas las interfaces, especifique all para interface-name.

Para obtener una lista de niveles de jerarquía en los que puede incluir estas instrucciones, consulte las secciones de resumen de instrucciones.

Habilitar y deshabilitar LDP

LDP es consciente de la instancia de enrutamiento. Para habilitar LDP en una interfaz específica, incluya las siguientes instrucciones:

Para obtener una lista de niveles de jerarquía en los que puede incluir estas instrucciones, consulte las secciones de resumen de instrucciones.

Para habilitar LDP en todas las interfaces, especifique all para interface-name.

Si ha configurado propiedades de interfaz en un grupo de interfaces y desea deshabilitar LDP en una de las interfaces, incluya la interface instrucción con la disable opción:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción.

Configurar el temporizador LDP para los mensajes de saludo

Los mensajes de saludo de LDP permiten que los nodos de LDP se descubran entre sí y detecten la falla de un vecino o el vínculo con el vecino. Los mensajes de saludo se envían periódicamente a todas las interfaces en las que LDP está habilitado.

Hay dos tipos de mensajes de saludo de LDP:

  • Mensajes de saludo de vínculo: se envían a través de la interfaz del LDP como paquetes UDP dirigidos al puerto de descubrimiento de LDP. La recepción de un mensaje de saludo de vínculo LDP en una interfaz identifica una adyacencia con el enrutador par LDP.

  • Mensajes de saludo dirigidos: se envían como paquetes UDP dirigidos al puerto de descubrimiento de LDP en una dirección específica. Los mensajes de saludo dirigidos se utilizan para admitir sesiones de LDP entre enrutadores que no están conectados directamente. Un enrutador de destino determina si debe responder o ignorar un mensaje de saludo dirigido. Un enrutador de destino que elige responder lo hace mediante el envío periódico de mensajes de saludo dirigidos de vuelta al enrutador iniciador.

De forma predeterminada, LDP envía mensajes de saludo cada 5 segundos para los mensajes de saludo del vínculo y cada 15 segundos para los mensajes de saludo dirigidos. Puede configurar el temporizador LDP para alterar la frecuencia con la que se envían ambos tipos de mensajes de saludo. Sin embargo, no puede configurar una hora para el temporizador LDP que sea mayor que el tiempo de espera del LDP. Para obtener más información, consulte Configuración del retraso antes de que los vecinos de LDP se consideren inactivos.

Configuración del temporizador LDP para mensajes de saludo del vínculo

Para modificar la frecuencia con la que LDP envía mensajes de saludo del vínculo, especifique un nuevo intervalo de mensajes de saludo de vínculo para el temporizador LDP mediante la hello-interval instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

Configuración del temporizador LDP para mensajes de saludo dirigidos

Para modificar la frecuencia con la que LDP envía mensajes de saludo de destino, especifique un nuevo intervalo de mensajes de saludo de destino para el temporizador LDP configurando la hello-interval instrucción como una opción para la targeted-hello instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir estas instrucciones, consulte las secciones de resumen de instrucciones de estas instrucciones.

Configurar el retraso antes de que los vecinos de LDP se consideren inactivos

El tiempo de espera determina cuánto tiempo debe esperar un nodo LDP para recibir un mensaje de saludo antes de declarar que un vecino está inactivo. Este valor se envía como parte de un mensaje de saludo para que cada nodo LDP indique a sus vecinos cuánto tiempo debe esperar. Los valores enviados por cada vecino no tienen que coincidir.

Normalmente, el tiempo de espera debe ser al menos tres veces el intervalo de saludo. El valor predeterminado es de 15 segundos para los mensajes de saludo del vínculo y 45 segundos para los mensajes de saludo dirigidos. Sin embargo, es posible configurar un tiempo de espera LDP que se acerque al valor del intervalo de saludo.

Nota:

Al configurar un tiempo de espera de LDP cercano al intervalo de saludo (menos de tres veces el intervalo de saludo), es posible que se detecten errores de vecino de LDP con mayor rapidez. Sin embargo, esto también aumenta la posibilidad de que el enrutador declare un LDP vecino que sigue funcionando normalmente. Para obtener más información, consulte Configuración del temporizador LDP para mensajes de saludo.

El tiempo de espera del LDP también se negocia automáticamente entre los pares del LDP. Cuando dos pares de LDP anuncian tiempos de espera LDP diferentes entre sí, se utiliza el valor más pequeño. Si un enrutador par LDP anuncia un tiempo de espera más corto que el valor que ha configurado, se utiliza el tiempo de espera anunciado del enrutador par. Esta negociación también puede afectar el intervalo de mantenimiento del LDP.

Si el tiempo de espera local de LDP no se acorta durante la negociación de par de LDP, el intervalo de mantenimiento configurado por el usuario se deja sin cambios. Sin embargo, si el tiempo de espera local se reduce durante la negociación entre pares, el intervalo de mantenimiento se recalcula. Si el tiempo de espera de LDP se ha reducido durante la negociación entre pares, el intervalo de mantenimiento se reduce a un tercio del nuevo valor de tiempo de espera. Por ejemplo, si el nuevo valor de tiempo de espera es de 45 segundos, el intervalo de mantenimiento se establece en 15 segundos.

Este cálculo automatizado de intervalos de mantenimiento puede hacer que se configuren intervalos de mantenimiento diferentes en cada enrutador par. Esto permite que los enrutadores sean flexibles en cuanto a la frecuencia con la que envían mensajes de mantención, ya que la negociación de par LDP garantiza que se envíen con más frecuencia que el tiempo de espera del LDP.

Cuando se reconfigura el intervalo de tiempo de espera, los cambios no tienen efecto hasta después de restablecer la sesión. El tiempo de espera se negocia cuando se inicia la sesión de emparejamiento de LDP y no se puede renegociar mientras la sesión esté activa (requerido por RFC 5036, especificación LDP). Para forzar manualmente el restablecimiento de la sesión de LDP, emita el clear ldp session comando.

Configuración del tiempo de espera del LDP para los mensajes de saludo del vínculo

Para modificar el tiempo que un nodo LDP debe esperar a que un mensaje de saludo del vínculo antes de declarar el vecino, especifique un nuevo tiempo en segundos mediante la hold-time instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

Configuración del tiempo de espera del LDP para mensajes de saludo dirigidos

Para modificar cuánto tiempo debe esperar un nodo LDP para recibir un mensaje de saludo de destino antes de declarar el vecino, especifique un nuevo tiempo en segundos utilizando la hold-time instrucción como opción para la targeted-hello instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir estas instrucciones, consulte las secciones de resumen de instrucciones de estas instrucciones.

Habilitación de mensajes de saludo dirigidos estrictos para LDP

Use mensajes de saludo dirigidos estrictos para evitar que las sesiones de LDP se establezcan con vecinos remotos que no se han configurado específicamente. Si configura la strict-targeted-hellos instrucción, un par LDP no responde a los mensajes de saludo de destino procedentes de un origen que no es uno de sus vecinos remotos configurados. Los vecinos remotos configurados pueden incluir:

  • Puntos de conexión de túneles RSVP para los cuales está configurada la tunelización de LDP

  • Vecinos del circuito de capa 2

Si un vecino no configurado envía un mensaje de saludo, el par LDP ignora el mensaje y registra un error (con el error indicador de seguimiento) que indica el origen. Por ejemplo, si el par LDP recibió un saludo de destino de la dirección de Internet 10.0.0.1 y ningún vecino con esta dirección está configurado específicamente, el siguiente mensaje se imprime en el archivo de registro LDP:

Para habilitar mensajes de saludo específicos estrictos, incluya la strict-targeted-hellos instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

Configuración del intervalo para mensajes de mantenimiento de LDP

El intervalo de mantenimiento determina la frecuencia con la que se envía un mensaje a través de la sesión para garantizar que no se supere el tiempo de espera de mantenimiento. Si no se envía ningún otro tráfico LDP a través de la sesión en tanto tiempo, se envía un mensaje de mantención. El valor predeterminado es de 10 segundos. El valor mínimo es 1 segundo.

El valor configurado para el intervalo de mantenimiento se puede alterar durante la negociación de sesión de LDP si el valor configurado para el tiempo de espera de LDP en el enrutador par es menor que el valor configurado localmente. Para obtener más información, consulte Configuración del retraso antes de que los vecinos de LDP se consideren inactivos.

Para modificar el intervalo de mantenimiento, incluya la keepalive-interval instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

Configurar el tiempo de espera de mantención de LDP

Después de establecer una sesión LDP, los mensajes deben intercambiarse periódicamente para garantizar que la sesión siga funcionando. El tiempo de espera de la sesión define la cantidad de tiempo que espera el nodo LDP vecino antes de decidir que la sesión ha fallado. Este valor suele establecerse en al menos tres veces el intervalo de mantenimiento. El valor predeterminado es de 30 segundos.

Para modificar el intervalo de mantenimiento, incluya la keepalive-timeout instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

El valor configurado para la keepalive-timeout instrucción se muestra como el tiempo de espera cuando se emite el show ldp session detail comando.

Configuración de la coincidencia más larga para LDP

Para permitir que el LDP aprenda las rutas agregadas o resumidas en áreas OSPF o niveles de ISIS en el interdominio, Junos OS le permite configurar la coincidencia más larga para LDP con base en RFC5283.

Antes de configurar la coincidencia más larga para LDP, debe hacer lo siguiente:

  1. Configure las interfaces del dispositivo.

  2. Configure el protocolo MPLS.

  3. Configure el protocolo OSPF.

Para configurar la coincidencia más larga para LDP, debe hacer lo siguiente:

  1. Configure la coincidencia más larga para el protocolo LDP.
  2. Configure el protocolo LDP en la interfaz.

    Por ejemplo, para configurar las interfaces:

Ejemplo: Configuración de la coincidencia más larga para LDP

En este ejemplo, se muestra cómo configurar la coincidencia más larga para LDP basada en RFC5283. Esto permite que el PLD aprenda las rutas agregadas o resumidas en las áreas de OSPF o los niveles de ISIS en los dominios. La política de coincidencia más larga proporciona granularidad por prefijo.

Requisitos

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

  • Seis enrutadores serie MX con protocolo OSPF y LDP habilitados en las interfaces conectadas.

  • Junos OS versión 16.1 o posterior se ejecuta en todos los dispositivos.

Antes de empezar:

  • Configure las interfaces del dispositivo.

  • Configure OSPF.

Descripción general

El LDP se utiliza a menudo para establecer rutas de conmutación de etiquetas (LSP) de MPLS en todo un dominio de red completo mediante un IGP, como OSPF o IS-IS. En una red de este tipo, todos los enlaces del dominio tienen adyacencias IGP y Adyacencias LDP. El LDP establece los LSP en la ruta más corta a un destino según lo determine el reenvío de IP. En Junos OS, la implementación de LDP hace una búsqueda exacta de coincidencia en la dirección IP de la FEC en las rutas RIB o IGP para la asignación de etiquetas. Esta asignación exacta requiere que las direcciones IP de punto de conexión LDP de extremo a extremo de MPLS se configuren en todas las LER. Esto no cumple con el propósito del diseño jerárquico ip o del enrutamiento predeterminado en los dispositivos de acceso. La configuración longest-match ayuda a superar esto al suprimir el comportamiento exacto de coincidencia y configurar LSP basado en la ruta de coincidencia más larga por prefijo.

Topología

En la topología, Figura 1muestra la coincidencia más larga para LDP está configurada en el dispositivo R0 .

Figura 1: Ejemplo de coincidencia más larga para LDPEjemplo de coincidencia más larga para LDP

Configuración

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, copie y pegue los comandos en la CLI en el nivel de jerarquía y, luego, ingrese commit desde el [edit] modo de configuración.

R0

R1

R2

R3

R4

R5

Configuración del dispositivo R0

Procedimiento paso a paso

El siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración en la Guía del usuario de CLI.

Para configurar el dispositivo R0:

  1. Configure las interfaces.

  2. Asigne las direcciones de circuito cerrado al dispositivo.

  3. Configure el ID de enrutador.

  4. Configure el protocolo MPLS en la interfaz.

  5. Configure el protocolo OSPF en la interfaz.

  6. Configure la coincidencia más larga para el protocolo LDP.

  7. Configure el protocolo LDP en la interfaz.

Resultados

Desde el modo de configuración, ingrese los comandos , show protocolsy show routing-options para confirmar la show interfacesconfiguración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.

Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.

Verificación

Confirme que la configuración funciona correctamente.

Verificar las rutas

Propósito

Verifique que se han aprendido las rutas esperadas.

Acción

En el dispositivo R0, desde el modo operativo, ejecute el show route comando para mostrar las rutas en la tabla de enrutamiento.

Significado

El resultado muestra todas las rutas en la tabla de enrutamiento del dispositivo R0.

Verificar la información general de LDP

Propósito

Mostrar información general de LDP.

Acción

En el dispositivo R0, desde el modo operativo, ejecute el show ldp overview comando para mostrar la descripción general del LDP.

Significado

El resultado muestra la información general del LDP del dispositivo R0

Verificar las entradas LDP en la tabla de topología interna

Propósito

Muestra las entradas de ruta en la tabla de topología interna de Protocolo de distribución de etiquetas (LDP).

Acción

En el dispositivo R0, desde el modo operativo, ejecute el show ldp route comando para mostrar la tabla de topología interna de LDP.

Significado

El resultado muestra las entradas de ruta en la tabla de topología interna del protocolo de distribución de etiquetas (LDP) del dispositivo R0.

Verificar solo la información de FEC de la ruta de LDP

Propósito

Muestra solo la información de FEC de la ruta LDP.

Acción

En el dispositivo R0, desde el modo operativo, ejecute el show ldp route fec-only comando para mostrar las rutas en la tabla de enrutamiento.

Significado

El resultado muestra solo las rutas FEC del protocolo LDP disponibles para el dispositivo R0.

Verificar FEC y rutas paralelas de LDP

Propósito

Muestra el FEC y las rutas de sombra en la tabla de enrutamiento.

Acción

En el dispositivo R0, desde el modo operativo, ejecute el show ldp route fec-and-route comando para mostrar las rutas FEC y de sombra en la tabla de enrutamiento.

Significado

El resultado muestra la FEC y las rutas de sombra del dispositivo R0

Configuración de preferencias de ruta de LDP

Cuando varios protocolos calculan rutas al mismo destino, se utilizan las preferencias de ruta para seleccionar qué ruta está instalada en la tabla de reenvío. Se selecciona la ruta con el valor de preferencia más bajo. El valor de preferencia puede ser un número en el intervalo del 0 al 255. De forma predeterminada, las rutas LDP tienen un valor de preferencia de 9.

Para modificar las preferencias de ruta, incluya la preference instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

Reinicio elegante del PLD

El reinicio agraciado de LDP permite que un enrutador cuyo plano de control LDP está siendo reiniciado continúe reenviando el tráfico mientras recupera su estado de los enrutadores vecinos. También habilita un enrutador en el que el modo de ayuda está habilitado para ayudar a un enrutador vecino que intenta reiniciar LDP.

Durante la inicialización de la sesión, un enrutador anuncia su capacidad de realizar un reinicio agraciado de LDP o de aprovechar que un vecino realice un reinicio agraciado de LDP mediante el envío del reinicio agraciado TLV. Esta TLV contiene dos campos relevantes para el reinicio agraciado del PLD: el tiempo de reconexión y el tiempo de recuperación. Los valores de los tiempos de reconexión y recuperación indican las capacidades de reinicio agraciadas compatibles con el enrutador.

Cuando un enrutador descubre que un enrutador vecino se está reiniciando, espera hasta el final del tiempo de recuperación antes de intentar volver a conectarse. El tiempo de recuperación es el tiempo que un enrutador espera a que LDP se reinicie con elegancia. El período de recuperación comienza cuando se envía o recibe un mensaje de inicialización. Este período de tiempo también suele ser el tiempo que un enrutador vecino mantiene su información sobre el enrutador de reinicio, lo que le permite continuar reenviando tráfico.

Puede configurar el reinicio agraciado de LDP tanto en la instancia maestra para el protocolo LDP como para una instancia de enrutamiento específica. Puede deshabilitar el reinicio agraciado a nivel global para todos los protocolos, en el nivel de protocolo solo para LDP y en una instancia de enrutamiento específica. El reinicio agraciado de LDP está deshabilitado de forma predeterminada, ya que, a nivel global, el reinicio agraciado está deshabilitado de forma predeterminada. Sin embargo, el modo auxiliar (la capacidad de ayudar a un enrutador vecino a intentar un reinicio agraciado) está habilitado de forma predeterminada.

Los siguientes son algunos de los comportamientos asociados con el reinicio agraciado de LDP:

  • Las etiquetas de salida no se mantienen en los reinicios. Se asignan nuevas etiquetas de salida.

  • Cuando un enrutador se está reiniciando, no se envían mensajes de etiqueta-map a los vecinos que admiten un reinicio agraciado hasta que el enrutador de reinicio se ha estabilizado (los mensajes de etiqueta-mapa se envían de inmediato a los vecinos que no admiten el reinicio agraciado). Sin embargo, el resto de mensajes (keepalive, address-message, notification y release) se envían como siempre. La distribución de estos otros mensajes impide que el enrutador distribuya información incompleta.

  • El modo auxiliar y el reinicio agraciado son independientes. Puede deshabilitar el reinicio agraciado en la configuración, pero aún así permitir que el enrutador coopere con un vecino que intente reiniciar con elegancia.

Configurar el reinicio elegante del LDP

Cuando se altera la configuración de reinicio agraciado en los [edit routing-options graceful-restart] niveles de jerarquía o [edit protocols ldp graceful-restart] , cualquier sesión LDP en ejecución se reinicia automáticamente para aplicar la configuración de reinicio agraciado. Este comportamiento refleja el comportamiento del BGP cuando modifica su configuración de reinicio agraciado.

De forma predeterminada, el modo auxiliar de reinicio agraciado está habilitado, pero el reinicio agraciado está deshabilitado. Por lo tanto, el comportamiento predeterminado de un enrutador es ayudar a los enrutadores vecinos a intentar un reinicio agraciado, pero no intentar un reinicio agraciado en sí mismo.

Para configurar el reinicio agraciado de LDP, consulte las siguientes secciones:

Habilitación del reinicio agraciado

Para habilitar el reinicio agraciado de LDP, también debe habilitar el reinicio agraciado en el enrutador. Para habilitar el reinicio agraciado, incluya la graceful-restart instrucción:

Puede incluir esta instrucción en los siguientes niveles jerárquicos:

  • [edit routing-options]

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

Nota:

Los enrutadores serie ACX no admiten el nivel de jerarquía [edit logical-systems logical-system-name routing-options].

La graceful-restart instrucción permite el reinicio agraciado para todos los protocolos que admiten esta función en el enrutador. Para obtener más información acerca del reinicio agraciado, consulte la biblioteca de protocolos de enrutamiento de Junos OS para dispositivos de enrutamiento.

De forma predeterminada, el reinicio agraciado de LDP está habilitado cuando habilita el reinicio agraciado tanto en el nivel del protocolo LDP como en todas las instancias de enrutamiento. Sin embargo, puede deshabilitar tanto el reinicio agraciado de LDP como el modo de ayuda de reinicio agraciado de LDP.

Deshabilitar el reinicio agraciado de LDP o el modo de ayuda

Para deshabilitar el reinicio y la recuperación Agraciados de LDP, incluya la disable instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

Solo puede deshabilitar el modo auxiliar a nivel de protocolos LDP. No puede deshabilitar el modo auxiliar para una instancia de enrutamiento específica. Para deshabilitar el modo de ayuda de LDP, incluya la helper-disable instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

Son posibles las siguientes configuraciones de reinicio agraciado de LDP:

  • El reinicio agraciado del LDP y el modo de ayuda están habilitados.

  • El reinicio agraciado del LDP está deshabilitado, pero el modo de ayuda está habilitado. Un enrutador configurado de esta manera no puede reiniciarse con elegancia, pero puede ayudar a un vecino que está reiniciando.

  • El reinicio agraciado del LDP y el modo de ayuda están deshabilitados. El enrutador no usa LDP graceful restart ni el tipo, longitud y valor (TLV) enviado en el mensaje de inicialización. El enrutador se comporta como un enrutador que no puede admitir el reinicio agraciado de LDP.

Se produce un error de configuración si intenta habilitar el reinicio agraciado y deshabilitar el modo de ayuda.

Configurar el tiempo de reconexión

Después de que la conexión LDP entre vecinos falla, los vecinos esperan una cierta cantidad de tiempo para que el enrutador que reinicia con gracia vuelva a enviar mensajes de LDP. Después del período de espera, la sesión de LDP se puede restablecer. Puede configurar el período de espera en segundos. Este valor se incluye en la sesión tolerante a errores TLV envía en los mensajes de inicialización de LDP cuando se habilita el reinicio agraciado de LDP.

Supongamos que el enrutador A y el B son vecinos de LDP. El enrutador A es el enrutador de reinicio. El tiempo de reconexión es el tiempo que el enrutador A le dice al enrutador B que espere después de que el enrutador B detecte que el enrutador A se ha reiniciado.

Para configurar el tiempo de reconexión, incluya la reconnect-time instrucción:

Puede establecer el tiempo de reconexión en un valor en el intervalo de 30 a 300 segundos. De forma predeterminada, son 60 segundos.

Para obtener una lista de niveles de jerarquía en los que puede configurar estas instrucciones, consulte las secciones de resumen de instrucciones de estas instrucciones.

Configurar el tiempo de recuperación y el tiempo máximo de recuperación

El tiempo de recuperación es la cantidad de tiempo que un enrutador espera a que LDP se reinicie con gracia. El período de recuperación comienza cuando se envía o recibe un mensaje de inicialización. Este período también suele ser la cantidad de tiempo que un enrutador vecino mantiene su información sobre el enrutador de reinicio, lo que le permite continuar reenviando tráfico.

Para evitar que un enrutador vecino se vea afectado negativamente si recibe un valor falso para el tiempo de recuperación del enrutador de reinicio, puede configurar el tiempo máximo de recuperación en el enrutador vecino. Un enrutador vecino mantiene su estado durante el menor tiempo de las dos veces. Por ejemplo, el enrutador A está realizando un reinicio Agraciado del PLD. Ha enviado un tiempo de recuperación de 900 segundos al enrutador B vecino. Sin embargo, el enrutador B tiene configurado su tiempo de recuperación máximo en 400 segundos. El enrutador B solo esperará 400 segundos antes de purgar su información de LDP del enrutador A.

Para configurar el tiempo de recuperación, incluya la recovery-time instrucción y la maximum-neighbor-recovery-time instrucción:

Para obtener una lista de niveles de jerarquía en los que puede configurar estas instrucciones, consulte las secciones de resumen de instrucciones de estas instrucciones.

Filtrado de enlaces de etiquetas LDP entrantes

Puede filtrar los enlaces de etiquetas de LDP recibidos, aplicar políticas para aceptar o denegar enlaces anunciados por enrutadores vecinos. Para configurar el filtrado de etiquetas recibidas, incluya la import instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

La política denominada (configurada en el [edit policy-options] nivel de jerarquía) se aplica a todos los enlaces de etiquetas recibidos de todos los vecinos LDP. Todo el filtrado se realiza con from instrucciones. Tabla 1 Enumera los únicos from operadores que se aplican al filtrado de etiquetas recibidas de LDP.

Tabla 1: de operadores que se aplican al filtrado de etiquetas recibidas de LDP

from Operador

Descripción

interface

Coincidencias en los enlaces recibidos de un vecino adyacente a través de la interfaz especificada

neighbor

Coincidencias en los enlaces recibidos del ID de enrutador LDP especificado

next-hop

Coincidencias en los enlaces recibidos de un vecino que anuncia la dirección de interfaz especificada

route-filter

Coincidencias en enlaces con el prefijo especificado

Si se filtra un enlace, aún aparece en la base de datos de LDP, pero no se considera para la instalación como parte de una ruta conmutada por etiquetas (LSP).

Generalmente, la aplicación de políticas en LDP se puede usar solo para bloquear el establecimiento de LSP, no para controlar su enrutamiento. Esto se debe a que la ruta que sigue un LSP está determinada por el enrutamiento de unidifusión y no por LDP. Sin embargo, cuando hay varias rutas de igual costo al destino a través de diferentes vecinos, puede usar el filtrado de LDP para excluir algunos de los posibles saltos próximos de consideración. (De lo contrario, LDP elige uno de los posibles próximos saltos al azar.)

Las sesiones de LDP no están vinculadas a interfaces ni direcciones de interfaz. LDP anuncia solo etiquetas por enrutador (no por interfaz); por lo que si existen varios vínculos en paralelo entre dos enrutadores, solo se establece una sesión LDP y no está vinculada a una sola interfaz. Cuando un enrutador tiene varias adyacencias al mismo vecino, tenga cuidado de asegurarse de que el filtro haga lo que se espera. (Generalmente, el uso next-hop y interface no es apropiado en este caso.)

Si una etiqueta se ha filtrado (es decir, que la política rechazó y no se utiliza para construir un LSP), se marca como filtrada en la base de datos:

Para obtener más información acerca de cómo configurar políticas para LDP, consulte la Guía del usuario de políticas de enrutamiento, filtros de firewall y policías de tráfico.

Ejemplos: Filtrado de enlaces de etiquetas LDP entrantes

Aceptar solo los prefijos /32 de todos los vecinos:

Aceptar 131.108/16 o más del ID 10.10.255.2 del enrutador y aceptar todos los prefijos de todos los demás vecinos:

Filtrado de enlaces de etiquetas LDP salientes

Puede configurar políticas de exportación para filtrar etiquetas de salida LDP. Puede filtrar los enlaces de etiquetas salientes aplicando políticas de enrutamiento para bloquear que los enlaces se anuncien a enrutadores vecinos. Para configurar el filtrado de etiquetas salientes, incluya la export instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

La política de exportación denominada (configurada en el [edit policy-options] nivel de jerarquía) se aplica a todos los enlaces de etiquetas transmitidos a todos los vecinos LDP. El único from operador que se aplica al filtrado de etiquetas de salida de LDP es route-filter, que hace coincidir los enlaces con el prefijo especificado. Los únicos to operadores que aplican al filtrado de etiquetas salientes son los operadores en Tabla 2.

Tabla 2: a los operadores para el filtrado de etiquetas salientes de LDP

al operador

Descripción

interface

Coincidencias en los enlaces enviados a un vecino adyacente a través de la interfaz especificada

neighbor

Coincidencias en los enlaces enviados al ID de enrutador LDP especificado

next-hop

Coincidencias en los enlaces enviados a un vecino que anuncian la dirección de interfaz especificada

Si se filtra un enlace, el enlace no se anuncia al enrutador vecino, pero se puede instalar como parte de un LSP en el enrutador local. Puede aplicar políticas en LDP para bloquear el establecimiento de LSP, pero no para controlar su enrutamiento. La ruta que sigue un LSP está determinada por el enrutamiento de unidifusión, no por LDP.

Las sesiones de LDP no están vinculadas a interfaces ni direcciones de interfaz. LDP anuncia solo etiquetas por enrutador (no por interfaz). Si existen varios vínculos paralelos entre dos enrutadores, solo se establece una sesión LDP y no está vinculada a una sola interfaz.

No use los next-hop operadores y interface cuando un enrutador tiene varias adyacencias al mismo vecino.

Las etiquetas filtradas se marcan en la base de datos:

Para obtener más información acerca de cómo configurar políticas para LDP, consulte la Guía del usuario de políticas de enrutamiento, filtros de firewall y policías de tráfico.

Ejemplos: Filtrado de enlaces de etiquetas LDP salientes

Bloquee la transmisión de la ruta para 10.10.255.6/32 cualquier vecino:

Envíe solo 131.108/16 o más al ID 10.10.255.2de enrutador y envíe todos los prefijos a todos los demás enrutadores:

Especificar la dirección de transporte utilizada por LDP

Los enrutadores primero deben establecer una sesión TCP entre sí antes de poder establecer una sesión LDP. La sesión TCP permite que los enrutadores intercambien los anuncios de etiquetas necesarios para la sesión LDP. Para establecer la sesión TCP, cada enrutador debe aprender la dirección de transporte del otro enrutador. La dirección de transporte es una dirección IP utilizada para identificar la sesión TCP sobre la cual se ejecutará la sesión LDP.

Para configurar la dirección de transporte de LDP, incluya la instrucción de dirección de transporte:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

Si especifica la router-id opción, la dirección del identificador del enrutador se utiliza como dirección de transporte (a menos que se configure lo contrario, el identificador del enrutador suele ser el mismo que la dirección de circuito cerrado). Si especifica la interface opción, la dirección de la interfaz se utiliza como dirección de transporte para cualquier LDP sesiones de vecinos a los que se pueda llegar a través de esa interfaz. Tenga en cuenta que el identificador del enrutador se utiliza como dirección de transporte de forma predeterminada.

Nota:

Para que el funcionamiento sea adecuado, se debe tener acceso a la dirección de transporte del LDP. El ID del enrutador es un identificador, no una dirección IP enrutable. Por esta razón, se recomienda que el ID del enrutador se ajuste para que coincida con la dirección de circuito cerrado, y que la dirección de circuito cerrado sea anunciada por el IGP.

No puede especificar la interface opción cuando hay varios vínculos paralelos al mismo vecino LDP, ya que la especificación del LDP requiere que se anuncie la misma dirección de transporte en todas las interfaces al mismo vecino. Si LDP detecta varios vínculos paralelos al mismo vecino, deshabilita las interfaces con ese vecino una por una hasta que se desactive la condición, ya sea desconectando el vecino en una interfaz o especificando la router-id opción.

Dirección de transporte de control utilizada para la sesión de LDP dirigida

Para establecer una sesión TCP entre dos dispositivos, cada dispositivo debe aprender la dirección de transporte del otro dispositivo. La dirección de transporte es una dirección IP que se utiliza para identificar la sesión TCP sobre la que opera la sesión LDP. Anteriormente, esta dirección de transporte solo podía ser el ID del enrutador o una dirección de interfaz. Con la función de dirección de transporte de LDP, puede configurar explícitamente cualquier dirección IP como la dirección de transporte para los vecinos LDP dirigidos para los circuitos de capa 2, MPLS y adyacencias VPLS. Esto le permite controlar las sesiones de LDP de destino mediante la configuración de dirección de transporte.

Beneficios de controlar la dirección de transporte utilizada para la sesión de LDP dirigida

Configurar la dirección de transporte para establecer sesiones de LDP de destino tiene las siguientes ventajas:

  • Flexible interface configurations: ofrece la flexibilidad de configurar varias direcciones IP para una interfaz de circuito cerrado sin interrumpir la creación de sesión LDP entre los vecinos de LDP de destino.

  • Ease of operation— La dirección de transporte configurada en el nivel de interfaz le permite usar más de un protocolo en la red troncal del IGP para LDP. Esto permite operaciones fluidas y sencillas.

Descripción general de la dirección de transporte del LDP dirigida

Antes de la versión 19.1R1 de Junos OS, LDP solo era compatible con el ID del enrutador o la dirección de interfaz como dirección de transporte en cualquier interfaz LDP. Las adyacencias formadas en esa interfaz usaban una de las direcciones IP asignadas a la interfaz o el ID del enrutador. En caso de adyacencia dirigida, la interfaz es la interfaz de circuito cerrado. Cuando se configuraron varias direcciones de circuito cerrado en el dispositivo, no se pudo derivar la dirección de transporte para la interfaz y, como resultado, no se pudo establecer la sesión LDP.

A partir de Junos OS versión 19.1R1, además de las direcciones IP predeterminadas utilizadas para la dirección de transporte de las sesiones de LDP de destino, puede configurar cualquier otra dirección IP como dirección de transporte en las sessioninstrucciones , session-groupy interface de configuración. La configuración de la dirección de transporte solo se aplica a los vecinos configurados, incluidos los circuitos de capa 2, MPLS y adyacencias VPLS. Esta configuración no se aplica a las adyacencias descubiertas (dirigidas o no).

Preferencia de dirección de transporte

Puede configurar la dirección de transporte para sesiones de LDP dirigidas a nivel de sesión, grupo de sesión e interfaz.

Después de configurar la dirección de transporte, la sesión LDP de destino se establece según la preferencia de dirección de transporte de LDP.

El orden de preferencia de la dirección de transporte para el vecino de destino (configurado mediante circuito de capa 2, configuración de MPLS, VPLS y LDP) es el siguiente:

  1. En [edit protocols ldp session] jerarquía.

  2. En [edit protocols ldp session-group] jerarquía.

  3. En [edit protocols ldp interfcae lo0] jerarquía.

  4. En [edit protocols ldp] jerarquía.

  5. Dirección predeterminada.

El orden de preferencia de la dirección de transporte para los vecinos descubiertos es el siguiente:

  1. En [edit protocols ldp interfcae] jerarquía.

  2. En [edit protocols ldp] jerarquía.

  3. Dirección predeterminada.

El orden de preferencia de la dirección de transporte para los vecinos de destino automático en los que LDP está configurado para aceptar paquetes hola es el siguiente:

  1. En [edit protocols ldp interfcae lo0] jerarquía.

  2. En [edit protocols ldp] jerarquía.

  3. Dirección predeterminada.

Solución de problemas de la configuración de la dirección de transporte

Puede usar los siguientes resultados de comando show para solucionar problemas de sesiones de LDP dirigidos:

  • show ldp session

  • show ldp neighbor

    El detail nivel de salida del show ldp neighbor comando muestra la dirección de transporte enviada en los mensajes de saludo al vecino de destino. Si esta dirección no es accesible desde el vecino, la sesión del PLD no aparece.

  • show configuration protocols ldp

También puede habilitar las evaluaciones de seguimiento de LDP para la resolución de problemas.

  • Si la configuración cambia de usar una dirección de transporte no válida (no accesible) a una dirección de transporte que sea válida, se pueden observar los siguientes seguimientos:

  • Si la configuración cambia de usar una dirección de transporte válida a una dirección de transporte no válida (no accesible), se pueden observar los siguientes seguimientos:

En caso de que la configuración sea defectuosa, realice las siguientes tareas de solución de problemas:

  • Compruebe el address family. La dirección de transporte configurada en la session instrucción debe pertenecer a la misma familia de direcciones que el vecino o la sesión.

  • La dirección configurada como dirección de transporte en neighbor una instrucción o session debe ser local para el enrutador para que se inicien los mensajes de saludo de destino. Puede comprobar si la dirección está configurada. Si la dirección no está configurada en ninguna interfaz, la configuración se rechaza.

Configurar los prefijos anunciados en LDP desde la tabla de enrutamiento

Puede controlar el conjunto de prefijos que se anuncian en LDP y hacer que el enrutador sea el enrutador de salida de esos prefijos. De forma predeterminada, solo la dirección de circuito cerrado se anuncia en LDP. Para configurar el conjunto de prefijos de la tabla de enrutamiento que se anunciará en LDP, incluya la egress-policy instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

Nota:

Si configura una política de salida para LDP que no incluye la dirección de circuito cerrado, ya no se anuncia en LDP. Para seguir anunciando la dirección de circuito cerrado, debe configurarla explícitamente como parte de la política de salida del PLD.

La política denominada (configurada en el [edit policy-options] nivel de jerarquía o [edit logical-systems logical-system-name policy-options] de jerarquía) se aplica a todas las rutas de la tabla de enrutamiento. Esas rutas que coincidan con la política se anuncian en LDP. Puede controlar el conjunto de vecinos al que se anuncian esos prefijos mediante la instrucción export . Solo from se consideran operadores; puede usar cualquier operador válido from . Para obtener más información, consulte la biblioteca de protocolos de enrutamiento de Junos OS para dispositivos de enrutamiento.

Nota:

Los enrutadores serie ACX no admiten el nivel de jerarquía [edit logical-systems].

Ejemplo: Configuración de los prefijos anunciados en LDP

Anuncie todas las rutas conectadas a LDP:

Configuración de la deagregación de FEC

Cuando un enrutador de salida LDP anuncia varios prefijos, los prefijos se enlazan a una sola etiqueta y se agregan en una sola clase de equivalente de reenvío (FEC). De forma predeterminada, LDP mantiene esta agregación a medida que el anuncio atraviesa la red.

Normalmente, dado que un LSP no se divide en varios saltos siguientes y los prefijos están enlazados a un único LSP, no se produce equilibrio de carga en rutas de igual costo. Sin embargo, puede equilibrar la carga en rutas de igual costo si configura una política de equilibrio de carga y desagrega las FE.

Al desagregar las FEC, cada prefijo se vincula a una etiqueta independiente y se convierte en un LSP independiente.

Para configurar fecs desaggregadas, incluya la deaggregate instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

Para todas las sesiones de LDP, puede configurar FET desaggregados solo de forma global.

Desaggregar una FEC permite que los múltiples LSP resultantes se distribuyan a través de varias rutas de igual costo y distribuye los LSP en los múltiples saltos siguientes en los segmentos de salida, pero solo instala un salto siguiente por LSP.

Para agregar FET, incluya la no-deaggregate instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

Para todas las sesiones de LDP, puede configurar FET agregadas solo de forma global.

Configuración de politización para FET de LDP

Puede configurar Junos OS para rastrear y controlar el tráfico de los FET de LDP. Las políticas FEC de LDP se pueden utilizar para hacer cualquiera de los siguientes:

  • Rastree o controle el tráfico de entrada de una FEC LDP.

  • Rastree o controle el tráfico de tránsito de una FEC LDP.

  • Rastree o ordene el tráfico de LDP FEC que se origina en una clase de reenvío específica.

  • Rastree o ordene el tráfico de FEC de LDP que se origina en un sitio específico de enrutamiento y reenvío virtual (VRF).

  • Descarte el tráfico falso con destino a una FEC de LDP específica.

Para configurar el tráfico de una FEC LDP, primero debe configurar un filtro. Específicamente, debe configurar la interface instrucción o la interface-set instrucción en el [edit firewall family protocol-family filter filter-name term term-name from] nivel de jerarquía. La interface instrucción le permite hacer coincidir el filtro con una sola interfaz. La interface-set instrucción le permite hacer coincidir el filtro con varias interfaces.

Para obtener más información sobre cómo configurar la instrucción, la interface instrucción y los policías para los FET de LDP, consulte la Guía del usuario de políticas de enrutamiento, filtros de firewall y policías de tráfico.interface-set

Una vez configurados los filtros, debe incluirlos en la configuración de instrucción policing para LDP. Para configurar los policias para los FET de LDP, incluya la policing instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

La policing instrucción incluye las siguientes opciones:

  • fec— Especifique la dirección FEC para la FEC LDP que desea dirigir.

  • ingress-filter— Especifique el nombre del filtro de tráfico de entrada.

  • transit-traffic— Especifica el nombre del filtro de tráfico de tránsito.

Configuración del filtrado FEC IPv4 de LDP

De forma predeterminada, cuando se establece una sesión de LDP de destino, Junos OS siempre intercambia tanto las clases de equivalencia de reenvío (FE) de IPv4 como las FE de circuito de capa 2 a través de la sesión LDP de destino. Para una sesión de LDP a un vecino conectado indirectamente, es posible que solo desee exportar fecs de circuito de capa 2 al vecino si la sesión está específicamente configurada para admitir circuitos de capa 2 o VPLS.

En una red de proveedores mixtos en la que todos los prefijos que no sean del BGP se anuncian en LDP, la base de datos de LDP puede volverse grande. Para este tipo de entorno, puede ser útil evitar el anuncio de FET IPv4 en sesiones LDP formadas debido a la configuración del circuito de capa 2 o LDP VPLS. Del mismo modo, puede ser útil filtrar cualquier FET IPv4 recibida en este tipo de entorno.

Si todos los vecinos de LDP asociados con una sesión de LDP son solo de capa 2, puede configurar Junos OS para que anuncie solo feCs de circuito de capa 2 mediante la configuración de la l2-smart-policy instrucción. Esta función también filtra automáticamente los FET IPv4 recibidos en esta sesión. Configurar una política explícita de exportación o importación que se activa para l2-smart-policy deshabilitar esta función en la dirección correspondiente.

Si uno de los vecinos de la sesión de LDP se forma debido a una adyacencia descubierta o si la adyacencia se forma debido a una configuración de tunelización de LDP en uno o más LSP RSVP, las FE IPv4 se anuncian y se reciben utilizando el comportamiento predeterminado.

Para evitar que LDP exporte FET IPv4 a través de sesiones de LDP con solo vecinos de capa 2 y para filtrar las FE de IPv4 recibidas durante dichas sesiones, incluya la l2-smart-policy instrucción:

Para obtener una lista de niveles de jerarquía en los que puede configurar esta instrucción, consulte el resumen de instrucción de esta instrucción.

Configuración de BFD para LSP LDP

Puede configurar la detección de reenvío bidireccional (BFD) para LSP de LDP. El protocolo BFD es un simple mecanismo de saludo que detecta fallas en una red. Los paquetes de saludo se envían a un intervalo regular y especificado. Se detecta un error de vecino cuando el enrutador deja de recibir una respuesta después de un intervalo especificado. BFD funciona con una amplia variedad de entornos de red y topologías. Los temporizadores de detección de fallas para BFD tienen límites de tiempo más cortos que los mecanismos de detección de fallas de rutas estáticas, lo que proporciona una detección más rápida.

Se registra un error cada vez que se produce un error en la sesión de BFD de una ruta. A continuación se muestra cómo puede aparecer el BFD para los mensajes de registro LSP LSP:

También puede configurar BFD para LSP RSVP, como se describe en Configuración de BFD para LSP señalizadas de RSVP.

Los temporizadores de detección de fallas de BFD son adaptables y se pueden ajustar para que sean más o menos agresivos. Por ejemplo, los temporizadores pueden adaptarse a un valor más alto si la adyacencia falla, 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 una solap de sesión BFD ocurre más de tres veces en un lapso de 15 segundos. Un algoritmo de respaldo aumenta el intervalo de recepción (Rx) en dos si la instancia de BFD local es el motivo del flap de sesión. El intervalo de transmisión (tx) aumenta dos si la instancia de BFD remota es la razón de la flap de sesión. Puede usar el clear bfd adaptation comando para devolver temporizadores de intervalo BFD a sus valores configurados. El clear bfd adaptation comando no tiene golpes, lo que significa que el comando no afecta al flujo de tráfico en el dispositivo de enrutamiento.

Para habilitar BFD para LSP LDP, incluya las oam instrucciones y bfd-liveness-detection :

Puede habilitar BFD para los LSP de LDP asociados con una clase de equivalencia de reenvío (FEC) específica configurando la dirección FEC mediante la fec opción en el [edit protocols ldp] nivel de jerarquía. Alternativamente, puede configurar una política de entrada de administración y administración de operaciones (OAM) para habilitar BFD en un rango de direcciones FEC. Para obtener más información, consulte Configuración de políticas de entrada de OAM para LDP.

No puede habilitar LSP de LDP BFD a menos que sus direcciones FEC equivalentes estén explícitamente configuradas o que la OAM esté habilitada en las FEC mediante una política de entrada de OAM. Si BFD no está habilitado para ninguna dirección FEC, la sesión BFD no aparecerá.

Puede configurar la oam instrucción en los siguientes niveles jerárquicos:

  • [edit protocols ldp]

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

Nota:

Los enrutadores serie ACX no admiten el nivel de jerarquía [edit logical-systems].

La oam instrucción incluye las siguientes opciones:

  • fec— Especifica la dirección FEC. Debe especificar una dirección FEC o configurar una política de entrada de OAM para asegurarse de que la sesión BFD aparezca.

  • lsp-ping-interval— Especifica la duración del intervalo de ping LSP en segundos. Para emitir un ping en un LSP con señal de LDP, utilice el ping mpls ldp comando. Para obtener más información, consulte el Explorador de CLI.

La bfd-liveness-detection instrucción incluye las siguientes opciones:

  • ecmp: haga que LDP establezca sesiones BFD para todas las rutas ECMP configuradas para la FEC especificada. Si configura la ecmp opción, también debe configurar la periodic-traceroute instrucción para la FEC especificada. Si no lo hace, se produce un error en la operación de confirmación. Puede configurar la periodic-traceroute instrucción en el nivel de jerarquía global ([edit protocols ldp oam]) mientras configura solo la ecmp opción para una FEC específica ([edit protocols ldp oam fec address bfd-liveness-detection]).

  • intervalo de contención : especifique la duración que debe permanecer activa la sesión de BFD antes de agregar la ruta o el siguiente salto. Especificar un tiempo de 0 segundos hace que la ruta o el salto siguiente se agreguen tan pronto como se vuelva a activar la sesión BFD.

  • minimum-interval— Especifica el intervalo mínimo de transmisión y recepción. Si configura la minimum-interval opción, no es necesario configurar la minimum-receive-interval opción ni la minimum-transmit-interval opción.

  • minimum-receive-interval— Especifique el intervalo de recepción mínimo. 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.

  • multiplier— Especifica el multiplicador de tiempo de detección. El rango es de 1 a 255.

  • version (version): especifique la versión de BFD. Las opciones son BFD versión 0 o BFD versión 1. De forma predeterminada, el software Junos OS intenta determinar automáticamente la versión de BFD.

Configuración de BFD con conocimiento de ECMP para LSP LDP

Cuando configure BFD para una FEC, se establece una sesión BFD para solo un salto local activo para el enrutador. Sin embargo, puede configurar varias sesiones BFD, una para cada FEC asociada con una ruta específica de múltiples rutas de igual costo (ECMP). Para que esto funcione correctamente, también debe configurar LSP ruta de seguimiento periódico LSP. (Consulte Configuración de LSP LSP Traceroute.) LDP LSP traceroute se utiliza para descubrir rutas ECMP. Se inicia una sesión BFD para cada ruta ECMP descubierta. Siempre que se produce un error en una sesión BFD para una de las rutas ECMP, se registra un error.

LDP LSP traceroute se ejecuta periódicamente para comprobar la integridad de las rutas ECMP. Cuando se detecta un problema, es posible que ocurra lo siguiente:

  • Si el enrutamiento de seguimiento LSP más reciente de LSP para una FEC difiere del anterior traceroute, las sesiones BFD asociadas con esa FEC (las sesiones BFD para rangos de direcciones que han cambiado con respecto a la ejecución anterior) se desactivan y se inician nuevas sesiones BFD para las direcciones de destino en los rangos alterados.

  • Si el LSP traceroute LSP devuelve un error (por ejemplo, un tiempo de espera), todas las sesiones de BFD asociadas con ese FEC se desmontarán.

Para configurar LDP para establecer sesiones BFD para todas las rutas ECMP configuradas para la FEC especificada, incluya la ecmp instrucción.

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

Junto con la ecmp instrucción, también debe incluir la periodic-traceroute instrucción, ya sea en la configuración de OAM global LDP (en el [edit protocols ldp oam] nivel de jerarquía o [edit logical-systems logical-system-name protocols ldp oam] de jerarquía) o en la configuración para la FEC especificada (en el [edit protocols ldp oam fec address] nivel de jerarquía o [edit logical-systems logical-system-name protocols ldp oam fec address] de jerarquía). De lo contrario, se produce un error en la operación de confirmación.

Nota:

Los enrutadores serie ACX no admiten el nivel de jerarquía [edit logical-systems].

Configuración de una acción de error para la sesión BFD en un LSP

Puede configurar las propiedades de ruta y salto siguiente en caso de un evento de falla de sesión BFD en un LSP LDP. El evento de falla podría ser una sesión BFD existente que haya caído o podría ser una sesión BFD que nunca llegó. LDP vuelve a agregar la ruta o el siguiente salto cuando la sesión BFD relevante vuelve a subir.

Puede configurar una de las siguientes opciones de acción de error para la failure-action instrucción en caso de que se produzca un error de sesión BFD en el LSP LDP:

  • remove-nexthop: quita la ruta correspondiente al siguiente salto de la ruta del LSP en el nodo de entrada cuando se detecta un evento de falla de sesión BFD.

  • remove-route— Quita la ruta correspondiente al LSP de las tablas de enrutamiento adecuadas cuando se detecta un evento de falla de sesión BFD. Si el LSP está configurado con ECMP y una sesión BFD correspondiente a cualquier ruta cae, la ruta se elimina.

Para configurar una acción de error en caso de que se produzca un error en la sesión de BFD en un LSP LDP, incluya la remove-nexthop opción o la remove-route opción para la failure-action instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

Configuración del intervalo de espera para la sesión BFD

Puede especificar la duración de la sesión BFD antes de agregar una ruta o el siguiente salto configurando la holddown-interval instrucción en el [edit protocols ldp oam bfd-livenesss-detection] nivel de jerarquía o en el [edit protocols ldp oam fec address bfd-livenesss-detection] nivel de jerarquía. Especificar un tiempo de 0 segundos hace que la ruta o el salto siguiente se agreguen tan pronto como se vuelva a activar la sesión BFD.

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

Descripción del reenrutamiento rápido de solo multidifusión

El reenrutamiento rápido de solo multidifusión (MoFRR) minimiza la pérdida de paquetes para el tráfico en un árbol de distribución de multidifusión cuando se producen fallas de vínculo, lo que mejora los protocolos de enrutamiento de multidifusión, como la multidifusión independiente de protocolo (PIM) y el protocolo de distribución de etiquetas multipunto (LDP multipunto) en dispositivos que admiten estas funciones.

Nota:

En conmutadores, no se admite MoFRR con rutas conmutadas por etiquetas MPLS y LDP multipunto.

Para los enrutadores serie MX, MoFRR solo se admite en enrutadores serie MX con tarjetas de línea MPC. Como requisito previo, debe configurar el enrutador en network-services enhanced-ip modo y todas las tarjetas de línea del enrutador deben ser MPC.

Con MoFRR habilitado, los dispositivos envían mensajes de unión en rutas ascendentes principales y de respaldo hacia una fuente de multidifusión. Los dispositivos reciben paquetes de datos de las rutas principal y de respaldo, y descartan los paquetes redundantes según la prioridad (pesos que se asignan a las rutas principal y de respaldo). Cuando un dispositivo detecta un error en la ruta principal, inmediatamente comienza a aceptar paquetes de la interfaz secundaria (la ruta de copia de seguridad). El cambio rápido mejora en gran medida los tiempos de convergencia en caso de fallas de vínculo de ruta principal.

Una aplicación para MoFRR es la transmisión de IPTV. Las transmisiones de IPTV son multidifusión como flujos UDP, por lo que no se retransmiten los paquetes perdidos, lo que lleva a una experiencia del usuario menos que satisfactoria. MoFRR puede mejorar la situación.

Descripción general de MoFRR

Con el reenrutamiento rápido en flujos de unidifusión, un dispositivo de enrutamiento ascendente preestablece las rutas conmutadas por etiquetas (LSP) de MPLS o precompute una ruta de respaldo de reenrutamiento rápido alternativa sin bucles IP (LFA) para manejar fallas de un segmento en la ruta descendente.

En el enrutamiento de multidifusión, el lado receptor generalmente origina los gráficos de distribución de tráfico. Esto es a diferencia del enrutamiento de unidifusión, que generalmente establece la ruta desde el origen hasta el receptor. PIM (para IP), LDP de varios puntos (para MPLS) y RSVP-TE (para MPLS) son protocolos capaces de establecer gráficos de distribución de multidifusión. De estos, los receptores PIM y LDP multipunto inician la configuración del gráfico de distribución, por lo que MoFRR puede trabajar con estos dos protocolos de multidifusión donde son compatibles.

En un árbol de multidifusión, si el dispositivo detecta una falla en un componente de red, lleva un tiempo realizar una reparación reactiva, lo que lleva a una pérdida significativa de tráfico mientras configura una ruta alternativa. El MoFRR reduce la pérdida de tráfico en un árbol de distribución de multidifusión cuando falla un componente de red. Con el MoFRR, uno de los dispositivos de enrutamiento descendente configura una ruta alternativa hacia la fuente para recibir una transmisión en vivo de respaldo del mismo tráfico de multidifusión. Cuando ocurre una falla en la transmisión principal, el dispositivo de enrutamiento MoFRR puede cambiar rápidamente a la secuencia de respaldo.

Con MoFRR habilitado, para cada entrada (S, G), el dispositivo utiliza dos de las interfaces ascendentes disponibles para enviar un mensaje de unión y recibir tráfico de multidifusión. El protocolo intenta seleccionar dos rutas disjuntas si hay dos de estas rutas disponibles. Si las rutas disjuntas no están disponibles, el protocolo selecciona dos rutas no disjuntas. Si dos rutas no disjuntos no están disponibles, solo se selecciona una ruta principal sin copia de seguridad. El MoFRR prioriza la copia de seguridad desarticulado a favor de equilibrar la carga de las rutas disponibles.

MoFRR se admite para familias de protocolos IPv4 e IPv6.

Figura 12 muestra dos rutas desde el dispositivo de enrutamiento del receptor de multidifusión (también conocido como el dispositivo de borde del proveedor de salida (PE)) al dispositivo de enrutamiento de origen de multidifusión (también conocido como dispositivo de PE de entrada).

Figura 12: Topología de ejemplo MoFRRTopología de ejemplo MoFRR

Con MoFRR habilitado, el dispositivo de enrutamiento de salida (lado del receptor) configura dos árboles de multidifusión, una ruta principal y una ruta de respaldo, hacia el origen de multidifusión para cada uno (S, G). En otras palabras, el dispositivo de enrutamiento de salida propaga los mismos mensajes de unión (S, G) hacia dos vecinos ascendentes diferentes, creando así dos árboles de multidifusión.

Uno de los árboles de multidifusión pasa por el plano 1 y el otro por el plano 2, como se muestra en Figura 12. Para cada (S,G), el dispositivo de enrutamiento de salida reenvía el tráfico recibido en la ruta principal y deja caer el tráfico recibido en la ruta de respaldo.

MoFRR se admite tanto en rutas de múltiples rutas de costo igual (ECMP) como en rutas que no son ECMP. El dispositivo debe habilitar rutas alternativas sin bucle de unidifusión (LFA) para admitir MoFRR en rutas que no son ECMP. Habilitar rutas de LFA mediante la link-protection instrucción en la configuración del protocolo de puerta de enlace interior (IGP). Cuando habilita la protección de vínculos en una interfaz OSPF o IS-IS, el dispositivo crea una ruta LFA de respaldo al siguiente salto principal para todas las rutas de destino que atraviesan la interfaz protegida.

Junos OS implementa MoFRR en la red IP para IP MoFRR y en el dispositivo de enrutamiento de borde de etiqueta (LER) de MPLS para MoFRR de LDP multipunto.

El MoFRR de LDP multipunto se utiliza en el dispositivo de salida de una red MPLS, donde los paquetes se reenvían a una red IP. Con el MoFRR de LDP multipunto, el dispositivo establece dos rutas hacia el dispositivo de enrutamiento de PE ascendente para recibir dos flujos de paquetes MPLS en el LER. El dispositivo acepta una de las secuencias (la principal) y la otra (la copia de seguridad) se cae en el LER. Si se produce un error en la ruta principal, el dispositivo aceptará la secuencia de respaldo en su lugar. La compatibilidad con la señalización en banda es un requisito previo para MoFRR con LDP multipunto (consulte Descripción de la señalización de banda de LDP multipunto para LSP de punto a multipunto).

Funcionalidad de PIM

Junos OS admite MoFRR para que el árbol de ruta más corta (SPT) se une en multidifusión específica de fuente PIM (SSM) y multidifusión de cualquier fuente (ASM). MoFRR es compatible con los rangos SSM y ASM. Para habilitar MoFRR para las uniónes (*,G), incluya la mofrr-asm-starg instrucción de configuración en la [edit routing-options multicast stream-protection] jerarquía. Para cada grupo G, el MoFRR funcionará para (S,G) o (*, G), pero no para ambos. (S, G) siempre tiene prioridad sobre (*, G).

Con MoFRR habilitado, un dispositivo de enrutamiento PIM propaga mensajes de unión en dos interfaces ascendentes de reenvío de ruta inversa (RPF) para recibir tráfico de multidifusión en ambos vínculos para la misma solicitud de unión. MoFRR da preferencia a dos rutas que no convergen al mismo dispositivo de enrutamiento ascendente inmediato. PIM instala rutas de multidifusión adecuadas con próximos saltos RPF ascendentes con dos interfaces (para las rutas principal y de respaldo).

Cuando se produce un error en la ruta principal, la ruta de copia de seguridad se actualiza al estado principal y el dispositivo reenvía el tráfico en consecuencia. Si hay rutas alternativas disponibles, MoFRR calcula una nueva ruta de copia de seguridad y actualiza o instala la ruta de multidifusión adecuada.

Puede habilitar MoFRR con equilibrio de carga de unión PIM (consulte la join-load-balance automatic instrucción). Sin embargo, en ese caso, es posible que la distribución de mensajes de unión entre los vínculos no sea uniforme. Cuando se agrega un nuevo vínculo ECMP, los mensajes de unión en la ruta principal se redistribuyen y se equilibran la carga. Es posible que los mensajes de unión en la ruta de copia de seguridad sigan la misma ruta y no se redistribuyan de manera uniforme.

Puede habilitar MoFRR mediante la stream-protection instrucción de configuración en la [edit routing-options multicast] jerarquía. El MoFRR se administra mediante un conjunto de políticas de filtro.

Cuando un dispositivo de enrutamiento PIM de salida recibe un mensaje de unión o un informe IGMP, comprueba si hay una configuración MoFRR y procede de la siguiente manera:

  • Si la configuración MoFRR no está presente, PIM envía un mensaje de unión aguas arriba hacia un vecino ascendente (por ejemplo, el plano 2 en Figura 12).

  • Si la configuración moFRR está presente, el dispositivo comprueba una configuración de política.

  • Si una política no está presente, el dispositivo comprueba las rutas principal y de respaldo (interfaces ascendentes) y procede de la siguiente manera:

    • Si las rutas principal y de respaldo no están disponibles, PIM envía un mensaje de unión aguas arriba hacia un vecino ascendente (por ejemplo, el plano 2 en Figura 12).

    • Si las rutas principal y de respaldo están disponibles, PIM envía el mensaje de unión aguas arriba hacia dos de los vecinos ascendentes disponibles. Junos OS configura rutas de multidifusión primarias y secundarias para recibir tráfico de multidifusión (por ejemplo, plano 1 en Figura 12).

  • Si hay una política presente, el dispositivo comprueba si la política permite el MoFRR para esto (S,G) y procede de la siguiente manera:

    • Si se produce un error en esta comprobación de política, PIM envía un mensaje de unión aguas arriba hacia un vecino ascendente (por ejemplo, el plano 2 en Figura 12).

    • Si se aprueba esta comprobación de política: el dispositivo comprueba las rutas principal y de respaldo (interfaces ascendentes).

      • Si las rutas principal y de respaldo no están disponibles, PIM envía un mensaje de unión aguas arriba hacia un vecino ascendente (por ejemplo, el plano 2 en Figura 12).

      • Si las rutas principal y de respaldo están disponibles, PIM envía el mensaje de unión aguas arriba hacia dos de los vecinos ascendentes disponibles. El dispositivo configura las rutas de multidifusión principal y secundaria para recibir tráfico de multidifusión (por ejemplo, el plano 1 en Figura 12).

Funcionalidad de LDP multipunto

Para evitar la duplicación de tráfico de MPLS, el LDP multipunto suele seleccionar solo una ruta ascendente. (Véase la sección 2.4.1.1. Determinar el LSR ascendente en RFC 6388, Extensiones de protocolo de distribución de etiquetas para rutas conmutadas de etiquetas de punto a multipunto y de multipunto a multipunto).

Para LDP multipunto con MoFRR, el dispositivo LDP multipunto selecciona dos pares ascendentes separados y envía dos etiquetas separadas, una a cada par ascendente. El dispositivo usa el mismo algoritmo descrito en RFC 6388 para seleccionar la ruta ascendente principal. El dispositivo usa el mismo algoritmo para seleccionar la ruta ascendente de copia de seguridad, pero excluye el LSR ascendente principal como candidato. Los dos pares ascendentes diferentes envían dos flujos de tráfico MPLS al dispositivo de enrutamiento de salida. El dispositivo selecciona solo una de las rutas vecinas ascendentes como la ruta principal desde la cual aceptar el tráfico MPLS. La otra ruta se convierte en la ruta de respaldo, y el dispositivo pierde ese tráfico. Cuando se produce un error en la ruta ascendente principal, el dispositivo comienza a aceptar tráfico de la ruta de respaldo. El dispositivo LDP multipunto selecciona las dos rutas ascendentes según el siguiente salto del dispositivo raíz del protocolo de puerta de enlace interior (IGP).

Una clase de equivalente de reenvío (FEC) es un grupo de paquetes IP que se reenvían de la misma manera, a través de la misma ruta y con el mismo tratamiento de reenvío. Normalmente, la etiqueta que se pone en un paquete determinado representa la FEC a la que se asigna ese paquete. En el MoFRR, se colocan dos rutas en la tabla mpls.0 para cada FEC: una ruta para la etiqueta principal y la otra ruta para la etiqueta de copia de seguridad.

Si hay vínculos paralelos hacia el mismo dispositivo inmediato ascendente, el dispositivo considera que ambos vínculos paralelos son los principales. En cualquier momento, el dispositivo ascendente envía tráfico solo en uno de los múltiples vínculos paralelos.

Un nodo bud es una LSR que es una LSR de salida, pero que también tiene uno o más LSR descendente directamente conectados. En el caso de un nodo bud, el tráfico de la ruta principal ascendente se reenvía a una LSR descendente. Si se produce un error en la ruta ascendente principal, el tráfico de MPLS desde la ruta ascendente de respaldo se reenvía a la LSR descendente. Esto significa que el próximo salto LSR descendente se agrega a ambas rutas MPLS junto con el salto siguiente de salida.

Al igual que con PIM, se habilita MoFRR con LDP de varios puntos mediante la stream-protection instrucción de configuración en la [edit routing-options multicast] jerarquía, y se administra mediante un conjunto de políticas de filtro.

Si ha habilitado la FEC de punto a multipunto LDP de punto a multipunto para MoFRR, el dispositivo tiene en cuenta las siguientes consideraciones para seleccionar la ruta ascendente:

  • Las sesiones de LDP dirigidas se omiten si hay una sesión LDP no dirigida. Si hay una sola sesión LDP de destino, se selecciona la sesión LDP de destino, pero la FEC de punto a multipunto correspondiente pierde la capacidad MoFRR porque no hay ninguna interfaz asociada con la sesión LDP de destino.

  • Se considera que todas las interfaces que pertenecen a la misma LSR ascendente son la ruta principal.

  • Para cualquier actualización de ruta de nodo raíz, la ruta ascendente se cambia según los próximos saltos más recientes del IGP. Si hay una mejor ruta disponible, el LDP multipunto intenta cambiar a la mejor ruta.

Reenvío de paquetes

Para PIM o LDP de multipunto, el dispositivo realiza la selección de flujo de origen de multidifusión en la interfaz de entrada. Esto preserva el ancho de banda de la estructura y maximiza el rendimiento del reenvío, ya que:

  • Evita enviar flujos duplicados a través de la estructura

  • Evita varias búsquedas de ruta (que provocan caídas de paquetes).

Para PIM, cada transmisión de multidifusión IP contiene la misma dirección de destino. Independientemente de la interfaz a la que llegan los paquetes, los paquetes tienen la misma ruta. El dispositivo comprueba la interfaz a la que llega cada paquete y reenvía solo aquellos que son de la interfaz principal. Si la interfaz coincide con una interfaz de transmisión de respaldo, el dispositivo deja caer los paquetes. Si la interfaz no coincide con la interfaz de flujo principal o de copia de seguridad, el dispositivo controla los paquetes como excepciones en el plano de control.

Figura 13 muestra este proceso con interfaces principales y de respaldo de ejemplo para enrutadores con PIM. Figura 14 lo muestra de manera similar para los conmutadores con PIM.

Figura 13: Búsqueda de ruta de IP MoFRR en el motor de reenvío de paquetes en enrutadoresBúsqueda de ruta de IP MoFRR en el motor de reenvío de paquetes en enrutadores
Figura 14: Manejo de rutas de IP MoFRR en el motor de reenvío de paquetes en conmutadoresManejo de rutas de IP MoFRR en el motor de reenvío de paquetes en conmutadores

Para MoFRR con LDP multipunto en enrutadores, el dispositivo usa varias etiquetas MPLS para controlar la selección de flujo MoFRR. Cada etiqueta representa una ruta independiente, pero cada una hace referencia a la misma lista de interfaces. El dispositivo solo reenvía la etiqueta principal y deja caer todos los demás. Varias interfaces pueden recibir paquetes con la misma etiqueta.

Figura 15 muestra este proceso para enrutadores con LDP multipunto.

Figura 15: Búsqueda de ruta MoFRR MPLS en el motor de reenvío de paquetesBúsqueda de ruta MoFRR MPLS en el motor de reenvío de paquetes

Limitaciones y advertencias

Limitaciones y advertencias del MoFRR en dispositivos de conmutación y enrutamiento

MoFRR tiene las siguientes limitaciones y advertencias en los dispositivos de enrutamiento y conmutación:

  • La detección de fallas de MoFRR es compatible con la protección inmediata de vínculos del dispositivo de enrutamiento en el que está habilitado MoFRR y no en todos los vínculos (de extremo a extremo) de la ruta de tráfico de multidifusión.

  • MoFRR admite el reenrutamiento rápido en dos rutas desarticuladas seleccionadas hacia el origen. Dos de los vecinos seleccionados ascendentes no pueden estar en la misma interfaz; en otras palabras, dos vecinos ascendentes en un segmento LAN. Lo mismo es cierto si la interfaz ascendente es una interfaz de túnel de multidifusión.

  • No se admite la detección de la cantidad máxima de rutas ascendentes desarticuladas de extremo a extremo. El dispositivo de enrutamiento del lado del receptor (salida) solo se asegura de que haya un dispositivo ascendente inconexo (el salto anterior inmediato). La PIM y el LDP de varios puntos no admiten el equivalente de objetos de ruta explícitos (ERE). Por lo tanto, la detección de rutas ascendentes desarticulando se limita al control sobre el dispositivo de salto inmediatamente anterior. Debido a esta limitación, es posible que se comparta la ruta al dispositivo ascendente del salto anterior seleccionado como principal y de copia de seguridad.

  • Es posible que vea alguna pérdida de tráfico en las siguientes situaciones:

    • Una mejor ruta ascendente está disponible en un dispositivo de salida.

    • MoFRR está habilitado o deshabilitado en el dispositivo de salida mientras fluye una corriente de tráfico activa.

  • No se admite el equilibrio de carga de unión PIM para mensajes de unión para rutas de respaldo.

  • Para un grupo de multidifusión G, el MoFRR no está permitido para los mensajes de unión (S,G) y (*,G). Los mensajes de unión (S, G) tienen prioridad sobre (*, G).

  • MoFRR no se admite para flujos de tráfico de multidifusión que utilizan dos grupos de multidifusión diferentes. Cada combinación (S, G) se trata como un flujo de tráfico de multidifusión único.

  • El rango PIM bidireccional no se admite con MoFRR.

  • El modo denso PIM no se admite con MoFRR.

  • PIM no mantiene las estadísticas de multidifusión para el flujo de tráfico de respaldo y, por lo tanto, no están disponibles en la salida operativa de show los comandos.

  • No se admite la supervisión de velocidad.

Limitaciones del MoFRR en la conmutación de dispositivos con PIM

El MoFRR con PIM tiene las siguientes limitaciones en dispositivos de conmutación:

  • No se admite MoFRR cuando la interfaz ascendente es una interfaz de enrutamiento y puente integrados (IRB), lo que afecta a otras funciones de multidifusión, como el esnooping del Protocolo de administración de grupos de Internet versión 3 (IGMPv3).

  • La replicación de paquetes y las búsquedas de multidifusión, mientras que el tráfico de multidifusión reenvío pueden hacer que los paquetes se recirculan a través de PPE varias veces. Como resultado, los valores mostrados para los recuentos de paquetes de multidifusión del show pfe statistics traffic comando pueden mostrar números más altos que los esperados en campos de salida como Input packets y Output packets. Es posible que note este comportamiento con mayor frecuencia en escenarios de MoFRR, ya que las secuencias primarias y de copia de seguridad duplicadas aumentan el flujo de tráfico en general.

Limitaciones y advertencias del MoFRR en dispositivos de enrutamiento con LDP multipunto

El MoFRR tiene las siguientes limitaciones y advertencias en enrutadores cuando se utiliza con LDP de varios puntos:

  • MoFRR no se aplica al tráfico de LDP multipunto recibido en un túnel RSVP, ya que el túnel RSVP no está asociado con ninguna interfaz.

  • No se admite el MoFRR ascendente mixto. Esto se refiere a la señalización en banda de LDP multipunto PIM, en la que una ruta ascendente es a través de LDP multipunto y la segunda ruta ascendente es a través de PIM.

  • No se admiten etiquetas LDP multipunto como etiquetas internas.

  • Si se puede llegar al origen a través de varios dispositivos de enrutamiento perimetral (PE) de proveedor de entrada (lado de fuente), no se admite moFRR de LDP multipunto.

  • Las sesiones ascendentes de LDP dirigidas no se seleccionan como el dispositivo ascendente para MoFRR.

  • No se admite la protección de vínculos LDP multipunto en la ruta de copia de seguridad, ya que no se admiten etiquetas internas MoFRR.

Configurar el reenrutamiento rápido de solo multidifusión

Puede configurar el reenrutamiento rápido de solo multidifusión (MoFRR) para minimizar la pérdida de paquetes en una red cuando se produce un error de vínculo.

Cuando se aplica un reenrutamiento rápido a flujos de unidifusión, un enrutador ascendente preestablece las rutas de conmutación de etiquetas (LSP) de MPLS o precompute una ruta de respaldo de reenrutamiento rápido alternativa sin bucles IP (LFA) para manejar fallas de un segmento en la ruta descendente.

En el enrutamiento de multidifusión, los gráficos de distribución de tráfico suelen ser originados por el receptor. Esto es a diferencia del enrutamiento de unidifusión, que generalmente establece la ruta desde el origen hasta el receptor. Los protocolos que son capaces de establecer gráficos de distribución de multidifusión son PIM (para IP), LDP de multipunto (para MPLS) y RSVP-TE (para MPLS). De estos, los receptores PIM y LDP multipunto inician la configuración del gráfico de distribución y, por lo tanto:

  • En la serie QFX, MoFRR se admite en dominios PIM.

  • En las series MX y SRX, el MoFRR se admite en dominios PIM y LDP multipunto.

Los pasos de configuración son los mismos para habilitar MoFRR para PIM en todos los dispositivos que admiten esta función, a menos que se indique lo contrario. También se indican los pasos de configuración que no son aplicables a LDP MoFRR de varios puntos.

(Solo para enrutadores serie MX) MoFRR es compatible con enrutadores de la serie MX con tarjetas de línea MPC. Como requisito previo, todas las tarjetas de línea del enrutador deben ser MPC.

Para configurar MoFRR en enrutadores o conmutadores:

  1. (Solo para enrutadores serie MX y SERIE SRX) Establezca el enrutador en modo IP mejorado.
  2. Habilite el MoFRR.
  3. (Opcional) Configure una política de enrutamiento que se filtre para un conjunto restringido de flujos de multidifusión que se verán afectados por la configuración de MoFRR.

    Puede aplicar filtros basados en direcciones de origen o grupo.

    Por ejemplo:

  4. (Opcional) Si configuró una política de enrutamiento para filtrar el conjunto de grupos de multidifusión que se verán afectados por la configuración de MoFRR, aplique la política de protección de flujos MoFRR.

    Por ejemplo:

  5. (Opcional) En un dominio PIM con MoFRR, permita que MoFRR se aplique a las conexiones de multidifusión de cualquier origen (ASM) (*, G).

    Esto no se admite para LDP MoFRR de varios puntos.

  6. (Opcional) En un dominio PIM con MoFRR, permita que solo se seleccione un RPF desarticulados (un RPF en un plano independiente) como ruta de RPF de respaldo.

    Esto no se admite para LDP MoFRR de varios puntos. En un dominio MoFRR de LDP multipunto, la misma etiqueta se comparte entre vínculos paralelos al mismo vecino ascendente. Este no es el caso en un dominio PIM, donde cada vínculo forma un vecino. La mofrr-disjoint-upstream-only instrucción no permite seleccionar una ruta RPF de copia de seguridad si la ruta va al mismo vecino ascendente que la de la ruta RPF principal. Esto garantiza que el MoFRR se active solo en una topología que tenga varios vecinos RPF ascendentes.

  7. (Opcional) En un dominio PIM con MoFRR, evite el envío de mensajes de unión en la ruta de copia de seguridad, pero conserve todas las demás funciones de MoFRR.

    Esto no se admite para LDP MoFRR de varios puntos.

  8. (Opcional) En un dominio PIM con MoFRR, permita que la selección de la nueva ruta principal se base en la selección de la puerta de enlace de unidifusión para la ruta de unidifusión al origen y que cambie cuando se produce un cambio en la selección de unidifusión, en lugar de que la ruta de copia de seguridad se promocione como principal. Esto garantiza que el salto de RPF principal esté siempre en la mejor ruta.

    Cuando se incluye la mofrr-primary-selection-by-routing instrucción, no se garantiza que la ruta de copia de seguridad se promocione como la nueva ruta principal cuando la ruta principal cae.

    Esto no se admite para LDP MoFRR de varios puntos.

Ejemplo: Configuración del reenrutamiento rápido de solo multidifusión en un dominio LDP multipunto

En este ejemplo, se muestra cómo configurar el reenrutamiento rápido de solo multidifusión (MoFRR) para minimizar la pérdida de paquetes en una red cuando se produce un error de vínculo.

El MoFRR de LDP multipunto se utiliza en el nodo de salida de una red MPLS, donde los paquetes se reenvían a una red IP. En el caso del MoFRR de LDP multipunto, las dos rutas hacia el enrutador de borde de proveedor ascendente (PE) se establecen para recibir dos flujos de paquetes MPLS en el enrutador de borde de etiquetas (LER). Se acepta una de las secuencias (la principal) y la otra (la copia de seguridad) se pierde en el LER. La secuencia de copia de seguridad se acepta si se produce un error en la ruta principal.

Requisitos

No se requiere ninguna configuración especial más allá de la inicialización del dispositivo antes de configurar este ejemplo.

En un dominio LDP multipunto, para que MoFRR funcione, solo el enrutador de PE de salida debe tener habilitado MoFRR. Los otros enrutadores no necesitan ser compatibles con MoFRR.

MoFRR es compatible con plataformas serie MX con tarjetas de línea MPC. Como requisito previo, el enrutador debe estar establecido network-services enhanced-ip en modo y todas las tarjetas de línea de la plataforma deben ser MPC.

En este ejemplo, se requiere la versión 14.1 o posterior de Junos OS en el enrutador de PE de salida.

Descripción general

En este ejemplo, el dispositivo R3 es el enrutador de borde de salida. MoFRR solo está habilitado en este dispositivo.

El OSPF se utiliza para la conectividad, aunque se puede utilizar cualquier protocolo de puerta de enlace interior (IGP) o rutas estáticas.

Para fines de prueba, los enrutadores se utilizan para simular el origen y el receptor. Los dispositivos R4 y R8 están configurados para unirse estáticamente al grupo deseado mediante el set protocols igmp interface interface-name static group group comando. En el caso de que un host receptor de multidifusión real no esté disponible, como en este ejemplo, esta configuración igMP estática es útil. En los receptores, para que escuchen la dirección del grupo de multidifusión, en este ejemplo se utiliza set protocols sap listen group.

La configuración de MoFRR incluye una opción de política que no se muestra en este ejemplo, pero que se explica por separado. La opción se configura de la siguiente manera:

Topología

Figura 16 muestra la red de ejemplo.

Figura 16: MoFRR en un dominio LDP multipunto MoFRR en un dominio LDP multipunto

Configuración rápida de CLI muestra la configuración de todos los dispositivos en Figura 16.

En la sección Configuración se describen los pasos del dispositivo R3.

Configuración rápida de CLI

Configuración rápida de CLI

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

Dispositivo src1

Dispositivo src2

Dispositivo R1

Dispositivo R2

Dispositivo R3

Dispositivo R4

Dispositivo R5

Dispositivo R6

Dispositivo R7

Dispositivo R8

Configuración

Procedimiento

Procedimiento paso a paso

El siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración en la Guía del usuario de la CLI de Junos OS.

Para configurar el dispositivo R3:

  1. Habilite el modo IP mejorado.

  2. Configure las interfaces del dispositivo.

  3. Configure el número de sistema autónomo (AS).

  4. Configure las políticas de enrutamiento.

  5. Configure PIM.

  6. Configure LDP.

  7. Configure un IGP o rutas estáticas.

  8. Configure el BGP interno.

  9. Configure MPLS y, opcionalmente, RSVP.

  10. Habilite el MoFRR.

Resultados

Desde el modo de configuración, ingrese los comandos , show interfaces, show protocols, show policy-optionsy show routing-options para confirmar la show chassisconfiguración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.

Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.

Verificación

Confirme que la configuración funciona correctamente.

Comprobar las clases de equivalencia de reenvío punto a multipunto LDP

Propósito

Asegúrese de que el MoFRR está habilitado y determine qué etiquetas se están utilizando.

Acción
Significado

El resultado muestra que MoFRR está habilitado y muestra que las etiquetas 301568 y 301600 se utilizan para los dos LSP de punto a multipunto LDP.

Examinar la información de la etiqueta

Propósito

Asegúrese de que el dispositivo de salida tiene dos interfaces ascendentes para la unión de grupo de multidifusión.

Acción
Significado

El resultado muestra las rutas ascendentes principales y las rutas ascendentes de respaldo. También muestra los próximos saltos de RPF.

Comprobación de las rutas de multidifusión

Propósito

Examine la tabla de reenvío de multidifusión IP para asegurarse de que hay una lista de interfaz RPF ascendente, con una interfaz principal y una interfaz de respaldo.

Acción
Significado

El resultado muestra las sesiones principales y de respaldo, y los próximos saltos de RPF.

Comprobar las estadísticas de tráfico de punto a multipunto del LDP

Propósito

Asegúrese de que se enumeran las estadísticas principales y de respaldo.

Acción
Significado

El resultado muestra las rutas principal y de respaldo con las etiquetas.

Ejemplo: Configurar LDP descendente a pedido

En este ejemplo, se muestra cómo configurar LDP descendente a pedido. El LDP se configura comúnmente mediante el modo de anuncio no solicitado descendente, lo que significa que los anuncios de etiquetas para todas las rutas se reciben de todos los pares de LDP. A medida que los proveedores de servicios integran las redes de acceso y agregación en un solo dominio de MPLS, se necesitan LDP descendentes a pedido para distribuir los enlaces entre las redes de acceso y agregación, y para reducir los requisitos de procesamiento para el plano de control.

Los nodos descendentes podrían recibir decenas de miles de enlaces de etiquetas de los nodos de agregación ascendentes. En lugar de aprender y almacenar todos los enlaces de etiquetas para todas las direcciones de circuito cerrado posibles dentro de toda la red MPLS, el nodo de agregación descendente se puede configurar mediante LDP descendente a pedido para solicitar solo los enlaces de etiquetas para los FET correspondientes a las direcciones de circuito cerrado de esos nodos de salida en los que tiene servicios configurados.

Requisitos

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

  • Enrutador serie M

  • Junos OS 12.2

Descripción general

Puede habilitar el anuncio de etiqueta LDP descendente a pedido para una sesión LDP mediante la inclusión de la instrucción descendente a pedido en el [edit protocols ldp session] nivel de jerarquía. Si ha configurado la fase descendente a pedido, el enrutador de Juniper Networks anuncia la solicitud descendente a pedido a sus enrutadores pares. Para que se establezca una sesión descendente a pedido entre dos enrutadores, ambos tienen que anunciar el modo descendente a pedido durante el establecimiento de la sesión de LDP. Si un enrutador anuncia el modo descendente no solicitado y el otro anuncia la distribución a pedido, se utiliza el modo descendente no solicitado.

Configuración

Configurar LDP descendente a pedido

Procedimiento paso a paso

Para configurar una política de LDP descendente a pedido y, luego, configurar esa política y habilitar LDP descendente a pedido en la sesión de LDP:

  1. Configure la política descendente a pedido (DOD-Request-Loopbacks en este ejemplo).

    Esta política hace que el enrutador reenvíe mensajes de solicitud de etiquetas solo a los FET que coincidan con la DOD-Request-Loopbacks política.

  2. Especifique la política DOD-Request-Loopbacks mediante la dod-request-policy instrucción en el [edit protocols ldp] nivel jerárquico.

    La política especificada con la dod-request-policy instrucción se utiliza para identificar los prefijos para enviar mensajes de solicitud de etiqueta. Esta política es similar a una política de salida o a una política de importación. Al procesar rutas desde la tabla de enrutamiento inet.0, el software Junos OS comprueba si las rutas coinciden con la DOD-Request-Loopbacks política (en este ejemplo). Si la ruta coincide con la política y la sesión LDP se negocia con el modo de anuncio del DOD, los mensajes de solicitud de etiqueta se envían a la sesión LDP descendente correspondiente.

  3. Incluya la downstream-on-demand instrucción en la configuración de la sesión LDP para habilitar el modo de distribución a pedido descendente.

Distribución de LDP descendente a pedido en rutas etiquetadas como BGP

Procedimiento paso a paso

Para distribuir LDP descendente bajo demanda rutas en BGP etiquetado, utilice una política de exportación de BGP.

  1. Configure la política de ruta de LDP (redistribute_ldp en este ejemplo).

  2. Incluya la política redistribute_ldp de ruta de LDP en la configuración del BGP (como parte de la configuración ebgp-to-abr del grupo BGP en este ejemplo).

    El BGP reenvía las rutas de LDP según la redistribute_ldp política al enrutador de PE remoto

Procedimiento paso a paso

Para restringir la propagación de etiquetas a otros enrutadores configurados en modo descendente no solicitado (en lugar de descendente a pedido), configure las siguientes políticas:

  1. Configure la dod-routes política para aceptar rutas de LDP.

  2. Configure la do-not-propagate-du-sessions política para no reenviar rutas a los vecinos 10.1.1.1, 10.2.2.2y 10.3.3.3.

  3. Configure la filter-dod-on-du-sessions política para evitar que las rutas examinadas por la dod-routes política se reenvíen a los enrutadores vecinos definidos en la do-not-propagate-du-sessions política.

  4. Especifique la filter-dod-routes-on-du-sesssion política como la política de exportación para BGP group ebgp-to-abr.

Resultados

Desde el modo de configuración, ingrese los comandos y show protocols ldp para confirmar la show policy-options configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.

Verificación

Verificar el modo de anuncio de etiqueta

Propósito

Confirme que la configuración funciona correctamente.

Utilice el show ldp session comando para comprobar el estado del modo de anuncio de etiqueta para la sesión LDP.

Acción

Emita los show ldp session comandos y show ldp session detail :

  • El siguiente resultado del comando indica que el show ldp sessionAdv. Mode (modo de anuncio de etiqueta) es (lo DOD que significa que la sesión LDP descendente a pedido está operativa):

  • El siguiente resultado del show ldp session detail comando indica que el Local Label Advertisement mode es , el valor predeterminado (es Downstream unsoliciteddecir, descendente a pedido no está configurado en la sesión local). Por el contrario, ambos Remote Label Advertisement modeNegotiated Label Advertisement mode indican que Downstream on demand está configurado en la sesión remota

Configuración del soporte de IPv6 nativo de LDP

El LDP se admite en una red solo IPv6 y en una red de doble pila IPv6 o IPv4, como se describe en el RFC 7552. Configure la familia de direcciones como inet para IPv4 o inet6 IPv6 o ambos, y la preferencia de transporte sea o IPv4IPv6. La dual-transport instrucción permite que el LDP de Junos OS establezca la conexión TCP mediante IPv4 con vecinos IPv4, y sobre IPv6 con vecinos IPv6 como una LSR de una sola pila. Los inet-lsr-id ID e inet6-lsr-id son los dos ID de LSR que se deben configurar para establecer una sesión LDP mediante transporte TCP IPv4 e IPv6. Estos dos IDENTIFICA no deben ser cero y deben configurarse con valores diferentes.

Antes de configurar IPv6 como doble pila, asegúrese de configurar los protocolos de enrutamiento y señalización.

Para configurar la compatibilidad con IPv6 nativa de LDP, debe hacer lo siguiente:

  1. Habilite la desagregación de clase de equivalencia de reenvío (FEC) para usar diferentes etiquetas para diferentes familias de direcciones.
  2. Configure familias de direcciones LDP.
  3. Configure la transport-preference instrucción para seleccionar el transporte preferido para la conexión TCP cuando estén habilitados IPv4 e IPv6. De forma predeterminada, IPv6 se utiliza como transporte TCP para establecer una conexión LDP.
  4. (Opcional) Configure el transporte dual para permitir que LDP establezca una sesión IPv4 independiente con un vecino IPv4 y una sesión IPv6 con un vecino IPv6. Configure inet-lsr-id como ID de LSR para IPv4 y inet6-lsr-id como ID de LSR para IPv6.

    Por ejemplo, configure inet-lsr-id como 10.255.0.1 e inet6-lsr-id como 10.1.1.1.

Ejemplo: Configuración del soporte de IPv6 nativo de LDP

En este ejemplo, se muestra cómo permitir que el protocolo de distribución de etiquetas (LDP) de Junos OS establezca la conexión TCP a través de IPv4 con vecinos IPv4, y a través de IPv6 con vecinos IPv6 como una LSR de una sola pila. Esto ayuda a evitar la tunelización de IPv6 a través del núcleo de MPLS IPv4 con rutas de conmutación de etiquetas (LSP) señalizadas por IPv4.

Requisitos

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

  • Dos enrutadores serie MX

  • Junos OS versión 16.1 o posterior se ejecuta en todos los dispositivos

Antes de configurar IPv6 como doble pila, asegúrese de configurar los protocolos de enrutamiento y señalización.

Descripción general

El LDP se admite en una red solo IPv6 y en una red de doble pila IPv6 o IPv4, como se describe en el RFC 7552. Configure la familia de direcciones como inet para IPv4 o inet6 IPv6. De forma predeterminada, IPv6 se utiliza como transporte TCP para la sesión LDP con sus pares cuando están habilitados IPv4 e IPv6. La instrucción de transporte dual permite al LDP de Junos establecer la conexión TCP a través de IPv4 con vecinos IPv4, y a través de IPv6 con vecinos IPv6 como una LSR de una sola pila. Los inet-lsr-id y inet6-lsr-id son los dos ID de LSR que se deben configurar para establecer una sesión LDP mediante transporte TCP IPv4 y IPv6. Estos dos IDENTIFICA no deben ser cero y deben configurarse con valores diferentes.

Topología

Figura 17 muestra el LDP IPv6 configurado como doble pila en los dispositivos R1 y R2.

Figura 17: Ejemplo de soporte de IPv6 nativo de LDP Ejemplo de soporte de IPv6 nativo de LDP

Configuración

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, copie y pegue los comandos en la CLI en el nivel de jerarquía y, luego, ingrese commit desde el [edit] modo de configuración.

R1

R2

Configuración de R1

Procedimiento paso a paso

El siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de cómo navegar por la CLI, consulte " Using the CLI Editor in Configuration Mode " en la Guía del usuario de la CLI de Junos OS.

Para configurar el dispositivo R1:

  1. Configure las interfaces.

  2. Asigne una dirección de circuito cerrado al dispositivo.

  3. Configure las interfaces IS-IS.

  4. Configure MPLS para usar interfaces LDP en el dispositivo.

  5. Habilite la desagregación de clase de equivalencia de reenvío (FEC) para usar diferentes etiquetas para diferentes familias de direcciones.

  6. Configure familias de direcciones LDP.

Resultados

Desde el modo de configuración, ingrese los comandos y show protocols para confirmar la show interfaces configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.

Configure la preferencia de transporte para seleccionar el transporte preferido

Configuración rápida de CLI
Procedimiento paso a paso

Puede configurar la transport-preference instrucción para seleccionar el transporte preferido para una conexión TCP cuando estén habilitados IPv4 e IPv6. De forma predeterminada, IPv6 se utiliza como transporte TCP para establecer una conexión LDP.

  • (Opcional) Configure la preferencia de transporte para una conexión LDP.

Procedimiento paso a paso
Resultados

Desde el modo de configuración, ingrese el comando para confirmar la show protocols configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.

Configurar el transporte dual para establecer sesiones separadas para IPv4 con un vecino IPv4 e IPv6 con un vecino IPv6

Procedimiento paso a paso

Puede configurar la dual-transport instrucción para permitir que LDP establezca una sesión IPv4 independiente con un vecino IPv4 y una sesión IPv6 con un vecino IPv6. Esto requiere la configuración como ID de inet-lsr-id LSR para IPv4 y inet6-lsr-id como ID de LSR para IPv6.

  • (Opcional) Configure el transporte dual para permitir que LDP establezca la conexión TCP a través de IPv4 con vecinos IPv4, y sobre IPv6 con vecinos IPv6 como una LSR de una sola pila.

Resultados

Desde el modo de configuración, ingrese el comando para confirmar la show protocols configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.

Verificación

Confirme que la configuración funciona correctamente.

Verificar las entradas de ruta en la tabla mpls.0
Propósito

Muestra la información de la tabla de rutas mpls.0.

Acción

En el dispositivo R1, desde el modo operativo, ejecute el show route table mpls.0 comando para mostrar la información de tabla de rutas mpls.0.

Significado

El resultado muestra la información de la tabla de rutas mpls.0.

Verificar las entradas de ruta en la tabla inet.3
Propósito

Muestra la información de la tabla de rutas inet.3.

Acción

En el dispositivo R1, desde el modo operativo, ejecute el show route table inet.3 comando para mostrar la información de tabla de rutas inet.3.

Significado

El resultado muestra la información de la tabla de rutas inet.3.

Verificar las entradas de ruta en la tabla inet6.3
Propósito

Muestra la información de la tabla de rutas inet6.3.

Acción

En el dispositivo R1, desde el modo operativo, ejecute el show route table inet6.3 comando para mostrar la información de tabla de ruta inet6.3.

Significado

El resultado muestra la información de la tabla de rutas inet6.3.

Verificar la base de datos de LDP
Propósito

Muestra la información de la base de datos del LDP.

Acción

En el dispositivo R1, desde el modo operativo, ejecute el comando para mostrar la show ldp database información de la base de datos del LDP.

Significado

El resultado muestra las entradas en la base de datos LDP.

Verificar la información de vecino de LDP
Propósito

Muestra la información de vecino de LDP.

Acción

En el dispositivo R1, desde el modo operativo, ejecute los show ldp neighbor comandos y show ldp neighbor extensive para mostrar información de vecino de LDP.

Significado

El resultado muestra información de vecino de LDP de direcciones IPv4 e IPv6.

Verificar la información de la sesión de LDP
Propósito

Muestra la información de la sesión de LDP.

Acción

En el dispositivo R1, desde el modo operativo, ejecute los show ldp session comandos y show ldp session extensive para mostrar la información de la sesión del LDP.

Significado

El resultado muestra información para la sesión LDP usando IPv6 como transporte TCP.

Verificación

Confirme que la configuración funciona correctamente.

Verificar la información de vecino de LDP
Propósito

Muestra la información de vecino de LDP.

Acción

En el dispositivo R1, desde el modo operativo, ejecute el show ldp neighbor extensive comando para mostrar información de vecino de LDP.

Significado

El resultado muestra información de vecino de LDP para las direcciones IPv4 e IPv6.

Verificar la información de la sesión de LDP
Propósito

Muestra la información de la sesión de LDP.

Acción

En el dispositivo R1, desde el modo operativo, ejecute el comando para mostrar la show ldp session extensive información de la sesión de LDP.

Significado

El resultado muestra información para la sesión LDP usando IPv6 como transporte TCP.

Verificación

Confirme que la configuración funciona correctamente.

Verificar la información de vecino de LDP
Propósito

Muestra la información de vecino de LDP.

Acción

En el dispositivo R1, desde el modo operativo, ejecute el show ldp neighbor extensive comando para mostrar información de vecino de LDP.

Significado

El resultado muestra información de vecino de LDP para las direcciones IPv4 e IPv6.

Verificar la información de la sesión de LDP
Propósito

Muestra la información de la sesión de LDP.

Acción

En el dispositivo R1, desde el modo operativo, ejecute el show ldp session extensive comando para mostrar información de vecino de LDP.

Ejemplo: Configuración de señalización en banda de LDP multipunto para LSP punto a multipunto

Descripción de la señalización de banda de LDP multipunto para LSP de punto a multipunto

El Protocolo de distribución de etiquetas multipunto (M-LDP) para rutas de conmutación de etiquetas de punto a multipunto (LSP) con señalización en banda es útil en una implementación con una red troncal IP/MPLS existente, en la cual debe transportar tráfico de multidifusión, para IPTV, por ejemplo.

Durante años, la solución más utilizada para el transporte de tráfico de multidifusión ha sido usar la multidifusión IP nativa en el núcleo del proveedor de servicios con tunelización de IP multipunto para aislar el tráfico del cliente. Un protocolo de enrutamiento de multidifusión, generalmente multidifusión independiente de protocolo (PIM), se despliega para configurar las rutas de reenvío. El enrutamiento de multidifusión IP se utiliza para el reenvío mediante la señalización PIM en el núcleo. Para que este modelo funcione, la red central debe estar habilitada para la multidifusión. Esto permite despliegues efectivos y estables incluso en escenarios de sistemas interautónomos (AS).

Sin embargo, en una red IP/MPLS existente, la implementación de PIM puede no ser la primera opción. Algunos operadores de telecomunicaciones están interesados en reemplazar la tunelización ip por la encapsulación de etiquetas MPLS. La motivación para pasarse a la conmutación de etiquetas MPLS es aprovechar las funciones de protección e ingeniería de tráfico de MPLS, y reducir la cantidad de sobrecarga de tráfico de control en el núcleo del proveedor.

Para ello, los proveedores de servicios están interesados en aprovechar la extensión de las implementaciones existentes para permitir que el tráfico de multidifusión pase a través. Las extensiones de multidifusión existentes para IP/MPLS son extensiones de punto a multipunto para RSVP-TE y extensiones de punto a multipunto y de multipunto a multipunto para LDP. Estos escenarios de despliegue se analizan en RFC 6826, Señalización en banda de LDP multipunto para rutas conmutadas de etiqueta de punto a multipunto y de multipunto a multipunto. Esta descripción general de la función está limitada a extensiones de punto a multipunto para LDP.

Cómo funciona M-LDP

Enlaces de etiquetas en señalización M-LDP

La extensión de multipunto a LDP utiliza elementos de la clase de equivalente de reenvío (FEC) de punto a multipunto y multipunto a multipunto (definido en RFC 5036, especificación LDP) junto con anuncios de capacidad, asignación de etiquetas y procedimientos de señalización. Los elementos FEC incluyen la idea de la raíz LSP, que es una dirección IP, y un valor "opaco", que es un selector que agrupa los nodos leaf que comparten el mismo valor opaco. El valor opaco es transparente para los nodos intermedios, pero tiene significado para la raíz LSP. Cada nodo LDP anuncia su etiqueta entrante local enlazando al nodo LDP ascendente en la ruta más corta a la dirección IP raíz que se encuentra en la FEC. El nodo ascendente que recibe los enlaces de etiquetas crea su propia etiqueta local e interfaces de salida. Este proceso de asignación de etiquetas puede dar lugar a la replicación de paquetes, si hay varias sucursales de salida. Como se muestra en Figura 18, un nodo LDP fusiona los enlaces de etiquetas para el mismo valor opaco si encuentra nodos descendentes que comparten el mismo nodo ascendente. Esto permite la construcción eficaz de LSP de punto a multipunto y la conservación de etiquetas.

Figura 18: Enlaces de etiquetas en señalización M-LDPEnlaces de etiquetas en señalización M-LDP
M-LDP en núcleo MPLS sin PIM

Figura 19 muestra un escenario de implementación horizontal. Dos dominios PIM separados están interconectados por un sitio central sin PIM. Los enrutadores de borde de este sitio de núcleo admiten PIM en las interfaces de borde. Además, estos enrutadores de borde recopilan y distribuyen la información de enrutamiento desde los sitios adyacentes hasta la red central. Los enrutadores de borde en el sitio C ejecutan BGP para el descubrimiento de nodos raíz. Las rutas del protocolo de puerta de enlace interior (IGP) no se pueden usar para el descubrimiento de entrada, ya que en la mayoría de los casos el siguiente salto de reenvío proporcionado por el IGP no proporcionaría información sobre el dispositivo de entrada hacia el origen. La señalización en banda M-LDP tiene una asignación uno a uno entre el LSP de punto a multipunto y el flujo (S, G). Con la señalización en banda, los mensajes PIM se traducen directamente a enlaces FEC M-LDP. Por el contrario, la señalización fuera de banda se basa en la configuración manual. Una aplicación para la señalización de banda M-LDP es transportar tráfico de multidifusión IPTV en una red troncal MPLS.

Figura 19: Topología de ejemplo de M-LDP en núcleo MPLS sin PIMTopología de ejemplo de M-LDP en núcleo MPLS sin PIM
Configuración

La instrucción de configuración mldp-inband-signalling en el enrutador de etiqueta-borde (LER) permite que PIM use señalización M-LDP en banda para los vecinos ascendentes cuando el LER no detecta un vecino PIM aguas arriba. La configuración estática de la raíz LSP de MPLS se incluye en la configuración de PIM mediante la política. Esto es necesario cuando el IBGP no está disponible en el sitio principal o para invalidar la detección de raíz de LSP basada en IBGP.

Por ejemplo:

M-LDP en núcleo MPLS habilitado para PIM

A partir de la versión 14.1 de Junos OS, para migrar los servicios de IPTV existentes de la multidifusión ip nativa a la multidifusión MPLS, debe hacer una transición fluida de PIM a LSP de punto a multipunto M-LDP con una interrupción mínima. Figura 20 muestra una topología Figura 19M-LDP similar a , pero con un escenario diferente. El núcleo está habilitado con PIM, con una fuente de transmisión de todos los canales IPTV. Los canales de TV se envían como flujos ASM con cada canal identificado por su dirección de grupo. Anteriormente, estos canales se transmitían en el núcleo como flujos IP y se señalizaban mediante PIM.

Figura 20: Topología de ejemplo de M-LDP en núcleo MPLS habilitado para PIMTopología de ejemplo de M-LDP en núcleo MPLS habilitado para PIM

Al configurar el en este escenario, la mldp-inband-signaling señalización M-LDP se inicia solo cuando no hay ningún piM vecino hacia el origen. Sin embargo, dado que siempre hay un PIM vecino hacia el origen, a menos que PIM se desactive en las interfaces ascendentes del PE de salida, PIM tiene prioridad sobre M-LDP y M-LDP no tiene efecto.

Configuración

Para migrar progresivamente canal por canal al núcleo de M-LDP MPLS con pocos flujos que usen M-LDP ascendente y otros flujos que usen PIM ascendente existente, incluya la selected-mldp-egress instrucción de configuración junto con filtros basados en grupo en el filtro de políticas para la señalización de banda de M-LDP.

Nota:

El filtro de política de señalización de banda M-LDP puede incluir la source-address-filter instrucción o la route-filter instrucción, o una combinación de ambas.

Por ejemplo:

Nota:

Algunas de las limitaciones de la configuración anterior son las siguientes:

  • La selected-mldp-egress instrucción debe configurarse solo en el LER. Configurar la selected-mldp-egress instrucción en enrutadores PIM sin salida puede causar errores en la configuración de la ruta.

  • Cuando se realizan cambios de política para cambiar el tráfico de PIM ascendente a M-LDP ascendente y viceversa, se puede esperar una pérdida de paquetes a medida que se realiza el mecanismo de interrupción y toma en el plano de control.

Terminología

Los siguientes términos son importantes para comprender la señalización en banda M-LDP para el tráfico de multidifusión.

Point-to-point LSP

Un LSP que tiene un enrutador de conmutación de etiquetas de entrada (LSR) y una LSR de salida.
Multipoint LSP

Ya sea un LSP de punto a multipunto o de multipunto a multipunto.
Point-to-multipoint LSP

Un LSP que tiene una LSR de entrada y uno o más LSR de salida.
Multipoint-to-point LSP

Un LSP que tiene una o más LSR de entrada y una LSR de salida única.
Multipoint-to-multipoint LSP

Un LSP que conecta un conjunto de nodos, de modo que el tráfico enviado por cualquier nodo en el LSP se entrega a todos los demás.

Ingress LSR

Un LSR de entrada para un LSP determinado es un LSR que puede enviar un paquete de datos a lo largo del LSP. Los LSP de varios puntos a multipunto pueden tener varios LSR de entrada. Los LSP de punto a multipunto tienen solo uno, y ese nodo se suele denominar nodo raíz.
Egress LSR

Un LSR de salida para un LSP en particular es un LSR que puede eliminar un paquete de datos de ese LSP para su posterior procesamiento. Los LSP de punto a punto y multipunto a punto tienen un solo nodo de salida. Los LSP de punto a multipunto y de multipunto a multipunto pueden tener varios nodos de salida.
Transit LSR

Un LSR que tiene accesibilidad a la raíz de la LSP multipunto a través de una LSR ascendente conectada directamente y uno o más LSR directamente conectados descendentemente.

Bud LSR

Una LSR que es una salida, pero que también tiene uno o más LSR descendente directamente conectados.
Leaf node

Ya sea una LSR de salida o de brote en el contexto de un LSP de punto a multipunto. En el contexto de un LSP de multipunto a multipunto, una LSR es tanto de entrada como de salida para el mismo LSP de multipunto a multipunto y también puede ser un LSR de raíz.

Incorporación de traducción y manejo de pseudo interfaz

En el LER de entrada, LDP notifica a PIM sobre los mensajes (S, G) que se reciben a través de la señalización en banda. El PIM asocia cada mensaje (S, G) con una pseudo interfaz. Posteriormente, se inicia un mensaje de unión de árbol de ruta más corta (SPT) hacia el origen. PIM lo trata como un nuevo tipo de receptor local. Cuando el LSP se derriba, PIM elimina este receptor local según la notificación de LDP.

Empalme de entrada

LDP proporciona a PIM un siguiente salto que se asociará con cada entrada (S, G). PIM instala una ruta de multidifusión PIM (S, G) con el salto siguiente de LDP y otros receptores PIM. El siguiente salto es un siguiente salto compuesto de receptores locales + la lista de pim vecinos descendentes + un salto siguiente de subni level para el túnel LDP.

Reenvío de ruta inversa

El cálculo del reenvío de ruta inversa (RPF) de PIM se realiza en el nodo de salida.

PIM realiza señalización M-LDP en banda cuando se cumplen todas las condiciones siguientes:

  • No hay vecinos PIM hacia la fuente.

  • La instrucción de señalización en banda M-LDP está configurada.

  • El siguiente salto se aprende a través del BGP o está presente en la asignación estática (especificada en una política de señalización en banda M-LDP).

De lo contrario, si se produce un error en la detección de raíz de LSP, PIM conserva la entrada (S,G) con un estado RPF sin resolver.

PIM RPF registra esta dirección de origen cada vez que cambia la información de enrutamiento de unidifusión. Por lo tanto, si la ruta hacia el origen cambia, se vuelve a calcular el RPF. Los próximos saltos del protocolo BGP hacia el origen también se monitorean para detectar cambios en la raíz LSP. Estos cambios podrían causar interrupciones del tráfico durante breves duraciones.

Detección de raíz LSP

Si la operación de RPF detecta la necesidad de señalización de M-LDP en banda ascendente, se detecta la raíz LSP (entrada). Esta raíz es un parámetro para la señalización LSP de LDP.

El nodo raíz se detecta de la siguiente manera:

  1. Si la configuración estática existente especifica la dirección de origen, la raíz se toma como se indica en la configuración.

  2. Se realiza una búsqueda en la tabla de enrutamiento de unidifusión. Si se encuentra la dirección de origen, el siguiente salto del protocolo hacia el origen se utiliza como raíz LSP.

    Antes de la versión 16.1 de Junos OS, el LSP de punto a multipunto M-LDP se señala desde una salida hacia la entrada mediante la dirección raíz de la LSR de entrada. Solo se puede acceder a esta dirección raíz mediante IGP, lo que limita el LSP de punto a multipunto M-LDP a un solo sistema autónomo. Si la dirección raíz no es accesible a través de un IGP, pero se puede acceder a través del BGP, y si esa ruta del BGP se resuelve recursivamente mediante un LSP MPLS, entonces el LSP de punto a multipunto no se indica más lejos desde ese punto hacia la dirección raíz de LSR de entrada.

    Existe la necesidad de que estos LSP de punto a multipunto no segmentados se señalen en varios sistemas autónomos, que se pueden usar para las siguientes aplicaciones:

    • MVPN entre AS con LSP de punto a multipunto no segmentados.

    • Señalización en banda de M-LDP del interAS entre redes de cliente conectadas por una red central MPLS.

    • Señalización en banda de MVPN o M-LDP entre áreas con LSP de punto a multipunto no segmentado (multidifusión MPLS sin problemas).

    A partir de la versión 16.1 de Junos OS, M-LDP puede señalar LSP de punto a multipunto en ASBR o transitar o salir cuando la dirección raíz es una ruta BGP que se resuelve recursivamente a través de un LSP MPLS.

Incorporación de la traducción y manejo de pseudo interfaces

En el LER de salida, la PIM notifica al LDP del mensaje (S,G) que se va a señalar junto con la raíz LSP. PIM crea una pseudo interfaz como interfaz ascendente para este mensaje (S, G). Cuando se recibe un mensaje de poda (S, G), se elimina esta asociación.

Empalme de salida

En el nodo de salida de la red central, donde se recibe el mensaje de unión (S,G) del sitio descendente, este mensaje de unión se traduce a los parámetros de señalización en banda M-LDP y se notifica al LDP. Además, el desmontaje de LSP ocurre cuando se pierde la entrada (S, G), cuando la raíz de LSP cambia, o cuando se puede acceder a la entrada (S, G) a través de un vecino PIM.

Funcionalidad compatible

Para la señalización en banda M-LDP, Junos OS admite la siguiente funcionalidad:

  • Empalme de salida del PIM siguiente salto con la ruta LDP

  • Empalme de entrada de la ruta PIM con el próximo salto del LDP

  • Traducción de mensajes de unión PIM a parámetros de configuración LSP punto a multipunto LSP

  • Traducción de parámetros LSP de M-LDP en banda para configurar mensajes de unión PIM

  • Detección de raíz de LSP basada en saltos y configurado estáticamente y el protocolo BGP

  • Estados PIM (S, G) en los rangos de multidifusión específica de fuente (SSM) y multidifusión de cualquier fuente (ASM)

  • Instrucciones de configuración en LER de entrada y salida para permitirles actuar como enrutadores de borde

  • IGMP une mensajes en LER

  • Llevar la dirección de grupo y origen IPv6 como información opaca hacia un nodo raíz IPv4

  • Configuración estática para asignar una IPv6 (S, G) a una dirección raíz IPv4

Funcionalidad no compatible

Para la señalización de M-LDP en banda, Junos OS no admite la siguiente funcionalidad:

  • Soporte completo para PIM ASM

  • El mpls lsp point-to-multipoint ping comando con una opción (S, G)

  • Enrutamiento activo sin interrupciones (NSR)

  • Make-before-break (MBB) para PIM

  • Direcciones raíz de LSP IPv6 (LDP no admite LSP IPv6.)

  • Relación de vecino entre altavoces PIM que no están conectados directamente

  • Reinicio agraciado

  • Modo denso PIM

  • Modo bidireccional PIM

Funcionalidad de LDP

La información PIM (S, G) se lleva como codificaciones de tipo-longitud (TLV) M-LDP opaca. El elemento FEC de punto a multipunto consta de la dirección del nodo raíz. En el caso de VPN de multidifusión de última generación (MVPN de NGEN), el LSP de punto a multipunto se identifica mediante la dirección del nodo raíz y el ID de LSP.

Funcionalidad de LER de salida

En el LER de salida, PIM activa LDP con la siguiente información para crear un LSP de punto a multipunto:

  • Nodo raíz

  • (S, G)

  • Siguiente salto

PIM encuentra el nodo raíz según el origen del árbol de multidifusión. Si la dirección raíz está configurada para esta entrada (S,G), la dirección configurada se utiliza como raíz LSP de punto a multipunto. De lo contrario, la tabla de enrutamiento se utiliza para buscar la ruta al origen. Si la ruta al origen del árbol de multidifusión es una ruta aprendida del BGP, PIM recupera la dirección del siguiente salto del BGP y la utiliza como nodo raíz para el LSP de punto a multipunto.

LDP encuentra el nodo ascendente según el nodo raíz, asigna una etiqueta y envía la asignación de etiquetas al nodo ascendente. LDP no usa penúltimo salto de salto (PHP) para la señalización M-LDP en banda.

Si las direcciones raíz del origen del árbol de multidifusión cambian, la PIM elimina el LSP de punto a multipunto y activa el LDP para crear un nuevo LSP de punto a multipunto. Cuando esto sucede, la lista de interfaz de salida se convierte en NULL, PIM activa LDP para eliminar el LSP de punto a multipunto, y LDP envía un mensaje de retirada de etiqueta al nodo ascendente.

Funcionalidad de LSR de tránsito

El LSR de tránsito anuncia una etiqueta en la LSR ascendente hacia el origen de la FEC de punto a multipunto e instala el estado de reenvío necesario para reenviar los paquetes. El LSR de tránsito puede ser cualquier enrutador compatible con M-LDP.

Funcionalidad de LER de entrada

En el LER de entrada, el LDP proporciona la siguiente información a PIM al recibir la asignación de etiquetas:

  • (S, G)

  • Inundar el próximo salto

Luego, PIM instala el estado de reenvío. Si se agregan o eliminan las nuevas sucursales, el salto siguiente inundación se actualiza en consecuencia. Si se eliminan todas las sucursales debido a que se retira una etiqueta, LDP envía la información actualizada a PIM. Si hay varios vínculos entre los vecinos ascendentes y descendentes, el LSP de punto a multipunto no está equilibrado de carga.

Consulte también

Ejemplo: Configuración de señalización en banda de LDP multipunto para LSP punto a multipunto

En este ejemplo, se muestra cómo configurar la señalización en banda de LDP (M-LDP) de varios puntos para el tráfico de multidifusión, como extensión del protocolo de multidifusión independiente de protocolo (PIM) o como sustituto de PIM.

Requisitos

Este ejemplo se puede configurar con los siguientes componentes de hardware y software:

  • Junos OS versión 13.2 o posterior

  • Plataformas de enrutamiento universal de 5G serie MX o enrutadores de borde multiservicio serie M para los enrutadores de borde de proveedor (PE)

  • Enrutadores de transporte de paquetes serie PTX que actúan como enrutadores conmutados por etiquetas de tránsito

  • Enrutadores de núcleo serie T para los enrutadores de núcleo

Nota:

Los enrutadores pe también podrían ser enrutadores de núcleo de la serie T, pero eso no es típico. Según sus requisitos de escala, los enrutadores principales también podrían ser plataformas de enrutamiento universal 5G serie MX o enrutadores de borde multiservicio serie M. Los dispositivos del borde del cliente (CE) podrían ser otros enrutadores o conmutadores de Juniper Networks u otro proveedor.

No se requiere ninguna configuración especial más allá de la inicialización del dispositivo antes de configurar este ejemplo.

Descripción general

Configuración rápida de CLI muestra la configuración de todos los dispositivos en Figura 21. En la sección #d158e70__d158e838 se describen los pasos de la salida del dispositivo.

Figura 21: Señalización de ejemplo de M-LDP en banda para LSP de punto a multipunto Señalización de ejemplo de M-LDP en banda para LSP de punto a multipunto

Configuración

Procedimiento
Configuración rápida de CLI

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

Dispositivo src1

PE de entrada del dispositivo

Egreso del dispositivo

Dispositivo p6

Dispositivo pr3

Dispositivo pr4

Dispositivo pr5

Procedimiento paso a paso

El siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración en la Guía del usuario de CLI.

Para configurar elPE de salida del dispositivo:

  1. Configure las interfaces.

    Habilite MPLS en las interfaces de núcleo. En los próximos saltos de salida, no es necesario habilitar MPLS.

  2. Configure IGMP en las interfaces de salida.

    Para fines de prueba, en este ejemplo se incluyen direcciones estáticas de grupo y origen.

  3. Configure MPLS en las interfaces de núcleo.

  4. Configure BGP.

    El BGP es un protocolo basado en políticas, por lo que también configure y aplique las políticas de enrutamiento necesarias.

    Por ejemplo, es posible que desee exportar rutas estáticas al BGP.

  5. (Opcional) Configure una conexión par MSDP con el dispositivo pr5 para interconectar los dominios PIM dispares, lo que permite los RP redundantes.

  6. Configure OSPF.

  7. Configure LDP en las interfaces de núcleo y en la interfaz de circuito cerrado.

  8. Habilite los LSP MPLS de punto a multipunto.

  9. Configure PIM en las interfaces descendentes.

  10. Configure la configuración de RP porque este dispositivo sirve como punto de encuentro PIM (RP).

  11. Habilite la señalización en banda M-LDP y establezca la política asociada.

  12. Configure la política de enrutamiento que especifica la dirección raíz para el LSP de punto a multipunto y las direcciones de origen asociadas.

  13. Configure el ID del sistema autónomo (AS).

Resultados

Desde el modo de configuración, ingrese los comandos , show protocols, show policy-optionsy show routing-options para confirmar la show interfacesconfiguración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.

Egreso del dispositivo

De manera similar, configure los otros dispositivos de salida.

Si ha terminado de configurar los dispositivos, ingrese commit desde el modo de configuración.

Verificación

Confirme que la configuración funciona correctamente.

Comprobar los estados de unión de PIM
Propósito

Muestra información sobre los estados de unión PIM para verificar los detalles ascendentes y descendentes de M-LDP en banda. En el dispositivo de entrada, el show pim join extensive comando se muestra Pseudo-MLDP para la interfaz descendente. En la salida, el show pim join extensive comando se muestra Pseudo-MLDP para la interfaz ascendente.

Acción

Desde el modo operativo, ingrese el show pim join extensive comando.

Comprobación de las fuentes PIM
Propósito

Verifique que las fuentes de PIM tengan los detalles esperados de M-LDP en la banda ascendente y descendente.

Acción

Desde el modo operativo, ingrese el show pim source comando.

Comprobar la base de datos de LDP
Propósito

Asegúrese de que el show ldp database comando muestra los enlaces root-to-(S,G) esperados.

Acción
Buscar la información de ruta para la etiqueta MPLS
Propósito

Muestra la información de FEC de punto a multipunto.

Acción
Comprobar las estadísticas de tráfico del LDP
Propósito

Monitoree las estadísticas de tráfico de datos para el LSP de punto a multipunto.

Acción

Asignación de cliente y servidor para el enrutamiento por segmentos a la interoperabilidad de LDP

El servidor de asignación de enrutamiento por segmentos y el soporte de cliente permiten la interoperabilidad entre las islas de red que ejecutan LDP y el enrutamiento por segmentos (SR o SPRING). Esta interoperabilidad es útil durante una migración de LDP a SR. Durante la transición puede haber islas (o dominios) con dispositivos que admiten solo LDP o solo enrutamiento por segmentos. Para que estos dispositivos intertraigan la funcionalidad del servidor de asignación de enrutamiento por segmentos (SRMS) de LDP y del cliente de asignación de enrutamiento por segmentos (SRMC). Active estas funciones de servidor y cliente en un dispositivo de la red de enrutamiento por segmentos.

La funcionalidad de cliente y servidor de asignación de SR se admite con OSPF o ISIS.

Descripción general del enrutamiento por segmentos para la interoperabilidad de LDP

Figura 22 muestra una topología de red LDP simple para ilustrar cómo funciona la interoperabilidad de los dispositivos de enrutamiento por segmentos con los dispositivos LDP. Tenga en cuenta que tanto OSPF como ISIS son compatibles, por lo que por ahora mantendremos las cosas agnósticas con respecto al IGP. La topología de muestra tiene seis dispositivos, de R1 a R6, en una red que se está sometiendo a una migración de LDP al enrutamiento por segmentos.

En la topología, los dispositivos R1, R2 y R3 están configurados solo para el enrutamiento por segmentos. Los dispositivos R5 y R6 forman parte de un dominio LDP heredado y actualmente no admiten SR. El dispositivo R4 es compatible con LDP y enrutamiento por segmentos. Se muestran las direcciones de circuito cerrado de todos los dispositivos. Estos circuitos cerrados se anuncian como FET de salida en el dominio LDP y como ID de nodo SR en el dominio SR. La interoperabilidad se basa en la asignación de una FEC LDP en un ID de nodo SR y viceversa.

Figura 22: Ejemplo de enrutamiento por segmentos a topología de interoperación de LDP Ejemplo de enrutamiento por segmentos a topología de interoperación de LDP

Para que R1 intertrabaja con R6, se necesitan tanto un servidor de asignación de enrutamiento de segmentos LDP (SRMS) como un cliente de asignación de enrutamiento por segmentos (SRMC). Es más fácil comprender el papel de SRMS y SRMC al ver el flujo de tráfico de una manera unidireccional. Figura 22Según , diremos que el tráfico que fluye de izquierda a derecha se origina en el dominio SR y termina en el dominio LDP. De manera similar, el tráfico que fluye de derecha a izquierda se origina en el dominio LDP y termina en el dominio SR.

El SRMS proporciona la información necesaria para unir el tráfico de izquierda a derecha. El SRMC proporciona asignación para el tráfico que fluye de derecha a izquierda.

  • Flujo de tráfico de izquierda a derecha: El servidor de asignación de enrutamiento por segmentos

    El SRMS facilita la unión de LSP entre los dominios SR y LDP. El servidor asigna FE de LDP en ID de nodo SR. Configure los FET de LDP para que se asignen bajo el [edit routing-options source-packet-routing] nivel de jerarquía. Normalmente, debe asignar todas las direcciones de circuito cerrado de nodo LDP para una conectividad completa. Como se muestra a continuación, puede asignar prefijos contiguos en una sola instrucción de rango. Si los bucles de circuito cerrado del nodo LDP no son contiguos, debe definir varias instrucciones de asignación.

    Puede aplicar la configuración de asignación SRMS en el [edit protocols ospf] nivel de jerarquía o [edit protocols isis] . Esta opción depende del IGP que se esté utilizando. Tenga en cuenta que tanto los nodos SR como LDP comparten un dominio de enrutamiento de IGP de área/nivel único.

    El SRMS genera una lista de prefijos extendida LSA (o LSP en el caso de ISIS). La información de esta LSA permite que los nodos SR asignen prefijos de LDP (FET) a los ID de nodo de SR. Las rutas asignadas para los prefijos de LDP se instalan en las inet.3 tablas y mpls.0 de enrutamiento de los nodos SR para facilitar la entrada de LSP y las operaciones de unión para el tráfico de izquierda a derecha.

    El LSA (o LSP) extendido se inunda en toda el área de IGP (única). Esto significa que es libre de colocar la configuración de SRMS en cualquier enrutador del dominio SR. El nodo SRMS no tiene que ejecutar LDP.

  • Flujo de tráfico de derecha a izquierda: Cliente de asignación de enrutamiento por segmentos

    Para interoperar en la dirección de derecha a izquierda, es decir, desde la isla LDP hasta la isla SR, simplemente habilite la funcionalidad de cliente de asignación de enrutamiento por segmentos en un nodo que hable tanto SR como LDP. En nuestro ejemplo, ese es R4. Puede activar la funcionalidad de SRMC con la mapping-client instrucción en la [edit protocols ldp] jerarquía.

    La configuración de SRMC activa automáticamente una política de salida de LDP para anunciar el nodo del dominio SR y los SID de prefijo como FET de salida de LDP. Esto proporciona a los nodos LDP la accesibilidad de LSP a los nodos del dominio SR.

  • La función SRMC debe configurarse en un enrutador que se conecte a los dominios SR y LSP. Si se desea, el mismo nodo también puede funcionar como SRMS.

Enrutamiento por segmentos a la interoperabilidad de LDP mediante OSPF

Haga referencia a Figura 22, suponga que device R2 (en la red de enrutamiento por segmentos) es el SRMS.

  1. Defina la función SRMS:

    Esta configuración crea un bloque de asignación para las direcciones de circuito cerrado del dispositivo LDP en la topología de ejemplo. El índice inicial del ID de segmento (SID) asignado al circuito cerrado de R5 es 1000. Si se especifica el tamaño 2 , el índice SID 10001 se asigna a la dirección de circuito cerrado de R6.

    Nota:

    La dirección IP utilizada como start-prefix es una dirección de circuito cerrado de un dispositivo en la red LDP (R5, en este ejemplo). Para una conectividad completa, debe asignar todas las direcciones de circuito cerrado de los enrutadores LDP en el dominio SR. Si las direcciones de circuito cerrado son contiguas, puede hacerlo con una sola prefix-segment-range instrucción. Las circuito cerrados no contiguos requieren la definición de varias instrucciones de asignación de prefijos.

    En nuestro ejemplo, se usan circuitos cerrados contiguas para que se muestre una sola prefix-segment-range . Este es un ejemplo de varias asignaciones para admitir el caso de dos nodos LDP con direccionamiento de circuito cerrado no contiguo:

  2. A continuación, configure la compatibilidad con OSPF para la LSA extendida que se utiliza para inundar los prefijos asignados.

    Una vez que se confirma la configuración del servidor de asignación en el dispositivo R2, el rango de prefijo extendido TLV se inunda en el área OSPF. Los dispositivos capaces de enrutamiento por segmentos (R1, R2 y R3) instalan rutas de enrutamiento de segmentos OSPF para la dirección de circuito cerrado especificada (R5 y R6 en este ejemplo), con un índice de ID de segmento (SID). Los dispositivos de enrutamiento por segmentos también actualizan el índice SID en la mpls.0 tabla de enrutamiento.

  3. Habilite la funcionalidad de SRMC. Para nuestra topología de ejemplo, debe habilitar la funcionalidad de SRMC en R4.

    Una vez que se confirma la configuración del cliente de asignación en el dispositivo R4, los ID de nodo sr y los bloques de etiquetas se anuncian como FET de salida al enrutador R5, que luego los vuelve a anunciar en R6.

El soporte para unir el enrutamiento por segmentos y los saltos próximos de LDP con OSPF comenzó en Junos OS 19.1R1.

Unsupported Features and Functionality for Segment Routing interoperability with LDP using OSPF

  • Los conflictosde prefijos solo se detectan en el SRMS. Cuando hay un conflicto de rango de prefijo, prevalecerá el SID del prefijo del ID de enrutador inferior. En tales casos, se genera un mensaje de error de registro del sistema —RPD_OSPF_PFX_SID_RANGE_CONFLICT—.

  • No se admiten los prefijos IPv6.

  • No se admite inundación del prefijo extendido LSA opaco opaco de OSPF a través de los límites del AS (interAS).

  • No se admite la funcionalidad del servidor de asignación de LDP entre áreas.

  • No se admite la funcionalidad ABR de la LSA opaca del prefijo extendido.

  • No se admite la funcionalidad ASBR del prefijo opaco extendido LSA.

  • No se admite el TLV delservidor de asignación de enrutamiento, por ejemplo.

Interoperabilidad del enrutamiento por segmentos con LDP mediante ISIS

Haga referencia a Figura 22, suponga que el dispositivo R2 (en la red de enrutamiento por segmentos) es el SRMS. La siguiente configuración se agrega para la función de asignación:

  1. Defina la función SRMS:

    Esta configuración crea un bloque de asignación para las direcciones de circuito cerrado del dispositivo LDP en la topología de ejemplo. El índice del ID de segmento inicial (SID) asignado al circuito cerrado de R5 es 1000. Si se especifica el tamaño 2 , el índice SID 10001 se asigna a la dirección de circuito cerrado de R6.

    Nota:

    La dirección IP utilizada como start-prefix es una dirección de circuito cerrado de un dispositivo en la red LDP (R5, en este ejemplo). Para una conectividad completa, debe asignar todas las direcciones de circuito cerrado de los enrutadores LDP en el dominio SR. Si las direcciones de circuito cerrado son contiguas, puede hacerlo con una prefix-segment-range instrucción. Las circuito cerrados no contiguos requieren la definición de varias instrucciones de asignación.

    En nuestro ejemplo, se usan circuitos cerrados contiguas para que se muestre una sola prefix-segment-range . Este es un ejemplo de asignaciones de prefijo para manejar el caso de dos enrutadores LDP con direccionamiento de circuito cerrado no contiguo:

  2. A continuación, configure el soporte de ISIS para el LSP extendido utilizado para inundar los prefijos mapeados.

    Una vez que se confirma la configuración del servidor de asignación en el dispositivo R2, el rango de prefijo extendido TLV se inunda en el área OSPF. Los dispositivos capaces de enrutamiento por segmentos (R1, R2 y R3) instalan rutas de enrutamiento de segmentos ISIS para la dirección de circuito cerrado especificada (R5 y R6 en este ejemplo), con un índice de ID de segmento (SID). Los dispositivos de enrutamiento por segmentos también actualizan el índice SID en la mpls.0 tabla de enrutamiento.

  3. Habilite la funcionalidad de SRMC. Para nuestra topología de ejemplo, debe habilitar la funcionalidad de SRMC en R4.

    Una vez que la configuración del cliente de asignación se confirma en el dispositivo R4, los ID de nodo de SR y los bloques de etiquetas se anuncian como FET de salida al enrutador R5 y, de ahí en adelante, a R6.

El soporte para unir el enrutamiento por segmentos y los próximos saltos de LDP con ISIS comenzó en Junos OS 17.4R1.

Unsupported Features and Functionality for Interoperability of Segment Routing with LDP using ISIS

  • No se admite el comportamiento de popping penúltimo de salto para el TLV de enlace de etiquetas.

  • No se admite la publicidad de rango de prefijos en el TLV de enlace de etiquetas.

  • No se admite la resolución de conflictos de enrutamiento por segmentos.

  • Las estadísticas de tráfico de LDP no funcionan.

  • No se admite el enrutamiento activo sin interrupciones (NSR) y el cambio agraciado del motor de enrutamiento (GRES).

  • Isis entre niveles no es compatible.

  • RFC 7794, Atributos de prefijo IS-IS para IPv4 extendido no es compatible.

  • No se admite la redistribución de la ruta de LDP como un prefijo en el nodo de unión.

Propiedades varias de LDP

En las siguientes secciones se describe cómo configurar varias propiedades de LDP.

Configurar LDP para usar la métrica de ruta de IGP

Use la track-igp-metric instrucción si desea que se use la métrica de ruta del protocolo de puerta de enlace interior (IGP) para las rutas LDP en lugar de la métrica de ruta de LDP predeterminada (la métrica de ruta de LDP predeterminada es 1).

Para usar la métrica de ruta IGP, incluya la track-igp-metric instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

Evitar la adición de rutas de entrada a la tabla de enrutamiento inet.0

Al configurar la no-forwarding instrucción, puede evitar que se agreguen rutas de entrada a la tabla de enrutamiento inet.0 en lugar de la tabla de enrutamiento inet.3, incluso si habilitó la traffic-engineering bgp-igp instrucción en el [edit protocols mpls] nivel de jerarquía o en el [edit logical-systems logical-system-name protocols mpls] . De forma predeterminada, la no-forwarding instrucción está deshabilitada.

Nota:

Los enrutadores de la serie ACX no admiten el nivel de jerarquía [edit logical-systems].

Para omitir rutas de entrada de la tabla de enrutamiento inet.0, incluya la no-forwarding instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

VPN de LDP y Carrier-of-Carrier-of-Carrier-of-Instance

Al configurar varias instancias de enrutamiento de LDP, puede usar LDP para anunciar etiquetas en una VPN de operadora de operadoras desde un enrutador de borde (PE) de proveedor de servicios hasta un enrutador de borde de cliente (CE) de operador de cliente. Esto es especialmente útil cuando el cliente operador es un proveedor de servicios de Internet (ISP) básico y quiere restringir las rutas de Internet completas a sus enrutadores de PE. Al usar LDP en lugar de BGP, el cliente operador protege a sus otros enrutadores internos de Internet. El LDP de varias instancias también es útil cuando un cliente de operadora desea proporcionar servicios VPN de capa 2 o capa 3 a sus clientes.

Para obtener un ejemplo de cómo configurar varias instancias de enrutamiento de LDP para VPN de operadora de operadora, consulte la Guía del usuario del protocolo de distribución de etiquetas para varias instancias.

Configure MPLS y LDP para abrir la etiqueta en el enrutador Ultimate-Hop

La etiqueta anunciada por defecto es la etiqueta 3 (etiqueta Null implícita). Si se anuncia la etiqueta 3, el enrutador de penúltimo salto elimina la etiqueta y envía el paquete al enrutador de salida. Si está habilitado el popping de último salto, se anuncia la etiqueta 0 (etiqueta IPv4 Explicit Null). El salto final garantiza que cualquier paquete que atraviesa una red MPLS incluya una etiqueta.

Para configurar el salto final, incluya la explicit-null instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

Nota:

Los enrutadores de Juniper Networks hacen colas de paquetes basados en la etiqueta entrante. Los enrutadores de otros proveedores pueden poner en cola los paquetes de manera diferente. Tenga esto en cuenta cuando trabaje con redes que contengan enrutadores de varios proveedores.

Para obtener más información acerca de las etiquetas, consulte Descripción general de etiquetas MPLS y asignación de etiquetas MPLS.

Habilitar LDP a través de LSP establecidos por RSVP

Puede ejecutar LDP a través de LSP establecidos por RSVP, túnelando efectivamente el LSP establecido por LDP a través del establecido por RSVP. Para ello, habilite LDP en la interfaz lo0.0 (consulte Habilitar y deshabilitar LDP). También debe configurar los LSP sobre los que desea que funcione el LDP incluyendo la ldp-tunneling instrucción en el [edit protocols mpls label-switched-path lsp-name] nivel de jerarquía:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

Nota:

El LDP se puede tunelización mediante una sesión RSVP que tenga habilitada la protección de vínculos. A partir de Junos OS R21.1R1, al mostrar detalles de la ruta tunelizadas LDP, se muestran los próximos saltos de LSP primarios y de bypass. En versiones anteriores de Junos OS, el salto siguiente del LSP de omisión muestra el siguiente salto para el LSP principal.

Habilitar LDP a través de LSP establecidos por RSVP en redes heterogéneas

Otros proveedores usan una métrica OSPF de 1 para la dirección de circuito cerrado. Los enrutadores de Juniper Networks usan una métrica OSPF de 0 para la dirección de circuito cerrado. Esto puede requerir que configure manualmente la métrica RSVP al implementar la tunelización de LDP en LSP RSVP en redes heterogéneas.

Cuando un enrutador de Juniper Networks está vinculado al enrutador de otro proveedor a través de un túnel RSVP y la tunelización de LDP también está habilitada, de forma predeterminada, es posible que el enrutador de Juniper Networks no use el túnel RSVP para enrutar tráfico a los destinos de LDP descendentes del enrutador de salida del otro proveedor si la ruta RSVP tiene una métrica de 1 más grande que la ruta física OSPF.

Para garantizar que la tunelización LDP funcione correctamente en redes heterogéneas, puede configurar OSPF para ignorar la métrica LSP RSVP incluyendo la ignore-lsp-metrics instrucción:

Puede configurar esta instrucción en los siguientes niveles jerárquicos:

  • [edit protocols ospf traffic-engineering shortcuts]

  • [edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts]

Nota:

Los enrutadores de la serie ACX no admiten el nivel de jerarquía [edit logical-systems].

Para habilitar LDP a través de LSP RSVP, también debe completar el procedimiento en la sección Habilitar LDP a través de LSP establecidos por RSVP.

Configure la firma TCP MD5 para sesiones LDP

Puede configurar una firma MD5 para una conexión TCP LDP para protegerse contra la introducción de segmentos TCP falsificados en flujos de conexión de sesión LDP. Para obtener más información acerca de la autenticación TCP, consulte TCP. Para ver cómo usar la opción de autenticación TCP (TCP-AO) en lugar de TCP MD5, consulte No link title.

Un enrutador que usa la opción de firma MD5 se configura con una contraseña para cada par para el que se requiere autenticación. La contraseña se almacena cifrada.

Las adyacencias hola LDP aún se pueden crear incluso cuando las interfaces de emparejamiento están configuradas con diferentes firmas de seguridad. Sin embargo, la sesión TCP no se puede autenticar y nunca se establece.

Puede configurar el código de autenticación de mensajes hash (HMAC) y la autenticación MD5 para sesiones de LDP como una configuración por sesión o una configuración de coincidencia de subred (es decir, coincidencia de prefijo más larga). La compatibilidad con la autenticación de subred y coincidencia de subred ofrece flexibilidad para configurar la autenticación para sesiones de LDP dirigidas automáticamente (TLDP). Esto facilita el despliegue de los pseudocables alternativos remotos sin bucle (LFA) y FEC 129.

Para configurar una firma MD5 para una conexión TCP LDP, incluya la authentication-key instrucción como parte del grupo de sesión:

Use la session-group instrucción para configurar la dirección para el final remoto de la sesión LDP.

La md5-authentication-key, o contraseña, en la configuración puede tener hasta 69 caracteres de longitud. Los caracteres pueden incluir cualquier cadena ASCII. Si incluye espacios, encierre todos los caracteres entre comillas.

También puede configurar un mecanismo de actualización de clave de autenticación para el protocolo de enrutamiento LDP. Este mecanismo le permite actualizar las claves de autenticación sin interrumpir los protocolos de enrutamiento y señalización asociados, como la ruta abierta más corta primero (OSPF) y el Protocolo de configuración de reserva de recursos (RSVP).

Para configurar el mecanismo de actualización de clave de autenticación, incluya la key-chain instrucción en el [edit security authentication-key-chains] nivel de jerarquía y especifique la key opción de crear un llavero que consta de varias claves de autenticación.

Para configurar el mecanismo de actualización de clave de autenticación para el protocolo de enrutamiento LDP, incluya la authentication-key-chain instrucción en el [edit protocols ldp] nivel jerárquico para asociar el protocolo con las claves de [edit security suthentication-key-chains] autenticación. También debe configurar el algoritmo de autenticación incluyendo la authentication-algorithm algorithm instrucción el [edit protocols ldp] nivel de jerarquía.

Para obtener más información acerca de la función de actualización de clave de autenticación, consulte Configuración del mecanismo de actualización de clave de autenticación para protocolos de enrutamiento BGP y LDP.

Configurar la protección de sesión de LDP

Normalmente, se crea una sesión LDP entre un par de enrutadores que están conectados por uno o más vínculos. Los enrutadores forman una adyacencia hola para cada vínculo que los conecta y asocian todas las adyacencias con la sesión LDP correspondiente. Cuando la última adyacencia de hola para una sesión LDP desaparece, la sesión LDP termina. Es posible que desee modificar este comportamiento para evitar que una sesión LDP se rescinda y restablezca innecesariamente.

Puede configurar Junos OS para dejar la sesión de LDP entre dos enrutadores en activo incluso si no hay adyacencias hola en los vínculos que conectan los dos enrutadores mediante la configuración de la session-protection instrucción. Opcionalmente, puede especificar un tiempo en segundos mediante la timeout opción. La sesión permanece activa durante la duración especificada, siempre que los enrutadores mantengan la conectividad de red IP.

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción.

Deshabilitar capturas SNMP para LDP

Cada vez que un LSP LDP hace una transición de arriba abajo o de abajo a arriba, el enrutador envía una trampa SNMP. Sin embargo, es posible deshabilitar las capturas SNMP de LDP en un enrutador, sistema lógico o instancia de enrutamiento.

Para obtener más información acerca de las capturas SNMP de LDP y el MIB de propiedad de LDP, consulte snmp MIB Explorer..

Para deshabilitar las capturas SNMP para LDP, especifique la trap disable opción para la log-updown instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

Configurar la sincronización de LDP con el IGP en vínculos LDP

El LDP es un protocolo para distribuir etiquetas en aplicaciones que no están diseñadas para el tráfico. Las etiquetas se distribuyen a lo largo de la mejor ruta determinada por el IGP. Si no se mantiene la sincronización entre el LDP y el IGP, el LSP se cae. Cuando el LDP no está completamente operativo en un vínculo determinado (no se establece una sesión y no se intercambian etiquetas), el IGP anuncia el vínculo con la métrica de costo máximo. No se prefiere el vínculo, pero permanece en la topología de red.

La sincronización de LDP solo se admite en interfaces activas de punto a punto e interfaces LAN configuradas como punto a punto bajo el IGP. La sincronización de LDP no se admite durante el reinicio agraciado.

Para anunciar la métrica de costo máximo hasta que el LDP esté operativo para la sincronización, incluya la ldp-synchronization instrucción:

Para deshabilitar la sincronización, incluya la disable instrucción. Para configurar el período de tiempo para anunciar la métrica de costo máximo para un vínculo que no esté completamente operativo, incluya la hold-time instrucción.

Para obtener una lista de niveles de jerarquía en los que puede configurar esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

Configurar la sincronización de LDP con el IGP en el enrutador

Puede configurar el tiempo que el LDP espera antes de informar al IGP que el vecino del LDP y la sesión de una interfaz están operativos. En el caso de redes grandes con numerosos FET, es posible que deba configurar un valor más largo para permitir el tiempo suficiente para que se intercambien las bases de datos de etiquetas de LDP.

Para configurar el tiempo que el LDP espera antes de informar al IGP que el vecino del LDP y la sesión están operativos, incluya la igp-synchronization instrucción y especifique un tiempo en segundos para la holddown-interval opción:

Para obtener una lista de niveles de jerarquía en los que puede configurar esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

Configurar el temporizador de retirada de etiquetas

El temporizador de retirada de etiquetas retrasa el envío de un mensaje de retirada de etiqueta para una FEC a un vecino. Cuando un vínculo de IGP a un vecino falla, la etiqueta asociada con la FEC debe retirarse de todos los enrutadores ascendentes si el vecino es el siguiente salto para la FEC. Después de que el IGP converge y se recibe una etiqueta de un nuevo salto siguiente, la etiqueta se readvierte a todos los enrutadores ascendentes. Este es el comportamiento típico de la red. Al retrasar la retirada de etiquetas en una pequeña cantidad de tiempo (por ejemplo, hasta que el IGP converge y el enrutador recibe una nueva etiqueta para la FEC del siguiente salto descendente), pronto se pudo evitar la retirada de etiquetas y el envío de una asignación de etiquetas. La label-withdrawal-delay instrucción le permite configurar este tiempo de retraso. De forma predeterminada, el retraso es de 60 segundos.

Si el enrutador recibe la nueva etiqueta antes de que se agote el temporizador, se cancelará el temporizador de retirada de etiquetas. Sin embargo, si se agota el temporizador, la etiqueta de la FEC se retira de todos los enrutadores ascendentes.

De forma predeterminada, el LDP espera 60 segundos antes de retirar las etiquetas para evitar renunciar a los LSP varias veces mientras el IGP vuelve a converger. Para configurar el tiempo de retraso de retirada de etiquetas en segundos, incluya la label-withdrawal-delay instrucción:

Para obtener una lista de niveles de jerarquía en los que puede configurar esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

Ignorar la comprobación de subred de LDP

En la versión 8.4 de Junos OS y versiones posteriores, se realiza una verificación de subred de dirección de origen del LDP durante el procedimiento de establecimiento vecino. La dirección de origen en el paquete de saludo del vínculo LDP se coincide con la dirección de interfaz. Esto causa un problema de interoperabilidad con los equipos de otros proveedores.

Para deshabilitar la comprobación de subred, incluya la allow-subnet-mismatch instrucción:

Esta instrucción se puede incluir en los siguientes niveles de jerarquía:

  • [edit protocols ldp interface interface-name]

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

Nota:

Los enrutadores serie ACX no admiten el nivel de jerarquía [edit logical-systems].

Consulte también

Configurar LSP Traceroute de LSP

Puede rastrear la ruta seguida de un LSP señal de LDP. LDP LSP traceroute está basado en RFC 4379, detectando fallas de plano de datos de etiquetas multiprotocolo (MPLS). Esta función le permite rastrear periódicamente todas las rutas en una FEC. La información de topología de FEC se almacena en una base de datos accesible desde la CLI.

Un cambio de topología no activa automáticamente un seguimiento de un LSP LDP. Sin embargo, puede iniciar manualmente una ruta de seguimiento. Si la solicitud de traceroute es para una FEC que se encuentra actualmente en la base de datos, el contenido de la base de datos se actualiza con los resultados.

La característica periódica traceroute se aplica a todas las FET especificadas por la oam instrucción configurada en el [edit protocols ldp] nivel de jerarquía. Para configurar LSP traceroute periódico de LSP, incluya la periodic-traceroute instrucción:

Puede configurar esta instrucción en los siguientes niveles jerárquicos:

  • [edit protocols ldp oam]

  • [edit protocols ldp oam fec address]

Puede configurar la periodic-traceroute instrucción por sí misma o con cualquiera de las siguientes opciones:

  • exp: especifique la clase de servicio que se utilizará al enviar sondeos.

  • fanout— Especifica el número máximo de próximos saltos que se buscarán por nodo.

  • frequency— Especifica el intervalo entre los intentos de traceroute.

  • paths— Especifica el número máximo de rutas que se buscarán.

  • retries: especifique el número de intentos de enviar un sondeo a un nodo específico antes de renunciar.

  • source— Especifique la dirección de origen IPv4 que se utilizará al enviar sondeos.

  • ttl— Especifique el valor máximo de tiempo de vida. Los nodos que están más allá de este valor no se rastrean.

  • wait— Especifique el intervalo de espera antes de reenviar un paquete de sondeo.

Recopilación de estadísticas del PLD

Las estadísticas de tráfico de LDP muestran el volumen de tráfico que ha pasado por un FEC en particular en un enrutador.

Cuando configure la instrucción en el traffic-statistics[edit protocols ldp] nivel de jerarquía, las estadísticas de tráfico LDP se recopilan periódicamente y se escriben en un archivo. Puede configurar la frecuencia con la que se recopilan las estadísticas (en segundos) mediante la interval opción. El intervalo de recopilación predeterminado es de 5 minutos. Debe configurar un archivo de estadísticas LDP; de lo contrario, las estadísticas de tráfico de LDP no se recopilan. Si el LSP falla, se restablecen las estadísticas del LDP.

Para recopilar estadísticas de tráfico de LDP, incluya la traffic-statistics instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

Esta sección incluye los siguientes temas:

Salida de estadísticas del PLD

La siguiente salida de ejemplo proviene de un archivo de estadísticas LDP:

El archivo de estadísticas LDP incluye las siguientes columnas de datos:

  • FEC—FEC para la cual se recopilan estadísticas de tráfico de LDP.

  • Type— Tipo de tráfico que se origina en un enrutador, ya sea Ingress (originado en este enrutador) o Transit (reenviado a través de este enrutador).

  • Packets— Número de paquetes pasados por la FEC desde que surgió su LSP.

  • Bytes—Número de bytes de datos pasados por la FEC desde que surgió su LSP.

  • Shared— Un Yes valor indica que varios prefijos están enlazados a la misma etiqueta (por ejemplo, cuando se anuncian varios prefijos con una política de salida). Las estadísticas de tráfico de LDP para este caso se aplican a todos los prefijos y deben tratarse como tales.

  • read— Este número (que aparece junto a la fecha y hora) puede diferir del número real de las estadísticas mostradas. Algunas de las estadísticas se resumen antes de mostrarse.

Deshabilitar estadísticas de LDP en el enrutador Penultimate-Hop

La recopilación de estadísticas de tráfico de LDP en el enrutador de penúltimo salto puede consumir recursos de sistema excesivos, en particular en las rutas del próximo salto. Este problema se agrava si ha configurado la deaggregate instrucción además de la traffic-statistics instrucción. Para los enrutadores que alcancen su límite de uso de ruta del próximo salto, recomendamos configurar la no-penultimate-hop opción para la traffic-statistics instrucción:

Para obtener una lista de niveles de jerarquía en los que puede configurar la traffic-statistics instrucción, consulte la sección resumen de instrucción de esta instrucción.

Nota:

Cuando configure la no-penultimate-hop opción, no hay estadísticas disponibles para los FET que son el penúltimo salto para este enrutador.

Siempre que incluya o quite esta opción de la configuración, las sesiones LDP se descomprimen y, luego, se reinician.

La siguiente salida de ejemplo proviene de un archivo de estadísticas LDP que muestra los enrutadores en los que está configurada la no-penultimate-hop opción:

Limitaciones de las estadísticas del LDP

Los siguientes son problemas relacionados con la recopilación de estadísticas de LDP mediante la configuración de la traffic-statistics instrucción:

  • No se pueden borrar las estadísticas del PLD.

  • Si acorta el intervalo especificado, solo se emite una nueva solicitud de estadísticas de LDP si el temporizador de estadísticas caduca más tarde que el nuevo intervalo.

  • Una nueva operación de recopilación de estadísticas de LDP no puede comenzar hasta que la anterior haya terminado. Si el intervalo es corto o si el número de estadísticas LDP es grande, el intervalo de tiempo entre las dos colecciones de estadísticas puede ser más largo que el intervalo.

Cuando un LSP cae, las estadísticas del LDP se restablecen.

Rastreo de tráfico de protocolo LDP

En las siguientes secciones se describe cómo configurar las opciones de seguimiento para examinar el tráfico de protocolo LDP:

Rastreo de tráfico de protocolo LDP en los niveles de protocolo y instancia de enrutamiento

Para rastrear el tráfico de protocolo LDP, puede especificar opciones en la instrucción global traceoptions en el [edit routing-options] nivel de jerarquía, y puede especificar opciones específicas de LDP incluyendo la traceoptions instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección resumen de instrucción de esta instrucción.

Utilice la file instrucción para especificar el nombre del archivo que recibe el resultado de la operación de seguimiento. Todos los archivos se colocan en el directorio /var/log. Recomendamos que coloque la salida de LDP-tracing en el archivo ldp-log.

Los siguientes indicadores de seguimiento muestran las operaciones asociadas con el envío y recepción de varios mensajes LDP. Cada uno puede llevar uno o más de los siguientes modificadores:

  • address— Rastrea el funcionamiento de los mensajes de retirada de direcciones y direcciones.

  • binding— Seguimiento de las operaciones de enlace de etiquetas.

  • error— Condiciones de seguimiento de errores.

  • event— Seguimiento de eventos de protocolo.

  • initialization— Rastrea el funcionamiento de los mensajes de inicialización.

  • label— Rastrea el funcionamiento de los mensajes de solicitud de etiquetas, asignación de etiquetas, retirada de etiquetas y liberación de etiquetas.

  • notification— Seguimiento del funcionamiento de los mensajes de notificación.

  • packets— Rastree el funcionamiento de la dirección, la retirada de direcciones, la inicialización, la solicitud de etiquetas, la asignación de etiquetas, la retirada de etiquetas, la liberación de etiquetas, la notificación y los mensajes periódicos. Este modificador es equivalente a establecer los addressmodificadores , initialization, labelnotification, yperiodic.

    También puede configurar el filter modificador de marca con la match-on address subopción para el packets indicador. Esto le permite realizar un seguimiento según las direcciones de origen y destino de los paquetes.

  • path— Rastrea las operaciones de ruta conmutada por etiquetas.

  • path— Rastrea las operaciones de ruta conmutada por etiquetas.

  • periodic— Rastrea el funcionamiento de los mensajes de saludo y de atención.

  • route— Rastrea el funcionamiento de los mensajes de ruta.

  • state— Rastreo de transiciones de estado de protocolo.

Rastreo del tráfico del protocolo LDP dentro de las FET

El LDP asocia una clase de equivalencia de reenvío (FEC) con cada LSP que crea. El FEC asociado con un LSP especifica qué paquetes se asignan a ese LSP. Los LSP se extienden a través de una red a medida que cada enrutador elige la etiqueta anunciada en el siguiente salto para la FEC y lo empala a la etiqueta que anuncia en todos los demás enrutadores.

Puede rastrear el tráfico de protocolo LDP dentro de una FEC específica y filtrar instrucciones de seguimiento de LDP basadas en una FEC. Esto es útil cuando desea rastrear o solucionar problemas del tráfico de protocolo LDP asociado con una FEC. Los siguientes indicadores de seguimiento están disponibles para este propósito: routey path.binding

En el siguiente ejemplo, se muestra cómo puede configurar la instrucción LDP traceoptions para filtrar instrucciones de seguimiento de LDP basadas en una FEC:

Esta función tiene las siguientes limitaciones:

  • La capacidad de filtrado solo está disponible para FET compuestas por prefijos ip versión 4 (IPv4).

  • Los FET de circuito de capa 2 no se pueden filtrar.

  • Cuando configure tanto el rastreo como el filtrado de rutas, no se muestran las rutas MPLS (el filtro las bloquea).

  • El filtrado está determinado por la política y el valor configurado para la match-on opción. Al configurar la política, asegúrese de que el comportamiento predeterminado sea siempre reject.

  • La única match-on opción es fec. En consecuencia, el único tipo de política que debe incluir es una política de filtro de ruta.

Ejemplos: Rastreo de tráfico de protocolo LDP

Rastree los mensajes de ruta de LDP en detalle:

Rastrear todos los mensajes salientes de LDP:

Rastree todas las condiciones de error de LDP:

Rastree todos los mensajes entrantes de LDP y todas las operaciones de enlace de etiquetas:

Rastree el tráfico de protocolo LDP para una FEC asociada con el LSP:

Tabla de historial de versiones
Liberación
Descripción
22.4R1
A partir de Junos OS Evolved versión 22.4R1, puede configurar la autenticación TCP-AO o TCP MD5 con una subred IP para incluir todo el rango de direcciones en esa subred.
22.4R1
A partir de Junos OS Evolved versión 22.4R1, la autenticación TCP es consciente de VRF.
19.1
A partir de la versión 19.1R1 de Junos OS, el enrutador de borde LDP de enrutamiento por segmentos puede unir el tráfico de enrutamiento de segmentos al siguiente salto de LDP y viceversa.
16.1
A partir de la versión 16.1 de Junos OS, M-LDP puede señalar LSP de punto a multipunto en ASBR o transitar o salir cuando la dirección raíz es una ruta BGP que se resuelve recursivamente a través de un LSP MPLS.
14.1
A partir de la versión 14.1 de Junos OS, para migrar los servicios de IPTV existentes de la multidifusión ip nativa a la multidifusión MPLS, debe hacer una transición fluida de PIM a LSP de punto a multipunto M-LDP con una interrupción mínima.