要約

  • multipath は複数の適格経路をローカル転送へ参加させるが、帯域倍増、物理的独立、バイト数の均等を保証しない。
  • BGP は参加資格を決め、再帰解決とハードウェアはメンバーを組み、ハッシュとフロー構成が実際の利用を決める。
  • 検証には Adj-RIB-In、RIB、FIB、メンバー別のパケット・バイト・キュー、障害時の挙動までが必要である。

ルート表に書かれていない「五割」

実事故ではなく、仕組みを切り出した例を考える。同じプレフィックスへの二経路が装置の multipath 条件を満たし、ECMP グループにも二つの next hop が入った。変更記録はこれを「50対50」と表現した。ところが、長時間続く大きなフローがメンバー A に割り当てられ、A のキューだけが伸び、B には余裕が残る。

この時点で BGP セッションも経路も正常であり得る。誤りは、メンバー数の等しさを転送バイト量の等しさに置き換えたことだ。ハッシュはフロー識別子を振り分けるが、各フローの大きさを同じにする機能ではない。

RFC 4271 の基本決定手順は、適格経路から選択し、Loc-RIB に導入し、直近 next hop を決定する。一般的な BGP multipath は、そのローカルな結果に追加の適格経路を残す実装拡張である。全ピアが同じ集合を広告・導入・利用するという相互運用上の約束を新設するものではない。RFC 4271 9.1.2節

「同等」の条件も製品ごとに境界がある。Cisco は multipath の比較項目を示しつつ、広告用の best path を一つ指定する。FRRouting は前段の選択条件の後に multipath 判定を行い、multipath-relax で AS_PATH の完全一致を緩和できる。Arista は引用した EOS の文脈で、この緩和についてさらに異なる既定動作を記している。いずれも参加資格の定義であり、容量、契約上の意味、障害ドメインの一致を証明しない。Cisco の best-path 文書、FRRouting BGP 文書、Arista EOS BGP 文書

判定は一回ではなく三回ある

第一は候補判定だ。経路が利用可能で、ポリシーを通過し、その実装の等価条件を満たすかを見る。maximum-paths は上限にすぎず、指定数がハードウェアへ入った証拠ではない。

第二はグループ構築である。候補ごとに next hop を再帰解決し、FIB と ASIC の制限内で ECMP メンバーにする。異なる二つの next hop が同じトンネル、同じラインカード、同じ遠隔回線へ収束することもある。経路本数は物理的冗長性の代わりにならない。

第三は各フローの選択だ。RFC 2991 は同一フローを一経路に保つことで順序逆転を抑える考え方と、メンバー変更時の影響を述べる。RFC 2992 の hash-threshold 分析も、ハッシュ空間の分散と実トラフィック量を区別している。フロー数が均されても、巨大フロー一つでバイト量は偏り得る。RFC 2991、RFC 2992

従って、「候補になった」「FIB に入った」「通信を運んだ」は別々に証明しなければならない。

ハッシュの材料は装置から見えるものだけ

利用できるフィールドは、アドレスファミリー、カプセル化、装置、設定で変わる。IPv6 flow label はトランスポートヘッダーを参照できない場面で追加のエントロピーになり得る。RFC 6438 は同時に、トンネル、フラグメント、不可視の上位ヘッダーが材料を減らすことも示す。多数の内側セッションが同じ外側タプルを共有すれば、装置には一つのフローのように見える場合がある。RFC 6438

「常に五タプル」と決めつけず、対象機種、ファミリー、封入方式、フィールド、seed、粒度を記録する必要がある。Arista が文書化する hash seed、polarization、resilient ECMP は、このローカルな実装面の一例であって、全装置の既定値ではない。Arista IPv4 文書

RFC 7424 は、多数のフローを少数のリンクへ対応づける際に、大きなフローが不均衡を生むことを扱う。短い接続が多数あれば平均化しやすいが、バックアップや複製の一本が長時間一メンバーを占有できる。パケット、バイト、キュー、drop、遅延は、それぞれ違う問いへの答えである。RFC 7424

容量の違うリンクを通常の ECMP に入れても、装置が自動で比率を理解するとは限らない。weighted ECMP や adaptive routing は別の仕組みであり、別の検証と失敗条件を持つ。

見える経路と使う経路

ADD-PATH は可視性の機能だ。RFC 7911 により、同一プレフィックスの複数経路を暗黙の置換なしに広告できるが、受信側に同時導入や配分比率を義務づけない。逆に、ローカルでは multipath を使いながら通常のピアには best path だけを広告することもできる。RFC 7911

PIC は障害後の修復を速くするための待機・転送状態を扱う。平常時に同時利用するメンバーとは証拠が異なる。Junos 文書でも、BGP multipath の選択と forwarding table の load-balancing policy は分けて扱われる。歴史的な “per-packet” という表現も、文脈上は多くの場合 per-flow hash を指すため、文字どおりの無制御なパケット分散と読んではならない。Junos 文書

候補からパケットまで追跡する

変更前に対象プレフィックス、アドレスファミリー、ピア群、上限、責任者、rollback 条件を定める。Adj-RIB-In の候補と等価判定を保存し、multipath-relax を使うなら何を緩和したかを書く。

次に再帰 next hop と障害ドメインを確認し、実際の FIB・ハードウェアグループ ID とメンバーを読む。RIB が二本で FIB が一本なら、まず解決、容量、プログラミングを調べるべきで、ハッシュの議論はその後だ。

代表的な時間幅で、メンバー別の packet、byte、drop、queue を採り、大きなフローを特定する。異なるキーを持つ複数のテストフローを実際の入口から送る。一本の ping は、そのキーの到達性しか示さない。メンバーの除去と復帰も試す。resilient hash は再配置を減らせても、全移動や順序逆転をなくすわけではない。

設定を戻しただけでは rollback は完了しない。候補集合、RIB、FIB、パケット挙動の復帰まで確認する。