¿Por qué mis LSP de igual costo no equilibran la carga por igual cuando uso el ancho de banda automático?

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;

El problema es el:

[edit protocols rsvp]
load-balance bandwidth

Si mira la documentación de Juniper para LSP de RSVP de equilibrio de carga de costo desigual , dice:

Para que el equilibrio de carga desigual utilice el ancho de banda para trabajar, debe tener al menos dos LSP de igual costo hacia el mismo enrutador de salida y al menos uno de los LSP debe tener un valor de ancho de banda configurado en [editar protocolos mpls etiqueta-ruta-conmutada lsp- nombre de ruta] nivel de jerarquía. Si ningún LSP tiene ancho de banda configurado, se realiza un equilibrio de carga de distribución igual. Si solo algunos LSP tienen ancho de banda configurado, los LSP sin ancho de banda configurado no recibirán ningún tráfico.

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:

[edit protocols mpls label-switched-path LSP1]
bandwidth 2g

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.

jhead@R1> show log mpls-stats

LSP1 (LSP ID 3388, Tunnel ID 2646)    177150801 pkt   155450491134 Byte 178572 pps 152286259 Bps Util 228.46% Reserved Bw 66660264 Bps
LSP2 (LSP ID 3393, Tunnel ID 2647)            0 pkt              0 Byte      0 pps        0 Bps Util  0.00% Reserved Bw 116698880 Bps

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:

request mpls lsp adjust-autobandwidth

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.

"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