Primero, agrego esta pregunta y me respondo porque este tipo de comportamiento no estaba en ningún lugar, espero que ayude a alguien.
Problema:
Utilizamos el ancho de banda automático para manejar las suscripciones de ancho de banda para nuestros LSP. Los LSP tienen el mismo costo y aparecen en nuestras tablas de reenvío / enrutamiento de manera apropiada como los próximos saltos disponibles para cada destino.
Sin embargo, para un solo destino, los 4 LSP de igual costo no están equilibrando la carga por igual (o incluso cerca de la misma). Entendemos que JUNOS utiliza un algoritmo de equilibrio de carga por flujo a pesar de la declaración "por paquete" en la política para habilitar el equilibrio de carga. Pero eso no explica la gran diferencia entre cada suscripción para el LSP (este desequilibrio de suscripción ocurre varias veces al día, no es una ocurrencia única), así:
jhead@R1> show route protocol rsvp 1.1.1.1 detail
1.1.1.1/32 (2 entries, 1 announced)
State: <FlashAll>
*RSVP Preference: 7/1
Next hop: 192.168.1.1 via xe-0/0/0.0 weight 0x1 balance 35%, selected
Label-switched-path LSP1
Next hop: 192.168.1.2 via xe-1/0/0.0 weight 0x1 balance 35%
Label-switched-path LSP2
Next hop: 192.168.1.3 via xe-0/0/1.0 weight 0x1 balance 26%
Label-switched-path LSP3
Next hop: 192.168.1.4 via xe-0/0/0.0 weight 0x1 balance 5%
Label-switched-path LSP4
R1-R4 son MX480 y CORE-R1-R4 son MX960.
A continuación hay gráficos que comparan la suscripción de RSVP y la utilización del LSP. El rojo es suscripción, el verde es utilización. Puede ver que la utilización sigue la reserva casi exactamente durante todo el día. Nosotros deberíamos ver suscripciones ser muy cerca uno del otro entre los LSP hacia el mismo destino.
Topología:
R1 - R4 son enrutadores de entrada para todos los LSP, tienen 2 o 4 LSP hacia cada enrutador central.
Configuración:
La configuración de LSP es un único destino desde R1, solo como un ejemplo. Todos los LSP están configurados exactamente de la misma manera (de nuevo, con 2 o 4).
[edit protocols mpls]
statistics {
file mpls-stats;
interval 300;
auto-bandwidth;
}
traffic-engineering bgp;
label-switched-path LSP1 {
to 1.1.1.1;
optimize-timer 300;
auto-bandwidth {
adjust-interval 7200;
adjust-threshold 10;
minimum-bandwidth 100m;
maximum-bandwidth 4g;
adjust-threshold-overflow-limit 2;
adjust-threshold-underflow-limit 4;
}
primary primary-loose;
}
label-switched-path LSP2 {
to 1.1.1.1;
optimize-timer 300;
auto-bandwidth {
adjust-interval 7200;
adjust-threshold 10;
minimum-bandwidth 100m;
maximum-bandwidth 4g;
adjust-threshold-overflow-limit 2;
adjust-threshold-underflow-limit 4;
}
primary primary-loose;
}
label-switched-path LSP3 {
to 1.1.1.1;
optimize-timer 300;
auto-bandwidth {
adjust-interval 7200;
adjust-threshold 10;
minimum-bandwidth 100m;
maximum-bandwidth 4g;
adjust-threshold-overflow-limit 2;
adjust-threshold-underflow-limit 4;
}
primary primary-loose;
}
label-switched-path LSP4 {
to 1.1.1.1;
optimize-timer 300;
auto-bandwidth {
adjust-interval 7200;
adjust-threshold 10;
minimum-bandwidth 100m;
maximum-bandwidth 4g;
adjust-threshold-overflow-limit 2;
adjust-threshold-underflow-limit 4;
}
primary primary-loose;
}
[edit protocols rsvp]
load-balance bandwidth
interface xe-0/0/0.0 {
bandwidth 9g;
}
interface xe-0/0/1.0 {
bandwidth 9g;
}
interface xe-1/0/0.0 {
bandwidth 9g;
}
[edit routing-options forwarding-table]
export load-balance;
fuente
Respuestas:
El problema es el:
Si mira la documentación de Juniper para LSP de RSVP de equilibrio de carga de costo desigual , dice:
Esto implica que, independientemente de que se configure esa característica, no se producirá un equilibrio de carga de costo igual si no establece estáticamente un valor de ancho de banda en un LSP individual, de esta manera:
Sin embargo, el ancho de banda automático sí cuenta como establecer un valor de ancho de banda, a pesar de que no está presente en la configuración.
Cuando el ancho de banda automático está habilitado, RPD comenzará a monitorear el consumo de ancho de banda. Asignará valores de ancho de banda en función de la utilización, y luego la declaración de "ancho de banda de equilibrio de carga" en RSVP comenzará inmediatamente a intentar mantener las relaciones de tráfico dentro de esas suscripciones (35, 35, 26, 5 respectivamente). El problema con esto es que nunca le da al ancho de banda automático la oportunidad de ajustarse de manera uniforme, porque el objetivo del "ancho de banda de equilibrio de carga" es mantener el tráfico lo más cerca posible de esas relaciones. Esto tiene sentido cuando tienen un conjunto de 10, 30, 20, 40.
Es esencialmente una condición de carrera entre "ancho de banda de equilibrio de carga" y "ancho de banda automático"
Después de quitar:
[editar protocolos rsvp] ancho de banda de equilibrio de carga
Tráfico ajustado (con un ligero hipo, como se ve a continuación):
NOTA: Este es un ejemplo de un enrutador diferente que se vio afectado por el mismo problema.
Como elimina la capacidad de equilibrio de carga (para RSVP), el PFE se reprogramará en una sola ruta hasta que se produzca un ajuste automático del ancho de banda, o puede forzar un ajuste:
Y a continuación, si el ancho de banda se ajusta para 2 LSP con los mismos síntomas, las configuraciones cambian y los ajustes ocurrieron a medio día del viernes, puede ver lo diferente en las suscripciones casi de inmediato.
fuente
"Entendemos que JUNOS utiliza un algoritmo de equilibrio de carga por flujo a pesar de la declaración" por paquete "en la política para habilitar el equilibrio de carga"
Descubrí que esa declaración es bastante cierta cuando se usa iperf para probar algunos escenarios de equilibrio de carga. Con una sola sesión de iperf, el tráfico no tiene carga equilibrada, pero cuando se habilitan las sesiones paralelas de iperf, el tráfico se equilibra con la carga.
¡Aunque la documentación de Juniper sugiere lo contrario! http://www.juniper.net/documentation/en_US/junos13.2/topics/usage-guidelines/mpls-configuring-load-balancing-across-rsvp-lsps.html
Me pregunto si lo anterior es aplicable a partir de JUNOS13.2
fuente