自動帯域幅を使用すると、等コストLSPが均等にロードバランシングされないのはなぜですか？

最初に、このタイプの動作はどこにも見当たらないため、この質問を追加して自分で答えます。うまくいけば、誰かの役に立つと思います。

問題：

自動帯域幅を使用して、LSPの帯域幅サブスクリプションを処理します。LSPは同等のコストであり、各宛先の利用可能なネクストホップとして転送/ルーティングテーブルに適切に表示されます。

ただし、単一の宛先の場合、4つの等コストLSPは均等に（または均等に近くても）ロードバランシングを行いません。JUNOSは、ロードバランシングを有効にするポリシーの「per-packet」というステートメントにもかかわらず、フローごとのロードバランシングアルゴリズムを使用することを理解しています。しかし、これはLSPの各サブスクリプション間の主な違いを説明していません（このサブスクリプションの不均衡は1日に複数回発生し、1回限りの発生ではありません）。

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はMX480で、CORE-R1-R4はMX960です。

以下は、RSVPサブスクリプションとLSPの使用率を比較したグラフです。赤はサブスクリプション、緑は使用率です。使用率は1日を通してほぼ正確に予約に従っていることがわかります。私たちは、必要があるサブスクリプションが同じ目的地に向けてのLSPの間でお互いに非常に近いこと参照してください。

トポロジー：

R1〜R4はすべてのLSPの入力ルーターであり、各コアルーターに向けて2つまたは4つのLSPがあります。

構成：

LSP設定は、例として、R1からの単一の宛先です。すべてのLSPはまったく同じ方法で構成されます（ここでも、2または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;

問題は次のとおりです。

[edit protocols rsvp]
load-balance bandwidth

不等コストロードバランシングRSVP LSPに関するジュニパーのドキュメントを参照すると、次のように記載されています。

帯域幅を使用して不均等なロードバランシングを機能させるには、同じ出口ルータに対して少なくとも2つの等コストLSPが必要であり、少なくとも1つのLSPに[edit protocol mpls label-switched-path lsp-パス名]階層レベル。帯域幅が設定されているLSPがない場合、均等分散ロードバランシングが実行されます。一部のLSPのみに帯域幅が設定されている場合、帯域幅が設定されていないLSPはトラフィックを受信しません。

これは、構成されている機能に関係なく、次のように個々のLSPに帯域幅の値を静的に設定しないと、等コストロードバランシングが発生しないことを意味します。

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

ただし、自動帯域幅は、構成に存在しないにもかかわらず、実際には帯域幅値の設定としてカウントされます。

自動帯域幅を有効にすると、RPDは帯域幅消費の監視を開始します。使用率に基づいて帯域幅の値を割り当て、RSVPの「負荷分散帯域幅」ステートメントは、それらのサブスクリプション内のトラフィック比率（それぞれ35、35、26、5）を維持しようとします。「ロードバランス帯域幅」の目標は、トラフィックをそれらの比率にできる限り近づけることであるので、これに関する問題は、自動帯域幅に均等に調整する機会を決して与えないことです。これは、10、30、20、40などのセットの場合に意味があります。

これは基本的に「ロードバランス帯域幅」と「自動帯域幅」の間の競合状態です

削除後：

[プロトコルrsvpの編集]帯域幅の負荷分散

トラフィックを調整しました（下に表示されている少ししゃっくりがあります）：

注：これは、同じ問題の影響を受けた別のルーターの例です。

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

（RSVPの場合）ロードバランシング機能を削除したため、自動帯域幅調整が自動的に行われるか、強制的に調整できるようになるまで、PFEは単一のパスのみに再プログラムします。

request mpls lsp adjust-autobandwidth

以下は、同じ症状の2つのLSPの帯域幅調整です。構成の変更と調整が金曜日の正午に行われたため、サブスクリプションの違いがほぼすぐにわかります。

「JUNOSは、ロードバランシングを有効にするポリシーの「パケットごと」というステートメントにもかかわらず、フローごとのロードバランシングアルゴリズムを使用することを理解しています」

いくつかの負荷分散シナリオをテストするためにiperfを使用する場合、そのステートメントは非常に真実であることがわかりました。単一のiperfセッションでは、トラフィックはまったく負荷分散されませんが、並列iperfセッションを有効にすると、トラフィックは負荷分散されます。

ジュニパーのドキュメントでは別の方法が推奨されていますが！ http://www.juniper.net/documentation/en_US/junos13.2/topics/usage-guidelines/mpls-configuring-load-balancing-across-rsvp-lsps.html

上記はJUNOS13.2から適用可能かと思います