BGPマルチパス

BGPマルチパスを使用すると、複数のBGPルートを同時に使用して同じ宛先に到達できます。BGPマルチパスの仕組みと、その実装に伴うトレードオフを理解することで、ネットワークエンジニアリングのスキルを向上させることができます。 

本稿では、複数の同一性能パスを使用する等コストマルチパス（ECMP）を中心に、BGPマルチパスの原理、利点、および潜在的な欠点について概説します。また、より高度な不等コストマルチパス（UCMP）とその注意点についても解説します。

詳しく見ていく前に、すべてのルーター実装において、BGPルートよりもスタティックルートまたはIGPルート（OSPF、ISIS）が優先されることに注意してください。通常変更すべきではないデフォルトの階層が存在します。ここではBGPのみに焦点を当てます。ただし、プロトコル階層に慣れていない場合は、以下を参照してください。 Juniperのルート優先度値の理解 記事。

この記事では、Juniperの設定と運用に関するshowコマンドの出力を使用します。他のベンダーの構文も非常に似ています。 Cisco (NAIST) と ノキア 構文の詳細については、ドキュメントを参照してください。 

バニラBGP：マルチパスではないBGP

BGPマルチパスの詳細に入る前に、従来のBGPの仕組みを復習しておきましょう。 

BGPルーティングプロトコルは、ネットワーク上の宛先（プレフィックス）への経路を受信して​​アドバタイズします。例えば、宛先10.10.10.0/24への経路などです。ルータが同じ宛先へのBGP経路を2つ以上受信した場合、最適パス選択プロセスによって最適な経路が1つ選択されます。

ルータが宛先10.10.10.0/24を指すルートAとルートBを受信した場合、ルータはそれらのうち最適なルートを選択する必要があります。ルータは、ASパス長やBGPメトリックなど、ルートアドバタイズメントに含まれる複数の属性を評価します。最適なルートが見つかり、ルーティングテーブル（ルーティング情報ベース、RIB）にアクティブルートとしてインストールされます。 

次に、アクティブルートが転送情報ベース（FIB）に追加され、ハードウェアASICにプログラムされます。シャーシベースのルータでは、各ラインカードにこのアクティブルートがプログラムされます。

BGPマルチパスの利点

BGPマルチパスの、通常のBGPと比較した主な利点は以下のとおりです。

• 複数のリンク間でトラフィックの負荷分散を行う機能。 
• BGPセッションまたはリンク障害発生時の影響を軽減します。 

このようなネクストホップ障害が発生すると、トラフィックを再び転送するにはBGPの再収束が必要になりますが、複数のパスが既にインストールされている場合は、継続的な転送とパケット損失ゼロが保証されます。 

複数のパスがアクティブに使用されている状態で障害が発生した場合、ルータはRIBの最適パス選択、FIBプログラミング、およびASICプログラミングのプロセスが完了するのを待つのではなく、障害が発生した転送ネクストホップのみを削除する必要があります。これにより、その宛先へのすべてのトラフィックが影響を受けるのではなく、障害が発生したパスのみが影響を受けます。 

アクティブなマルチパスリンクが2つ使用されている場合、トラフィックの約半分が影響を受けます。リンクが4つになると、約4分の1が影響を受け、以下同様です。

BGPマルチパスを実装する際の考慮事項

BGPプロトコルは、リンク容量や負荷に依存しません。適切に設計・維持管理されたネットワークでは、バックアップパスに十分なリンク容量が確保されているため、プライマリBGP/リンク障害発生時でも、輻輳やデータ損失なくサービスの継続性が保証されます。

BGPマルチパスを実装する際は、トラフィックの変化による影響に注意してください。現在のリンクの容量と利用パターンを考慮し、BGPマルチパスの実装がネットワークの状態にどのような影響を与えるかを検討してください。

等コストマルチパス（ECMP）

ECMPは複数のルートを使用し、それぞれのルートはリンク容量と遅延に関して非常に類似または同一の特性を持つパスを使用し、ASパスやBGPメトリックなどの同一のBGP属性を持ちます。

この概念を説明するために、基本的な使用例を見てみましょう。以下では、企業ルーターが2つの独立したリンクとBGPセッションを介して2つのISPルーターに接続しています。プライマリ/バックアップのフェイルオーバー構成でリンクを設定する代わりに、トラフィックをそれらの間で負荷分散することが目的です。

ISPは各BGPセッションを通じてデフォルトルートをアドバタイズし、両方のルートが受け入れられてRIBにインストールされます。BGPマルチパスを有効にしない場合、RIBは次のようになります。

user@router> show route 0.0.0.0/0 exact
...
0.0.0.0/0         *[BGP/170] 1w5d 18:04:33, MED 0, localpref 100
                     AS path: 65000 I, validation-state: unknown
                     >  to 172.16.1.1 via xe-0/0/1.0
                   [BGP/170] 0w6d 22:42:11, MED 0, localpref 100
                      AS path: 65000 I, validation-state: unknown
                     >  to 172.16.2.1 via xe-0/0/2.0

0.0.0.0/0 への経路が 2 つ存在し、ネクストホップが 172.16.1.1 の xe-0/0/1.0 を経由する BGP セッションで学習された経路が、優先されるアクティブな経路です。これは、この経路が最も古く、つまり最も長く安定して稼働しているためです。 

すぐにわかるように、すべての送信トラフィックはこの経路を使用します。もう一方の経路はフェイルオーバー用に用意されていますが、現在は使用されていません。

転送テーブルを確認することで、このことを確認できます。転送テーブルには、ネクストホップMACアドレスとネクストホップインターフェースがそれぞれ1つずつ表示されています。0.0.0.0/0宛ての送信パケットは、このインターフェースと宛先MACアドレスを使用します。

user@router> show route forwarding-table destination 0.0.0.0/0
Routing table: default.inet
Internet:
Enabled protocols: Bridging,
Destination        Type RtRef Next hop           Type Index    NhRef Netif
default            user     5 172.16.1.1
                                                 ucst    16975    11 xe-0/0/1.0

一方、BGPマルチパスを有効にすると、両方のルートが使用可能になります。次のセクションでは、その設定と検証を行います。

BGPマルチパス設定

BGPピアがマルチパスを使用するように設定するには、2つの手順を実行する必要があります。該当するBGPセッションでマルチパスを有効にします。
を追加してみましょう マルチパス ISPピアリングへのノブ：

set protocols bgp group MYISP neighbor 172.16.1.1 description "MYISP Link#1 Circuit ID: 11111"
set protocols bgp group MYISP neighbor 172.16.1.1 import IMPORT_MYISP
set protocols bgp group MYISP neighbor 172.16.1.1 export EXPORT_MYISP
set protocols bgp group MYISP neighbor 172.16.1.1 peer-as 65000
set protocols bgp group MYISP neighbor 172.16.1.1 multipath

set protocols bgp group MYISP neighbor 172.16.2.1 description "MYISP Link#2 Circuit ID: 22222"
set protocols bgp group MYISP neighbor 172.16.2.1 import IMPORT_MYISP
set protocols bgp group MYISP neighbor 172.16.2.1 export EXPORT_MYISP
set protocols bgp group MYISP neighbor 172.16.2.1 peer-as 65000
set protocols bgp group MYISP neighbor 172.16.2.1 multipath

マルチパスが機能していることを確認するには、BGPネイバーシップの状態を確認できます。マルチパスを追加する前に：

user@router> show bgp neighbor 172.16.1.1 | match options
  Options: <Preference AuthKey LogUpDown AddressFamily PeerAS Rib-group Refresh>

マルチパスを追加した後：

user@router> show bgp neighbor 172.16.1.1 | match options
  Options: <Preference AuthKey LogUpDown AddressFamily PeerAS Multipath Rib-group Refresh>

転送テーブルでロードバランシングを有効にしてください。
ISPのAS番号に対して選択的に有効化します の範囲を限定し、他のルートへの望ましくない影響を防ぐために、新機能は選択的かつ具体的に導入するのが最善です。なぜなら、ECMPをグローバルに使用することを望まない場合もあるからです。 最も特異性が高い 設定スタイルがトラブルシューティングを容易にする。

#
# define as-path for MYISP, matching all routes received
#
set policy-options as-path MYISP "65000 .*"

#
# define policy-statement matching this AS path
# then load-balancing across routes which match
#
set policy-options policy-statement ECMP-FIB from as-path MYISP
set policy-options policy-statement ECMP-FIB then load-balance per-packet



#
# apply this policy to the forwarding table (FIB)
#
set routing-options forwarding-table export ECMP-FIB

このシンプルなポリシーにより、AS 65000 から学習したルート宛のパケットを照合し、 流量ごと 利用可能な等コスト経路間で負荷分散を行う。 

これはタイプミスではありません。Junos構文'パケットごとの負荷分散は、旧来の互換性のために残された不適切な名称です。詳細については、1パックあたり'構文をお願いします JuniperのWebサイト「パケットごとの負荷の設定」を参照してください。 記事。

ほぼすべての最新ルーターは、 フローこれにより、あるIPアドレスから別のIPアドレスへのフロー（会話に類似）が常に同じ経路を通ることが保証されます。ルーターがフローをリンクに一貫してバインドする理由は、ラウンドロビン方式やパケットごとのランダムスプレー方式の負荷分散を回避するためです。そうすると、フローが複数のリンクに分散され、パケットが宛先IPアドレスに順不同で到着し、TCPのパフォーマンス問題が発生することになります。

TCPプロトコルはシーケンス番号に基づいてパケットの順序を並べ替えますが、これはパフォーマンスとスループットに悪影響を与える可能性があります。順序の並べ替えは処理オーバーヘッドを発生させ、再送要求の送信（パケット損失時と同様）によってレイテンシや輻輳を増加させる可能性があります。したがって、その影響はパケット損失と類似しており、TCPスライディングウィンドウサイズの縮小につながり、転送速度が低下します。 

ベストプラクティスは、マルチパス/ECMPが以下のように構成されていることを確認することです。 流量ごと 負荷分散。

Junosには、この記事の範囲を超えるいくつかの代替ロードバランシング方法が用意されています。特定のユースケースがある場合は、Junosのドキュメントを参照して、それぞれの動作を理解してください。

consistent-hash      Give a prefix consistent load-balancing
  destination-ip-only  Give a destination based ip load-balancing
  per-packet           Load balance on a per-packet basis
  random               Load balance using packet random spray
  source-ip-only       Give a source based ip load-balancing

BGPマルチパス検証

RIBでこのルートを表示すると、次のようになります。

0.0.0.0/0     *[BGP/170] 1w5d 18:04:33, localpref 100
                      AS path: 65000 I, validation-state: unknown
                       to 172.16.1.1 via xe-0/0/1.0
                    >  to 172.16.2.1 via xe-0/0/2.0

両方のパスが表示されていますが、アクティブとして表示されているのは「>」で示される1つのパスのみであることに注意してください。これはJunosの特殊な動作です。パケット転送レベルで何が起こっているかを確認するには、転送テーブルを再度確認する必要があります。

user@router> show route forwarding-table destination 0.0.0.0/0
Routing table: default.inet
Internet:
Enabled protocols: Bridging,
Destination        Type RtRef Next hop           Type Index    NhRef Netif
0.0.0.0/0          user     0                    ulst  1048662    32
                              172.16.1.1         ucst     1396     4 xe-0/0/1.0
                              172.16.2.1         ucst     1850     4 xe-0/0/2.0

ここでは、宛先0.0.0.0/0に対して、ネクストホップとインターフェースの両方がリストされていることがわかります。トラフィックは、Juniperのデフォルトの「パケット単位」のロードバランシングに従って、これらのリンク間で負荷分散されます。 

おめでとうございます！これで、BGPルートを使用したフローごとのECMPロードバランシングの設定と検証が完了しました。Junosデバイスでこの機能を有効にする手順は以上です。これで、ロードバランシングと高速フェイルオーバーのメリットを享受できます。

リンクアグリゲーションは、BGPマルチパスの代替手段または補完手段となる。

リンクアグリゲーションは、状況によってはマルチパス方式の代替手段または補完手段として有効です。複数の類似または同一のリンクを単一の論理リンクに統合することで、物理的な冗長性と容量の増加を実現しつつ、管理すべき論理リンクとルーティングプロトコルを1つに絞り込むことができます。 

このような集約リンクは、一般的にリンク集約グループ（LAG）および集約イーサネットインターフェイス（AggEthまたは）として知られています。 ae Junos のインターフェース）。前の例を拡張して、2 つの異なる ISP への接続が可能になりました。また、各 ISP への物理リンクが 2 つあります。 

これらのリンクを集約することで、4つのBGPセッション（リンクごとに1つのセッション）を確立する代わりに、設定と管理を簡素化できます。

我々側では、単一の 論理的な ae ISPごとのインターフェース、それぞれ ae 2 つの物理メンバリンクを持つインターフェース。ISP 側でも同じ構成が使用されます。 ae このリンクは、単一のIPアドレスとMACアドレスが割り当てられるなど、他の標準的なリンクと同様に動作します。また、論理リンク内の物理リンクの状態とメンバーシップを管理する、リンクアグリゲーション制御プロトコル（LACP）と呼ばれる追加プロトコルも有効にしています。

#
# first enable the creation of aggregate ethernet interfaces
#
set chassis aggregated-devices ethernet device-count 8

#
# then create our new logical interfaces, MYISP1 first
#
set interfaces ae1 description "MYISP1 Circuit ID: 11111"
set interfaces ae1 aggregated-ether-options lacp active
set interfaces ae1 aggregated-ether-options lacp periodic fast
set interfaces ae1 unit 0 family inet address 172.16.1.1/30

#
# then configure physical interfaces, adding to the ae
#
set interfaces xe-0/0/0 description "MYISP1 Link #1"
set interfaces xe-0/0/0 gigether-options 802.1ad ae1

set interfaces xe-0/0/1 description "MYISP1 Link #2"
set interfaces xe-0/0/1 gigether-options 802.1ad ae1

#
# repeat for MYISP2
#
set interfaces ae2 description "MYISP2 Circuit ID: 22222"
set interfaces ae2 aggregated-ether-options lacp active
set interfaces ae2 aggregated-ether-options lacp periodic fast
set interfaces ae2 unit 0 family inet address 172.16.2.1/30

set interfaces xe-0/0/2 description "MYISP2 Link #1"
set interfaces xe-0/0/2 gigether-options 802.1ad ae2

set interfaces xe-0/0/3 description "MYISP2 Link #2"
set interfaces xe-0/0/3 gigether-options 802.1ad ae2

Verification

LACP隣接が各新規イベントで発生したことを確認します ae インタフェース：

user@router> show lacp interfaces ae1
Aggregated interface: ae1
    LACP state:       Role   Exp   Def  Dist  Col  Syn  Aggr  Timeout  Activity
      xe-0/0/1       Actor    No    No   Yes  Yes  Yes   Yes     Fast    Active
      xe-0/0/1     Partner    No    No   Yes  Yes  Yes   Yes     Fast    Active
      xe-0/0/2       Actor    No    No   Yes  Yes  Yes   Yes     Fast    Active
      xe-0/0/2     Partner    No    No   Yes  Yes  Yes   Yes     Fast    Active
    LACP protocol:        Receive State  Transmit State          Mux State
      xe-0/0/1                  Current   Fast periodic Collecting distributing
      xe-0/0/2                  Current   Fast periodic Collecting distributing

この構成により、リンクごとに1つのBGPセッションを実行する必要がなくなり、リンクの冗長性を維持しながら、追加容量を活用することが可能になりました。 

将来、容量需要が増加すると仮定します。このコマンドを使用すれば、ルーティングを変更することなく追加のリンクを追加できます。

set interfaces xe-0/0/4 description "MYISP2 Link #3"
set interfaces xe-0/0/4 gigether-options 802.1ad ae2

BGPマルチパスはIPパケット層（レイヤ3）での負荷分散に関するものですが、JunosにはLAGを通過するフレーム（レイヤ2）の継続的な再分散を行うための適応型負荷分散機能があります。リンクの使用率が高い場合や、大量のデータフローがリンクを通過する場合（例：毎晩のバックアップ）には、この機能を有効にすることをお勧めします。 

LAGとECMPを組み合わせる

LACP LAGとECMPを組み合わせることは可能です。ISPごとに1つのLAGを設定し、それぞれからデフォルトルート（0.0.0.0/0）を受信して​​いるとします。 

以前の負荷分散設定に少し変更を加えるだけで、両方のISP間でトラフィックを分散させることができます。 

このシナリオでは、各ISPとのリンク冗長性に加え、ISP間の冗長性も確保されています。さらに、1つのISPが障害を起こした場合でも、影響を受けるトラフィックは約半分にとどまるため、高速なフェイルオーバーが可能となり、アクティブなトラフィックへの影響を最小限に抑えることができます。

#
# define policy-statement matching each ISP’s route
# then load-balancing across them
#
set policy-options policy-statement ECMP-FIB from next-hop 172.16.1.2
set policy-options policy-statement ECMP-FIB from next-hop 172.16.2.2
set policy-options policy-statement ECMP-FIB then load-balance per-packet

Verification

RIBとFIBを確認することで、0.0.0.0/0ルートが両方ともアクティブであることを確認できます。RIBには2つのパスが表示されますが、アクティブとしてマークされているのは1つだけです。しかし、FIBの出力には2つのアクティブなネクストホップが表示されます。

show route 0.0.0.0/0 exact
show route forwarding-table destination 0.0.0.0/0

ベストプラクティス

LAGの欠点とBGPマルチパスの利点の1つに気づかれたかもしれません。LAG内部で障害が発生し、容量が20Gbpsから10Gbpsに低下した場合、何が起こるかを考えてみましょう。以下は、すべてのリンクが稼働している安定した状態のネットワークです。

さて、ISP2 に面する ae2 内のリンク #2 が、ISP 側の光ファイバーまたはプラグイン可能な光障害によって故障した場合、どうなるでしょうか? 光信号損失または LACP プロトコルがリンク障害を検出し、それをネットワークから削除します。 ae バンドル化することで、容量を10Gbpsに削減します。 

しかし、当社のBGPプロトコルとロードバランシング構成はこの新しい状況に対応できません。トラフィックは引き続きリンクae1とae2間でほぼ均等に分散されます。ただし、13.5Gbpsのトラフィック需要は10Gbpsのリンクには収まらないため、約3.6Gbpsのパケットが破棄されます。TCPはこのパケット損失を検出し、ある程度補償しますが、ユーザーエクスペリエンスは著しく低下します。

この例は、容量が低下した際にLAGと上位層プロトコルがどのように動作するか、そして容量管理の課題という2つの問題を浮き彫りにしています。 

以下の表は、リンクをアップグレードすべき時期を詳細に示しています。 

これにより、LAG構成オプションについて説明します。 最小限のリンクISP、別の内部ルーター、またはデータセンターのスイッチに接続されている場合でも、LAGは、動作可能なリンクが十分でなくなった場合に完全に機能停止するように構成できます。 

例えば、2x10G LAGの場合、両方のリンクが稼働している場合にのみ動作すると判断したり、4x10G LAGの場合は、半分の容量で動作しても問題ないと判断したりするかもしれません。設定は簡単です。

set interfaces xe-3/1/1 gigether-options 802.1ad ae5
set interfaces xe-3/1/2 gigether-options 802.1ad ae5
set interfaces xe-3/1/3 gigether-options 802.1ad ae5
set interfaces xe-3/1/4 gigether-options 802.1ad ae5
set interfaces ae5 aggregated-ether-options minimum-links 2

不等コストマルチパス（UCMP）

「容量の異なるリンク間でトラフィックの負荷分散は可能か？」という疑問は、UCMPというより高度なトピックへと繋がります。UCMPは使用可能ですが、いくつかの理由から一般的には推奨されません。

• LAGにおけるリンク障害はネットワークに悪影響を及ぼす可能性があるUCMPでは、初日のネットワーク計画では時間の経過に伴うルーティングの変更やトラフィックの変動が考慮されない可能性があるため、容量管理の複雑さが増します。
• 経路間の不平等は、単に容量の違いだけでなく、遅延時間の違いにも関係する可能性がある。 ルーターはフローを常にどちらか一方のパスに固定しようとしますが、レイテンシの違いによって、ユーザーと特定の宛先間のフローの開始と終了のたびに異なるパスが通るため、ユーザーエクスペリエンスが低下する可能性があります。その結果、ユーザーはネットワークパフォーマンスの不安定さを訴え、フローの状態が一時的なものであるため、トラブルシューティングが非常に困難になる可能性があります。
• クライアントからサーバーへの経路は低遅延である可能性がある一方、トラフィックの大部分はサーバーからクライアントへ、高遅延の経路を流れる可能性がある。 ウェブページが複数のリソースからレンダリングされ、複数のエンドポイント間で複数のフローが必要となることを考えると、配信とレンダリングの不整合が顕著になる可能性がある。
• レイテンシーの違いには対応していません。 BGPプロトコルは信号経路の帯域幅を拡張するようになったものの、遅延の違いには対処していません。そのため、部分的な緩和策に過ぎず、その使用はネットワークの複雑さを増大させ、リスクを生み出します。

UCMPの潜在的な問題点に関するより詳しい情報については、IP Spaceの 不均等コストのマルチパスは理にかなっているか 記事。 

結論：BGPマルチパスのユースケースを理解する 

適切なユースケースにおいては、BGPマルチパスはルーターのオペレーティングシステムを問わず利用可能な効果的なツールです。実装は比較的容易で、ECMPアプリケーションも通常は単純明快です。しかし、UCMPは急速に複雑化し、保守が困難になる可能性があります。 

一般的に、可能な限りUCMPを避け、常に以下の点を考慮してください。

• BGPマルチパスをいつ、どこで使用すべきか。 マルチパスは、同じ宛先への複数のBGPルートがあり、それら間で負荷分散を積極的に行いたい場合に便利です。ただし、プライマリ/バックアップのフェイルオーバー構成には、より適切な構成がある場合はマルチパスを使用すべきではありません。例えば、デュアルISP構成の場合、ISP1の方が接続容量が大きかったり、より高速または信頼性の高いサービスを提供したりするため、プライマリ接続として優先される場合があります。
• LAGをいつ、どこで使用すべきか。 LAGは、BGPルーティングの設定、監視、トラブルシューティングを簡素化するのに役立ちます。2つの内部デバイスを接続する場合、またはリンクの両端で1つのデバイスに複数のBGPセッションを設定する場合は、LAGの使用を検討してください。場合によっては、LAGは使用可能ですが、理想的ではありません。たとえば、LAGがローカルでは単一のデバイスで終端し、リモート側では2つのデバイスに接続する場合です。リモート側で2つのデバイスで終端するには、MC-LAGとICCPプロトコルが必要となり、設定ミスやソフトウェアの欠陥により複雑化やリスクが増大します。
• BGPマルチパスとLAGを組み合わせるタイミングと場所。 両方の技術を組み合わせるのに適したユースケースとしては、データセンターファブリック、デュアルISPの例、あるいはトランジットネットワークを運用している場合にマルチホーム接続の顧客を接続する場合などが挙げられます。 

いずれにせよ、ネットワークに新しい機能を導入する際は、その影響を常に慎重に検討し（そしてラボでテストし）、特に容量管理、フェイルオーバーシナリオ、運用保守の観点から注意する必要があります。

よくあるご質問