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 el LDP con una configuración mínima:

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

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

  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 para interface-name.

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

Habilitación y desactivación de LDP

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

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

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

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

Para obtener una lista de niveles 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 LDP permiten que los nodos LDP se descubran entre sí y detecten la falla de un vecino o del vínculo con el vecino. Los mensajes de saludo se envían periódicamente en todas las interfaces donde está habilitada la LDP.

Hay dos tipos de mensajes de saludo LDP:

  • Mensajes de saludo de vínculo: enviados a través de la interfaz LDP como paquetes UDP dirigidos al puerto de detección 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 de LDP entre enrutadores que no están conectados directamente. Un enrutador de destino determina si debe responder o ignorar un mensaje de saludo dirigido. Un enrutador dirigido 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 mensajes de saludo de vínculo y cada 15 segundos para 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 Configurar el retraso antes de que se consideren hacia abajo los vecinos LDP.

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

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 LDP mediante la hello-interval instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de resumen de instrucciones para 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 LDP configurando la hello-interval instrucción como una opción para la targeted-hello instrucción:

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

Configurar el retraso antes de que los vecinos del LDP se consideren hacia abajo

El tiempo de espera determina cuánto tiempo debe esperar un nodo LDP un mensaje de saludo antes de declarar que un vecino está caído. Este valor se envía como parte de un mensaje de saludo para que cada nodo LDP indique a sus vecinos cuánto tiempo de espera. 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 15 segundos para los mensajes de saludo de vínculo y 45 segundos para los mensajes de saludo dirigidos. Sin embargo, es posible configurar un tiempo de espera 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 se detecten más rápidamente las fallas del vecino LDP. Sin embargo, esto también aumenta la posibilidad de que el enrutador pueda declarar un vecino LDP hacia abajo que sigue funcionando normalmente. Para obtener más información, consulte Configurar el temporizador LDP para mensajes de saludo.

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

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

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

Cuando reconfigura 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 (requerida por RFC 5036, especificación LDP). Para forzar manualmente el restablecimiento de la sesión de LDP, ejecute el clear ldp session comando.

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

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

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de resumen de instrucciones para 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 un mensaje de saludo de destino antes de declarar el vecino hacia abajo, especifique una nueva hora en segundos mediante la hold-time instrucción como opción para la targeted-hello instrucción:

Para obtener una lista de niveles de jerarquía en los que puede incluir estas instrucciones, consulte las secciones de resumen de instrucciones para 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 se configura 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 el indicador de error seguimiento) que indica el origen. Por ejemplo, si el par LDP recibió un saludo de destino de la dirección de Internet 10.0.0.1 y ningún vecino con esta dirección está configurado específicamente, el siguiente mensaje se imprime en el archivo de registro LDP:

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

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

Configuración del intervalo para mensajes de mantenimiento de LDP

El intervalo de 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 de keepalive. Si no se envía ningún otro tráfico LDP a través de la sesión en este tiempo, se envía un mensaje de keepalive. El valor predeterminado es de 10 segundos. El valor mínimo es 1 segundo.

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

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

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

Configuración del tiempo de espera de keepalive de LDP

Después de establecer una sesión de LDP, los mensajes se deben intercambiar 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 normalmente se establece en al menos tres veces el intervalo de keepalive. El valor predeterminado es de 30 segundos.

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

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

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

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

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

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

  1. Configure las interfaces del dispositivo.

  2. Configure el protocolo MPLS.

  3. Configure el protocolo OSPF.

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

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

    Por ejemplo, para configurar las interfaces:

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

En este ejemplo, se muestra cómo configurar la coincidencia más larga para LDP basada en RFC5283. Esto permite que el LDP aprenda las rutas agregadas o resumidas en á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 serie MX con protocolo OSPF y LDP habilitados en las interfaces conectadas.

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

Antes de comenzar:

  • Configure las interfaces del dispositivo.

  • Configure OSPF.

Descripción general

A menudo, el LDP se utiliza para establecer rutas conmutadas por etiquetas (LSP) MPLS en todo un dominio de red completo mediante un IGP como OSPF o IS-IS. En esta red, todos los vínculos del dominio tienen adyacencias de IGP, así como adyacencias de LDP. LDP establece los LSP en la ruta más corta a un destino según lo determinado por el reenvío IP. En Junos OS, la implementación de LDP hace 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 se configuren en todos los LER. Esto anula el propósito del diseño jerárquico IP o el enrutamiento predeterminado en los dispositivos de acceso. longest-match La configuración ayuda a superar esto mediante la supresión del comportamiento de coincidencia exacto y la configuración de LSP en función de 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 y, luego, ingrese commit desde el [edit] modo de configuración.

R0

R1

R2

R3

R4

R5

Configuración del dispositivo R0

Procedimiento paso a paso

En el ejemplo siguiente, se requiere navegar 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 el modo de configuración en la Guía del usuario de la 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, confirme la configuración ingresando los show interfacescomandos , show protocolsy show routing-options . Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.

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

Verificación

Confirme que la configuración funciona correctamente.

Verificar las rutas

Propósito

Compruebe que se aprenden las rutas esperadas.

Acción

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

Significado

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

Verificar la información general del LDP

Propósito

Muestra información general de LDP.

Acción

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

Significado

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

Verifique 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

Muestra solo 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 solo muestra las rutas FEC del protocolo LDP disponibles para el dispositivo R0.

Verifique fec y rutas de sombra de LDP

Propósito

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

Acción

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

Significado

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

Configuración de preferencias de ruta LDP

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

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

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

Reinicio agraciado del LDP

El reinicio correcto de LDP permite a un enrutador cuyo plano de control LDP se está reiniciando para continuar reenvía tráfico mientras recupera su estado de enrutadores vecinos. También habilita un enrutador en el que el modo de aplicación auxiliar está habilitado para ayudar a un enrutador vecino que intenta reiniciar el LDP.

Durante la inicialización de la sesión, un enrutador anuncia su capacidad para realizar un reinicio correcto de LDP o para aprovechar a un vecino que realiza un reinicio agraciado de LDP mediante el envío de la TLV de reinicio correcto. Esta TLV contiene dos campos relevantes para el reinicio correcto del LDP: el tiempo de reconección y el tiempo de recuperación. Los valores de los tiempos de reconexión y recuperación indican las capacidades de reinicio correctas 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 espera un enrutador para que el LDP se reinicie correctamente. El período de tiempo de recuperación comienza cuando se envía o recibe un mensaje de inicialización. Este período de tiempo también suele ser la longitud de tiempo que un enrutador vecino mantiene su información sobre el enrutador de reinicio, lo que le permite seguir reenviando 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 a nivel global para todos los protocolos, en el nivel de protocolo solo para LDP y en una instancia de enrutamiento específica. El reinicio correcto de 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 a intentar reiniciar correctamente) 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 se reinicia un enrutador, no se envían mensajes de asignación de etiquetas a los vecinos que admitan un reinicio correcto hasta que el enrutador de reinicio se haya estabilizado (los mensajes de asignación de etiquetas se envían inmediatamente a los vecinos que no admiten un reinicio correcto). Sin embargo, todos los demás mensajes (keepalive, dirección-mensaje, notificación y versión) se envían como de costumbre. La distribución de estos otros mensajes impide que el enrutador distribuya información incompleta.

  • El modo auxiliar y el reinicio correcto son independientes. Puede deshabilitar el reinicio correcto en la configuración, pero seguir permitiendo que el enrutador coopere con un vecino que intenta reiniciar correctamente.

Configuración del reinicio correcto del LDP

Cuando se modifica la configuración de reinicio correcto en los [edit routing-options graceful-restart] niveles de 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 del BGP cuando se modifica su configuración de reinicio correcta.

De forma predeterminada, el modo de aplicación 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 a intentar un reinicio correcto, pero no a intentar un reinicio correcto.

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

Habilitación del reinicio correcto

Para habilitar el reinicio correcto de LDP, también debe habilitar un 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 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 compatibles con 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 un reinicio correcto tanto en el nivel del protocolo LDP como en todas las instancias de enrutamiento. Sin embargo, puede deshabilitar tanto el reinicio correcto de LDP como el modo de aplicación auxiliar de reinicio agraciado 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 niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de resumen de instrucciones para esta instrucción.

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

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

Las siguientes configuraciones de reinicio de LDP son posibles:

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

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

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

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

Configurar el tiempo de reconectación

Después de que se produce un error en la conexión LDP entre vecinos, los vecinos esperan una cierta cantidad de tiempo para que el enrutador que 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 la sesión tolerante a errores TLV enviada en mensajes de inicialización de LDP cuando se habilita el reinicio correcto de LDP.

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

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

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

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

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

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

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

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

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

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

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

from Operador

Descripción

interface

Hace coincidir los enlaces recibidos de un vecino adyacente a través de la interfaz especificada

neighbor

Coincidencias en los enlaces recibidos del ID de enrutador LDP especificado

next-hop

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

route-filter

Hace coincidir los enlaces con el prefijo especificado

Si se filtra un enlace, sigue aparecen en la base de datos LDP, pero no se considera para la instalación como parte de una ruta de conmutación de etiquetas (LSP).

Por lo general, la aplicación de políticas en LDP solo se puede utilizar para bloquear el establecimiento de LSP, no para controlar su enrutamiento. Esto se debe a que la ruta que sigue un LSP está determinada por el enrutamiento de unidifusión y no por el 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 siguientes saltos posibles de consideración. (De lo contrario, el LDP elige uno de los próximos saltos posibles al azar.)

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

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

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

Ejemplos: Filtrado de enlaces de etiquetas LDP entrantes

Acepte solo /32 prefijos de todos los vecinos:

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

Filtrado de enlaces de etiquetas LDP salientes

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

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

La política de exportación denominada (configurada en el [edit policy-options] nivel de jerarquía) se aplica a todos los enlaces de etiquetas transmitidos a todos los vecinos de LDP. El único from operador que se aplica al filtrado de etiquetas salientes de 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 en Tabla 2.

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

al operador

Descripción

interface

Hace coincidir los 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

Hace coincidir los enlaces enviados a un vecino que anuncia la dirección de interfaz especificada

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

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

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

Las etiquetas filtradas se marcan en la base de datos:

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

Ejemplos: Filtrado de enlaces de etiquetas LDP salientes

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

Enviar solo 131.108/16 o más al ID 10.10.255.2del enrutador y enviar 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 sí antes de que puedan establecer una sesión LDP. La sesión TCP permite a los enrutadores intercambiar los anuncios de etiquetas necesarios para la sesión de 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 usa para identificar la sesión TCP en la que se ejecutará la sesión de LDP.

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

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

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

Nota:

Para una operación adecuada, debe ser accesible la dirección de transporte LDP. El ID de enrutador es un identificador, no una dirección IP enrutable. Por esta razón, se recomienda establecer el ID del enrutador para que coincida con la dirección de circuito cerrado y que la dirección de circuito cerrado sea anunciada por el IGP.

No puede especificar la interface opción cuando hay varios vínculos paralelos al mismo vecino LDP, ya que la especificación 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 a ese vecino una a una hasta que se borra la condición, ya sea desconectando el vecino en una interfaz o especificando la router-id opción.

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

Para establecer una sesión TCP entre dos dispositivos, cada dispositivo debe aprender la dirección de transporte del otro dispositivo. La dirección de transporte es una dirección IP que se usa para identificar la sesión TCP en la que opera la sesión de 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 dirigidos para adyacencias de circuito de capa 2, MPLS y VPLS. Esto le permite controlar las sesiones de LDP de destino mediante la configuración de dirección de transporte.

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

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

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

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

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

Antes de Junos OS versión 19.1R1, LDP solo proporcionaba soporte para 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 usaron 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 de 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 sessioninstrucciones de session-groupconfiguración y ,interface La configuración de dirección de transporte es aplicable para vecinos configurados solo incluyendo circuitos de capa 2, MPLS y adyacencias VPLS. Esta configuración no se aplica a las adyacencias detectadas (dirigidas o no).

Preferencia de dirección de transporte

Puede configurar la dirección de transporte para las sesiones de LDP de destino en el nivel de sesión, grupo de sesiones e interfaz.

Después de configurar la dirección de transporte, la sesión LDP de destino se establece 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 objetivo (configurado a través del circuito de capa 2, MPLS, VPLS y configuración 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 donde el 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 Configuración de direcciones de transporte

Puede utilizar las siguientes salidas de comando show para solucionar problemas de las sesiones de LDP de destino:

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

  • show configuration protocols ldp

También puede habilitar las opciones de seguimiento de LDP para una solución de problemas más avanzada.

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

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

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

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

  • La dirección que está configurada como dirección de transporte en una neighbor o session instrucción debe ser local al 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 niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de resumen de instrucciones para esta instrucción.

Nota:

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

La política denominada (configurada en el [edit policy-options] nivel o [edit logical-systems logical-system-name policy-options] jerarquía) se aplica a todas las rutas de la tabla de enrutamiento. Las rutas que coincidan 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 tienen en cuenta 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 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 a 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 se enlazan en un solo LSP, no se produce el equilibrio de carga entre rutas de igual costo. Sin embargo, puede equilibrar la carga en rutas de igual costo si configura una política de equilibrio de carga y desagrega las FEC.

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

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

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

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

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

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

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

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

Configuración de agentes de policía para FEC LDP

Puede configurar Junos OS para realizar un seguimiento y controlar el tráfico de las FEC LDP. Los agentes de policía fec de LDP se pueden utilizar para hacer cualquiera de las siguientes acciones:

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

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

  • Seguimiento o policía del tráfico FEC LDP que se origina en una clase de reenvío específica.

  • Seguimiento o policía del tráfico FEC LDP que se origina en un sitio específico de enrutamiento y reenvío virtual (VRF).

  • Descarte el tráfico falso enlazado para un FEC LDP específico.

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

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

Una vez que haya configurado los filtros, debe incluirlos en la configuración de instrucción policing para LDP. Para configurar los agentes de policía para fec LDP, incluya la policing instrucción:

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

La policing instrucción incluye las siguientes opciones:

  • fec: especifique la dirección FEC para la FEC LDP que desea policiar.

  • 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 de circuito de capa 2 a través de la sesión LDP de destino. Para una sesión LDP a un vecino conectado indirectamente, es posible que solo desee exportar las 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 mixtos en la que todos los prefijos no BGP se anuncian en LDP, la base de datos LDP puede convertirse en grande. Para este tipo de entorno, puede ser útil evitar el anuncio de FEC IPv4 sobre sesiones de LDP formadas debido a la configuración de circuito de capa 2 o VPLS LDP. 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 anunciar solo FEC de circuito de capa 2 mediante la configuración de la l2-smart-policy instrucción. Esta función también filtra automáticamente los FEC IPv4 recibidos en esta sesión. Configurar una política de exportación o importación explícita que se active para l2-smart-policy deshabilitar esta función en la dirección correspondiente.

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

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

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

Configuración de BFD para LSP LDP

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

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

También puede configurar BFD para LSP RSVP, como se describe en Configurar BFD para LSP con señal RSVP.

Los temporizadores de detección de fallas BFD son adaptables y se pueden ajustar para que sean más o menos agresivos. Por ejemplo, los temporizadores pueden adaptarse a un valor más alto si se produce un error en 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 una solapa 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 BFD local es la razón de la solapa de sesión. El intervalo de transmisión (tx) se incrementa en dos si la instancia BFD remota es la razón del flap de sesión. Puede usar el clear bfd adaptation comando para devolver los temporizadores de intervalo BFD a sus valores configurados. El clear bfd adaptation comando no tiene pulsaciones, lo que significa que el comando no afecta al flujo de tráfico en el dispositivo de enrutamiento.

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

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

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

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

  • [edit protocols ldp]

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

Nota:

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

La oam instrucción incluye las siguientes opciones:

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

  • 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, utilice el ping mpls ldp comando. Para obtener más información, consulte el Explorador de CLI.

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

  • ecmp— Hacer que LDP establezca sesiones BFD para todas las rutas ECMP configuradas para la FEC especificada. Si configura la ecmp opción, también debe configurar la periodic-traceroute instrucción para la FEC especificada. Si no lo hace, se 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 solo configura la ecmp opción para una FEC específica ([edit protocols ldp oam fec address bfd-liveness-detection]).

  • intervalo de retención: especifique la duración de la sesión BFD debe permanecer activa antes de agregar la ruta o el próximo salto. Especificar un tiempo de 0 segundos hace que se agregue la ruta o el próximo salto tan pronto como vuelva a activarse la sesión 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 de recepción mínimo. El rango es de 1 a 255 000 milisegundos.

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

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

  • versión: especifique la versión 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 consciente de ECMP para LSP LDP

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

El traceroute LDP LSP se ejecuta periódicamente para comprobar la integridad de las rutas ECMP. Puede ocurrir lo siguiente cuando se detecta un problema:

  • Si el traceroute LDP LSP más reciente para una FEC difiere de la ruta de seguimiento anterior, se reducen las sesiones BFD asociadas con esa FEC (las sesiones BFD para intervalos de direcciones que han cambiado de la ejecución anterior) y se inician nuevas sesiones BFD para las direcciones de destino en los intervalos modificados.

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

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

Para obtener una lista de niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de resumen de instrucciones para 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 OAM de LDP (en el [edit protocols ldp oam] nivel de jerarquía) o [edit logical-systems logical-system-name protocols ldp oam] en la configuración del FEC especificado (en el [edit protocols ldp oam fec address] nivel de jerarquía).[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 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 propiedades de ruta y salto siguiente en caso de un evento de error de sesión BFD en un LSP LDP. El evento de error podría ser una sesión BFD existente que se ha caído o puede ser una sesión BFD que nunca surgió. LDP agrega de nuevo la ruta o el próximo salto cuando vuelve a activarse 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 un error de sesión BFD en LDP LSP:

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

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

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

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

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

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

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

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

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

Nota:

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

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

Con MoFRR habilitado, los dispositivos envían mensajes de unión en rutas ascendentes principales y de respaldo hacia 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 (ponderaciones que se asignan a las rutas principal y de respaldo). Cuando un dispositivo detecta un error en la ruta principal, comienza inmediatamente a aceptar paquetes desde la interfaz secundaria (la ruta de respaldo). La conmutación rápida mejora en gran parte los tiempos de convergencia de las fallas del vínculo de ruta principal.

Una aplicación para MoFRR es la transmisión de IPTV. Las secuencias de IPTV son de multidifusión como flujos UDP, por lo que los paquetes perdidos no se retransmiten, lo que da lugar 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 secuencias de unidifusión, un dispositivo de enrutamiento ascendente establece previamente rutas conmutadas por etiquetas (LSP) MPLS o precompute una ruta de copia de seguridad de reenrutamiento rápido alternativo sin bucle IP (LFA) para manejar fallas de un segmento en la ruta descendente.

En el enrutamiento de multidifusión, el lado receptor suele originar los gráficos de distribución de tráfico. Esto es diferente del 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 que son 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 se admiten.

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

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

MoFRR se admite para familias de protocolos IPv4 e IPv6.

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

Figura 12: Topología de ejemplo moFRRTopología de ejemplo moFRR

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

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

MoFRR se admite tanto en rutas multipath (ECMP) de costo igual como en rutas no ECMP. El dispositivo debe habilitar rutas alternativas sin bucle de unidifusión (LFA) para admitir MoFRR en rutas que no sean ECMP. Habilite rutas LFA mediante la link-protection instrucción en la configuración del protocolo de puerta de enlace interior (IGP). Cuando habilita la protección de vínculo en una interfaz OSPF o IS-IS, el dispositivo crea una ruta de LFA de respaldo al salto siguiente 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 etiqueta-borde (LER) MPLS para moFRR de LDP multipunto.

El MoFRR de LDP multipunto se utiliza en el dispositivo de salida de una red MPLS, donde los paquetes se reenvían a una red IP. Con el MoFRR de LDP multipunto, el dispositivo establece dos rutas hacia el dispositivo de enrutamiento PE ascendente para recibir dos secuencias de paquetes MPLS en el LER. El dispositivo acepta una de las secuencias (la principal) y la otra (la copia de seguridad) se cae en el LER. Si se produce un error en la ruta principal, el dispositivo 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 de LDP multipunto en banda para LSP de punto a multipunto).

Funcionalidad pim

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

Con el 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 con el mismo dispositivo de enrutamiento ascendente inmediato. PIM instala rutas de multidifusión adecuadas con saltos siguientes RPF ascendentes con dos interfaces (para las rutas principal y de respaldo).

Cuando se produce un error en la ruta principal, la ruta de respaldo 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 respaldo y actualiza o instala la ruta de multidifusión adecuada.

Puede habilitar MoFRR con equilibrio de carga de unión PIM (consulte la join-load-balance automatic instrucción). Sin embargo, en ese caso, es posible que la distribución de mensajes de combinación entre los vínculos no sea uniforme. Cuando se agrega un nuevo vínculo ECMP, se redistribuye y se equilibra la carga de los mensajes de unión en la ruta principal. Los mensajes de unión en la ruta de copia de seguridad pueden seguir la misma ruta y no se pueden redistribuir uniformemente.

Habilitar MoFRR mediante la stream-protection instrucción de configuración 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, busca una configuración de MoFRR y continúa 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, plano 2 en Figura 12).

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

  • Si no hay una política, el dispositivo busca rutas principales y de respaldo (interfaces ascendentes) y continúa de la siguiente manera:

    • Si las rutas principal y de respaldo no están disponibles, PIM envía un mensaje de unión ascendente hacia un vecino ascendente (por ejemplo, plano 2 en 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, plano 1 en Figura 12).

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

    • Si esta comprobación de política falla: PIM envía un mensaje de unión ascendente hacia un vecino ascendente (por ejemplo, plano 2 en Figura 12).

    • Si esta comprobación de política pasa: el dispositivo busca rutas principales y de respaldo (interfaces ascendentes).

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

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

Funcionalidad de 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. Determinar el "LSR ascendente" de Uno en RFC 6388, extensiones de protocolo de distribución de etiquetas para rutas conmutadas de etiqueta de 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 separadas, una a cada par ascendente. El dispositivo utiliza el mismo algoritmo descrito en RFC 6388 para seleccionar la ruta de subida principal. El dispositivo utiliza el mismo algoritmo para seleccionar la ruta ascendente de respaldo, pero excluye el LSR ascendente principal como candidato. Los dos pares ascendentes diferentes envían dos flujos de tráfico MPLS al dispositivo de enrutamiento de salida. El dispositivo solo selecciona una de las rutas de vecino ascendentes como la ruta principal desde la cual se acepta el tráfico MPLS. La otra ruta se convierte en la ruta de respaldo y el dispositivo deja caer ese tráfico. Cuando se produce un error en la ruta ascendente principal, el dispositivo comienza a aceptar tráfico desde la ruta de respaldo. El dispositivo LDP multipunto selecciona las dos rutas ascendentes según el 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, a través de la misma ruta y con el mismo tratamiento de reenvío. Normalmente, la etiqueta que se coloca en un paquete determinado representa el FEC al que se asigna 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 bud es un LSR que es un LSR de salida, pero también tiene uno o más LSR descendentes conectados directamente. Para un nodo bud, 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 respaldo se reenvía al LSR descendente. Esto significa que el salto siguiente LSR descendente se agrega a ambas rutas MPLS junto con el salto siguiente de salida.

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

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

  • Las sesiones LDP de destino se omiten si hay una sesión LDP no segmentada. Si hay una sola sesión LDP de destino, se selecciona la sesión 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 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 según los últimos saltos siguientes del IGP. Si hay una mejor ruta disponible, LDP multipunto intenta cambiar a la mejor ruta.

Reenvío de paquetes

Para PIM o LDP multipunto, el dispositivo realiza la selección de secuencia 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, ya que:

  • Evita enviar secuencias duplicadas a través de la estructura

  • Evita varias búsquedas de rutas (que provocan 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 aquellas que provienen de la interfaz principal. Si la interfaz coincide con una interfaz de secuencia de respaldo, el dispositivo descarta los paquetes. Si la interfaz no coincide con la interfaz principal o de secuencia de respaldo, el dispositivo controla los paquetes como excepciones en el plano de control.

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

Figura 13: Búsqueda de ruta IP MoFRR en el motor de reenvío de paquetes en enrutadoresBúsqueda de ruta IP MoFRR en el motor de reenvío de paquetes en enrutadores
Figura 14: Manejo de ruta IP MoFRR en el motor de reenvío de paquetes en conmutadoresManejo de ruta 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 secuencia 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 descarta todos los demás. Varias interfaces pueden recibir paquetes con la misma etiqueta.

Figura 15 muestra este proceso para enrutadores con LDP multipunto.

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

Limitaciones y advertencias

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

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

  • La detección de fallas 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) en la ruta de tráfico de multidifusión.

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

  • No se admite la detección de las rutas ascendentes desarticuladas de extremo a extremo máximas. El dispositivo de enrutamiento del lado del receptor (salida) solo se asegura de que haya un dispositivo ascendente desarticulado (el salto anterior inmediato). Pim y LDP multipunto no admiten el equivalente de objetos de ruta explícitos (ERO). Por lo tanto, la detección de ruta ascendente desarticulada 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 que fluye.

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

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

  • MoFRR no se admite para secuencias de tráfico de multidifusión que utilizan dos grupos de multidifusión diferentes. Cada combinación (S,G) se trata como una secuencia de tráfico de multidifusión única.

  • El rango PIM bidireccional no se admite con MoFRR.

  • El modo denso PIM no se admite con MoFRR.

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

  • No se admite la supervisión de velocidad.

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), que afecta a otras funciones de multidifusión, como el protocolo de administración de grupos de Internet versión 3 (IGMPv3) de espionaje.

  • La replicación de paquetes y las búsquedas de multidifusión, mientras reenvía el tráfico de multidifusión, puede hacer que los paquetes se recirculan a través de pfEs varias veces. Como resultado, los valores mostrados para los recuentos de paquetes de multidifusión del show pfe statistics traffic comando pueden mostrar números más altos de los esperados en campos de salida como Input packets y Output packets. Es posible que observe este comportamiento con más frecuencia en escenarios de MoFRR, ya que las secuencias principales y de copia de seguridad 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:

  • El 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 MoFRR de aguas arriba mixtas. Esto se refiere a la señalización LDP en banda multipunto PIM, donde una ruta ascendente es a través de LDP multipunto y la segunda ruta ascendente es mediante PIM.

  • No se admiten etiquetas LDP multipunto como etiquetas internas.

  • Si el origen es accesible a través de varios dispositivos de enrutamiento de borde del proveedor (PE) de entrada (lado fuente), no se admite moFRR de LDP multipunto.

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

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

Configurar un reenrutamiento rápido solo de multidifusión

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

Cuando se aplica un reenrutamiento rápido a secuencias de unidifusión, un enrutador ascendente restablece previamente las rutas conmutadas por etiquetas (LSP) MPLS o precompute una ruta de copia de seguridad de reenrutamiento rápido sin bucle IP (LFA) para manejar fallas de un segmento en la ruta descendente.

En el enrutamiento de multidifusión, los gráficos de distribución de tráfico suelen ser originados por el receptor. Esto es diferente del enrutamiento de unidifusión, que normalmente establece la ruta desde el origen hasta el receptor. Los protocolos que son capaces de establecer gráficos de distribución de multidifusión son PIM (para IP), LDP 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 admiten esta función, a menos que se indique lo contrario. También se indican los pasos de configuración que no son aplicables al MoFRR de LDP multipunto.

(Solo para enrutadores serie MX) MoFRR se admite en enrutadores 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 filtros para un conjunto restringido de flujos de multidifusión que se verán afectados por la configuración de MoFRR.

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

    Por ejemplo:

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

    Por ejemplo:

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

    Esto no se admite para moFRR de LDP multipunto.

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

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

  7. (Opcional) En un dominio PIM con MoFRR, evite enviar 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 cambie cuando haya un cambio en la selección de unidifusión, en lugar de tener la ruta de respaldo promocionada como principal. Esto garantiza que el salto RPF principal siempre esté en la mejor ruta.

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

    Esto no se admite para moFRR de LDP multipunto.

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

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

El MoFRR de LDP multipunto se utiliza en el nodo de salida de una red MPLS, donde los paquetes se reenvían a una red IP. En el caso de MoFRR de LDP multipunto, se establecen las dos rutas hacia el enrutador de borde del proveedor ascendente (PE) 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 cae en el LER. La secuencia de copia de seguridad se acepta si se produce un error en la ruta principal.

Requisitos

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

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

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

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

Descripción general

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

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

Para fines de prueba, los enrutadores se utilizan para simular el origen y el receptor. Los dispositivos R4 y R8 se configuran para unirse estáticamente al grupo deseado mediante el set protocols igmp interface interface-name static group group comando. En el caso de que un host receptor de multidifusión real no esté disponible, como en este ejemplo, esta configuración IGMP estática es útil. En los receptores, para hacer que escuche 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 se explica por separado. La opción está configurada 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, luego, copie y pegue los comandos en la CLI en el [edit] nivel de jerarquía.

Dispositivo src1

Dispositivo src2

Dispositivo R1

Dispositivo R2

Dispositivo R3

Dispositivo R4

Dispositivo R5

Dispositivo R6

Dispositivo R7

Dispositivo R8

Configuración

Procedimiento

Procedimiento paso a paso

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

Para configurar el dispositivo R3:

  1. Habilite el modo IP mejorado.

  2. Configure las interfaces del dispositivo.

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

  4. Configure las políticas de enrutamiento.

  5. Configure PIM.

  6. Configure LDP.

  7. Configure una 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, confirme la configuración ingresando los show chassiscomandos , show interfaces, show protocols, show policy-optionsy show routing-options . Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.

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

Verificación

Confirme que la configuración funciona correctamente.

Comprobación de las clases de equivalencia de reenvío de punto a multipunto LDP

Propósito

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

Acción
Significado

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

Examinar la información de la etiqueta

Propósito

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

Acción
Significado

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

Comprobación de las rutas de multidifusión

Propósito

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

Acción
Significado

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

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

Propósito

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

Acción
Significado

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

Ejemplo: Configuración de LDP descendente a pedido

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

Los nodos descendentes podrían recibir potencialmente 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 mediante LDP descendente a pedido para solicitar solo los enlaces de etiquetas para las FEC correspondientes a las direcciones de circuito cerrado de esos nodos de salida en los que tiene servicios configurados.

Requisitos

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

  • Enrutador serie M

  • Junos OS 12.2

Descripción general

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

Configuración

Configuración de LDP descendente a pedido

Procedimiento paso a paso

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

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

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

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

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

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

Distribución de LDP aguas abajo en rutas a pedido en BGP etiquetado

Procedimiento paso a paso

Para distribuir las rutas LDP descendentes a pedido en bgp etiquetado, utilice una política de exportación del BGP.

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

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

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

Procedimiento paso a paso

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

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

  2. Configure la do-not-propagate-du-sessions política para que no reenvíe rutas a vecinos 1.1.1.1, 2.2.2.2y 3.3.3.3.

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

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

Resultados

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

Verificación

Verificar el modo de anuncio de etiquetas

Propósito

Confirme que la configuración funciona correctamente.

Utilice el show ldp session comando para comprobar el estado del modo de anuncio de etiqueta para la sesión de 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 de LDP descendente a pedido es operativa):

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

Configuración de soporte IPv6 nativo de LDP

El LDP se admite en una red de solo IPv6 y en una red de pila doble IPv6 o IPv4 como se describe en RFC 7552. Configure la familia de direcciones como inet para IPv4 o inet6 IPv6 o ambos, y la preferencia de transporte sea o IPv6IPv4 . La dual-transport instrucción permite que Junos OS LDP 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. Los inet-lsr-id IDs y inet6-lsr-id los dos LSR son los que se deben configurar para establecer una sesión LDP a través del transporte TCP IPv4 e IPv6. Estos dos IDs 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 de IPv6 de LDP, debe hacer lo siguiente:

  1. Habilite la desagregación de la clase de equivalencia de reenvío (FEC) para usar diferentes etiquetas para diferentes familias de direcciones.
  2. Configure familias de direcciones LDP.
  3. Configure la transport-preference instrucción para seleccionar el transporte preferido para la conexión TCP cuando se habilitan IPv4 e IPv6. De forma predeterminada, IPv6 se utiliza como transporte TCP para establecer una conexión LDP.
  4. (Opcional) Configure el transporte dual para permitir que el 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 soporte 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 sobre IPv6 con vecinos IPv6 como un LSR de una sola pila. Esto ayuda a evitar la tunelización del núcleo MPLS IPv6 a través de IPv4 con rutas MPLS conmutadas por etiquetas (LSP) señaladas 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 que se ejecuta 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

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

Topología

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

Figura 17: Soporte de IPv6 nativo de LDP de ejemplo Soporte de IPv6 nativo de LDP de ejemplo

Configuración

Configuración rápida de CLI

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

R1

R2

Configuración de R1

Procedimiento paso a paso

En el ejemplo siguiente, se requiere navegar por varios niveles en la jerarquía de configuración. Para obtener más información sobre 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 la clase de equivalencia de reenvío (FEC) para usar diferentes etiquetas para diferentes familias de direcciones.

  6. Configure familias de direcciones LDP.

Resultados

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

Configure la preferencia de transporte para seleccionar el transporte preferido

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

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

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

Procedimiento paso a paso
Resultados

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

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

Procedimiento paso a paso

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

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

Resultados

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

Verificación

Confirme que la configuración funciona correctamente.

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

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

Acción

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

Significado

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

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

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

Acción

En el dispositivo R1, desde el modo operativo, ejecute el show route table inet.3 comando para mostrar 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 ruta inet6.3.

Verificar la base de datos de LDP
Propósito

Muestra 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 información de base de datos LDP.

Significado

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

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

Muestra la información del vecino 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 LDP.

Significado

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

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

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

Acción

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

Significado

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

Verificación

Confirme que la configuración funciona correctamente.

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

Muestra la información del vecino LDP.

Acción

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

Significado

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

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

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

Acción

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

Significado

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

Verificación

Confirme que la configuración funciona correctamente.

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

Muestra la información del vecino LDP.

Acción

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

Significado

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

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

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

Acción

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

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

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

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

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

Sin embargo, en una red IP/MPLS existente, es posible que la implementación de PIM no sea 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 funciones de ingeniería y protección de 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 las implementaciones 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 implementación se discuten en RFC 6826, Señalización en banda LDP multipunto para rutas conmutadas de etiqueta de punto a multipunto y multipunto a multipunto. Esta descripción general de funciones se limita a extensiones de punto a multipunto para LDP.

Cómo funciona M-LDP

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

La extensión multipunto a LDP utiliza elementos de clase de equivalencia de reenvío de punto a multipunto y multipunto a multipunto (FEC) (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 enlace de etiqueta entrante local 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 sus propias interfaces de salida y etiqueta local. Este proceso de asignación de etiquetas puede dar como resultado la replicación de paquetes, si hay varias sucursales salientes. Como se muestra en Figura 18, un nodo LDP fusiona los enlaces de etiquetas para el mismo valor opaco si encuentra nodos descendentes que comparten el mismo nodo ascendente. Esto permite la construcción eficaz de LSP de punto a multipunto y 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 despliegue horizontal. Dos dominios PIM independientes están interconectados por un sitio central sin PIM. Los enrutadores de borde de este sitio central admiten PIM en las interfaces de borde. Además, estos enrutadores de borde recopilan y distribuyen la información de enrutamiento de los sitios adyacentes a la red central. Los enrutadores de borde 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, ya que en la mayoría de los casos el próximo 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 de banda M-LDP tiene una asignación uno a uno entre el LSP de punto a multipunto y el flujo (S,G). Con la señalización en banda, los mensajes PIM se traducen directamente 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 de banda M-LDP es transportar tráfico de multidifusión IPTV en una red troncal MPLS.

Figura 19: Topología M-LDP de ejemplo en núcleo MPLS sin PIMTopología M-LDP de ejemplo 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 ascendente pim. La configuración estática de la raíz LSP MPLS se incluye en la configuración PIM mediante la política. Esto se necesita cuando IBGP no está disponible en el sitio central o para reemplazar 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 IPTV existentes de multidifusión IP nativa a multidifusión MPLS, debe pasar sin problemas de PIM a LSP de punto a multipunto M-LDP con una interrupción mínima. Figura 20 muestra una topología M-LDP similar como Figura 19, pero con un escenario diferente. El núcleo se habilita con PIM, con una sola fuente que transmite todos los canales IPTV. Los canales de TV se envían como secuencias asm con cada canal identificado por su dirección de grupo. Anteriormente, estos canales se transmitían en el núcleo como flujos IP y se señalizaban mediante PIM.

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

Al configurar el en este escenario, la mldp-inband-signaling señalización M-LDP se inicia solo cuando no hay ningún 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 a núcleo MPLS M-LDP con pocas secuencias mediante M-LDP ascendente y otras secuencias con 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 de banda M-LDP.

Nota:

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

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. Configurar la selected-mldp-egress instrucción en enrutadores PIM que no son de salida puede provocar errores de configuración de ruta.

  • Cuando se realizan cambios en la política para conmutar el tráfico de PIM ascendente a M-LDP ascendente y viceversa, se puede esperar pérdida de paquetes mientras se realiza un mecanismo de interrupción y realizació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 multidifusión.

LSP punto a punto

Un LSP que tiene un enrutador conmutado por etiqueta de entrada (LSR) y un LSR de salida.

LSP multipunto

Ya sea un LSP de punto a multipunto o de multipunto a multipunto.

LSP punto a multipunto

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

LSP multipunto a punto

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

LSP multipunto a multipunto

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

LSR de entrada

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 multipunto a multipunto pueden tener varios LSR de entrada. Los LSP de punto a multipunto solo tienen uno, y ese nodo suele denominarse nodo raíz.

LSR de salida

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

LSR de tránsito

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

Bud LSR

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

Nodo leaf

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

Traducción de unión de entrada y manejo de pseudo interfaces

En el LER de entrada, el 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 pseudo interfaz. Posteriormente, se inicia un mensaje de unión de árbol de ruta más corta (SPT) hacia el origen. PIM trata esto como un nuevo tipo de receptor local. Cuando se derriba el LSP, PIM quita este receptor local según la notificación del LDP.

Empalme de entrada

LDP proporciona a PIM un salto siguiente que se asociará a 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 salto siguiente compuesto de receptores locales + la lista de vecinos descendentes PIM + un salto siguiente 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 el origen.

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

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

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

Pim RPF registra esta dirección de origen cada vez que cambia la información de enrutamiento de unidifusión. Por lo tanto, si cambia la ruta hacia el origen, el recálculo de RPF vuelve a ocurrir. Los próximos saltos del protocolo BGP hacia el origen también se supervisan para los cambios en la raíz LSP. Estos cambios pueden causar interrupciones del tráfico durante breves períodos.

Detección de raíz LSP

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

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

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

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

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

    Es necesario que estos LSP de punto a multipunto no segmentados se señalen en varios sistemas autónomos, los cuales se pueden utilizar para las siguientes aplicaciones:

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

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

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

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

Traducción de unión de salida y manejo de pseudo interfaces

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

Empalme de salida

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

Funcionalidad compatible

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

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

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

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

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

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

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

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

  • IGMP se une a los mensajes en los INDICADORES

  • 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 una 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 interrupción (NSR)

  • Make-before-break (MBB) para PIM

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

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

  • Reinicio correcto

  • Modo pim denso

  • Modo bidireccional PIM

Funcionalidad de LDP

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

Funcionalidad de LER de salida

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

  • Nodo raíz

  • (S,G)

  • Siguiente salto

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

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

Si cambian las direcciones raíz para el 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 de salida se convierte en NULL, PIM activa LDP para eliminar el LSP de punto a multipunto, y LDP envía un mensaje de retirada de etiquetas al nodo ascendente.

Funcionalidad de LSR de tránsito

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

Funcionalidad de LER de entrada

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

  • (S,G)

  • Próximo salto de inundación

A continuación, PIM instala el estado de reenvío. Si se agregan o eliminan las nuevas sucursales, el siguiente salto de inundación se actualiza en consecuencia. Si se eliminan todas las sucursales 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 de punto a multipunto no está equilibrado de carga.

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

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

Requisitos

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

  • Junos OS versión 13.2 o posterior

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

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

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

Nota:

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

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

Descripción general

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

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

Dispositivo src1

Entrada de dispositivo

Salida del dispositivo

Dispositivo p6

Dispositivo pr3

Dispositivo pr4

Dispositivo pr5

Procedimiento paso a paso

En el ejemplo siguiente, debe navegar 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 el modo de configuración en la Guía del usuario de la CLI.

Para configurar la salida del dispositivo:

  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 el IGMP en las interfaces de salida.

    Para fines de prueba, este ejemplo incluye direcciones de origen y grupo estáticos.

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

  4. Configure BGP.

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

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

  5. (Opcional) Configure una conexión par MSDP con el dispositivo pr5 para interconectar los dominios PIM dispares, habilitando así LOS 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 de punto a multipunto.

  9. Configure PIM en las interfaces descendentes.

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

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

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

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

Resultados

Desde el modo de configuración, confirme la configuración ingresando los show interfacescomandos , show protocols, show policy-optionsy show routing-options . Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.

Salida del dispositivo

Del mismo modo, configure los otros dispositivos de salida.

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

Verificación

Confirme que la configuración funciona correctamente.

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

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

Acción

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

Comprobación de las fuentes PIM
Propósito

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

Acción

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

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

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

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

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

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

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

Acción

Servidor de asignación de LDP para interoperabilidad del enrutamiento por segmentos con descripción general de LDP

En una red LDP con despliegue gradual de enrutamiento por segmentos, puede haber islas de dispositivos que admitan solo LDP o solo enrutamiento por segmentos. Para que los dispositivos intertraviesen, se requiere que la función de servidor de asignación de LDP se configure en cualquier dispositivo de la red de enrutamiento por segmentos.

La función de servidor de asignación LDP se implementa mediante OSPF o ISIS.

Interoperabilidad del enrutamiento por segmentos con LDP mediante OSPF

Para implementar la interoperabilidad del enrutamiento por segmentos con LDP mediante OSPF, se genera un anuncio de estado de vínculo (LSA) de prefijo extendido con tipo de rango, longitud y valor (TLV) para todos los prefijos LDP, y las rutas de asignación correspondientes al prefijo se instalan en las tablas de enrutamiento inet.3 y mpls.0.

Figura 22 es una topología de red LDP simple que se utiliza para ilustrar la interoperabilidad de los dispositivos de enrutamiento por segmentos con dispositivos LDP que utilizan OSPF. La topología tiene seis dispositivos (dispositivos R1, R2, R3, R4, R5 y R6) con migración de enrutamiento LDP a segmento.

Figura 22: Topología de LDP de ejemplo con interoperabilidad del enrutamiento por segmentos con LDP mediante OSPFTopología de LDP de ejemplo con interoperabilidad del enrutamiento por segmentos con LDP mediante OSPF

En la topología anterior, los dispositivos R1, R2 y R3 solo son capaces de enrutamiento por segmentos, los dispositivos R5 y R6 solo son capaces de LDP, y el dispositivo R4 admite tanto LDP como enrutamiento por segmentos. Aquí, el dispositivo R1 no puede trabajar con el dispositivo R6 debido a problemas de interoperabilidad.

Para habilitar la interoperabilidad entre los dispositivos compatibles con LDP y los dispositivos de enrutamiento por segmentos, cualquier interfaz del dispositivo en el segmento de red de enrutamiento por segmentos se configura como el servidor de asignación de LDP. Actualmente, el servidor de asignación configura prefijos bajo el [edit routing-options source-packet-routing] nivel de jerarquía. Con esta característica, OSPF anuncia la configuración del servidor de asignación de LDP si se aplica bajo el [edit protocols ospf] nivel jerárquico, donde OSPF anuncia un nuevo prefijo extendido LSA con intervalo TLV para todos los prefijos LDP. El dispositivo capaz de enrutamiento por segmentos analiza el intervalo de prefijo extendido TLV y las rutas de asignación correspondientes al prefijo se instalan en las tablas de enrutamiento inet.3 y mpls.0.

Por ejemplo, en Figura 22, si el dispositivo R2 (en la red de enrutamiento por segmentos) es el servidor de asignación de LDP, se incluye la siguiente configuración:

Nota:

La dirección IP utilizada como start-prefix la es la dirección de circuito cerrado del dispositivo en la red LDP (dispositivo R5, en este ejemplo).

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

A partir de Junos OS versión 19.1R1, el enrutador de borde LDP de enrutamiento por segmentos puede unir el tráfico de enrutamiento por segmentos al salto siguiente de LDP y viceversa.

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

  • El conflicto de prefijo solo se detecta en la configuración de origen. Cuando hay un conflicto de intervalo de prefijos, prevalece el SID del prefijo del ID de enrutador inferior. En estos casos, se genera un mensajeRPD_OSPF_PFX_SID_RANGE_CONFLICT de error de registro del sistema.

  • No se admiten prefijos IPv6.

  • No se admite la inundación del prefijo extendido OSPF LSA opaco generado por el servidor de asignación de enrutamiento por segmentos para sistemas autónomos (AS).

  • No se admite el servidor de asignación de LDP entre áreas.

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

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

  • No se admite la preferencia TLV del servidor de asignación de enrutamiento por segmentos.

Interoperabilidad del enrutamiento por segmentos con LDP mediante ISIS

Para implementar la interoperabilidad del enrutamiento por segmentos con LDP mediante ISIS, se requiere una configuración de cliente de servidor en los protocolos ISIS y LDP, respectivamente, y las rutas de las tablas de enrutamiento inet.3 o inet.0 se utilizan para unir el LSP de enrutamiento por segmentos con un LSP LDP y viceversa.

Figura 23 es una topología de red LDP simple que se utiliza para ilustrar la interoperabilidad de los dispositivos de enrutamiento por segmentos con dispositivos LDP mediante una función de asignación de LDP servidor-cliente. La topología tiene cuatro dispositivos de borde de proveedor (PE) (dispositivos PE1, PE2, PE3 y PE4) y cuatro dispositivos de proveedor (P) (dispositivos P5, P6, P7 y P8).

Figura 23: Topología de LDP de ejemplo con interoperabilidad del enrutamiento por segmentos con LDP mediante ISISTopología de LDP de ejemplo con interoperabilidad del enrutamiento por segmentos con LDP mediante ISIS

Los dispositivos PE3, PE4, P6, P7 y P8 son los dispositivos compatibles con LDP. Los dispositivos PE1, PE2, P5 y P6 son capaces de enrutamiento por segmentos con un valor de bloque global de enrutamiento por segmentos (SRGB) de 100 y 200, y un valor de IDs de segmento de nodo (SID) de 101, 102,105 y 106, respectivamente.

Para que un flujo de servicio se tunelización hacia y desde el dispositivo PE3 y el dispositivo PE1 mediante un túnel MPLS continuo, las islas de dispositivos que admiten enrutamiento por segmentos y LDP deben interoperar.

LDP Mapping Client Functionality (LDP to Segment Routing)

La funcionalidad del cliente LDP es la asignación de enrutamiento de LDP a segmentos, que es el flujo de tráfico de derecha a izquierda en Figura 23. En el dispositivo P6, se configura una política de salida de LDP para anunciar todos los SID de nodo y los SID de prefijo de la red de enrutamiento de segmentos de la izquierda. Como resultado, en el dispositivo P6, el LDP anuncia los dispositivos PE1, PE2 y P5 como enlaces de etiqueta FEC de salida al dispositivo P7.

El dispositivo PE3 aprendió una ruta de servicio con el dispositivo PE1 como el próximo salto del protocolo. El dispositivo PE3 tiene un enlace de etiqueta LDP del salto siguiente P8 para el FEC PE1. Como resultado, el dispositivo PE3 envía su paquete de servicio al dispositivo P8 según el comportamiento clásico de LDP. El dispositivo P8 tiene un enlace de etiqueta LDP de su salto siguiente P7 para el FEC PE1, por lo tanto, el dispositivo P8 reenvía al dispositivo P7 según el comportamiento clásico de LDP.

El dispositivo P7 tiene un enlace de etiqueta LDP de su salto siguiente P6 el FEC PE1, como resultado, el dispositivo P7 reenvía al dispositivo P6 según el comportamiento clásico de LDP.

El dispositivo P6que actúa como salida LDP para el FEC pe1, une e intercambia la etiqueta LDP de salida entrante para el FEC PE1 con un NODO de enrutamiento por segmentos equivalente SID (101 en este ejemplo) para reenviar el tráfico al dispositivo P5.

El dispositivo P5 extrae 101 SID suponiendo que el dispositivo PE1 anunciaba su segmento de nodo 101 con el penúltimo conjunto de indicadores emergentes y, luego, reenvía el tráfico al dispositivo PE1. El dispositivo PE1 recibe el paquete tunelización y procesa la etiqueta de servicio.

Como resultado, el túnel MPLS de extremo a extremo se construye desde un LSP LDP del dispositivo PE3 al dispositivo P6, y el segmento de nodo relacionado del dispositivo P6 al dispositivo PE1.

LDP Mapping Server Functionality (Segment Routing to LDP)

La funcionalidad del servidor LDP es la asignación del enrutamiento por segmentos a LDP, que es el flujo de tráfico de izquierda a derecha en Figura 23. En el dispositivo P6, la configuración de los prefijos del servidor de asignación se incluye en el [edit routing-options source-packet-routing] nivel jerárquico. Cuando se aplica la configuración en el IGP específico, el tipo de enlace de etiquetas, la longitud y el valor (TLV) para todos los enlaces de etiqueta FEC de LDP de la red LDP se anuncian como rutas LDP inet.3.

Aquí, el dispositivo P6 actúa como un servidor de asignación de enrutamiento por segmentos (SRMS) y anuncia las siguientes asignaciones: (P7, 107), (P8, 108), (PE3, 103), (PE4, 104) y (P7, 107). Si se admite el enrutamiento por segmentos en el dispositivo PE3, el nodo SID 103 se hubiera configurado en el dispositivo PE3. Dado que el dispositivo PE3 no admite enrutamiento por segmentos, la política se configura en el SRMS del dispositivo P6 y el dispositivo P6 es responsable de anunciar las asignaciones.

Estos anuncios de servidor de asignación solo se entienden por los dispositivos de enrutamiento por segmentos. Los dispositivos de enrutamiento por segmentos instalan los SID de nodo relacionados en el plano de datos MPLS exactamente cómo los propios nodos anunciaron los segmentos de nodo. Por ejemplo, el dispositivo PE1 instala el NODO SID 103 con el salto siguiente P5 exactamente como si el dispositivo PE3 hubiera anunciado SID 103.

El dispositivo PE1 tiene una ruta de servicio con PE3 como próximo salto de protocolo. El dispositivo PE1 tiene un segmento de nodo para esa ruta IGP: 103 con el salto siguiente P5. Como resultado, el dispositivo PE1 envía su paquete de servicio al dispositivo P5 con dos etiquetas: la etiqueta inferior, que es la etiqueta de servicio, y la etiqueta superior, que es SID 103. El dispositivo P5 cambia 103 por 103 y se reenvía al dispositivo P6. El siguiente salto para el dispositivo P6 es la ruta IGP PE3, que no es capaz de enrutamiento por segmentos. (El dispositivo P7 no anuncia la capacidad de enrutamiento por segmentos). Sin embargo, el dispositivo P6 tiene un enlace de etiqueta LDP de ese salto siguiente para el mismo FEC (por ejemplo, la etiqueta LDP 1037). Como resultado, en el dispositivo P6, el IGP intercambia 103 por 1037 y reenvía al dispositivo P7.

El dispositivo P7 intercambia esta etiqueta con la etiqueta LDP recibida del dispositivo P8 y, luego, la reenvía al dispositivo P8. El dispositivo P8 extrae la etiqueta LDP y se reenvía al dispositivo PE3.

El dispositivo PE3 recibe el paquete tunelización y procesa la etiqueta de servicio. El túnel MPLS de extremo a extremo se construye a partir de un nodo de enrutamiento por segmentos de los dispositivos PE1 a P6, y un LSP LDP de los dispositivos P6 a PE3.

Segment Routing to LDP Stitching

Cuando el salto siguiente ip del enrutamiento por segmentos IGP del LSP no admite el enrutamiento por segmentos, el IGP mira la tabla de enrutamiento inet.3 para ver si hay un LSP LDP en el mismo prefijo. Si el LDP LSP está presente, el IGP une el LSP de enrutamiento por segmentos al LSP LDP programando una ruta de tránsito MPLS que intercambia la etiqueta de enrutamiento por segmentos con la etiqueta LDP para cambiar el tráfico del dominio de enrutamiento por segmentos al dominio LDP.

Figura 24 ilustra la unión del enrutamiento por segmentos y LSP LDP para permitir la interoperabilidad.

Figura 24: Unir enrutamiento por segmentos y LSP LDPUnir enrutamiento por segmentos y LSP LDP

En la topología, el dispositivo PE3 es compatible con LDP y no admite enrutamiento por segmentos. El servidor de asignación en el dominio de enrutamiento por segmentos puede anunciar TLV de enlace de etiquetas para los dispositivos P7, P8 y PE4. En tal caso, el dispositivo PE1 puede tener el prefijo SID y el enlace remoto de etiquetas TLV y SID para llegar al dispositivo PE4. Sin embargo, el dispositivo PE1 prefiere el prefijo SID a TLV de enlace remoto de etiquetas mientras programa su ruta de enrutamiento por segmentos de entrada para el dispositivo PE4. Como resultado, el dispositivo PE1 utiliza el enrutamiento por segmentos LSP de extremo a extremo para enviar tráfico al dispositivo PE4, y utiliza la unión de enrutamiento por segmentos a LDP mientras envía tráfico al dispositivo PE3.

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

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

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

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

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

  • No se admite el enrutamiento activo sin interrupción (NSR) y la conmutación agraciada del motor de enrutamiento (GRES).

  • No se admite el internivel de ISIS.

  • Rfc 7794, atributos de prefijo IS-IS para IPv4 extendido no se admite.

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

Configuración de propiedades de LDP varios

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

Configuración de LDP para usar la métrica de ruta de 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 utilice 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 IGP, incluya la track-igp-metric instrucción:

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

Prevención de 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 se agreguen rutas de entrada a la tabla de enrutamiento inet.0 en lugar de la tabla de enrutamiento inet.3, incluso si ha habilitado la traffic-engineering bgp-igp instrucción en el [edit protocols mpls] nivel de jerarquía o [edit logical-systems logical-system-name protocols mpls] . De forma predeterminada, la no-forwarding instrucción está deshabilitada.

Nota:

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

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

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

VPN de LDP y operadora de operadoras de varias instancias

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

Configuración de MPLS y LDP para hacer estallar la etiqueta en el enrutador ultimate-hop

La etiqueta anunciada predeterminada es la etiqueta 3 (etiqueta Null implícita). Si se anuncia la etiqueta 3, el penúltimo enrutador de salto elimina la etiqueta y envía el paquete al enrutador de salida. Si está habilitada la opción ultimate-hop popping, se anuncia la etiqueta 0 (etiqueta IPv4 Explicit Null). El salto final garantiza que todos los paquetes que atraviesan una red MPLS incluyan una etiqueta.

Para configurar ultimate-hop popping, incluya la explicit-null instrucción:

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

Nota:

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

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

Habilitación del LDP sobre LSP establecidos por RSVP

Usted puede ejecutar el LDP sobre los 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 Habilitar y deshabilitar LDP). También debe configurar los LSP sobre los que desea que el LDP funcione incluyendo la ldp-tunneling instrucción en el [edit protocols mpls label-switched-path lsp-name] nivel de jerarquía:

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

Habilitación de LDP sobre LSP establecidos por RSVP en redes heterogéneas

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

Cuando un enrutador de Juniper Networks está vinculado al enrutador de otro proveedor mediante un túnel RSVP y la tunelización de LDP también está habilitada, de forma predeterminada, es posible que el enrutador de Juniper Networks no utilice el túnel RSVP para enrutar el tráfico a los destinos LDP descendentes 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 garantizar que la tunelización LDP funcione correctamente en redes heterogéneas, puede configurar OSPF para que ignore la métrica LSP de RSVP incluyendo la ignore-lsp-metrics instrucción:

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

  • [edit protocols ospf traffic-engineering shortcuts]

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

Nota:

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

Para habilitar LDP a través de LSVP de RSVP, también debe completar el procedimiento en sección Habilitación del LDP sobre LSP establecidos por RSVP.

Configuración de la firma TCP MD5 para sesiones de LDP

Puede configurar una firma MD5 para una conexión TCP LDP para protegerse de la introducción de segmentos TCP suplantados en flujos de conexión de sesión LDP.

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

Todavía se pueden crear adyacencias de saludo LDP 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.

A partir de la versión 16.1R1 de Junos OS, la compatibilidad con el código de autenticación de mensajes hash (HMAC) y la autenticación MD5 para sesiones LDP se extiende de una configuración por sesión a una configuración de coincidencia de subred (es decir, la configuración de prefijo-coincidencia más larga).

La compatibilidad con la autenticación de coincidencia de subred ofrece flexibilidad para configurar la autenticación para sesiones de LDP (TLDP) de destino automático, lo que facilita el despliegue de pseudocables alternativos sin circuito remoto (LFA) y FEC 129.

Para configurar una firma MD5 para una conexión TCP LDP, incluya la session-group instrucción and authentication-key :

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

La md5-authentication-key (contraseña) puede tener hasta 69 caracteres. Los caracteres pueden incluir cualquier cadena ASCII. Si incluye espacios, incluya todos los caracteres entre comillas.

También puede configurar un mecanismo de actualización de clave de autenticación para el protocolo de enrutamiento LDP. Este mecanismo le permite actualizar las claves de autenticación sin interrumpir los protocolos de enrutamiento y señalización asociados, como 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 de crear un cadena de claves que consta de varias claves de autenticación.

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

Para obtener más información acerca de la función de actualización de clave de autenticación, consulte Configurar el 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 de LDP

Normalmente, se crea una sesión de LDP entre un par de enrutadores conectados por uno o más vínculos. Los enrutadores forman una adyacencia de saludo para cada vínculo 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 LDP, se termina la sesión LDP. Es posible que desee modificar este comportamiento para evitar que una sesión de LDP se termine y restablezca innecesariamente.

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

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

Deshabilitar trampas SNMP para LDP

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

Para obtener información acerca de las trampas SNMP de LDP y el MIB de LDP patentado, consulte SNMP MIB Explorer..

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

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

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

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

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

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

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

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

Configuración de 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 LDP y la sesión para una interfaz son operativos. En el caso de redes grandes con numerosas FEC, es posible que deba configurar un valor más largo para permitir el tiempo suficiente para que se intercambien las bases de datos de etiquetas LDP.

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

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

Configuración del temporizador de retirada de etiquetas

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

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

De forma predeterminada, el LDP espera 60 segundos antes de retirar las etiquetas para evitar renunciar a los LSP varias veces mientras el IGP está reconvergiendo. Para configurar el tiempo de retraso de retirada de etiquetas 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, consulte la sección de resumen de instrucciones para esta instrucción.

Ignorar la comprobación de subred LDP

En la versión 8.4 y versiones posteriores de Junos OS, se realiza una comprobación de subred de dirección de origen LDP durante el procedimiento de establecimiento vecino. La dirección de origen en el paquete de saludo del vínculo LDP se hace coincidir con la dirección de interfaz. Esto causa un problema de interoperabilidad con algunos 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 serie ACX no admiten el nivel de jerarquía [edit logical-systems].

Configuración del traceroute LDP LSP

Puede rastrear la ruta seguida de un LSP con señal LDP. El traceroute LDP LSP se basa en RFC 4379, detectando errores de plano de datos conmutados por etiquetas multi protocol (MPLS). Esta función le permite rastrear periódicamente todas las rutas en un FEC. La información de topología de FEC se almacena en una base de datos accesible desde la CLI.

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

La función de traceroute periódica se aplica a todas las FEC especificadas por la oam instrucción configurada en el [edit protocols ldp] nivel de jerarquía. Para configurar el traceroute LSP periódico 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 por sí misma o con cualquiera de las siguientes opciones:

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

  • fanout: especifique el número máximo de saltos siguientes que se buscarán por nodo.

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

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

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

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

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

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

Recopilación de estadísticas de LDP

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

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

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

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

Esta sección incluye los siguientes temas:

Resultados de estadísticas de LDP

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

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

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

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

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

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

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

  • 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 mostrarse.

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

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

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

Nota:

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

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

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

Limitaciones de 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, solo se emite una nueva solicitud de estadísticas LDP si el temporizador de estadísticas caduca más tarde que el intervalo nuevo.

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

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

Seguimiento del tráfico de protocolo LDP

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

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

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

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

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

Las siguientes marcas 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: trace la operación de los mensajes de retirada de direcciones y direcciones.

  • binding: operaciones de enlace de etiquetas de seguimiento.

  • error: condiciones de error de seguimiento.

  • event: eventos de protocolo de seguimiento.

  • initialization: trace la operación de los mensajes de inicialización.

  • label: trace el funcionamiento de la solicitud de etiquetas, el mapa de etiquetas, el retiro de etiquetas y los mensajes de liberación de etiquetas.

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

  • packets: trace la operación de dirección, retirada de direcciones, inicialización, solicitud de etiquetas, mapa de etiquetas, retirada de etiquetas, liberación de etiquetas, notificación y mensajes periódicos. Este modificador es equivalente a establecer los addressmodificadores , initialization, label, notificationy periodic .

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

  • path: trace las operaciones de ruta conmutada por etiquetas.

  • path: trace las operaciones de ruta conmutada por etiquetas.

  • periodic: trace la operación de los mensajes de saludo y keepalive.

  • route: trace la operación de los mensajes de ruta.

  • state— Transiciones de estado de protocolo de seguimiento.

Rastreo del tráfico de protocolo LDP dentro de 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, ya que cada enrutador elige la etiqueta anunciada por el próximo salto para el FEC y la une a la etiqueta que anuncia a todos los demás enrutadores.

Puede rastrear el tráfico de protocolo LDP dentro de un FEC específico y filtrar instrucciones de seguimiento LDP basadas en un FEC. Esto es útil cuando desea rastrear o solucionar problemas del tráfico de protocolo LDP asociado con un FEC. Las siguientes marcas de seguimiento están disponibles para este propósito: route, pathy binding.

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

Esta función tiene las siguientes limitaciones:

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

  • No se pueden filtrar los FEC de circuito de capa 2.

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

  • El filtrado lo determina la política y el valor configurado para la match-on opción. Cuando configure la política, asegúrese de que el comportamiento predeterminado es siempre reject.

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

Ejemplos: Seguimiento del tráfico de protocolo LDP

Trace los mensajes de ruta de LDP en detalle:

Trace todos los mensajes salientes de LDP:

Trace todas las condiciones de error de LDP:

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

Trace el tráfico del protocolo LDP para una FEC asociada con el LSP:

Tabla de historial de versiones
Liberación
Descripción
19.1
A partir de Junos OS versión 19.1R1, el enrutador de borde LDP de enrutamiento por segmentos puede unir el tráfico de enrutamiento por segmentos al salto siguiente de LDP y viceversa.
16.1R1
A partir de la versión 16.1R1 de Junos OS, la compatibilidad con el código de autenticación de mensajes hash (HMAC) y la autenticación MD5 para sesiones LDP se extiende de una configuración por sesión a una configuración de coincidencia de subred (es decir, la configuración de prefijo-coincidencia más larga).
16.1
A partir de la versión 16.1 de Junos OS, M-LDP puede indicar LSP de punto a multipunto en ASBR o tránsito o salida cuando la dirección raíz es una ruta BGP que se resuelve de forma recursiva mediante un LSP MPLS.
14.1
A partir de Junos OS versión 14.1, para migrar los servicios IPTV existentes de multidifusión IP nativa a multidifusión MPLS, debe pasar sin problemas de PIM a LSP de punto a multipunto M-LDP con una interrupción mínima.