Configuración de LSP de contenedor
Descripción general de la administración dinámica del ancho de banda mediante LSP de contenedor
Los LSP RSVP con la función de banda automática se implementan cada vez más en las redes para satisfacer las necesidades de ingeniería de tráfico. Sin embargo, las soluciones actuales de ingeniería de tráfico 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 de RSVP intentan adaptar los LSP a lo largo de una ruta determinada sin crear LSP paralelos, o no interactúan con los otros enrutadores en la red y buscan un ancho de banda adicional disponible.
Esta característica proporciona un enrutador de entrada con 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 varias rutas RSVP
- Implementación de varias rutas de 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 Junos OS
- Instrucciones de configuración compatibles con LSP de contenedor
- Impacto de la configuración de LSP de contenedor en el rendimiento de la red
- Funciones compatibles y no compatibles
Descripción de las extensiones de varias rutas RSVP
Las extensiones multiruta RSVP propuestas en el IETF [KOMPELLA-MLSP] permiten la configuración de rutas de conmutación de etiquetas (LSP de contenedor) diseñadas por tráfico. Los LSP de contenedor, además de ajustarse a las restricciones de ingeniería de tráfico, utilizan varias rutas independientes desde un origen hasta un destino, lo que facilita el equilibrio de carga del tráfico. Las extensiones de varias rutas requieren cambios en el protocolo RSVP-TE y permiten la fusión de etiquetas en los nodos descendentes (similar a LDP), lo que también ayuda a conservar los recursos de reenvío.
Las extensiones de varias rutas a RSVP ofrecen los siguientes beneficios:
Facilidad de configuración. Por lo general, varios LSP RSVP están configurados para el equilibrio de carga o el empaquetado de contenedores. Con un LSP de contenedor, hay una sola entidad para aprovisionar, administrar y supervisar LSP. Los cambios en la topología se manejan de manera fácil y autónoma mediante la adición, cambio o eliminación de LSP miembro para reequilibrar el tráfico, mientras se mantienen las mismas restricciones de ingeniería de tráfico.
La multiruta de costo igual (ECMP) de RSVP hereda las ventajas estándar del ECMP al absorber los aumentos de tráfico.
La ingeniería de tráfico de varias rutas permite un uso mejor y completo de los recursos de red.
Conocer la relación entre los LSP ayuda a computar diversas rutas con enrutamiento basado en restricciones. Permite el ajuste de los LSP miembros mientras que otros LSP miembros continúan llevando tráfico.
Los enrutadores intermedios tienen la oportunidad de fusionar las etiquetas de los LSP miembros. Esto reduce la cantidad de etiquetas que deben agregarse al plano de reenvío y, a su vez, reduce el tiempo de convergencia.
Si la cantidad 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 de punto a punto RSVP que requieren protección de vínculo o nodo, los próximos saltos se duplican a medida que cada LSP está programado con los próximos saltos principales y de respaldo. Varias rutas (o ECMP) de RSVP obvia la necesidad de realizar copias de seguridad en los próximos saltos.
Cuando se produce un error de vínculo, el enrutador ascendente al error del vínculo puede distribuir el tráfico del vínculo fallido a las sucursales de ECMP restantes, lo que evita la necesidad de omitir LSP. El enfoque de LSP de bypass no solo requiere más estado al señalar LSP de respaldo, sino que también sufre problemas de escalamiento que resultan en la temporización del punto de fusión de un bloque de estado de ruta protegida (PSB) antes de que el punto de reparación local (PLR) tenga la oportunidad de señalar el LSP de respaldo.
Implementación de varias rutas de RSVP de Junos OS
Para implementar varias rutas de RSVP (ECMP) en una red, todos los nodos por los que pasan los LSP de ECMP deben comprender las extensiones de protocolo ECMP RSVP. Esto puede ser un desafío, especialmente en las redes de varios proveedores.
Junos OS implementa las extensiones de varias rutas RSVP sin la necesidad de extensiones de protocolo. Se aprovisiona un LSP de contenedor único, que tiene las características de ECMP y TE RSVP. Un LSP de contenedor consta de varios LSP miembros y se configura entre el dispositivo de enrutamiento de entrada y salida. Cada LSP miembro toma una ruta diferente al mismo destino. El dispositivo de enrutamiento de entrada está configurado con todos los parámetros necesarios para calcular el LSP ECMP RSVP. Los parámetros configurados para calcular un conjunto de LSP punto a punto RSVP pueden ser utilizados por el dispositivo de enrutamiento de entrada para calcular también 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 del 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 el tráfico de manera dinámica para beneficiar a los recursos disponibles.
Figura 1 muestra una topología de red de ejemplo con todos los LSP con las mismas prioridades de espera y configuración, y control de admisión restringido en el enrutador de entrada. Todos los vínculos se anotan con una tupla (costo y capacidad).
Algunos de los problemas de ingeniería de tráfico que se ven en Figura 1 se enumeran aquí:
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 sean capaces de señalar algunos LSP con las demandas requeridas, aunque el ancho de banda está disponible en la red, lo que lleva a una infrautilización de la capacidad de vínculo.
Por ejemplo, los siguientes LSP llegan a la secuencia mencionada en Tabla 1.
Tabla 1: Orden de secuencia LSP para el embalaje del contenedor Hora
Source
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 se señala primero al enrutador B, ambos LSP son enrutables. El empaquetado de contenedores ocurre debido a la falta de visibilidad de las demandas de ancho de banda individual por LSP y por dispositivo en el dispositivo de enrutamiento de entrada.
El embalaje de contenedores también puede ocurrir cuando no hay ningún requisito para pedir LSP. Por ejemplo, si hay un LSP con demanda X y hay dos rutas diferentes al destino del 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ñale o re-optimice con la nueva demanda. En Figura 1, con soporte de LSP de contenedor, la entrada B crea dos LSP cada uno de tamaño 5 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.
DeadlockTeniendo en cuenta Figura 1, los LSP siguen la secuencia mencionada en Tabla 2.
Tabla 2: Orden de secuencia LSP para bloqueo Hora
Source
Destino
Demanda
ERO
Evento
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
2 a 20
A-C-D-E
Error en el enrutamiento basado en restricciones, sin señalización RSVP
En el momento 3, la demanda de LSP de A a E aumenta de 2 a 20. Si la banda automática está configurada, el cambio no se detecta hasta que caduca 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 caiga en otros LSP que comparten vínculos comunes con el LSP que se comporta mal.
Esto se debe a las siguientes razones:
Falta de estado global en todos los enrutadores de entrada
Señalización de demandas de mal comportamiento
Desmontar las demandas de comportamiento erróneo
Con el LSP de contenedor configurado, la entrada A tiene más posibilidades de dividir la carga (incluso de forma incremental, si no completa) en varios LSP. Por lo tanto, es menos probable que LSP desde A vea pérdidas de tráfico prolongadas.
Latency InflationLa inflación de latencia es causada por la conexión automática de banda y otros parámetros 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 se pueden congestionar rutas más cortas entre centros de datos ubicados en la misma ciudad. 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 mediante autowidth de banda, el LSP puede reenrutarse a una ruta de retraso más alta. Cuando muchos LSP se someten a una selección de ruta menos que óptima, pueden formar una cadena de dependencias. Modificar las prioridades del 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 a que el LSP pase a una ruta de latencia más larga. El LSP tiene que atravesar una ruta larga aunque la ruta corta sea capaz de transportar la mayor parte del tráfico.
Ancho de banda mínimo y máximo
Ancho de banda mínimo y máximo, especifique los límites para los tamaños de LSP. Si el ancho de banda mínimo es pequeño, un LSP es más propenso a un ajuste de ancho de banda automático, ya que un pequeño cambio en el ancho de banda es suficiente para cruzar los límites de umbral. Es posible que los LSP se reenrutan aunque el ancho de banda esté disponible. Por otro lado, si el ancho de banda mínimo es grande, es posible que se desabaste 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 aumentar de tamaño. Estos LSP pueden sufrir debido a una política de todo o nada.
Umbral de ajuste de banda ancha automática
El umbral de ancho de banda dicta si es necesario volver a optimizar y cambiar el tamaño de los LSP. Si el valor es pequeño, los LSP se vuelven a optimizar y enrutar con frecuencia. Eso podría causar un pico de CPU, ya que las aplicaciones o protocolos, como el BGP que resuelven 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 LSP de contenedor configurado, es menos probable que un LSP se someta 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ñalan 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 pedidos diferentes en Tabla 3 y Tabla 4. El ERO que usa un LSP depende de su tiempo de señalización.
Tabla 3: Orden de secuencia LSP para previsibilidad Hora
Source
Destino
Demanda
ERO
1
A
E
5
A-C-D-E
2
B
E
5
B-C-E
Tabla 4: Orden de secuencia LSP para previsibilidad Hora
Source
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 EROs predecibles. Si se reenrutan los LSP debido a una política de todo o sin LSP de contenedor configurado, es posible que dichos LSP vean menos rotación 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 solución a los desafíos que enfrentan las funciones actuales de ingeniería de tráfico. Teniendo en cuenta Figura 1que, cuando la demanda X en un LSP de contenedor aumenta con la capacidad de red (flujo máximo) es más que la demanda, los siguientes enfoques entran en vigor con un LSP de contenedor:
- Dar cabida a la nueva demanda X
- Creación de nuevos LSP para satisfacer la demanda X
- Asignación de ancho de banda a los nuevos LSP
- Control de las rutas LSP
Dar cabida a la nueva demanda X
En la implementación actual, la banda automática intenta volver a señalizar 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 activadores 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 en los LSP recién creados.
Creación de nuevos LSP para satisfacer la demanda X
Aunque la cantidad de LSP nuevos creados puede ser un máximo del límite configurable permitido, no hay muchos beneficios de estos LSP una vez que el número de LSP supere la cantidad de posibles rutas diversas o multirutas de igual costo (ECMP). El beneficio de crear los LSP más pequeños se ve cuando un enrutador de entrada utiliza los LSP recién creados para equilibrar el tráfico de carga. Sin embargo, esto depende de la topología y el estado de la red.
La creación de varios LSP paralelos por todos los enrutadores de entrada en la red puede dar lugar a problemas de escalabilidad en los enrutadores de tránsito. Por lo tanto, la cantidad de LSP nuevos 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 determinada. El resultado de un problema de optimización es asignar valores óptimos de ancho de banda. Sin embargo, para resolver un problema de optimización, hay que fijar la cantidad de LSP recién creados. Por lo tanto, es complejo optimizar la cantidad y el tamaño de cada LSP. Por lo tanto, para simplificar el problema, se asume la misma cantidad de ancho de banda para todos los LSP recién creados y, luego, se calcula la cantidad de LSP necesarios.
Control de las rutas 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. El LSP de cada miembro se trata como un LSP de punto a punto y se vuelve a optimizar individualmente. Un enrutador de entrada no intenta calcular las rutas de costo de IGP iguales para todos sus LSP, sino que calcula las rutas de todos los LSP mediante la información actual de base de datos de ingeniería de tráfico. Mientras se calcula una ruta, el enrutamiento basado en restricciones cumple con las restricciones especificadas a través de la configuración, aunque no se produce ningún cambio en el método de enrutamiento basado en restricciones para la computación de rutas.
Cuándo crear un nuevo LSP: cuándo crear un nuevo LSP se puede especificar explícitamente. De forma predeterminada, un enrutador de entrada calcula periódicamente la tasa de tráfico agregada mediante la adición de la velocidad de tráfico de todos los LSP individuales. Al observar el ancho de banda y la configuración agregados, el enrutador de entrada recompone la cantidad de LSP y los anchos de banda de los LSP. Luego, se señalan los nuevos LSP o los LSP existentes se vuelven a señalar con el ancho de banda actualizado. En lugar de mirar la velocidad de agregado instantáneo, 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 activos y excepcionales considerando el ancho de banda agregado es más escalable que crear los nuevos LSP basados en el uso de un LSP en particular. Los intervalos y umbrales se pueden configurar para rastrear el tráfico agregado y el ajuste de activación. Estos LSP dinámicos coexisten e interoperan con la configuración de banda automática por LSP.
Implementación de LSP de contenedor Junos OS
Un LSP de contenedor es un LSP TE ECMP que actúa como un LSP de contenedor que consta de uno o más LSP miembros. Un LSP de TE punto a punto es equivalente a un LSP de contenedor con un LSP de un solo miembro. Los LSP miembros se agregan al LSP de contenedor mediante un proceso llamado división y se eliminan del LSP del contenedor mediante un proceso llamado fusión.
- Terminología LSP de contenedor
- División de LSP
- Fusión de LSP
- Protección de nodos y vínculos
- Convención de nomenclatura
- Normalización
- Computación de ruta de enrutamiento basada en restricciones
- Muestreo
- Compatibilidad con NSR, IPG-FA y rutas estáticas
Terminología LSP de contenedor
Los siguientes términos se definen en el contexto de un LSP de contenedor:
Normalization— Un evento 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 toma de muestras y estima periódicamente el uso agregado de un LSP de contenedor.Nominal LSP: es 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.La conexión automática de banda se ejecuta sobre cada uno de los LSP miembros, y cada LSP se cambia de tamaño según el tráfico que transporta y los parámetros de configuración de banda automática. La demanda agregada de un LSP de contenedor se rastrea agregando el ancho de banda en 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 la banda automática de banda.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 la banda automática de banda.Merging-bandwidth: especifica el umbral de ancho de banda más bajo en el uso de ancho de banda agregado, de modo que, si el uso agregado cae por debajo de este valor, el enrutador de entrada fusiona los LSP miembros en el momento de la normalización.Splitting-bandwidth: especifica el umbral de ancho de banda superior en el uso de ancho de banda agregado, 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 la fusión de los LSP miembros activos actuales. Este ancho de banda mínimo es diferente del ancho de banda mínimo de banda automática.Aggregate maximum-bandwidth— Suma del ancho de banda dividido de los LSP de miembros activos actuales. Este ancho de banda máximo es diferente del ancho de banda máximo de banda automática.
División de LSP
Descripción general operativa
El mecanismo de división de LSP permite que un enrutador de entrada cree nuevos LSP miembros o re-señalizar los LSP existentes con diferentes anchos de banda dentro de un LSP de contenedor cuando se coloca una demanda X en el LSP contenedor. Con la división de LSP habilitada, un enrutador de entrada crea periódicamente una serie de LSP (mediante la señalización de los nuevos o re-señalización de los existentes) para dar cabida a 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 se señala o permanece activo, pero con el ancho de banda reservado antiguo.
Entre dos eventos de normalización (división o fusión), es posible que los LSP individuales se vuelvan a señalizar con diferentes anchos de banda debido a los ajustes de ancho de banda automático. Si un LSP de contenedor no está configurado con autobandwidth, los LSP miembros se señalizarán con el valor de ancho de banda estático, si está configurado. No hay división dinámica en este caso, 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 se admiten en el IGP para esta función.
Entre dos eventos de normalización, dos LSP pueden tener distintos anchos de banda sujetos a restricciones de banda automática.
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 explícito compartido (SE) para esta característica.Cuando los LSP se vuelven a señalizar con anchos de banda modificados, es posible que algunos de los LSP no se señalen correctamente, lo que lleva a opciones de conmutación por error.
Restricciones operativas
La división de LSP tiene las siguientes restricciones operativas:
Ancho de banda del LSP: aunque hay varias formas 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 vuelven a señalizar 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 menos del número mínimo de LSP. En caso de que el enrutador de entrada no pueda hacer un enrutamiento basado en restricciones para cálculos en el número suficiente de LSP o señal suficiente de LSP, el enrutador de entrada recurre a una serie de opciones de conmutación por error.
De forma predeterminada, se admite un enfoque incremental como opción de reserva (a menos que se configure de manera diferente), en la que un enrutador de entrada intenta activar la cantidad suficiente de LSP, de modo que el nuevo ancho de banda agregado supere el ancho de banda agregado antiguo (y esté lo más cerca posible de la demanda deseada). El enrutador de entrada, luego, equilibra la carga del tráfico mediante los LSP. El enrutador de entrada elimina los LSP que no se pudieron crear.
Criterios compatibles
Cuando un LSP de contenedor señala a un LSP miembro, el LSP miembro recibe la señal con un ancho de banda mínimo de señalización. Dado que cada LSP miembro está configurado con autobandwidth, entre dos eventos de normalización, cada LSP puede someterse a un ajuste de banda automática varias veces. A medida que aumenta la demanda de tráfico, el enrutador de entrada crea LSP suplementarios adicionales. Todos los LSP miembros se utilizan para ECMP, por lo que deberían tener aproximadamente el mismo ancho de banda reservado después de la normalización.
Por ejemplo, si hay LSP K señalizado después de la normalización, cada LSP se señala 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 mínimo de señalización es menor o igual que B, que es el turno es menor o igual que el ancho de banda máximo de señalización
(ancho de banda mínimo de señalización ≤ B ≤ ancho de banda máximo de señalización)
Hasta el próximo evento de normalización, el LSP de cada miembro se somete a varios ajustes de banda automática. Después de cualquier ajuste de banda automática, si hay N LSP con anchos de banda reservados bi, donde i=1,2,.., N, cada bi debe cumplir 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 ≤ dos ≤ ancho de banda máximo)
Ambas condiciones son aplicables para LSP por miembro (nominal y complementaria) y, básicamente, tienen el ancho de banda reservado para existir dentro de un rango.
Activadores de división
Cada vez que caduca el temporizador de normalización, el enrutador de entrada decide si es necesario dividir 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 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 LSP miembros N en la red en el momento de la normalización, los dos enfoques para activar la división de LSP son los siguientes:
Desencadenador absoluto: la división de LSP se realiza cuando
New-Aggr-Bwes mayor queAggregate-maximum-bandwidth.(
New-Aggr-Bw>Aggregate-maximum-bandwidth)Activador relativo (Relative Trigger): en la activación relativa, se realiza un cálculo dinámico. Se
Current-Aggr-Bwcompara 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 </= </= 1)Nota:En la condición anterior, "a" es el umbral de ajuste y su valor predeterminado es el 10 por ciento (es decir, 0,10). Puede configurar el umbral de ajuste mediante la
splitting-merging-thresholdinstrucción en el[edit protocols mpls container-label-switched-path lsp-name]nivel de 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 su lugar, dado que se trata de una situación de activación relativa, se realiza la división de LSP. Sin embargo, cuando la división de LSP y la fusión de LSP se configuran 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 operativa
Junos OS admite dos tipos de LSP: LSP configurados por CLI y LSP creados dinámicamente. Los LSP configurados por CLI se crean manualmente y permanecen en el sistema hasta que se modifica la configuración. Los LSP dinámicos se crean dinámicamente mediante MVPN de última generación, servicio LAN privada virtual BGP (VPLS) o LDP, según una configuración de plantilla, y se eliminan del sistema cuando ninguna aplicación no lo usa 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 para que se mantenga menos información de estado en la red. Si un enrutador de entrada proporciona varios LSP miembros entre los enrutadores de entrada y salida, y hay una reducción general del ancho de banda agregado (lo que da como resultado que algunos LSP se infrautilizan), el enrutador de entrada distribuye la nueva carga de tráfico entre menos LSP.
Aunque hay varias maneras de combinar los LSP miembros, Junos OS solo admite la fusió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 la cantidad de LSP que deben estar activos en un dispositivo de enrutamiento de entrada. Como resultado, puede ocurrir lo siguiente periódicamente a medida que se activa el temporizador de normalización:
Re-señalización de algunos de los LSP existentes con un ancho de banda actualizado
Creación de nuevos LSP
Eliminación de algunos de los LSP existentes
Restricciones operativas
Si un LSP de contenedor no está configurado con autobandwidth, los LSP miembros se señalizarán 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 activador 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 hace inactivo, de modo que el tráfico cambia a otros LSP antes de eliminar el LSP. Esto se debe a que RSVP envía PathTear antes de eliminar rutas y los próximos saltos del motor de reenvío de paquetes.
Cuando se vuelven a señalizar los LSP de los miembros con un ancho de banda modificado, puede suceder que algunos LSP no se señalen correctamente.
Fusión de activadores
Cada vez que caduca el temporizador de normalización, el enrutador de entrada decide si es necesaria 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 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 LSP miembros N en la red en el momento de la normalización, los dos enfoques para activar la fusión de LSP son los siguientes:
Desencadenador absoluto: la fusión de LSP se realiza cuando
New-Aggr-Bwes menor queAggregate-minimum-bandwidth.(
New-Aggr-Bw<Aggregate-minimum-bandwidth)Activación relativa:
Current-Aggr-Bwse compara 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 </= </= 1)Nota:En la condición anterior, "a" es el umbral de ajuste y su valor predeterminado es el 10 por ciento (es decir, 0,10). Puede configurar el umbral de ajuste mediante la
splitting-merging-thresholdinstrucción en el[edit protocols mpls container-label-switched-path lsp-name]nivel de 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, elCurrent-Aggr-Bwdispositivo de enrutamiento de entrada no realiza la normalización, sino que se realiza la fusión de LSP. Sin embargo, cuando la división de LSP y la fusión de LSP se configuran 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:
Reenrutamiento rápido
Protección de vínculo
Protección de vínculo de nodo
Solo se puede configurar uno de los modos de protección mencionados anteriormente en un dispositivo de enrutamiento de entrada en cualquier momento dado. Todos los LSP miembros (nominales y suplementarios) 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 complementario 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 la precisión durante el análisis de configuración. El nombre LSP del contenedor debe identificar parámetros de manera única, como los nombres de enrutadores de entrada y salida.
Un LSP miembro de un contenedor LSP y un LSP de 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 de 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 miembros se denominan bob-<configured-suffix>-1, bob-<configured-suffix>-2, ..., y bob-<configured-suffix>-N.
Después de un evento de normalización, la cantidad de LSP miembro puede cambiar. Por ejemplo, si el número de LSP miembros 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ñal.
De manera similar, si el número de LSP miembros se reduce de ocho a seis, el dispositivo de enrutamiento de entrada vuelve a señalr a los LSP miembros de tal manera que los LSP activos restantes del sistema se nombren bob-<configured-suffix>-1, bob-<configured-suffix>-2..., y bob-<configured-suffix>-6.
En el proceso de crear nuevos LSP, se puede configurar un LSP RSVP denominado bob-<configured-suffix>-7 .
Normalización
Descripción general operativa
La normalización es un evento que ocurre periódicamente. Cuando sucede, se toma una decisión sobre la cantidad de LSP miembros que deben permanecer activos y sus respectivos anchos de banda en un LSP de contenedor. Más específicamente, se toma la decisión sobre si se deben crear nuevos LSP suplementarios o si se requiere que cualquier LSP existente se vuelva a señalizar o eliminar durante el evento de normalización.
Entre dos eventos de normalización, un LSP miembro puede someterse a varios ajustes de banda automática. Se configura un temporizador de normalización, similar al temporizador de optimizació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 según eventos de red, como cambios de topología.
Restricciones operativas
La normalización tiene las siguientes restricciones operativas:
La normalización ocurre solo cuando ninguno de los LSP miembros se somete a la optimización o a la conversión antes del descanso. La normalización comienza cuando todos los LSP miembros completan su proceso de operaciones antes del descanso. 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 primero calcula un conjunto de rutas factibles de ancho de banda mediante cálculos de enrutamiento basados en restricciones. Si no se presentan suficientes rutas de enrutamiento computadas basadas en restricciones con un valor de ancho de banda agregado que supere el ancho de banda deseado, se tomarán varias acciones de conmutación por error.
Después de que un conjunto de rutas posibles de ancho de banda estén disponibles, el dispositivo de enrutamiento de entrada señala esas rutas mientras mantiene el conjunto original de rutas con los valores antiguos de ancho de banda. El make-before-break se hace con el estilo de uso compartido explícito (SE), y cuando algunos de los LSP no se vuelven a señalizar correctamente, se intenta un número limitado de reintentos para una duración especificada. Solo cuando todos los LSP se señalan correctamente, el enrutador de entrada cambia de la instancia antigua del LSP del contenedor a la instancia más reciente. Si no se pudo señalizar correctamente todos los LSP, el enrutador de entrada mantiene aquellas instancias de miembros que tienen 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 la señalización de LSP-1 con ancho de banda 2G falla, 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, donde algunos LSP tienen valores de ancho de banda actualizados solo si el ancho de banda agregado ha aumentado. El enrutador de entrada hace un intento de abrir esos LSP que no se pudieron señalizar correctamente, lo que resulta en una pérdida mínima de tráfico.
Si un LSP se cae entre dos eventos de normalización, puede aumentar la carga en otros LSP que están activados. Para evitar el uso excesivo de otros LSP, se puede configurar una normalización anticipada en caso de falla de LSP. Los LSP pueden caer debido a la preconscripción o a la falta de protección de nodos o vínculos. Es posible que no sea necesario activar los LSP que están caídos, ya que el proceso de normalización vuelve a ejecutar los cálculos de ruta de enrutamiento basados en restricciones.
Interoperación con banda ancha automática
Tomando como ejemplo, hay un LSP nominal denominado LSP-1 configurado con los siguientes parámetros:
División del ancho de banda y ancho de banda máximo de señalización de 1G
Fusión de ancho de banda y ancho de banda mínimo de señalización de 0,8G
Conexión de banda automática
La normalización se realiza de manera diferente en los siguientes escenarios:
Cambios en ajustes de banda automática por LSP
Tabla 5 muestra cómo la normalización divide y fusiona los LSP miembros a medida que los ajustes de banda automática cambian por ancho de banda por LSP con normalización incondicional.
Tiempo de normalización |
Estado actual |
Eventos |
Estado ajustado |
|---|---|---|---|
T0 |
Sin estado. |
Inicialización |
LSP-1 se señala con un ancho de banda de 0,8 G |
T1 |
El uso de LSP-1 aumenta a 1,5G |
|
LSP-1 = 0,8 G LSP-2 = 0,8 G |
T2 |
Aumento de 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 la conexión automática de banda está configurada por LSP, cada vez que se realiza un ajuste de banda automática, el enrutador de entrada vuelve a señalr a cada LSP con Max Avg Bw.
Otro enfoque para manejar los cambios en los ajustes de ancho automático de banda por LSP es no permitir que los LSP individuales ejecuten autobandwidth en el enrutador de entrada, sino que se ejecuten autobandwidth en modo pasivo (monitoreo). De esta manera, se toma de muestras en todos los intervalos de estadísticas solo para los LSP miembros, y se normaliza el LSP del contenedor solo, en lugar de actuar sobre la expiración del temporizador de ajuste de los LSP individuales.
Como resultado, se reduce el número de intentos de re-señalización y las fluctuaciones de ancho de banda de un LSP determinado. El enrutador de entrada solo utiliza los valores de ancho de banda computados por miembro para encontrar un ancho de banda agregado que se utilizará durante la normalización. Configurar el ajuste de banda automática seguido de la normalización (los ajustes y los intervalos de normalización son comparables) puede dar lugar a una sobrecarga considerable debido a la re-señalización.
Tomando el mismo ejemplo, y aplicando el segundo enfoque, LSP-1 pasa de 0,8G a 1,5G y luego de vuelta a 0,8G. Si el temporizador de normalización es del mismo orden que el intervalo de ajuste, el enrutador de entrada deja LSP-1 solo con su 0,8G original y solo señala LSP-2 con 0,8G. Esto ayuda a lograr el resultado final de la normalización, evitando así el intento adicional de señalización en LSP-1 con 1.5G al vencimiento del temporizador de ajuste.
Dado que los LSP de los miembros siempre usan el mismo ancho de banda, cualquier ajuste realizado en los LSP miembros se deshace. Los LSP miembros se vuelven a señalizar 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 disparador de ajuste para los LSP miembros puede ser útil si se asume que los intervalos de normalización y ajuste son del mismo orden.
Recomendamos que el temporizador de normalización sea mayor que el intervalo de ajuste de banda automática y 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 de banda ancha automática
Normalización
Cambios en el crecimiento del tráfico
Tabla 6 ilustra cómo se realiza la normalización cuando el tráfico crece en gran factor.
Tiempo de normalización |
Estado actual |
Eventos |
Estado ajustado |
|---|---|---|---|
T0 |
Sin estado |
LSP-1 se señala con un ancho de banda de 0,8 G |
|
T1 |
Aumento del uso de LSP-1 a 3G |
|
LSP-1 = 1G LSP-2 = 1G LSP-3 = 1G |
Se prefiere tener menos LSP en lugar de señalar cuatro LSP con ancho de banda de 0,8G cada uno, a menos que haya una restricción en el número mínimo de LSP.
Rango calculado y rangos factibles configurados
Cuando un enrutador de entrada se configura con el número mínimo y máximo de LSP, y por valores de ancho de banda de división de LSP y ancho de banda de fusión, los umbrales de ancho de banda se utilizan para dividir y fusionar. Para esto, la cantidad de LSP (N) debe satisfacer las siguientes restricciones:
minimum-member-lsps ≤ N ≤ maximum-member-lsps
En el momento de la normalización, según la demanda agregada X:
[X/splitting-bandwidth] ≤ N ≤ [X/merging-bandwidth]
Las restricciones mencionadas proporcionan dos rangos para que N funcione. Si los dos intervalos de N se superponen, N se seleccionará del intervalo de superposición (N más bajo posible) para mantener el número de LSP pequeño en la red.
De lo contrario, si el lsps máximo de miembros es menor que [X/split-ancho de banda], el enrutador de entrada mantiene (como máximo) los lsps máximos de miembros en el sistema, y el ancho de banda de cada LSP es [X/maximum-member-lsps] o el ancho de banda máximo de señalización, el que sea menor. Es posible que algunos LSP no se señalen correctamente.
De manera similar, si los lsps mínimos de miembro es mayor que [X/fusionando-ancho de banda], el enrutador de entrada mantiene (como mínimo) los lsps de miembro mínimo en el sistema, y el ancho de banda de cada LSP es [X/minimum-member-lsps] o el ancho de banda mínimo de señalización, el que sea menor.
Tomando como ejemplo, la normalización se realiza de la siguiente manera en estos casos:
Caso 1
lsps de miembro mínimo = 2
lsps de miembro máximo = 10
demanda agregada = 10 G
fusión de ancho de banda = 1G
división de ancho de banda = 2,5G
En este caso, el dispositivo de enrutamiento de entrada señala a cuatro LSP miembros cada uno con un ancho de banda de 2G.
Caso 2
lsps de miembro mínimo = 5
lsps de miembro máximo = 10
demanda agregada = 10 G
fusión de ancho de banda = 2,5G
división de ancho de banda = 10 G
En este caso, el dispositivo de enrutamiento de entrada señala cinco LSP miembros cada uno con un ancho de banda de 2G. Aquí, la configuración estática en la cantidad de LSP miembro tiene prioridad.
Caso 3
ancho de banda mínimo de señalización = 5G
ancho de banda máximo de señalización = 40G
fusión de ancho de banda = 10 G
división de ancho de banda = 50G
Cuando aparece un LSP de contenedor, el LSP nominal se señala con un ancho de banda mínimo de señalización. En el momento de la normalización, el nuevo agregado de ancho de banda es 100 G. 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 = mín {100/2G, 40G} = 40 G
Esta opción no satisface el nuevo agregado de 100 G.
N = 3, ancho de banda = mín{100/3G, 40G} = 33,3 G
Esta opción hace que el ancho de banda agregado sea igual a 100 G.
En este caso, el dispositivo de enrutamiento de entrada señala tres LSP con un ancho de banda de 33.3G cada uno.
Nota:El enrutador de entrada no indica un LSP más pequeño que el ancho de banda mínimo de señalización.
Computación de ruta de enrutamiento basada en restricciones
Aunque no hay cambios en el cálculo de rutas de enrutamiento general basado 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 basado en restricciones. Cuando se produce la normalización, un enrutador de entrada tiene que calcular las rutas de enrutamiento basadas en restricciones, si es necesario cambiar la cantidad de LSP o el ancho de banda de los LSP.
Por ejemplo, hay LSP K en el enrutador de entrada con valores de ancho de banda X-1, X-2, ..., y X-K. El valor de ancho de banda agregado actual 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 solo necesita N LSP (LSP-1, LSP-2, .., y LSP-N) cada uno con valor de ancho de banda B, la tarea del módulo de enrutamiento basado en restricciones es proporcionar un conjunto de LSP factibles de ancho de banda que puedan adaptarse a la nueva demanda agregada que no es menor que Y.
Luego, el enrutador de entrada intenta ver si las rutas de enrutamiento basadas en restricciones se pueden calcular correctamente para todos los LSP N. Si las rutas de 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 de 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 de incremento esté configurada o no, si no se pudieron calcular las rutas de enrutamiento basadas en restricciones para un número suficiente de LSP, el enrutador de entrada tiene que repetir el proceso de encontrar un nuevo conjunto de LSP. Inicialmente, el enrutador de entrada comienza con el valor más bajo de N de la región posible. 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 se vuelve menor y, por lo tanto, hay una mayor probabilidad de que la señalización sea exitosa. El proceso se repite para todos los valores posibles de N (o algún número limitado de veces o duración según la configuración).
El enrutador de entrada envía señales a los LSP después de cálculos exitosos de la computación de ruta de enrutamiento basada en restricciones. Puede suceder que cuando se señalan los LSP, la señalización de muchos LSP falla. Además de los cálculos de rutas de enrutamiento basados en restricciones para tener éxito, la señalización RSVP también debe tener éxito, de modo que el nuevo agregado no sea menor que el ancho de banda de agregado antiguo.
Muestreo
El muestreo es importante para que la normalización funcione. Con la toma de muestras configurada, 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 muestras, 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 toma de muestras es diferente de los muestreos estadísticos que se realizan 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 cualquier ejemplo atípico, se configura un token de muestra. En otras palabras, de todas las muestras agregadas recopiladas durante el tiempo configurado, se ignoran los valores atípicos inferiores y superiores antes de calcular una medida estadística a partir de las muestras restantes.
Se admiten los dos métodos siguientes para calcular un valor agregado de ancho de banda:
Promedio: el dispositivo de enrutamiento de entrada considera todas las muestras de ancho de banda agregadas y, luego, se eliminan todos los ejemplos atípicos. El valor promedio del ancho de banda se calcula a partir del resto de los ejemplos que se usarán durante la normalización.
Máximo: el dispositivo de enrutamiento de entrada considera todos los ejemplos agregados de ancho de banda y, a continuación, se eliminan todos los ejemplos atípicos. El valor máximo de ancho de banda se elige de los ejemplos restantes que se usarán durante la normalización.
La duración del tiempo, la cantidad de muestras agregadas pasadas para almacenar, el valor del percentil que se va a determinar y los valores atípicos de ignorar son parámetros configurables por el usuario.
Compatibilidad con NSR, IPG-FA y rutas estáticas
A partir de la versión 15.1 de Junos OS, las rutas conmutadas por etiquetas de contenedor (LSP) proporcionan soporte para el enrutamiento activo (NSR) sin interrupciones, el reenvío de IGP (FA) y rutas estáticas para abordar los requisitos de casos empresariales más amplios.
Soporte de NSR
Un LSP de contenedor tiene las características de la ingeniería de tráfico ECMP y RSVP. Dado que un LSP contenedor consta de varios LSP miembros entre un enrutador de entrada y un enrutador de salida, con cada LSP miembro tomando una ruta diferente al mismo destino, el enrutador de entrada está configurado 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 respaldo para permitir la compatibilidad con el enrutamiento activo sin interrupciones (NSR) para LSP de contenedor. Aunque parte de la información de estado de reenvío en el motor de enrutamiento de copia de seguridad 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 de contenedor se crean dinámicamente mediante los estados replicados en el motor de enrutamiento de respaldo.
De forma predeterminada, la normalización ocurre una vez cada 6 horas y durante este tiempo, se producen una serie de ajustes de banda automática en cada LSP miembro. Un LSP miembro cambia el tamaño según el tráfico que transporta y los parámetros de configuración de banda automática configurados. La demanda agregada en un LSP de contenedor se rastrea mediante la suma del ancho de banda en todos los LSP miembros.
Para los LSP punto a punto de RSVP, una conmutación del motor de enrutamiento puede realizarse en cualquiera de los siguientes casos:
Steady state
En el estado estacionario, el estado LSP está activo y reenvía el tráfico; sin embargo, no se produce ningún otro evento, como el make-before-break (MBB) en el LSP. En esta etapa, el RPD se ejecuta en los motores de enrutamiento, y el evento de conmutación se alterna entre el motor de enrutamiento principal y el motor de enrutamiento de respaldo. El motor de enrutamiento de respaldo ya tiene la información del LSP replicada. Después de la conmutación, el nuevo principal usa la información de la estructura replicada para construir el LSP de contenedor y en-cola la ruta (ERO) de LSP en el modo de retrascamiento. Señales RSVP y comprueba si la ruta mencionada en la ERO es accesible. Si las comprobaciones RSVP fallan, el LSP se reinicia. 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 de manera 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, se comprueba la ruta para averiguar dónde está la ruta en el proceso MBB. Si la ruta se encuentra en medio del proceso MBB, con la instancia principal caída y la ruta optimizada, MBB puede pasar 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 miembros durante la optimización del ancho de banda.
Una conmutación del motor de enrutamiento en estado estable (cuando la normalización no está en curso), mantiene los LSP del contenedor en funcionamiento sin pérdida de tráfico. Los eventos, como un MBB debido a ajustes de banda automática, estado del vínculo caído o falla doble en el estado estacionario, son similares a los de 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 ninguno de los casos, no se garantiza una pérdida de tráfico de cero por ciento.
Normalización en la fase de computación
Durante la fase de computación, el motor de enrutamiento principal calcula el número de LSP y el ancho de banda con el que se debe volver a señalizar la LSP de cada miembro. El motor de enrutamiento de respaldo 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 reintento de normalización. Si el cambio se produce durante la fase de computación, el motor de enrutamiento de respaldo no conoce el recuento de LSP de los miembros de destino y el ancho de banda que se va a señalizar. Dado que las estadísticas de tráfico no se copian en el motor de enrutamiento de respaldo, no puede calcular el número de miembros y el ancho de banda de destino. En este caso, el nuevo motor de enrutamiento principal utiliza los datos antiguos almacenados en el recuento de LSP de miembros de destino y el ancho de banda objetivo para señalar a 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 a los LSP con el ancho de banda recién calculado. Si el cambio se produce durante la señalización de los 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 número de miembros objetivo y el valor de ancho de banda con el que se va a señalar, para activar los LSP.
Soporte de IPG-FA
Una adyacencia de reenvío (FA) es una ruta de conmutación de etiquetas (LSP) de ingeniería de tráfico que se configura entre dos nodos y que un protocolo de puerta de enlace interior (IGP) utiliza para reenviar tráfico. De forma predeterminada, un IGP no considera los 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 de 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 de 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:
IS-IS
[edit]
protocols {
isis {
label-switched-path container-lsp-name;
}
}
Ruta de acceso abierta más corta primero (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 regulares de punto a punto. Si un LSP de contenedor y un LSP de punto a punto comparten el mismo nombre, se da preferencia al LSP de punto a punto por la FA.
Soporte para rutas estáticas
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 políticas y otros protocolos.
Para anunciar un LSP de contenedor como una ruta estática, el nombre de 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 de ruta estática se aplica tanto a los LSP de contenedor como a los LSP de punto a punto regulares. Si un LSP de contenedor y un LSP de punto a punto comparten el mismo nombre, se da preferencia al LSP de punto a punto para el enrutamiento estático.
Instrucciones de configuración compatibles con LSP de contenedor
Tabla 7 enumera las instrucciones de configuración de LSP MPLS que se aplican a LSP RSVP y un LSP de contenedor (nominal y suplementario).
La compatibilidad de configuración se define mediante los siguientes términos:
Sí: la instrucción de configuración se admite para 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 se aplica a este tipo de LSP.
Instrucción de configuración |
LSP RSVP (entrada) |
LSP miembro (entrada) |
|---|---|---|
Adaptación (Por defecto: no adaptable) |
Sí |
Sí |
admin-down |
Sí |
Sí |
admin-group |
Sí |
Sí |
admin-groups, excepto |
Sí |
Sí |
grupos de aplicación |
Sí |
Sí |
grupos de aplicación, excepto |
Sí |
Sí |
associate-backup-pe-groups |
Sí |
No |
associate-lsp (Sin soporte bidireccional) |
Sí |
No |
ancho de banda automático |
Sí |
Sí |
copia de seguridad |
Sí |
No |
Banda |
Sí |
Sí |
clase de servicio |
Sí |
Sí |
bidireccional (Sin soporte bidireccional) |
Sí |
No |
bidireccional-pasiva (Sin soporte bidireccional) |
Sí |
No |
Descripción |
Sí |
Sí |
disable |
Sí |
Sí |
Protección de salida |
Sí |
No |
excluir-srlg |
Sí |
Sí |
reenrutamiento rápido (El mismo reenrutamiento rápido para todos los LSP miembros) |
Sí |
Sí |
De |
Sí |
Sí |
límite de saltos |
Sí |
Sí |
Instalar |
Sí |
Sí |
entre dominios (Mismo enrutador de terminación) |
Sí |
Sí |
secundario (Todos los LSP son principales) |
Sí |
No |
ldp-tunelización (Todos los LSP hacen tunelización) |
Sí |
Sí |
menor cantidad de relleno |
Sí |
Sí |
protección de vínculos (Todos los LSP comparten el mismo mecansim de protección de vínculos) |
Sí |
Sí |
lsp-attributes |
Sí |
Sí |
controlador externo lsp |
Sí |
No |
Métricas (Todos los LSP son los mismos) |
Sí |
Sí |
mayor cantidad de datos |
Sí |
Sí |
sin cspf (Los LSP usan IGP) |
Sí |
Sí |
sin decrement-ttl (Todos los LSP comparten el mismo comportamiento TTL) |
Sí |
Sí |
sin instalación a dirección |
Sí |
Sí |
sin registro |
Sí |
Sí |
protección de vínculos de nodos (Los LSP al comparten el mismo mecanismo de protección de vínculos de nodo) |
Sí |
Sí |
Oam |
Sí |
Sí |
optimizar-espera-retrasos (Todos los LSP tienen el mismo valor) |
Sí |
Sí |
optimizar el cambio y el 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 principales) |
Sí |
No |
Aleatorio |
Sí |
Sí |
grabar |
Sí |
Sí |
límite de reintentos (Aplicable a los miembros) |
Sí |
Sí |
temporizador de reintentos (Aplicable a los miembros) |
Sí |
Sí |
temporizador de reversión (Sin LSP secundario) |
Sí |
No |
secundario (Todos los LSP son principales) |
Sí |
No |
preferencia por software |
Sí |
Sí |
Espera (Todos los LSP están en espera) |
Sí |
No |
Plantilla |
Sí |
No |
Para |
Sí |
Sí |
evaluaciones de seguimiento |
Sí |
Sí |
lo mejor en saltos emergentes |
Sí |
Sí |
Impacto de la configuración de LSP de contenedor en el rendimiento de la red
Un LSP de contenedor es un LSP contenedor que permite que varios LSP miembros coexisten y se administren como un paquete. Los LSP miembros son similares a los LSP de punto a punto RSVP independientes. Como resultado, el consumo de recursos es similar a la suma de recursos consumidos por cada LSP de RSVP punto a punto. Sin embargo, aprovisionar un LSP de contenedor es más eficiente, ya que los LSP de los miembros infrautilizados se eliminan dinámicamente, lo que ahorra recursos de memoria y CPU.
Las funciones de LSP de contenedor dependen de la presencia de una implementación de RSVP de MPLS 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 base de MPLS RSVP. Las categorías de posibles ataques y contramedidas son las siguientes:
Interacción con los procesos y la configuración del enrutador
No se requieren mecanismos de comunicación nuevos 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, a excepción de la adyacencia vecina de 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 señalizadas de MPLS de RSVP dependen de los servicios de RSVP e IGP para comunicar mensajes de RSVP entre enrutadores vecinos en toda la red. Dado 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 rutas, y ataques al transporte TCP/UDP subyacente para las 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 agentes de policía y filtros para proteger contra ataques de denegación de servicio basados en inyectar mayores que las demandas de tráfico esperadas. En el nivel de LSP de MPLS, Junos OS permite a los operadores configurar límites en el ancho de banda del LSP y la cantidad de LSP. Sin embargo, al igual que los LSP RSVP punto a punto, los LSP de contenedor no aplican límites al volumen de tráfico reenviado a través de estos LSP.
Funciones compatibles 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
División y fusión de LSP basada en ancho de banda agregado de una forma de hacer antes de la interrupción
Mecanismo de nomenclatura basado en números de LSP para LSP miembros creados dinámicamente
Mecanismos de toma de muestras periódicas para estimar el ancho de banda agregado
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
Configurar LSP de contenedor mediante accesos directos de IGP
Enlaces Ethernet agregados
Sistemas lógicos
Junos OS admite not la siguiente funcionalidad LSP de contenedor:
Rutas disociadas de nodos y vínculos para diferentes LSP entre un dispositivo de enrutamiento de entrada y un dispositivo de enrutamiento de salida
Política de asignación de ancho de banda diferente a la política de ancho de banda igual en el evento de normalización
Computación de rutas de enrutamiento basada en restricciones para encontrar rutas de costo IGP iguales para los LSP diferentes
Objetos RSVP, como
MLSP_TUNNEL Sender Template, yMLSP_TUNNEL Filter Specificationdefinidos en [KOMPELLA-MLSP]Cambio en la topología como desencadenador para la división y fusión de LSP
Cambio en la topología y error de vínculo como activador para la normalización, a menos que los LSP miembros no
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 con LSP de contenedor
Rutas secundarias para LSP de contenedor
LSP de contenedor bidireccional
Policía
Rutas estáticas que utilizan LSP de contenedor como próximos saltos con el mejor esfuerzo
Entidad de computación 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 conmutadas por etiquetas de contenedor (LSP) que permiten el equilibrio de carga en varios LSP de miembros 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, MX o T, de los cuales dos enrutadores son enrutadores de borde de proveedor (PE) y tres enrutadores son enrutadores de proveedor (P)
-
Junos OS versión 14.2 o posterior se ejecuta en todos los enrutadores
Antes de empezar:
-
Configure las interfaces del dispositivo.
-
Configure los números de sistema autónomo y los identificaciones de enrutador para los dispositivos.
-
Configure los siguientes protocolos:
-
RSVP
-
MPLS
-
BGP
-
OSPF
-
Descripción general
A partir de Junos OS versión 14.2, se introduce un nuevo tipo de LSP, llamado LSP de contenedor, para permitir el equilibrio de carga en varios LSP punto a punto. Un LSP de contenedor incluye uno o más LSP miembros entre los mismos dispositivos de enrutamiento de entrada y salida. Los LSP miembros son similares a los LSP de punto a punto independientes, y cada LSP miembro toma una ruta diferente al mismo destino y se puede enrutar a lo largo de una ruta de costo IGP diferente.
Un LSP de contenedor proporciona soporte para la administración dinámica del ancho de banda al permitir que el enrutador de entrada agregue y elimine LSP de forma dinámica mediante un proceso llamado división de LSP y fusión de LSP, respectivamente, en función de la configuración y el agregado de tráfico. Además de la adición y eliminación, los LSP de los miembros también se pueden volver a optimizar con diferentes valores de ancho de banda de una manera 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 de núcleo, P1 y P2, y P3 se conectan a los enrutadores de 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 y, luego, ingrese commit desde el [edit] 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 siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración en la Guía del usuario de 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 de 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 política para equilibrar la carga del tráfico.
[edit routing-options] user@PE1# set forwarding-table export pplb
-
Habilite 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 de estadísticas 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 la 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 locales y vecinas.
[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 el OSPF en todas las interfaces del enrutador PE1 (excluyendo la interfaz de administración) junto con 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 política para equilibrar el tráfico de carga.
[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 de etiqueta de la tabla vrf, destino y destino de ruta 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, ingrese los comandos , show routing-options, show protocols, show policy-optionsy 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 funciona correctamente.
- Verificar el estado del LSP del contenedor sin ancho de banda
- Verificar el estado del LSP del contenedor con un mayor ancho de banda (antes de la normalización)
- Verificar el estado del LSP del contenedor con un mayor ancho de banda (después de la normalización)
- Verificar el proceso de división de LSP del contenedor
- Verificar las estadísticas de LSP del contenedor
- Verificar el estado del LSP del contenedor con un ancho de banda reducido (antes de la normalización)
- Verificar el estado del LSP del contenedor con un ancho de banda reducido (después de la normalización)
- Verificar el proceso de fusión de LSP de contenedor
- Verificar la normalización de la conmutación por error
- Verificar la normalización incremental
Verificar el 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 de contenedor se establece entre los enrutadores PE1 y PE2.
Verificar el estado del LSP del contenedor con un mayor ancho de banda (antes de la normalización)
Propósito
Verifique el estado del LSP del contenedor con mayor ancho de banda antes de que ocurra 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 la normalización no ha ocurrido, el recuento de LSP de miembros se mantiene en 2.
Verificar el estado del LSP del contenedor con un mayor ancho de banda (después de la normalización)
Propósito
Verifique el estado del LSP del contenedor con un mayor ancho de banda después de que ocurra 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 vencimiento del temporizador de normalización, el LSP del contenedor se divide en cinco LSP miembros, cada uno con 10 Mbps (ancho de banda mínimo y máximo de señalización). Como resultado, el ancho de banda agregado es de 50 Mbps.
Verificar el proceso de división de LSP del contenedor
Propósito
Verifique el proceso de división de LSP del contenedor después de que ocurra 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 inyectó la adyacencia de reenvío.
Verificar las estadísticas de LSP del contenedor
Propósito
Verifique las estadísticas de LSP del contenedor después de 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 miembros recién creados.
Verificar el estado del LSP del contenedor con un ancho de banda reducido (antes de la normalización)
Propósito
Verifique el estado del LSP del contenedor con un ancho de banda reducido 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
Dado que la normalización no ha ocurrido, el recuento de LSP de miembros permanece en 5.
Verificar el estado del LSP del contenedor con un ancho de banda reducido (después de la normalización)
Propósito
Verifique el estado del LSP del contenedor con un ancho de banda reducido 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 vencimiento del temporizador de normalización, la fusión del LSP del contenedor se lleva a cabo porque hay una reducción general del ancho de banda. Los LSP de miembro se fusionan y el recuento de LSP miembro es 2 después de la normalización.
Verificar el proceso de fusión de LSP de contenedor
Propósito
Verifique el proceso de división de LSP del contenedor después de que ocurra 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 fusionados.
Verificar la normalización de la conmutación por error
Propósito
Verifique la redistribución de carga cuando se envía tráfico a 35 Mbps y el vínculo entre los enrutadores P1 y P2 está deshabilitado. La llegada de PathErr al error del vínculo desencadena una normalización inmediata.
Para habilitar la normalización de la conmutación por error, incluya la failover-normalization instrucción de configuración en el [edit protocols mpls container-label-switched-path container-lsp-name splitting-merging normalization] nivel de 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 se cae, la normalización se activa de inmediato.
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 de PathErr al error del vínculo desencadena la normalización inmediata.
Verificar la normalización incremental
Propósito
Verifique 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 uno.
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 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 el equilibrio de carga en varios LSP punto a punto dinámicamente. Un LSP de contenedor incluye uno o más LSP miembros entre los mismos dispositivos de enrutamiento de entrada y salida. Los LSP miembros son similares a los LSP de punto a punto independientes, y cada LSP miembro toma una ruta diferente al mismo destino y se puede enrutar a lo largo de una ruta de costo IGP diferente.
Un LSP de contenedor proporciona soporte para la administración dinámica del ancho de banda al permitir que el enrutador de entrada agregue y elimine LSP de forma dinámica mediante un proceso llamado división de LSP y fusión de LSP, respectivamente, en función de la configuración y el agregado de tráfico. Además de la adición y eliminación, los LSP de los miembros también se pueden volver a optimizar con diferentes valores de ancho de banda de una manera 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 siguientes protocolos:
RSVP
BGP
Configure un grupo de BGP para emparejar el dispositivo con el dispositivo de borde de proveedor remoto (PE).
OSPF
Habilite capacidades de ingeniería de tráfico.
Configure una instancia de enrutamiento VRF.
Para configurar el dispositivo PE: