Configuración de LDP

Configurar el temporizador de LDP para mensajes de saludo de vínculo

Para modificar la frecuencia con la que LDP envía mensajes de saludo de vínculo, especifique un nuevo intervalo de mensajes de saludo de vínculo para el temporizador de LDP mediante la hello-interval instrucció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 para esta instrucción.

Configurar el temporizador de LDP para mensajes de saludo dirigidos

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

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

Configurar el tiempo de espera de LDP para mensajes de saludo de vínculo

Para modificar cuánto tiempo debe esperar un nodo LDP a un mensaje de saludo de vínculo antes de declarar que el vecino está inactivo, especifique un nuevo tiempo en segundos mediante la hold-time instrucció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 para esta instrucción.

Configurar el tiempo de espera de LDP para mensajes de saludo dirigidos

Para modificar cuánto tiempo debe esperar un nodo LDP a recibir un mensaje de saludo específico antes de declarar que el vecino está inactivo, especifique un nuevo tiempo en segundos utilizando la hold-time instrucción como una opción para la targeted-hello 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 instrucciones para estas instrucciones.

Habilitación de un reinicio virtuoso

Para habilitar el reinicio correcto de LDP, también debe habilitar el reinicio correcto en el enrutador. Para habilitar el reinicio normal, incluya la graceful-restart 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]

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

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

Deshabilitar el modo auxiliar o el reinicio elegante de LDP

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 Resumen de instrucciones para esta instrucción.

Solo puede deshabilitar el modo auxiliar solo en el nivel de protocolos LDP. No puede deshabilitar el modo auxiliar para una instancia de enrutamiento específica. Para deshabilitar el modo auxiliar de LDP, incluya la helper-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 Resumen de instrucciones para esta instrucción.

Son posibles las siguientes configuraciones de reinicio correcto de LDP:

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

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

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

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

Configuración del tiempo de reconexión

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

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

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

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

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

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

El tiempo de recuperación es la cantidad de tiempo que un enrutador espera 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 también suele ser la cantidad de tiempo que un enrutador vecino mantiene su información sobre el enrutador de reinicio, lo que le permite continuar reenviando 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 de reinicio, puede configurar el tiempo máximo de recuperación en el enrutador vecino. Un enrutador vecino mantiene su estado por el más corto de los dos tiempos. Por ejemplo, el enrutador A está realizando un reinicio satisfactorio de LDP. Ha enviado un tiempo de recuperación de 900 segundos al enrutador B vecino. Sin embargo, el enrutador B tiene su tiempo máximo de recuperación configurado en 400 segundos. El enrutador B solo esperará 400 segundos antes de purgar su información de LDP del enrutador A.

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

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

Ejemplos: Filtrado de enlaces de etiquetas de LDP entrantes

Acepte solo prefijos /32 de todos los vecinos:

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

Ejemplos: filtrado de enlaces de etiquetas de LDP salientes

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

Enviar solo 131.108/16 o más al ID del 10.10.255.2enrutador y enviar todos los prefijos a todos los demás enrutadores:

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

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

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

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

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

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

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

Preferencia de dirección de transporte

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

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

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

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

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

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

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

5. Dirección predeterminada.

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

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

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

3. Dirección predeterminada.

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

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

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

3. Dirección predeterminada.

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

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

• show ldp session

• show ldp neighbor

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

• show configuration protocols ldp

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

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

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

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

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

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

Ejemplo: Configuración de los prefijos anunciados en LDP

Anunciar todas las rutas conectadas en LDP:

Descripción general de MoFRR

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

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

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

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

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

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

Figura 12: Topología de muestra de MoFRR

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

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

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

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

LDP multipunto MoFRR se utiliza en el dispositivo de salida de una red MPLS, donde los paquetes se reenvían a una red IP. Con LDP MoFRR multipunto, el dispositivo establece dos rutas hacia el dispositivo de enrutamiento de PE ascendente para recibir dos flujos de paquetes MPLS en el LER. El dispositivo acepta una de las secuencias (la principal) y la otra (la copia de seguridad) se coloca 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 requisito previo para MoFRR con LDP multipunto (consulte Descripción de la señalización en banda de LDP multipunto para LSP punto a multipunto).

Funcionalidad de PIM

Junos OS admite MoFRR para uniones de árbol de ruta más corta (SPT) en PIM, multidifusión específica de fuente (SSM) y multidifusión de cualquier fuente (ASM). MoFRR es compatible con los rangos SSM y ASM. Para habilitar MoFRR para uniones (*,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 operará para (S,G) o (*,G), pero no para ambos. (S,G) siempre tiene prioridad sobre (*,G).

Con MoFRR habilitado, un dispositivo de enrutamiento PIM propaga mensajes de unión en dos interfaces ascendentes de reenvío de ruta inversa (RPF) para recibir tráfico de multidifusión en ambos vínculos para la misma solicitud de unión. MoFRR da preferencia a dos rutas que no convergen al mismo dispositivo de enrutamiento ascendente inmediato. PIM instala rutas de multidifusión apropiadas con RPF ascendente, próximos saltos 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 el equilibrio de carga de unión PIM (consulte la join-load-balance automatic declaración). Sin embargo, en ese caso, la distribución de mensajes de unión entre los vínculos podría no ser uniforme. Cuando se agrega un nuevo vínculo ECMP, los mensajes de unión en la ruta principal se redistribuyen y equilibran la carga. Es posible que los mensajes de combinación de la ruta de acceso de copia de seguridad sigan la misma ruta y no se redistribuyan de manera uniforme.

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

Cuando un dispositivo de enrutamiento PIM de salida recibe un mensaje de unión o un informe IGMP, 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 unión ascendente hacia un vecino ascendente (por ejemplo, el plano 2 en la Figura 12).

• Si la configuración MoFRR está presente, el dispositivo busca 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, el PIM envía un mensaje de unión ascendente hacia un vecino ascendente (por ejemplo, el plano 2 de la Figura 12).

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

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

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

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

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

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

Funcionalidad de LDP multipunto

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

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

Una clase de equivalencia de reenvío (FEC) es un grupo de paquetes IP que se reenvían de la misma manera, en la misma ruta y con el mismo tratamiento de reenvío. Normalmente, la etiqueta que se coloca en un paquete determinado representa la FEC a la que está asignado ese paquete. En MoFRR, se colocan dos rutas en la tabla mpls.0 para cada FEC: una ruta para la etiqueta principal y la otra ruta para la etiqueta de respaldo.

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

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

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

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

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

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

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

Reenvío de paquetes

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

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

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

Para PIM, cada flujo de multidifusión IP contiene la misma dirección de destino. Independientemente de la interfaz a la que lleguen los paquetes, estos tienen la misma ruta. El dispositivo comprueba la interfaz a la que llega cada paquete y reenvía solo los que provienen de la interfaz principal. Si la interfaz coincide con una interfaz de flujo de respaldo, el dispositivo descarta los paquetes. Si la interfaz no coincide con la interfaz de flujo principal o de respaldo, el dispositivo maneja los paquetes como excepciones en el plano de control.

En la Figura 13 se muestra este proceso con ejemplos de interfaces principales y de respaldo para enrutadores con PIM. La Figura 14 muestra esto de manera similar para los conmutadores con PIM.

Figura 13: Búsqueda de ruta IP MoFRR en el motor de reenvío de paquetes en enrutadores

Figura 14: Manejo de rutas IP MoFRR en el motor de reenvío de paquetes en conmutadores

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

En la figura 15 , se muestra este proceso para enrutadores con LDP multipunto.

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

Limitaciones y advertencias

• Limitaciones y advertencias de MoFRR en dispositivos de conmutación y enrutamiento
• Limitaciones de MoFRR en dispositivos de conmutación con PIM
• Limitaciones y advertencias de MoFRR en dispositivos de enrutamiento con LDP multipunto

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

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

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

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

Para que R1 interfuncione con R6, se necesitan tanto un servidor de mapeo de enrutamiento por segmentos (SRMS) de LDP como un cliente de mapeo de enrutamiento por segmentos (SRMC). Es más fácil entender la función del SRMS y del SRMC observando el flujo de tráfico de manera unidireccional. Según la Figura 22, diremos que el tráfico que fluye de izquierda a derecha se origina en el dominio de SR y termina en el dominio de LDP. Del mismo modo, el tráfico que fluye de derecha a izquierda se origina en el dominio de LDP y termina en el dominio de SR.

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

• Flujo de tráfico de izquierda a derecha: el servidor de mapeo de enrutamiento por segmentos

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

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

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

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

• Flujo de tráfico de derecha a izquierda: el cliente de mapeo de enrutamiento por segmentos

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

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

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

Enrutamiento por segmentos a interoperabilidad de LDP mediante OSPF

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

1. Defina la función SRMS:

   Esta configuración crea un bloque de asignación para ambas direcciones de circuito cerrado del dispositivo LDP en la topología de ejemplo. El índice inicial de ID de segmento (SID) asignado al circuito cerrado de R5 es 1000. La especificación del tamaño 2 da como resultado que el índice SID 10001 se asigne a la dirección de circuito cerrado de R6.

   Nota:

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

   Nuestro ejemplo utiliza circuitos cerrados contiguos, por lo que se muestra uno solo prefix-segment-range arriba. Este es un ejemplo de varias asignaciones para admitir el caso de dos nodos de LDP con direccionamiento de circuito cerrado no contiguo:

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

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

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

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

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

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

• No se admiten prefijos IPv6.

• Inundar el prefijo extendido opaco LSA de OSPF a través de los límites del AS (entre AS) no es compatible.

• No se admite la funcionalidad del servidor de mapeo de LDP entre áreas.

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

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

• No se admite la preferencia del servidor de mapeo de enrutamiento por segmentos TLV.

Interoperabilidad del enrutamiento por segmentos con LDP mediante SI-SI

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

1. Defina la función SRMS:

   Esta configuración crea un bloque de asignación para ambas direcciones de circuito cerrado del dispositivo LDP en la topología de ejemplo. El índice inicial de ID de segmento (SID) asignado al circuito cerrado de R5 es 1000. La especificación del tamaño 2 da como resultado que el índice SID 10001 se asigne a la dirección de circuito cerrado de R6.

   Nota:

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

   Nuestro ejemplo utiliza circuitos cerrados contiguos, por lo que se muestra uno solo prefix-segment-range arriba. A continuación, se muestra un ejemplo de asignaciones de prefijo para manejar el caso de dos enrutadores LDP con direccionamiento de circuito cerrado no contiguo:

2. A continuación, configure la compatibilidad con SI-SI para el LSP extendido que se utiliza para inundar los prefijos asignados.

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

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

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

La compatibilidad para unir el enrutamiento de segmentos y los próximos saltos de LDP con SI-SI comenzó en Junos OS 17.4R1.

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

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

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

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

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

• No se admite el enrutamiento activo sin paradas (NSR) ni el cambio normal del motor de enrutamiento (GRES).

• No se admite SI-SI internivel.

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

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

Configure LDP para que utilice la métrica de ruta IGP

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

Para utilizar la métrica de ruta IGP, incluya la track-igp-metric instrucció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 para esta instrucción.

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

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

Para omitir las rutas de entrada de la tabla de enrutamiento inet.0, incluya la no-forwarding instrucció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 para esta instrucción.

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

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

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

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

La etiqueta anunciada predeterminada es la etiqueta 3 (etiqueta nula implícita). Si se anuncia la etiqueta 3, el enrutador de penúltimo salto quita la etiqueta y envía el paquete al enrutador de salida. Si está habilitada la función emergente de salto final, se anuncia la etiqueta 0 (etiqueta nula explícita IPv4). La extracción de salto definitivo garantiza que cualquier paquete que atraviese una red MPLS incluya una etiqueta.

Para configurar el último salto, incluya la explicit-null instrucció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 para esta instrucción.

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

Habilitar LDP a través de LSP establecidos por RSVP

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

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

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

Otros proveedores utilizan una métrica de OSPF de 1 para la dirección de circuito cerrado. Los enrutadores de Juniper Networks utilizan una métrica OSPF de 0 para la dirección de circuito cerrado. Esto puede requerir que configure manualmente la métrica RSVP al implementar la tunelización de LDP a través de 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 el enrutador de Juniper Networks no puede utilizar el túnel RSVP para enrutar el tráfico a los destinos de LDP aguas abajo del enrutador de salida del otro proveedor si la ruta RSVP tiene una métrica de 1 mayor que la ruta física del OSPF.

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

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

• [edit protocols ospf traffic-engineering shortcuts]

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

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

Configurar la firma TCP MD5 para sesiones de LDP

Puede configurar una firma MD5 para una conexión TCP de LDP a fin de impedir la introducción de segmentos TCP suplantados en flujos de conexión de sesión de LDP. Para obtener más información acerca de la autenticación TCP, consulte TCP. Para obtener información sobre cómo utilizar la opción de autenticación TCP (TCP-AO) en lugar de TCP MD5, consulte Opción de autenticación TCP (TCP-AO).

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

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

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

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

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

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

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

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

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

Para obtener más información sobre la función de actualización de claves de autenticación, consulte Configurar el mecanismo de actualización de claves de autenticación para protocolos de enrutamiento BGP y LDP.

Configurar la protección de la sesión de LDP

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

Puede configurar la instrucción Junos OS para dejar activa la sesión LDP entre dos enrutadores, incluso si no hay adyacencias de saludo en los vínculos que conectan los dos enrutadores session-protection . Opcionalmente, puede especificar un tiempo en segundos mediante la timeout opción. La sesión permanece activa durante el tiempo especificado, siempre y cuando los enrutadores mantengan 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.

Deshabilitar capturas de SNMP para LDP

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

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

Para deshabilitar capturas SNMP para LDP, especifique la trap disable opción de la log-updown instrucció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 para esta instrucción.

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

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

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

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

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

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

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

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

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

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

Configuración del temporizador de retirada de etiquetas

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

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

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

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

Ignorar la comprobación de la subred de LDP

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

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

Esta instrucción se puede incluir en los siguientes niveles jerárquicos:

• [edit protocols ldp interface interface-name]

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

Salida de estadísticas de LDP

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

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

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

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

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

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

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

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

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

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

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

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

Limitaciones de las estadísticas de LDP

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

• No puede borrar las estadísticas de LDP.

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

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

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

Rastreo del tráfico del protocolo LDP a nivel de instancia de protocolo y enrutamiento

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

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

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

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

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

• binding: rastree las operaciones de enlace de etiquetas.

• error—Condiciones de error de rastreo.

• event—Rastreo de eventos de protocolo.

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

• label: rastree la operación de los mensajes de solicitud de etiquetas, mapa de etiquetas, retirada de etiquetas y liberación de etiquetas.

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

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

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

• path: rastreo de operaciones de ruta conmutada por etiquetas.

• path: rastreo de operaciones de ruta conmutada por etiquetas.

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

• route: rastree el funcionamiento de los mensajes de ruta.

• state—Rastree las transiciones de estado del protocolo.

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

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

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

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

Esta función tiene las siguientes limitaciones:

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

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

• Cuando se configura el rastreo y el filtrado de rutas, las rutas MPLS no se muestran (están bloqueadas por el filtro).

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

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

Ejemplos: Rastreo del tráfico del protocolo LDP

Rastree los mensajes de ruta de LDP en detalle:

Rastrear todos los mensajes salientes de LDP:

Rastree todas las condiciones de error de LDP:

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

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