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 LDP mínima

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

  1. Activar todas las interfaces relevantes de la familia MPLS. En el caso de LDP dirigida, es necesario activar la interfaz de bucle invertido con la familia MPLS.

  2. Adicional Configure las interfaces relevantes bajo [edit protocol mpls] el nivel de jerarquía.

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

Ésta es la configuración de LDP mínima. Todas las demás instrucciones de configuración de LDP son opcionales.

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

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

Habilitación y deshabilitación de LDP

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

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

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

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

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

Configurar el temporizador LDP para mensajes de saludo

Los mensajes de saludo de LDP permiten que los nodos LDP se detecten uno a otro y detectar el fallo de un vecino o el vínculo al vecino. Los mensajes de saludo se envían periódicamente en todas las interfaces en las que está habilitado LDP.

Hay dos tipos de mensajes de saludo LDP:

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

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

De forma predeterminada, LDP envía mensajes de saludo cada 5 segundos para los mensajes de saludo del vínculo y cada 15 segundos para los mensajes de saludo de destino. 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 mayor que el tiempo de conservación de LDP. Para obtener más información, vea configurar el retraso para que los vecinos de LDP se consideren inactivos.

Configuración del temporizador LDP para mensajes de saludo de vinculación

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

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

Configurar el temporizador LDP para los mensajes de saludo de destino

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

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

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

El tiempo de retención determina durante cuánto tiempo debe esperar un nodo LDP a un mensaje de saludo antes de declarar un vecino para que sea inactivo. Este valor se envía como parte de un mensaje de saludo para que cada nodo LDP indique a sus vecinos el tiempo de espera. Los valores que envía cada vecino no tienen que coincidir.

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

Nota:

Si configura un tiempo de conservación de LDP cerca del intervalo de saludo (menos de tres veces el intervalo de saludo), es posible que se detecten más rápidamente los errores de LDP Neighbor. Sin embargo, esto también aumenta la posibilidad de que el enrutador pueda declarar un vecino LDP hacia abajo que sigue funcionando con normalidad. Para obtener más información, vea configurar el temporizador LDP para mensajes de saludo.

El tiempo de conservación de LDP también se negocia automáticamente entre los homólogos de los elementos LDP. Cuando dos homólogos LDP anuncian diferentes tiempos de retención de LDP entre sí, se utiliza el menor valor. Si un enrutador par LDP anuncia un tiempo de espera menor que el valor que configuró, se utilizará el tiempo de espera anunciado del enrutador par. Esta negociación también puede afectar al intervalo de KeepAlive LDP.

Si no se acorta la hora de conservación de LDP local durante la negociación de homólogos de LDP, el intervalo de KeepAlive configurado por el usuario permanece sin cambios. Sin embargo, si se reduce el tiempo de conservación local durante la negociación del mismo nivel, se vuelve a calcular el intervalo de KeepAlive. Si se ha reducido el tiempo de conservación de LDP durante la negociación del mismo nivel, el intervalo de KeepAlive se reduce a un tercio del nuevo valor de hora de retención. Por ejemplo, si el nuevo valor de tiempo de retención es 45 segundos, el intervalo de KeepAlive se establece en 15 segundos.

Este cálculo automatizado del intervalo de KeepAlive puede hacer que se configuren varios intervalos de KeepAlive en cada enrutador del mismo nivel. Esto permite que los enrutadores sean flexibles en cuanto a la frecuencia con la que envían mensajes de actividad, ya que la negociación de homólogos de LDP garantiza que se envían con más frecuencia que la hora de conservación de LDP.

Cuando se vuelve a configurar el intervalo de tiempo de suspensión, los cambios no surten efecto hasta después de restablecerse la sesión. El tiempo de espera se negocia cuando se inicia la sesión de emparejamiento de LDP y no se puede renegociar mientras la sesión esté activa (obligatorio por RFC 5036, Especificación LDP). Para forzar de forma manual a que se restablezca la clear ldp session sesión LDP, ejecute el comando.

Configuración de la hora de conservación de LDP para mensajes de saludo de vínculo

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

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

Configuración de la hora de conservación de LDP para mensajes de saludo dirigidos

Para modificar el tiempo que un nodo LDP debe esperar un mensaje de saludo de destino antes de declarar el vecino desactivado, especifique una nueva hora hold-time en segundos usando la instrucción como targeted-hello una opción para la instrucción:

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

Habilitación de mensajes de saludo de destino estrictos para LDP

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

  • Puntos de conexión de túneles RSVP para los que está configurado el túnel LDP

  • vecinos de circuito de capa 2

Si un vecino sin configurar envía un mensaje de saludo, el elemento de mismo nivel LDP omite el mensaje y registra un error ( error con la marca de seguimiento) que indica el origen. Por ejemplo, si el interlocutor de LDP recibió un saludo de destino de la dirección de Internet 10.0.0.1 y ningún vecino con esta dirección está configurado específicamente, se imprimirá el siguiente mensaje en el archivo de registro LDP:

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

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

Configurar el intervalo de mensajes de KeepAlive 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 de LDP a través de la sesión en este tiempo, se envía un mensaje de actividad de KeepAlive. El valor predeterminado es de 10 segundos. El valor mínimo es de 1 segundo.

El valor configurado para el intervalo de KeepAlive puede modificarse durante la negociación de sesión LDP si el valor configurado para la hora de conservación de LDP en el enrutador del mismo nivel es inferior al valor configurado localmente. Para obtener más información, vea configurar el retraso para que los vecinos de LDP se consideren inactivos.

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

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

Configurando el tiempo de espera de KeepAlive LDP

Una vez establecida una sesión LDP, se deben intercambiar periódicamente los mensajes para asegurarse de que la sesión sigue funcionando. El tiempo de espera de KeepAlive define la cantidad de tiempo que el nodo LDP de vecino espera antes de decidir que la sesión ha fallado. Este valor suele establecerse al menos tres veces el intervalo de KeepAlive. El valor predeterminado es de 30 segundos.

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

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

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

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

Para permitir que LDP aprenda las rutas agregadas o resumidas OSPF través de áreas o niveles de ISIS en entre dominios, Junos OS le permite configurar la coincidencia más larga para LDP según 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 de 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 según RFC5283. Esto permite a LDP aprender las rutas agregadas o resumidas en OSPF áreas o niveles de ISIS en interdominio.. La Directiva de coincidencia más larga proporciona una granularidad por prefijo.

Aplicables

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

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

  • Junos OS la versión 16,1 o posterior que se ejecuta en todos los dispositivos.

Antes de empezar:

  • Configure las interfaces del dispositivo.

  • Configure OSPF.

Descripción general

A menudo, LDP se utiliza para establecer MPLS rutas conmutadas por etiqueta (LSP) en un dominio de red completo utilizando un IGP como OSPF o IS-IS. En dicho tipo de red, todos los vínculos del dominio tienen IGP adyacencias, así como con las adyacencias de LDP. LDP establece los LSP en la ruta más corta hacia un destino según lo determinado por el reenvío IP. En Junos OS, la implementación de LDP realiza una búsqueda de coincidencias exactas en la dirección IP de la FEC del nervio o de IGP rutas para la asignación de etiquetas. Esta asignación exacta requiere que MPLS se configuren las direcciones IP de extremo de LDP de extremo a extremo en todos los LERs. Esto invalida el propósito del diseño jerárquico de IP o el enrutamiento predeterminado en los dispositivos de acceso. La longest-match configuración ayuda a superar esto al suprimir el comportamiento de coincidencia exacta y el LSP de configuración según el prefijo de la ruta más larga que coincida.

Topología

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

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

Automática

Configuración rápida de CLI

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

R0

R1

R2

R3

R4

R5

Configurando el dispositivo R0

Procedimiento paso a paso

El ejemplo siguiente requiere que se exploren varios niveles en la jerarquía de configuración. Para obtener más información sobre Cómo desplazarse por la CLI, consulte uso del editor de CLI en el modo de configuración en la Guía del usuario de CLI.

Para configurar R0 de dispositivos:

  1. Configure las interfaces.

  2. Asigne las direcciones de bucle invertido al dispositivo.

  3. Configure el ID.

  4. Configure el protocolo MPLS en la interfaz.

  5. Configure el protocolo OSPF en la interfaz.

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

  7. Configure el protocolo LDP en la interfaz.

Resultados

Desde el modo de configuración, escriba los show interfacescomandos, show protocolsy y show routing-options para confirmar la configuración. 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, entre commit en el modo de configuración.

Comproba

Confirme que la configuración funciona correctamente.

Comprobando las rutas

Purpose

Compruebe que se han aprendido las rutas esperadas.

Intervención

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

Efectos

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

Comprobación de la información general de LDP

Purpose

Mostrar información general de LDP.

Intervención

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

Efectos

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

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

Purpose

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

Intervención

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

Efectos

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

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

Purpose

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

Intervención

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

Efectos

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

Comprobar FEC y enrutamientos de sombra de LDP

Purpose

Muestre la ruta FEC y las instantáneas en la tabla de enrutamiento.

Intervención

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

Efectos

El resultado muestra la FEC y las rutas de instantánea del dispositivo R0

Configuración de preferencias de ruta LDP

Cuando varios protocolos calculan rutas en el mismo destino, las preferencias de ruta se utilizan para seleccionar qué ruta se instala en la tabla de reenvío. Se seleccionará la ruta con el menor valor de preferencia. El valor de la preferencia puede ser un número en el rango comprendido entre 0 y 255. De forma predeterminada, las rutas LDP tienen un valor de preferencia de 9.

Para modificar las preferencias de ruta, incluya preference el extracto:

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

Reinicio correcto de LDP

El reinicio correcto de LDP permite que un enrutador cuyo plano de control LDP esté experimentando un reinicio para seguir reenviando el tráfico mientras recupera su estado de los 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 intente reiniciar LDP.

Durante la inicialización de la sesión, un enrutador anuncia su capacidad para realizar un reinicio correcto de LDP o para aprovechar el reinicio correcto LDP mediante el envío de un TLV de reinicio ordenado. Este TLV contiene dos campos relevantes para el reinicio correcto de LDP: el tiempo de reconexión y el tiempo de recuperación. Los valores de los tiempos de reconexión y recuperación indican las capacidades de reinicio correcto que admite el enrutador.

Cuando un enrutador descubre que un enrutador vecino se está reiniciando, esperará hasta el final del tiempo de recuperación antes de intentar la reconexión. La hora de recuperación es la cantidad de tiempo que un enrutador espera para que 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 es normalmente el tiempo durante el que un enrutador vecino mantiene su información sobre el enrutador de reinicio, lo que le permite seguir reenviando el tráfico.

Puede configurar el reinicio correcto de LDP tanto en la instancia de Master para el protocolo LDP como en una instancia de enrutamiento específica. Puede deshabilitar el reinicio normal en el nivel global para todos los protocolos, en el nivel de protocolo para LDP y en una instancia de enrutamiento específica. El reinicio correcto de LDP está deshabilitado de forma predeterminada, ya que en el nivel global se deshabilita el reinicio correcto de forma predeterminada. Sin embargo, el modo de aplicación auxiliar (la capacidad de ayudar a un enrutador vecino que intente un reinicio correcto) está habilitado de forma predeterminada.

A continuación, se muestran algunos de los comportamientos asociados con el reinicio correcto de LDP:

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

  • Cuando un enrutador se reinicia, no se envían mensajes de mapa de etiqueta a los vecinos que admitan el reinicio correcto hasta que el enrutador esté estabilizado (los mensajes de mapa de etiqueta se envían de inmediato a los vecinos que no admiten el reinicio normal). Sin embargo, todos los demás mensajes (keepalive, Address-Message, Notification y Release) se envían de la forma habitual. La distribución de estos otros mensajes impide que el enrutador distribuya información incompleta.

  • El modo de aplicación auxiliar y el reinicio correcto son independientes. Puede deshabilitar el reinicio normal en la configuración, pero aún así permitir que el enrutador cooperó con un vecino que intentará reiniciar correctamente.

Configurando el reinicio correcto LDP

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

De forma predeterminada, el modo de aplicación de reinicio ordenado está habilitado, pero el reinicio correcto está deshabilitado. Por lo tanto, el comportamiento predeterminado de un enrutador es ayudar a los enrutadores vecinos que intenten un reinicio normal, pero no intentar un reinicio correcto.

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

Habilitar el reinicio normal

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

Puede incluir esta instrucción en los siguientes niveles de jerarquía:

  • [edit routing-options]

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

Nota:

Serie ACX enrutadores no admitenedit logical-systems logical-system-name routing-optionsel nivel de jerarquía [].

La graceful-restart instrucción habilita el reinicio correcto para todos los protocolos compatibles con esta característica en el enrutador. Para obtener más información sobre el reinicio correcto, consulte la biblioteca de Junos OS de protocolos de enrutamiento para dispositivos de enrutamiento.

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

Deshabilitando el reinicio correcto de LDP o el modo de aplicación auxiliar

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

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

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

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

Las siguientes configuraciones de reinicio correcto LDP son posibles:

  • Tanto el reinicio correcto LDP como el modo auxiliar están habilitados.

  • El reinicio correcto de LDP está deshabilitado pero el modo de ayuda está habilitado. Un enrutador configurado de esta manera no puede reiniciarse correctamente, pero puede ayudar a reiniciar el vecino.

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

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

Configurar el tiempo de reconexión

Después de producirse un error en la conexión LDP entre vecinos, los vecinos esperan una cantidad determinada de tiempo para que el enrutador que se reinicia correctamente reanude el envío de mensajes LDP. Después del periodo de espera, puede restablecerse la sesión LDP. Puede configurar el periodo de espera en segundos. Este valor se incluye en el TLV de sesión tolerante a errores que se envía en los mensajes de inicialización LDP cuando está habilitado el reinicio correcto de LDP.

Supongamos que el enrutador A y el enrutador B son vecinos LDP. El enrutador A es el enrutador de reinicio. El tiempo de reconexión es el tiempo durante el cual el enrutador indica al enrutador B que debe esperar después de que el enrutador B detecte que el enrutador se reinició.

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

Puede establecer el tiempo de reconexión en un valor comprendido entre 30 y 300 segundos. De forma predeterminada, es de 60 segundos.

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

Configuración del tiempo de recuperación y el tiempo máximo de recuperación

La hora de recuperación es la cantidad de tiempo durante la que un enrutador espera a que 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 es normalmente la cantidad de tiempo que un enrutador vecino mantiene su información sobre el enrutador de reinicio, lo que le permite seguir reenviando el tráfico.

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

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

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

Filtrado de enlaces de etiquetas LDP entrantes

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

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

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

Tabla 1: de los operadores que se aplican a los filtros de etiquetas recibidas de LDP

from Armador

Descripción

interface

Coincide con los enlaces recibidos de un vecino que es adyacente a la interfaz especificada

neighbor

Coincidencias con los enlaces recibidos del ID. de enrutador LDP especificado

next-hop

Resultados de los enlaces recibidos de un vecino que anuncian la dirección de interfaz especificada

route-filter

Coincidencias en enlaces con el prefijo especificado

Si se filtra un enlace, sigue apareciendo en la base de datos LDP, pero no se considera para la instalación como parte de una ruta de acceso conmutada por etiqueta (LSP).

Generalmente, aplicar las políticas en LDP sólo 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 LDP. Sin embargo, cuando hay varios trazos de igual costo en el destino a través de vecinos distintos, puede utilizar el filtrado de LDP para excluir algunos de los siguientes saltos que se deben tener en cuenta. (De lo contrario, LDP elige uno de los siguientes saltos aleatoriamente.)

Las sesiones LDP no están enlazadas a interfaces o a direcciones de interfaz. LDP anuncia sólo las etiquetas por enrutador (no para cada interfaz); por tanto, 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 con el mismo vecino, tenga cuidado de asegurarse de que el filtro lo hace lo que se espera. (Generalmente, el next-hop uso interface de y no es adecuado en este caso.)

Si se ha filtrado una etiqueta (lo que significa que ha sido rechazada por la Directiva y no se utiliza para crear 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 agentes de tráfico.

Cita Filtrado de enlaces de etiquetas LDP entrantes

Aceptar solo/32 prefijos de todos los vecinos:

Acepte o más tiempo del ID del enrutador y acepte todos los 131.108/1610.10.255.2 prefijos del resto de vecinos:

Filtrado de enlaces de etiquetas LDP salientes

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

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

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

Tabla 2: Operadores to para el filtrado LDP de salida de etiquetas

al operador

Descripción

interface

Coincide con los enlaces enviados a un vecino que es adyacente a la interfaz especificada

neighbor

Coincidencias en los enlaces enviados al identificador de enrutador LDP especificado

next-hop

Concordancias con los enlaces enviados a un vecino que anuncian la dirección de interfaz especificada

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

Las sesiones LDP no están enlazadas a interfaces o a direcciones de interfaz. LDP anuncia sólo las etiquetas por enrutador (no para cada 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 and interface cuando un enrutador tenga varias adyacencias al mismo vecino.

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

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

Cita Filtrado de enlaces de etiquetas LDP salientes

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

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

Especificar 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 que los enrutadores intercambian los anuncios de etiquetas necesarios para la sesión LDP. Para establecer la sesión TCP, cada enrutador debe aprender la dirección de transporte del otro enrutador. La dirección de transporte es una dirección IP que se utiliza para identificar la sesión TCP en la que se ejecutará la sesión LDP.

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

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

Si especifica la router-id opción, se utilizará la dirección del identificador de enrutador como dirección de transporte (a menos que se configure lo contrario, el identificador de enrutador suele ser el mismo que la dirección de bucle de retroceso). Si especifica la interface opción, la dirección de interfaz se utilizará como dirección de transporte para cualquier sesión LDP a los vecinos a las que se pueda tener acceso a través de dicha interfaz. Tenga en cuenta que el identificador de enrutador se utiliza de forma predeterminada como dirección de transporte.

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 la misma dirección de transporte se anuncie en todas las interfaces del mismo vecino. Si LDP detecta varios vínculos paralelos al mismo vecino, deshabilita las interfaces para 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 usada para sesión LDP de destino

Para establecer una sesión TCP entre dos dispositivos, cada dispositivo debe aprender la dirección de transporte del otro dispositivo. La dirección de transporte es una dirección IP que se utiliza para identificar la sesión TCP a través de la cual funciona la sesión LDP. Anteriormente, esta dirección de transporte solo puede ser el identificador enrutador o una dirección de interfaz. Con la característica de dirección de transporte LDP, puede configurar explícitamente cualquier dirección IP como dirección de transporte para LDP Neighbors dirigidas para el circuito de capa 2, el MPLS y las adyacencias VPLS. Esto le permite controlar las sesiones de LDP dirigidas mediante la configuración de dirección de transporte.

Ventajas de controlar la dirección de transporte utilizada para la sesión 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 utilizar más de un protocolo en la red troncal IGP para LDP. Esto permite operaciones sencillas y fáciles.

Target: Introducción a la dirección de transporte LDP

Antes de Junos OS versión de 19.1 R1, LDP ofrecía compatibilidad únicamente para los IDENTIFICADOres de enrutador o la dirección de interfaz como dirección de transporte en cualquier interfaz LDP. Las adyacencias formadas en esa interfaz usaban una de las direcciones IP asignadas a la interfaz o al enrutador. En el caso de una adyacencia dirigida, la interfaz es la interfaz de bucle de retorno. Cuando se configuraron varias direcciones de bucle de retroceso en el dispositivo, no se pudo derivar la dirección de transporte de la interfaz y, como resultado, no se pudo establecer la sesión LDP.

A partir de Junos os versión de 19.1 R1, además de a las direcciones IP predeterminadas utilizadas para las direcciones de transporte de las sesiones LDP de destino, puede configurar cualquier otra dirección IP sessioncomo session-groupdirección de interface transporte con el bajo el, el y la configuración extractos. La configuración de las direcciones de transporte sólo se aplica a los vecinos configurados, incluidos los circuitos de capa 2, MPLS y las adyacencias VPLS. Esta configuración no se aplica a las adyacencias detectadas (destinadas o no).

Preferencia de dirección de transporte

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

Una vez configurada la dirección de transporte, la sesión de LDP dirigida se establece en función de la preferencia de dirección de transporte de LDP.

El orden de preferencia de las direcciones de transporte para los vecinos dirigidos (configurados a través del circuito 2, MPLS, VPLS y la configuración LDP) es el siguiente:

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

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

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

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

  5. Dirección predeterminada.

El orden de preferencia de las direcciones de transporte de los vecinos descubiertos es el siguiente:

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

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

  3. Dirección predeterminada.

El orden de preferencia de las direcciones de transporte para vecinos de destino automático en los que LDP está configurado para aceptar paquetes de saludo es el siguiente:

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

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

  3. Dirección predeterminada.

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

Puede usar los siguientes resultados del comando show para solucionar las sesiones de LDP dirigidas:

  • show ldp session

  • show ldp neighbor

    El detail nivel de salida del show ldp neighbor comando muestra la dirección de transporte enviada en los mensajes de saludo al vecino de destino. Si no se puede tener acceso a esta dirección desde el vecino, no se activará la sesión LDP.

  • show configuration protocols ldp

También puede activar LDP TraceOptions para solucionar más problemas.

  • Si se cambia la configuración desde una dirección de transporte que no es válida (no se puede alcanzar) a una dirección de transporte válida, pueden tenerse en cuentan los seguimientos siguientes:

  • Si se cambia la configuración desde una dirección de transporte válida a una dirección de transporte que no es válida (no se puede alcanzar), se pueden observar las siguientes trazas:

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

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

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

Configurando los prefijos anunciados en LDP desde la tabla de enrutamiento

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

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

Nota:

Si configura una directiva de salida para LDP que no incluye la dirección de bucle invertido, dejará de anunciarse en LDP. Para seguir anunciando la dirección de bucle de retroceso, debe configurarla explícitamente como parte de la Directiva de salida LDP.

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

Nota:

Serie ACX enrutadores no admitenedit logical-systemsel nivel de jerarquía [].

Ejemplo Configurando los prefijos anunciados en LDP

Anunciar todas las rutas conectadas a LDP:

Configurando la deagregación de FEC

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

Normalmente, dado que un LSP no se divide en varios saltos siguientes y los prefijos se enlazan a un LSP único, no se produce el balanceo de la carga entre las rutas de igual costo. Sin embargo, puede equilibrar la carga entre rutas de igualdad de costo si configura una política de balanceo de carga y desagrega la FECs.

Al deshacer la FECs, cada prefijo se enlaza a una etiqueta independiente y se convierte en un LSP independiente.

Para configurar FECs desagregados, incluya la deaggregate instrucción:

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

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

La desagregación de FEC permite que los varios LSP resultantes se distribuyan en varios paths de igual costo y distribuya LSP en varios saltos siguientes en los segmentos de salida, pero solo instala un salto próximo por LSP.

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

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

Para todas las sesiones LDP, solo puede configurar globalmente los FECs agregados.

Configuración de directivas para LDP FECs

Puede configurar el Junos OS para controlar y supervisar el tráfico de LDP FECs. Se pueden usar las directivas de LDP FEC para realizar cualquiera de las siguientes acciones:

  • Seguimiento o policía el tráfico de entrada para un FEC de LDP.

  • Seguimiento o control de la policía del tráfico de tránsito de un FEC de LDP.

  • Seguimiento o policía de tráfico LDP FEC procedente de una clase de reenvío específica.

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

  • Descartar el tráfico falso enlazado a un LDP específico de

Para el tráfico de policía para LDP FEC, 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 jerárquico. La interface instrucción permite hacer coincidir el filtro con una sola interfaz. La interface-set instrucción permite hacer coincidir el filtro con varias interfaces.

Para obtener más información sobre cómo configurar la instrucción, la instrucción y los agentes de políticas para FPC de LDP, consulte la Guía del usuario de políticas de enrutamiento, filtros de firewall y agentes de interfaceinterface-set tráfico. https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/config-guide-policy/config-guide-policy.html

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

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

La policing instrucción incluye las siguientes opciones:

  • fec: especifique la dirección FEC para el LDP FEC que desea policía.

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

  • transit-traffic: permite especificar el nombre del filtro de tráfico de tránsito.

Configurar el filtrado FEC de IPv4 de LDP

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

En una red de proveedores mixta en la que todos los prefijos no BGP se anuncian en LDP, la base de datos LDP puede llegar a ser grande. Para este tipo de entorno, puede ser útil evitar el anuncio de FECs IPv4 a través de sesiones LDP formadas debido a un circuito de capa 2 o a la configuración de VPLS de LDP. De manera similar, puede ser útil filtrar cualquier FECs IPv4 recibido en este tipo de entorno.

Si todos los vecinos del LDP asociados con una sesión de LDP son solo de capa 2, puede configurar el Junos OS para anunciar solo circuitos FEC de capa 2 mediante la configuración de la l2-smart-policy instrucción. Esta característica también filtra automáticamente las FECs IPv4 recibidas en esta sesión. Si se configura una directiva de importación o exportación explícita que l2-smart-policy se activa para desactivar esta función en la dirección correspondiente.

Si uno de los vecinos de la sesión LDP se forma debido a una adyacencia descubierta o si la adyacencia se forma debido a una configuración de tunelización de LDP en uno o más LSP RSVP, los 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 los niveles de jerarquía en los que puede configurar esta instrucción, consulte el resumen del extracto de cuenta de este extracto.

Configurando BFD para LSP de LDP

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

Se registra un error siempre que falla una sesión BFD de una ruta de acceso. A continuación se muestra cómo puede aparecer BFD para mensajes de registro de LSP LDP:

También puede configurar BFD para LSP de RSVP, tal y como se describe en Configuring BFD para LSP señalizados con RSVP.

Los temporizadores de detección de fallos de BFD son adaptables y se pueden ajustar para ser más o menos agresivos. Por ejemplo, los temporizadores se pueden adaptar a un valor superior si se produce un error en la adyacencia o un vecino puede negociar un valor superior para un temporizador que con el valor configurado. Los temporizadores se adaptan a un valor superior cuando se produce una solapa de sesión BFD más de tres veces en un período de 15 segundos. Un algoritmo de reversión aumenta el intervalo de recepción (RX) por dos si la instancia BFD local es la razón de la solapa de sesión. El intervalo de transmisión (TX) se aumenta en dos si la instancia de BFD remota es la razón de la solapa de sesión. Puede usar el clear bfd adaptation comando para devolver BFD intervalo de tiempo a sus valores configurados. El clear bfd adaptation comando es hitless, lo que significa que el comando no afecta al flujo de tráfico del dispositivo de enrutamiento.

Para habilitar BFD para LSP de LDP, incluya oam las bfd-liveness-detection sentencias e:

Puede habilitar BFD para el LSP de LDP asociado con una clase de equivalencia de reenvío (FEC) específica si configura la dirección FEC mediante fec la opción en [edit protocols ldp] el nivel de jerarquía. O bien, puede configurar una directiva de entrada de administración de operaciones (mantenimiento seguros) para activar BFD en un intervalo de direcciones FEC. Para obtener más información, consulte Configuring mantenimiento seguros Ingress Policies para LDP.

No puede habilitar BFD los LSP de LDP a menos que sus direcciones FEC equivalente se configuren de forma explícita o que mantenimiento seguros esté habilitado en el FECs usando una directiva mantenimiento seguros de entrada. Si BFD no está habilitado para ninguna dirección FEC, no se mostrará la sesión BFD.

Puede configurar el oam extracto en los siguientes niveles de jerarquía:

  • [edit protocols ldp]

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

Nota:

Serie ACX enrutadores no admitenedit logical-systemsel nivel de jerarquía [].

La oam instrucción incluye las siguientes opciones:

  • fec: especifique la dirección FEC. Debe especificar una dirección FEC o configurar una directiva mantenimiento seguros de entrada para garantizar que se activa la sesión de BFD.

  • lsp-ping-interval: permite especificar la duración del intervalo de ping de LSP en cuestión de segundos. Para emitir un comando ping en un LSP señalizado con LDP, utilice ping mpls ldp la. Para obtener más información, consulte el CLI Explorer.

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

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

  • intervalo de retención:especifique la duración de la sesión de BFD debe permanecer activa antes de agregar la ruta o el salto siguiente. Si se especifica una hora de 0 segundos, la ruta o el siguiente salto se agregará en cuanto vuelva a iniciarse la sesión de BFD.

  • minimum-interval: permite especificar el intervalo mínimo de transmisión y recepción. Si configura la minimum-interval opción, no es necesario que configure la minimum-receive-interval opción ni la minimum-transmit-interval opción.

  • minimum-receive-interval: permite especificar el intervalo mínimo de recepción. El intervalo va de 1 a 255 000 milisegundos.

  • minimum-transmit-interval: permite especificar el intervalo mínimo de transmisión. El intervalo va de 1 a 255 000 milisegundos.

  • multiplier: permite especificar el multiplicador de tiempo de detección. El rango está comprendido entre 1 y 255.

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

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

Cuando configure BFD para una FEC, se establece una sesión de BFD solo para un próximo salto local activo para el enrutador. Sin embargo, puede configurar varias sesiones de BFD, una para cada FEC asociada con una ruta específica de múltiples rutas (ECMP) de igual costo. Para que funcione correctamente, también es necesario configurar el traceroute periódico de LDP de los LSP. (Consulte configuraciónde los LSP de LDP. Se usa el traceroute de LSP de LDP para detectar paths ECMP. Se inicia una sesión BFD para cada ruta de acceso ECMP detectada. Siempre que falle una sesión de BFD para una de las rutas ECMP, se registrará un error.

El traceroute de LSP de LDP se ejecuta periódicamente para comprobar la integridad de las rutas de ECMP. Es posible que se produzca lo siguiente cuando se detecte un problema:

  • Si la última versión de Traceroute de un LSP de LDP para FEC es diferente a la anterior, las sesiones de BFD asociadas con ese FEC (las sesiones de BFD para intervalos de direcciones que han cambiado desde la ejecución anterior) se ponen al alcance y se inician nuevas sesiones BFD para el destino las direcciones en los rangos modificados.

  • Si el LSP de LPD de LDP devuelve un error (por ejemplo, un tiempo de espera), se desactivarán todas las sesiones de BFD asociadas con la FEC.

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

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

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

Nota:

Serie ACX enrutadores no admitenedit logical-systemsel nivel de jerarquía [].

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

Puede configurar las propiedades de enrutamiento y de salto siguiente en caso de un evento de error de sesión BFD en un LSP de LDP. El evento de fallo podría ser una sesión de BFD existente que se haya apagado o que pudiera ser una sesión de BFD que no apareció nunca. LDP vuelve a agregar la ruta o el siguiente salto cuando vuelve a estar en la sesión de BFD pertinente.

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

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

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

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

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

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

Puede especificar la duración de la sesión BFD antes de agregar una ruta o un salto siguiente configurando la holddown-interval instrucción en el [edit protocols ldp oam bfd-livenesss-detection] nivel de jerarquía o en el [edit protocols ldp oam fec address bfd-livenesss-detection] nivel de jerarquía. Si se especifica una hora de 0 segundos, la ruta o el siguiente salto se agregará en cuanto vuelva a iniciarse la sesión de BFD.

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

Descripción de la reruta rápida de solo multidifusión

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

Nota:

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

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

Con MoFRR habilitado, los dispositivos envían mensajes de unión en rutas 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, inmediatamente comienza a aceptar paquetes desde la interfaz secundaria (la ruta de respaldo). El cambio rápido mejora en gran medida los tiempos de convergencia cuando se produce un error en el vínculo de ruta principal.

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

Descripción general de MoFRR

Con un reenrutado rápido en flujos de unidifusión MPLS, un dispositivo de enrutamiento ascendente preestabla una ruta de conmutación de etiquetas (LSP) o precomputa una ruta de respaldo de reenrutación rápida sin bucles IP (LFA) para controlar el error de un segmento en la ruta descendente.

En el enrutamiento de multidifusión, el lado receptor generalmente origina los gráficos de distribución de tráfico. Esto no es lo mismo que el enrutamiento de unidifusión, que generalmente establece la ruta del origen al receptor. PIM (para IP), LDP multipunto (para MPLS) y RSVP-ING-T (para MPLS) son protocolos capaces de establecer gráficos de distribución de multidifusión. De estos, los receptores LDP multipunto y PIM inician la configuración del gráfico de distribución, por lo que MoFRR puede funcionar con estos dos protocolos de multidifusión donde se admiten.

En un árbol de multidifusión, si el dispositivo detecta un error 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 al configurar 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 transmisión en vivo de respaldo del mismo tráfico de multidifusión. Cuando se produce un error a lo largo de la transmisión principal, el dispositivo de enrutamiento MoFRR puede conmutar 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 de acceso inconexas si dos de estas rutas están disponibles. Si no hay trazados disjuntos disponibles, el protocolo selecciona dos rutas de acceso no discontinuas. Si no hay dos trazados no separados disponibles, solo se selecciona un path primario sin copia de seguridad. MoFRR prioriza la desintegración de la copia de seguridad a favor del equilibrio de carga de las rutas disponibles.

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

Figura 12 muestra dos rutas del 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 moFRR habilitado, el dispositivo de enrutamiento de salida (lado del receptor) configura dos árboles de multidifusión, una ruta principal y una ruta de respaldo, hacia el origen de multidifusión para cada uno (S,G). En otras palabras, el dispositivo de enrutamiento de salida propaga los mismos mensajes (S,G) unirse a dos vecinos ascendentes diferentes, creando así dos árboles de multidifusión.

Uno de los árboles de multidifusión pasa a través del plano 1 y el otro hasta el plano Figura 122, tal y como se muestra en la. Para cada uno (S,G), el dispositivo de enrutamiento de salida reenvía el tráfico recibido en la ruta principal y descarta el tráfico recibido en la ruta de respaldo.

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

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

La moFRR de LDP multipunto se utiliza en el dispositivo de salida de una red MPLS, donde los paquetes se reenvía a una red IP. Con el moFRR de LDP multipunto, el dispositivo establece dos rutas hacia el dispositivo de enrutamiento de PE ascendente para recibir dos flujos de MPLS paquetes 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 respaldo en su lugar. La compatibilidad con la señalización en banda es un prerrequisito para MoFRR con LDP multipunto (consulte Descripción de la señalización en banda de LDP multipunto para LSP de punto a multipunto).

Funcionalidad de PIM

Junos OS admite MoFRR para las uniones de árbol de ruta de acceso más corta (más corta) en PIM (MULTISOURCE-especificidad multicast) y en cualquier fuente de multidifusión (ASM). MoFRR se admite para rangos SSM y ASM. Para habilitar MoFRR para las combinaciones (*,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 moFRR habilitado, un dispositivo de enrutamiento PIM propaga mensajes de unión en dos interfaces ascendentes de reenvío de ruta inversa (RPF) para recibir tráfico de multidifusión en ambos vínculos para la misma solicitud de unión. El 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 los siguientes saltos de 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 combinación PIM (consulte la join-load-balance automatic instrucción). Sin embargo, en ese caso, es posible que la distribución de mensajes de unión entre los vínculos no sea uniforme. Cuando se agrega un nuevo vínculo ECMP, las combinaciones de los mensajes de la ruta de acceso primaria se redistribuyen y se equilibra la carga. Los mensajes de unión de la ruta de copia de seguridad pueden seguir seguido de la misma ruta y es posible que no se redistribuyan uniformemente.

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

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

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

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

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

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

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

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

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

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

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

      • Si las rutas principales y de copia de seguridad 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, el plano 1 Figura 12 en).

Funcionalidad LDP de Multipoint

Para evitar MPLS duplicación de tráfico, el LDP multipunto suele seleccionar solo una ruta ascendente. (Consulte la sección 2.4.1.1. Determinar las rutas "ascendentes ECE" en rfc 6388, Extensiones de protocolo de distribución de etiquetas para rutas conmutadas de punto a multipunto y de etiqueta multipunto a multipunto.)

Para el LDP multipunto con MoFRR, el dispositivo LDP multipunto selecciona dos pares ascendentes independientes y envía dos etiquetas independientes, una a cada par ascendente. El dispositivo usa el mismo algoritmo descrito en rfc 6388 para seleccionar la ruta ascendente principal. El dispositivo usa el mismo algoritmo para seleccionar la ruta ascendente de copia de seguridad, pero excluye la ruta principal ascendente ECE como candidato. Los dos pares ascendentes diferentes envían dos flujos de MPLS de tráfico al dispositivo de enrutamiento de salida. El dispositivo solo selecciona una de las rutas de vecino ascendente como la ruta principal desde la cual aceptar el MPLS tráfico. La otra ruta se convierte en la ruta de respaldo y el dispositivo cae 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ía 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 en particular representa la FEC a la que está asignado dicho paquete. En MoFRR, se colocan dos rutas en la tabla mpls.0 para cada FEC: una ruta para la etiqueta principal y la otra 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 el principal. En cualquier momento, el dispositivo ascendente envía tráfico solo a uno de los múltiples vínculos paralelos.

Un nodo de conexión es un ECE que es un puerto ECE salida, pero también tiene uno o más LSR descendentes conectados directamente. En el caso de un nodo de desarrollo, el tráfico desde la ruta ascendente principal se reenvía a una ruta descendente ECE. Si se produce un error en la ruta de acceso de entrada de flujo primaria, el MPLS tráfico de la ruta de backup upstream se reenvía al LSR de dirección descendente. Esto significa que el siguiente salto LSR de la dirección descendente se agrega a las dos rutas MPLS junto con el próximo salto de salida.

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

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

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

  • Se considera que todas las interfaces que pertenecen al mismo LSR de entrada de flujo son la ruta de acceso primaria.

  • En cualquier actualización de ruta de nodo raíz, la ruta de acceso ascendente se cambia en función de los siguientes saltos más recientes de la IGP. Si hay disponible una ruta de acceso mejor, Multipoint LDP intenta cambiar a la ruta de acceso más adecuada.

Reenvío de paquetes

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

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

  • Impide varias búsquedas de ruta (que resultan en pérdidas de paquetes).

Para PIM, cada secuencia de multidifusión IP contiene la misma dirección de destino. Independientemente de la interfaz en la que llegan los paquetes, los paquetes tienen la misma ruta. El dispositivo comprueba la interfaz a la que llega cada paquete y reenvía solo aquellas que son de la interfaz principal. Si la interfaz coincide con una interfaz de transmisión de respaldo, el dispositivo deja caer los paquetes. Si la interfaz no coincide con la interfaz 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 de prueba principal y de respaldo 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 rutas IP moFRR en la motor de reenvío de paquetes en conmutadoresManejo de rutas IP moFRR en la motor de reenvío de paquetes en conmutadores

Para MoFRR con LDP de multipunto en enrutadores, el dispositivo utiliza varias etiquetas MPLS para controlar la selección de flujos MoFRR. Cada etiqueta representa una ruta independiente, pero cada una de ellas hace referencia a la misma comprobación de la lista de interfaces. El dispositivo solo reenvía la etiqueta principal y deja caer a 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: MoFRR MPLS búsqueda de ruta en el motor de reenvío de paquetesMoFRR MPLS búsqueda de ruta en el motor de reenvío de paquetes

Limitaciones y advertencias

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

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

  • La detección de errores de MoFRR se admite para la protección inmediata del vínculo 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 el reenrutado rápido en dos rutas desconexas 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. Esto mismo se aplica si la interfaz de nivel superior es una interfaz de túnel de multidifusión.

  • No se admite la detección del máximo de paths inconexos de i-Stream de extremo a extremo. El dispositivo de enrutamiento del lado del receptor (salida) solo se asegura de que haya un dispositivo ascendente desconexo (el salto anterior inmediato). PIM y Multipoint LDP no admiten el equivalente de objetos Route explícitos (EROs). Por lo tanto, la detección de ruta ascendente desconexa 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 se pierda algo de tráfico en los siguientes casos:

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

    • La MoFRR está habilitada o deshabilitada en el dispositivo de salida mientras hay un flujo de tráfico activo.

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

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

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

  • El intervalo PIM bidireccional no se admite con MoFRR.

  • El modo denso PIM no se admite con MoFRR.

  • Las estadísticas de multidifusión del flujo de tráfico de copia de seguridad no son mantenidas por PIM y, show por lo tanto, no están disponibles en la salida operativa de los comandos.

  • No se admite la supervisión de la velocidad.

Limitaciones de MoFRR en dispositivos de conmutación con PIM

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

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

  • La replicación de paquetes y las búsquedas de multidifusión mientras se reenvía el tráfico de multidifusión pueden hacer que los paquetes recirculen a través de PFE varias veces. Como resultado, los valores mostrados para los recuentos de paquetes de multidifusión del comando pueden mostrar números más altos de lo esperado en campos de show pfe statistics traffic salida como Input packets y Output packets . Es posible que observe este comportamiento con más frecuencia en situaciones de MoFRR, ya que las secuencias principales y de respaldo duplicadas aumentan el flujo de tráfico en general.

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

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

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

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

  • No se admiten las etiquetas LDP de Multipoint como etiquetas internas.

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

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

  • No se admite la protección de vínculos de Multipoint LDP en la ruta de copia de seguridad porque no se admiten etiquetas internas de MoFRR.

Configurando la reruta rápida de solo multidifusión

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

Cuando se aplica la reruta rápida a las secuencias de unidifusión, un enrutador de nivel superior preestablece MPLS rutas de acceso de etiqueta conmutada (LSP) o calcula previamente una ruta de copia de seguridad de redireccionamiento rápido alternativa y sin bucles IP (LFA) para controlar la falla de un segmento en la ruta de flujo descendente.

En el enrutamiento de multidifusión, los gráficos de distribución de tráfico suelen ser originados por el receptor. Esto no es lo mismo que el enrutamiento de unidifusión, que normalmente establece la ruta desde el origen hasta el receptor. Los protocolos capaces de establecer gráficos de distribución de multidifusión son PIM (para IP), Multipoint LDP (por MPLS) y RSVP-TE (por MPLS). De estos, los receptores de PIM y Multipoint 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 la serie MX y serie SRX, MoFRR se admite en los dominios PIM y Multipoint LDP.

Los pasos de configuración son los mismos para activar MoFRR para PIM en todos los dispositivos que admiten esta característica, a menos que se indique lo contrario. También se indican los pasos de configuración que no son aplicables a multipoint LDP MoFRR.

(Solo para enrutadores de la serie MX) MoFRR se admite en enrutadores de la serie MX con fichas de líneas MPCs. Como requisito previo, todas las tarjetas de línea del enrutador deben ser MPCs.

Para configurar MoFRR en enrutadores o conmutadores:

  1. (Sólo para enrutadores de la serie MX y serie SRX) Establecer el enrutador en modo de IP mejorado.
  2. Activar MoFRR.
  3. Adicional Configure una directiva de enrutamiento que filtre un conjunto restringido de secuencias de multidifusión a fin de que se vea afectada por la configuración MoFRR.

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

    Por ejemplo:

  4. Adicional Si configuró una directiva de enrutamiento para filtrar el conjunto de grupos de multidifusión que se verán afectados por la configuración MoFRR, aplique la Directiva para la protección MoFRR transmisión por secuencias.

    Por ejemplo:

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

    Esto no es compatible con Multipoint LDP MoFRR.

  6. Adicional En un dominio PIM con MoFRR, permita seleccionar solo un RPF discontinuo (una RPF en un plano independiente) como ruta de copia de seguridad RPF.

    Esto no es compatible con Multipoint LDP MoFRR. En un dominio Multipoint de LDP MoFRR, se comparte la misma etiqueta entre vínculos paralelos al mismo vecino que precede en la cadena. Este no es el caso en un dominio PIM, donde cada vínculo forma un vecino. La mofrr-disjoint-upstream-only instrucción no permite seleccionar una ruta de copia de seguridad RPF si la ruta de acceso va al mismo vecino que precede en la ruta de acceso de RPF principal. Esto garantiza que MoFRR sólo se desencadenará en una topología que tenga varios vecinos que preceden hacia el flujo de RPF.

  7. Adicional En un dominio PIM con MoFRR, evite enviar mensajes de combinación en la ruta de copia de seguridad, pero conservar las demás funciones de la MoFRR.

    Esto no es compatible con Multipoint LDP MoFRR.

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

    Cuando se incluye la mofrr-primary-selection-by-routing instrucción, no se garantiza que la ruta de la copia de seguridad sea promovible a la ruta de acceso primaria nueva cuando la ruta de acceso principal deja de funcionar.

    Esto no es compatible con Multipoint LDP MoFRR.

Ejemplo Configuración de la reenrutación rápida de solo multidifusión en un dominio de Multipoint LDP

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

Multipoint LDP MoFRR se utiliza en el nodo de salida de una red de MPLS, donde los paquetes se reenvían a una red IP. En el caso de Multipoint LDP MoFRR, las dos rutas hacia el enrutador de extremo de proveedor (PE) de flujo de entrada se establecen para recibir dos secuencias de paquetes de MPLS en el enrutador de límite de etiqueta (LER). Se acepta una de las secuencias (la principal) y la otra (la copia de seguridad) se coloca en LER. La secuencia de copia de seguridad se acepta si falla la ruta de acceso primaria.

Aplicables

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

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

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

Este ejemplo requiere Junos OS versión 14,1 o posterior del enrutador PE de salida.

Descripción general

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

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

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

La configuración MoFRR incluye una opción de directiva que no se muestra en este ejemplo, pero se explica por separado. La opción está configurada de la siguiente manera:

Topología

Figura 16muestra la red de ejemplo.

Figura 16: MoFRR en un dominio de Multipoint LDPMoFRR en un dominio de Multipoint LDP

Configuración rápida de CLImuestra la configuración de todos los dispositivos de Figura 16.

En la Automática secció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, quite los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, a continuación, copie y [edit] pegue los comandos en la CLI en el nivel de jerarquía.

Dispositivo SRC1

Dispositivo src2

Dispositivo R1

Dispositivo R2

Dispositivo R3

Dispositivo R4

Dispositivo R5

R6 de dispositivo

Dispositivo R7

Dispositivo R8

Automática

Modalidades

Procedimiento paso a paso

El ejemplo siguiente requiere que se exploren 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 CLI de Junos os.

Para configurar el dispositivo R3:

  1. Activar el modo de IP mejorado.

  2. Configure las interfaces del dispositivo.

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

  4. Configure las políticas de enrutamiento.

  5. Configurar PIM.

  6. Configurar LDP.

  7. Configure una IGP o rutas estáticas.

  8. Configure BGP interna.

  9. Configure MPLS y, opcionalmente, RSVP.

  10. Activar MoFRR.

Resultados

Desde el modo de configuración show chassis, especifique los comandos, show interfaces, show protocolsshow policy-options, y show routing-options para confirmar la configuración. 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, entre commit en el modo de configuración.

Comproba

Confirme que la configuración funciona correctamente.

Comprobación de las clases de equivalencia de enrutamiento de punto a multipunto de LDP

Purpose

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

Intervención
Efectos

El resultado muestra que MoFRR está habilitado, y muestra que los rótulos 301568 y 301600 se están utilizando para los dos LSP de punto a multipunto de LDP de multipoint.

Examinar la información de las etiquetas

Purpose

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

Intervención
Efectos

El resultado muestra las rutas de flujo principales y las rutas de backup ascendentes. También muestra los siguientes saltos de la RPF.

Comprobando las rutas de multidifusión

Purpose

Examine la tabla de reenvío de multidifusión IP para asegurarse de que hay una lista de interfaces de preflujo de RPF, con una interfaz primaria y una de copia de seguridad.

Intervención
Efectos

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

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

Purpose

Asegúrese de que se muestran tanto las estadísticas principales como las de reserva.

Intervención
Efectos

El resultado muestra tanto las rutas principales como las de copia de seguridad con las etiquetas.

Ejemplo Configuración de LDP en sentido descendente según demanda

En este ejemplo se muestra cómo configurar LDP en sentido descendente a pedido. LDP suele configurarse utilizando el modo de anuncio no solicitado de nivel inferior, lo que significa que los anuncios de etiqueta de todas las rutas se reciben desde todos los homólogos de LDP. Dado que los proveedores de servicios integran las redes de acceso y agregación en un único dominio de MPLS, es necesario un modo descendente de LDP para distribuir los enlaces entre las redes de acceso y agregación, así como para reducir los requisitos de procesamiento del plano de control.

Los nodos descendentes podrían recibir decenas de miles de enlaces de etiqueta a partir de nodos de agregación de nivel superior. En lugar de aprender y almacenar todos los enlaces de etiquetas para todas las posibles direcciones de bucle invertido en toda la red MPLS, puede configurarse el nodo de agregación de flujo descendente mediante LDP downstream en sentido descendente a pedido para solicitar únicamente los enlaces de etiqueta para FECs correspondientes a las direcciones de bucle de retroceso de los nodos de salida en los que tiene servicios configurados.

Aplicables

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

  • Enrutador M Series

  • Junos OS 12,2

Descripción general

Puede habilitar LDP de forma descendente en el anuncio de etiquetas de demanda para una sesión LDP si incluye la instrucción downstream de bajo [edit protocols ldp session] demanda en el nivel de la jerarquía. Si ha configurado la conexión directa a pedido, el enrutador de Juniper Networks anuncia la solicitud a petición de nivel inferior a sus enrutadores de punto de conexión. Para establecer una sesión a pedido bajo bajo demanda entre dos enrutadores, ambos deben anunciar el modo indirecto en la demanda durante el establecimiento de sesión LDP. Si un enrutador anuncia el modo no solicitado de dirección descendente y el otro anuncia a pedido, se utiliza el modo no solicitado de nivel inferior.

Automática

Configuración de LDP en sentido descendente según demanda

Procedimiento paso a paso

Para configurar una directiva LDP en sentido descendente a pedido y, a continuación, configurarla y habilitar LDP downstream a pedido en la sesión LDP:

  1. Configure la Directiva a demanda de nivel inferior (de solicitudes de DOD-bucles) en este ejemplo.

    Esta directiva hace que el enrutador reenvíe sólo los mensajes de solicitud de etiqueta a los FECs que coinciden con la Directiva de bucle de retroceso de DOD-request.

  2. Especifique la Directiva de bucles de retroceso de solicitud de dod-request-policy DoD mediante la [edit protocols ldp] instrucción en el nivel de jerarquía.

    La Directiva especificada con la dod-request-policy instrucción se utiliza para identificar los prefijos a fin de enviar mensajes de solicitud de etiqueta. Esta directiva es similar a una directiva de salida o a una directiva de importación. Cuando se procesan rutas desde la tabla de enrutamiento inet. 0, Junos OS software comprueba si hay DOD-Request-Loopbacks rutas que coincidan con la Directiva (en este ejemplo). Si la ruta coincide con la Directiva y la sesión LDP se negocia con el modo de aviso DOD, los mensajes de solicitud de etiqueta se envían a la sesión LDP downstream correspondiente.

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

Distribución de LDP downstream en las rutas de demanda en BGP etiquetadas

Procedimiento paso a paso

Para distribuir rutas LDP en sentido indirecto a pedido en BGP con etiqueta, utilice una política de exportación BGP.

  1. Configure la Directiva de rutaredistribute_ldp LDP (en este ejemplo).

  2. Incluya la Directiva de ruta LDP redistribute_ldp , en el BGP configuración (como parte de la configuración ebgp-to-abr de los grupos de BGP en este ejemplo).

    BGP reenvía las rutas LDP basadas en redistribute_ldp la Directiva al enrutador remoto de PE

Procedimiento paso a paso

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

  1. Configure dod-routes la Directiva para que acepte rutas de LDP.

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

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

  4. Especifique la filter-dod-routes-on-du-sesssion Directiva como la Directiva de exportación para BGP ebgp-to-abrbroup.

Resultados

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

Comproba

Comprobando modo de anuncio de etiqueta

Purpose

Confirme que la configuración funciona correctamente.

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

Intervención

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

  • La siguiente salida de comando para show ldp session el comando indica que Adv. Mode el (modo de anuncio de DOD etiqueta) es (lo que significa que la sesión LDP downstream on Demand está en funcionamiento):

  • La siguiente salida de comando para show ldp session detail el comando indica que Local Label Advertisement mode is Downstream unsolicited, el valor predeterminado (significa que la dirección descendente de la petición no está configurada en la sesión local). A la inversa, el Remote Label Advertisement mode y Negotiated Label Advertisement mode ambos indican que Downstream on demand está configurado en la sesión remota

Configuración de la compatibilidad con IPv6 nativa LDP

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

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

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

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

    Por ejemplo, configure inet-LSR-ID como 10.255.0.1 y inet6-LSR-ID como pág.

Ejemplo Configuración de la compatibilidad con IPv6 nativa LDP

Este ejemplo muestra cómo permitir que el protocolo de distribución de etiquetas de Junos OS (LDP) establezca la conexión TCP a través de IPv4 con vecinos IPv4, y a través de IPv6 con vecinos de IPv6 como LSR de pila única. Esto ayuda a evitar el túnel de IPv6 a través de MPLS de núcleo de IPv4 con las rutas de conmutación de nombre de etiqueta MPLS (LSP) señalizadas por IPv4.

Aplicables

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

  • Dos enrutadores serie MX

  • Junos OS la versión 16,1 o posterior que se ejecuta en todos los dispositivos

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

Descripción general

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

Topología

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

Figura 17: Ejemplo de compatibilidad con IPv6 nativa de LDPEjemplo de compatibilidad con IPv6 nativa de LDP

Automática

Configuración rápida de CLI

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

R1

R2

Configuración de R1

Procedimiento paso a paso

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

Para configurar el dispositivo R1:

  1. Configure las interfaces.

  2. Asigne una dirección de bucle de retroceso 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 poder usar etiquetas distintas para familias de direcciones diferentes.

  6. Configurar familias de direcciones LDP.

Resultados

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

Configure Transport-Preference 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 tanto IPv4 como IPv6. De forma predeterminada, IPv6 se utiliza como transporte TCP para establecer una conexión LDP.

  • Adicional Configure la preferencia de transporte para una conexión LDP.

Procedimiento paso a paso
Resultados

Desde el modo de configuración, escriba el show protocols comando para confirmar la 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 independientes para IPv4 con un vecino IPv4 e IPv6 con un vecino IPv6.

Procedimiento paso a paso

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

  • Adicional Configure el transporte dual para permitir que LDP establezca la conexión TCP a través de IPv4 con vecinos IPv4, y a través de IPv6 con vecinos de IPv6 como LSR de pila única.

Resultados

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

Comproba

Confirme que la configuración funciona correctamente.

Verificación de las entradas de ruta en la tabla MPLS. 0
Purpose

Mostrar MPLS. 0 información de tabla de rutas.

Intervención

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

Efectos

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

Comprobar las entradas de ruta en la tabla inet. 3
Purpose

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

Intervención

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

Efectos

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

Comprobación de las entradas de ruta en la tabla inet 6.3
Purpose

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

Intervención

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

Efectos

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

Comprobando la base de datos LDP
Purpose

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

Intervención

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

Efectos

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

Comprobar la información de LDP Neighbor
Purpose

Mostrar la información de LDP Neighbor.

Intervención

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

Efectos

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

Comprobación de la información de sesión LDP
Purpose

Mostrar la información de sesión LDP.

Intervención

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

Efectos

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

Comproba

Confirme que la configuración funciona correctamente.

Comprobar la información de LDP Neighbor
Purpose

Mostrar la información de LDP Neighbor.

Intervención

En el dispositivo R1, desde el modo operativo, show ldp neighbor extensive ejecute el comando para que se muestre la información de LDP Neighbor.

Efectos

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

Comprobación de la información de sesión LDP
Purpose

Mostrar la información de sesión LDP.

Intervención

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

Efectos

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

Comproba

Confirme que la configuración funciona correctamente.

Comprobar la información de LDP Neighbor
Purpose

Mostrar la información de LDP Neighbor.

Intervención

En el dispositivo R1, desde el modo operativo, show ldp neighbor extensive ejecute el comando para que se muestre la información de LDP Neighbor.

Efectos

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

Comprobación de la información de sesión LDP
Purpose

Mostrar la información de sesión LDP.

Intervención

En el dispositivo R1, desde el modo operativo, show ldp session extensive ejecute el comando para que se muestre la información de LDP Neighbor.

Ejemplo Configuración de señalización dentro de banda de Multipoint LDP para LSP de punto a multipunto

Descripción de la señalización entre bandas de Multipoint LDP para LSP de punto a multipunto

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

Durante años, la solución más utilizada para el transporte de tráfico de multidifusión ha sido la utilización de multidifusión de IP nativa en el núcleo del proveedor de servicios con túnel de Multipoint IP para aislar el tráfico del cliente. Para configurar las rutas de reenvío, se ha implementado un protocolo de enrutamiento de multidifusión, normalmente multidifusión independiente del Protocolo (PIM). El enrutamiento de multidifusión IP se utiliza para el reenvío, mediante el uso de señales PIM en el núcleo. Para que este modelo funcione, la red principal debe tener habilitada la multidifusión. Esto permite implementaciones eficaces y estables incluso en escenarios de sistemas autónomos (AS).

Sin embargo, en una red existente de IP/MPLS, es posible que la implementación de PIM no sea la primera opción. Algunos proveedores de servicios están interesados en reemplazar el túnel IP con el MPLS encapsulación de etiquetas. Las motivaciones para cambiar MPLS etiquetas consisten en aprovechar las características MPLS de ingeniería de tráfico y protección, y en reducir la cantidad de sobrecarga de tráfico de control en el núcleo del proveedor.

Para ello, los proveedores de servicios están interesados en aprovechar la extensión de las implementaciones existentes para permitir que pase el tráfico de multidifusión. Las extensiones de multidifusión para IP/MPLS son extensiones punto a multipunto para extensiones de RSVP-TE y de punto a multipunto, así como Multipoint-to-multipoint para LDP. Estas situaciones de implementación se analizan en RFC 6826, Señalización en banda de LDP multipunto para rutas conmutadas de etiqueta de punto a multipunto y de varios puntos a multipunto. Este Resumen de características se limita a las extensiones punto a multipunto para LDP.

Funcionamiento de M-LDP

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

La extensión multipunto al LDP utiliza elementos de clase de equivalencia de reenvío de punto 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 del 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 del LSP. Cada nodo LDP anuncia su enlace de etiqueta local entrante al nodo LDP que precede en la cadena en la ruta más corta a la dirección IP raíz encontrada en la FEC. El nodo de nivel de flujo que recibe los enlaces de etiqueta crea su propia etiqueta local y sus interfaces de salida. Este proceso de asignación de etiquetas podría producir la replicación de paquetes, si hay varias bifurcaciones de salida. Como se muestra Figura 18en, un nodo LDP combina los enlaces de etiqueta para el mismo valor opaco si encuentra nodos indirectos que comparten el mismo nodo que precede en la cadena. Esto permite crear de forma eficaz los LSP de punto a multipunto y la conservación de las etiquetas.

Figura 18: Enlaces de etiqueta en M-señalización LDPEnlaces de etiqueta en M-señalización LDP
M-LDP en el núcleo de MPLS libres de PIM

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

Figura 19: Muestra M-topología LDP en el núcleo de MPLS libres de PIMMuestra M-topología LDP en el núcleo de MPLS libres de PIM
Automática

La instrucción mldp-inband-signalling de configuración en el enrutador de borde de etiqueta (ler) permite a PIM utilizar señalización en banda de M-LDP para los vecinos ascendentes cuando el ler no detecta un vecino que precede en la cadena. La configuración estática de la raíz del LSP de MPLS se incluye en la configuración de PIM, mediante el uso de políticas. Esto es necesario cuando IBGP no está disponible en el sitio principal o para ignorar la detección de raíz de LSP basada en la IBGP.

Por ejemplo:

M-LDP en el núcleo MPLS habilitado para PIM

A partir de la versión 14.1 de Junos OS, para migrar los servicios DE IP TV existentes de multidifusión IP nativa MPLS una multidifusión, 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 un origen que transmite todos los canales IPTV. Los canales de TV se envían como flujos de ASM con cada canal identificados por su dirección de grupo. Anteriormente, estos canales se transmitieron en el núcleo como secuencias IP y se señalaban mediante PIM.

Figura 20: M-topología LDP de ejemplo en el núcleo de MPLS habilitadas para PIMM-topología LDP de ejemplo en el núcleo de MPLS habilitadas para PIM

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

Automática

Para migrar progresivamente Channel por canal a M-LDP MPLS central con pocas secuencias que utilizan M-LDP ascendente y otras secuencias con PIM existente, incluya la selected-mldp-egress instrucción de configuración junto con filtros basados en grupos en el filtro de políticas para M-LDP señalización.

Nota:

El filtro de la Directiva de señalización entre bandas M-LDP puede source-address-filter incluir la instrucción route-filter o el extracto 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 ler. La configuración selected-mldp-egress de la instrucción en enrutadores PIM de no salida puede ocasionar errores en la configuración de la ruta.

  • Cuando se realizan cambios en la política de conmutación de tráfico de PIM ascendente a M-LDP ascendente y viceversa, se puede esperar que la pérdida de paquetes se realice en el plano de control.

Terminología

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

LSP de punto a punto

Un LSP que cuenta con un enrutador de entrada de etiqueta (LSR) y un LSR de salida.

LSP de Multipoint

Un LSP de punto a multipunto o de Multipoint-to-multipunto.

LSP de punto a multipunto

Un LSP que tiene una LSR de entrada y una o más LSRs de salida.

LSP de Multipoint-to-Point

Un LSP que tiene uno o varios LSRs de entrada y un LSR de salida único.

LSP de Multipoint-to-multipoint

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

Una LSR de entrada para un LSP en particular es una LSR que puede enviar un paquete de datos a través del LSP. Los LSP de Multipoint-to-multipoint pueden tener varios LSRs de entrada. Los LSP de punto a multipunto sólo tienen uno, y a menudo se hace referencia a ese nodo como nodo raíz.

LSR de salida

Un LSR de salida para un LSP determinado es un LSR que puede eliminar un paquete de datos de ese LSP para su procesamiento posterior. Los LSP de punto a punto y de Multipoint-to-Point solo tienen un único nodo de salida. Los LSP de punto a multipunto y de Multipoint-to-multipoint pueden tener varios nodos de salida.

LSR de tránsito

LSR que tiene posibilidad de acceso a la raíz del LSP de Multipoint a través de un LSR de entrada de flujo directa y uno o más LSRs de salida directamente conectados.

Bud LSR

Un LSR que es una salida pero que también tiene una o más LSRs de salida directa conectados directamente.

Nodo hoja

LSR de salida o Bud en el contexto de un LSP de punto a multipunto. En el contexto de un LSP de multipunto a multipunto, un LSR es ingreso y salida para el mismo LSP de Multipoint-to-multipunto y también puede ser un LSR.

Traducción de una combinación de entrada y un manejo de pseudo interfaces

En la LER de entrada, LDP notifica a PIM acerca de los mensajes que se reciben a través de la señalización dentro de banda. PIM lo asocia a cada (S, G) messagewith una pseudo interfaz. Posteriormente, se inicia un mensaje de unión de árbol de ruta de acceso más corta (de tres sentidos) hacia el origen. PIM lo trata como un nuevo tipo de receptor local. Cuando el LSP se deja de presionar, PIM quita este receptor local en función de la notificación de LDP.

Empalme de entrada

LDP proporciona PIM con un salto siguiente para asociarlo a cada entrada de (S, G). PIM instala una ruta de multidifusión PIM (S, G) con el siguiente salto LDP y otros receptores PIM. El siguiente salto es un próximo salto compuesto de receptores locales + la lista de vecinos de PIM posterior + a subnivel siguiente hopfor 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 una señalización en banda de M-LDP cuando se cumplen todas las condiciones siguientes:

  • No hay vecinos PIM hacia el origen.

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

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

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

PIM RPF registra esta dirección de origen cada vez que cambia la información de enrutamiento de unidifusión. Por lo tanto, si la ruta hacia el código cambia, el cálculo de RPF se repite. BGP protocolo a continuación se desplazan hacia el origen también se supervisan los cambios en la raíz del LSP. Estos cambios pueden ocasionar interrupciones en el tráfico durante las duraciones cortas.

Detección de raíz de LSP

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

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

  1. Si la configuración estática actual 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 de protocolo hacia el origen se utilizará como raíz del LSP.

    Antes de Junos OS versión 16,1, M-LSP de punto a multipunto de LDP se señaliza de salida a entrada a través de 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 precisa el LSP de punto a multipunto de M-LDP en un solo sistema autónomo. Si no se puede tener acceso a la dirección raíz a través de un IGP, sino que se puede tener acceso a través de BGP y si dicha ruta BGP se resuelve de forma recursiva en un LSP de MPLS, el LSP de punto a multipunto no se señaliza más allá desde ese punto hacia la dirección raíz LSR de entrada.

    Es necesario que estos LSP de punto a multipunto no segmentados se señalizan en varios sistemas autónomos, por lo que se pueden usar para las siguientes aplicaciones:

    • Inter-AS MVPN, con LSP de punto a multipunto no segmentados.

    • La señalización en banda entre "M-LDP" entre las redes de cliente conectadas por una red de MPLS Core.

    • Señalización a banda MVPN o inter-Area de forma LDP con LSP de punto a multipunto sin segmentar (perfecta MPLS multidifusión).

    A partir de Junos OS versión 16,1, M-LDP puede señalizar LSP de punto a multipunto en ASBR o de transmisión o salida cuando la dirección raíz es una ruta BGPda que se resuelve más recursivamente a través de un LSP de MPLS.

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

En el LER de salida, PIM notifica a LDP el mensaje (S, G) que debe señalizarse junto con la raíz del LSP. PIM crea una Pseudointerfaz como la interfaz de entrada de flujo para este mensaje (S, G). Cuando se recibe un mensaje de eliminación, se quita esta asociación.

Empalmes de salida

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

Funcionalidad compatible

En el caso de la señalización en banda de M-LDP, Junos OS admite la siguiente funcionalidad:

  • Salida de empalmes del siguiente salto PIM con la ruta LDP

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

  • Traducción de mensajes de unión de PIM a parámetros de instalación de punto a multipunto de proveedores de LPD

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

  • Protocolos configurados estáticamente y BGP detección de raíz de LSP basada en el próximo salto

  • Estados de PIM (S, G) en los rangos de multidifusión (SSM) y anysource multicsast (ASM) específicos del origen PIM

  • Instrucciones de configuración sobre entrada y salida LERs que les permita actuar como enrutadores de borde

  • Mensajes de Unión IGMP en LERs

  • Transporte de direcciones de origen y de grupo de IPv6 como información opaca hacia un nodo raíz de IPv4

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

Funcionalidad no compatible

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

  • Soporte completo para PIM ASM

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

  • Enrutamiento activo no detenido INE

  • Activar antes de interrumpir (MBB) para PIM

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

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

  • Reinicio correcto

  • Modo de la densidad PIM

  • Modo bidireccional PIM

Funcionalidad LDP

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

Funcionalidad de LER de salida

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

  • Nodo raíz

  • (S, G)

  • Próximo salto

PIM busca el nodo raíz en función del 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 de LSP de punto a multipunto. De lo contrario, la tabla de enrutamiento se utilizará para buscar la ruta hacia el origen. Si la ruta al origen del árbol de multidifusión es una ruta aprendida BGP, PIM recupera la BGP dirección del siguiente salto y la utiliza como nodo raíz para el LSP de punto a multipunto.

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

Si las direcciones raíz del origen del árbol de multidifusión cambian, PIM elimina el LSP de punto a multipunto e desencadena LDP para crear un nuevo LSP de punto a multipunto. Cuando esto ocurre, la lista de interfaces salientes se convierte en nula, PIM desencadena que LDP elimine el LSP de punto a multipunto y LDP envía un mensaje de retirada de etiqueta al nodo de nivel superior.

Funcionalidad de LSR de tránsito

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

Funcionalidad de LER de entrada

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

  • (S, G)

  • Desbordar el siguiente salto

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

Ejemplo Configuración de señalización dentro de banda de Multipoint LDP para LSP de punto a multipunto

Este ejemplo muestra cómo configurar la señalización dentro de banda de Multipoint LDP (M-LDP) para el tráfico de multidifusión, como una extensión del Protocolo de multidifusión independiente del Protocolo (PIM) o como un sustituto de PIM.

Aplicables

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

  • Junos OS versión 13,2 o posterior

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

  • serie PTX enrutadores de transporte de paquetes que actúan como enrutadores con etiqueta de tránsito

  • serie T enrutadores principales para los enrutadores principales

Nota:

Los enrutadores de PE también podrían ser serie T enrutadores principales, pero esto no suele ser habitual. Dependiendo de los requisitos de escala, los enrutadores principales también podrían ser de serie MX 5G de enrutamiento universal o de M Series enrutadores de borde de multiservicio. Los dispositivos de perímetro del cliente (CE) pueden ser otros enrutadores o conmutadores de Juniper Networks u otro proveedor.

No es necesaria 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 CLImuestra la configuración de todos los dispositivos de Figura 21. En esta #d517e60__d517e616 sección se describen los pasos en EgressPE de dispositivo.

Figura 21: M: señalización en banda de LDP para la topología de ejemplo de LSP de punto a multipuntoM: señalización en banda de LDP para la topología de ejemplo de LSP de punto a multipunto

Automática

Modalidades
Configuración rápida de CLI

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

Dispositivo SRC1

Dispositivo IngressPE

Dispositivo EgressPE

Dispositivo P6

Dispositivo PR3

Dispositivo PR4

Dispositivo PR5

Procedimiento paso a paso

El ejemplo siguiente requiere que se exploren varios niveles en la jerarquía de configuración. Para obtener más información sobre Cómo desplazarse por la CLI, consulte uso del editor de CLI en el modo de configuración en la Guía del usuario de CLI.

Para configurar EgressPE de dispositivos:

  1. Configure las interfaces.

    Habilitar la MPLS en las interfaces de conexión a núcleo. En los saltos siguientes, no es necesario activar MPLS.

  2. Configure IGMP en las interfaces de salida.

    Para propósitos de prueba, este ejemplo incluye las direcciones estáticas de grupo y de origen.

  3. Configure MPLS en las interfaces principales.

  4. Configure BGP.

    BGP es un protocolo impulsado por políticas, por lo que también debe configurar y aplicar las políticas de enrutamiento que sean necesarias.

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

  5. Adicional Configure una conexión de MSDP peer con el dispositivo PR5 para poder interconectar los distintos dominios PIM, con lo que habilita RPs redundantes.

  6. Configure OSPF.

  7. Configure LDP en las interfaces de conexión a núcleo y en la interfaz de bucle de retroceso.

  8. Habilite los LSP de MPLS punto a multipunto.

  9. Configure PIM en las interfaces de salida de flujo.

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

  11. Habilite M-señalización en banda LDP y configure la directiva asociada.

  12. Configure la Directiva 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 identificador de sistema autónomo (AS).

Resultados

Desde el modo de configuración, para confirmar la configuración show interfaces, show protocolsescriba show policy-optionslos comandos show routing-options ,, y. Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.

Dispositivo EgressPE

Del mismo modo, configure el resto de dispositivos de salida.

Si ha terminado la configuración de los dispositivos, commit entre en el modo de configuración.

Comproba

Confirme que la configuración funciona correctamente.

Comprobación de los Estados de unión de PIM
Purpose

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

Intervención

En modo operativo, escriba el show pim join extensive comando.

Comprobación de las fuentes PIM
Purpose

Compruebe que el origen PIM tenga los detalles de M-LDP en banda ascendente y descendente que se esperan.

Intervención

En modo operativo, escriba el show pim source comando.

Comprobando la base de datos LDP
Purpose

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

Intervención
Buscar la información de ruta de la etiqueta de MPLS
Purpose

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

Intervención
Comprobando las estadísticas de tráfico LDP
Purpose

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

Intervención

Servidor de asignación LDP para la interoperabilidad del enrutamiento de segmentos con la información general de LDP

En una red LDP con implementación gradual del enrutamiento en segmentos, pueden existir islas de dispositivos que admitan solo LDP o solo el enrutamiento en segmentos. Para que los dispositivos funcionen correctamente, es necesario que la característica del servidor de asignación LDP esté configurada en cualquier dispositivo de la red de enrutamiento de segmentos.

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

Interoperabilidad del enrutamiento de segmentos con LDP mediante OSPF

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

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

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

En la topología anterior, los dispositivos R1, R2 y R3 solo son capaces de enrutar segmentos, los dispositivos R5 y R6 solo son capaces de utilizar LDP, y el dispositivo R4 admite enrutamiento en segmentos y LDP. Aquí, Device R1 no puede interfuncionar con el dispositivo R6 debido a problemas de interoperabilidad.

Para habilitar la interoperabilidad entre los dispositivos compatibles con LDP y los dispositivos de enrutamiento de segmentos, cualquier interfaz del dispositivo en el segmento de red de enrutamiento de segmentos está configurada como servidor de asignación 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, la configuración del servidor de asignación LDP, si [edit protocols ospf] se aplica bajo el nivel de la jerarquía, en la que OSPF anuncia un nuevo prefijo extendido LSA con TLV del intervalo para todos los prefijos LDP. El dispositivo capaz de enrutar el segmento analice las rutas del TLV del rango de prefijos extendidos y la asignación correspondiente al prefijo instalado en inet. 3 y MPLS. 0 tablas de enrutamiento.

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

Nota:

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

Cuando la configuración del servidor de asignación LDP se confirma en el dispositivo R2, el TLV del intervalo de prefijos extendidos se inunda a través del área OSPF. Los dispositivos capaces de enrutar segmentos (dispositivos R1, R2 y R3) instalan OSPF rutas de enrutamiento de segmentos para la dirección de bucle de retorno especificada con un índice ID de segmento (SID). El índice de SID también se actualiza en la tabla de enrutamiento MPLS. 0 por los dispositivos de enrutamiento del segmento.

A partir de la Junos OS de la versión 19.1 R1, enrutamiento de segmentos-enrutador de borde LDP puede unir el tráfico de enrutamiento de segmentos a LDP Next-hop y viceversa.

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

  • Los conflictos de prefijo solo se detectan en la configuración de origen. Cuando hay un conflicto de intervalo de prefijo, prevalecerá el SID de prefijo del identificador de enrutador inferior. En tales casos, se genera un mensaje de error de registro RPD_OSPF_PFX_SID_RANGE_CONFLICT del sistema.

  • No se admiten prefijos IPv6.

  • No se admite la inundación de OSPF prefijos extendidos LSA generados por el servidor de asignación de enrutamiento de segmentos para sistemas autónomos (Asoc).

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

  • ABR (funcionalidad) del prefijo extendido LSA no compatible.

  • Funcionalidad de ASBR del prefijo extendido LSA no compatible.

  • No se admite el TLV de preferencia de servidor de asignación de segmentos.

Interoperabilidad del enrutamiento de segmentos con LDP utilizando ISIS

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

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

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

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

Para que un flujo de servicio pueda canalizarse hacia y desde el PE3 del dispositivo y el PE1 del dispositivo utilizando un túnel de MPLS continuo, las islas de dispositivos que admiten enrutamiento de segmentos y LDP deben interoperar.

LDP Mapping Client Functionality (LDP to Segment Routing)

La funcionalidad del cliente LDP se corresponde con la asignación de enrutamiento LDP-to-Segment, en la que se encuentra el flujo Figura 23de tráfico de derecha a izquierda. En el dispositivo P6, se configura una directiva de salida LDP para anunciar todos los SID de nodo y los de prefijos de los SID de la red de enrutamiento de segmentos a la izquierda. Como resultado, en Device P6, LDP anuncia los dispositivos PE1, PE2 y P5 como los enlaces de etiqueta FEC de salida a los P7 de dispositivo.

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

El dispositivo P7 cuenta con un enlace LDP Label from su próximo salto P6 el PE1 FEC, como resultado, el dispositivo P7 reenvía al dispositivo P6 como según el comportamiento clásico de LDP.

El P6that del dispositivo actúa como salida LDP para el PE1 FEC, y une y intercambia la etiqueta LDP de entrada de salida de PE1 FEC con un SID de nodo de enrutamiento de segmento equivalente (en este ejemplo, 101) para reenviar el tráfico al Device P5.

El dispositivo P5 extra 101 SID suponiendo que el PE1 de dispositivo anunció su segmento de nodo 101 con el penúltimo indicador establecido y, a continuación, reenvía el tráfico al dispositivo PE1. Dispositivo PE1receives el paquete de túnel y procesa la etiqueta de servicio.

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

LDP Mapping Server Functionality (Segment Routing to LDP)

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

Aquí, el dispositivo P6 actúa como 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 admitía enrutamiento de segmentos en el dispositivo PE3, el SID del nodo 103 se habría configurado en el dispositivo PE3. Dado que PE3 de dispositivos no admite el enrutamiento de segmentos, la Directiva se configura en el SRMS en el dispositivo P6, mientras que el dispositivo P6 es responsable de anunciar las asignaciones.

Los anuncios de servidor de asignación sólo los entienden los dispositivos de enrutamiento de segmentos. Los dispositivos de enrutamiento de segmento instalan los SID de nodo relacionados en el MPLS plano de datos exactamente cómo los nodos ellos mismos habían anunciado los segmentos de nodo. Por ejemplo, PE1 de dispositivo instala el SID de nodo 103 con P5 Next hop exactamente igual que si Device PE3 hubiera anunciado el SID 103.

El dispositivo PE1 tiene una ruta de servicio con PE3 como protocolo siguiente. El dispositivo PE1 tiene un segmento de nodo para IGP ruta: 103 con el próximo salto 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. Device P5 intercambia el 103 para 103 y lo reenvía al dispositivo P6. El próximo salto del dispositivo P6 es el IGP Route PE3, que no es capaz de enrutarse en segmentos. (El P7 del dispositivo no anuncia la capacidad de enrutamiento del segmento). Sin embargo, el dispositivo P6 tiene un enlace de etiqueta LDP del siguiente salto para la misma FEC (por ejemplo, la etiqueta LDP 1037). Como resultado, en el dispositivo P6, el IGP intercambia 103 para 1037 y lo reenvía al dispositivo P7.

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

El dispositivo PE3 recibe el paquete de túnel y procesa la etiqueta de servicio. El túnel de MPLS de extremo a extremo se crea a partir de un nodo de enrutamiento de segmento desde los dispositivos PE1 hasta P6, y un LSP de LPD desde los dispositivos P6 a PE3.

Segment Routing to LDP Stitching

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

Figura 24ilustra la Unión de enrutamiento de segmentos y LSP de LDP para permitir la interoperabilidad.

Figura 24: Engrapando enrutamiento de segmentos y LSP de LDPEngrapando enrutamiento de segmentos y LSP de LDP

En la topología, el PE3 de dispositivo es compatible con LDP y no admite el enrutamiento de segmentos. El servidor de asignación del dominio de enrutamiento del segmento puede anunciar el TLV de enlace de etiqueta para los dispositivos P7, P8 y PE4. En este escenario, el PE1 del dispositivo puede tener el SID de prefijo y el TLV de enlace de etiqueta remota y el SID para llegar al dispositivo PE4. Sin embargo, Device PE1 prefiere el prefijo SID sobre el TLV de la etiqueta de enlace remoto mientras programa su ruta de enrutamiento de segmento de entrada para el dispositivo PE4. Como resultado, el dispositivo PE1 usa el LSP de enrutamiento de segmentos de extremo a extremo para enviar tráfico al dispositivo PE4, y utiliza el modo segmentar enrutar 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 un penúltimo salto para Label Binding TLV.

  • No se admite la publicidad de una variedad de prefijos en el TLV de enlace de etiqueta.

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

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

  • No se admite el enrutamiento activo no detenido (INE) ni el cambio motor de enrutamiento correcto (en ingreso).

  • No se admite la internivelación de ISIS.

  • RFC 7794, no se admite SI-SI de prefijo para IPv4 extendido.

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

Configuración de varias propiedades LDP

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

Configuración de LDP para usar la métrica de ruta IGP

Utilice la 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 track-igp-metric 1).

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

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

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

Mediante la configuración no-forwarding de la instrucción, es posible evitar que las rutas de entrada se agreguen a la tabla de enrutamiento inet. 0 en vez de la tabla de enrutamiento inet. 3 traffic-engineering bgp-igp , incluso si [edit protocols mpls] se ha [edit logical-systems logical-system-name protocols mpls] habilitado la instrucción en el nivel de o en la jerarquía. De forma predeterminada, no-forwarding la instrucción está deshabilitada.

Nota:

Serie ACX enrutadores no admitenedit logical-systemsel nivel de jerarquía [].

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

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

Redes privadas virtuales LDP y operadora de operadores de varias instancias

Mediante la configuración de varias instancias de enrutamiento LDP, puede utilizar LDP para anunciar etiquetas en una red privada virtual (VPN) de operadora de transporte desde un enrutador de extremo de proveedor de servicios de servicio (PE) al enrutador de borde de cliente (CE) del operador del cliente. Esto es especialmente útil cuando el cliente de la operadora es un proveedor de servicios Internet (ISP) básico y desea restringir las rutas de Internet completas a sus enrutadores PE. Con el uso de LDP en lugar de BGP, el cliente de la portadora protege sus otros enrutadores internos de Internet. El LDP de varias instancias también resulta útil cuando un cliente de operadora desea proporcionar servicios VPN de capa 2 o capa 3 a sus clientes.

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

Configurar MPLS e LDP para que exabran la etiqueta en el enrutador de salto final

La etiqueta anunciada predeterminada es etiqueta 3 (etiqueta nula implícita). Si se anuncia la etiqueta 3, el enrutador de penúltimo salto quitará la etiqueta y enviará el paquete al enrutador de salida. Si se habilita la expropiación del salto final, se anunciará la etiqueta 0 (etiqueta null explícita IPv4). El emergemiento de saltos de última fin garantiza que cualquier paquete que atraviese una red MPLS incluirá una etiqueta.

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

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

Nota:

Juniper Networks enrutadores envían paquetes en cola en función de la etiqueta entrante. Los enrutadores de otros proveedores pueden poner en cola los paquetes de manera diferente. Tenga esto en cuenta cuando trabaje con redes que contengan enrutadores de varios proveedores.

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

Habilitar LDP sobre LSP establecidos por RSVP

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

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

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

Otros proveedores utilizan una métrica OSPF de 1 para la dirección de bucle invertido. Juniper Networks enrutadores utilizan una métrica OSPF de 0 para la dirección de bucle invertido. Esto podría requerir la configuración manual de la métrica de RSVP cuando se implemente un túnel LDP sobre LSP de RSVP en redes heterogéneas.

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

Para asegurarse de que el túnel LDP funciona correctamente en redes heterogéneas, puede configurar OSPF para ignorar la métrica de LSP de RSVP ignore-lsp-metrics si incluye la siguiente declaración:

Puede configurar esta instrucción en los siguientes niveles de jerarquía:

  • [edit protocols ospf traffic-engineering shortcuts]

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

Nota:

Serie ACX enrutadores no admitenedit logical-systemsel nivel de jerarquía [].

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

Configuración de la firma TCP MD5 para sesiones LDP

Puede configurar una firma MD5 para una conexión TCP LDP con el fin de protegerse contra la introducción de segmentos TCP suplantados en las secuencias de conexiones de sesión LDP.

Un enrutador que utilice la opción de firma MD5 se configura con una contraseña para cada equipo del mismo nivel para el que se requiere autenticación. La contraseña se almacena de forma cifrada.

Las adyacencias de LDP se pueden seguir creando incluso cuando las interfaces de interconexión se configuran con distintas firmas de seguridad. Sin embargo, no se puede autenticar la sesión TCP y nunca se establece.

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

La compatibilidad con autenticación de coincidencia de subred proporciona flexibilidad a la hora de configurar la autenticación para sesiones LDP (TLDP) dirigidas automáticamente, lo que hace que la implementación de alternativas libres de bucles remotos (LFA) y FEC 129 pseudowires sencilla.

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

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

El md5-authentication-key valor de la (contraseña) puede ser de hasta 69 caracteres. Los caracteres pueden incluir cualquier cadena ASCII. Si incluye espacios en blanco, incluya todos los caracteres entre comillas.

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

Para configurar el mecanismo de actualización de claves de autenticación key-chain , incluya la [edit security authentication-key-chains] instrucción en el nivel de la key jerarquía y especifique la opción de crear una cadena clave que se componga 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 instrucción en el nivel de jerarquía para asociar el protocolo authentication-key-chain con las claves de [edit protocols ldp][edit security authentication-key-chains] autenticación. También debe configurar el algoritmo de autenticación incluyendo la authentication-algorithm algorithm instrucción el nivel de [edit protocols ldp] jerarquía.

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

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

Una sesión LDP suele crearse entre un par de enrutadores conectados por uno o varios vínculos. Los enrutadores forman una proximidad de saludo para cada vínculo que los conecta y asocia todas las adyacencias con la sesión LDP correspondiente. Cuando la adyacencia del último saludo de una sesión de LDP desaparece, la sesión LDP finaliza. Es posible que desee modificar este comportamiento para evitar que una sesión LDP finalice innecesariamente y se restablezca.

Puede configurar el Junos OS para dejar la sesión LDP entre dos enrutadores, incluso si no hay coyacencia 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 permanecerá durante el tiempo especificado mientras los enrutadores mantienen la conectividad de red IP.

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

Deshabilitación de capturas SNMP para LDP

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

Para obtener más información acerca de las capturas SNMP de LDP y el BIA LDP patentado, consulte el Snmp BIA Explorer..

Para desactivar las interrupciones SNMP para LDP, especifique trap disable la opción de log-updown la instrucción:

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

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

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

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

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

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

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

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

Puede configurar el tiempo de espera de LDP antes de informar al IGP que el vecino o la sesión LDP para una interfaz están operativos. En el caso de redes de gran tamaño con numerosas FECs, es posible que tenga que configurar un valor más largo para disponer de tiempo suficiente para que se intercambien las bases de datos de etiquetas LDP.

Para configurar el tiempo de espera de LDP antes de informar al IGP que el vecino o la sesión LDP están operativos, incluya la igp-synchronization instrucción y especifique el 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 Resumen de extractos de este extracto.

Configuración del temporizador de retirada de etiqueta

El temporizador de retirada de etiquetas retrasa el envío de un mensaje de revocación de etiqueta para una FEC a un vecino. Cuando se produce un error en un vínculo de IGP a un vecino, la etiqueta asociada con la FEC debe ser retirada de todos los enrutadores en dirección ascendente si el vecino es el siguiente salto de FEC. Una vez que el IGP converge y se recibe una etiqueta desde un nuevo salto, la etiqueta se vuelve a anunciar a todos los enrutadores en secuencia ascendente. Este es el comportamiento típico de la red. Al retrasar la retirada de la etiqueta en un poco de tiempo (por ejemplo, hasta que el IGP converge y el enrutador recibe una nueva etiqueta para la FEC del próximo salto siguiente), la retirada de etiqueta y el envío de una asignación de etiqueta pronto podrían evitarse. La label-withdrawal-delay instrucción le permite configurar este tiempo de retraso. De forma predeterminada, la demora es de 60 segundos.

Si el enrutador recibe la nueva etiqueta antes de que el cronómetro se agote, el temporizador de retirada de etiqueta se cancela. Sin embargo, si el temporizador se agota, la etiqueta de la FEC se retira de todos los enrutadores que preceden en la cadena.

De forma predeterminada, 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 la etiqueta en cuestión de 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 Resumen de extractos de este extracto.

Omitiendo la comprobación de subred LDP

En Junos OS versión 8.4 y versiones posteriores, se realiza una comprobación de subred de dirección de origen LDP durante el procedimiento de establecimiento vecino. La dirección de origen del paquete de saludo de LDP Link se compara con la dirección de interfaz. Esto provoca un problema de interoperabilidad con el equipo de otros proveedores.

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

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

  • [edit protocols ldp interface interface-name]

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

Nota:

Serie ACX enrutadores no admitenedit logical-systemsel nivel de jerarquía [].

Configurando traceroute LSP de LDP

Puede rastrear la ruta seguida de un LSP señalado por LDP. El traceroute LDP LSP se basa en RFC 4379, detectar fallas en el plano de datos de etiquetas de varios protocolos (MPLS). Esta característica le permite realizar un seguimiento periódicamente de todas las rutas de la FEC. La información de topología de FEC se almacena en una base de datos a la que se puede tener acceso desde la CLI.

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

La característica de Traceroute periódico se aplica a todos los FECs oam especificados por la [edit protocols ldp] instrucción configurada en el nivel de jerarquía. Para configurar el traceroute periódico de un LSP de periodic-traceroute LDP, incluya el extracto:

Puede configurar esta instrucción en los siguientes niveles de jerarquía:

  • [edit protocols ldp oam]

  • [edit protocols ldp oam fec address]

Puede configurar el periodic-traceroute extracto por sí solo o por cualquiera de las siguientes opciones:

  • exp: especifique las clase de servicio que se deben usar al enviar los sondeos.

  • fanout: permite especificar la cantidad máxima de saltos siguientes que se buscarán por nodo.

  • frequency: permite especificar el intervalo entre los intentos de traceroute.

  • paths: permite especificar la cantidad máxima de rutas que se buscarán.

  • retries: especifique la cantidad de intentos de enviar un sondeo a un nodo específico antes de renunciar.

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

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

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

Recopilando estadísticas LDP

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

Cuando configure la traffic-statistics instrucción en el [edit protocols ldp] nivel de la jerarquía, las estadísticas de tráfico LDP se recopilarán periódicamente y se escribirán en un archivo. Puede configurar la frecuencia con la que se recopilan las estadísticas (en segundos) con 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 recopilarán las estadísticas de tráfico LDP. Si el LSP deja de funcionar, se restablecerán las estadísticas de LDP.

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

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

Esta sección incluye los siguientes temas:

Salida de estadísticas LDP

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

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

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

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

  • Packets: número de paquetes pasados por la FEC desde que su LSP llegó.

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

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

  • read: este número (que aparece junto a la fecha y la hora) puede diferir del número real de las estadísticas mostradas. Algunas de las estadísticas están resumidas antes de mostrarse.

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

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

Para obtener una lista de los niveles de jerarquía en los que traffic-statistics puede configurar la instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

Nota:

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

Cada vez que se incluye o quita esta opción de la configuración, las sesiones LDP se desactivan y luego se reinician.

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

Limitaciones de las estadísticas LDP

A continuación se enumeran problemas relacionados con la recopilación de estadísticas traffic-statistics de LDP mediante la configuración de la instrucción:

  • No puede borrar las estadísticas LDP.

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

  • No se puede iniciar una nueva operación de recopilación de estadísticas LDP hasta que haya finalizado la anterior. Si el intervalo es corto o si el número de estadísticas de LDP es grande, es posible que el intervalo de tiempo entre las dos colecciones de estadísticas sea más largo.

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

Seguimiento del tráfico del 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 del protocolo LDP, puede especificar opciones en traceoptions la instrucción global [edit routing-options] en el nivel de la jerarquía y especificar opciones específicas de LDP incluyendo la traceoptions instrucción:

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección de Resumen de Estados de cuenta de este extracto.

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

Los siguientes indicadores de traza muestran las operaciones asociadas con el envío y la recepción de varios mensajes LDP. Cada uno de los cuales puede contener uno o varios de los siguientes modificadores:

  • address: permite rastrear la operación de los mensajes de retirada de direcciones y direcciones.

  • binding: seguimiento de operaciones de vinculación de etiquetas.

  • error: condiciones de error de seguimiento.

  • event: seguimiento de eventos de protocolo.

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

  • label: permite rastrear el funcionamiento de la solicitud de etiqueta, el mapa de etiquetas, la retirada de etiquetas y los mensajes de versión de la etiqueta.

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

  • packets: permite rastrear la operación de dirección, retirada de dirección, inicialización, solicitud de etiqueta, asignación de etiquetas, retirada de etiquetas, publicación de etiquetas, notificación y mensajes periódicas. Este modificador equivale a establecer los addressmodificadores initialization, labelnotification, y y periodic .

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

  • path— Trace las operaciones de ruta conmutadas por etiquetas.

  • path— Trace las operaciones de ruta conmutadas por etiquetas.

  • periodic: permite rastrear la operación de los mensajes de saludo y keepa live.

  • route: permite rastrear el funcionamiento de los mensajes de ruta.

  • state: transiciones de estado de protocolo de seguimiento.

Seguimiento del tráfico de protocolo LDP dentro de FECs

LDP asocia una clase de equivalencia de reenvío (FEC) a cada LSP que crea. La FEC asociada con un LSP especifica qué paquetes se han asignado a ese LSP. Los LSP se extienden a través de una red ya que cada enrutador elige la etiqueta anunciada por el siguiente salto para FEC y la marca hacia la etiqueta que anuncia al resto de enrutadores.

Puede rastrear el tráfico de protocolo LDP dentro de un FEC específico y filtrar las instrucciones de seguimiento LDP basadas en FEC. Esto resulta útil cuando se desea rastrear o solucionar problemas de tráfico de protocolo LDP asociado con FEC. Para este fin, están disponibles las siguientes marcas de traza: route, path, y binding.

El siguiente ejemplo muestra cómo configurar la instrucción LDP traceoptions para filtrar instrucciones de seguimiento LDP basadas en un FEC:

Esta característica tiene las siguientes limitaciones:

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

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

  • Cuando configure tanto el seguimiento como el filtrado, no se mostrarán MPLS rutas (bloqueadas por el filtro).

  • La Directiva y el valor configurado de la match-on opción determinan el filtrado. Al configurar la Directiva, 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 directiva que debe incluirse es una directiva de filtro de enrutamiento.

Cita Seguimiento del tráfico del protocolo LDP

Rastrear con todo detalle los mensajes de ruta LDP:

Seguimiento de todos los mensajes salientes de LDP:

Seguimiento de todas las condiciones de error LDP:

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

Seguimiento del tráfico de protocolo LDP para obtener una FEC asociada con el LSP:

Tabla de historial de versiones
Liberación
Descripción
19.1
A partir de la Junos OS de la versión 19.1 R1, enrutamiento de segmentos-enrutador de borde LDP puede unir el tráfico de enrutamiento de segmentos a LDP Next-hop y viceversa.
16.1R1
A partir de Junos OS versión 16.1 R1, se extiende la compatibilidad con el código de autenticación de mensajes hash (HMAC) y la autenticación MD5 para las sesiones LDP desde una configuración por sesión a una configuración de coincidencia de subred (es decir, coincidencia con un prefijo más largo).
16.1
A partir de Junos OS versión 16,1, M-LDP puede señalizar LSP de punto a multipunto en ASBR o de transmisión o salida cuando la dirección raíz es una ruta BGPda que se resuelve más recursivamente a través de un LSP de MPLS.
14.1
A partir de Junos OS versión 14,1, para migrar servicios IPTV existentes desde Native IP multimulticast a MPLS multicast, es necesario realizar una transición sin problemas desde un PIM a M: LSP de punto a multipunto con un mínimo de interrupciones.