Configuración de LSP del contenedor
Descripción general de la administración dinámica de ancho de banda mediante LSP de contenedor
Los LSP de RSVP con la función de ancho de banda automático se despliegan cada vez más en las redes para satisfacer las necesidades de ingeniería de tráfico. Sin embargo, las soluciones de ingeniería de tráfico actuales para los LSP punto a punto son ineficientes en términos de utilización del ancho de banda de la red, principalmente porque los enrutadores de entrada que originan los LSP RSVP intentan ajustar los LSP a lo largo de una ruta determinada sin crear LSP paralelos o no interactúan con los otros enrutadores de la red y sondean el ancho de banda adicional disponible.
Esta característica proporciona a un enrutador de entrada la capacidad de adquirir tanto ancho de banda de red como sea posible mediante la creación dinámica de LSP paralelos.
- Descripción de las extensiones de múltiples rutas RSVP
- Implementación de múltiples rutas RSVP de Junos OS
- Desafíos actuales de la ingeniería de tráfico
- Uso de LSP de contenedor como solución
- Implementación de LSP de contenedor de Junos OS
- Instrucciones de configuración admitidas para los LSP de contenedor
- Impacto de la configuración de LSP de contenedor en el rendimiento de la red
- Características admitidas y no compatibles
Descripción de las extensiones de múltiples rutas RSVP
Las extensiones de múltiples rutas RSVP propuestas en el IETF [KOMPELLA-MLSP] permiten la configuración de rutas de conmutación de etiquetas de múltiples rutas diseñadas por tráfico (LSP de contenedor). Los LSP de contenedor, además de cumplir con las restricciones de ingeniería de tráfico, utilizan múltiples rutas independientes desde un origen hasta un destino, lo que facilita el equilibrio de carga del tráfico. Las extensiones multiruta requieren cambios en el protocolo RSVP-TE y permiten la fusión de etiquetas en los nodos posteriores (similar a LDP), lo que también ayuda a preservar los recursos de reenvío.
Las extensiones de múltiples rutas para confirmar su asistencia ofrecen las siguientes ventajas:
Facilidad de configuración. Normalmente, se configuran varios LSP RSVP para equilibrio de carga o empaquetado de contenedores. Con un LSP de contenedor, hay una única entidad para aprovisionar, administrar y monitorear LSP. Los cambios en la topología son manejados fácil y autónomamente por el LSP de entrada, agregando, cambiando o eliminando LSP miembro para reequilibrar el tráfico, manteniendo las mismas restricciones de ingeniería de tráfico.
RSVP de múltiples rutas de igual costo (ECMP) hereda los beneficios estándar de ECMP al absorber los picos de tráfico.
La ingeniería de tráfico de múltiples rutas permite un uso mejor y más completo de los recursos de red.
Conocer la relación entre los LSP ayuda a calcular diversas rutas con enrutamiento basado en restricciones. Permite el ajuste de los LSP miembro mientras otros LSP miembros continúan transportando tráfico.
Los enrutadores intermedios tienen la oportunidad de combinar las etiquetas de los LSP miembro. Esto reduce el número de etiquetas que deben agregarse al plano de reenvío y, a su vez, reduce el tiempo de convergencia.
Si el número de rutas ECMP independientes es enorme, la fusión de etiquetas supera las limitaciones de la plataforma en los próximos saltos máximos (ECMP). Con los LSP RSVP punto a punto que requieren protección de vínculo o nodo, los siguientes saltos se duplican a medida que cada LSP se programa con los siguientes saltos primarios y de respaldo. La multiruta RSVP (o ECMP) evita la necesidad de realizar copias de seguridad en los próximos saltos.
Cuando se produce un error de vínculo, el enrutador que precede a la falla del vínculo puede distribuir el tráfico desde el vínculo fallido a las ramas ECMP restantes, lo que evita la necesidad de derivar LSP. El enfoque de LSP de derivación no solo requiere más estado al señalar los LSP de respaldo, sino que también adolece de problemas de escalado que dan lugar a que se agote el tiempo de espera de un bloque de estado de ruta protegido (PSB) antes de que el punto de reparación local (PLR) tenga la oportunidad de señalar el LSP de respaldo.
Implementación de múltiples rutas RSVP de Junos OS
Para implementar varias rutas RSVP (ECMP) en una red, todos los nodos por los que pasan los LSP ECMP deben comprender las extensiones del protocolo RSVP ECMP. Esto puede ser un desafío, especialmente en redes de múltiples proveedores.
Junos OS implementa las extensiones RSVP de múltiples rutas sin necesidad de extensiones de protocolo. Se aprovisiona un LSP de contenedor único, que tiene las características de ECMP y RSVP TE. Un LSP de contenedor consta de varios LSP miembro y se configura entre el dispositivo de enrutamiento de entrada y salida. Cada LSP miembro toma una ruta diferente hacia el mismo destino. El dispositivo de enrutamiento de entrada está configurado con todos los parámetros necesarios para calcular el LSP ECMP RSVP. El dispositivo de enrutamiento de entrada también puede usar los parámetros configurados para calcular un conjunto de LSP punto a punto RSVP para calcular el LSP del contenedor.
Desafíos actuales de la ingeniería de tráfico
El principal desafío para la ingeniería de tráfico es hacer frente a la dinámica tanto de la topología como de las demandas de tráfico. Se necesitan mecanismos que puedan manejar la dinámica de carga de tráfico en escenarios con cambios repentinos en la demanda de tráfico y distribuir dinámicamente el tráfico para beneficiarse de los recursos disponibles.
Figura 1 muestra un ejemplo de topología de red con todos los LSP con las mismas prioridades de retención y configuración, y el control de admisión restringido en el enrutador de entrada. Todos los enlaces están anotados con una tupla (costo y capacidad).
Algunos de los problemas de ingeniería de tráfico que se ven en Figura 1 se enumeran a continuación:
Bin PackingEste problema surge debido a un orden particular en el que se señalan los LSP. Es posible que los enrutadores de entrada no puedan señalar algunos LSP con las demandas requeridas, aunque el ancho de banda esté disponible en la red, lo que lleva a una subutilización de la capacidad del vínculo.
Por ejemplo, los siguientes LSP llegan en la secuencia mencionada en Tabla 1.
Tabla 1: Orden de secuencia LSP para el embalaje de contenedores Hora
Fuente
Destino
Demanda
ERO
1
A
E
5
A-C-D-E
2
B
E
10
Sin ERO
El LSP que se origina en el enrutador B no es enrutable, ya que el enrutamiento basado en restricciones no encuentra una ruta factible. Sin embargo, si primero se señala el enrutador B, ambos LSP son enrutables. El empaquetado de contenedores se produce debido a la falta de visibilidad de las demandas individuales de ancho de banda por LSP y por dispositivo en el dispositivo de enrutamiento de entrada.
El embalaje de contenedores también puede ocurrir cuando no hay un requisito para ordenar LSP. Por ejemplo, si hay un LSP con demanda X y hay dos rutas diferentes al destino desde el enrutador de entrada con anchos de banda disponibles Y1 e Y2, de modo que Y1 es menor que X, Y2 es menor que X e Y1 más Y2 es mayor o igual que X.
En este caso, aunque haya suficientes recursos de red en términos de ancho de banda disponible para satisfacer la demanda agregada de LSP X, es posible que el LSP no se señalice ni se vuelva a optimizar con la nueva demanda. En Figura 1, con compatibilidad con LSP de contenedor, la entrada B crea dos LSP de tamaño 5 cada uno cuando se plantea la demanda 10. Un LSP se enruta a lo largo de B-C-E y otro a lo largo de B-C-D-E.
DeadlockConsiderando Figura 1, los LSP siguen la secuencia mencionada en Tabla 2.
Tabla 2: Orden de secuencia LSP para interbloqueo Hora
Fuente
Destino
Demanda
ERO
Encuentro
1
A
E
2
A-C-D-E
Enrutamiento basado en restricciones con señalización RSVP
2
B
E
2
B-C-D-E
Enrutamiento basado en restricciones con señalización RSVP
3
A
E
De 2 a 20
A-C-D-E
El enrutamiento basado en restricciones falla, no hay señalización RSVP
En el momento 3, la demanda de LSP de A a E aumenta de 2 a 20. Si se configura el ancho de banda automático, el cambio no se detecta hasta que expira el temporizador de ajuste. En ausencia de control de admisión en A, el aumento de la demanda de tráfico podría hacer que el tráfico disminuya en otros LSP que comparten vínculos comunes con el LSP que se comporta mal.
Esto sucede debido a las siguientes razones:
Falta de estado global en todos los enrutadores de entrada
Señalización de demandas que se comportan mal
Derribar las demandas que se comportan mal
Con el LSP del contenedor configurado, la entrada A tiene más posibilidades de dividir la carga (incluso incrementalmente, si no completamente) en varios LSP. Por lo tanto, es menos probable que LSP de A vea una pérdida de tráfico prolongada.
Latency InflationEl inflación de latencia es causado por el ancho de banda automático y otros parámetros de LSP. Algunos de los otros factores que contribuyen a la inflación de latencia incluyen:
Prioridad de LSP
Los LSP eligen rutas más largas porque las rutas más cortas entre centros de datos ubicados en la misma ciudad pueden estar congestionadas. El ancho de banda en las rutas más cortas puede agotarse con LSP de igual o mayor prioridad. Debido a la optimización periódica de LSP por ancho de banda automático, LSP puede redirigirse a una ruta de mayor retraso. Cuando muchos LSP se someten a una selección de ruta menos que óptima, potencialmente pueden formar una cadena de dependencias. Modificar las prioridades de LSP dinámicamente es una solución alternativa al problema; sin embargo, ajustar dinámicamente las prioridades de LSP para encontrar rutas más cortas es una tarea desafiante.
Política de todo o nada
Cuando la demanda de un LSP aumenta y al menos uno de los vínculos a lo largo de la ruta más corta está cerca de su límite de reserva, la optimización de LSP puede obligar al LSP a moverse a una ruta de latencia más larga. LSP tiene que atravesar un camino largo a pesar de que el camino corto es capaz de transportar la mayor parte del tráfico.
Ancho de banda mínimo y máximo
El ancho de banda mínimo y máximo especifica los límites de los tamaños de LSP. Si el ancho de banda mínimo es pequeño, un LSP es más propenso al ajuste automático del ancho de banda porque un pequeño cambio en el ancho de banda es suficiente para cruzar los límites del umbral. Los LSP pueden reenrutar aunque haya ancho de banda disponible. Por otro lado, si el ancho de banda mínimo es grande, es posible que se desperdicie el ancho de banda de la red. Si el valor máximo de ancho de banda es pequeño, es posible que se necesite una gran cantidad de LSP en el enrutador de entrada para satisfacer la demanda de la aplicación. Si el ancho de banda máximo es grande, los LSP pueden crecer en tamaño. Tales LSP pueden sufrir debido a una política de todo o nada.
Umbral de ajuste automático del ancho de banda
El umbral de ancho de banda determina si es necesario reoptimizar y cambiar el tamaño de los LSP. Si el valor es pequeño, los LSP se vuelven a optimizar y redireccionar con frecuencia. Eso podría causar un pico de CPU porque las aplicaciones o protocolos, como la resolución BGP a través de los LSP, podrían mantener al motor de enrutamiento ocupado haciendo la resolución del próximo salto. Un valor grande podría hacer que un LSP sea inmóvil. Con el LSP del contenedor configurado, es menos probable que un LSP esté sujeto a una o ninguna política. Un enrutador de entrada origina varios LSP, aunque no todos los LSP potencialmente atraviesan rutas de alta latencia.
PredictabilityLos proveedores de servicios a menudo quieren un comportamiento predecible en términos de cómo se señalizan y enrutan los LSP. Actualmente, sin ninguna coordinación global, es difícil establecer el mismo conjunto de LSP de una manera predecible. Considere los dos ordenamientos diferentes en Tabla 3 y Tabla 4. El ERO que utiliza un LSP depende de su tiempo de señalización.
Tabla 3: Orden de secuencia de LSP para previsibilidad Hora
Fuente
Destino
Demanda
ERO
1
A
E
5
A-C-D-E
2
B
E
5
B-C-E
Tabla 4: Orden de secuencia de LSP para previsibilidad Hora
Fuente
Destino
Demanda
ERO
1
B
E
5
B-C-E
2
A
E
5
A-C-D-E
El LSP de contenedor no ayuda directamente a los LSP a encontrar ERO predecibles. Si los LSP se redirigen debido a una política total o nula sin LSP de contenedor configurado, es posible que dichos LSP vean menos abandono si se configuran LSP de contenedor, ya que los LSP más pequeños tienen más posibilidades de encontrar una ruta más corta o la misma.
Uso de LSP de contenedor como solución
Un LSP de contenedor se puede utilizar como una solución a los desafíos que enfrentan las características actuales de ingeniería de tráfico. Considerando Figura 1, cuando la demanda X en un LSP de contenedor aumenta con la capacidad de red (flujo máximo) siendo mayor que la demanda, los siguientes enfoques entran en vigor con un LSP de contenedor:
- Acomodar la nueva demanda X
- Creación de nuevos proveedores de servicios lingüísticos para satisfacer la demanda X
- Asignación de ancho de banda a los nuevos LSP
- Control de las rutas de LSP
Acomodar la nueva demanda X
En la implementación actual, el ancho de banda automático intenta volver a señalar un LSP con la nueva demanda X y sigue la política de todo o nada como se mencionó anteriormente.
El enfoque LSP de contenedor calcula varios LSP de ancho de banda pequeños (más pequeños que la demanda X) de modo que el ancho de banda agregado no sea inferior a X, y el enrutador de entrada realiza este ajuste periódicamente. Uno de los desencadenadores para crear nuevos LSP o eliminar LSP antiguos se puede cambiar en ancho de banda agregado. Luego, el enrutador de entrada equilibra la carga del tráfico entrante a través de los LSP recién creados.
Creación de nuevos proveedores de servicios lingüísticos para satisfacer la demanda X
Aunque el número de nuevos LSP creados puede ser un máximo del límite configurable permitido, estos LSP no se benefician mucho una vez que el número de LSP supera el número de rutas diversas posibles o de múltiples rutas de acceso (ECMP) de igual costo. La ventaja de crear los LSP más pequeños se ve cuando un enrutador de entrada utiliza los LSP recién creados para equilibrar la carga del tráfico. Sin embargo, esto depende de la topología y el estado de la red.
La creación de varios LSP paralelos por parte de todos los enrutadores de entrada de la red puede provocar problemas de escalado en los enrutadores de tránsito. Por lo tanto, el número de nuevos LSP que se crearán depende del tamaño de los LSP individuales y de la demanda agregada dada, X en este caso.
Asignación de ancho de banda a los nuevos LSP
En general, puede haber una serie de heurísticas para asignar anchos de banda a los LSP recién creados. Un enrutador de entrada puede resolver un problema de optimización en el que puede maximizar una función de utilidad dada. El resultado de un problema de optimización es la asignación de valores óptimos de ancho de banda. Sin embargo, para resolver un problema de optimización, se debe corregir el número de LSP recién creados. Por lo tanto, es complejo optimizar el número y el tamaño de cada LSP. Por lo tanto, para simplificar el problema, se supone la misma cantidad de ancho de banda para todos los LSP recién creados y, a continuación, se calcula el número de LSP necesarios.
Control de las rutas de LSP
La flexibilidad para controlar las rutas de LSP se expresa en términos de la configuración de LSP punto a punto y LSP de contenedor. El control de las rutas LSP mediante los parámetros de configuración se puede aplicar bajo dos aspectos diferentes:
Topología: no hay restricciones de topología con esta función. Cada LSP miembro se trata como un LSP punto a punto y se vuelve a optimizar individualmente. Un enrutador de entrada no intenta calcular rutas de costo de IGP iguales para todos sus LSP, sino que calcula rutas para todos los LSP utilizando la información actual de la base de datos de ingeniería de tráfico. Al calcular una ruta, el enrutamiento basado en restricciones se adhiere a las restricciones especificadas a través de la configuración, aunque no hay cambios en el método de enrutamiento basado en restricciones para el cálculo de rutas.
Cuándo crear un nuevo LSP: se puede especificar explícitamente cuándo crear un nuevo LSP. De forma predeterminada, un enrutador de entrada calcula periódicamente la tasa de tráfico agregada sumando la tasa de tráfico de todos los LSP individuales. Al observar el ancho de banda agregado y la configuración, el enrutador de entrada vuelve a calcular el número de LSP y los anchos de banda de los LSP. A continuación, se señalizan los nuevos LSP o se vuelven a señalar los LSP existentes con el ancho de banda actualizado. En lugar de observar la tasa agregada instantánea, los enrutadores de entrada pueden calcular un promedio (de agregados) durante cierto tiempo mediante la eliminación de muestras atípicas (de agregados). Administrar los LSP que permanecen pendientes y activos teniendo en cuenta el ancho de banda agregado es más escalable que crear los nuevos LSP basados en el uso de un LSP determinado. Los intervalos y umbrales se pueden configurar para realizar un seguimiento del tráfico agregado y activar el ajuste. Estos LSP dinámicos coexisten e interoperan con la configuración de ancho de banda automático por LSP.
Implementación de LSP de contenedor de Junos OS
Un LSP contenedor es un LSP ECMP TE que actúa como un LSP contenedor que consta de uno o más LSP miembros. Un LSP TE punto a punto es equivalente a un LSP contenedor con un LSP de un solo miembro. Los LSP miembros se agregan al LSP del contenedor a través de un proceso llamado división y se eliminan del LSP del contenedor mediante un proceso llamado fusión.
- Terminología de LSP de contenedor
- División de LSP
- Fusión de LSP
- Protección de nodos y vínculos
- Convención de nomenclatura
- Normalización
- Cálculo de rutas de enrutamiento basadas en restricciones
- Muestreo
- Compatibilidad con NSR, IPG-FA y rutas estáticas
Terminología de LSP de contenedor
Los siguientes términos se definen en el contexto de un LSP de contenedor:
Normalization: suceso que se produce periódicamente cuando se realiza una acción para ajustar los LSP miembros, ya sea para ajustar sus anchos de banda, su número o ambos. Un proceso de normalización se asocia con un proceso de muestreo y estima periódicamente la utilización agregada de un LSP de contenedor.Nominal LSP: la instancia de un LSP de contenedor que siempre está presente.Supplementary LSP: las instancias o sub-LSP de un LSP de contenedor, que se crean o eliminan dinámicamente.El ancho de banda automático se ejecuta sobre cada uno de los LSP miembros, y cada LSP se redimensiona de acuerdo con el tráfico que transporta y los parámetros de configuración del ancho de banda automático. Se realiza un seguimiento de la demanda agregada de un LSP de contenedor sumando el ancho de banda de todos los LSP miembros.
Minimum signaling-bandwidth: el ancho de banda mínimo con el que se señala un LSP miembro en el momento de la normalización o inicialización. Esto podría ser diferente del ancho de banda mínimo definido en ancho de banda automático.Maximum signaling-bandwidth: el ancho de banda máximo con el que se señala un LSP miembro en el momento de la normalización o inicialización. Esto podría ser diferente del ancho de banda máximo definido en ancho de banda automático.Merging-bandwidth: especifica el umbral de ancho de banda inferior en el uso agregado de ancho de banda, de modo que si el uso agregado cae por debajo de este valor, el enrutador de entrada combina los LSP miembros en el momento de la normalización.Splitting-bandwidth: especifica el umbral de ancho de banda superior en el uso agregado del ancho de banda, de modo que si el uso agregado supera este valor, el enrutador de entrada divide los LSP miembros en el momento de la normalización.Aggregate minimum-bandwidth: suma del ancho de banda de fusión de los LSP miembros activos actuales. Este ancho de banda mínimo es diferente del ancho de banda mínimo de ancho de banda automático.Aggregate maximum-bandwidth: suma del ancho de banda de división de los LSP miembros activos actuales. Este ancho de banda máximo es diferente del ancho de banda máximo de ancho de banda automático.
División de LSP
Descripción general de las operaciones
El mecanismo de división de LSP permite que un enrutador de entrada cree nuevos LSP miembro o vuelva a señalar los LSP existentes con diferentes anchos de banda dentro de un LSP de contenedor cuando se coloca una demanda X en el LSP de contenedor. Con la división de LSP habilitada, un enrutador de entrada crea periódicamente una serie de LSP (señalando otros nuevos o reseñalando los existentes) para acomodar una nueva demanda agregada X. En la implementación actual, un enrutador de entrada intenta encontrar una ruta LSP que satisfaga una demanda X y otras restricciones. Si no se encuentra ninguna ruta, el LSP no recibe señal o permanece activo, pero con el antiguo ancho de banda reservado.
Entre dos eventos de normalización (división o fusión), los LSP individuales pueden volver a señalizarse con diferentes anchos de banda debido a los ajustes automáticos del ancho de banda. Si un LSP de contenedor no está configurado con ancho de banda automático, los LSP miembro se señalizan con el valor de ancho de banda estático, si está configurado. En este caso, no hay división dinámica, ya que no hay una estimación dinámica del ancho de banda agregado. Los ajustes de división con un valor de ancho de banda específico se pueden activar manualmente.
Tenga en cuenta las siguientes consideraciones para la división de LSP:
Después de la división de LSP, el enrutador de entrada continúa inyectando una adyacencia de reenvío. Las adyacencias de reenvío no son compatibles con IGP para esta característica.
Entre dos eventos de normalización, dos LSP pueden tener anchos de banda diferentes sujetos a restricciones de ancho de banda automático.
Después de dividir (o fusionar) los LSP, make-before-break usa el uso compartido de estilo de filtro fijo (FF), a menos que la
adaptiveopción esté configurada. Sin embargo, dos LSP diferentes no hacen el uso compartido de estilo explícito (SE) compartido para esta característica.Cuando los LSP se vuelven a señalar con anchos de banda modificados, es posible que algunos de los LSP no se señalicen correctamente, lo que da lugar a opciones de conmutación por error.
Limitaciones operativas
La división de LSP tiene las siguientes restricciones operativas:
Ancho de banda de LSP: aunque hay varias maneras de asignar valores de ancho de banda a los LSP, la implementación de Junos OS solo admite una política de asignación de ancho de banda igual cuando se realiza la normalización, en la que todos los LSP miembros se señalizan o reseñalan con el mismo ancho de banda.
Número de LSP: si un enrutador de entrada está configurado para tener un número mínimo de LSP, mantiene el número mínimo de LSP, incluso si la demanda se puede satisfacer con un número inferior al mínimo de LSP. En caso de que el enrutador de entrada no pueda realizar enrutamiento basado en restricciones para cálculos en el número suficiente de LSP o señal de un número suficiente de LSP, el enrutador de entrada recurre a una serie de opciones de conmutación por recuperación.
De forma predeterminada, se admite un enfoque incremental como una opción de reserva (a menos que se configure de otra manera), donde un enrutador de entrada intenta generar el número suficiente de LSP, de modo que el nuevo ancho de banda agregado supere el ancho de banda agregado anterior (y esté lo más cerca posible de la demanda deseada). A continuación, el enrutador de entrada equilibra la carga del tráfico mediante los LSP. El enrutador de entrada elimina los LSP que no se pudieron generar.
Criterios admitidos
Cuando un LSP contenedor señala a un LSP miembro, el LSP miembro recibe una señal con un ancho de banda de señalización mínimo. Dado que cada LSP miembro está configurado con ancho de banda automático, entre dos eventos de normalización, cada LSP puede someterse a un ajuste automático del ancho de banda varias veces. A medida que aumenta la demanda de tráfico, el enrutador de entrada crea LSP suplementarios adicionales. Todos los LSP miembro se usan para ECMP, por lo que deben tener aproximadamente el mismo ancho de banda reservado después de la normalización.
Por ejemplo, si hay K LSP señalados después de la normalización, cada LSP se señaliza con el mismo ancho de banda B. El ancho de banda agregado total reservado es B.K, donde B cumple la siguiente condición:
El ancho de banda de señalización mínimo es menor o igual que B, cuyo giro es menor o igual que el ancho de banda de señalización máximo
(ancho de banda de señalización mínimo ≤ B ≤ ancho de banda de señalización máximo)
Hasta el siguiente evento de normalización, cada LSP miembro se somete a varios ajustes automáticos de ancho de banda. Después de cualquier ajuste de ancho de banda automático, si hay N LSP con anchuras de banda reservadas bi, donde i=1,2,.., N, cada bi debe satisfacer la siguiente condición:
El ancho de banda mínimo es menor o igual que bi, que a su vez es menor o igual que el ancho de banda máximo
(ancho de banda mínimo ≤ bi ≤ ancho de banda máximo)
Ambas condiciones mencionadas anteriormente son aplicables para el LSP por miembro (nominal y suplementario) y, esencialmente, tienen el ancho de banda reservado para existir dentro de un rango.
División de disparadores
Cada vez que expira el temporizador de normalización, el enrutador de entrada decide si se requiere la división de LSP. El enrutador de entrada funciona con el ancho de banda agregado en lugar de los anchos de banda LSP individuales. Se definen las dos variables siguientes para el ancho de banda agregado:
Current-Aggr-Bw: suma de los anchos de banda reservados de todos los LSP miembros actuales.New-Aggr-Bw—Suma de las tasas de tráfico de todos los LSP miembros actuales según el muestreo.
Tomando, por ejemplo, si hay N LSP miembros en la red en el momento de la normalización, los dos enfoques para desencadenar la división de LSP son los siguientes:
Disparador absoluto: la división de LSP se realiza cuando
New-Aggr-Bwes mayor queAggregate-maximum-bandwidth.New-Aggr-Bw( >Aggregate-maximum-bandwidth)Disparador relativo: en Disparo relativo, se realiza un cálculo dinámico. El
Current-Aggr-Bwse compara conNew-Aggr-Bwel dispositivo de enrutamiento de entrada. La división de LSP se realiza cuando la diferencia en el ancho de banda es mayor o igual que una cantidad de umbral calculada. La siguiente ecuación describe el estado deseado:([1-a] x
Current-Aggr-Bw<New-Aggr-Bw< [1+a] xCurrent-Aggr-Bw, donde 0 </= a </= 1)Nota:En la condición anterior, "a" es el umbral de ajuste y su valor predeterminado es 10 por ciento (es decir, 0,10). Puede configurar el umbral de ajuste mediante la
splitting-merging-thresholdinstrucción en el nivel de[edit protocols mpls container-label-switched-path lsp-name]jerarquía. El valor también se muestra en la salida delshow mpls container-lsp extensivecomando.Cuando
New-Aggr-Bwes mayor queCurrent-Aggr-Bwmultiplicado por [1+a], superando así el umbral calculado, el dispositivo de enrutamiento de entrada no realiza la normalización. En cambio, debido a que esta es una situación desencadenante relativa, se realiza la división de LSP. Sin embargo, cuando tanto la división de LSP como la fusión de LSP están configuradas en el enrutador de entrada, la división de LSP se activa en el enrutador de entrada cuando se cumple una de las dos condiciones.
Fusión de LSP
Descripción general de las operaciones
Junos OS admite dos tipos de LSP: los LSP configurados por CLI y los LSP creados dinámicamente. Los LSP configurados por la CLI se crean manualmente y permanecen en el sistema hasta que se modifica la configuración. Los LSP dinámicos son creados dinámicamente por MVPN de próxima generación, BGP virtual private LAN service (VPLS) o LDP, según una configuración de plantilla, y se eliminan del sistema cuando ninguna aplicación los utiliza durante un período determinado. La fusión de LSP sigue un enfoque similar al de los LSP dinámicos.
La fusión de LSP permite que un dispositivo de enrutamiento de entrada elimine dinámicamente algunos LSP miembros del LSP del contenedor, de modo que se mantenga menos información de estado en la red. Si un enrutador de entrada aprovisiona varios LSP miembro entre los enrutadores de entrada y salida, y se produce una reducción general del ancho de banda agregado (lo que provoca que algunos LSP se infrautilicen), el enrutador de entrada distribuye la nueva carga de tráfico entre menos LSP.
Aunque hay varias formas de combinar los LSP miembro, Junos OS solo admite la combinación general cuando se realiza la normalización. Un enrutador de entrada considera la demanda agregada y el número mínimo (o máximo) de LSP y revisa el número de LSP que deben estar activos en un dispositivo de enrutamiento de entrada. Como resultado, lo siguiente puede ocurrir periódicamente a medida que se activa el temporizador de normalización:
Reseñalización de algunos de los LSP existentes con ancho de banda actualizado
Creación de nuevos LSP
Eliminación de algunos de los LSP existentes
Limitaciones operativas
Si un LSP de contenedor no está configurado con ancho de banda automático, los LSP miembro se señalizan con el valor de ancho de banda estático, si está configurado. La fusión de LSP no ocurre porque no hay una estimación dinámica del ancho de banda agregado. Sin embargo, se puede configurar un desencadenador manual para dividir y ajustar con un valor de ancho de banda específico.
Los LSP nominales nunca se eliminan como parte de la fusión de LSP.
Antes de eliminar un LSP, el LSP se vuelve inactivo, de modo que el tráfico se desplaza a otros LSP antes de eliminar el LSP. Esto se debe a que RSVP envía PathTear antes de eliminar rutas y saltos siguientes del motor de reenvío de paquetes.
Cuando los LSP miembro se vuelven a señalar con ancho de banda modificado, es posible que algunos LSP no se señalicen correctamente.
Disparadores de fusión
Cada vez que expira el temporizador de normalización, el enrutador de entrada decide si se requiere la fusión de LSP. El enrutador de entrada funciona con el ancho de banda agregado en lugar de los anchos de banda LSP individuales. Se definen las dos variables siguientes para el ancho de banda agregado:
Current-Aggr-Bw: suma de los anchos de banda reservados de todos los LSP miembros actuales.New-Aggr-Bw—Suma de las tasas de tráfico de todos los LSP miembros actuales según el muestreo.
Por ejemplo, si hay N LSP miembros en la red en el momento de la normalización, los dos enfoques para desencadenar la fusión de LSP son los siguientes:
Disparador absoluto: la fusión de LSP se realiza cuando
New-Aggr-Bwes menor queAggregate-minimum-bandwidth.New-Aggr-Bw( <Aggregate-minimum-bandwidth)Disparador relativo: se
Current-Aggr-Bwcompara conNew-Aggr-Bwel dispositivo de enrutamiento de entrada. La fusión de LSP se realiza cuando la diferencia en la cantidad de ancho de banda está desactivada por un umbral.([1-a] x
Current-Aggr-Bw<New-Aggr-Bw< [1+a] xCurrent-Aggr-Bw, donde 0 </= a </= 1)Nota:En la condición anterior, "a" es el umbral de ajuste y su valor predeterminado es 10 por ciento (es decir, 0,10). Puede configurar el umbral de ajuste mediante la
splitting-merging-thresholdinstrucción en el nivel de[edit protocols mpls container-label-switched-path lsp-name]jerarquía. El valor también se muestra en la salida delshow mpls container-lsp extensivecomando.Cuando el
New-Aggr-Bwvalor es menor o igual que [1+a] multiplicado por el valor, el dispositivo de enrutamiento de entrada no realiza la normalización, sino que realiza laCurrent-Aggr-Bwfusión de LSP. Sin embargo, cuando tanto la división de LSP como la fusión de LSP están configuradas en el enrutador de entrada, la división de LSP se activa en el enrutador de entrada cuando se cumple una de las dos condiciones.
Protección de nodos y vínculos
Junos OS admite los siguientes mecanismos para la protección de nodos y vínculos:
Redireccionamiento rápido
Protección de enlaces
Protección de vínculos de nodo
Solo se puede configurar uno de los modos de protección mencionados anteriormente en un dispositivo de enrutamiento de entrada en un momento dado. Todos los LSP miembro (nominal y suplementario) utilizan el mismo modo de protección que está configurado.
Convención de nomenclatura
Al configurar un LSP de contenedor, se asigna un nombre al LSP. El nombre de un LSP nominal y uno suplementario se forma agregando el sufijo de nombre configurado y un sufijo generado automáticamente al nombre del LSP del contenedor. El nombre del LSP del contenedor es único y se comprueba su exactitud durante el análisis de la configuración. El nombre LSP del contenedor debe identificar de forma exclusiva los parámetros, como los nombres de enrutador de entrada y salida.
Un LSP miembro LSP de contenedor y un LSP punto a punto en un dispositivo de enrutamiento de entrada no pueden tener el mismo nombre de LSP.
Los LSP de contenedor siguen una convención de nomenclatura LSP basada en números. Por ejemplo, si el nombre configurado del LSP nominal es bob y el número de LSP miembro es N, los LSP miembro se denominan bob-<configured-suffix>-1, bob-<configured-suffix>-2, ...) y bob-<configured-suffix>-N.
Después de un evento de normalización, el número de LSP miembro puede cambiar. Por ejemplo, si el número de LSP miembro aumenta de seis a ocho, el dispositivo de enrutamiento de entrada mantiene los primeros seis LSP denominados bob-<configured-suffix>-1, bob-<configured-suffix>-2, ... y bob-<configured-suffix>-6. Los dos LSP adicionales se denominan bob-7 y bob-8. Es posible que sea necesario volver a optimizar los LSP originales si cambia su ancho de banda señalado.
De manera similar, si el número de LSP miembro se reduce de ocho a seis, el dispositivo de enrutamiento de entrada vuelve a enviar una señal a los LSP miembros de tal manera que los LSP activos restantes en el sistema se denominan bob-<configured-suffix>-1, bob-<configured-suffix>-2, ... y bob-<configured-suffix>-6.
En el proceso de creación de nuevos LSP, se puede configurar un LSP RSVP denominado bob-<configured-suffix>-7 .
Normalización
Descripción general de las operaciones
La normalización es un evento que ocurre periódicamente. Cuando sucede, se toma una decisión sobre el número de LSP miembros que deben permanecer activos y sus respectivos anchos de banda en un LSP de contenedor. Más concretamente, se toma la decisión de si se van a crear nuevos LSP suplementarios, o si se requiere que los LSP existentes se vuelvan a señalar o eliminen durante el evento de normalización.
Entre dos eventos de normalización, un LSP miembro puede someterse a varios ajustes automáticos de ancho de banda. Se configura un temporizador de normalización, similar al temporizador de reoptimización. El intervalo del temporizador de normalización no debe ser inferior al intervalo de ajuste o al temporizador de optimización.
La normalización no se activa en función de eventos de la red, como cambios en la topología.
Limitaciones operativas
La normalización tiene las siguientes restricciones operativas:
La normalización ocurre solo cuando ninguno de los LSP miembros está experimentando una reoptimización o hacer antes de la interrupción. La normalización comienza cuando todos los LSP miembros completan su preparación antes de la pausa. Si la normalización está pendiente, no se debe intentar una nueva optimización hasta que se complete la normalización.
Después de la normalización, un dispositivo de enrutamiento de entrada calcula primero un conjunto de rutas factibles para el ancho de banda mediante cálculos de enrutamiento basados en restricciones. Si no se muestran suficientes rutas calculadas de enrutamiento basadas en restricciones con un valor de ancho de banda agregado que supere el ancho de banda deseado, se realizan varias acciones de conmutación por error.
Una vez que hay disponible un conjunto de rutas de ancho de banda factible, el dispositivo de enrutamiento de entrada señala esas rutas mientras mantiene el conjunto original de rutas con los valores de ancho de banda antiguos. La preparación antes de la interrupción se realiza con el estilo de uso compartido explícito (SE) y, cuando algunos de los LSP no se vuelven a señalar correctamente, se intenta un número limitado de reintentos durante un período especificado. Sólo cuando todos los LSP se señalizan correctamente, el enrutador de entrada cambia de la instancia antigua del LSP de contenedor a la instancia más reciente. Si no se pudieron señalar correctamente todos los LSP, el enrutador de entrada mantiene las instancias de miembros que están activas con valores de ancho de banda más altos.
Por ejemplo, si el ancho de banda de una instancia antigua de un LSP miembro (LSP-1) es 1G, el LSP se divide en LSP-1 con ancho de banda 2G y LSP-2 con ancho de banda 2G. Si falla la señalización de LSP-1 con ancho de banda 2G, el enrutador de entrada mantiene LSP-1 con ancho de banda 1G y LSP-2 con ancho de banda 2G.
Cuando se produce un error de señalización, el dispositivo de enrutamiento de entrada permanece en el estado de error, en el que algunos LSP han actualizado los valores de ancho de banda solo si el ancho de banda agregado ha aumentado. El enrutador de entrada intenta mostrar los LSP que no se pudieron señalar correctamente, lo que resulta en una pérdida de tráfico mínima.
Si un LSP cae entre dos eventos de normalización, puede aumentar la carga en otros LSP que están activos. Para evitar el uso excesivo de otros LSP, se puede configurar una normalización prematura en caso de fallo del LSP. Los LSP pueden disminuir debido a la preferencia o a la falta de protección de nodos o vínculos. Es posible que no sea necesario mostrar los LSP que están inactivos, ya que el proceso de normalización vuelve a ejecutar los cálculos de ruta de enrutamiento basados en restricciones.
Interoperación con ancho de banda automático
Tomando como ejemplo, hay un LSP nominal llamado LSP-1 configurado con los siguientes parámetros:
Ancho de banda dividido y ancho de banda de señalización máximo de 1G
Combinación de ancho de banda y ancho de banda de señalización mínima de 0,8G
Ancho de banda automático
La normalización se realiza de manera diferente en los siguientes escenarios:
Cambios en los ajustes de ancho de banda automático por LSP
Tabla 5 ilustra cómo la normalización divide y combina los LSP miembro a medida que los ajustes automáticos de ancho de banda cambian el ancho de banda por LSP con normalización incondicional.
Tiempo de normalización |
Estado actual |
Eventos |
Estado ajustado |
|---|---|---|---|
T0 |
No hay estado. |
Inicialización |
LSP-1 se señala con un ancho de banda de 0.8G |
T1 |
El uso de LSP-1 aumenta a 1.5G |
|
LSP-1 = 0,8G LSP-2 = 0,8G |
T2 |
Aumento del uso de LSP-1 a 2G El uso de LSP-2 aumenta a 0,9 G (dentro de los límites) |
|
LSP-1 = 1G LSP-2 = 1G LSP-3 = 1G |
T3 |
El uso de LSP-3 aumenta a 1.5G |
|
LSP-1 = 1G LSP-2 = 1G LSP-3 = 1G LSP-4 = 1G |
T4 |
El uso de LSP-2 cae a 0.5G |
|
LSP-1 = 1G LSP-2 = 1G LSP-3 = 1G |
Dado que el ancho de banda automático se configura por LSP, cada vez que se realiza un ajuste automático del ancho de banda, el enrutador de entrada vuelve a enviar señales a cada LSP con Max Avg Bw.
Otro enfoque para controlar los cambios en los ajustes de ancho de banda automático por LSP es no permitir que los LSP individuales ejecuten ancho de banda automático en el enrutador de entrada, sino ejecutar ancho de banda automático en modo pasivo (monitor). De esta manera, el muestreo se realiza en cada intervalo estadístico solo para los LSP miembro, y la normalización se realiza solo para el LSP del contenedor en lugar de actuar sobre la expiración del temporizador de ajuste de LSP individuales.
Como resultado, se reduce el número de intentos de reseñalización y las fluctuaciones del ancho de banda para un LSP miembro determinado. El enrutador de entrada solo utiliza los valores de ancho de banda calculados por LSP de miembro para encontrar un ancho de banda agregado que se utilizará durante la normalización. La configuración del ajuste automático del ancho de banda seguido de la normalización (los ajustes y los intervalos de normalización son comparables) puede provocar una sobrecarga considerable debido a la reseñalización.
Tomando el mismo ejemplo, y aplicando el segundo enfoque, LSP-1 pasa de 0.8G a 1.5G y luego vuelve a 0.8G. Si el temporizador de normalización es del mismo orden que el intervalo de ajuste, el enrutador de entrada deja el LSP-1 solo con su 0,8G original y sólo señala al LSP-2 con 0,8G. Esto ayuda a lograr el resultado final de la normalización, evitando así el intento de señalización adicional en LSP-1 con 1.5G al vencimiento del temporizador de ajuste.
Dado que los LSP miembro siempre usan el mismo ancho de banda, cualquier ajuste realizado en los LSP miembro se deshace. Los LSP miembro se vuelven a señalar con un ancho de banda reducido en comparación con la capacidad reservada en el disparador de ajuste con el disparador de normalización. Por lo tanto, evitar el desencadenante de ajuste para los LSP miembro podría ser útil suponiendo que los intervalos de normalización y ajuste son del mismo orden.
Se recomienda que el temporizador de normalización sea superior al intervalo de ajuste del ancho de banda automático y a la duración regular de la optimización, ya que las tendencias del tráfico se observan en una escala de tiempo más larga y la normalización se realiza de una a tres veces al día. Un LSP puede someterse a optimización por las siguientes razones:
Optimización normal
Ajuste automático del ancho de banda
Normalización
Cambios en el crecimiento del tráfico
Tabla 6 Muestra cómo se realiza la normalización cuando el tráfico crece en factor grande.
Tiempo de normalización |
Estado actual |
Eventos |
Estado ajustado |
|---|---|---|---|
T0 |
Sin estado |
LSP-1 se señala con un ancho de banda de 0.8G |
|
T1 |
Aumento del uso de LSP-1 a 3G |
|
LSP-1 = 1G LSP-2 = 1G LSP-3 = 1G |
Tener menos LSP es preferible a señalar cuatro LSP, cada uno con un ancho de banda de 0.8G, a menos que exista una restricción en el número mínimo de LSP.
Rango calculado y rangos factibles configurados
Cuando se configura un enrutador de entrada con el número mínimo y máximo de LSP, y por valores de ancho de banda dividido y ancho de banda de fusión de LSP, los umbrales de ancho de banda se utilizan para dividir y fusionar. Para ello, el número de LSP (N) debe satisfacer las siguientes restricciones:
minimum-member-lsps ≤ N ≤ maximum-member-lsps
En el momento de la normalización, en función de la demanda agregada X:
[X/splitting-bandwidth] ≤ N ≤ [X/merging-bandwidth]
Las restricciones mencionadas anteriormente proporcionan dos rangos para que N trabaje. Si los dos rangos para N se superponen, N se seleccionará del intervalo de superposición (el menor posible N) para mantener el número de LSP pequeño en la red.
De lo contrario, si maximum-member-lsps es menor que [X/splitting-bandwidth], el enrutador de entrada mantiene (como máximo) el máximo-member-lsps en el sistema y el ancho de banda de cada LSP es [X/maximum-member-lsps] o el ancho de banda de señalización máximo, el que sea menor. Es posible que algunos LSP no se señalicen correctamente.
De manera similar, si minimum-member-lsps es mayor que [X/merging-bandwidth], el enrutador de entrada mantiene (como mínimo) los lsps de miembros mínimos en el sistema, y el ancho de banda de cada LSP es [X/minimum-member-lsps] o el ancho de banda de señalización mínimo, el que sea menor.
Tomando como ejemplo, la normalización se realiza de la siguiente manera en estos casos:
Caso 1
mínimo-miembro-lsps = 2
máximo-miembro-lsps = 10
demanda agregada = 10G
ancho de banda de fusión = 1G
ancho de banda dividido = 2,5 G
En este caso, el dispositivo de enrutamiento de entrada señala LSP de cuatro miembros, cada uno con un ancho de banda de 2G.
Caso 2
mínimo-miembro-lsps = 5
máximo-miembro-lsps = 10
demanda agregada = 10G
ancho de banda de fusión = 2,5 G
ancho de banda dividido = 10G
En este caso, el dispositivo de enrutamiento de entrada señala LSP de cinco miembros, cada uno con un ancho de banda de 2G. Aquí, la configuración estática en el número de LSP miembros tiene prioridad.
Caso 3
ancho de banda de señalización mínimo = 5G
ancho de banda de señalización máximo = 40 G
ancho de banda de fusión = 10G
ancho de banda dividido = 50G
Cuando aparece un LSP de contenedor, el LSP nominal se señala con un ancho de banda de señalización mínimo. En el momento de la normalización, el ancho de banda agregado nuevo es 100G. Para encontrar N y el ancho de banda de cada LSP, N debe satisfacer la siguiente restricción:
100/50 ≤ N ≤ 100/10, which gives 2 ≤ N ≤ 10
Por lo tanto, N es igual a:
N = 2, ancho de banda = min {100/2G, 40G} = 40G
Esta opción no satisface el nuevo agregado de 100G.
N = 3, ancho de banda = mínimo {100/3G, 40G} = 33,3G
Esta opción hace que el ancho de banda agregado sea igual a 100G.
En este caso, el dispositivo de enrutamiento de entrada señala tres LSP, cada uno con un ancho de banda de 33,3G.
Nota:El enrutador de entrada no indica un LSP menor que el ancho de banda de señalización mínimo.
Cálculo de rutas de enrutamiento basadas en restricciones
Aunque no hay cambios en el cálculo general de la ruta de enrutamiento basada en restricciones, con un LSP de contenedor hay un módulo independiente que supervisa el proceso de normalización, programa eventos de enrutamiento basados en restricciones y programa el cambio de una instancia antigua a una nueva, cuando corresponda. Un dispositivo de enrutamiento de entrada tiene que manejar periódicamente el cálculo de la ruta de enrutamiento basada en restricciones. Cuando se produce la normalización, un enrutador de entrada tiene que calcular rutas de enrutamiento basadas en restricciones, si es necesario cambiar el número de LSP o el ancho de banda de los LSP.
Por ejemplo, hay K LSP en el enrutador de entrada con valores de ancho de banda X-1, X-2, ... y X-K. El valor agregado actual del ancho de banda es Y, que es la suma de X-1 más X-2 más X-K. Si hay una nueva demanda de W, el enrutador de entrada primero calcula cuántos LSP se requieren. Si el enrutador de entrada sólo necesita N LSP (LSP-1, LSP-2, .., y LSP-N), cada uno con un valor de ancho de banda B, la tarea del módulo de enrutamiento basado en restricciones es proporcionar un conjunto de LSP viables para el ancho de banda que puedan acomodar la nueva demanda agregada que no sea inferior a Y.
A continuación, el enrutador de entrada intenta ver si las rutas de enrutamiento basadas en restricciones se pueden calcular correctamente para todos los N LSP. Si las rutas para todos los LSP se encuentran correctamente, el módulo de enrutamiento basado en restricciones devuelve el conjunto al módulo de normalización.
Es posible que el cálculo del enrutamiento basado en restricciones no sea correcto para algunos LSP. En este caso, el dispositivo de enrutamiento de entrada realiza la siguiente acción:
Si la configuración permite la normalización incremental, lo que implica que si el enrutador de entrada tiene suficientes LSP cuyo agregado supera Y, el módulo de enrutamiento basado en restricciones devuelve ese conjunto de rutas.
Ya sea que la normalización incremental esté configurada o no, si no se pueden calcular rutas de enrutamiento basadas en restricciones para un número suficiente de LSP, el enrutador de entrada tiene que repetir el proceso de búsqueda de un nuevo conjunto de LSP. Inicialmente, el enrutador de entrada comienza con el valor más bajo de N de la región factible. Cada vez que el enrutador de entrada tiene que revisar el número, lo aumenta linealmente en 1. Como resultado, el ancho de banda por LSP disminuye y, por lo tanto, hay una mayor probabilidad de que la señalización sea exitosa. El proceso se repite para todos los valores factibles de N (o algún número acotado de veces o duración según lo configurado).
El enrutador de entrada señala los LSP después de cálculos exitosos del cálculo de la ruta de enrutamiento basada en restricciones. Puede suceder que cuando se señalan los LSP, la señalización de muchos LSP falle. Además de que los cálculos de rutas de enrutamiento basadas en restricciones se realicen correctamente, la señalización RSVP también debe realizarse correctamente, de modo que el nuevo agregado no sea menor que el ancho de banda agregado anterior.
Muestreo
El muestreo es importante para que la normalización funcione. Con el muestreo configurado, un dispositivo de enrutamiento de entrada puede hacer una estimación estadística de las demandas de tráfico agregadas. Cada vez que se activa el temporizador de muestreo, el dispositivo de enrutamiento de entrada puede considerar las tasas de tráfico en diferentes LSP y calcular una muestra de ancho de banda agregada. Este temporizador de muestreo es diferente del muestreo estadístico realizado periódicamente por RSVP en todos los LSP. El ancho de banda agregado es una muestra que se utilizará en el momento de la normalización. Un dispositivo de enrutamiento de entrada puede guardar muestras pasadas para calcular un promedio (o alguna otra medida estadística) y usarlo la próxima vez que ocurra la normalización.
Para quitar muestras atípicas, se configura un token de muestreo. En otras palabras, de todas las muestras agregadas recolectadas durante el tiempo configurado, los valores atípicos inferior y superior se ignoran antes de calcular una medida estadística a partir de las muestras restantes.
Se admiten los dos métodos siguientes para calcular un valor de ancho de banda agregado:
Promedio: el dispositivo de enrutamiento de entrada considera todas las muestras agregadas de ancho de banda y, a continuación, se eliminan todas las muestras de valores atípicos. El valor promedio de ancho de banda se calcula a partir de las muestras restantes que se utilizarán durante la normalización.
Máx: el dispositivo de enrutamiento de entrada considera todas las muestras agregadas de ancho de banda y, a continuación, se eliminan todas las muestras atípicas. El valor máximo de ancho de banda se selecciona de las muestras restantes para utilizarlas durante la normalización.
La duración del tiempo, el número de muestras agregadas anteriores que se van a almacenar, el valor de percentil que se debe determinar y los valores atípicos ignorados son parámetros configurables por el usuario.
Compatibilidad con NSR, IPG-FA y rutas estáticas
A partir de Junos OS versión 15.1, las rutas conmutadas por etiqueta de contenedor (LSP) proporcionan compatibilidad con el enrutamiento activo sin paradas (NSR), la adyacencia de reenvío de IGP (FA) y las rutas estáticas para abordar los requisitos de casos empresariales más amplios.
Soporte NSR
Un LSP de contenedor tiene las características de la ingeniería de tráfico ECMP y RSVP. Dado que un LSP de contenedor consta de varios LSP miembro entre un enrutador de entrada y uno de salida, en el que cada LSP miembro toma una ruta diferente hacia el mismo destino, el enrutador de entrada se configura con todos los parámetros necesarios para calcular un LSP ECMP RSVP. Estos parámetros, junto con la información del estado de reenvío, deben sincronizarse entre los motores de enrutamiento principal y de reserva para habilitar la compatibilidad con el enrutamiento activo sin paradas (NSR) para los LSP de contenedor. Aunque parte de la información del estado de reenvío del motor de enrutamiento de reserva se crea localmente en función de la configuración, la mayor parte se crea en función de las actualizaciones periódicas del motor de enrutamiento principal. Los LSP del contenedor se crean dinámicamente utilizando los estados replicados en el motor de enrutamiento de reserva.
De forma predeterminada, la normalización se produce una vez cada 6 horas y, durante este tiempo, se realizan varios ajustes automáticos del ancho de banda en cada LSP miembro. Se cambia el tamaño de un LSP miembro según el tráfico que transporta y los parámetros de configuración de ancho de banda automático configurados. La demanda agregada de un LSP de contenedor se rastrea sumando el ancho de banda en todos los LSP miembros.
Para los LSP punto a punto de RSVP, un cambio de motor de enrutamiento puede ser bajo cualquiera de los siguientes:
Steady state
En el estado estacionario, el estado LSP es tráfico ascendente y reenviable; sin embargo, no se produce ningún otro evento, como el make-before-break (MBB), en el LSP. En esta etapa, la RPD se ejecuta en ambos motores de enrutamiento, y el evento de conmutación alterna entre el motor de enrutamiento principal y el motor de respaldo. El motor de enrutamiento de copia de seguridad ya tiene la información de LSP replicada. Después del cambio, el nuevo primario usa la información de la estructura replicada para construir el LSP del contenedor y pone en cola la ruta (ERO) del LSP en el modo de retroceso. RSVP señala y comprueba si la ruta mencionada en el ERO es accesible. Si se produce un error en las comprobaciones de RSVP, se reinicia el LSP. Si las comprobaciones RSVP se realizan correctamente, el estado LSP permanece activo.
Action leading to make-before-break (MBB)
Un LSP de contenedor se puede optimizar con un ancho de banda actualizado, y este cambio se realiza en forma de MBB. Durante un proceso MBB, hay dos instancias de ruta para un LSP dado, y el LSP cambia de una instancia a otra. Para cada cambio de motor de enrutamiento, la ruta se comprueba para averiguar en qué parte del proceso MBB se encuentra la ruta. Si la ruta está en medio del proceso de MBB, con la instancia principal inactiva y la ruta reoptimizada hacia arriba, MBB puede cambiar a la nueva instancia. El
show mpls lsp extensiveresultado del comando, en este caso, es el siguiente:13 Dec 3 01:33:38.941 Make-before-break: Switched to new instance 12 Dec 3 01:33:37.943 Record Route: 10.1.1.1 11 Dec 3 01:33:37.942 Up 10 Dec 3 01:33:37.942 Automatic Autobw adjustment succeeded: BW changes from 100 bps to 281669 bps 9 Dec 3 01:33:37.932 Originate make-before-break call 8 Dec 3 01:33:37.931 CSPF: computation result accepted 10.1.1.1 7 Dec 3 01:28:44.228 CSPF: ERO retrace was successful 10.1.1.1 6 Dec 3 01:19:39.931 10.1.1.2 Down: mbb/reopt 5 Dec 3 01:18:29.286 Up: mbb/reopt 4 Dec 3 01:14:47.119 10.1.1.2 Down: mbb/reopt 3 Dec 3 01:13:29.285 Up: mbb/reopt 2 Dec 3 01:10:59.755 Selected as active path: selected by master RESe mantiene un comportamiento similar para los LSP miembro durante la optimización del ancho de banda.
Un cambio de motor de enrutamiento en estado estable (cuando la normalización no está en curso) mantiene los LSP del contenedor en funcionamiento sin ninguna pérdida de tráfico. Los eventos, como un MBB debido a ajustes automáticos del ancho de banda, estado del vínculo inactivo o doble error, en el estado estable son similares a un LSP punto a punto RSVP normal.
Si el LSP del contenedor está en proceso de normalización y el evento de normalización se activa manual o periódicamente, pasa por la fase de cálculo y ejecución. En cualquiera de los casos, no se garantiza una pérdida de tráfico del cero por ciento.
Normalización en la fase de cálculo
Durante la fase de cálculo, el motor de enrutamiento principal calcula el recuento de LSP del miembro de destino y el ancho de banda con el que se debe volver a señalar a cada LSP miembro. El motor de enrutamiento de reserva tiene información limitada sobre el LSP del contenedor, como el nombre del LSP, el ID de LSP, el ancho de banda actual de su LSP miembro, el recuento de LSP de miembro y el recuento de reintentos de normalización. Si el cambio se produce durante la fase de cálculo, el motor de enrutamiento de reserva no es consciente del recuento de LSP del miembro de destino ni del ancho de banda que se va a señalar. Dado que las estadísticas de tráfico no se copian en el motor de enrutamiento de reserva, no se puede calcular el número de miembros de destino ni el ancho de banda. En este caso, el nuevo motor de enrutamiento principal utiliza los datos antiguos almacenados en el recuento de LSP del miembro de destino y el ancho de banda de destino para señalar los LSP.
Normalización en la fase de ejecución
Durante la fase de ejecución, RSVP del motor de enrutamiento principal intenta señalar los LSP con el ancho de banda recién calculado. Si el cambio se produce durante la señalización de LSP con mayor ancho de banda o durante la división o fusión de LSP, el nuevo motor de enrutamiento principal utiliza la información del recuento de miembros de destino y el valor de ancho de banda con el que se va a señalar, para mostrar los LSP.
Soporte IPG-FA
Una adyacencia de reenvío (FA) es una ruta de ingeniería de tráfico conmutada por etiquetas (LSP) que se configura entre dos nodos y que un protocolo de puerta de enlace interior (IGP) utiliza para reenviar el tráfico. De forma predeterminada, un IGP no considera túneles de ingeniería de tráfico MPLS entre sitios, para el reenvío de tráfico. La adyacencia de reenvío trata un túnel LSP de ingeniería de tráfico como un vínculo en una topología IGP, lo que permite que los nodos de la red también reenvíen el tráfico IP para llegar al destino a través de este LSP FA. Se puede crear una adyacencia de reenvío entre dispositivos de enrutamiento, independientemente de su ubicación en la red.
Para anunciar un LSP de contenedor como IGP-FA, el nombre de LSP debe configurarse en IS-IS u OSPF. Por ejemplo:
SI-SI
[edit]
protocols {
isis {
label-switched-path container-lsp-name;
}
}
OSPF
[edit]
protocols {
ospf {
area 0.0.0.0 {
label-switched-path container-lsp-name;
}
}
}
El IGP-FA se aplica tanto a los LSP de contenedor como a los LSP punto a punto regulares. Si un LSP de contenedor y un LSP punto a punto comparten el mismo nombre, el LSP punto a punto tiene preferencia para FA.
Soporte de ruta estática
Las rutas estáticas a menudo incluyen solo una o muy pocas rutas a un destino y generalmente no cambian. Estas rutas se utilizan para unir servicios cuando no se configuran directivas y otros protocolos.
Para anunciar un LSP de contenedor como una ruta estática, el nombre del LSP debe configurarse en la configuración de ruta estática. Por ejemplo:
Ruta estática
[edit]
routing-options {
static {
route destination {
lsp-next-hop container-lsp-name;
}
}
}
La compatibilidad con rutas estáticas se aplica tanto a los LSP de contenedor como a los LSP punto a punto regulares. Si un LSP de contenedor y un LSP punto a punto comparten el mismo nombre, el LSP punto a punto tiene preferencia para el enrutamiento estático.
Instrucciones de configuración admitidas para los LSP de contenedor
Tabla 7 enumera las instrucciones de configuración de LSP de MPLS que se aplican al LSP RSVP y a un LSP de contenedor (nominal y suplementario).
La compatibilidad con la configuración se define mediante los siguientes términos:
Sí: la instrucción de configuración es compatible con este tipo de LSP.
No: la instrucción de configuración no es compatible con este tipo de LSP.
N/A: la instrucción de configuración no es aplicable para este tipo de LSP.
Declaración de configuración |
RSVP LSP (entrada) |
LSP de miembro (ingreso) |
|---|---|---|
adaptable (Valor predeterminado: no adaptativo) |
Sí |
Sí |
admin-down |
Sí |
Sí |
grupo administrativo |
Sí |
Sí |
admin-groups-except |
Sí |
Sí |
grupos de aplicación |
Sí |
Sí |
aplicar-grupos-excepto |
Sí |
Sí |
associate-backup-pe-groups |
Sí |
No |
asociado-lsp (Sin soporte bidireccional) |
Sí |
No |
ancho de banda automático |
Sí |
Sí |
copia de seguridad |
Sí |
No |
ancho de banda |
Sí |
Sí |
Clase de servicio |
Sí |
Sí |
corouted-bidireccional (Sin soporte bidireccional) |
Sí |
No |
corouted-bidireccional-pasivo (Sin soporte bidireccional) |
Sí |
No |
descripción |
Sí |
Sí |
inutilizar |
Sí |
Sí |
protección de salida |
Sí |
No |
exclude-srlg |
Sí |
Sí |
reenrutamiento rápido (El mismo reenrutamiento rápido para todos los LSP miembros) |
Sí |
Sí |
De |
Sí |
Sí |
límite de salto |
Sí |
Sí |
instalar |
Sí |
Sí |
entre dominios (El mismo enrutador de terminación) |
Sí |
Sí |
secundario (Todos los LSP son primarios) |
Sí |
No |
Tunelización de LDP (Todos los LSP hacen tunelización) |
Sí |
Sí |
menos llenado |
Sí |
Sí |
protección de enlaces (Todos los LSP comparten el mismo mecanismo de protección de enlace) |
Sí |
Sí |
atributos lsp |
Sí |
Sí |
LSP-External-Controller |
Sí |
No |
métrico (Todos los LSP son iguales) |
Sí |
Sí |
más llenado |
Sí |
Sí |
no-CSPF (Los LSP usan IGP) |
Sí |
Sí |
no-decrement-ttl (Todos los LSP comparten el mismo comportamiento de TTL) |
Sí |
Sí |
no-install-to-address |
Sí |
Sí |
sin registro |
Sí |
Sí |
protección de vínculos de nodo (Al LSP comparten el mismo mecanismo de protección de vínculo de nodo) |
Sí |
Sí |
Oam |
Sí |
Sí |
optimize-hold-dead-delay (Todos los LSP tienen el mismo valor) |
Sí |
Sí |
optimizar-cambio-retraso (Todos los LSP tienen el mismo valor) |
Sí |
Sí |
temporizador de optimización (Todos los LSP tienen el mismo valor) |
Sí |
Sí |
p2mp |
Sí |
NA |
Policía (Tráfico variable) |
Sí |
No |
preferencia |
Sí |
Sí |
principal (Todas las rutas son primarias) |
Sí |
No |
aleatorio |
Sí |
Sí |
grabar |
Sí |
Sí |
Límite de reintentos (Aplicable a los miembros) |
Sí |
Sí |
temporizador de reintento (Aplicable a los miembros) |
Sí |
Sí |
temporizador de reversión (Sin LSP secundario) |
Sí |
No |
secundario (Todos los LSP son primarios) |
Sí |
No |
preferencia suave |
Sí |
Sí |
espera (Todos los LSP están en espera) |
Sí |
No |
plantilla |
Sí |
No |
Para |
Sí |
Sí |
traceoptions |
Sí |
Sí |
Ultimate-hop-popping |
Sí |
Sí |
Impacto de la configuración de LSP de contenedor en el rendimiento de la red
Un LSP contenedor es un LSP contenedor que permite que varios LSP miembro coexistan y se administren como un paquete. Los LSP miembro son similares a los LSP de RSVP punto a punto independientes. Como resultado, el consumo de recursos es similar a la suma de los recursos consumidos por cada LSP de RSVP punto a punto. Sin embargo, el aprovisionamiento de un LSP de contenedor es más eficiente, ya que los LSP miembro infrautilizados se eliminan dinámicamente, ahorrando así memoria y recursos de CPU.
Las características del LSP del contenedor dependen de la presencia de una implementación de RSVP MPLS de base funcional. Como resultado, un LSP de contenedor no introduce ninguna consideración de seguridad más allá de las consideraciones existentes para la funcionalidad básica de RSVP de MPLS. Las categorías de posibles ataques y contramedidas son las siguientes:
Interacción con procesos y configuración del router
No se requieren nuevos mecanismos de comunicación con hosts externos para un LSP de contenedor. Los datos llegan al módulo RSVP a través de procesos de software locales y configuración del enrutador, aparte de la adyacencia del vecino RSVP. Junos OS proporciona controles de seguridad en el acceso al enrutador y la configuración del enrutador.
Comunicación con vecinos RSVP externos
Los LSP MPLS señalados RSVP dependen de los servicios de RSVP e IGP para comunicar mensajes RSVP entre enrutadores vecinos a través de la red. Debido a que las sesiones RSVP implican comunicación fuera del enrutador local, están sujetas a muchas formas de ataque, como suplantación de pares, inyección de mensajes RSVP falsificados y actualizaciones de ruta, y ataques al transporte TCP/UDP subyacente para sesiones. Junos OS proporciona contramedidas para estos vectores de ataque.
Límites de recursos y denegación de servicio
Junos OS proporciona varios mecanismos a través de políticas y filtros para proteger contra ataques de denegación de servicio basados en la inyección de demandas de tráfico superiores a las esperadas. En el nivel de LSP MPLS, Junos OS permite a los operadores configurar límites en el ancho de banda de LSP y el número de LSP. Sin embargo, al igual que los LSP RSVP punto a punto, los LSP de contenedor no imponen límites al volumen de tráfico reenviado a través de estos LSP.
Características admitidas y no compatibles
Junos OS admite las siguientes funciones de LSP de contenedor:
Mecanismo de división de LSP basado en ancho de banda igual
LSP basado en ancho de banda agregado que se divide y fusiona de forma innovadora
Mecanismo de nomenclatura basado en números LSP para LSP miembros creados dinámicamente
Mecanismos de muestreo periódico para estimar la anchura de banda agregada
Interoperabilidad con la función de ancho de banda automático
ECMP mediante los LSP creados dinámicamente
Tunelización de LDP en el LSP creado dinámicamente
Configuración de LSP de contenedor mediante accesos directos de IGP
Vínculos Ethernet agregados
Sistemas lógicos
Junos OS admite not la siguiente funcionalidad LSP de contenedor:
Rutas disjuntas de nodo y vínculo para diferentes LSP entre un dispositivo de enrutamiento de entrada y salida
Directiva de asignación de ancho de banda diferente de la directiva de igual ancho de banda en el evento de normalización
Cálculo de rutas de enrutamiento basadas en restricciones para encontrar rutas de costo de IGP iguales para diferentes LSP
Objetos RSVP, como
MLSP_TUNNEL Sender Template, yMLSP_TUNNEL Filter Specificationdefinidos en [KOMPELLA-MLSP]Cambio en la topología como desencadenante de la división y fusión de LSP
Cambio en la topología y error de vínculo como desencadenante de la normalización, a menos que los LSP miembro dejen de funcionar
Protección de salida en LSP de contenedor
LSP de contenedor como LSP de respaldo para interfaz IGP
LSP de contenedor como túnel de proveedor para VPN de multidifusión
LSP dinámicos para la normalización
CCC usando LSP de contenedor
Rutas secundarias para LSP de contenedor
Contenedor bidireccional LSP
Policía
Rutas estáticas que utilizan LSP de contenedor como próximos saltos en función del mejor esfuerzo
Entidad informática de ruta externa, como PCE
Multichasis
IPv6
Ejemplo: Configuración de la administración dinámica de ancho de banda mediante LSP de contenedor
En este ejemplo se muestra cómo habilitar la administración dinámica del ancho de banda mediante la configuración de rutas de conmutación de etiquetas de contenedor (LSP) que permiten el equilibrio de carga entre varios LSP miembro punto a punto.
Requisitos
En este ejemplo, se utilizan los siguientes componentes de hardware y software:
-
Cinco enrutadores que pueden ser una combinación de enrutadores serie M, serie MX o serie T, de los cuales dos enrutadores son enrutadores perimetrales de proveedor (PE) y tres enrutadores son enrutadores de proveedor (P)
-
Junos OS versión 14.2 o posterior ejecutándose en todos los enrutadores
Antes de empezar:
-
Configure las interfaces del dispositivo.
-
Configure los números de sistema autónomo y los ID de enrutador para los dispositivos.
-
Configure los protocolos siguientes:
-
Confirmación de asistencia (RSVP)
-
MPLS
-
protocolo de puerta de enlace de frontera (BGP)
-
OSPF
-
Descripción general
A partir de Junos OS versión 14.2, se introduce un nuevo tipo de LSP, denominado LSP de contenedor, para habilitar el equilibrio de carga entre varios LSP punto a punto. Un LSP de contenedor incluye uno o más LSP miembro entre los mismos dispositivos de enrutamiento de entrada y salida. Los LSP miembro son similares a los LSP punto a punto independientes, y cada LSP miembro toma una ruta diferente hacia el mismo destino y se puede enrutar a lo largo de una ruta de costo de IGP diferente.
Un LSP de contenedor proporciona compatibilidad con la administración dinámica del ancho de banda al permitir que el enrutador de entrada agregue y elimine dinámicamente LSP miembro mediante un proceso denominado división de LSP y fusión de LSP, respectivamente, en función de la configuración y el tráfico agregado. Además de la adición y eliminación, los LSP miembro también se pueden volver a optimizar con diferentes valores de ancho de banda de una manera que se hace antes de la interrupción.
Topología
Figura 2 es una topología de ejemplo configurada con LSP de contenedor.
En este ejemplo, los enrutadores PE1 y PE2 son los enrutadores PE conectados a los hosts Host1 y Host2, respectivamente. Los enrutadores principales, los enrutadores P1, P2 y P3 se conectan a los enrutadores PE.
Configuración
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los comandos en la CLI en el nivel de jerarquía [edit] y, luego, ingrese commit desde el modo de configuración.
PE1
set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.1/24 set interfaces ge-0/0/1 unit 0 family inet address 10.10.10.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 10.40.40.1/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.102.166/32 set interfaces lo0 unit 0 family mpls set routing-options router-id 10.255.102.166 set routing-options autonomous-system 65034 set routing-options forwarding-table export pplb set protocols rsvp preemption aggressive set protocols rsvp interface all aggregate set protocols rsvp interface fxp0.0 disable set protocols rsvp interface ge-0/0/1.0 set protocols rsvp interface ge-0/0/2.0 set protocols mpls statistics file auto-bw set protocols mpls statistics file size 10m set protocols mpls statistics interval 10 set protocols mpls statistics auto-bandwidth set protocols mpls label-switched-path PE1-to-PE2-template1 template set protocols mpls label-switched-path PE1-to-PE2-template1 optimize-timer 30 set protocols mpls label-switched-path PE1-to-PE2-template1 link-protection set protocols mpls label-switched-path PE1-to-PE2-template1 adaptive set protocols mpls label-switched-path PE1-to-PE2-template1 auto-bandwidth adjust-interval 300 set protocols mpls label-switched-path PE1-to-PE2-template1 auto-bandwidth adjust-threshold 5 set protocols mpls label-switched-path PE1-to-PE2-template1 auto-bandwidth minimum-bandwidth 10m set protocols mpls label-switched-path PE1-to-PE2-template1 auto-bandwidth maximum-bandwidth 10m set protocols mpls container-label-switched-path PE1-PE2-container-100 label-switched-path-template PE1-to-PE2-template1 set protocols mpls container-label-switched-path PE1-PE2-container-100 to 10.255.102.128 set protocols mpls container-label-switched-path PE1-PE2-container-100 splitting-merging maximum-member-lsps 20 set protocols mpls container-label-switched-path PE1-PE2-container-100 splitting-merging minimum-member-lsps 2 set protocols mpls container-label-switched-path PE1-PE2-container-100 splitting-merging splitting-bandwidth 40m set protocols mpls container-label-switched-path PE1-PE2-container-100 splitting-merging merging-bandwidth 6m set protocols mpls container-label-switched-path PE1-PE2-container-100 splitting-merging maximum-signaling-bandwidth 10m set protocols mpls container-label-switched-path PE1-PE2-container-100 splitting-merging minimum-signaling-bandwidth 10m set protocols mpls container-label-switched-path PE1-PE2-container-100 splitting-merging normalization normalize-interval 400 set protocols mpls container-label-switched-path PE1-PE2-container-100 splitting-merging normalization failover-normalization set protocols mpls container-label-switched-path PE1-PE2-container-100 splitting-merging normalization normalization-retry-duration 20 set protocols mpls container-label-switched-path PE1-PE2-container-100 splitting-merging normalization normalization-retry-limits 3 set protocols mpls container-label-switched-path PE1-PE2-container-100 splitting-merging sampling cut-off-threshold 1 set protocols mpls container-label-switched-path PE1-PE2-container-100 splitting-merging sampling use-percentile 90 set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group to-PE2 type internal set protocols bgp group to-PE2 local-address 10.255.102.166 set protocols bgp group to-PE2 family inet-vpn unicast set protocols bgp group to-PE2 export direct set protocols bgp group to-PE2 neighbor 10.255.102.128 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 metric 100 set policy-options policy-statement direct term 1 from protocol direct set policy-options policy-statement direct term 1 then accept set policy-options policy-statement pplb then load-balance per-packet set routing-instances vpn1 instance-type vrf set routing-instances vpn1 interface ge-0/0/0.0 set routing-instances vpn1 route-distinguisher 10.255.102.166:1 set routing-instances vpn1 vrf-target target:1:1 set routing-instances vpn1 vrf-table-label
P1
set interfaces ge-0/0/0 unit 0 family inet address 10.50.50.1/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.10.10.2/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 10.20.20.1/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.102.152/32 set protocols rsvp interface all aggregate set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 metric 100
P2
set interfaces ge-0/0/0 unit 0 family inet address 10.30.30.1/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.60.60.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 10.20.20.2/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.102.29/32 set protocols rsvp interface all aggregate set protocols rsvp interface fxp0.0 disable set protocols mpls statistics file auto_bw set protocols mpls statistics file size 10m set protocols mpls statistics interval 5 set protocols mpls statistics auto-bandwidth set protocols mpls icmp-tunneling set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 metric 100
P3
set interfaces ge-0/0/0 unit 0 family inet address 10.50.50.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.60.60.2/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 10.40.40.2/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 family inet address 10.70.70.2/24 set interfaces ge-0/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.102.182/32 set protocols rsvp interface all aggregate set protocols rsvp interface fxp0.0 disable set protocols mpls icmp-tunneling set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable
PE2
set interfaces ge-0/0/0 unit 0 family inet address 10.30.30.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.2.2.1/24 set interfaces ge-0/0/3 unit 0 family inet address 10.70.70.1/24 set interfaces ge-0/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.102.128/32 set interfaces lo0 unit 0 family mpls set routing-options router-id 10.255.102.128 set routing-options autonomous-system 65034 set protocols rsvp interface all aggregate set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group to-PE1 type internal set protocols bgp group to-PE1 local-address 10.255.102.128 set protocols bgp group to-PE1 family inet-vpn unicast set protocols bgp group to-PE1 neighbor 10.255.102.166 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set policy-options policy-statement direct from protocol direct set policy-options policy-statement direct then accept set routing-instances vpn1 instance-type vrf set routing-instances vpn1 interface ge-0/0/1.0 set routing-instances vpn1 route-distinguisher 10.255.102.128:1 set routing-instances vpn1 vrf-target target:1:1 set routing-instances vpn1 vrf-table-label
Procedimiento
Procedimiento paso a paso
El ejemplo siguiente requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI.
Para configurar el enrutador PE1:
-
Configure las interfaces PE1 del enrutador.
[edit interfaces] user@PE1# set ge-0/0/0 unit 0 family inet address 10.1.1.1/24 user@PE1# set ge-0/0/1 unit 0 family inet address 10.10.10.1/24 user@PE1# set ge-0/0/1 unit 0 family mpls user@PE1# set ge-0/0/2 unit 0 family inet address 10.40.40.1/24 user@PE1# set ge-0/0/2 unit 0 family mpls user@PE1# set lo0 unit 0 family inet address 10.255.102.166/32 user@PE1# set lo0 unit 0 family mpls
-
Configure el ID del enrutador y el número de sistema autónomo para el enrutador PE1.
[edit routing-options] user@PE1# set router-id 10.255.102.166 user@PE1# set autonomous-system 65034
-
Habilite la directiva para equilibrar la carga del tráfico.
[edit routing-options] user@PE1# set forwarding-table export pplb
-
Active RSVP en todas las interfaces PE1 del enrutador (excluyendo la interfaz de administración).
[edit protocols] user@PE1# set rsvp preemption aggressive user@PE1# set rsvp interface all aggregate user@PE1# set rsvp interface fxp0.0 disable user@PE1# set rsvp interface ge-0/0/1.0 user@PE1# set rsvp interface ge-0/0/2.0
-
Habilite MPLS en todas las interfaces del enrutador PE1 (excluyendo la interfaz de administración).
[edit protocols] user@PE1# set mpls interface all user@PE1# set mpls interface fxp0.0 disable
-
Configure los parámetros estadísticos de MPLS.
[edit protocols] user@PE1# set mpls statistics file auto-bw user@PE1# set mpls statistics file size 10m user@PE1# set mpls statistics interval 10 user@PE1# set mpls statistics auto-bandwidth
-
Configure los parámetros de plantilla de ruta de conmutación de etiquetas (LSP).
[edit protocols] user@PE1# set mpls label-switched-path PE1-to-PE2-template1 template user@PE1# set mpls label-switched-path PE1-to-PE2-template1 optimize-timer 30 user@PE1# set mpls label-switched-path PE1-to-PE2-template1 link-protection user@PE1# set mpls label-switched-path PE1-to-PE2-template1 adaptive user@PE1# set mpls label-switched-path PE1-to-PE2-template1 auto-bandwidth adjust-interval 300 user@PE1# set mpls label-switched-path PE1-to-PE2-template1 auto-bandwidth adjust-threshold 5 user@PE1# set mpls label-switched-path PE1-to-PE2-template1 auto-bandwidth minimum-bandwidth 10m user@PE1# set mpls label-switched-path PE1-to-PE2-template1 auto-bandwidth maximum-bandwidth 10m
-
Configure un LSP de contenedor entre el enrutador PE1 y el enrutador PE2, y asigne la plantilla LSP PE1 a PE2-template1.
[edit protocols] user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 to 10.255.102.128 user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 label-switched-path-template PE1-to-PE2-template1
-
Configure los parámetros LSP del contenedor.
[edit protocols] user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging maximum-member-lsps 20 user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging minimum-member-lsps 2 user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging splitting-bandwidth 40m user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging merging-bandwidth 6m user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging maximum-signaling-bandwidth 10m user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging minimum-signaling-bandwidth 10m user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging normalization normalize-interval 400 user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging normalization failover-normalization user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging normalization normalization-retry-duration 20 user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging normalization normalization-retry-limits 3 user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging sampling cut-off-threshold 1 user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging sampling use-percentile 90
-
Configure el grupo BGP y asigne las direcciones IP local y vecina.
[edit protocols] user@PE1# set bgp group to-PE2 type internal user@PE1# set bgp group to-PE2 local-address 10.255.102.166 user@PE1# set bgp group to-PE2 neighbor 10.255.102.128 user@PE1# set bgp group to-PE2 family inet-vpn unicast user@PE1# set bgp group to-PE2 export direct
-
Habilite OSPF en todas las interfaces del enrutador PE1 (excluyendo la interfaz de administración) junto con las capacidades de ingeniería de tráfico.
[edit protocols] user@PE1# set ospf traffic-engineering user@PE1# set ospf area 0.0.0.0 interface all user@PE1# set ospf area 0.0.0.0 interface fxp0.0 disable user@PE1# set ospf area 0.0.0.0 interface ge-0/0/2.0 metric 100
-
Configure la instrucción de directiva para equilibrar la carga del tráfico.
[edit policy-options] user@PE1# set policy-statement direct term 1 from protocol direct user@PE1# set policy-statement direct term 1 then accept user@PE1# set policy-statement pplb then load-balance per-packet
-
Configure una instancia de enrutamiento en el enrutador PE1 y asigne la interfaz de instancia de enrutamiento.
[edit routing-instances] user@PE1# set vpn1 instance-type vrf user@PE1# set vpn1 interface ge-0/0/0.0
-
Configure los valores del distinguidor de ruta, el destino vrf y la etiqueta vrf table para la instancia de enrutamiento VRF.
[edit routing-instances] user@PE1# set vpn1 route-distinguisher 10.255.102.166:1 user@PE1# set vpn1 vrf-target target:1:1 user@PE1# set vpn1 vrf-table-label
Resultados
Desde el modo de configuración, escriba los comandos , show routing-options, show policy-optionsshow protocols, y show routing-options para confirmar la show interfacesconfiguración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
user@PE1# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 10.1.1.1/24;
}
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.10.10.1/24;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 10.40.40.1/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.102.166/32;
}
family mpls;
}
}
user@PE1# show routing-options
router-id 10.255.102.166;
autonomous-system 65034;
forwarding-table {
export pplb;
}
user@PE1# show protocols
rsvp {
preemption aggressive;
interface all {
aggregate;
}
interface fxp0.0 {
disable;
}
interface ge-0/0/1.0;
interface ge-0/0/2.0;
}
mpls {
statistics {
file auto-bw size 10m;
interval 10;
auto-bandwidth;
}
label-switched-path PE1-to-PE2-template1 {
template;
optimize-timer 30;
link-protection;
adaptive;
auto-bandwidth {
adjust-interval 300;
adjust-threshold 5;
minimum-bandwidth 10m;
maximum-bandwidth 10m;
}
}
container-label-switched-path PE1-PE2-container-100 {
label-switched-path-template {
PE1-to-PE2-template1;
}
to 10.255.102.128;
splitting-merging {
maximum-member-lsps 20;
minimum-member-lsps 2;
splitting-bandwidth 40m;
merging-bandwidth 6m;
maximum-signaling-bandwidth 10m;
minimum-signaling-bandwidth 10m;
normalization {
normalize-interval 400;
failover-normalization;
normalization-retry-duration 20;
normalization-retry-limits 3;
}
sampling {
cut-off-threshold 1;
use-percentile 90;
}
}
}
interface all;
interface fxp0.0 {
disable;
}
}
bgp {
group to-PE2 {
type internal;
local-address 10.255.102.166;
family inet-vpn {
unicast;
}
export direct;
neighbor 10.255.102.128;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
interface ge-0/0/2.0 {
metric 100;
}
}
}
user@PE1# show policy-options
policy-statement direct {
term 1 {
from protocol direct;
then accept;
}
}
policy-statement pplb {
then load-balance {
per-packet;
}
}
user@PE1# show routing-instances
vpn1 {
instance-type vrf;
interface ge-0/0/0.0;
route-distinguisher 10.255.102.166:1;
vrf-target target:1:1;
vrf-table-label;
}
Verificación
Confirme que la configuración funcione correctamente.
- Verificación del estado del LSP del contenedor sin ancho de banda
- Verificación del estado del LSP del contenedor con un mayor ancho de banda (antes de la normalización)
- Verificación del estado del LSP del contenedor con un mayor ancho de banda (después de la normalización)
- Comprobación del proceso de división de LSP del contenedor
- Comprobación de las estadísticas de LSP del contenedor
- Verificación del estado del LSP del contenedor con ancho de banda disminuido (antes de la normalización)
- Verificación del estado del LSP del contenedor con ancho de banda disminuido (después de la normalización)
- Comprobación del proceso de fusión de LSP de contenedores
- Comprobación de la normalización de conmutación por error
- Comprobación de la normalización incremental
Verificación del estado del LSP del contenedor sin ancho de banda
Propósito
Compruebe el estado del LSP del contenedor.
Acción
Desde el modo operativo, ejecute el show mpls container-lsp extensive comando.
user@PE1> show mpls container-lsp extensive
Ingress LSP: 1 sessions
Container LSP name: PE1-PE2-container-100, State: Up, Member count: 2
Normalization
Min LSPs: 2, Max LSPs: 20
Aggregate bandwidth: 20Mbps, Sampled Aggregate bandwidth: 0bps
NormalizeTimer: 400 secs, NormalizeThreshold: 10%
Max Signaling BW: 10Mbps, Min Signaling BW: 10Mbps, Splitting BW: 40Mbps, Merging BW: 6Mbps
Mode: incremental-normalization, failover-normalization
Sampling: Outlier cut-off 1, Percentile 90 of Aggregate
Normalization in 143 second(s)
36 Jun 5 04:12:17.497 Clear history and statistics: on container (PE1-PE2-container-100)
35 Jun 5 04:12:17.497 Avoid normalization: not needed with bandwidth 0 bps
34 Jun 5 04:05:37.484 Clear history and statistics: on container (PE1-PE2-container-100)
33 Jun 5 04:05:37.484 Avoid normalization: not needed with bandwidth 0 bps
32 Jun 5 03:58:57.470 Clear history and statistics: on container (PE1-PE2-container-100)
31 Jun 5 03:58:57.470 Avoid normalization: not needed with bandwidth 0 bps
30 Jun 5 03:52:17.455 Clear history and statistics: on container (PE1-PE2-container-100)
29 Jun 5 03:52:17.455 Avoid normalization: not needed with bandwidth 0 bps
28 Jun 5 03:45:37.440 Clear history and statistics: on container (PE1-PE2-container-100)
27 Jun 5 03:45:37.440 Avoid normalization: not needed with bandwidth 0 bps
26 Jun 5 03:38:59.013 Normalization complete: container (PE1-PE2-container-100) with 2 members
25 Jun 5 03:38:57.423 Delete member LSPs: PE1-PE2-container-100-3 through PE1-PE2-container-100-7
24 Jun 5 03:38:57.423 Normalize: container (PE1-PE2-container-100) create 2 LSPs, min bw 10000000bps, member count 7
23 Jun 5 03:38:57.423 Normalize: normalization with aggregate bandwidth 0 bps
22 Jun 5 03:32:19.019 Normalization complete: container (PE1-PE2-container-100) with 7 members
21 Jun 5 03:32:17.404 Clear history and statistics: on container (PE1-PE2-container-100)
20 Jun 5 03:32:17.403 Normalize: container (PE1-PE2-container-100) into 7 members - each with bandwidth 10000000 bps
19 Jun 5 03:32:17.403 Normalize: normalization with aggregate bandwidth 62914560 bps
18 Jun 5 03:32:17.403 Normalize: normalizaton with 62914560 bps
17 Jun 5 03:32:09.219 Normalization complete: container (PE1-PE2-container-100) with 7 members
16 Jun 5 03:32:07.600 Clear history and statistics: on container (PE1-PE2-container-100)
15 Jun 5 03:32:07.600 Normalize: container (PE1-PE2-container-100) into 7 members - each with bandwidth 10000000 bps
14 Jun 5 03:32:07.599 Normalize: normalization with aggregate bandwidth 62914560 bps
13 Jun 5 03:32:07.599 Normalize: normalizaton with 62914560 bps
12 Jun 5 03:26:57.295 Clear history and statistics: on container (PE1-PE2-container-100)
11 Jun 5 03:26:57.295 Avoid normalization: not needed with bandwidth 0 bps
10 Jun 5 03:20:18.297 Normalization complete: container (PE1-PE2-container-100) with 2 members
9 Jun 5 03:20:17.281 Normalize: container (PE1-PE2-container-100) create 2 LSPs, min bw 10000000bps, member count 0
8 Jun 5 03:20:17.281 Normalize: normalization with aggregate bandwidth 0 bps
7 Jun 5 03:17:43.218 Clear history and statistics: on container (PE1-PE2-container-100)
6 Jun 5 03:17:43.218 Avoid normalization: not needed with bandwidth 0 bps
5 Jun 5 03:17:43.212 Normalize: container (PE1-PE2-container-100) received PathErr on member PE1-PE2-container-100-2
4 Jun 5 03:17:43.212 Normalize: container (PE1-PE2-container-100) received PathErr on member PE1-PE2-container-100-1
3 Jun 5 03:12:47.323 Normalization complete: container (PE1-PE2-container-100) with 2 members
2 Jun 5 03:12:16.555 Normalize: container (PE1-PE2-container-100) create 2 LSPs, min bw 10000000bps, member count 0
1 Jun 5 03:12:16.555 Normalize: normalization with aggregate bandwidth 0 bps
10.255.102.128
From: 10.255.102.166, State: Up, ActiveRoute: 0, LSPname: PE1-PE2-container-100-1
ActivePath: (primary)
LSPtype: Dynamic Configured, Penultimate hop popping
LoadBalance: Random
Autobandwidth
MinBW: 10Mbps, MaxBW: 10Mbps
AdjustTimer: 300 secs
Max AvgBW util: 0bps, Bandwidth Adjustment in 12 second(s).
Overflow limit: 0, Overflow sample count: 0
Underflow limit: 0, Underflow sample count: 0, Underflow Max AvgBW: 0bps
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Priorities: 7 0
Bandwidth: 10Mbps
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3)
10.10.10.2 S 10.20.20.2 S 10.30.30.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
10.10.10.2 10.20.20.2 10.30.30.2
17 Jun 5 03:38:59.013 Make-before-break: Switched to new instance
16 Jun 5 03:38:58.003 Record Route: 10.10.10.2 10.20.20.2 3=10.30.30.2
15 Jun 5 03:38:58.003 Up
14 Jun 5 03:38:57.423 Originate make-before-break call
13 Jun 5 03:38:57.423 CSPF: computation result accepted 10.10.10.2 10.20.20.2 10.30.30.2
12 Jun 5 03:33:30.400 CSPF: computation result ignored, new path no benefit
11 Jun 5 03:32:17.403 Pending old path instance deletion
10 Jun 5 03:32:09.218 Make-before-break: Switched to new instance
9 Jun 5 03:32:08.202 Record Route: 10.10.10.2 10.20.20.2 10.30.30.2
8 Jun 5 03:32:08.202 Up
7 Jun 5 03:32:07.603 Originate make-before-break call
6 Jun 5 03:32:07.603 CSPF: computation result accepted 10.10.10.2 10.20.20.2 10.30.30.2
5 Jun 5 03:20:18.278 Selected as active path
4 Jun 5 03:20:18.277 Record Route: 10.10.10.2 10.20.20.2 10.30.30.2
3 Jun 5 03:20:18.277 Up
2 Jun 5 03:20:17.281 Originate Call
1 Jun 5 03:20:17.281 CSPF: computation result accepted 10.10.10.2 10.20.20.2 10.30.30.2
Created: Thu Jun 5 03:20:16 2014
10.255.102.128
From: 10.255.102.166, State: Up, ActiveRoute: 0, LSPname: PE1-PE2-container-100-2
ActivePath: (primary)
LSPtype: Dynamic Configured, Penultimate hop popping
LoadBalance: Random
Autobandwidth
MinBW: 10Mbps, MaxBW: 10Mbps
AdjustTimer: 300 secs
Max AvgBW util: 0bps, Bandwidth Adjustment in 76 second(s).
Overflow limit: 0, Overflow sample count: 0
Underflow limit: 0, Underflow sample count: 0, Underflow Max AvgBW: 0bps
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Priorities: 7 0
Bandwidth: 10Mbps
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3)
10.10.10.2 S 10.20.20.2 S 10.30.30.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
10.10.10.2 10.20.20.2 10.30.30.2
17 Jun 5 03:38:59.013 Make-before-break: Switched to new instance
16 Jun 5 03:38:58.002 Record Route: 10.10.10.2 10.20.20.2 10.30.30.2
15 Jun 5 03:38:58.002 Up
14 Jun 5 03:38:57.423 Originate make-before-break call
13 Jun 5 03:38:57.423 CSPF: computation result accepted 10.10.10.2 10.20.20.2 10.30.30.2
12 Jun 5 03:33:26.189 CSPF: computation result ignored, new path no benefit
11 Jun 5 03:32:17.403 Pending old path instance deletion
10 Jun 5 03:32:09.219 Make-before-break: Switched to new instance
9 Jun 5 03:32:08.204 Record Route: 10.10.10.2 10.20.20.2 10.30.30.2
8 Jun 5 03:32:08.204 Up
7 Jun 5 03:32:07.603 Originate make-before-break call
6 Jun 5 03:32:07.603 CSPF: computation result accepted 10.10.10.2 10.20.20.2 10.30.30.2
5 Jun 5 03:20:18.297 Selected as active path
4 Jun 5 03:20:18.295 Record Route: 10.10.10.2 10.20.20.2 10.30.30.2
3 Jun 5 03:20:18.295 Up
2 Jun 5 03:20:17.281 Originate Call
1 Jun 5 03:20:17.281 CSPF: computation result accepted 10.10.10.2 10.20.20.2 10.30.30.2
Created: Thu Jun 5 03:20:16 2014
Total 2 displayed, Up 2, Down 0
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0Significado
El LSP del contenedor se establece entre los enrutadores PE1 y PE2.
Verificación del estado del LSP del contenedor con un mayor ancho de banda (antes de la normalización)
Propósito
Compruebe el estado del LSP del contenedor con un mayor ancho de banda antes de que se produzca la normalización.
Acción
Desde el modo operativo, ejecute el show mpls container-lsp extensive comando.
user@PE1> show mpls container-lsp extensive
Ingress LSP: 1 sessions
Container LSP name: PE1-PE2-container-100, State: Up, Member count: 2
Normalization
Min LSPs: 2, Max LSPs: 20
Aggregate bandwidth: 20Mbps, Sampled Aggregate bandwidth: 42.6984Mbps
NormalizeTimer: 400 secs, NormalizeThreshold: 10%
Max Signaling BW: 10Mbps, Min Signaling BW: 10Mbps, Splitting BW: 40Mbps, Merging BW: 6Mbps
Mode: incremental-normalization, failover-normalization
Sampling: Outlier cut-off 1, Percentile 90 of Aggregate
Normalization in 321 second(s)
3 Jun 5 21:22:34.731 Normalization complete: container (PE1-PE2-container-100) with 2 members
2 Jun 5 21:22:15.503 Normalize: container (PE1-PE2-container-100) create 2 LSPs, min bw 10000000bps, member count 0
1 Jun 5 21:22:15.503 Normalize: normalization with aggregate bandwidth 0 bps
10.255.102.128
From: 10.255.102.166, State: Up, ActiveRoute: 0, LSPname: PE1-PE2-container-100-1
ActivePath: (primary)
Link protection desired
LSPtype: Dynamic Configured, Penultimate hop popping
LoadBalance: Random
Autobandwidth
MinBW: 10Mbps, MaxBW: 10Mbps
AdjustTimer: 300 secs AdjustThreshold: 5%
Max AvgBW util: 23.9893Mbps, Bandwidth Adjustment in 221 second(s).
Overflow limit: 0, Overflow sample count: 6
Underflow limit: 0, Underflow sample count: 0, Underflow Max AvgBW: 0bps
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Priorities: 7 0
Bandwidth: 10Mbps
OptimizeTimer: 30
SmartOptimizeTimer: 180
Reoptimization in 9 second(s).
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3)
10.10.10.2 S 10.20.20.2 S 10.30.30.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
10.255.102.166(flag=0x20) 10.10.10.2(Label=303440) 10.255.102.29(flag=0x20) 10.20.20.2(Label=302144) 10.255.102.128(flag=0x20) 10.30.30.2(Label=3)
10.255.102.128
From: 10.255.102.166, State: Up, ActiveRoute: 0, LSPname: PE1-PE2-container-100-2
ActivePath: (primary)
Link protection desired
LSPtype: Dynamic Configured, Penultimate hop popping
LoadBalance: Random
Autobandwidth
MinBW: 10Mbps, MaxBW: 10Mbps
AdjustTimer: 300 secs AdjustThreshold: 5%
Max AvgBW util: 22.1438Mbps, Bandwidth Adjustment in 221 second(s).
Overflow limit: 0, Overflow sample count: 6
Underflow limit: 0, Underflow sample count: 0, Underflow Max AvgBW: 0bps
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Priorities: 7 0
Bandwidth: 10Mbps
OptimizeTimer: 30
SmartOptimizeTimer: 180
Reoptimization in 9 second(s).
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3)
10.10.10.2 S 10.20.20.2 S 10.30.30.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
10.255.102.166(flag=0x20) 10.10.10.2(Label=303456) 10.255.102.29(flag=0x20) 10.20.20.2(Label=302160) 10.255.102.128(flag=0x20) 10.30.30.2(Label=3)
Total 2 displayed, Up 2, Down 0
Significado
Dado que no se ha producido la normalización, el recuento de LSP de miembros permanece en 2.
Verificación del estado del LSP del contenedor con un mayor ancho de banda (después de la normalización)
Propósito
Compruebe el estado del LSP del contenedor con un mayor ancho de banda después de que se produzca la normalización.
Acción
Desde el modo operativo, ejecute el show mpls container-lsp extensive comando.
user@PE1> show mpls container-lsp extensive
Ingress LSP: 1 sessions
Container LSP name: PE1-PE2-container-100, State: Up, Member count: 5
Normalization
Min LSPs: 2, Max LSPs: 20
Aggregate bandwidth: 50Mbps, Sampled Aggregate bandwidth: 45.8873Mbps
NormalizeTimer: 400 secs, NormalizeThreshold: 10%
Max Signaling BW: 10Mbps, Min Signaling BW: 10Mbps, Splitting BW: 40Mbps, Merging BW: 6Mbps
Mode: incremental-normalization, failover-normalization
Sampling: Outlier cut-off 1, Percentile 90 of Aggregate
Normalization in 169 second(s)
7 Jun 5 21:29:02.921 Normalization complete: container (PE1-PE2-container-100) with 5 members
6 Jun 5 21:28:55.505 Clear history and statistics: on container (PE1-PE2-container-100)
5 Jun 5 21:28:55.505 Normalize: container (PE1-PE2-container-100) into 5 members - each with bandwidth 10000000 bps
4 Jun 5 21:28:55.504 Normalize: normalization with aggregate bandwidth 45281580 bps
3 Jun 5 21:22:34.731 Normalization complete: container (PE1-PE2-container-100) with 2 members
2 Jun 5 21:22:15.503 Normalize: container (PE1-PE2-container-100) create 2 LSPs, min bw 10000000bps, member count 0
1 Jun 5 21:22:15.503 Normalize: normalization with aggregate bandwidth 0 bps
10.255.102.128
From: 10.255.102.166, State: Up, ActiveRoute: 0, LSPname: PE1-PE2-container-100-1
ActivePath: (primary)
Link protection desired
LSPtype: Dynamic Configured, Penultimate hop popping
LoadBalance: Random
Autobandwidth
MinBW: 10Mbps, MaxBW: 10Mbps
AdjustTimer: 300 secs AdjustThreshold: 5%
Max AvgBW util: 11.0724Mbps, Bandwidth Adjustment in 129 second(s).
Overflow limit: 0, Overflow sample count: 1
Underflow limit: 0, Underflow sample count: 0, Underflow Max AvgBW: 0bps
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Priorities: 7 0
Bandwidth: 10Mbps
OptimizeTimer: 30
SmartOptimizeTimer: 180
Reoptimization in 12 second(s).
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3)
10.10.10.2 S 10.20.20.2 S 10.30.30.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
10.255.102.166(flag=0x20) 10.10.10.2(Label=303488) 10.255.102.29(flag=0x20) 10.20.20.2(Label=302224) 10.255.102.128(flag=0x20) 10.30.30.2(Label=3)
10.255.102.128
From: 10.255.102.166, State: Up, ActiveRoute: 0, LSPname: PE1-PE2-container-100-2
ActivePath: (primary)
Link protection desired
LSPtype: Dynamic Configured, Penultimate hop popping
LoadBalance: Random
Autobandwidth
MinBW: 10Mbps, MaxBW: 10Mbps
AdjustTimer: 300 secs AdjustThreshold: 5%
Max AvgBW util: 8.50751Mbps, Bandwidth Adjustment in 189 second(s).
Overflow limit: 0, Overflow sample count: 0
Underflow limit: 0, Underflow sample count: 11, Underflow Max AvgBW: 8.50751Mbps
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Priorities: 7 0
Bandwidth: 10Mbps
OptimizeTimer: 30
SmartOptimizeTimer: 180
Reoptimization in 6 second(s).
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3)
10.10.10.2 S 10.20.20.2 S 10.30.30.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
10.255.102.166(flag=0x20) 10.10.10.2(Label=303504) 10.255.102.29(flag=0x20) 10.20.20.2(Label=302240) 10.255.102.128(flag=0x20) 10.30.30.2(Label=3)
10.255.102.128
From: 10.255.102.166, State: Up, ActiveRoute: 0, LSPname: PE1-PE2-container-100-3
ActivePath: (primary)
Link protection desired
LSPtype: Dynamic Configured, Penultimate hop popping
LoadBalance: Random
Autobandwidth
MinBW: 10Mbps, MaxBW: 10Mbps
AdjustTimer: 300 secs AdjustThreshold: 5%
Max AvgBW util: 9.59422Mbps, Bandwidth Adjustment in 249 second(s).
Overflow limit: 0, Overflow sample count: 0
Underflow limit: 0, Underflow sample count: 5, Underflow Max AvgBW: 9.59422Mbps
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Priorities: 7 0
Bandwidth: 10Mbps
OptimizeTimer: 30
SmartOptimizeTimer: 180
Reoptimization in 25 second(s).
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3)
10.10.10.2 S 10.20.20.2 S 10.30.30.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
10.255.102.166(flag=0x20) 10.10.10.2(Label=303472) 10.255.102.29(flag=0x20) 10.20.20.2(Label=302176) 10.255.102.128(flag=0x20) 10.30.30.2(Label=3)
10.255.102.128
From: 10.255.102.166, State: Up, ActiveRoute: 0, LSPname: PE1-PE2-container-100-4
ActivePath: (primary)
Link protection desired
LSPtype: Dynamic Configured, Penultimate hop popping
LoadBalance: Random
Autobandwidth
MinBW: 10Mbps, MaxBW: 10Mbps
AdjustTimer: 300 secs AdjustThreshold: 5%
Max AvgBW util: 9.16169Mbps, Bandwidth Adjustment in 9 second(s).
Overflow limit: 0, Overflow sample count: 0
Underflow limit: 0, Underflow sample count: 29, Underflow Max AvgBW: 9.16169Mbps
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Priorities: 7 0
Bandwidth: 10Mbps
OptimizeTimer: 30
SmartOptimizeTimer: 180
Reoptimization in 1 second(s).
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3)
10.10.10.2 S 10.20.20.2 S 10.30.30.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
10.255.102.166(flag=0x20) 10.10.10.2(Label=303520) 10.255.102.29(flag=0x20) 10.20.20.2(Label=302192) 10.255.102.128(flag=0x20) 10.30.30.2(Label=3)
10.255.102.128
From: 10.255.102.166, State: Up, ActiveRoute: 0, LSPname: PE1-PE2-container-100-5
ActivePath: (primary)
Link protection desired
LSPtype: Dynamic Configured, Penultimate hop popping
LoadBalance: Random
Autobandwidth
MinBW: 10Mbps, MaxBW: 10Mbps
AdjustTimer: 300 secs AdjustThreshold: 5%
Max AvgBW util: 8.39908Mbps, Bandwidth Adjustment in 69 second(s).
Overflow limit: 0, Overflow sample count: 0
Underflow limit: 0, Underflow sample count: 23, Underflow Max AvgBW: 8.39908Mbps
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Priorities: 7 0
Bandwidth: 10Mbps
OptimizeTimer: 30
SmartOptimizeTimer: 180
Reoptimization in 17 second(s).
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3)
10.10.10.2 S 20.20.20.2 S 30.30.30.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
10.255.102.166(flag=0x20) 10.10.10.2(Label=303536) 10.255.102.29(flag=0x20) 10.20.20.2(Label=302208) 10.255.102.128(flag=0x20) 10.30.30.2(Label=3)
Total 5 displayed, Up 5, Down 0
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0Significado
Al expirar el temporizador de normalización, el LSP del contenedor se divide en cinco LSP miembros, cada uno con 10 Mbps (ancho de banda de señalización mínimo y máximo). Como resultado, el ancho de banda agregado es de 50 Mbps.
Comprobación del proceso de división de LSP del contenedor
Propósito
Compruebe el proceso de división de LSP del contenedor después de que se produzca la normalización.
Acción
Desde el modo operativo, ejecute el show route 10.2.2.0 comando.
user@PE1> show route 10.2.2.0
vpn1.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.2.2.0/24 *[BGP/170] 00:12:14, localpref 100, from 10.255.102.128
AS path: I, validation-state: unverified
>to 10.10.10.2 via ge-0/0/1.0,label-switched-path PE1-PE2-container100-1
to 10.10.10.2 via ge-0/0/1.0, label-switched-path PE1-PE2-container100-2
to 10.10.10.2 via ge-0/0/1.0, label-switched-path PE1-PE2-container100-3
to 10.10.10.2 via ge-0/0/1.0, label-switched-path PE1-PE2-container100-4
to 10.10.10.2 via ge-0/0/1.0, label-switched-path PE1-PE2-container100-5Significado
Después de la división de LSP, el enrutador PE1 ha inyectado la adyacencia de reenvío.
Comprobación de las estadísticas de LSP del contenedor
Propósito
Compruebe las estadísticas de LSP del contenedor después de que se produzca la normalización.
Acción
Desde el modo operativo, ejecute el show mpls container-lsp statistics comando.
user@PE1> show mpls container-lsp statistics Ingress LSP: 1 sessions Container LSP name State Member LSP count PE1-PE2-container-100 Up 5 To From State Packets Bytes LSPname 10.255.102.128 10.255.102.166 Up 15166271 2062612856 PE1-PE2-container-100-1 10.255.102.128 10.255.102.166 Up 12289912 1671428032 PE1-PE2-container-100-2 10.255.102.128 10.255.102.166 Up 13866911 1885899896 PE1-PE2-container-100-3 10.255.102.128 10.255.102.166 Up 12558707 1707984152 PE1-PE2-container-100-4 10.255.102.128 10.255.102.166 Up 11512151 1565652536 PE1-PE2-container-100-5
Significado
El tráfico tiene un equilibrio de carga en los LSP miembro recién creados.
Verificación del estado del LSP del contenedor con ancho de banda disminuido (antes de la normalización)
Propósito
Compruebe el estado del LSP del contenedor con ancho de banda disminuido antes de que ocurra la normalización.
Acción
Desde el modo operativo, ejecute el show mpls container-lsp detail comando.
user@PE1> show mpls container-lsp detail Ingress LSP: 1 sessions Container LSP name: PE1-PE2-container-100, State: Up, Member count: 5 Normalization Min LSPs: 2, Max LSPs: 20 Aggregate bandwidth: 50Mbps, Sampled Aggregate bandwidth: 2.0215Mbps NormalizeTimer: 400 secs, NormalizeThreshold: 10% Max Signaling BW: 10Mbps, Min Signaling BW: 10Mbps, Splitting BW: 40Mbps, Merging BW: 6Mbps Mode: incremental-normalization, failover-normalization Sampling: Outlier cut-off 1, Percentile 90 of Aggregate Normalization in 384 second(s) ---Output truncated---
Significado
Debido a que la normalización no ha ocurrido, el recuento de LSP de miembros permanece en 5.
Verificación del estado del LSP del contenedor con ancho de banda disminuido (después de la normalización)
Propósito
Compruebe el estado del LSP del contenedor con ancho de banda disminuido después de que se produzca la normalización.
Acción
Desde el modo operativo, ejecute el show mpls container-lsp detail comando.
user@PE1> show mpls container-lsp detail Ingress LSP: 1 sessions Container LSP name: PE1-PE2-container-100, State: Up, Member count: 2 Normalization Min LSPs: 2, Max LSPs: 20 Aggregate bandwidth: 20Mbps, Sampled Aggregate bandwidth: 0bps NormalizeTimer: 400 secs, NormalizeThreshold: 10% Max Signaling BW: 10Mbps, Min Signaling BW: 10Mbps, Splitting BW: 40Mbps, Merging BW: 6Mbps Mode: incremental-normalization, failover-normalization Sampling: Outlier cut-off 1, Percentile 90 of Aggregate Normalization in 397 second(s) 22 Jun 5 22:30:37.094 Clear history and statistics: on container (PE1-PE2-container-100) 21 Jun 5 22:30:37.094 Delete member LSPs: PE1-PE2-container-100-3 through PE1-PE2-container-100-5 20 Jun 5 22:30:37.090 Normalize: container (PE1-PE2-container-100) into 2 members - each with bandwidth 10000000 bps 19 Jun 5 22:30:37.090 Normalize: normalization with aggregate bandwidth 2037595 bps 18 Jun 5 22:30:37.090 Normalize: normalizaton with 2037595 bps ---Output truncated---
Significado
Al expirar el temporizador de normalización, se produce la fusión de LSP del contenedor porque hay una reducción general del ancho de banda. Los LSP de miembro se fusionan y el recuento de LSP de miembro es 2 después de la normalización.
Comprobación del proceso de fusión de LSP de contenedores
Propósito
Compruebe el proceso de división de LSP del contenedor después de que se produzca la normalización.
Acción
Desde el modo operativo, ejecute el show route 10.2.2.0 comando.
user@PE1> show route 10.2.2.0
vpn1.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.2.2.0/24 *[BGP/170] 01:09:45, localpref 100, from 10.255.102.128
AS path: I, validation-state: unverified
> to 10.10.10.2 via ge-0/0/1.0, label-switched-path PE1-PE2-container-100-1
to 10.10.10.2 via ge-0/0/1.0, label-switched-path PE1-PE2-container-100-2Significado
Después de la fusión de LSP, el enrutador PE1 ha eliminado los LSP miembros combinados.
Comprobación de la normalización de conmutación por error
Propósito
Verifique la redistribución de carga cuando el tráfico se envía a 35 Mbps y el vínculo entre los enrutadores P1 y P2 está deshabilitado. La llegada de PathErr al fallar el vínculo desencadena la normalización inmediata.
Para habilitar la normalización de conmutación por error, incluya la instrucción de failover-normalization configuración en el nivel de [edit protocols mpls container-label-switched-path container-lsp-name splitting-merging normalization] jerarquía.
Acción
Desde el modo operativo, ejecute el show mpls container-lsp comando.
user@PE1> show mpls container-lsp Ingress LSP: 1 sessions Container LSP name State Member LSP count PE1-PE2-container-100 Up 2 To From State Rt P ActivePath LSPname 10.255.102.128 10.255.102.166 Up 0 * PE1-PE2-container-100-1 10.255.102.128 10.255.102.166 Up 0 * PE1-PE2-container-100-2 Total 2 displayed, Up 2, Down 0
Después de que el vínculo ge-0/0/2 entre los enrutadores P1 y P2 deja de funcionar, la normalización se activa inmediatamente.
Desde el modo operativo, ejecute el show mpls container-lsp detail comando.
user@PE1> show mpls container-lsp detail
Ingress LSP: 1 sessions
Container LSP name: PE1-PE2-container-100, State: Up, Member count: 4
Normalization
Min LSPs: 2, Max LSPs: 20
Aggregate bandwidth: 40Mbps, Sampled Aggregate bandwidth: 34.5538Mbps
NormalizeTimer: 3000 secs, NormalizeThreshold: 10%
Max Signaling BW: 10Mbps, Min Signaling BW: 10Mbps, Splitting BW: 40Mbps, Merging BW: 6Mbps
Mode: incremental-normalization, failover-normalization
Sampling: Outlier cut-off 1, Percentile 90 of Aggregate
Normalization in 2970 second(s)
11 Jun 5 19:28:27.564 Normalization complete: container (PE1-PE2-container-100) with 4 members
10 Jun 5 19:28:20.315 Normalize: container (PE1-PE2-container-100) received PathErr on member PE1-PE2-container-100-2[2 times]
9 Jun 5 19:28:20.315 Normalize: container (PE1-PE2-container-100) received PathErr on member PE1-PE2-container-100-1[2 times]
8 Jun 5 19:28:20.311 Clear history and statistics: on container (PE1-PE2-container-100)
7 Jun 5 19:28:20.311 Normalize: container (PE1-PE2-container-100) into 4 members - each with bandwidth 10000000 bps
6 Jun 5 19:28:20.311 Normalize: normalization with aggregate bandwidth 33665020 bps
5 Jun 5 19:28:20.308 Normalize: container (PE1-PE2-container-100) received PathErr on member PE1-PE2-container-100-2
4 Jun 5 19:28:20.308 Normalize: container (PE1-PE2-container-100) received PathErr on member PE1-PE2-container-100-1
3 Jun 5 19:27:48.574 Normalization complete: container (PE1-PE2-container-100) with 2 members
2 Jun 5 19:27:28.644 Normalize: container (PE1-PE2-container-100) create 2 LSPs, min bw 10000000bps, member count 0
1 Jun 5 19:27:28.644 Normalize: normalization with aggregate bandwidth 0 bps
----Output truncated----Significado
La llegada del mensaje PathErr al fallar el vínculo desencadena la normalización inmediata.
Comprobación de la normalización incremental
Propósito
Compruebe la normalización incremental cuando no haya suficiente ancho de banda disponible.
En el enrutador PE1, el ancho de banda estático de las interfaces RSVP está restringido a 22 Mbps cada una.
Acción
Desde el modo operativo, ejecute el show rsvp interface comando.
user@PE1> show rsvp interface
RSVP interface: 4 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
ge-0/0/2.0 Up 0 100% 22Mbps 22Mbps 0bps 21.4031Mbps
ge-0/0/1.0 Up 2 100% 22Mbps 12Mbps 10Mbps 21.7011MbpsAntes de que ocurra la normalización:
Desde el modo operativo, ejecute el show mpls container-lsp comando.
user@PE1> show mpls container-lsp Ingress LSP: 1 sessions Container LSP name State Member LSP count PE1-PE2-container-100 Up 2 To From State Rt P ActivePath LSPname 10.255.102.128 10.255.102.166 Up 0 * PE1-PE2-container-100-1 10.255.102.128 10.255.102.166 Up 0 * PE1-PE2-container-100-2
Después de que ocurra la normalización:
Desde el modo operativo, ejecute el show mpls container-lsp comando.
user@PE1> show mpls container-lsp Ingress LSP: 1 sessions Container LSP name State Member LSP count PE1-PE2-container-100 Up 7 To From State Rt P ActivePath LSPname 10.255.102.128 10.255.102.166 Up 0 * PE1-PE2-container-100-1 10.255.102.128 10.255.102.166 Up 0 * PE1-PE2-container-100-2 10.255.102.128 10.255.102.166 Up 0 * PE1-PE2-container-100-3 10.255.102.128 10.255.102.166 Up 0 * PE1-PE2-container-100-4 10.255.102.128 10.255.102.166 Up 0 * PE1-PE2-container-100-5 10.255.102.128 10.255.102.166 Up 0 * PE1-PE2-container-100-6 10.255.102.128 0.0.0.0 Dn 0 - PE1-PE2-container-100-7 Total 7 displayed, Up 6, Down 1
Desde el modo operativo, ejecute el show mpls container-lsp detail comando.
user@PE1> show mpls container-lsp detail
Ingress LSP: 1 sessions
Container LSP name: PE1-PE2-container-100, State: Up, Member count: 7
Normalization
Min LSPs: 2, Max LSPs: 10
Aggregate bandwidth: 40.8326Mbps, Sampled Aggregate bandwidth: 50.129Mbps
NormalizeTimer: 9000 secs, NormalizeThreshold: 10%
Max Signaling BW: 10Mbps, Min Signaling BW: 5Mbps, Splitting BW: 40Mbps, Merging BW: 5Mbps
Mode: incremental-normalization, failover-normalization
Sampling: Outlier cut-off 1, Percentile 90 of Aggregate
Normalization in 8072 second(s)
10 Jun 5 18:40:17.812 Normalization complete: container (PE1-PE2-container-100) with 7 members, retry-limit reached
9 Jun 5 18:40:08.028 Normalize: container (PE1-PE2-container-100) for target member count 7, member bandwidth 6805439 bps
8 Jun 5 18:39:58.301 Normalize: container (PE1-PE2-container-100) for target member count 6, member bandwidth 7939679 bps
7 Jun 5 18:39:48.470 Clear history and statistics: on container (PE1-PE2-container-100)
6 Jun 5 18:39:48.470 Normalize: container (PE1-PE2-container-100) into 5 members - each with bandwidth 9527615 bps
5 Jun 5 18:39:48.469 Normalize: normalization with aggregate bandwidth 47638076 bps
4 Jun 5 18:39:48.469 Normalize: normalizaton with 47638076 bps
3 Jun 5 18:39:09.471 Normalization complete: container (PE1-PE2-container-100) with 2 members
2 Jun 5 18:38:59.822 Normalize: container (PE1-PE2-container-100) create 2 LSPs, min bw 5000000bps, member count 0
1 Jun 5 18:38:59.822 Normalize: normalization with aggregate bandwidth 0 bpsSignificado
Después de la normalización, el ancho de banda agregado después de tres reintentos es de 40,8326 Mbps.
Configuración de la administración dinámica de ancho de banda mediante LSP de contenedor
Puede configurar un LSP de contenedor para habilitar dinámicamente el equilibrio de carga entre varios LSP punto a punto. Un LSP de contenedor incluye uno o más LSP miembro entre los mismos dispositivos de enrutamiento de entrada y salida. Los LSP miembro son similares a los LSP punto a punto independientes, y cada LSP miembro toma una ruta diferente hacia el mismo destino y se puede enrutar a lo largo de una ruta de costo de IGP diferente.
Un LSP de contenedor proporciona compatibilidad con la administración dinámica del ancho de banda al permitir que el enrutador de entrada agregue y elimine dinámicamente LSP miembro mediante un proceso denominado división de LSP y fusión de LSP, respectivamente, en función de la configuración y el tráfico agregado. Además de la adición y eliminación, los LSP miembro también se pueden volver a optimizar con diferentes valores de ancho de banda de una manera que se hace antes de la interrupción.
Antes de empezar:
Configure las interfaces del dispositivo.
Configure el ID del enrutador del dispositivo y el número de sistema autónomo.
Configure los protocolos siguientes:
Confirmación de asistencia (RSVP)
protocolo de puerta de enlace de frontera (BGP)
Configure un grupo BGP para emparejar un dispositivo con un dispositivo perimetral de proveedor remoto (PE).
OSPF
Habilite las capacidades de ingeniería de tráfico.
Configure una instancia de enrutamiento VRF.
Para configurar el dispositivo PE: