Summary

  • RFC 3345が扱うのは、部分的な候補経路に対して各ルーターがローカル規則を適用し、その広告が他ノードの見える候補を変える決定論的な振動である。
  • 根拠は、複数ノードを巡る経路・UPDATE・撤回の反復であり、一台の「最適経路」表示ではない。

分析

二つのルートリフレクターを考える。一方が把握する出口から経路を選んで広告し、もう一方も自分の表にある候補だけで選択する。後から届いた撤回が、最初のリフレクターの判断材料を消すと、候補集合が変わって以前の経路が再び選ばれる。こうして広告と撤回が一巡する。乱数や故障は必要ない。分散した状態が互いに変化し、落ち着かないのである。

2002年の情報文書RFC 3345は、この構造を具体的なトポロジと経路表で説明した。BGPのMEDは原則として同じ隣接ASから学習した経路同士で比較する。これは相手ASが示す出口選好の範囲を保つためだ。iBGPのフルメッシュなら経路の可視性は広がるが、規模に限界がある。ルートリフレクションやASコンフェデレーションはセッション数を抑える一方、ルーターごとに見える出口を変える場合がある。

Type Iの条件には、単一階層の反射またはコンフェデレーション構成と、一つのプレフィックスに対して複数ASから異なるMEDを受け入れることが含まれる。反射の例では、MEDとNEXT_HOPまでのIGPコストの比較順が効く。UPDATEが別ノードの選択を変え、その後の広告や撤回が最初のノードの候補集合を変える。ここでの「最適」は局所評価であって、ネットワーク全体の安定性ではない。

Type IIは別の構成であり、多階層の反射またはサブASと、文書に示されたMED条件を要する。コンフェデレーションの例は、定期スキャナーが再計算の時点を左右することも示す。最後の表だけでは原因となった順序を復元できない。

提案された対策は、階層間IGPメトリックの調整、MEDを受け入れないこと、比較段階に至らない属性を使うこと、フルメッシュへの回帰などである。どれもポリシーや規模との交換条件があり、万能策ではない。後年のRFC 7964はADD-PATHなど経路多様性の仕組みを説明したが、それは全ネットワークへの導入や全条件の解消を証明しない。

実ネットワークの事例を立証するには、各ルーターの候補、属性、選択理由、UPDATEと撤回の時刻、スキャナー状態を保存し、転送結果も別に観測する必要がある。制御プレーンの振動だけでは、パケット損失やサービス障害は証明できない。

出典