Warum sind meine LSPs mit gleichen Kosten bei Verwendung der automatischen Bandbreite nicht gleichmäßig verteilt?

Zuerst füge ich diese Frage hinzu und beantworte mich selbst, weil diese Art von Verhalten absolut nicht zu finden war, hoffentlich hilft es jemandem.

Problem:

Wir verwenden die automatische Bandbreite, um die Bandbreitenabonnements für unsere LSPs zu verwalten. Die LSPs sind gleich teuer und werden in unseren Weiterleitungs- / Routing-Tabellen entsprechend als verfügbare nächste Hops für jedes Ziel angezeigt.

Für ein einzelnes Ziel sind die 4 LSPs mit gleichen Kosten jedoch nicht gleich (oder sogar nahezu gleich). Wir wissen, dass JUNOS trotz der Anweisung "pro Paket" in der Richtlinie einen Lastausgleichsalgorithmus pro Fluss verwendet, um den Lastausgleich zu ermöglichen. Dies erklärt jedoch nicht den Hauptunterschied zwischen den einzelnen Abonnements für den LSP (dieses Ungleichgewicht bei den Abonnements tritt mehrmals pro Tag auf, es handelt sich nicht um ein einmaliges Ereignis).

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 sind MX480 und CORE-R1-R4 sind MX960.

Unten finden Sie Diagramme, in denen das RSVP-Abonnement und die Nutzung des LSP verglichen werden. Rot ist Abonnement, Grün ist Nutzung. Sie können sehen, dass die Nutzung der Reservierung fast genau den ganzen Tag folgt. Wir sollten sehen, dass Abonnements zwischen den LSPs in Richtung desselben Ziels sehr nahe beieinander liegen.

Topologie:

R1 - R4 sind Ingress-Router für alle LSPs. Sie haben entweder 2 oder 4 LSPs für jeden Core-Router.

Aufbau:

Die LSP-Konfiguration ist nur als Beispiel ein einzelnes Ziel von R1. Alle LSPs sind genau gleich konfiguriert (wiederum mit 2 oder 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;

Das Problem ist das:

[edit protocols rsvp]
load-balance bandwidth

Wenn Sie sich die Juniper-Dokumentation für RSVP-LSPs mit ungleichem Kostenausgleich ansehen , heißt es:

Damit ein ungleichmäßiger Lastausgleich unter Verwendung der Bandbreite funktioniert, müssen mindestens zwei LSPs mit gleichen Kosten für denselben Ausgangsrouter vorhanden sein, und mindestens einer der LSPs muss einen Bandbreitenwert haben, der unter [edit protocol mpls label-switch-path lsp- Pfadname] Hierarchieebene. Wenn für keine LSPs die Bandbreite konfiguriert ist, wird ein Lastausgleich mit gleicher Verteilung durchgeführt. Wenn nur für einige LSPs die Bandbreite konfiguriert ist, empfangen die LSPs ohne konfigurierte Bandbreite keinen Datenverkehr.

Dies bedeutet, dass unabhängig von der konfigurierten Funktion kein Lastausgleich bei gleichen Kosten erfolgt, wenn Sie für einen einzelnen LSP keinen statischen Bandbreitenwert festlegen, wie z.

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

Die automatische Bandbreite zählt jedoch tatsächlich als Festlegen eines Bandbreitenwerts, obwohl dieser in der Konfiguration nicht vorhanden ist.

Wenn die automatische Bandbreite aktiviert ist, beginnt RPD mit der Überwachung des Bandbreitenverbrauchs. Es werden Bandbreitenwerte basierend auf der Auslastung zugewiesen, und dann wird die Anweisung "Lastausgleichsbandbreite" in RSVP sofort versuchen, die Verkehrsverhältnisse innerhalb dieser Abonnements zu halten (35, 35, 26, 5). Das Problem dabei ist, dass die automatische Bandbreite niemals die Möglichkeit hat, sich gleichmäßig anzupassen, da das Ziel der "Lastausgleichsbandbreite" darin besteht, den Datenverkehr so ​​nahe wie möglich an diesen Verhältnissen zu halten. Dies ist sinnvoll, wenn sie auf 10, 30, 20, 40 eingestellt sind.

Es ist im Wesentlichen eine Wettlaufbedingung zwischen "Lastausgleichsbandbreite" und "Auto-Bandbreite".

Nach dem Entfernen:

[Protokolle bearbeiten rsvp] Lastausgleichsbandbreite

Verkehr angepasst (mit leichtem Schluckauf, siehe unten):

HINWEIS: Dies ist ein Beispiel von einem anderen Router, der von demselben Problem betroffen war.

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

Da Sie die Möglichkeit des Lastausgleichs (für RSVP) entfernen, wird das PFE nur auf einen einzelnen Pfad neu programmiert, bis eine automatische Bandbreitenanpassung automatisch erfolgt, oder Sie können eine Anpassung erzwingen:

request mpls lsp adjust-autobandwidth

Und unten sind die Bandbreitenanpassungen für 2 LSPs mit den gleichen Symptomen aufgeführt, die Konfigurationen wurden geändert und die Anpassungen erfolgten am Freitagmittag. Sie können die Unterschiede in den Abonnements fast sofort erkennen.

"Wir verstehen, dass JUNOS trotz der Anweisung" pro Paket "in der Richtlinie einen Lastausgleichsalgorithmus pro Fluss verwendet, um den Lastausgleich zu ermöglichen."

Diese Aussage hat sich als richtig erwiesen, wenn iperf zum Testen einiger Lastausgleichsszenarien verwendet wurde. Bei einer einzelnen iperf-Sitzung wird der Datenverkehr überhaupt nicht ausgeglichen. Wenn Sie jedoch parallele iperf-Sitzungen aktivieren, wird der Datenverkehr lastausgeglichen.

Obwohl die Juniper-Dokumentation etwas anderes vorschlägt! http://www.juniper.net/documentation/en_US/junos13.2/topics/usage-guidelines/mpls-configuring-load-balancing-across-rsvp-lsps.html

Ich frage mich, ob das oben Gesagte ab JUNOS13.2 anwendbar ist