要約

  • maximum-prefix が判断するのは経路状態の量であり、境界を越えた経路の正当性ではない。切断動作では、1件の超過がセッション全体の経路撤回につながる。
  • 実効性のある方針には、隣接とアドレスファミリーごとの上限、受信前後の計数点、通常増加を含む余裕、相応の超過動作、RIB・FIB・パケットまで続く検証が必要である。

数字は中立でも、数字に結び付けた権限は中立ではない

経路数は観測値である。ところが maximum-prefix の設定では、その観測値が一定の整数を越えた瞬間に、警告、超過分の破棄、経路の非表示、あるいは BGP セッションの終了という行為へ変換される。数字そのものより重要なのは、数字にどの権限を与えたかである。

切断を選んだ場合、最後に届いた経路が不正である必要はない。正しいプレフィックス、正しいオリジン、通常の属性を持つ経路でも、カウンターを N から N+1 に進めれば条件は成立する。セッションが閉じれば、先に受け入れていた N 件も供給元を失う。代替経路があればトラフィックは移り、なければ到達性が消える。

これは maximum-prefix が不要という意味ではない。誤ってフルルートを送信する、急激に細分化する、想定外のアドレスファミリーが増えるといった事象は、メモリ、更新処理、収束時間を圧迫する。有限の装置には数量境界が必要である。ただし、保護した資源と、保護のために失ったサービスを同時に評価しなければならない。

標準が定める動作範囲

RFC 4271 は、隣接から受け入れるアドレスプレフィックス数にローカル上限を設定できるとしている。上限到達時には、新しいプレフィックスを捨てて接続を維持するか、BGP 接続を終了できる。上限超過を理由に終了するなら Cease 通知を送る。

RFC 4486 は、その理由を Cease サブコード1、Maximum Number of Prefixes Reached として特定する。通知には AFI、SAFI、4オクテットの上限値を含めることもできる。単に「セッションが落ちた」という記録より、どのファミリーの数量方針が実行されたかを示す強い証拠になる。

標準は具体的な上限値を決めない。少数の経路を広告する顧客、部分的な経路を交換するピア、フルルートを届けるトランジットでは期待値が異なる。受信装置の能力、冗長性、依存する顧客トラフィックもローカルな事情である。裁量がローカルにある以上、説明責任もローカルに残る。

経路の内容を検査する機能ではない

上限未満だから安全とは限らない。誤ったオリジン、契約に反する経路、望ましくない more-specific は少数でも存在し得る。一方、上限超過が攻撃や漏えいを証明するわけでもない。顧客追加、正当な分割広告、移行、障害時のトラフィックエンジニアリングによって、正常な経路だけで総数が増えることがある。

プレフィックスフィルター、AS_PATH 方針、RPKI オリジン検証、ネクストホップやコミュニティーの規則は、経路の属性や関係を評価する。maximum-prefix は量を評価する。正当な経路でも状態資源を使うため数量制御は有用だが、他の検証が持つ意味を借りることはできない。

セキュリティ制御と呼ぶなら、何を守るかを明示すべきである。ルーティングプロセスのメモリ、収束時間、更新処理能力、装置全体の安定性を、想定外の大量入力から守る可能性はある。しかし送信者の意図を認証せず、境界を越えた経路が損害を起こしたとも証明しない。

受信数と受理数は同じではない

設定値が同じでも、実装が数える位置によって境界は変わる。

FRRouting の BGP 文書では、maximum-prefix は既定で受理されたプレフィックスを数える。force を使うと、入力方針で拒否されたものを含む全受信プレフィックスを数え、そのために必要な入力状態を保持する。さらに、セッション破棄は不要経路の拒否よりはるかに破壊的だと注意している。

Junos は目的を分けている。prefix-limit は受信プレフィックス、accepted-prefix-limit はポリシーで受理されたプレフィックスを対象とする。切断、超過分の破棄、超過分の非表示があり、保持状態と復旧手順は同一ではない。

ポリシー前の計数は、フィルターが大部分を拒否する場合でも、隣接が送り込もうとした量を見せる。誤ったフルルート送信の検知には有利だが、実際には採用されない状態を理由に重要なセッションを閉じることもある。ポリシー後の計数は受理状態に近い反面、入力処理が受けた総圧力を隠す。

さらに、プレフィックス数とパス数が一致するとは限らない。ADD-PATH、VPN ファミリー、実装内部の保持方法により、同じ宛先に複数パスが存在する。稼働中リリースが何を「1」と数えるのかを確認せずに、他装置の値を転用してはならない。

超過時の選択が障害の形を決める

警告はセッションと全経路を維持する。調査時間を生むが、状態増加は止めない。通知経路、担当者、応答時間、残存容量が揃わなければ、警告は将来の超過を記録するだけになる。

超過分の破棄は既存経路を残し、後から届いたものを拒否する。全撤回を避ける一方、到着順序に左右される不完全なビューを作り得る。数が減っても、route refresh や再評価なしに拒否経路が戻るとは限らない。

超過分の非表示は情報を保持しながら通常選択から外す。再取得なしで戻せる利点はあるが、保護対象だったメモリを消費し続ける可能性がある。目的に合うかは実装の状態管理で判断する。

セッション切断は入力源を明確に止める。同時に、そのセッションだけが提供していた経路もすべて失う。トラフィックは予備回線へ移り、容量不足や経路伸長が現れ、代替のない宛先は消える。

ベンダー用語だけでは最終状態を比較できない。Cisco の maximum-prefix 文書は警告率、既定の切断、警告のみ、任意の再起動間隔を説明する。Arista EOS は上限超過でピアリングを無効化でき、警告動作ではセッションを保ちながら後続経路を捨てる場合を示す。同じ「警告」でも残る経路は同じとは限らない。

関係から上限を作る

RFC 7454 は、ピアリング関係に応じた最大プレフィックス数を推奨する。限定的な経路だけを送るピアなら、フルインターネットテーブルより低い値で誤送信を検知できる。フルルートを提供する上流なら、期待テーブルより上で、かつ受信装置が安全に扱える範囲に置く必要がある。

計算の出発点は、関係上正当な経路集合である。観測した変動、信頼できる成長予測、顧客追加、許容する分割、移行を加える。その値を装置能力と、超過動作がサービスへ与える費用に照らす。最後に所有者、見直し日、緊急変更手順を決める。

RFC 4778 は、交換予定のプレフィックス数を相互に認識し、正当な変動のための余裕を持たせることを勧める。相手に知られない保護は、承認済みの増加を障害へ変えやすい。RFC 7454 も、経路数が変化するため定期見直しを求める。

余裕は割合だけでなく、正常成長を何か月吸収できるか、どの程度の変動を覆えるかで示した方がよい。同じ20%でも安定した接続と急成長中の接続では意味が違う。小さ過ぎれば保護が障害原因になり、大き過ぎれば上限が装飾になる。

タイマーは修正を証明しない

自動再起動は、一時的な超過が既に解消した場合には停止時間を短くする。しかし送信集合が同じなら、確立、超過、切断、待機、再確立というループを自動化する。

時間経過だけでは条件の変化を示せない。超過経路の撤回、送信方針の修正、承認された上限変更、実際の能力増強といった新しい証拠が必要である。根拠のない手動 clear も、タイマーを人の操作へ置き換えただけである。

RFC 8538 は、Graceful Restart において maximum-prefix の Cease を hard reset 条件として扱うことを提案する。数量方針による意図的な切断を、通常再起動のような古い経路保持で曖昧にすべきではない。

カウンターからパケットまで追う

証拠の最初は、隣接と AFI/SAFI ごとの実効設定である。グループ継承、警告水準、動作を含め、稼働ソフトウェアと、受信・受理、プレフィックス・パスの定義を残す。

超過時には、最後に受理した更新、カウンター遷移、Cease コードとサブコード、AFI/SAFI/上限データ、セッション状態、再試行やアイドル時間、レート制限された可能性のあるログを保存する。撤回、破棄、非表示、維持を区別する。

その後、宛先を追跡する。最良経路が変わったプレフィックスはどれか。代替候補は RIB にあり、FIB にインストールされたか。流量を引き受けたリンクに容量はあるか。重要な宛先クラスへパケットが届くか。復旧前後の総数一致は、同じプレフィックス、属性、ネクストホップを意味しない。

保護対象の資源が安全目標内に残り、同時にサービス状態が承認済みの取引条件と一致した時にだけ、maximum-prefix は成功したと言える。カウンター単独ではどちらも証明できない。

出典