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 básica de LSP

Configuración de métricas de LSP

La métrica LSP se utiliza para indicar la facilidad o dificultad de enviar tráfico a través de un LSP determinado. Los valores de métricaSP más bajos (menor costo) aumentan la probabilidad de que se utilice un LSP. Por el contrario, los valores de métricas LSP altos (costo más alto) reducen la probabilidad de que se utilice un LSP.

El enrutador puede especificar dinámicamente la métrica LSP o el usuario explícitamente como se describe en las siguientes secciones:

Configuración de métricas dinámicas de LSP

Si no se configura ninguna métrica específica, un LSP intenta rastrear la métrica IGP hacia el mismo destino (la to dirección del LSP). IGP incluye OSPF, IS-IS, protocolo de información de enrutamiento (RIP) y rutas estáticas. Se excluyen el BGP y otras rutas RSVP o LDP.

Por ejemplo, si la métrica OSPF hacia un enrutador es 20, todos los LSP hacia ese enrutador heredan automáticamente la métrica 20. Si el OSPF hacia un enrutador cambia posteriormente a un valor diferente, todas las métricas de LSP cambian en consecuencia. Si no hay rutas IGP hacia el enrutador, el LSP eleva su métrica a 65 535.

Tenga en cuenta que, en este caso, la métrica LSP está completamente determinada por IGP; no tiene relación con la ruta real que LSP está atravesando actualmente. Si LSP reenruta (como mediante la reoptimización), su métrica no cambia y, por lo tanto, sigue siendo transparente para los usuarios. La métrica dinámica es el comportamiento predeterminado; no se requiere configuración.

Configuración de métricas LSP estáticas

Puede asignar manualmente un valor de métrica fijo a un LSP. Una vez configurada con la metric instrucción, la métrica LSP es fija y no puede cambiar:

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

La métrica LSP tiene varios usos:

  • Cuando hay LSP paralelos con el mismo enrutador de salida, las métricas se comparan para determinar qué LSP tiene el valor de métrica más bajo (el costo más bajo) y, por lo tanto, la ruta preferida al destino. Si las métricas son las mismas, el tráfico se comparte.

    Ajustar los valores de la métrica puede forzar al tráfico a preferir algunos LSP sobre otros, independientemente de la métrica IGP subyacente.

  • Cuando se habilita un acceso directo de IGP (consulte Uso de rutas con etiquetas conmutadas para aumentar SPF para calcular accesos directos de IGP), es posible que se instale una ruta IGP en la tabla de enrutamiento con un LSP como el siguiente salto, si el LSP está en la ruta más corta al destino. En este caso, la métrica LSP se agrega a las otras métricas de IGP para determinar la métrica total de ruta. Por ejemplo, si un LSP cuyo enrutador de entrada es X y el enrutador de salida es Y se encuentra en la ruta más corta hacia el destino Z, la métrica LSP se agrega a la métrica para la ruta IGP de Y a Z para determinar el costo total de la ruta. Si varios LSP son posibles próximos saltos, se comparan las métricas totales de las rutas para determinar qué ruta se prefiere (es decir, tiene la métrica total más baja). O bien, las rutas IGP y los LSP que conducen al mismo destino se pueden comparar mediante el valor de la métrica para determinar qué ruta se prefiere.

    Al ajustar la métrica LSP, puede forzar el tráfico a preferir LSP, preferir la ruta de IGP o compartir la carga entre ellos.

  • Si el enrutador X e Y son pares bgp y si hay un LSP entre ellos, la métrica LSP representa el costo total de llegar a Y desde X. Si por alguna razón el LSP vuelve a enrutar, el costo de la ruta subyacente puede cambiar significativamente, pero el costo de X de llegar a Y sigue siendo el mismo (la métrica LSP), lo que permite que X reporte a través de un discriminador de salida múltiple (MED) del BGP una métrica estable a los vecinos descendentes. Mientras Y permanezca accesible a través del LSP, no hay cambios visibles para los vecinos del BGP descendente.

Es posible configurar IS-IS para ignorar la métrica LSP configurada incluyendo la ignore-lsp-metrics instrucción en el [edit protocols isis traffic-engineering shortcuts] nivel de jerarquía. Esta instrucción elimina la dependencia mutua entre IS-IS y MPLS para el cálculo de ruta. Para obtener más información, consulte la biblioteca de protocolos de enrutamiento de Junos OS para dispositivos de enrutamiento.

Configuración de métricas condicionales de LSP RSVP

La métrica condicional ofrece la capacidad de usar diferentes valores de métrica condicionalmente para rutas de conmutación de etiquetas (LSP) configuradas estáticamente localmente. Las métricas condicionales se basan en la métrica IGP que cambia dinámicamente. Junos OS cambia la métrica LSP a la métrica condicional configurada que corresponde al umbral más alto alcanzado por la métrica IGP. Si no hay condiciones coincidentes, el LSP utiliza la métrica IGP de la ruta. Puede configurar hasta cuatro métricas condicionales para un LSP y estarán ordenadas.

Si configura la track-igp-metric instrucción con la configuración de métrica condicional, Junos OS utiliza la métrica IGP de las rutas instaladas para evaluar la métrica condicional configurada. No puede configurar métricas estáticas junto con métricas condicionales.

Configuración de una descripción de texto para LSP

Puede proporcionar una descripción textual para un LSP adjuntando cualquier texto descriptivo que incluya espacios entre comillas (" "). El texto descriptivo que incluya se muestra en la salida detallada del show mpls lsp comando o.show mpls container-lsp

Agregar una descripción de texto para un LSP no tiene ningún efecto en el funcionamiento del LSP. La descripción del texto LSP no puede tener más de 80 caracteres de longitud.

Para proporcionar una descripción textual para un LSP, incluya la description instrucción en cualquiera de los siguientes niveles jerárquicos:

Antes de comenzar:

  • Configure las interfaces del dispositivo.

  • Configure el dispositivo para la comunicación de red.

  • Habilite MPLS en las interfaces del dispositivo.

  • Configure un LSP en el dominio MPLS.

Para agregar una descripción de texto para un LSP:

  1. Escriba cualquier texto que describa el LSP.

    Por ejemplo:

  2. Verifique y confirme la configuración.

    Por ejemplo:

  3. Vea la descripción de un LSP mediante el show mpls lsp detail comando o show mpls container-lsp detail , según el tipo de LSP configurado.

Configuración de preferencias de software MPLS

La preferencia suave intenta establecer una nueva ruta para un LSP preferente antes de derribar el LSP original. El comportamiento predeterminado es derribar primero una LSP adelantada, indicar una nueva ruta y, luego, restablecer el LSP en la nueva ruta. En el intervalo entre cuando se quita la ruta y se establece el nuevo LSP, se pierde cualquier tráfico que intente utilizar el LSP. La preferencia suave evita este tipo de pérdida de tráfico. La desventaja es que, durante el tiempo en que se adelanta un LSP, se utilizan dos LSP con sus requisitos de ancho de banda correspondientes hasta que se derribe la ruta original.

La preferencia de software MPLS es útil para el mantenimiento de la red. Por ejemplo, puede alejar todos los LSP de una interfaz determinada y, luego, quitar la interfaz para el mantenimiento sin interrumpir el tráfico. La preferencia de software MPLS se describe en detalle en RFC 5712, Preferencia suave de ingeniería de tráfico MPLS.

La preferencia suave es una propiedad del LSP y está deshabilitada de forma predeterminada. Se configura en la entrada de un LSP incluyendo la soft-preemption instrucción:

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

También puede configurar un temporizador para la preferencia suave. El temporizador designa la duración del tiempo que el enrutador debe esperar antes de iniciar una preferencia difícil del LSP. Al final del tiempo especificado, el LSP se derriba y resigna. El temporizador de limpieza de preferencia temporal tiene un valor predeterminado de 30 segundos; el intervalo de valores permitidos es de 0 a 180 segundos. Un valor de 0 significa que la preferencia suave está deshabilitada. El temporizador de limpieza de preferencia temporal es global para todos los LSP.

Configure el temporizador incluyendo la cleanup-timer instrucción:

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

Nota:

La preferencia suave no se puede configurar en LSP para los cuales se configuró un reenrutamiento rápido. La configuración no se puede confirmar. Sin embargo, puede habilitar la preferencia suave junto con la protección de nodo y vínculo.

Nota:

El valor del contador para SoftPreemptionCnt se inicializa con un valor de 0 (cero), visible en el resultado del comando show rsvp interface detail .

Configuración de prioridad y preferencia para LSP

Cuando no hay suficiente ancho de banda para establecer un LSP más importante, es posible que desee derribar un LSP existente menos importante para liberar el ancho de banda. Para ello, prioriza el LSP existente.

Si se puede adelantar un LSP se determina por dos propiedades asociadas con el LSP:

  • Prioridad de configuración: determina si se puede establecer un nuevo LSP que prioriza un LSP existente. Para que se produzca la preferencia, la prioridad de configuración del nuevo LSP debe ser mayor que la del LSP existente. Además, el acto de adelantar el LSP existente debe producir suficiente ancho de banda para admitir el nuevo LSP. Es decir, la preferencia solo se produce si el nuevo LSP se puede configurar correctamente.

  • Prioridad de reserva: determina el grado en que un LSP mantiene su reserva de sesión después de que el LSP se haya configurado correctamente. Cuando la prioridad de la reserva es alta, el LSP existente tiene menos probabilidades de renunciar a su reservación, y por lo tanto es poco probable que el LSP pueda ser adelantado.

No puede configurar un LSP con una prioridad de configuración alta y una prioridad de reserva baja, ya que pueden producirse bucles de preferencia permanentes si se permite que dos LSP se anteponen entre sí. Debe configurar la prioridad de reserva para que sea mayor o igual que la prioridad de configuración.

La prioridad de configuración también define la importancia relativa de los LSP en el mismo enrutador de entrada. Cuando se inicia el software, cuando se establece un nuevo LSP o durante la recuperación de errores, la prioridad de configuración determina el orden en el que se presta servicio a los LSP. Los LSP de mayor prioridad tienden a establecerse primero y, por lo tanto, disfrutan de una selección de rutas más óptima.

Para configurar las propiedades de preferencia del LSP, incluya la priority instrucción:

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

Ambos setup-priority y reservation-priority pueden ser un valor del 0 al 7. El valor 0 corresponde a la prioridad más alta y el valor 7 al más bajo. De forma predeterminada, un LSP tiene una prioridad de configuración de 7 (es decir, no puede adelantar a ningún otro LSP) y una prioridad de reserva de 0 (es decir, otros LSP no pueden adelantarla). Estos valores predeterminados son de tal manera que no se produce la preferencia. Cuando se configuran estos valores, la prioridad de configuración siempre debe ser menor o igual que la prioridad de retención.

Configuración de grupos administrativos para LSP

A los grupos administrativos, también conocidos como color de vínculo o clase de recurso, se les asignan atributos manualmente que describen el "color" de los vínculos, de modo que los vínculos con el mismo color pertenecen conceptualmente a la misma clase. Puede usar grupos administrativos para implementar una variedad de configuraciones LSP basadas en políticas.

Los grupos administrativos solo son significativos cuando está habilitada la computación LSP de ruta restringida.

Puede asignar hasta 32 nombres y valores (en el intervalo del 0 al 31), los cuales definen una serie de nombres y sus valores correspondientes. Los nombres y valores administrativos deben ser idénticos en todos los enrutadores dentro de un solo dominio.

Nota:

El valor administrativo es distinto de la prioridad. Configure la prioridad para un LSP mediante la priority instrucción. Consulte Configurar prioridad y preferencia para LSP.

Para configurar grupos administrativos, siga estos pasos:

  1. Defina varios niveles de calidad del servicio incluyendo la admin-groups instrucción:

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

    • [edit protocols mpls]

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

    En el siguiente ejemplo de configuración se muestra cómo configurar un conjunto de nombres y valores administrativos para un dominio:

  2. Defina los grupos administrativos a los que pertenece una interfaz. Puede asignar varios grupos a una interfaz. Incluya la interface instrucción:

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

    • [edit protocols mpls]

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

    Si no incluye la admin-group instrucción, una interfaz no pertenece a ningún grupo.

    Los IGP utilizan la información del grupo para crear paquetes de estado de vínculo, que luego se inundan en toda la red, proporcionando información a todos los nodos de la red. En cualquier enrutador, la topología IGP, así como los grupos administrativos de todos los vínculos, están disponibles.

    Cambiar el grupo administrativo de la interfaz solo afecta a los LSP nuevos. Los LSP existentes en la interfaz no se adelantan ni se recomputan para mantener la red estable. Si es necesario quitar los LSP debido a un cambio de grupo, ejecute el clear rsvp session comando.

    Nota:

    Al configurar grupos administrativos y grupos administrativos extendidos juntos para un vínculo, ambos tipos de grupos administrativos se deben configurar en la interfaz.

  3. Configure una restricción de grupo administrativo para cada LSP o para cada ruta LSP principal o secundaria. Incluya la label-switched-path instrucción:

    Puede incluir la label-switched-path instrucción en los siguientes niveles jerárquicos:

    • [edit protocols mpls]

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

    Si omite las include-allinstrucciones , include-anyo exclude , el cálculo de ruta no cambia. El cálculo de ruta se basa en la computación LSP de ruta restringida. Para obtener información sobre cómo se calcula el cálculo LSP de ruta restringida, consulte Cómo CSPF selecciona una ruta.

    Nota:

    Cambiar el grupo administrativo del LSP provoca una recomputación inmediata de la ruta; por lo tanto, es posible que se reenrute el LSP.

Configuración de grupos administrativos extendidos para LSP

En la ingeniería de tráfico MPLS, se puede configurar un vínculo con un conjunto de grupos administrativos (también conocidos como colores o clases de recursos). Los grupos administrativos se llevan en el protocolo de puerta de enlace interior (IGP) (OSPFv2 e IS-IS) como un valor de 32 bits asignado a cada vínculo. Los enrutadores de Juniper Networks suelen interpretar este valor de 32 bits como una máscara de bits con cada bit que representa un grupo, lo que limita cada red a un total de 32 grupos administrativos distintos (intervalo de valor del 0 al 31).

Configure grupos administrativos extendidos, representados por un valor de 32 bits, lo que amplía la cantidad de grupos administrativos admitidos en la red más allá de solo 32. El intervalo original de valores disponibles para grupos administrativos sigue siendo compatible con versiones anteriores.

La configuración de grupos administrativos extendidos acepta un conjunto de interfaces con un conjunto correspondiente de nombres de grupos administrativos extendidos. Convierte los nombres en un conjunto de valores de 32 bits y propaga esta información en el IGP. Los valores de grupo administrativo extendido son globales y deben configurarse de manera idéntica en todos los enrutadores compatibles que participan en la red. La base de datos de grupos administrativos extendidos para todo el dominio, aprendida de otros enrutadores a través de la inundación de IGP, es utilizada por constrained Shortest Path First (CSPF) para el cálculo de rutas.

En el siguiente procedimiento se describe cómo configurar grupos administrativos extendidos:

  1. Configure la admin-groups-extended-range instrucción:

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

    • [edit routing-options]

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

    La admin-groups-extended-range instrucción incluye las minimum opciones y maximum . El máximo del intervalo debe ser mayor que el mínimo del intervalo.

  2. Configure la admin-groups-extended instrucción:

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

    • [edit routing-options]

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

    La admin-groups-extended instrucción le permite configurar un nombre de grupo y un valor de grupo para el grupo administrativo. El valor del grupo debe estar dentro del intervalo de valores configurado mediante la admin-groups-extended-range instrucción.

  3. Los grupos administrativos extendidos para una interfaz MPLS constan del conjunto de nombres de grupos administrativos extendidos asignados para la interfaz. Los nombres de grupos administrativos extendidos de interfaz se deben configurar para los grupos administrativos extendidos globales.

    Para configurar un grupo administrativo extendido para una interfaz MPLS, especifique el nombre del grupo administrativo dentro de la configuración de interfaz MPLS mediante la admin-groups-extended instrucción:

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

    • [edit protocols mpls interface interface-name]

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

  4. Los grupos administrativos extendidos de LSP definen el conjunto de restricciones de inclusión y exclusión para un LSP y para las rutas primarias y secundarias de una ruta. Los nombres de grupos administrativos extendidos se deben configurar para los grupos administrativos extendidos globales.

    Para configurar grupos administrativos extendidos para un LSP, incluya la admin-group-extended instrucción en un nivel de jerarquía LSP:

    La admin-group-extended instrucción incluye las siguientes opciones: apply-groups, apply-groups-except, exclude, , include-all, y include-any. Cada opción le permite configurar uno o más grupos administrativos extendidos.

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

  5. Para mostrar los grupos administrativos extendidos configurados actualmente, ejecute el show mpls admin-groups-extended comando.
Nota:

Al configurar grupos administrativos y grupos administrativos extendidos juntos para un vínculo, ambos tipos de grupos administrativos se deben configurar en la interfaz.

Configuración de valores de preferencia para LSP

Como opción, puede configurar varios LSP entre el mismo par de enrutadores de entrada y salida. Esto es útil para equilibrar la carga entre los LSP, ya que todos los LSP, de forma predeterminada, tienen el mismo nivel de preferencia. Para preferir un LSP sobre otro, establezca diferentes niveles de preferencia para LSP individuales. Se utiliza el LSP con el valor de preferencia más bajo. La preferencia predeterminada para los LSP RSVP es 7 y para LSP LDP es 9. Estos valores de preferencia son más bajos (más preferidos) que todas las rutas aprendidas, excepto las rutas de interfaz directa.

Para cambiar el valor de preferencia predeterminado, incluya la preference instrucción:

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

Deshabilitar la grabación de ruta de ruta por LSP

La implementación de Junos de RSVP admite el objeto Record Route, el cual permite que un LSP registre activamente los enrutadores por los que transita. Puede usar esta información para solucionar problemas y evitar bucles de enrutamiento. De forma predeterminada, se registra la información de ruta de ruta. Para deshabilitar la grabación, incluya la no-record instrucción:

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

Lograr una conmutación sin problemas antes del descanso para LSP

Es posible que las rutas adaptables conmutadas por etiquetas (LSP) necesiten establecer una nueva instancia de LSP y transferir el tráfico de una instancia LSP antigua a la nueva instancia de LSP antes de derribar la antigua. Este tipo de configuración se conoce como una realización antes de la interrupción (MBB).

RSVP-TE es un protocolo que se utiliza para establecer LSP en redes MPLS. La implementación de Junos OS de RSVP-TE para lograr una conmutación MBB sin problemas (sin pérdida de tráfico) se ha basado en la configuración de los valores del temporizador en las siguientes instrucciones de configuración:

  • optimize-switchover-delay— Cantidad de tiempo de espera antes de cambiar a la nueva instancia de LSP.

  • optimize-hold-dead-delay— Cantidad de tiempo para esperar después de la conmutación y antes de la eliminación de la antigua instancia de LSP.

Tanto las optimize-switchover-delayoptimize-hold-dead-delay instrucciones como las se aplican a todos los LSP que utilizan el comportamiento de hacer antes de romper para la configuración y el desmontaje de LSP, no solo para los LSP para los que también se configuró la optimize-timer instrucción. Las siguientes funciones MPLS hacen que los LSP se configuren y derriben mediante el comportamiento de hacer antes de romper:

  • LSP adaptables

  • Asignación automática de ancho de banda

  • BFD para LSP

  • Conmutación de motor de enrutamiento elegante

  • Protección de vínculos y nodos

  • Enrutamiento activo sin escalas

  • LSP optimizados

  • LSP punto a multipunto (P2MP)

  • Preferencias suaves

  • Rutas secundarias en espera

optimize-switchover-delay Las instrucciones y optimize-hold-dead-delay cuando se configuran agregan un retraso artificial al proceso de MBB. El valor de la optimize-switchover-delay instrucción varía según el tamaño de los objetos de ruta explícitos (ERO). Un ERO es una extensión a RSVP que permite que un mensaje de ruta RSVP atraviese una secuencia explícita de enrutadores que sea independiente del enrutamiento IP de ruta más corta convencional. El valor de la optimize-switchover-delay instrucción también depende de la carga de CPU en cada uno de los enrutadores de la ruta. Los clientes establecen la optimize-switchover-delay instrucción por prueba y error.

El valor de la optimize-hold-dead-delay instrucción depende de la velocidad con la que el enrutador de entrada mueve todos los prefijos de aplicación para que apunten al nuevo LSP. Esto lo determina la carga del motor de reenvío de paquetes, que puede variar de una plataforma a una plataforma. Los clientes tienen que establecer la optimize-hold-dead-delay instrucción por prueba y error.

Sin embargo, a partir de la versión 15.1, Junos OS es capaz de lograr una conmutación MBB sin hit sin necesidad de configurar los retrasos artificiales que estos valores de temporizador introducen.

En este tema se resumen los tres métodos para lograr una conmutación de MBB de un LSP antiguo a un LSP nuevo mediante Junos OS:

Especificar la cantidad de tiempo que espera el enrutador para cambiar a nuevas rutas

Para especificar la cantidad de tiempo que espera el enrutador para cambiar a través de instancias de LSP a rutas recién optimizadas, use la optimize-switchover-delay instrucción. Solo debe configurar esta instrucción en enrutadores que actúen como entrada para los LSP afectados (no es necesario configurar esta instrucción en enrutadores de tránsito o salida). El temporizador de esta instrucción ayuda a garantizar que se hayan establecido las nuevas rutas optimizadas antes de que el tráfico se cambie de las rutas antiguas. Este temporizador solo puede habilitarse o deshabilitarse para todos los LSP configurados en el enrutador.

Para configurar la cantidad de tiempo que espera el enrutador para conmutar las instancias de LSP a rutas recién optimizadas, especifique el tiempo en segundos mediante la optimize-switchover-delay instrucción:

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

  • [edit protocols mpls]

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

Especificación de la cantidad de tiempo para retrasar el derribo de rutas antiguas

Para especificar la cantidad de tiempo para retrasar el desprendmiento de rutas antiguas después de que el enrutador haya cambiado el tráfico a nuevas rutas optimizadas, use la optimize-hold-dead-delay instrucción. Solo debe configurar esta instrucción en enrutadores que actúen como entrada para los LSP afectados (no es necesario configurar esta instrucción en enrutadores de tránsito o salida). El temporizador de esta instrucción ayuda a garantizar que las rutas antiguas no se derriben antes de que todas las rutas se cambien a las nuevas rutas optimizadas. Este temporizador se puede habilitar para LSP específicos o para todos los LSP configurados en el enrutador.

Para configurar la cantidad de tiempo en segundos para retrasar el derribo de rutas antiguas después de que el enrutador haya cambiado el tráfico a nuevas rutas optimizadas, utilice la optimize-hold-dead-delay instrucción:

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

Lograr una conmutación de MBB sin problemas sin retrasos artificiales

A partir de la versión 15.1 de Junos OS, hay otra forma de renunciar a las instancias LSP antiguas después de la conmutación de MBB sin depender de los intervalos de tiempo arbitrarios configurados por la optimize-switchover-delay instrucción o optimize-hold-dead-delay . Por ejemplo, si usa la optimize-hold-dead-delay instrucción, configure un tiempo que cree que es seguro esperar antes de derribar la antigua instancia de LSP después de MBB. Sin embargo, es posible que algunas rutas aún estén en proceso de cambiar a la nueva instancia. La eliminación prematura de la antigua instancia de LSP da como resultado que uno de los nodos de tránsito abandone el tráfico de esas rutas que no se han desplazado a la nueva instancia de LSP.

Para evitar pérdidas de tráfico, en lugar de usar la optimize-switchover-delay instrucción, puede usar MPLS-OAM (ping lsp), lo que confirma que el plano de datos LSP se establece de extremo a extremo. En lugar de usar la optimize-hold-dead-delay instrucción, puede usar un mecanismo de comentarios de la infraestructura rpd que confirme que se conmutaron todos los prefijos que hacen referencia al LSP antiguo. El mecanismo de comentarios se obtiene de la biblioteca de etiquetas y se basa en la infraestructura del proceso de protocolo de enrutamiento (rpd) para determinar cuándo todas las rutas que utilizan la antigua instancia de LSP se han cambiado completamente a la nueva instancia de LSP después de la conmutación de MBB.

El mecanismo de retroalimentación siempre está vigente y es opcional. Configure la optimize-adaptive-teardown instrucción para que se use el mecanismo de comentarios durante la conmutación de MBB. Esta función no se admite para instancias LSP de punto a multipunto (P2MP) RSVP. La configuración global de la optimize-adaptive-teardown instrucción solo afecta a los LSP punto a punto configurados en el sistema.

Solo debe configurar la optimize-adaptive-teardown instrucción en enrutadores que actúan como entrada para los LSP afectados (no es necesario configurar esta instrucción en enrutadores de tránsito o salida). Este mecanismo de comentarios garantiza que las rutas antiguas no se derriben antes de que todas las rutas se cambien a las nuevas rutas optimizadas. La configuración global de esta instrucción de configuración solo afecta a los LSP punto a punto configurados en el sistema.

Puede incluir esta instrucción en el [edit protocols mpls] nivel de jerarquía.

Optimización de LSP señalizadas

Una vez que se ha establecido un LSP, los cambios de topología o recursos podrían, con el tiempo, hacer que la ruta sea subóptima. Es posible que haya disponible una nueva ruta que esté menos congestionada, que tenga una métrica más baja y que atraviese menos saltos. Puede configurar el enrutador para que vuelva a calcular rutas periódicamente para determinar si está disponible una ruta más óptima.

Si se habilita la reoptimización, se puede redirigir un LSP a través de distintas rutas mediante recomputaciones de ruta restringida. Sin embargo, si la reoptimización está deshabilitada, el LSP tiene una ruta fija y no puede aprovechar los recursos de red recién disponibles. El LSP se fija hasta que el próximo cambio de topología rompa el LSP y obligue a una recomputación.

La reoptimización no está relacionada con la conmutación por error. Siempre se calcula una nueva ruta cuando se producen errores en la topología que interrumpen una ruta establecida.

Debido a la posible sobrecarga del sistema, debe controlar cuidadosamente la frecuencia de reoptimización. La estabilidad de la red puede sufrir cuando se habilita la reoptimización. De forma predeterminada, la optimize-timer instrucción se establece en 0 (es decir, está deshabilitada).

La optimización de LSP solo es significativa cuando está habilitada la computación LSP de ruta restringida, que es el comportamiento predeterminado. Para obtener más información acerca de la computación LSP de ruta restringida, consulte Deshabilitar computación LSP de ruta restringida. Además, la optimización de LSP solo es aplicable a los LSP de entrada, por lo que solo es necesario configurar la optimize-timer instrucción en el enrutador de entrada. Los enrutadores de tránsito y salida no requieren ninguna configuración específica para admitir la optimización de LSP (aparte de tener MPLS habilitado).

Para habilitar la reoptimización de rutas, incluya la optimize-timer instrucción:

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

Una vez que haya configurado la optimize-timer instrucción, el temporizador de reoptimización continúa su cuenta regresiva al valor configurado, incluso si elimina la optimize-timer instrucción de la configuración. La siguiente optimización utiliza el nuevo valor. Puede forzar a Junos OS a usar un nuevo valor inmediatamente mediante la eliminación del valor antiguo, la confirmación de la configuración, la configuración del valor nuevo para la optimize-timer instrucción y, luego, la confirmación de la configuración de nuevo.

Después de ejecutar la reoptimización, el resultado solo se acepta si cumple los siguientes criterios:

  1. La nueva ruta no es más alta en la métrica IGP. (La métrica de la ruta antigua se actualiza durante el cálculo, por lo que si una métrica de vínculo reciente cambió en algún lugar a lo largo de la ruta antigua, se tiene en cuenta.)

  2. Si la nueva ruta tiene la misma métrica de IGP, no hay más saltos.

  3. La nueva ruta no provoca preferencias. (Esto es para reducir el efecto dominó de la preferencia causando más preferencia.)

  4. La nueva ruta no empeora la congestión en general.

    La congestión relativa de la nueva ruta se determina de la siguiente manera:

    1. El porcentaje de ancho de banda disponible en cada vínculo atravesado por la nueva ruta se compara con el de la ruta antigua, a partir de los vínculos más congestionados.

    2. Para cada ruta actual (antigua), el software almacena los cuatro valores más pequeños para la disponibilidad de ancho de banda para los vínculos atravesados en orden ascendente.

    3. El software también almacena los cuatro valores de disponibilidad de ancho de banda más pequeños para la nueva ruta, correspondientes a los vínculos atravesados en orden ascendente.

    4. Si cualquiera de los cuatro nuevos valores de ancho de banda disponibles es menor que cualquiera de los valores de disponibilidad de ancho de banda antiguos correspondientes, la nueva ruta tiene al menos un vínculo que está más congestionado que el vínculo utilizado por la ruta antigua. Dado que el uso del vínculo causaría más congestión, el tráfico no se cambia a esta nueva ruta.

    5. Si ninguno de los cuatro nuevos valores de ancho de banda disponibles es menor que los valores de disponibilidad correspondientes de ancho de banda antiguo, la nueva ruta está menos congestionada que la ruta antigua.

Cuando se cumplen todas las condiciones anteriores, entonces:

  1. Si la nueva ruta tiene una métrica IGP más baja, se acepta.

  2. Si la nueva ruta tiene una métrica IGP igual y un recuento de saltos inferiores, se acepta.

  3. Si elige least-fill como algoritmo de equilibrio de carga, los LSP se equilibran de la siguiente manera:

    1. El LSP se mueve a una nueva ruta que se utiliza al menos un 10 % menos que la ruta actual. Esto puede reducir la congestión en la ruta actual en solo una pequeña cantidad. Por ejemplo, si un LSP con 1 MB de ancho de banda se mueve fuera de una ruta que lleva un mínimo de 200 MB, la congestión en la ruta original se reduce en menos del 1 %.

    2. Para random o most-fill algoritmos, esta regla no se aplica.

    En el ejemplo siguiente se muestra cómo funciona el algoritmo de least-fill equilibrio de carga.

    Figura 1: Ejemplo de algoritmo de equilibrio de carga de menos rellenoEjemplo de algoritmo de equilibrio de carga de menos relleno

    Como se muestra en Figura 1, hay dos rutas potenciales para que un LSP atraviese del enrutador A al enrutador H, los vínculos impares de L1 a L13 y los vínculos pares de L2 a L14. Actualmente, el enrutador utiliza los vínculos pares como la ruta activa para el LSP. Cada vínculo entre los mismos dos enrutadores (por ejemplo, el enrutador A y el enrutador B) tiene el mismo ancho de banda:

    • L1, L2 = 10GE

    • L3, L4 = 1GE

    • L5, L6 = 1GE

    • L7, L8 = 1GE

    • L9, L10 = 1GE

    • L11, L12 = 10GE

    • L13, L14 = 10GE

    Es más probable que los vínculos 1GE se congestionen. En este ejemplo, los vínculos 1GE impares tienen el siguiente ancho de banda disponible:

    • L3 = 41%

    • L5 = 56%

    • L7 = 66%

    • L9 = 71%

    Los enlaces 1GE pares tienen el siguiente ancho de banda disponible:

    • L4 = 37%

    • L6 = 52%

    • L8 = 61%

    • L10 = 70%

    Según esta información, el enrutador calcularía la diferencia en el ancho de banda disponible entre los enlaces impares y los enlaces pares de la siguiente manera:

    • L4 - L3 = 41% - 37% = 4%

    • L6 - L5 = 56% - 52% = 4%

    • L8 - L7 = 66% - 61% = 5%

    • L10 - L9 = 71% - 70% = 1%

    El ancho de banda adicional total disponible en los enlaces impares es del 14 % (4 % + 4 % + 5 % + 1 %). Dado que el 14 % es mayor que el 10 % (el umbral mínimo del algoritmo de menor relleno), el LSP se mueve a la nueva ruta a través de los vínculos impares de la ruta original mediante los vínculos pares.

  4. De lo contrario, se rechaza la nueva ruta.

Puede deshabilitar los siguientes criterios de reoptimización (un subconjunto de los criterios enumerados anteriormente):

  • Si la nueva ruta tiene la misma métrica de IGP, no hay más saltos.

  • La nueva ruta no provoca preferencias. (Esto es para reducir el efecto dominó de la preferencia causando más preferencia.)

  • La nueva ruta no empeora la congestión en general.

  • Si la nueva ruta tiene una métrica IGP igual y un recuento de saltos inferiores, se acepta.

Para deshabilitarlos, emita el clear mpls lsp optimize-aggressive comando o incluya la optimize-aggressive instrucción:

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

  • [edit protocols mpls]

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

La inclusión de la optimize-aggressive instrucción en la configuración hace que el procedimiento de reoptimización se active con más frecuencia. Las rutas se redirigen con más frecuencia. También limita el algoritmo de reoptimización solo a la métrica IGP.

Configuración del temporizador smart optimize para LSP

Debido a las limitaciones de recursos de red y enrutador, normalmente es inadvisible configurar un intervalo corto para el temporizador de optimización. Sin embargo, en determinadas circunstancias, es posible que sea conveniente reoptimizar una ruta antes de lo que normalmente proporciona el temporizador de optimización.

Por ejemplo, un LSP está atravesando una ruta preferida que posteriormente falla. A continuación, el LSP se cambia a una ruta menos deseable para llegar al mismo destino. Incluso si la ruta original se restaura rápidamente, el LSP podría tardar demasiado tiempo en usarla de nuevo, ya que tiene que esperar a que el temporizador de optimización vuelva aoptimizar las rutas de red. Para estas situaciones, es posible que desee configurar el temporizador de optimización inteligente.

Cuando se habilita el temporizador de optimización inteligente, un LSP se vuelve a su ruta original, siempre y cuando la ruta original se haya restablecido a los 3 minutos de haber caído. Además, si la ruta original vuelve a bajar en 60 minutos, el temporizador de optimización inteligente está deshabilitado y la optimización de rutas se comporta como lo hace normalmente cuando el temporizador de optimización solo está habilitado. Esto impide que el enrutador use un vínculo de marcación.

El temporizador de optimización inteligente depende de otras funciones MPLS para funcionar correctamente. Para el escenario descrito aquí en el que un LSP se cambia a una ruta alternativa en caso de un error en la ruta original, se asume que ha configurado una o más de las funciones de protección de tráfico MPLS, como el reenrutamiento rápido, la protección de vínculos y las rutas secundarias en espera. Estas funciones ayudan a garantizar que el tráfico pueda llegar a su destino en caso de falla.

Al menos, debe configurar una ruta secundaria en espera para que la función de temporizador de optimización inteligente funcione correctamente. El reenrutamiento rápido y la protección de vínculos son soluciones más temporales para una interrupción de la red. Una ruta secundaria garantiza que haya una ruta alternativa estable en caso de que se produce un error en la ruta principal. Si no ha configurado ningún tipo de protección de tráfico para un LSP, el temporizador de optimización inteligente por sí mismo no garantiza que el tráfico pueda llegar a su destino. Para obtener más información acerca de la protección del tráfico MPLS, consulte MPLS y protección del tráfico.

Cuando se produce un error en una ruta principal y el temporizador de optimización inteligente cambia el tráfico a la ruta secundaria, es posible que el enrutador continúe utilizando la ruta secundaria incluso después de que se haya restablecido la ruta principal. Si el enrutador de entrada completa un cálculo cspf, puede determinar que la ruta secundaria es la mejor ruta.

Esto puede ser indeseable si la ruta principal debe ser la ruta activa y la ruta secundaria debe usarse solo como copia de seguridad. Además, si la ruta secundaria se usa como la ruta activa (aunque se haya restablecido la ruta principal) y se produce un error en la ruta secundaria, la función de temporizador de optimización inteligente no cambiará automáticamente el tráfico a la ruta principal. Sin embargo, puede habilitar la protección para la ruta secundaria mediante la configuración de la protección de nodo y vínculo o una ruta secundaria en espera adicional, en cuyo caso, el temporizador de optimización inteligente puede ser eficaz.

Especifique el tiempo en segundos para el temporizador de optimización inteligente mediante la smart-optimize-timer instrucción:

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

  • [edit protocols mpls]

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

Limitar la cantidad de saltos en LSP

De forma predeterminada, cada LSP puede atravesar un máximo de 255 saltos, incluidos los enrutadores de entrada y salida. Para modificar este valor, incluya la hop-limit instrucción:

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

El número de saltos puede ser del 2 al 255. (Una ruta con dos saltos consta solo de enrutadores de entrada y salida.)

Configuración del valor de ancho de banda para LSP

Cada LSP tiene un valor de ancho de banda. Este valor se incluye en el campo Tspec del remitente en los mensajes de configuración de ruta RSVP. Puede especificar un valor de ancho de banda en bits por segundo. Si configura más ancho de banda para un LSP, debe poder transportar un mayor volumen de tráfico. El ancho de banda predeterminado es de 0 bits por segundo.

Un ancho de banda distinto de cero requiere que los enrutadores de tránsito y salida reserven capacidad a lo largo de los vínculos salientes para la ruta. El esquema de reserva de RSVP se utiliza para reservar esta capacidad. Cualquier error en la reserva de ancho de banda (como fallas en el control de políticas RSVP o en el control de admisión) puede provocar un error en la configuración de LSP. Si no hay suficiente ancho de banda en las interfaces para los enrutadores de tránsito o salida, el LSP no se establece.

Para especificar un valor de ancho de banda para un LSP señalizado, incluya la bandwidth instrucción:

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

Asignación automática de ancho de banda para LSP

La asignación automática de ancho de banda permite que un túnel MPLS ajuste automáticamente su asignación de ancho de banda según el volumen del tráfico que fluye a través del túnel. Puede configurar un LSP con un ancho de banda mínimo; esta función puede ajustar dinámicamente la asignación de ancho de banda del LSP según los patrones de tráfico actuales. Los ajustes de ancho de banda no interrumpen el flujo de tráfico a través del túnel.

Establezca un intervalo de muestreo en un LSP configurado con asignación automática de ancho de banda. El ancho de banda promedio se monitorea durante este intervalo. Al final del intervalo, se intenta señalar una nueva ruta para el LSP con la asignación de ancho de banda establecida en el valor promedio máximo para el intervalo de muestreo anterior. Si la nueva ruta se establece correctamente y se elimina la ruta original, el LSP se conmuta a la nueva ruta. Si no se crea una nueva ruta, el LSP sigue utilizando su ruta actual hasta el final del siguiente intervalo de muestreo, cuando se realiza otro intento de establecer una nueva ruta. Tenga en cuenta que puede establecer valores de ancho de banda mínimos y máximos para el LSP.

Durante el intervalo de asignación automática de ancho de banda, el enrutador puede recibir un aumento constante del tráfico (aumento de la utilización del ancho de banda) en un LSP, lo que puede causar congestión o pérdida de paquetes. Para evitar esto, puede definir un segundo activador para caducar prematuramente el temporizador de ajuste de ancho de banda automático antes del final del intervalo de ajuste actual.

Configuración de la asignación automática de ancho de banda para LSP

La asignación automática de ancho de banda permite que un túnel MPLS ajuste automáticamente su asignación de ancho de banda según el volumen del tráfico que fluye a través del túnel. Puede configurar un LSP con un ancho de banda mínimo y esta función puede ajustar dinámicamente la asignación de ancho de banda del LSP según los patrones de tráfico actuales. Los ajustes de ancho de banda no interrumpen el flujo de tráfico a través del túnel.

Al final del intervalo de tiempo de asignación automática de ancho de banda, el uso de ancho de banda promedio máximo actual se compara con el ancho de banda asignado para el LSP. Si el LSP necesita más ancho de banda, se intenta configurar una nueva ruta en la que el ancho de banda sea igual al uso promedio máximo actual. Si el intento se realiza correctamente, el tráfico del LSP se enruta a través de la nueva ruta y se elimina la ruta antigua. Si se produce un error en el intento, el LSP sigue utilizando su ruta actual.

Nota:

Al calcular el valor para Max AvgBW (en relación con la LSP de entrada), la muestra recopilada durante la realización antes del descanso (MBB) se ignora para evitar resultados inexactos. El primer ejemplo después de un ajuste de ancho de banda o después de un cambio en el ID de LSP (independientemente del cambio de ruta), también se omite.

Si configuró la protección de vínculo y nodo para el LSP y el tráfico se cambió a la LSP de derivación, la función de asignación automática de ancho de banda sigue funcionando y toma muestras de ancho de banda del LSP de derivación. Para el primer ciclo de ajuste de ancho de banda, el uso promedio máximo del ancho de banda tomado del vínculo original y el LSP protegido por nodo se utiliza para renunciar a la LSP de derivación si se necesita más ancho de banda. (La protección de vínculos y nodos no se admite en conmutadores serie QFX.)

Si configuró el reenrutamiento rápido para el LSP, es posible que no pueda usar esta función para ajustar el ancho de banda. Dado que los LSP utilizan un estilo de reserva de filtro fijo (FF), cuando se señala una nueva ruta, el ancho de banda puede contarse dos veces. El conteo doble puede evitar que un LSP de reenrutamiento rápido ajuste su ancho de banda cuando se habilita la asignación automática de ancho de banda. (No se admite el reenrutamiento rápido en conmutadores de la serie QFX.)

Para configurar la asignación automática de ancho de banda, complete los pasos en las siguientes secciones:

Nota:

En los conmutadores QFX10000, solo puede configurar la asignación automática de ancho de banda en el edit protocols mpls nivel jerárquico. No se admiten sistemas lógicos.

Configuración de ajustes optimizados de ancho de banda automático para LSP MPLS

La funcionalidad de ancho de banda automático permite que los LSP RSVP-TE, configurados directamente o creados automáticamente mediante malla automática, redimensionen según la velocidad de tráfico. La velocidad de tráfico de cada LSP se mide mediante la recopilación periódica de muestras de la velocidad de tráfico. La frecuencia de la recopilación de estadísticas de tráfico se controla mediante la adjust-interval instrucción de configuración. El valor mínimo configurable es de adjust-interval un segundo. El redimensionamiento de los LSP se denomina ajuste y la frecuencia de los ajustes se controla mediante la adjust-interval instrucción.

A partir de Junos OS versión 20.4R1, el mínimo adjust-interval para un auto-bandwidth ajuste se reduce a 150 segundos si las adjust-threshold-overflow-limit instrucciones o adjust-threshold-underflow-limit cruzan los valores de umbral de desbordamiento o subflujo configurados.

Sin embargo, el mínimo adjust-interval para un auto-bandwidth ajuste es de 300 segundos si no se detecta ninguna muestra de desbordamiento o subflujo.

En versiones anteriores a la versión 20.4R1 de Junos OS, el adjust-interval tiempo es de 300 segundos en condiciones de desbordamiento o subflujo.

Con la implementación de la optimización automática del ajuste del ancho de banda, la auto-bandwidth disminución del ancho de banda del LSP más rápido. El enrutador de borde de etiqueta de entrada (LER) puede cambiar el tamaño en 150 segundos debido a la reducción de adjust-threshold-overflow-limit, siempre que el derribo de una antigua instancia de LSP post make-before-break (MBB) se realice en un plazo de 150 segundos.

Los requisitos para la optmización automática del ancho de banda son:

  • Reducir la probabilidad de cambio de ruta LSP: esto es para reducir la probabilidad de cambio de ruta LSP cuando se produce un ajuste de ancho de banda automático.

  • Reducir la probabilidad de reenrutamiento de LSP: esto es para reducir la probabilidad de reenrutamiento de LSP debido a los LSP de mayor prioridad que exigen el mismo recurso.

Para cumplir con estos requisitos, la optimización de los ajustes de ancho de banda automático admite lo siguiente:

  1. In-place LSP Bandwidth Update: permite que el enrutador de borde de etiqueta de entrada (LER) vuelva a usar el ID de LSP al realizar un cambio de ancho de banda en un LSP intradominio.

    Nota:

    La actualización de ancho de banda LSP in situ no es aplicable a un LSP entre dominios.

    En ciertos casos, la ruta LSP del próximo salto lleva el ancho de banda de LSP, ya sea directa o indirectamente. Aunque se admite la actualización de ancho de banda LSP local en estos casos, la mejora del rendimiento de la funcionalidad está limitada debido al cambio de ruta de LSP. Es decir, debido al cambio en la tabla de ruta inet.3 después del ancho de banda automático (túnel MPLS). Por ejemplo, la mejora del rendimiento está limitada cuando configura cualquiera de las instrucciones o ambas:

    • auto-policing configurada en MPLS.

    • La opción bandwidth bajo la instrucción load-balance configurada en RSVP.

    Nota:

    Se produce un error en la actualización del ancho de banda del LSP local mediante el reuso de LSP-ID y el LER de entrada activa de inmediato MBB con un nuevo LSP-ID si:

    • no-cspf está configurado para el LSP.

    • LSP se controla mediante el elemento de cálculo de ruta (PCE).

    • Se activa el temporizador de optimización LSP.

    • clear mpls lsp optimize-aggressive se ejecuta el comando.

  2. Per-priority Subscription— Para utilizar los recursos de red de manera más eficiente, la suscripción por prioridad le permite configurar un porcentaje de suscripción RSVP más bajo para LSP de prioridades más bajas y un mayor porcentaje de suscripción RSVP para LSP de prioridades más altas.

    Por ejemplo, en lugar de establecer el porcentaje de suscripción RSVP como 90 % para LSP para todas las prioridades, puede configurar un porcentaje de suscripción RSVP inferior (por ejemplo, un 75 %) para LSP de prioridades más bajas.

Nota:

La suscripción por prioridad no interopera con la ingeniería de tráfico consciente de los servicios diferenciados (DiffServ). La ingeniería de tráfico consciente de los servicios diferenciados (DiffServ) ofrece un uso compartido más flexible y estadístico del ancho de banda del vínculo de TE que la suscripción por prioridad.

To Configure In-place LSP Auto-bandwidth Resizing:

  1. Configure la interfaz del dispositivo para habilitar MPLS.
  2. Configure el protocolo MPLS en la interfaz.
  3. Configure MPLS y los LSP y configure la protección de vínculo para el LSP.
  4. Configure in-place-bandwidth-update para que LSP habilite el cambio de tamaño de LSP de ancho de banda automático.
  5. Ingrese confirmar desde el modo de configuración.

Verification

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

To Configure Per-priority Subscription:

  1. Configure el protocolo RSVP en la interfaz.

  2. Configure el valor de suscripción de ancho de banda para la interfaz. Puede ser un valor del 0 al 65 000 por ciento. El valor de suscripción predeterminado es del 100 %.

  3. Configure la prioridad de suscripción sobre la interfaz.

  4. Configure el porcentaje de suscripción para la prioridad.

  5. Ingrese confirmar desde el modo de configuración.

Verification

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

Configuración de informes de estadísticas de asignación automática de ancho de banda para LSP

La asignación automática de ancho de banda permite que un túnel MPLS ajuste automáticamente su asignación de ancho de banda según el volumen del tráfico que fluye a través del túnel. Puede configurar el dispositivo para recopilar estadísticas relacionadas con la asignación automática de ancho de banda mediante los siguientes pasos:

  1. Para recopilar estadísticas relacionadas con la asignación automática de ancho de banda, configure la auto-bandwidth opción para la statistics instrucción en el [edit protocols mpls] nivel de jerarquía. Esta configuración se aplica a todos los LSP configurados en el enrutador en el que también configuró la auto-bandwidth instrucción en el [edit protocols mpls label-switched-path label-switched-path-name] nivel de jerarquía.
  2. Especifique el filename para los archivos utilizados para almacenar la salida de la operación de seguimiento MPLS mediante la file opción. Todos los archivos se colocan en el directorio /var/log. Recomendamos que coloque la salida de seguimiento MPLS en el archivo mpls-log.
  3. Especifique el número máximo de archivos de seguimiento mediante la files number opción. Cuando un archivo de seguimiento llamado trace-file alcanza su tamaño máximo, se cambia el nombre trace-file.0, luego trace-file.1, y así sucesivamente, hasta que se alcanza el número máximo de archivos de seguimiento. Luego, se sobrescribe el archivo de seguimiento más antiguo.
  4. Especifique el intervalo para calcular el uso promedio de ancho de banda mediante la configuración de un tiempo en segundos mediante la interval opción. También puede establecer el intervalo de ajuste en un LSP específico configurando la interval opción en el [edit protocols mpls label-switch-path label-switched-path-name statistics] nivel jerárquico.
    Nota:

    Para evitar la resignación innecesaria de LSP, es mejor configurar un intervalo de ajuste LSP que sea al menos tres veces más largo que el intervalo de estadísticas de ancho de banda automático MPLS. Por ejemplo, si configura un valor de 30 segundos para el intervalo de estadísticas de ancho de banda automático MPLS (interval instrucción en el [edit protocols mpls statistics] nivel de jerarquía), debe configurar un valor de al menos 90 segundos para el intervalo de ajuste LSP (adjust-interval instrucción en el [edit protocols mpls label-switched-path label-switched-path-name auto-bandwidth] nivel de jerarquía).

  5. Para rastrear la asignación automática de ancho de banda, incluya la autobw-state flag instrucción MPLS traceoptions en el [edit protocols mpls] nivel de jerarquía.

    La siguiente configuración habilita las opciones de seguimiento MPLS para la asignación automática de ancho de banda. Los registros de seguimiento se almacenan en un archivo llamado auto-band-trace (el nombre de archivo es configurable por el usuario):

  6. Mediante el show log comando, puede mostrar el archivo de estadísticas de asignación automática de ancho de banda generado cuando configure la instrucción de ancho de banda automático (estadísticas MPLS ). A continuación, se muestra la salida del archivo de registro de ejemplo tomado de un archivo de estadísticas MPLS denominado auto-band-stats en un enrutador configurado con un LSP denominado E-D. El archivo de registro muestra que LSP E-D funciona sobre su límite de ancho de banda reservado inicialmente. Antes Oct 30 17:14:57, el enrutador activaba un ajuste automático del ancho de banda (es posible que vea dos sesiones de un LSP que se somete a un ajuste automático de ancho de banda). Por Oct 30 17:16:57, el LSP se ha restablecido a un ancho de banda más alto y ahora se muestra con menos del 100 % de su Reserved Bw (ancho de banda reservado).
  7. Ejecute el comando show mpls lsp autobandwidth para mostrar la información actual sobre la asignación automática de ancho de banda. A continuación, se muestra el show mpls lsp autobandwidth resultado de ejemplo del comando tomado aproximadamente al mismo tiempo que el archivo de registro que se muestra anteriormente:
  8. Ejecute el file show comando para mostrar el archivo de seguimiento MPLS. Debe especificar la ubicación del archivo y el nombre del archivo (el archivo se encuentra en /var/log/. A continuación, se muestra la salida del archivo de seguimiento de ejemplo que se toma de un archivo de seguimiento MPLS denominado auto-band-trace.0.gz en un enrutador configurado con un LSP denominado E-D. El archivo de seguimiento muestra que LSP E-D funciona sobre su límite de ancho de banda reservado inicialmente. En Oct 30 17:15:26, el enrutador activa un ajuste automático del ancho de banda (es posible que vea dos sesiones de un LSP que se somete a un ajuste automático de ancho de banda). Por Oct 30 17:15:57, el LSP se ha restablecido a un ancho de banda más alto y ahora se muestra con menos del 100 % de su Reserved Bw (ancho de banda reservado).

Configuración de un LSP en AS

Puede configurar un LSP para que atraviese varias áreas de una red incluyendo la inter-domain instrucción como parte de la configuración de LSP. Esta instrucción permite al enrutador buscar rutas en la base de datos IGP. Debe configurar esta instrucción en enrutadores que podrían no poder localizar una ruta mediante CSPF dentro del dominio (buscando en la base de datos de ingeniería de tráfico (TED)). Cuando configure LSP entre áreas, se requiere la inter-domain instrucción.

Antes de comenzar:

  • Configure las interfaces de dispositivo con MPLS de la familia.

  • Configure el ID del enrutador del dispositivo y el número del sistema autónomo.

  • Habilite MPLS y RSVP en el enrutador y las interfaces de tránsito.

  • Configure su IGP para admitir la ingeniería de tráfico.

  • Configure un LSP desde la entrada al enrutador de salida.

Para configurar un LSP en varios AS en el enrutador conmutado por etiqueta de entrada (LER):

  1. Habilite MPLS en todas las interfaces (sin la interfaz de administración).
  2. Habilite RSVP en todas las interfaces (sin la interfaz de administración).
  3. Configure el LSP entre áreas.
  4. Verifique y confirme la configuración.

Anuncio de amortiguación de cambios de estado de LSP

Cuando un LSP cambia de estar arriba a abajo, o de abajo a arriba, esta transición surte efecto inmediatamente en el software y el hardware del enrutador. Sin embargo, cuando se anuncian LSP en IS-IS y OSPF, es posible que desee amortiguar las transiciones de LSP, por lo tanto, no anunciar la transición hasta que haya ocurrido un cierto período de tiempo (conocido como el tiempo de espera). En este caso, si el LSP va de arriba a abajo, el LSP no se anuncia como caído hasta que se ha mantenido hacia abajo durante el período de espera. Las transiciones de abajo a arriba se anuncian en IS-IS y OSPF de inmediato. Observe que la amortiguación de LSP afecta solo a los anuncios IS-IS y OSPF del LSP; otros software y hardware de enrutamiento reaccionan de inmediato a las transiciones de LSP.

Para amortiguar las transiciones de LSP, incluya la advertisement-hold-time instrucción:

seconds puede ser un valor de 0 a 65 535 segundos. El valor predeterminado es de 5 segundos.

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

  • [edit protocols mpls]

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

Configuración de LSP bidireccionales corouted

Un paquete bidireccional corouted LSP es una combinación de dos LSP que comparten la misma ruta entre un par de nodos de entrada y salida, como se muestra en Figura 2. Se establece utilizando las extensiones GMPLS a RSVP-TE. Este tipo de LSP se puede utilizar para transportar cualquiera de los tipos estándar de tráfico basado en MPLS, incluyendo VPN de capa 2, circuitos de capa 2 y VPN de capa 3. Puede configurar una sola sesión BFD para el LSP bidireccional (no es necesario configurar una sesión BFD para cada LSP en cada dirección). También puede configurar un único LSP bidireccional en espera para proporcionar una copia de seguridad para el LSP bidireccional principal. Los LSP bidireccionales corouted son compatibles con el penúltimo salto emergente (PHP) y el salto final emergente (UHP).

La alta disponibilidad está disponible para LSP bidireccionales. Puede habilitar el reinicio correcto y el enrutamiento activo sin interrupciones. El reinicio correcto y el enrutamiento activo sin interrupciones se admiten cuando el enrutador de reinicio es el enrutador de entrada, salida o tránsito para el LSP bidireccional.

Figura 2: LSP bidireccional coroutedLSP bidireccional corouted

Para configurar un LSP bidireccional corouted:

  1. En el modo de configuración, configure el enrutador de entrada para el LSP e incluya la corouted-bidirectional instrucción para especificar que el LSP se establezca como un LSP bidireccional corouted.

    La ruta se calcula mediante CSPF y se inicia mediante la señalización RSVP (al igual que un RSVP unidireccional señaló LSP). Cuando se confirma esta configuración, se crean tanto la ruta al enrutador de salida como la ruta inversa del enrutador de salida.

  2. (Opcional) Para una ruta inversa, configure un LSP en el enrutador de salida e incluya la corouted-bidirectional-passive instrucción para asociar el LSP con otro LSP.

    No se utiliza ningún cálculo o señalización de ruta para este LSP, ya que se basa en el cálculo de ruta y la señalización proporcionadas por el LSP de entrada. No puede configurar la corouted-bidirectional instrucción y la corouted-bidirectional-passive instrucción en el mismo LSP.

    Esta instrucción también facilita la depuración de LSP bidireccionales corouted. Si configura la corouted-bidirectional-passive instrucción (de nuevo, en el enrutador de salida), puede emitir ping mpls lsp-end-point, ping mpls ldp, ping mpls rsvp, traceroute mpls ldpy traceroute mpls rsvp comandos para probar el LSP bidireccional corouted desde el enrutador de salida.

  3. Utilice los show mpls lsp extensive comandos y para show rsvp session extensive mostrar información sobre el LSP bidireccional.

    Lo siguiente muestra la salida del show rsvp session extensive comando cuando se ejecuta en un enrutador de entrada con un LSP bidireccional configurado:

Configuración de la etiqueta entropía para LSP

La inserción de etiquetas de entropía para un LSP permite a los enrutadores de tránsito equilibrar la carga del tráfico MPLS a través de rutas ECMP o grupos de agregación de vínculos utilizando solo la pila de etiquetas MPLS como entrada hash sin tener que depender de una inspección profunda de paquetes. La inspección profunda de paquetes requiere más de la potencia de procesamiento del enrutador y los diferentes enrutadores tienen diferentes capacidades de inspección profunda de paquetes.

Para configurar la etiqueta de entropía para un LSP, complete los pasos siguientes:

  1. En el enrutador de entrada, incluya la entropy-label instrucción en el [edit protocols mpls labeled-switched-path labeled-switched-path-name] nivel de jerarquía o en el [edit protocols mpls static-labeled-switched-path labeled-switched-path-name ingress] nivel jerárquico. La etiqueta de entropía se agrega a la pila de etiquetas MPLS y se puede procesar en el plano de reenvío.
    Nota:

    Esto solo es aplicable para RSVP y LSP estáticos.

  2. En el enrutador de entrada, puede configurar una política de entrada para LSP señalizadas por LDP:

    Configure la política de entrada en el [edit policy-options] nivel jerárquico:

    A continuación, se muestra un ejemplo de una política de entrada de etiquetas de entropía.

  3. (Opcional) De forma predeterminada, los enrutadores que admiten la inserción y el estallido de etiquetas de entropía se configuran con la load-balance-label-capability instrucción en el [edit forwarding-options] nivel de jerarquía para indicar las etiquetas por LSP. Si el enrutador par no está equipado para manejar etiquetas de equilibrio de carga, puede evitar que el enrutador de borde del proveedor (PE) señale la capacidad de etiqueta de entropía mediante la configuración de la no-load-balance-label-capability instrucción en el [edit forwarding-options] nivel de jerarquía.

Los enrutadores de tránsito no requieren configuración. La presencia de la etiqueta de entropía indica al enrutador de tránsito que el equilibrio de carga se basa únicamente en la pila de etiquetas MPLS.

Los enrutadores de penúltimo salto emergen de forma predeterminada la etiqueta de entropía.

Ejemplo: Configuración de una etiqueta de entropía para un BGP etiquetado como LSP de unidifusión

En este ejemplo, se muestra cómo configurar una etiqueta de entropía para un unidifusión etiquetado como BGP para lograr un equilibrio de carga de extremo a extremo mediante etiquetas de entropía. Cuando un paquete IP tiene varias rutas para llegar a su destino, Junos OS utiliza ciertos campos de los encabezados de paquete para hash el paquete en una ruta determinista. Esto requiere una etiqueta de entropía, una etiqueta especial de equilibrio de carga que pueda transportar la información de flujo. Los LSR en el núcleo simplemente usan la etiqueta de entropía como la clave para hash del paquete a la ruta correcta. Una etiqueta de entropía puede ser cualquier valor de etiqueta entre 16 y 1048575 (intervalo regular de etiquetas de 20 bits). Dado que este intervalo se superpone con el rango de etiquetas regular existente, se inserta una etiqueta especial denominada indicador de etiqueta de entropía (ELI) antes de la etiqueta de entropía. ELI es una etiqueta especial asignada por IANA con el valor de 7.

Los unidifusión etiquetados como BGP concatenan generalmente RSVP o LSP LDP en varias áreas de IGP o en varios sistemas autónomos. Las etiquetas de entropía RSVP o LDP se muestran en el penúltimo nodo de salto, junto con la etiqueta RSVP o LDP. Esta función permite el uso de etiquetas de entropía en los puntos de unión para unir la brecha entre el penúltimo nodo de salto y el punto de unión, con el fin de lograr el equilibrio de carga de etiqueta de entropía de extremo a extremo para el tráfico BGP.

Requisitos

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

  • Siete enrutadores serie MX con MPC

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

Antes de configurar una etiqueta de entropía para bgp etiquetado como unidifusión, asegúrese de:

  1. Configure las interfaces del dispositivo.

  2. Configure OSPF o cualquier otro protocolo IGP.

  3. Configure BGP.

  4. Configure RSVP.

  5. Configure MPLS.

Descripción general

Cuando el BGP etiquetado como unidifusión concatena RSVP o LDP LSP en varias áreas de IGP o varios sistemas autónomos, las etiquetas de entropía RSVP o LDP se colocan en el penúltimo nodo de salto, junto con la etiqueta RSVP o LDP. Sin embargo, no hay etiquetas de entropía en los puntos de unión, es decir, los enrutadores entre dos áreas. Por lo tanto, los enrutadores en los puntos de unión usaron las etiquetas del BGP para reenviar paquetes.

A partir de Junos OS versión 15.1, puede configurar una etiqueta de entropía para el BGP etiquetado como unidifusión para lograr un equilibrio de carga de etiqueta de entropía de extremo a extremo. Esta función permite el uso de una etiqueta de entropía en los puntos de unión para lograr un equilibrio de carga de etiqueta de entropía de extremo a extremo para el tráfico bgp. Junos OS permite la inserción de etiquetas de entropía en el BGP etiquetado como entrada LSP de unidifusión.

De forma predeterminada, los enrutadores que admiten etiquetas de entropía se configuran con la load-balance-label-capability instrucción en el [edit forwarding-options] nivel de jerarquía para indicar las etiquetas por LSP. Si el enrutador par no está equipado para manejar etiquetas de equilibrio de carga, puede evitar la señalización de la capacidad de etiqueta de entropía mediante la configuración del no-load-balance-label-capability nivel jerárquico [edit forwarding-options] .

Nota:

Puede deshabilitar explícitamente la capacidad de etiqueta de entropía publicitaria en la salida para rutas especificadas en la política con la no-entropy-label-capability opción en el [edit policy-options policy-statement policy name then] nivel de jerarquía.

Topología

En Figura 3 , el enrutador PE1 es el enrutador de entrada y el enrutador PE2 es el enrutador de salida. Los enrutadores P1 y P2 son los enrutadores de tránsito. El enrutador ABR es el enrutador de puente de área entre el área 0 y el área 1. El LAG se configura en los enrutadores del proveedor para equilibrar la carga del tráfico. La capacidad de etiqueta de entropía para unidifusión etiquetada como BGP está habilitada en el enrutador de entrada PE1.

Figura 3: Configuración de una etiqueta de entropía para bgp etiquetado como unidifusiónConfiguración de una etiqueta de entropía para bgp etiquetado como unidifusión

Configuración

Configuración rápida de CLI

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

Enrutador PE1

Enrutador P1

ABR del enrutador

Enrutador P2

PE2 del enrutador

Configuración del enrutador PE1

Procedimiento paso a paso

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

Para configurar el ENRUTADOR PE1:

Nota:

Repita este procedimiento para EL PE2 del enrutador después de modificar los nombres de interfaz, las direcciones y otros parámetros adecuados.

  1. Configure las interfaces con direcciones IPv4 e IPv6.

  2. Configure la interfaz de circuito cerrado.

  3. Establezca el ID del enrutador y el número del sistema autónomo.

  4. Configure el protocolo RSVP para todas las interfaces.

  5. Habilite MPLS en todas las interfaces del enrutador PE1 y especifique el LSP.

  6. Configure el IBGP en los enrutadores internos.

  7. Habilite la capacidad de etiqueta de entropía para unidifusión etiquetada de BGP para ibgp del grupo BGP interno.

  8. Habilite el protocolo OSPF en todas las interfaces del enrutador de borde de área (ABR).

  9. Defina listas de prefijos para especificar las rutas con capacidad de etiqueta de entropía.

  10. Defina una política EL para especificar las rutas con capacidad de etiqueta de entropía.

  11. Defina otra política EL-2 para especificar las rutas con capacidad de etiqueta de entropía.

  12. Defina una política para exportar rutas BGP a la tabla de enrutamiento OSPF.

  13. Defina una política para exportar rutas OSPF a la tabla de enrutamiento BGP.

  14. Defina una política para exportar rutas estáticas a la tabla de enrutamiento BGP.

  15. Configure un destino VPN para la comunidad VPN.

  16. Configure la instancia de enrutamiento VPN de capa 3 VPN-l3vpn.

  17. Asigne las interfaces para la instancia de enrutamiento VPN-l3vpn.

  18. Configure el distinguidor de rutas para la instancia de enrutamiento VPN-l3vpn.

  19. Configure un destino de enrutamiento y reenvío VPN (VRF) para la instancia de enrutamiento VPN-l3vpn.

  20. Configure una ruta estática al dispositivo CE1 mediante el protocolo VPN de capa 3 para la instancia de enrutamiento VPN-l3vpn.

  21. Exporte las rutas BGP a la tabla de enrutamiento OSPF para la instancia de enrutamiento VPN-l3vpn.

  22. Asigne la interfaz OSPF para la instancia de enrutamiento VPN-l3vpn.

Configuración del enrutador P1

Procedimiento paso a paso

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

Para configurar el enrutador P1:

Nota:

Repita este procedimiento para el enrutador P2 después de modificar los nombres, direcciones y otros parámetros de interfaz adecuados.

  1. Configure las interfaces con direcciones IPv4 e IPv6.

  2. Configure la agregación de vínculos en las interfaces.

  3. Configure la interfaz de circuito cerrado.

  4. Configure etiquetas MPLS que el enrutador usa para hashizar los paquetes en su destino para equilibrar la carga.

  5. Establezca el ID del enrutador y el número del sistema autónomo.

  6. Habilite el equilibrio de carga por paquete.

  7. Configure el protocolo RSVP para todas las interfaces.

  8. Habilite MPLS en todas las interfaces del enrutador P1 y especifique el LSP.

  9. Habilite el protocolo OSPF en todas las interfaces del enrutador P1, excluyendo la interfaz de administración.

  10. Defina una política para el equilibrio de carga por paquete.

Configuración de ABR del enrutador

Procedimiento paso a paso

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

Para configurar la ABR del enrutador:

  1. Configure las interfaces con direcciones IPv4 e IPv6.

  2. Configure la interfaz de circuito cerrado.

  3. Configure la agregación de vínculos en las interfaces.

  4. Configure etiquetas MPLS que el enrutador usa para hashizar los paquetes en su destino para equilibrar la carga.

  5. Establezca el ID del enrutador y el número del sistema autónomo.

  6. Habilite el equilibrio de carga por paquete.

  7. Configure el protocolo RSVP para todas las interfaces.

  8. Habilite MPLS en todas las interfaces del enrutador P1 y especifique el LSP.

  9. Configure el IBGP en los enrutadores internos.

  10. Habilite el protocolo OSPF en todas las interfaces de ABR.

  11. Defina una política para especificar las rutas con capacidad de etiqueta de entropía.

Resultados

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

Verificación

Confirme que la configuración funciona correctamente.

Verificar que la capacidad de etiqueta de entropía se anuncia desde el ENRUTADOR PE2

Propósito

Verifique que el atributo de la ruta de capacidad de la etiqueta de entropía se anuncie desde el ENRUTADOR ASCENDENTE PE2 a la salida.

Acción

Desde el modo operativo, ejecute el comando en el show route 10.255.101.200 advertising-protocol bgp 10.255.102.102 enrutador PE2.

Significado

El resultado muestra que el HOST PE2 con la dirección IP de 10.255.101.200 tiene la capacidad de etiqueta de entropía. El host anuncia la capacidad de etiqueta de entropía para sus vecinos del BGP.

Verificar que el enrutador ABR recibe el anuncio de etiqueta de entropía

Propósito

Verifique que el enrutador ABR reciba el anuncio de etiqueta de entropía en la entrada del enrutador PE2.

Acción

Del modo operativo, ejecute el comando en el show route 10.255.101.200 receiving-protocol bgp 10.255.101.200 enrutador ABR.

Significado

El ENRUTADOR ABR recibe el anuncio de la capacidad de la etiqueta de entropía de su PE2 vecino del BGP.

Comprobación de que la marca de etiqueta de entropía está establecida

Propósito

Compruebe que la marca de etiqueta de entropía está establecida para los elementos de etiqueta en la entrada.

Acción

Desde el modo operativo, ejecute el comando en el show route protocol bgp detail enrutador PE1.

Significado

Se habilita una etiqueta de entropía en el enrutador PE1. El resultado muestra que la etiqueta de entropía se utiliza para el BGP etiquetado como unidifusión para lograr el equilibrio de carga de extremo a extremo.

Configuración de Ultimate-Hop Popping para LSP

De forma predeterminada, los LSP con señal RSVP utilizan penúltimo salto emergente (PHP). Figura 4 ilustra un penúltimo salto que aparece LSP entre el enrutador PE1 y el enrutador PE2. El enrutador CE1 reenvía un paquete a su próximo salto (enrutador PE1), que también es la entrada LSP. El enrutador PE1 inserta la etiqueta 1 en el paquete y reenvía el paquete etiquetado al enrutador P1. El enrutador P1 completa la operación de intercambio de etiquetas MPLS estándar, intercambia la etiqueta 1 por la etiqueta 2 y reenvía el paquete al enrutador P2. Dado que el enrutador P2 es el penúltimo enrutador de salto para LSP al enrutador PE2, primero extrae la etiqueta y, luego, reenvía el paquete al enrutador PE2. Cuando el enrutador PE2 lo recibe, el paquete puede tener una etiqueta de servicio, una etiqueta explicit-null o simplemente ser un paquete IP o VPLS sin formato. El ENRUTADOR PE2 reenvía el paquete sin etiquetar al enrutador CE2.

Figura 4: Penúltimo salto para una LSPPenúltimo salto para una LSP

También puede configurar ultimate-hop popping (UHP) (como se muestra en Figura 5) para LSP con señal RSVP. Algunas aplicaciones de red pueden requerir que los paquetes lleguen al enrutador de salida (enrutador PE2) con una etiqueta externa no nula. Para un LSP de salto final, el penúltimo enrutador (enrutador P2 in Figura 5) realiza la operación de intercambio de etiquetas MPLS estándar (en este ejemplo, la etiqueta 2 para la etiqueta 3 ) antes de reenviar el paquete al enrutador de salida PE2. El enrutador PE2 extrae la etiqueta externa y realiza una segunda búsqueda de la dirección del paquete para determinar el destino final. A continuación, reenvía el paquete al destino adecuado (ya sea el enrutador CE2 o el enrutador CE4).

Figura 5: Ultimate-Hop Popping para un LSPUltimate-Hop Popping para un LSP

Las siguientes aplicaciones de red requieren que configure LSP UHP:

  • MPLS-TP para monitoreo de rendimiento y OAM en banda

  • Circuitos virtuales de protección de borde

Las siguientes funciones no admiten el comportamiento de UHP:

  • LSP señalizados por LDP

  • LSP estáticos

  • LSP punto a multipunto

  • CCC

  • traceroute Comando

Para obtener más información sobre el comportamiento de UHP, consulte Borrador de Internet draft-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt, Comportamiento no PHP y Asignación fuera de banda para LSP RSVP-TE.

Para los LSP con señal RSVP punto a punto, el comportamiento UHP se señala desde la entrada LSP. Según la configuración del enrutador de entrada, RSVP puede indicar el LSP UHP con el conjunto de indicadores que no sean PHP. Los mensajes de ruta RSVP llevan los dos indicadores en el objeto LSP-ATTRIBUTES. Cuando el enrutador de salida recibe el mensaje PATH, asigna una etiqueta no nula al LSP. RSVP también crea e instala dos rutas en la tabla de enrutamiento mpls.0. S hace referencia al bit S de la etiqueta MPLS, que indica si se ha alcanzado la parte inferior de la pila de etiquetas.

  • Ruta S=0: indica que hay más etiquetas en la pila. El siguiente salto de esta ruta apunta a la tabla de enrutamiento mpls.0, lo que activa una búsqueda de etiquetas MPLS encadenado para descubrir las etiquetas MPLS restantes en la pila.

  • Ruta S=1: indica que no hay más etiquetas. El siguiente salto apunta a la tabla de enrutamiento inet.0 si la plataforma admite búsquedas encadenadas y multifamiliar. Como alternativa, la ruta de etiqueta puede apuntar a una interfaz VT para iniciar el reenvío IP.

Si habilita LSP UHP, las aplicaciones MPLS como VPN de capa 3, VPLS, VPN de capa 2 y circuitos de capa 2 pueden utilizar los LSP UHP. A continuación, se explica cómo los LSP UHP afectan a los diferentes tipos de aplicaciones MPLS:

  • VPN de capa 2 y circuitos de capa 2: un paquete llega al enrutador de PE (salida del LSP UHP) con dos etiquetas. La etiqueta externa (S=0) es la etiqueta UHP y la etiqueta interna (S=1) es la etiqueta VC . Una búsqueda basada en la etiqueta de transporte da como resultado un identificador de tabla para la tabla de enrutamiento mpls.0. Hay una ruta adicional en la tabla de enrutamiento mpls.0 correspondiente a la etiqueta interna. Una búsqueda basada en la etiqueta interna da como resultado el próximo salto del enrutador CE.

  • VPN de capa 3: un paquete llega al enrutador de PE (salida del LSP UHP) con dos etiquetas. La etiqueta externa (S=0) es la etiqueta UHP y la etiqueta interna es la etiqueta VPN (S=1). Una búsqueda basada en la etiqueta de transporte da como resultado el identificador de la tabla para la tabla de enrutamiento mpls.0. Hay dos casos en este caso. De forma predeterminada, las VPN de capa 3 anuncian la etiqueta por salto siguiente. Una búsqueda basada en la etiqueta interna da como resultado el siguiente salto hacia el enrutador CE. Sin embargo, si ha configurado la vrf-table-label instrucción para la instancia de enrutamiento VPN de capa 3, la etiqueta LSI interna apunta a la tabla de enrutamiento VRF. También se completa una búsqueda IP para la tabla de enrutamiento VRF.

    Nota:

    UHP para VPN de capa 3 configuradas con la vrf-table-label instrucción solo se admite en plataformas de enrutamiento universal 5G serie MX.

  • VPLS: un paquete llega al enrutador de PE (salida del LSP UHP) con dos etiquetas. La etiqueta externa es la etiqueta de transporte (S=0) y la etiqueta interna es la etiqueta VPLS (S=1). Una búsqueda basada en la etiqueta de transporte da como resultado el identificador de la tabla para la tabla de enrutamiento mpls.0. Una búsqueda basada en la etiqueta interna en la tabla de enrutamiento mpls.0 da como resultado la interfaz de túnel LSI de la instancia de enrutamiento VPLS si los servicios de túnel no están configurados (o una interfaz VT no está disponible). Los enrutadores serie MX 3D admiten búsqueda en cadena y búsqueda multifamiliar.

    Nota:

    La UHP para VPLS configurada con la no-tunnel-service instrucción solo se admite en enrutadores serie MX 3D.

  • IPv4 a través de MPLS: un paquete llega al enrutador de PE (salida del LSP UHP) con una etiqueta (S=1). Una búsqueda basada en esta etiqueta devuelve una interfaz de túnel VT. Otra búsqueda IP se completa en la interfaz VT para determinar dónde reenviar el paquete. Si la plataforma de enrutamiento admite búsquedas multifamiliar y encadenadas (por ejemplo, enrutadores MX 3D y enrutadores de transporte de paquetes serie PTX), la búsqueda basada en la ruta de etiqueta (S=1) apunta a la tabla de enrutamiento inet.0.

  • IPv6 sobre MPLS: para la tunelización IPv6 a través de MPLS, los enrutadores de PE anuncian rutas IPv6 entre sí con un valor de etiqueta de 2. Esta es la etiqueta null explícita para IPv6. Como resultado, los próximos saltos de reenvío para rutas IPv6 que se aprenden de enrutadores de PE remotos normalmente insertan dos etiquetas. La etiqueta interna es 2 (podría ser diferente si el enrutador de PE publicitario es de otro proveedor) y la etiqueta del enrutador es la etiqueta LSP. Los paquetes llegan al enrutador de PE (salida del LSP UHP) con dos etiquetas. La etiqueta externa es la etiqueta de transporte (S=0) y la etiqueta interna es la etiqueta explicit-null IPv6 (etiqueta 2). La búsqueda basada en la etiqueta interna de la tabla de enrutamiento mpls.0 redirige de nuevo a la tabla de enrutamiento mpls.0. En los enrutadores serie MX 3D, se quita la etiqueta interna (etiqueta 2) y se realiza una búsqueda IPv6 mediante la tabla de enrutamiento inet6.0.

  • Habilitación de LSP PHP y UHP: puede configurar ambos LSP PHP y UHP a través de las mismas rutas de red. Puede separar el tráfico PHP y UHP seleccionando reenviar los próximos saltos de LSP mediante una expresión regular con la install-nexthop instrucción. También puede separar el tráfico simplemente nombrando los LSP adecuadamente.

Las siguientes instrucciones habilitan el salto final para un LSP. Puede habilitar esta función en un LSP específico o para todos los LSP de entrada configurados en el enrutador. Configure estas instrucciones en el enrutador en la entrada LSP.

  1. Para habilitar el salto final, incluya la ultimate-hop-popping instrucción:

    Incluya esta instrucción en el [edit protocols mpls label-switched-path label-switched-path-name] nivel jerárquico para habilitar el salto final en un LSP específico. Incluya esta instrucción en el [edit protocols mpls] nivel jerárquico para habilitar el salto final en todos los LSP de entrada configurados en el enrutador. También puede configurar la ultimate-hop-popping instrucción en los niveles de jerarquía equivalentes [edit logical-routers] .

    Nota:

    Cuando se habilita el salto final, RSVP intenta renunciar a los LSP existentes como LSP de salto final de una manera de hacer antes del descanso. Si un enrutador de salida no admite salto final, el LSP existente se derriba (RSVP envía un mensaje PathTear a lo largo de la ruta de un LSP, quitando el estado de la ruta y el estado de reserva dependiente y liberando los recursos de red asociados).

    Si deshabilita el salto final, RSVP resigna los LSP existentes como penúltimo salto saltando LSP de una manera de hacer antes del descanso.

  2. Si desea habilitar tanto los saltos finales como los próximos saltos encadenados solo en enrutadores serie MX 3D, también debe configurar la enhanced-ip opción para la network-services instrucción:

    Configure esta instrucción en el nivel de [edit chassis] jerarquía. Una vez que haya configurado la network-services instrucción, debe reiniciar el enrutador para habilitar el comportamiento de UHP.

Configuración de LSP de ruta explícita

Si deshabilita el cálculo de rutas restringidas conmutadas por etiquetas (LSP), como se describe en Deshabilitar computación LSP de ruta restringida, puede configurar LSP manualmente o permitir que los LSP sigan la ruta de IGP.

Cuando se configuran los LSP de ruta explícita, el LSP se establece a lo largo de la ruta especificada. Si la ruta no es topologíalmente factible, ya sea porque la red está particionada o porque hay recursos insuficientes disponibles a lo largo de algunas partes de la ruta, el LSP fallará. No se pueden usar rutas alternativas. Si la configuración se realiza correctamente, el LSP permanece en la ruta definida de forma indeterminada.

Para configurar un LSP de ruta explícita, siga estos pasos:

  1. Configure la información de la ruta en una ruta con nombre, como se describe en Creación de rutas con nombre. Para configurar la información de ruta completa, especifique cada salto de enrutador entre los enrutadores de entrada y salida, preferiblemente mediante el strict atributo. Para configurar información de ruta incompleta, especifique solo un subconjunto de saltos del enrutador mediante el loose atributo en lugares en los que la ruta está incompleta.

    En el caso de rutas incompletas, los enrutadores MPLS completan la ruta consultando la tabla de enrutamiento local. Esta consulta se realiza salto a salto, y cada enrutador puede averiguar solo la información suficiente para alcanzar el próximo salto explícito. Es posible que sea necesario atravesar varios enrutadores para alcanzar el siguiente salto explícito (suelto).

    Configurar información de ruta incompleta crea partes de la ruta que dependen de la tabla de enrutamiento actual, y esta parte de la ruta puede volver a enrutarse a medida que cambia la topología. Por lo tanto, una LSP de ruta explícita que contiene información de ruta incompleta no es completamente fija. Estos tipos de LSP solo tienen una capacidad limitada para repararse a sí mismos, y tienden a crear bucles o flaps según el contenido de la tabla de enrutamiento local.

  2. Para configurar el LSP y apuntarlo a la ruta denominada, use la primary instrucción o secondary , como se describe en Configurar LSP principal y secundario.

  3. Deshabilite la computación LSP de ruta restringida incluyendo la no-cspf instrucción como parte del LSP o como parte de una primary instrucción o secondary . Para obtener más información, consulte Deshabilitar computación LSP de ruta restringida.

  4. Configure cualquier otra propiedad de LSP.

El uso de LSP de ruta explícita tiene los siguientes inconvenientes:

  • Se requiere más esfuerzo de configuración.

  • La información de ruta configurada no puede tener en cuenta la reserva dinámica de ancho de banda de la red, por lo que los LSP tienden a fallar cuando los recursos se agotan.

  • Cuando se produce un error en una LSP de ruta explícita, es posible que tenga que repararla manualmente.

Debido a estas limitaciones, recomendamos que use LSP de ruta explícita solo en situaciones controladas, como para aplicar una estrategia de colocación LSP optimizada resultante de cálculos con un paquete de software de simulación sin conexión.

Ejemplo: Configuración de un LSP de ruta explícita

En el enrutador de entrada, cree un LSP de ruta explícita y especifique los enrutadores de tránsito entre los enrutadores de entrada y salida. En esta configuración, no se realiza ningún cálculo de ruta restringida. Para la ruta principal, todos los saltos intermedios se especifican estrictamente para que su ruta no pueda cambiar. La ruta secundaria debe desplazarse por el enrutador 14.1.1.1 primero y, luego, tomar cualquier ruta disponible para llegar al destino. La ruta restante que toma la ruta secundaria suele ser la ruta más corta calculada por el IGP.

Descripción general de la sobresuscripción de ancho de banda LSP

Los LSP se establecen con reservas de ancho de banda configuradas para la cantidad máxima de tráfico que espera atravesar el LSP. No todos los LSP llevan la cantidad máxima de tráfico a través de sus vínculos en todo momento. Por ejemplo, incluso si el ancho de banda del vínculo A se ha reservado por completo, es posible que el ancho de banda real aún esté disponible pero no esté en uso actualmente. Este exceso de ancho de banda se puede utilizar al permitir que otros LSP también usen el vínculo A, sobrescribiendo el vínculo. Puede sobrescribir el ancho de banda configurado para tipos de clase individuales o especificar un único valor para todos los tipos de clase mediante una interfaz.

Puede usar la suscripción excesiva para aprovechar la naturaleza estadística de los patrones de tráfico y para permitir una mayor utilización de vínculos.

En los ejemplos siguientes se describe cómo puede usar el ancho de banda sobresuscripción y subscripción:

  • Utilice la suscripción excesiva en tipos de clase en los que los períodos pico de tráfico no coincidan a tiempo.

  • Utilice una suscripción excesiva de tipos de clase que transporten tráfico de mejor esfuerzo. Corre el riesgo de retrasar o dejar caer temporalmente el tráfico a cambio de hacer una mejor utilización de los recursos de red.

  • Proporcione diferentes grados de sobresuscripción o subsuscripción de tráfico para los diferentes tipos de clase. Por ejemplo, configure la suscripción para clases de tráfico de la siguiente manera:

    • Mejor esfuerzo:ct0 1000

    • Voz:ct3 1

Cuando se subscribe un tipo de clase para una LSP multiclase, la demanda total de todas las sesiones RSVP siempre es menor que la capacidad real del tipo de clase. Puede usar subsuscripción para limitar la utilización de un tipo de clase.

El cálculo de sobresuscripción de ancho de banda se produce solo en el enrutador local. Dado que no se requiere ninguna señal u otra interacción de otros enrutadores de la red, la función se puede habilitar en enrutadores individuales sin estar habilitada o disponible en otros enrutadores que podrían no admitir esta función. Los enrutadores vecinos no necesitan saber sobre el cálculo de sobresuscripción, confían en el IGP.

En las siguientes secciones se describen los tipos de sobresuscripción de ancho de banda disponibles en Junos OS:

Sobresuscripción de tamaño LSP

Para la sobresuscripción del tamaño de LSP, simplemente configura menos ancho de banda que la velocidad máxima esperada para el LSP. También es posible que deba ajustar la configuración de los agentes de policía automáticos. Los agentes de policía automáticos administran el tráfico asignado a un LSP, lo que garantiza que no supere los valores de ancho de banda configurados. La sobresuscripción del tamaño de LSP requiere que el LSP pueda superar su asignación de ancho de banda configurada.

La policía sigue siendo posible. Sin embargo, el aplicador de políticas debe configurarse manualmente para tener en cuenta el ancho de banda máximo planificado para el LSP, en lugar del valor configurado.

Multiplicadores de sobresuscripción de tipo de clase y sobresuscripción local

Los multiplicadores de sobresuscripción local (LDM) permiten diferentes valores de sobresuscripción para diferentes tipos de clase. Las LDM son útiles para redes en las que la relación de sobresuscripción debe configurarse de manera diferente en distintos vínculos y en las que se requieren valores de sobresuscripción para diferentes clases. Puede usar esta característica para sobrescribir tipos de clase que administran el tráfico de mejor esfuerzo, pero no usar una sobresuscripción para los tipos de clase que gestionan el tráfico de voz. Un LOM se calcula localmente en el enrutador. No se indica ninguna información relacionada con un LOM a otros enrutadores de la red.

Una LOM se puede configurar en cada vínculo y para cada tipo de clase. El tipo de LOM por clase le permite aumentar o disminuir la relación de sobresuscripción. El LOM por clase se considera en toda la contabilidad de ancho de banda local para el control de admisión y el anuncio de IGP de anchos de banda no reservados.

El cálculo de LOM está vinculado al modelo de ancho de banda (MAM, MAM extendido y muñecas rusas) utilizado, ya que el efecto de la sobresuscripción en los tipos de clase debe tenerse en cuenta con precisión.

Nota:

Junos OS realiza todos los cálculos de LOM y no requiere intervención del usuario.

Las fórmulas relacionadas con la sobresuscripción de tipos de clase se describen en las siguientes secciones:

Configuración del porcentaje de suscripción de ancho de banda para LSP

De forma predeterminada, RSVP permite usar todo el ancho de banda de un tipo de clase (100 por ciento) para reservas de RSVP. Cuando sobrescriba un tipo de clase para un LSP multiclase, se permite que la demanda agregada de todas las sesiones RSVP supere la capacidad real del tipo de clase.

Si desea sobrescribir o subscribir todos los tipos de clase en una interfaz con el mismo ancho de banda porcentual, configure el porcentaje mediante la subscription instrucción:

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

Para subscribir o sobrescribir el ancho de banda para cada tipo de clase, configure un porcentaje para cada tipo de clase (ct0, ct1, ct2, y ct3) opción para la subscription instrucción. Cuando sobrescriba un tipo de clase, se aplica un LOM para calcular el ancho de banda real reservado. Consulte Multiplicadores de sobresuscripción de tipo de clase y sobresuscripción local para obtener más información.

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

percentage es el porcentaje de ancho de banda de clase que RSVP permite usar para reservas. Puede ser un valor del 0 al 65 000 por ciento. Si especifica un valor mayor que 100, está sobrescribiendo la interfaz o el tipo de clase.

El valor que se configura cuando sobresuscribe un tipo de clase es un porcentaje del ancho de banda del tipo de clase que se puede utilizar realmente. El valor de suscripción predeterminado es del 100 %.

Puede usar la subscription instrucción para deshabilitar nuevas sesiones RSVP para uno o más tipos de clase. Si configura un porcentaje de 0, no se permiten sesiones nuevas (incluidas aquellas con requisitos de ancho de banda cero) para el tipo de clase.

Las sesiones de RSVP existentes no se ven afectadas por el cambio del factor de suscripción. Para borrar una sesión existente, ejecute el clear rsvp session comando. Para obtener más información sobre el clear rsvp session comando, consulte el Explorador de CLI.

Restricciones para configurar la suscripción de ancho de banda

Tenga en cuenta los siguientes problemas al configurar la suscripción de ancho de banda:

  • Si configura restricciones de ancho de banda en el [edit class-of-service interface interface-name] nivel de jerarquía, anulan cualquier configuración de ancho de banda que especifique en el [edit protocols rsvp interface interface-name bandwidth] nivel de jerarquía para Diffserv-TE. También tenga en cuenta que cualquiera de las restricciones de ancho de banda CoS o RSVP puede invalidar las restricciones de ancho de banda de hardware de interfaz.

  • Si configura un valor de suscripción de ancho de banda para una interfaz específica que difiere del valor configurado para todas las interfaces (incluyendo valores diferentes para la subscription instrucción en los [edit protocols rsvp interface interface-name] niveles de jerarquía y [edit protocols rsvp interface all] ), el valor específico de la interfaz se usa para esa interfaz.

  • Solo puede configurar la suscripción para cada tipo de clase si también configura un modelo de ancho de banda. Si no se configura ningún modelo de ancho de banda, la operación de confirmación falla con el siguiente mensaje de error:

  • No puede incluir la subscription instrucción tanto en la configuración de un tipo de clase específico como en la configuración de toda la interfaz. La operación de confirmación falla con el siguiente mensaje de error:

Tabla de historial de versiones
Liberación
Descripción
14.1R9
A partir de Junos OS versión 14.1R9, 15.1R7, 16.1R5, 16.1X2, 16.2R3 y 17.2R2, todas las muestras de ancho de banda de valor cero se consideran muestras de bajo flujo, excepto las muestras de valor cero que llegan después de que un LSP aparece por primera vez, y las muestras de valor cero que llegan primero después de un cambio de motor de enrutamiento.