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 en la familia MPLS. En el caso de LDP dirigido, la interfaz de circuito cerrado debe habilitarse con MPLS de familia.

  2. (Opcional) Configure las interfaces relevantes en el nivel jerárquico [edit protocol mpls] .

  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 mínima de LDP. Todas las demás instrucciones de configuración de LDP son opcionales.

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

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

Habilitar y deshabilitar LDP

LDP reconoce las instancias de enrutamiento. Para habilitar LDP en una interfaz específica, incluya las siguientes instrucciones:

Para obtener una lista de los 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 .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 los niveles jerárquicos en los que puede incluir esta instrucción, consulte la sección Resumen de instrucciones.

Configuración del temporizador LDP para 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 hola se envían periódicamente en todas las interfaces donde LDP está habilitado.

Hay dos tipos de mensajes de saludo LDP:

  • Mensajes de enlace de saludo: se envían a través de la interfaz 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 detección de LDP en una dirección específica. Los mensajes de saludo dirigidos se utilizan para admitir sesiones LDP entre enrutadores que no están conectados directamente. Un enrutador de destino determina si responder o ignorar un mensaje de saludo dirigido. Un enrutador de destino que elige responder lo hace enviando periódicamente mensajes de saludo dirigidos al enrutador iniciador.

De forma predeterminada, LDP envía mensajes de saludo cada 5 segundos para los mensajes de saludo de vínculo y cada 15 segundos para los mensajes de saludo dirigidos. Puede configurar el temporizador LDP para modificar 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 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 enlace de hola

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

Para obtener una lista de los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

Configuración del temporizador LDP para mensajes de saludo dirigidos

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

Para obtener una lista de los niveles jerárquicos en los que puede incluir estas instrucciones, consulte las secciones de resumen de instrucciones de estas instrucciones.

Configuración del 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 deben esperar. Los valores enviados por cada vecino no tienen que coincidir.

El tiempo de espera normalmente debe ser al menos tres veces el intervalo de saludo. El valor predeterminado es de 15 segundos para los mensajes de enlace de saludo y de 45 segundos para los mensajes de saludo dirigidos. Sin embargo, es posible configurar un tiempo de espera de LDP que esté cerca del valor del intervalo de saludo.

Nota:

Al configurar un tiempo de espera de LDP cerca del intervalo de saludo (menos de tres veces el intervalo de saludo), es posible que los errores de vecino de LDP se detecten más rápidamente. Sin embargo, esto también aumenta la posibilidad de que el enrutador pueda declarar un vecino LDP caído que todavía funciona normalmente. Para obtener más información, consulte Configuración del temporizador LDP para mensajes de saludo.

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

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

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

Cuando se vuelve a configurar el intervalo de tiempo de espera, los cambios no surten efecto hasta después de restablecer la sesión. El tiempo de espera se negocia cuando se inicia la sesión de emparejamiento 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 LDP, ejecute el clear ldp session comando.

Configuración del tiempo de espera de LDP para mensajes de enlace Hello

Para modificar cuánto tiempo debe esperar un nodo LDP para recibir un mensaje de saludo de vínculo antes de declarar al vecino inactivo, especifique una nueva hora en segundos mediante la hold-time instrucción:

Para obtener una lista de los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

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

Para modificar cuánto tiempo debe esperar un nodo LDP para recibir un mensaje de saludo dirigido antes de declarar al vecino caído, especifique una nueva hora en segundos usando la hold-time instrucción como una opción para la targeted-hello instrucción:

Para obtener una lista de los niveles jerárquicos 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

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

  • Puntos de conexión de túneles RSVP para los que está configurada la tunelización 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 la marca de error seguimiento) que indica el origen. Por ejemplo, si el interlocutor de LDP recibió un saludo de destino de la dirección de Internet 10.0.0.1 y no hay ningún vecino con esta dirección configurado específicamente, se imprime el siguiente mensaje en el archivo de registro de LDP:

Para habilitar mensajes de saludo dirigidos estrictamente, incluya la strict-targeted-hellos instrucción:

Para obtener una lista de los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

Configuración del intervalo para mensajes keepalive de LDP

El intervalo keepalive 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 keepalive. 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 keepalive. El valor predeterminado es de 10 segundos. El valor mínimo es 1 segundo.

El valor configurado para el intervalo keepalive se puede modificar durante la negociación de la sesión 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 keepalive, incluya la keepalive-interval instrucción:

Para obtener una lista de los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

Configuración del tiempo de espera de mantenimiento de LDP

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

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

Para obtener una lista de los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

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

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

Para permitir que LDP aprenda las rutas agregadas o resumidas en las áreas de OSPF o los niveles de ISIS entre dominios, Junos OS le permite configurar la coincidencia más larga para LDP en función de 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 en función de RFC5283. Esto permite a LDP aprender las rutas agregadas o resumidas a través de las áreas OSPF o niveles de ISIS en interdominio. 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 de la serie MX con protocolo OSPF y LDP habilitado en las interfaces conectadas.

  • Junos OS versión 16.1 o posterior ejecutándose en todos los dispositivos.

Antes de empezar:

  • Configure las interfaces del dispositivo.

  • Configure OSPF.

Descripción general

LDP se utiliza a menudo para establecer rutas de conmutación de etiquetas (LSP) MPLS en un dominio de red completo mediante un IGP como OSPF o IS-IS. En dicha red, todos los enlaces en el dominio tienen adyacencias IGP, así como adyacencias LDP. LDP establece los LSP en la ruta más corta a un destino según lo determinado por el reenvío de IP. En Junos OS, la implementación de LDP realiza una búsqueda de coincidencia exacta en la dirección IP del FEC en las rutas RIB o IGP para la asignación de etiquetas. Esta asignación exacta requiere que las direcciones IP del punto de conexión LDP de extremo a extremo de MPLS estén configuradas en todos los LER. Esto frustra el propósito del diseño jerárquico IP o el 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 que 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 [edit] y, luego, ingrese commit desde el modo de configuración.

R0

R1

R2

R3

R4

R5

Configuración del dispositivo R0

Procedimiento paso a paso

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

Para configurar el dispositivo R0:

  1. Configure las interfaces.

  2. Asigne las direcciones de circuito cerrado al dispositivo.

  3. Configure el ID del 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, escriba los comandos , y show routing-options para confirmar la show interfacesconfiguración. show protocols 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 funcione correctamente.

Verificación de las rutas

Propósito

Compruebe 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 de la tabla de enrutamiento del dispositivo R0.

Verificación de 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 de LDP del dispositivo R0

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

Propósito

Muestra las entradas de ruta en la tabla de topología interna del 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.

Verifique solo la información FEC de la ruta LDP

Propósito

Mostrar sólo la información 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

La salida muestra solo las rutas FEC del protocolo LDP disponibles para el dispositivo R0.

Verificar FEC y rutas ocultas de LDP

Propósito

Muestre el FEC y las rutas ocultas 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 shadow en la tabla de enrutamiento.

Significado

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

Configuración de las preferencias de ruta de LDP

Cuando varios protocolos calculan rutas al mismo destino, las preferencias de ruta se utilizan 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 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 los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

Reinicio correcto de LDP

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

Durante la inicialización de la sesión, un enrutador anuncia su capacidad para realizar un reinicio correcto de LDP o para aprovechar que un vecino realiza un reinicio correcto de LDP enviando el TLV de reinicio correcto. Este TLV contiene dos campos relevantes para el reinicio elegante de LDP: 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 correcto 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 correctamente. 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 período de tiempo que un enrutador vecino mantiene su información sobre el enrutador que se reinicia, lo que le permite continuar reenviando el tráfico.

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

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

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

  • Cuando un enrutador se está reiniciando, no se envían mensajes de mapa de etiqueta a los vecinos que admitan un reinicio correcto hasta que el enrutador de reinicio se haya estabilizado (los mensajes de mapa de etiqueta se envían inmediatamente a los vecinos que no admiten el reinicio correcto). Sin embargo, todos los demás mensajes (keepalive, dirección-mensaje, notificación y liberación) se envían como de costumbre. La distribución de estos otros mensajes evita que el enrutador distribuya información incompleta.

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

Configuración de LDP Correcto reinicio

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

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

Para configurar un reinicio correcto de LDP, consulte las siguientes secciones:

Habilitación del reinicio correcto

Para habilitar el reinicio correcto de LDP, también debe habilitar el reinicio correcto en el enrutador. Para habilitar el reinicio correcto, 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 de la serie ACX no admiten el nivel de jerarquía [edit logical-systems logical-system-name routing-options].

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

De forma predeterminada, el reinicio correcto de LDP se habilita cuando se habilita el reinicio correcto tanto en el nivel de protocolo LDP como en todas las instancias de enrutamiento. Sin embargo, puede deshabilitar tanto el reinicio correcto de LDP como el modo auxiliar de reinicio correcto de LDP.

Deshabilitar el reinicio correcto de LDP o el modo auxiliar

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

Para obtener una lista de los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

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

Para obtener una lista de los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

Son posibles las siguientes configuraciones de reinicio correcto de LDP:

  • El reinicio elegante de LDP y el modo auxiliar están habilitados.

  • El reinicio correcto de LDP está deshabilitado, pero el modo auxiliar está habilitado. Un enrutador configurado de esta manera no puede reiniciarse correctamente, pero puede ayudar a un vecino que se reinicia.

  • El reinicio correcto de LDP y el modo auxiliar están deshabilitados. El enrutador no utiliza el reinicio correcto LDP ni el tipo, longitud y valor de reinicio correcto (TLV) enviados en el mensaje de inicialización. El enrutador se comporta como un enrutador que no admite el reinicio correcto de LDP.

Se emite un error de configuración si intenta habilitar el reinicio correcto y deshabilitar el modo auxiliar.

Configuración del 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 se reinicia correctamente reanude el envío de mensajes LDP. Después del período de espera, se puede restablecer la sesión de LDP. Puede configurar el período de espera en segundos. Este valor se incluye en el TLV de sesión tolerante a errores que se envía en los mensajes de inicialización de LDP cuando está habilitado el reinicio correcto de LDP.

Supongamos que el enrutador A y el enrutador B son vecinos de LDP. El enrutador A es el enrutador que se reinicia. El tiempo de reconexión es el tiempo que el enrutador A le indica al enrutador B que espere después de que el enrutador B detecte que el enrutador A se reinició.

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 los niveles de jerarquía en los que puede configurar estas instrucciones, consulte las secciones de resumen de instrucciones para estas instrucciones.

Configuración del tiempo de recuperación y del 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 correctamente. 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 que se reinicia, lo que le permite continuar reenviando el 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 que se reinicia, puede configurar el tiempo máximo de recuperación en el enrutador vecino. Un enrutador vecino mantiene su estado durante el más corto de los dos tiempos. Por ejemplo, el enrutador A está realizando un reinicio correcto de LDP. Ha enviado un tiempo de recuperación de 900 segundos al enrutador B vecino. Sin embargo, el enrutador B tiene su tiempo máximo de recuperación configurado en 400 segundos. El enrutador B solo esperará 400 segundos antes de purgar su información 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 los niveles de jerarquía en los que puede configurar estas instrucciones, consulte las secciones de resumen de instrucciones para estas instrucciones.

Filtrado de enlaces de etiquetas LDP entrantes

Puede filtrar los enlaces de etiquetas LDP recibidos y 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 los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

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

Tabla 1: de Operadores que aplican al filtrado de etiquetas recibidas de LDP

from Operador

Description

interface

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

neighbor

Coincidencias en enlaces recibidos del ID de enrutador LDP especificado

next-hop

Coincidencias en 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, sigue apareciendo en la base de datos LDP, pero no se considera para su instalación como parte de una ruta de conmutación de etiquetas (LSP).

En general, la aplicación de políticas en LDP solo se puede usar para bloquear el establecimiento de LSP, no para controlar su enrutamiento. Esto se debe a que la ruta que sigue un LSP viene 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 LDP para excluir algunos de los posibles saltos siguientes de la consideración. (De lo contrario, LDP elige uno de los posibles saltos siguientes al azar).

Las sesiones LDP no están enlazadas a interfaces ni direcciones de interfaz. LDP anuncia solo etiquetas por enrutador (no por interfaz); por lo tanto, si existen varios vínculos paralelos 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 esperado. (Generalmente, usar next-hop y interface no es apropiado en este caso).

Si una etiqueta se ha filtrado (lo que significa que ha sido rechazada por la política 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 directivas para LDP, consulte la Guía del usuario de directivas de enrutamiento, filtros de firewall y políticas de tráfico.

Ejemplos: Filtrado de enlaces de etiquetas LDP entrantes

Solo acepta prefijos /32 de todos los vecinos:

Acepte 131.108/16 o más tiempo desde el ID 10.10.255.2 del enrutador y acepte todos los prefijos de todos los demás vecinos:

Filtrado de encuadernaciones de etiquetas LDP salientes

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

Para obtener una lista de los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

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

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

al operador

Description

interface

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

neighbor

Coincidencias en enlaces enviados al ID de enrutador LDP especificado

next-hop

Coincidencias en enlaces enviados a un vecino que anuncia 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 directivas en LDP para bloquear el establecimiento de LSP, pero no para controlar su enrutamiento. La ruta que sigue un LSP viene determinada por el enrutamiento de unidifusión, no por LDP.

Las sesiones LDP no están enlazadas 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á enlazada a una sola interfaz.

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

Las etiquetas filtradas están marcadas en la base de datos:

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

Ejemplos: Filtrado de encuadernaciones de etiquetas LDP salientes

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

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

Especificación de la dirección de transporte utilizada por LDP

Los enrutadores primero deben establecer una sesión TCP entre ellos antes de poder establecer una sesión LDP. La sesión TCP permite a los enrutadores intercambiar los anuncios de etiqueta 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 que se utiliza para identificar la sesión TCP sobre la que se ejecutará la sesión LDP.

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

Para obtener una lista de los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

Si especifica la router-id opción, la dirección del identificador de enrutador se utiliza como dirección de transporte (a menos que se configure lo contrario, el identificador de enrutador suele ser el mismo que la dirección de circuito cerrado). Si especifica la interface opción, la dirección de interfaz se utiliza como dirección de transporte para cualquier sesión de LDP a vecinos a la que se pueda acceder 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 un funcionamiento correcto, la dirección de transporte de LDP debe ser accesible. 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 establezca para que coincida con la dirección de circuito cerrado y que el IGP anuncie la dirección de circuito cerrado.

No puede especificar la interface opción cuando hay varios vínculos paralelos al mismo vecino de LDP, porque la especificación 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 borre 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 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 utilizada 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 LDP, puede configurar explícitamente cualquier dirección IP como dirección de transporte para vecinos LDP de destino para circuitos de capa 2, adyacencias MPLS y VPLS. Esto le permite controlar las sesiones de LDP de destino mediante la configuración de direcciones de transporte.

Ventajas de controlar la dirección de transporte usada para la sesión LDP dirigida

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

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

  • Ease of operation—Dirección de transporte configurada a nivel de interfaz, permite utilizar más de un protocolo en la red troncal de IGP para LDP. Esto permite operaciones fluidas y fáciles.

Descripción general de la dirección de transporte de LDP de destino

Antes de Junos OS versión 19.1R1, LDP solo ofrecía compatibilidad con el ID de enrutador o la dirección de interfaz como dirección de transporte en cualquier interfaz LDP. Las adyacencias formadas en esa interfaz utilizaron una de las direcciones IP asignadas a la interfaz o al 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 LDP de destino, puede configurar cualquier otra dirección IP como dirección de transporte en las sessionsession-groupinstrucciones , y interface configuration. La configuración de la dirección de transporte solo se aplica a los vecinos configurados, incluidos los circuitos de capa 2, las adyacencias MPLS y 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 LDP de destino en el nivel de sesión, grupo de sesión e interfaz.

Una vez configurada la dirección de transporte, se establece la sesión de LDP de destino en función de 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 a través del circuito de capa 2, la configuración MPLS, VPLS y LDP) es el siguiente:

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

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

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

  4. Bajo [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. Bajo [edit protocols ldp interfcae] jerarquía.

  2. Bajo [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 de saludo es el siguiente:

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

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

  3. Dirección predeterminada.

Solución de problemas de configuración de direcciones de transporte

Puede utilizar los siguientes resultados del comando show para solucionar problemas de sesiones de LDP dirigidas:

  • 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 de LDP no aparece.

  • show configuration protocols ldp

También puede habilitar las traceoptions de LDP para solucionar problemas adicionales.

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

  • Si la configuración se cambia de utilizar 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 configuración defectuosa, realice las siguientes tareas de solución de problemas:

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

  • La dirección que se configura como dirección de transporte en una instrucción o neighborsession debe ser local en 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, se rechaza la configuración.

Configuración de 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 para 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 los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

Nota:

Si configura una directiva 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 directiva de salida de LDP.

La directiva con nombre (configurada en el nivel de [edit policy-options] jerarquía o [edit logical-systems logical-system-name policy-options] ) se aplica a todas las rutas de la tabla de enrutamiento. Las rutas que coinciden con la política se anuncian en LDP. Puede controlar el conjunto de vecinos a los que se anuncian esos prefijos mediante la export instrucción. Solo from se consideran los 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 de la 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 en LDP:

Configuración de la desagregació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 equivalencia 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 un equilibrio de carga entre rutas de igual costo. Sin embargo, puede equilibrar la carga en rutas de acceso de igual costo si configura una directiva de equilibrio de carga y desagrega los FEC.

La desagregación de los FEC hace que cada prefijo se vincule a una etiqueta separada y se convierta en un LSP independiente.

Para configurar FEC desagregadas, incluya la deaggregate instrucción:

Para obtener una lista de los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

Para todas las sesiones de LDP, solo puede configurar FEC desagregados globalmente.

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

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

Para obtener una lista de los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

Para todas las sesiones de LDP, solo puede configurar FEC agregados globalmente.

Configuración de políticas para FEC de LDP

Puede configurar Junos OS para rastrear y vigilar el tráfico de los FEC de LDP. Los policías de LDP FEC se pueden usar para realizar cualquiera de las siguientes acciones:

  • Rastrear o vigilar el tráfico de entrada para un LDP FEC.

  • Rastrear o vigilar el tráfico de tránsito para un FEC LDP.

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

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

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

Para controlar el tráfico de un FEC de LDP, primero debe configurar un filtro. En concreto, debe configurar la interface instrucción o la interface-set instrucción en el nivel jerárquico [edit firewall family protocol-family filter filter-name term term-name from] . 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 acerca de cómo configurar la instrucción, la instrucción y los interface aplicadores de políticas para FEC de LDP, consulte la Guía del usuario de directivas de enrutamiento, filtros de firewall y políticas de tráfico.interface-set

Una vez que haya configurado los filtros, debe incluirlos en la configuración de instrucciones policing para LDP. Para configurar políticas para FEC de LDP, incluya la policing instrucción:

Para obtener una lista de los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

La policing instrucción incluye las siguientes opciones:

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

  • ingress-filter: especifique el nombre del filtro de tráfico de entrada.

  • transit-traffic: especifique 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 LDP de destino, Junos OS siempre intercambia las clases de equivalencia de reenvío IPv4 (FEC) y las FEC del circuito de capa 2 por la sesión LDP de destino. Para una sesión LDP a un vecino conectado indirectamente, es posible que solo desee exportar FEC de circuito de capa 2 al vecino si la sesión se configuró específicamente para admitir circuitos de capa 2 o VPLS.

En una red de proveedores mixta donde todos los prefijos que no son BGP se anuncian en LDP, la base de datos LDP puede llegar a ser grande. Para este tipo de entorno, puede ser útil evitar la publicidad de FEC IPv4 a través de sesiones LDP formadas debido a la configuración del circuito de capa 2 o LDP VPLS. Del mismo modo, puede ser útil filtrar cualquier FEC IPv4 recibido 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 FEC de circuito de capa 2 configurando la l2-smart-policy instrucción. Esta función también filtra automáticamente los FEC IPv4 recibidos en esta sesión. La configuración de una directiva explícita de exportación o importación que se activa para l2-smart-policy deshabilita esta función en la dirección correspondiente.

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

Para evitar que LDP exporte FEC IPv4 a través de sesiones LDP solo con vecinos de capa 2 y para filtrar los FEC IPv4 recibidos en dichas sesiones, incluya la l2-smart-policy instrucción:

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

Configuración de BFD para LSP de LDP

Puede configurar la detección de reenvío bidireccional (BFD) para los LSP de LDP. El protocolo BFD es un mecanismo de saludo simple que detecta fallas en una red. Los paquetes Hello se envían en un intervalo regular especificado. Una falla de vecino se detecta cuando el enrutador deja de recibir una respuesta después de un intervalo especificado. BFD trabaja con una amplia variedad de entornos y topologías de red. Los temporizadores de detección de fallas para BFD tienen límites de tiempo más cortos que los 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 falla una sesión BFD para una ruta. A continuación se muestra cómo pueden aparecer los mensajes de registro de BFD para LDP LSP:

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

Los temporizadores de detección de fallos BFD son adaptativos y se pueden ajustar para ser más o menos agresivos. Por ejemplo, los temporizadores pueden adaptarse a un valor más alto si falla la adyacencia, o un vecino puede negociar un valor más alto para un temporizador que el valor configurado. Los temporizadores se adaptan a un valor más alto cuando un colgajo de sesión BFD ocurre más de tres veces en un lapso de 15 segundos. Un algoritmo de retroceso aumenta el intervalo de recepción (Rx) en dos si la instancia local de BFD es el motivo de la solapa de sesión. El intervalo de transmisión (Tx) aumenta en dos si la instancia remota de BFD es el motivo de la solapa de sesión. Puede utilizar el comando para devolver los clear bfd adaptation temporizadores de intervalo BFD a sus valores configurados. El clear bfd adaptation comando no tiene hits, lo que significa que el comando no afecta al flujo de tráfico en el dispositivo de enrutamiento.

Para habilitar BFD para LSP de 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 nivel de [edit protocols ldp] jerarquía. Como alternativa, puede configurar una directiva de entrada de administración y gestión de operaciones (OAM) para habilitar BFD en un rango de direcciones FEC. Para obtener más información, consulte Configuración de directivas de entrada OAM para LDP.

No puede habilitar LSP de LDP de BFD a menos que sus direcciones FEC equivalentes estén configuradas explícitamente u OAM esté habilitado en los 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 de la serie ACX no admiten el nivel de jerarquía [edit logical-systems].

La oam instrucción incluye las siguientes opciones:

  • fec: especifique la dirección FEC. Debe especificar una dirección FEC o configurar una directiva de entrada de OAM para asegurarse de que se produce la sesión BFD.

  • lsp-ping-interval: especifique la duración del intervalo de ping LSP en segundos. Para emitir un ping en un LSP con señal LDP, use 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: hace que LDP establezca sesiones BFD para todas las rutas ECMP configuradas para el FEC especificado. Si configura la ecmp opción, también debe configurar la periodic-traceroute instrucción para el FEC especificado. Si no lo hace, se producirá 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 sólo configura la ecmp opción para un FEC ([edit protocols ldp oam fec address bfd-liveness-detection]).

  • intervalo de espera: especifique el tiempo que la sesión BFD debe permanecer activa antes de agregar la ruta o el próximo salto. Si se especifica un tiempo de 0 segundos, se agrega la ruta o el siguiente salto tan pronto como se recupere la sesión de BFD.

  • minimum-interval: especifique 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 o la minimum-transmit-interval opción.

  • minimum-receive-interval: especifique el intervalo mínimo de recepción. El rango es de 1 a 255,000 milisegundos.

  • minimum-transmit-interval: especifique el intervalo mínimo de transmisión. El rango es de 1 a 255,000 milisegundos.

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

  • versión: 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 compatible con ECMP para LSP de LDP

Cuando se configura BFD para un FEC, se establece una sesión de BFD para un solo salto siguiente local activo para el enrutador. Sin embargo, puede configurar varias sesiones de BFD, una para cada FEC asociada a una ruta de acceso múltiple (ECMP) específica de igual costo. Para que esto funcione correctamente, también debe configurar LDP LSP periodic traceroute. (Consulte Configuración de LDP LSP Traceroute.) LDP LSP traceroute se utiliza para descubrir rutas ECMP. Se inicia una sesión BFD para cada ruta ECMP descubierta. Cada vez que falla 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. Lo siguiente puede ocurrir cuando se descubre un problema:

  • Si la última ruta de seguimiento de LSP de LDP para un FEC difiere de la ruta de seguimiento anterior, las sesiones de BFD asociadas con ese FEC (las sesiones de BFD para rangos de direcciones que han cambiado con respecto a la ejecución anterior) se desactivan y se inician nuevas sesiones de BFD para las direcciones de destino en los rangos alterados.

  • Si la traceroute LSP de LDP devuelve un error (por ejemplo, un tiempo de espera), se desactivan todas las sesiones de BFD asociadas con ese FEC.

Para configurar LDP de modo que establezca sesiones BFD para todas las rutas ECMP configuradas para el FEC especificado, incluya la ecmp instrucción.

Para obtener una lista de los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

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

Nota:

Los enrutadores de la 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 LDP

Puede configurar las propiedades de ruta y próximo salto en caso de un evento de error de sesión BFD en un LSP de LDP. El evento de error podría ser una sesión de BFD existente que se ha caído o podría ser una sesión de BFD que nunca se produjo. LDP vuelve a agregar la ruta o el siguiente salto cuando vuelve a aparecer la sesión BFD relevante.

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 de 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 fallo de sesión BFD.

  • remove-route: quita la ruta correspondiente al LSP de las tablas de enrutamiento apropiadas cuando se detecta un evento de fallo de sesión BFD. Si el LSP está configurado con ECMP y una sesión BFD correspondiente a cualquier ruta deja de funcionar, la ruta se elimina.

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

Para obtener una lista de los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

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

Puede especificar la duración que debe durar la sesión BFD antes de agregar una ruta o un próximo salto configurando la holddown-interval instrucción en el nivel de [edit protocols ldp oam bfd-livenesss-detection] jerarquía o en el nivel de [edit protocols ldp oam fec address bfd-livenesss-detection] jerarquía. Si se especifica un tiempo de 0 segundos, se agrega la ruta o el siguiente salto tan pronto como se recupere la sesión de BFD.

Para obtener una lista de los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

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

El reenrutamiento rápido solo de 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 errores de vínculo, mejorando los protocolos de enrutamiento de multidifusión como la multidifusión independiente del protocolo (PIM) y el protocolo de distribución de etiquetas multipunto (LDP multipunto) en dispositivos que admiten estas funciones.

Nota:

En los conmutadores, no se admite MoFRR con rutas de conmutación de etiquetas MPLS y LDP multipunto.

Para los enrutadores de la serie MX, MoFRR solo se admite en enrutadores de la 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 primarias y de respaldo hacia un origen 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 asignados a las rutas principal y de respaldo). Cuando un dispositivo detecta un error en la ruta principal, inmediatamente comienza a aceptar paquetes desde 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 enlace de ruta primaria.

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

Descripción general de MoFRR

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

En el enrutamiento de multidifusión, el lado receptor suele originar los gráficos de distribución del tráfico. Esto es diferente al enrutamiento de unidifusión, que generalmente establece la ruta desde el origen hasta el receptor. PIM (para IP), LDP multipunto (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 sean compatibles.

En un árbol de multidifusión, si el dispositivo detecta un fallo en un componente de red, se tarda algún tiempo en realizar una reparación reactiva, lo que provoca una pérdida de tráfico significativa al configurar una ruta alternativa. MoFRR reduce la pérdida de tráfico en un árbol de distribución de multidifusión cuando falla un componente de red. Con MoFRR, uno de los dispositivos de enrutamiento descendente establece una ruta alternativa hacia el origen para recibir una transmisión en vivo de respaldo del mismo tráfico de multidifusión. Cuando se produce un error en la secuencia principal, el dispositivo de enrutamiento MoFRR puede cambiar rápidamente a la secuencia de reserva.

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 separadas si hay dos rutas disponibles. Si las rutas disjuntas no están disponibles, el protocolo selecciona dos rutas no separadas. Si no hay disponibles dos rutas no separadas, sólo se selecciona una ruta principal sin copia de seguridad. MoFRR prioriza la copia de seguridad separada en favor del equilibrio de carga de las rutas disponibles.

MoFRR es compatible con las familias de protocolos IPv4 e IPv6.

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

Figura 12: Topología de ejemplo de MoFRRTopología de ejemplo de 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 descarta el tráfico recibido en la ruta de respaldo.

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

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

Multipoint LDP MoFRR se utiliza en el dispositivo de salida de una red MPLS, donde los paquetes se reenvían a una red IP. Con el MoFRR 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 descarta en el LER. Si se produce un error en la ruta principal, el dispositivo acepta la secuencia de copia de seguridad 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 en banda de LDP multipunto para LSP de punto a multipunto).

Funcionalidad PIM

Junos OS admite MoFRR para las uniones de árbol de ruta más corta (SPT) 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 uniones (*,G), incluya la instrucción de mofrr-asm-starg configuración en la [edit routing-options multicast stream-protection] jerarquía. Para cada grupo G, MoFRR operará 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 de reenvío de ruta inversa (RPF) ascendentes 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 las rutas de multidifusión adecuadas con los siguientes saltos del RPF ascendente 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, la distribución de los mensajes de unión entre los enlaces podría no ser 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 de la ruta de copia de seguridad sigan la misma ruta y que no se redistribuyan de manera uniforme.

MoFRR se habilita mediante la instrucción configuration stream-protection en la [edit routing-options multicast] jerarquía. 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 de MoFRR y procede de la siguiente manera:

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

  • Si la configuración de MoFRR está presente, el dispositivo comprueba si hay una configuración de directiva.

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

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

    • Si hay rutas principales y de respaldo disponibles, PIM envía el mensaje de unión ascendente 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, el plano 1 de ).Figura 12

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

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

    • Si se aprueba esta comprobación de directivas: el dispositivo comprueba las rutas principales y de respaldo (interfaces ascendentes).

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

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

Funcionalidad LDP multipunto

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

Para LDP multipunto con MoFRR, el dispositivo LDP multipunto selecciona dos pares ascendentes independientes y envía dos etiquetas independientes, una a cada par ascendente. El dispositivo utiliza el mismo algoritmo descrito en RFC 6388 para seleccionar la ruta ascendente principal. El dispositivo utiliza el mismo algoritmo para seleccionar la ruta ascendente de copia de seguridad, pero excluye el LSR ascendente primario 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 ruta principal desde la que aceptar el tráfico MPLS. La otra ruta se convierte en la ruta de respaldo y el dispositivo elimina ese tráfico. Cuando se produce un error en la ruta ascendente principal, el dispositivo comienza a aceptar tráfico desde la ruta de copia de seguridad. El dispositivo LDP multipunto selecciona las dos rutas ascendentes en función del próximo salto del dispositivo raíz del protocolo de puerta de enlace interior (IGP).

Una clase de equivalencia de reenvío (FEC) es un grupo de paquetes IP que se reenvían de la misma manera, por la misma ruta y con el mismo tratamiento de reenvío. Normalmente, la etiqueta que se coloca en un paquete en particular representa el FEC al que está asignado ese paquete. En 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 respaldo.

Si hay vínculos paralelos hacia el mismo dispositivo ascendente inmediato, 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 de brote es un LSR que es un LSR de salida, pero también tiene uno o más LSR descendentes conectados directamente. Para un nodo de brote, el tráfico de la ruta ascendente principal se reenvía a un LSR descendente. Si se produce un error en la ruta ascendente principal, el tráfico MPLS de la ruta ascendente de copia de seguridad se reenvía al LSR descendente. Esto significa que el siguiente salto LSR descendente se agrega a ambas rutas MPLS junto con el siguiente salto de salida.

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

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

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

  • Todas las interfaces que pertenecen al mismo LSR ascendente se consideran la ruta principal.

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

Reenvío de paquetes

Para PIM o LDP 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 de reenvío porque:

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

  • Evita múltiples búsquedas de rutas (que dan lugar a caídas de paquetes).

Para PIM, cada secuencia de multidifusión IP contiene la misma dirección de destino. Independientemente de la interfaz en la que lleguen los paquetes, los paquetes tienen la misma ruta. El dispositivo comprueba la interfaz a la que llega cada paquete y reenvía solo los que provienen de la interfaz principal. Si la interfaz coincide con una interfaz de secuencia de reserva, el dispositivo descarta los paquetes. Si la interfaz no coincide con la interfaz de flujo principal o de respaldo, el dispositivo maneja 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 muestra esto de manera similar para los conmutadores con PIM.

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

Para MoFRR con LDP multipunto en enrutadores, el dispositivo utiliza 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 comprobación de lista de interfaces. El dispositivo solo reenvía la etiqueta principal y elimina todas las demás. Varias interfaces pueden recibir paquetes utilizando la misma etiqueta.

Figura 15 muestra este proceso para enrutadores con LDP multipunto.

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

Limitaciones y advertencias

Limitaciones y advertencias de 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 errores de MoFRR se admite para 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 disjuntas seleccionadas hacia la fuente. Dos de los vecinos ascendentes seleccionados no pueden estar en la misma interfaz, es decir, dos vecinos ascendentes en un segmento LAN. Lo mismo ocurre si la interfaz ascendente resulta ser una interfaz de túnel de multidifusión.

  • No se admite la detección del número máximo de rutas ascendentes disjuntas de extremo a extremo. El dispositivo de enrutamiento del lado receptor (salida) solo se asegura de que haya un dispositivo ascendente separado (el salto inmediatamente anterior). PIM y LDP multipunto no admiten el equivalente de objetos de ruta explícitos (ERO). Por lo tanto, la detección de ruta ascendente disjunta 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 respaldo.

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

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

    • MoFRR está habilitado o deshabilitado en el dispositivo de salida mientras hay un flujo de tráfico activo.

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

  • Para un grupo G de multidifusión, 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 es compatible con MoFRR.

  • El modo denso PIM no es compatible con MoFRR.

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

  • No se admite la supervisión de tasas.

Limitaciones de MoFRR en dispositivos de conmutación con PIM

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

  • MoFRR no se admite cuando la interfaz ascendente es una interfaz de enrutamiento y puente integrados (IRB), lo que afecta a otras características de multidifusión, como el espionaje 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 al reenviar tráfico de multidifusión pueden hacer que los paquetes vuelvan a circular a través de PFE varias veces. Como resultado, los valores mostrados para los show pfe statistics traffic recuentos de paquetes de multidifusión del comando pueden mostrar números más altos de lo esperado en los campos de salida como Input packets y Output packets. Es posible que observe este comportamiento con más frecuencia en escenarios de MoFRR porque las secuencias principales y de reserva duplicadas aumentan el flujo de tráfico en general.

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

MoFRR tiene las siguientes limitaciones y advertencias en los enrutadores cuando se utiliza con LDP multipunto:

  • MoFRR no se aplica al tráfico LDP multipunto recibido en un túnel RSVP porque 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 acceder al origen a través de varios dispositivos de enrutamiento perimetral (PE) del proveedor de entrada (lado de origen), no se admite MoFRR de LDP multipunto.

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

  • No se admite la protección de vínculos LDP multipunto en la ruta de copia de seguridad porque no hay compatibilidad con etiquetas internas de MoFRR.

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

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

Cuando se aplica un reenrutamiento rápido a flujos de unidifusión, un enrutador ascendente preestablece rutas MPLS conmutadas por etiqueta (LSP) o precalcula una ruta de respaldo de reenrutamiento rápido alternativa sin bucles (LFA) para manejar el error 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 diferente al enrutamiento de unidifusión, que generalmente establece la ruta desde la fuente hasta el receptor. Los protocolos que son capaces de establecer gráficos de distribución de multidifusión son PIM (para IP), LDP 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, 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 admitan esta función, a menos que se indique lo contrario. También se indican los pasos de configuración que no son aplicables a MoFRR de LDP multipunto.

(Solo para enrutadores de la 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 SRX) Establezca el enrutador en modo IP mejorado.
  2. Habilite MoFRR.
  3. (Opcional) Configure una política de enrutamiento que filtre un conjunto restringido de flujos de multidifusión que se verán afectados por su configuración de MoFRR.

    Puede aplicar filtros basados en direcciones de origen o de grupo.

    Por ejemplo:

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

    Por ejemplo:

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

    Esto no se admite para MoFRR de LDP multipunto.

  6. (Opcional) En un dominio PIM con MoFRR, permita seleccionar solo una RPF disjunta (una RPF en un plano independiente) como ruta de RPF de reserva.

    Esto no se admite para MoFRR de LDP multipunto. En un dominio MoFRR LDP multipunto, la misma etiqueta se comparte entre enlaces paralelos al mismo vecino ascendente. Este no es el caso en un dominio PIM, donde cada enlace forma un vecino. La mofrr-disjoint-upstream-only instrucción no permite seleccionar una ruta RPF de reserva si la ruta va al mismo vecino ascendente que la de la ruta RPF principal. Esto garantiza que 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 MoFRR de LDP multipunto.

  8. (Opcional) En un dominio PIM con MoFRR, permita que la nueva selección de ruta principal se base en la selección de puerta de enlace de unidifusión para la ruta de unidifusión al origen y que cambie cuando haya un cambio en la selección de unidifusión, en lugar de que la ruta de respaldo se promueva como principal. Esto garantiza que el salto 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 promueva a ser la nueva ruta principal cuando la ruta principal deje de funcionar.

    Esto no se admite para MoFRR de LDP multipunto.

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

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

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

Requisitos

No se necesita 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 necesita tener habilitado MoFRR. Los otros enrutadores no necesitan compatibilidad con MoFRR.

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

Este ejemplo requiere Junos OS versión 14.1 o posterior en el enrutador de PE de salida.

Descripción general

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

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 la fuente 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 no se disponga de un host receptor de multidifusión real, 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, este ejemplo 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 multipuntoMoFRR 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, a continuación, copie y pegue los comandos en la CLI en el nivel de [edit] 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 ejemplo siguiente requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI 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 directivas 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 MoFRR.

Resultados

Desde el modo de configuración, escriba los comandos , show interfaces, show policy-optionsshow protocols, y 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.

Cuando termine de configurar el dispositivo, ingrese commit en el modo de configuración.

Verificación

Confirme que la configuración funcione correctamente.

Comprobación de las clases de equivalencia de reenvío punto a multipunto de 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 están utilizando para los dos LSP punto a multipunto del LDP multipunto.

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 primarias y las rutas ascendentes de reserva. También muestra los siguientes saltos del FPR.

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 interfaces RPF ascendentes, con una interfaz principal y una interfaz de reserva.

Acción
Significado

El resultado muestra las sesiones principales y de copia de seguridad, y los siguientes saltos del RPF.

Comprobación de las estadísticas de tráfico punto a multipunto de LDP

Propósito

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

Acción
Significado

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

Ejemplo: Configuración de LDP Downstream on Demand

En este ejemplo se muestra cómo configurar LDP descendente a petición. LDP se configura comúnmente utilizando el modo de publicidad no solicitada descendente, lo que significa que los anuncios de etiqueta 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 único dominio MPLS, se necesita LDP descendente a petición 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 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 utilizando LDP descendente a petición para solicitar solo los enlaces de etiquetas para los FEC correspondientes a las direcciones de bucle invertido de los 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 a petición de LDP descendente para una sesión de LDP incluyendo la instrucción descendente a petición en el nivel jerárquico [edit protocols ldp session] . Si ha configurado la cadena descendente a pedido, el enrutador de Juniper Networks anuncia la solicitud descendente a petición a sus enrutadores pares. Para que se establezca una sesión descendente bajo demanda entre dos enrutadores, ambos deben anunciar el modo descendente bajo demanda durante el establecimiento de la sesión LDP. Si un enrutador anuncia modo descendente no solicitado y el otro anuncia modo descendente a pedido, se utiliza el modo descendente no solicitado.

Configuración

Configuración de LDP Downstream on Demand

Procedimiento paso a paso

Para configurar una directiva de LDP a petición descendente y, a continuación, configurar esa directiva y habilitar LDP descendente a petición en la sesión de LDP:

  1. Configure la directiva a petición descendente (DOD-Request-Loopbacks en este ejemplo).

    Esta política hace que el enrutador reenvíe mensajes de solicitud de etiqueta solo a los FEC que coinciden con la DOD-Request-Loopbacks política.

  2. Especifique la directiva DOD-Request-Loopbacks mediante la dod-request-policy instrucción en el nivel de [edit protocols ldp] jerarquía.

    La directiva especificada con la instrucción se utiliza para identificar los prefijos para enviar mensajes de solicitud de dod-request-policy etiqueta. Esta directiva es similar a una política de salida o una directiva 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 directiva (en este ejemplo). Si la ruta coincide con la política y la sesión LDP se negocia con el modo de anuncio DOD, los mensajes de solicitud de etiqueta se envían a la sesión LDP descendente correspondiente.

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

Distribución de rutas descendentes de LDP a pedido en BGP etiquetado

Procedimiento paso a paso

Para distribuir LDP aguas abajo en rutas a pedido en BGP etiquetado, utilice una política de exportación de BGP.

  1. Configure la directiva de rutas de LDP (redistribute_ldp en este ejemplo).

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

    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 petición), configure las siguientes directivas:

  1. Configure la dod-routes directiva para aceptar rutas de LDP.

  2. Configure la do-not-propagate-du-sessions directiva para que no reenvíe rutas a vecinos 10.1.1.1, 10.2.2.2, y 10.3.3.3.

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

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

Resultados

Desde el modo de configuración, escriba los comandos show policy-options y show protocols ldp para confirmar la 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 funcione 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 :

  • La siguiente salida de comando para el show ldp session comando indica que el Adv. Mode (modo de anuncio de etiqueta) es DOD (lo que significa que la sesión bajo demanda posterior de LDP está operativa):

  • La siguiente salida del comando para el show ldp session detail comando indica que es Downstream unsolicitedLocal Label Advertisement mode , el valor predeterminado (lo que significa que la secuencia descendente a petición no está configurada en la sesión local). Por el contrario, el Remote Label Advertisement mode y ambos Negotiated Label Advertisement mode indican que Downstream on demand está configurado en la sesión remota

Configuración de la compatibilidad con IPv6 nativo de LDP

LDP se admite en una red solo IPv6 y en una red de doble pila IPv6 o IPv4, como se describe en RFC 7552. Configure la familia de direcciones como inet IPv4 o inet6 IPv6 o ambas, y la preferencia de transporte sea o IPv4IPv6. La dual-transport instrucción permite a Junos OS LDP establecer la conexión TCP a través de IPv4 con vecinos IPv4 y a través de IPv6 con vecinos IPv6 como un LSR de una sola pila. Los inet-lsr-id ID y inet6-lsr-id son los dos ID de LSR que deben configurarse para establecer una sesión LDP a través de IPv4 y transporte TCP IPv6. Estos dos ID deben ser distintos de cero y deben configurarse con valores diferentes.

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

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

  1. Habilite la desagregación de clase de equivalencia de reenvío (FEC) para usar etiquetas diferentes para diferentes familias de direcciones.
  2. Configurar familias de direcciones LDP.
  3. Configure la transport-preference instrucción para seleccionar el transporte preferido para la conexión TCP cuando IPv4 e IPv6 estén habilitados. 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 el ID de LSR para IPv4 y inet6-lsr-id como el 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 de la compatibilidad con 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 un LSR de una sola pila. Esto ayuda a evitar la tunelización de IPv6 a través de núcleo MPLS IPv4 con rutas de conmutación de etiquetas (LSP) de MPLS 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 ejecutándose en todos los dispositivos

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

Descripción general

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

Topología

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

Figura 17: Ejemplo de compatibilidad con IPv6 nativo de LDPEjemplo de compatibilidad con 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 [edit] y, luego, ingrese commit desde el modo de configuración.

R1

R2

Configuración de R1

Procedimiento paso a paso

El ejemplo siguiente requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener 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 etiquetas diferentes para diferentes familias de direcciones.

  6. Configurar familias de direcciones LDP.

Resultados

Desde el modo de configuración, escriba los comandos show interfaces y show protocols para confirmar la 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 IPv4 e IPv6 están habilitados. 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, confírmela con el comando show protocols. 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 independientes 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 de como el ID de LSR para IPv4 y inet6-lsr-id como el ID de inet-lsr-id LSR para IPv6.

  • (Opcional) Configure el transporte dual para permitir que LDP establezca la conexión TCP sobre IPv4 con vecinos IPv4 y sobre IPv6 con vecinos IPv6 como un LSR de pila única.

Resultados

Desde el modo de configuración, confírmela con el comando show protocols. 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 funcione correctamente.

Comprobación de 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 la tabla de rutas mpls.0.

Significado

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

Verificación de 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 la tabla de rutas inet.3.

Significado

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

Comprobación de 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 la tabla de rutas inet6.3.

Significado

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

Verificación de la base de datos LDP
Propósito

Mostrar la información de la base de datos LDP.

Acción

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

Significado

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

Verificación de la información del vecino de LDP
Propósito

Mostrar la información del vecino de LDP.

Acción

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

Significado

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

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

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

Acción

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

Significado

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

Verificación

Confirme que la configuración funcione correctamente.

Verificación de la información del vecino de LDP
Propósito

Mostrar la información del vecino de LDP.

Acción

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

Significado

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

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

Mostrar 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 la información de la sesión LDP.

Significado

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

Verificación

Confirme que la configuración funcione correctamente.

Verificación de la información del vecino de LDP
Propósito

Mostrar la información del vecino de LDP.

Acción

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

Significado

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

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

Mostrar 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 del vecino de LDP.

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

Descripción de la señalización en banda 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 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 que se necesita transportar tráfico de multidifusión, por ejemplo, para IPTV.

Durante años, la solución más utilizada para transportar tráfico de multidifusión ha sido usar multidifusión IP nativa en el núcleo del proveedor de servicios con tunelización IP multipunto para aislar el tráfico del cliente. Se implementa un protocolo de enrutamiento de multidifusión, normalmente multidifusión independiente del protocolo (PIM), para configurar las rutas de reenvío. El enrutamiento de multidifusión IP se utiliza para el reenvío, utilizando la señalización PIM en el núcleo. Para que este modelo funcione, la red central debe estar habilitada para multidifusión. Esto permite implementaciones eficaces y estables aun en casos de sistemas interautónomos (AS).

Sin embargo, en una red IP/MPLS existente, la implementación de PIM podría no ser la primera opción. Algunos proveedores de servicios están interesados en reemplazar la tunelización IP por encapsulación de etiquetas MPLS. Las motivaciones para pasar a la conmutación de etiquetas MPLS son aprovechar las características de ingeniería y protección del tráfico 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 los despliegues existentes para permitir el paso del tráfico de multidifusión. Las extensiones de multidifusión existentes para IP/MPLS son extensiones punto a multipunto para RSVP-TE y extensiones punto a multipunto y multipunto a multipunto para LDP. Estos escenarios de despliegue se describen en RFC 6826, Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths. Esta descripción general de las características se limita a las extensiones punto a multipunto para LDP.

Cómo funciona M-LDP

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

La extensión multipunto para LDP utiliza elementos de clase de equivalencia de reenvío (FEC) de punto a multipunto y de multipunto a multipunto (definidos 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 de entrada local que se vincula 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 etiqueta 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 ramas salientes. Como se muestra en Figura 18, un nodo LDP combina los enlaces de etiqueta para el mismo valor opaco si encuentra nodos descendentes que comparten el mismo nodo ascendente. Esto permite la construcción efectiva de LSP punto a multipunto y la conservación de etiquetas.

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

Figura 19 muestra un escenario de implementación reducida. Dos dominios PIM separados están interconectados por un sitio central sin PIM. Los enrutadores de borde de este sitio principal 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 a la red principal. Los enrutadores perimetrales del sitio C ejecutan BGP para la detección de nodos raíz. Las rutas del protocolo de puerta de enlace interior (IGP) no se pueden usar para la detección de entrada porque, 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 un mapeo uno a uno entre el LSP punto a multipunto y el flujo (S,G). Con la señalización en banda, los mensajes PIM se traducen directamente en 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 en banda M-LDP es transportar tráfico de multidifusión IPTV en una red troncal MPLS.

Figura 19: Ejemplo de topología M-LDP en núcleo MPLS sin PIMEjemplo de topología M-LDP en núcleo MPLS sin PIM
Configuración

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

Por ejemplo:

M-LDP en núcleo MPLS habilitado para PIM

A partir de Junos OS versión 14.1, para migrar los servicios de IPTV existentes de multidifusión IP nativa a multidifusión MPLS, debe realizar una transición fluida de LSP punto a multipunto PIM a M-LDP con una interrupción mínima. Figura 20 muestra una topología M-LDP similar a Figura 19, pero con un escenario diferente. El núcleo está habilitado con PIM, con una fuente que transmite todos los canales de IPTV. Los canales de TV se envían como transmisiones 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: Ejemplo de topología M-LDP en MPLS Core habilitado para PIMEjemplo de topología M-LDP en MPLS Core habilitado para PIM

Al configurar el en este escenario, la mldp-inband-signaling señalización M-LDP se inicia sólo cuando no hay ningún vecino PIM hacia el origen. Sin embargo, dado que siempre hay un vecino PIM 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 surte efecto.

Configuración

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

Nota:

El filtro de política de señalización en banda M-LDP puede incluir la instrucción o la source-address-filterroute-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 solo debe configurarse en el LER. La configuración de la selected-mldp-egress instrucción en enrutadores PIM que no salen puede provocar errores en la configuración de rutas.

  • 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 un mecanismo de interrupción y fabricación 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 con conmutación de etiquetas de entrada (LSR) y un LSR de salida.
Multipoint LSP

Un LSP de punto a multipunto o de multipunto a multipunto.
Point-to-multipoint LSP

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

Un LSP que tiene uno o más LSR de entrada y un LSR de salida único.
Multipoint-to-multipoint LSP

Un LSP que conecta un conjunto de nodos, de modo que el tráfico enviado por cualquier nodo del 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 multipunto a multipunto pueden tener LSR de entrada múltiple. Los LSP de punto a multipunto tienen solo uno, y ese nodo a menudo se denomina nodo raíz.
Egress LSR

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

Un LSR que tiene accesibilidad a la raíz del LSP multipunto a través de un LSR ascendente conectado directamente y uno o más LSR descendentes conectados directamente.

Bud LSR

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

Un LSR de salida o de brote en el contexto de un LSP punto a multipunto. En el contexto de un LSP multipunto a multipunto, un LSR es tanto la entrada como la salida para el mismo LSP multipunto a multipunto y también puede ser un LSR excepcional.

Traducción de unión de entrada y manejo de pseudointerfaces

En el LER de entrada, LDP notifica a PIM acerca de los mensajes (S,G) que se reciben a través de la señalización en banda. PIM asocia cada mensaje (S,G) con una pseudointerfaz. Posteriormente, se inicia un mensaje de unión del árbol de ruta más corta (SPT) hacia el origen. PIM trata esto como un nuevo tipo de receptor local. Cuando se desactiva el LSP, PIM elimina este receptor local basándose en 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 próximo salto LDP y otros receptores PIM. El siguiente salto es un siguiente salto compuesto de receptores locales + la lista de vecinos PIM aguas abajo + un siguiente salto de subnivel 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 la señalización en banda M-LDP cuando se cumplen todas las condiciones siguientes:

  • No hay vecinos PIM hacia la fuente.

  • Se configura la instrucción de señalización en banda M-LDP.

  • El siguiente salto se aprende a través de 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 de 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 repetirá el recálculo del FPR. Los siguientes saltos del protocolo BGP hacia la fuente también se supervisan para detectar cambios en la raíz LSP. Estos cambios pueden causar interrupciones del tráfico durante períodos cortos.

Detección de raíz LSP

Si la operación RPF detecta la necesidad de señalización en banda M-LDP aguas arriba, 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 de LSP.

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

    Es necesario que estos LSP punto a multipunto no segmentados se señalicen a través de múltiples sistemas autónomos, lo que se puede utilizar para las siguientes aplicaciones:

    • interAS MVPN con LSP de punto a multipunto no segmentados.

    • La señalización en banda entre M-LDP del M-LDP entre las redes de cliente conectadas por una red de núcleo de CEMP.

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

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

Traducción de unión de salida y manejo de pseudointerfaces

En el LER de salida, PIM notifica a LDP el mensaje (S,G) que se va a señalar junto con la raíz LSP. PIM crea una pseudointerfaz 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 principal, donde se recibe el mensaje de unión (S,G) del sitio descendente, este mensaje de unión se traduce a parámetros de señalización en banda M-LDP y se notifica a LDP. Además, el desmontaje de LSP se produce cuando se pierde la entrada (S,G), cuando cambia la raíz de LSP o cuando se puede acceder a la entrada (S,G) a través de un vecino PIM.

Funcionalidad admitida

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

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

  • Empalme de entrada de la ruta PIM con el siguiente salto LDP

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

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

  • Configuración estática y detección de raíz LSP basada en el próximo salto del protocolo BGP

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

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

  • Mensajes de unión IGMP en LER

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

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

Funcionalidad no compatible

Para la señalización en banda M-LDP, 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)

  • Hacer antes de romper (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 virtuoso

  • Modo denso PIM

  • Modo bidireccional PIM

Funcionalidad LDP

La información PIM (S,G) se transporta como codificaciones M-LDP opaque type-length-value (TLV). El elemento FEC punto a multipunto consta de la dirección del nodo raíz. En el caso de las VPN de multidifusión de próxima generación (NGEN MVPN), el LSP punto a multipunto se identifica mediante la dirección del nodo raíz y el ID del LSP.

Funcionalidad 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 busca el nodo raíz basándose en 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 por BGP, PIM recupera la dirección del próximo salto BGP y la utiliza como nodo raíz para el LSP punto a multipunto.

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

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

Funcionalidad de Transit LSR

El LSR de tránsito anuncia una etiqueta al LSR ascendente hacia el origen del FEC 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 LER de entrada

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

  • (S,G)

  • Inundar el próximo salto

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

Consulte también

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

En este ejemplo se muestra cómo configurar la señalización en banda LDP MULTIPUNTO (M-LDP) para el tráfico de multidifusión, como una extensión del protocolo de multidifusión independiente del 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 5G serie MX o enrutadores perimetrales multiservicio serie M para enrutadores perimetrales de proveedor (PE)

  • Enrutadores de transporte de paquetes de la serie PTX que actúan como enrutadores con conmutación de etiquetas de tránsito

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

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 escalabilidad, los enrutadores principales también podrían ser plataformas de enrutamiento universal 5G serie MX o enrutadores de borde multiservicio serie M. Los dispositivos perimetrales del cliente (CE) podrían ser otros enrutadores o conmutadores de Juniper Networks u otro proveedor.

No se necesita 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 esta sección #d358e63__d358e831 se describen los pasos del Device EgressPE.

Figura 21: Señalización en banda M-LDP para topología de ejemplo de LSP de punto a multipuntoSeñalización en banda M-LDP para topología de ejemplo de 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, a continuación, copie y pegue los comandos en la CLI en el nivel de [edit] jerarquía.

Dispositivo src1

Entrada de dispositivosPE

Salida del dispositivo PE

Dispositivo p6

Dispositivo pr3

Dispositivo pr4

Dispositivo pr5

Procedimiento paso a paso

En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI.

Para configurar Device EgressPE:

  1. Configure las interfaces.

    Habilite MPLS en las interfaces orientadas al 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, este ejemplo incluye direcciones estáticas de grupo y origen.

  3. Configure MPLS en las interfaces orientadas al núcleo.

  4. Configure BGP.

    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 a BGP.

  5. (Opcional) Configure una conexión de par MSDP con el dispositivo pr5 para interconectar los dominios PIM dispares, habilitando así RP redundantes.

  6. Configure OSPF.

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

  8. Habilite los LSP MPLS punto a multipunto.

  9. Configure PIM en las interfaces descendentes.

  10. Configure las opciones de RP porque este dispositivo sirve como punto de encuentro (RP) PIM.

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

  12. Configure la directiva de enrutamiento que especifica la dirección raíz para el LSP 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 interfaces, show protocols, show policy-options y show routing-options para confirmar la configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.

Salida del dispositivo PE

Del mismo modo, configure los demás 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 funcione correctamente.

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

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

Acción

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

Comprobación de los orígenes PIM
Propósito

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

Acción

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

Comprobación de la base de datos LDP
Propósito

Asegúrese de que el show ldp database comando muestra los enlaces de raíz a (S,G) esperados.

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

Mostrar la información de FEC punto a multipunto.

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

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

Acción

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

El servidor de mapeo de enrutamiento de segmentos y la compatibilidad con clientes permite la interoperabilidad entre las islas de red que ejecutan LDP y el enrutamiento de 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 solo admitan LDP o solo enrutamiento por segmentos. Para que estos dispositivos interactúen, se requiere la funcionalidad del servidor de mapeo de enrutamiento de segmentos (SRMS) y del cliente de mapeo de enrutamiento de segmentos (SRMC). Estas funciones de servidor y cliente se habilitan en un dispositivo de la red de enrutamiento de segmentos.

La funcionalidad de servidor y cliente de mapeo de SR es compatible con OSPF o ISIS.

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

Figura 22 muestra una topología de red LDP sencilla para ilustrar cómo funciona la interoperabilidad de los dispositivos de enrutamiento de segmentos con 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 ejemplo tiene seis dispositivos, R1 a R6, en una red que está experimentando una migración de LDP a enrutamiento de segmentos.

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

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

Para que R1 interfuncione con R6, se necesitan un servidor de mapeo de enrutamiento de segmentos (SRMS) y un cliente de mapeo de enrutamiento de segmentos (SRMC). Es más fácil entender el papel del SRMS y SRMC observando el flujo de tráfico de una manera unidireccional. Basándonos en Figura 22, diremos que el tráfico que fluye de izquierda a derecha se origina en el dominio SR y termina en el dominio LDP. Del mismo modo, 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 una 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 FEC de LDP a identificadores de nodo de SR. Configure las FEC de LDP para que se asignen en el nivel de [edit routing-options source-packet-routing] jerarquía. Normalmente, debe asignar todas las direcciones de bucle invertido 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 loopbacks del nodo LDP no son contiguos, debe definir varias instrucciones de asignación.

    La configuración de asignación de SRMS se aplica en el nivel de [edit protocols ospf] jerarquía o [edit protocols isis] . Esta elección depende de qué IGP se está utilizando. Tenga en cuenta que los nodos SR y LDP comparten un dominio de enrutamiento IGP común de área o nivel único.

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

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

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

    Para interoperar de derecha a izquierda, es decir, desde la isla LDP a la isla SR, simplemente habilite la funcionalidad de cliente de mapeo de enrutamiento de segmentos en un nodo que hable tanto SR como LDP. En nuestro ejemplo eso es R4. La funcionalidad SRMC se activa 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 y el prefijo SID del dominio de SR como FEC de salida de LDP. Esto proporciona a los nodos LDP accesibilidad 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.

Interoperabilidad de enrutamiento por segmentos a LDP mediante OSPF

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

  1. Defina la función SRMS:

    Esta configuración crea un bloque de asignación para las direcciones de bucle invertido del dispositivo LDP en la topología de ejemplo. El índice inicial de 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 bucle invertido de R6.

    Nota:

    La dirección IP utilizada como dirección start-prefix 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 al dominio SR. Si las direcciones de circuito cerrado son contiguas, puede hacerlo con una sola prefix-segment-range instrucción. Los bucles invertidos no contiguos requieren la definición de varias instrucciones de asignación de prefijos.

    Nuestro ejemplo usa loopbacks contiguos para que se muestre un solo arriba prefix-segment-range . Este es un ejemplo de múltiples asignaciones para admitir el caso de dos nodos LDP con direccionamiento de circuito cerrado no contiguo:

  2. A continuación, configure la compatibilidad de OSPF para el LSA extendido utilizado para inundar los prefijos asignados.

    Una vez confirmada la configuración del servidor de asignación en el dispositivo R2, el TLV de rango de prefijo extendido se inunda en el área OSPF. Los dispositivos capaces de enrutamiento de 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). El índice SID también se actualiza en la tabla de mpls.0 enrutamiento mediante los dispositivos de enrutamiento de segmento.

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

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

La compatibilidad con el enrutamiento de segmentos de unión y los próximos saltos 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 s solo se detectan en el SRMS. Cuando hay un conflicto de intervalo de prefijos, prevalece el SID de 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 prefijos IPv6.

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

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

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

  • La funcionalidad ASBR del prefijo extendido opaco LSA no es compatible.

  • No se admite el TLV de preferencia del servidor de asignación de enrutamiento segment.

Interoperabilidad del enrutamiento por segmentos con LDP mediante ISIS

Consulte , Figura 22suponga que el dispositivo R2 (en la red de enrutamiento de segmentos) es el SRMS. Se agrega la siguiente configuración 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 bucle invertido del dispositivo LDP en la topología de ejemplo. El índice inicial de 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 bucle invertido de R6.

    Nota:

    La dirección IP utilizada como dirección start-prefix 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 de SR. Si las direcciones de circuito cerrado son contiguas, puede hacerlo con una prefix-segment-range instrucción. Los loopbacks no contiguos requieren la definición de varias instrucciones de asignación.

    Nuestro ejemplo usa loopbacks contiguos para que se muestre un solo arriba 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 la compatibilidad con ISIS para el LSP extendido utilizado para inundar los prefijos asignados.

    Una vez confirmada la configuración del servidor de asignación en el dispositivo R2, el TLV de rango de prefijo extendido se inunda en el área OSPF. Los dispositivos capaces de enrutamiento de 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). El índice SID también se actualiza en la tabla de mpls.0 enrutamiento mediante los dispositivos de enrutamiento de segmento.

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

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

La compatibilidad con el enrutamiento de 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 estallido de penúltimo salto para el TLV de enlace de etiquetas.

  • No se admite la publicidad del 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 detención (NSR) ni el cambio normal de motor de enrutamiento (GRES).

  • ISIS internivel no es compatible.

  • RFC 7794, No se admiten atributos de prefijo IS-IS para IPv4 extendido .

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

Propiedades Misceláneas de LDP

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

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

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

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

Para obtener una lista de los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

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

Mediante la configuración de la no-forwarding instrucción, puede evitar que las rutas de entrada se agreguen a la tabla de enrutamiento inet.0 en lugar de a la tabla de enrutamiento inet.3, incluso si habilitó la traffic-engineering bgp-igp instrucción en el nivel de [edit protocols mpls] jerarquía o [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 los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

VPN de múltiples instancias de LDP y de portadora de carriers

Al configurar varias instancias de enrutamiento LDP, puede usar LDP para anunciar etiquetas en una VPN de operadora desde un enrutador perimetral (PE) de proveedor de servicios hasta un enrutador perimetral de cliente (CE) de operadora de cliente. Esto es especialmente útil cuando el cliente operador es un proveedor de servicios de Internet (ISP) básico y desea restringir rutas completas de Internet a sus enrutadores PE. Al usar LDP en lugar de BGP, el cliente operador protege sus otros enrutadores internos de Internet. El LDP de instancias múltiples también es útil cuando un cliente operador 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 LDP para VPN de operadoras, consulte la Guía del usuario de varias instancias para el protocolo de distribución de etiquetas.

Configure MPLS y LDP para que aparezcan la etiqueta en el enrutador de salto definitivo

La etiqueta anunciada predeterminada es la etiqueta 3 (etiqueta nula implícita). Si se anuncia la etiqueta 3, el enrutador del penúltimo salto quita la etiqueta y envía el paquete al enrutador de salida. Si el estallido de último salto está habilitado, se anuncia la etiqueta 0 (etiqueta nula explícita IPv4). El último salto garantiza que cualquier paquete que atraviese una red MPLS incluya una etiqueta.

Para configurar la ventana emergente de último salto, incluya la explicit-null instrucción:

Para obtener una lista de los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

Nota:

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

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

Habilitar LDP sobre LSP establecidos por RSVP

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

Para obtener una lista de los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

Nota:

LDP se puede tunelizar a través de una sesión RSVP que tenga habilitada la protección de vínculos. A partir de Junos OS Release 21.1R1, al mostrar detalles sobre la ruta tunelizada LDP, se muestran los siguientes saltos principales y de derivación de LSP. En versiones anteriores de Junos OS, el siguiente salto del LSP de derivación mostraba el siguiente salto del LSP principal.

Habilite LDP sobre LSP establecidos por RSVP en redes heterogéneas

Algunos otros proveedores utilizan una métrica OSPF de 1 para la dirección de circuito cerrado. Los enrutadores de Juniper Networks utilizan una métrica OSPF de 0 para la dirección de circuito cerrado. Esto podría requerir que configure manualmente la métrica RSVP al implementar túnel LDP sobre 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 LDP también está habilitada, de forma predeterminada es posible que el enrutador de Juniper Networks no utilice el túnel RSVP para enrutar el tráfico a los destinos LDP aguas abajo del enrutador de salida del otro proveedor si la ruta RSVP tiene una métrica de 1 mayor que la ruta OSPF física.

Para asegurarse de que la tunelización de LDP funciona correctamente en redes heterogéneas, puede configurar OSPF para que ignore la métrica RSVP LSP 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 sobre RSVP LSP, también debe completar el procedimiento de la sección Habilitar LDP sobre LSP establecidos por RSVP.

Configurar la firma TCP MD5 para sesiones LDP

Puede configurar una firma MD5 para una conexión TCP LDP a fin de protegerla 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 obtener información sobre cómo utilizar la opción de autenticación TCP (TCP-AO) en lugar de TCP MD5, consulte No link title.

Un enrutador que utiliza 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 de saludo LDP 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 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 coincidencia de subred proporciona flexibilidad en la configuración de la autenticación para sesiones LDP de destino automático (TLDP). Esto facilita la implementación de la alternativa remota sin bucles (LFA) y los pseudocables FEC 129.

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

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

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

También puede configurar un mecanismo de actualización de claves de autenticación para el protocolo de enrutamiento LDP. Este mecanismo permite actualizar las claves de autenticación sin interrumpir los protocolos de enrutamiento y señalización asociados, como Open Shortest Path First (OSPF) y Resource Reservation Setup Protocol (RSVP).

Para configurar el mecanismo de actualización de claves 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 para crear un llavero que conste de varias claves de autenticación.

Para configurar el mecanismo de actualización de claves de autenticación para el protocolo de enrutamiento LDP, incluya la authentication-key-chain instrucción en el nivel de [edit protocols ldp] jerarquía 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 en el [edit protocols ldp] nivel de jerarquía.

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

Configuración de la protección de sesión LDP

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

Puede configurar Junos OS para que deje activa la sesión LDP entre dos enrutadores, incluso si no hay adyacencias de saludo en los vínculos que conectan los dos enrutadores, configurando la session-protection instrucción. Opcionalmente, puede especificar un tiempo en segundos mediante la timeout opción. La sesión permanece activa durante el tiempo especificado mientras los enrutadores mantengan la conectividad de red IP.

Para obtener una lista de los niveles jerárquicos en los que puede incluir esta instrucción, consulte la sección Resumen de instrucciones.

Deshabilitar capturas SNMP para LDP

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

Para obtener información acerca de las capturas SNMP de LDP y la MIB de LDP propietaria, consulte el Explorador de MIB de SNMP.

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

Para obtener una lista de los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

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

LDP es un protocolo para distribuir etiquetas en aplicaciones sin ingeniería de tráfico. Las etiquetas se distribuyen a lo largo del mejor camino determinado por el IGP. Si no se mantiene la sincronización entre LDP y el IGP, el LSP deja de funcionar. Cuando LDP no está completamente operativo en un enlace determinado (no se establece una sesión y no se intercambian etiquetas), el IGP anuncia el enlace 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 LDP solo se admite en interfaces punto a punto activas e interfaces LAN configuradas como punto a punto bajo el IGP. La sincronización LDP no se admite durante el reinicio correcto.

Para anunciar la métrica de costo máximo hasta que 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 de un vínculo que no está completamente operativo, incluya la hold-time instrucción.

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

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

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

Para configurar el tiempo que espera el LDP antes de informar al IGP de que el vecino y la sesión del LDP 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 los niveles de jerarquía en los que puede configurar esta instrucción, vea la sección resumen de instrucción de esta instrucción.

Configuración del temporizador de retirada de etiquetas

El temporizador de retiro de etiquetas retrasa el envío de un mensaje de retiro de etiqueta para un FEC a un vecino. Cuando un enlace IGP a un vecino falla, la etiqueta asociada con el FEC tiene que ser retirada 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 vuelve a anunciar a todos los enrutadores ascendentes. Este es el comportamiento típico de la red. Al retrasar la retirada de la etiqueta por un pequeño período de tiempo (por ejemplo, hasta que el IGP converja y el enrutador reciba una nueva etiqueta para el FEC del próximo salto aguas abajo), se podría evitar la retirada de la etiqueta y el envío de un mapeo de etiquetas pronto. 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, el temporizador de retirada de la etiqueta se cancela. Sin embargo, si se agota el temporizador, la etiqueta del FEC se retira de todos los enrutadores ascendentes.

De forma predeterminada, LDP espera 60 segundos antes de retirar las etiquetas para evitar volver a señalar los LSP varias veces mientras el IGP está reconvergiendo. Para configurar el tiempo de retraso de retirada de la etiqueta en segundos, incluya la label-withdrawal-delay instrucción:

Para obtener una lista de los niveles de jerarquía en los que puede configurar esta instrucción, vea 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 y posteriores de Junos OS, se realiza una comprobación de subred de la dirección de origen LDP durante el procedimiento de establecimiento del vecino. La dirección de origen en el paquete de saludo del vínculo LDP se compara con la dirección de la 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 jerárquicos:

  • [edit protocols ldp interface interface-name]

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

Nota:

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

Consulte también

Configuración de LDP LSP Traceroute

Puede rastrear la ruta seguida por un LSP con señal LDP. LDP LSP traceroute se basa en RFC 4379, Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures. Esta función le permite rastrear periódicamente todas las rutas en un FEC. La información de topología FEC se almacena en una base de datos accesible desde la CLI.

Un cambio de topología no desencadena automáticamente un seguimiento de un LSP de LDP. Sin embargo, puede iniciar manualmente un traceroute. Si la solicitud traceroute es para un 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 traceroute periódica se aplica a todas las FEC especificadas por la oam instrucción configurada en el nivel de [edit protocols ldp] jerarquía. Para configurar la traceroute periódica de LSP de LDP, 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 sola o con cualquiera de las siguientes opciones:

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

  • fanout: especifique el número máximo de próximos saltos para buscar por nodo.

  • frequency: especifique el intervalo entre los intentos de traceroute.

  • paths: especifique el número máximo de rutas que se van a buscar.

  • retries: especifique el número de intentos de enviar una sonda a un nodo específico antes de darse por vencido.

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

  • ttl: especifique el valor máximo de tiempo de vida. No se realiza un seguimiento de los nodos que superan este valor.

  • wait: especifique el intervalo de espera antes de volver a enviar un paquete de sondeo.

Recopilación de estadísticas de LDP

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

Cuando se configura la traffic-statistics instrucción en el nivel de [edit protocols ldp] jerarquía, las estadísticas de tráfico de 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 recolección predeterminado es de 5 minutos. Debe configurar un archivo de estadísticas LDP; de lo contrario, no se recopilan estadísticas de tráfico de LDP. Si el LSP deja de funcionar, se restablecen las estadísticas de LDP.

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

Para obtener una lista de los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

Esta sección incluye los siguientes temas:

Resultado de estadísticas de LDP

El siguiente resultado de ejemplo procede de un archivo de estadísticas LDP:

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

  • FEC—FEC para el que 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 aprobados por la FEC desde que apareció su LSP.

  • Bytes—Número de bytes de datos pasados por la FEC desde que apareció 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 la hora) puede diferir del número real de las estadísticas mostradas. Algunas de las estadísticas se resumen antes de ser mostradas.

Deshabilitar estadísticas de LDP en el enrutador de penúltimo salto

La recopilación de estadísticas de tráfico LDP en el enrutador del penúltimo salto puede consumir recursos excesivos del sistema, 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. En el caso de los enrutadores que alcanzan su límite de uso de rutas del próximo salto, recomendamos configurar la no-penultimate-hop opción para la traffic-statistics instrucción:

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

Nota:

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

Siempre que incluya o quite esta opción de la configuración, las sesiones de LDP se desactivan y, a continuación, 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 de 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 puede borrar las estadísticas de LDP.

  • Si acorta el intervalo especificado, sólo se emite una nueva solicitud de estadísticas LDP si el temporizador de estadísticas caduca después del nuevo intervalo.

  • Una nueva operación de recopilación de estadísticas de LDP no puede iniciarse hasta que haya finalizado la anterior. Si el intervalo es corto o si el número de estadísticas de LDP es grande, el intervalo de tiempo entre las dos recopilaciones de estadísticas puede ser mayor que el intervalo.

Cuando un LSP deja de funcionar, se restablecen las estadísticas de LDP.

Seguimiento del tráfico del protocolo LDP

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

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

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

Para obtener una lista de los niveles jerárquicos en los que puede incluir esta instrucción, vea la sección de resumen de instrucción de esta instrucción.

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. Le recomendamos que coloque el resultado del seguimiento de LDP en el archivo ldp-log.

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

  • address—Rastrear el funcionamiento de la dirección y los mensajes de retirada de direcciones.

  • binding: rastrea las operaciones de encuadernación de etiquetas.

  • error: condiciones de error de rastreo.

  • event: rastrea eventos de protocolo.

  • initialization: rastrea el funcionamiento de los mensajes de inicialización.

  • label: realiza un seguimiento del funcionamiento de los mensajes de solicitud de etiqueta, mapa de etiquetas, retirada de etiquetas y liberación de etiquetas.

  • notification: rastrea el funcionamiento de los mensajes de notificación.

  • packets: rastree la operación de la dirección, la retirada de direcciones, la inicialización, la solicitud de etiqueta, el mapa de etiquetas, la retirada de etiquetas, la liberación de etiquetas, la notificación y los mensajes periódicos. Este modificador equivale a establecer los addressmodificadores, initialization, notificationlabel, y periodic modificadores.

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

  • path: rastree las operaciones de las rutas conmutadas por etiquetas.

  • path: rastree las operaciones de las rutas conmutadas por etiquetas.

  • periodic: permite rastrear el funcionamiento de los mensajes de saludo y keepalive.

  • route: permite realizar un seguimiento del funcionamiento de los mensajes de ruta.

  • state: transiciones de estado del protocolo de seguimiento.

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

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 por el siguiente salto para el FEC y la empalma a la etiqueta que anuncia a todos los demás enrutadores.

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

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

Esta característica tiene las siguientes limitaciones:

  • La capacidad de filtrado solo está disponible para FEC compuestos por prefijos IP versión 4 (IPv4).

  • Los FEC del circuito de capa 2 no se pueden filtrar.

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

  • El filtrado viene determinado por la directiva y el valor configurado para la match-on opción. Al configurar la directiva, asegúrese de que el comportamiento predeterminado es siempre reject.

  • La única match-on opción es fec. Por consiguiente, el único tipo de directiva que debe incluir es una directiva de filtro de ruta.

Ejemplos: Seguimiento del tráfico del protocolo LDP

Realice un seguimiento detallado de los mensajes de ruta de acceso de LDP:

Rastree 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:

Rastrear el tráfico del protocolo LDP para un FEC asociado con el LSP:

Tabla de historial de cambios

La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice Feature Explorer a fin de determinar si una función es compatible con la plataforma.

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 de esa subred.
22.4R1
A partir de Junos OS Evolved versión 22.4R1, la autenticación TCP es compatible con VRF.
19.1
A partir de Junos OS versión 19.1R1, el enrutador de borde LDP de enrutamiento de segmentos puede unir el tráfico de enrutamiento de segmentos al siguiente salto de LDP y viceversa.
16.1
A partir de Junos OS versión 16.1, M-LDP puede señalar LSP punto a multipunto en ASBR o tránsito o salida 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 Junos OS versión 14.1, para migrar los servicios de IPTV existentes de multidifusión IP nativa a multidifusión MPLS, debe realizar una transición fluida de LSP punto a multipunto PIM a M-LDP con una interrupción mínima.