要約
- 発端は、約300台のルーターからなるフラットな IS-IS L2 ドメインと、下流に約100の隣接を持つ集約ルーターが実用的かという質問だった。
- Saku Ytti は古い制御プレーンで数千ノードを運用した経験を示し、Mark Tinka は2009年に約300ノードを扱っていたと報告した。
- Tom Beecher は規模そのものを問題視せず、地理的広がり、LSDB の大きさ、SPF 遅延を条件に挙げた。Dan Snyder はハードウェア、許容する障害ドメイン、収束時間を加えた。
- Matthew Petach の新しい返信は、プロトコルの収容力と、構成ミス・機器故障・ファイバー断を封じ込める設計を分離した。
- IETF 文書でも、IS-IS の階層化はフラッディングと SPF 計算の範囲を抑える一方、抽象化によって経路最適性を失う場合がある。
- 設計承認に必要なのは最大ノード数の逸話ではなく、障害ごとの影響範囲、残存容量、運用上の制御点を示す試験である。
元の投稿者が求めたのは、ベンダーの推奨値ではなく実運用の事例だった。想定は、約300台のルーターを一つの IS-IS Level 2ドメインに置き、集約ルーターの一部が下流におよそ100の隣接を持つ構成だ。
最初の回答群は、数字を過度に恐れる必要がないことを示した。Saku Ytti は、制御プレーンが現在よりはるかに遅かった時代に数千ノード規模の IS-IS を運用したという。Mark Tinka は、Cisco CRS-1 や ME3600X、Juniper M320、T320、MX480 を含むネットワークで2009年に約300ノードへ到達していたと述べた。Tom Beecher も、単一のフラットな L2 エリアで300ノードは一般に実現可能だとした。
ただし、これらは質問者の構成を再現したベンチマークではない。トポロジー、機種構成、リンク数、LSDB の見込み、遅延、必要な収束時間は開示されていない。従って、普遍的な上限を導くことはできない。導けるのは、300という個数だけでは設計判断にならないという点だ。
「動く」と「許容できる」の間にあるもの
Beecher は、地理的に広いネットワークでは SPF の遅延調整が必要になり得ること、LSDB 全体の大きさも効くことを指摘した。さらに、データベースの大きさが不安材料になるほどなら、フラットなまま維持する判断そのものを検討すべきだとした。
Dan Snyder は三つの軸に整理した。ハードウェアがどれだけ処理できるか、L2 エリアの問題をどの大きさの障害ドメインに閉じ込めたいか、障害後にどれだけ早く収束させたいかである。CPU が速くなっても、一つの誤設定が触れる範囲は自動では小さくならない。収束が速くても、残ったリンクに需要を収められるとは限らない。
後から索引された Matthew Petach の返信が、このスレッドを新しい運用シグナルに変えた。設計時には、まず自動化ツールのバグ、入力ミス、L1 から L3 までの機器故障、ファイバー断といった日常的な失敗を並べ、その「爆発半径」と、論理的な防火扉を置く場所を考えるべきだという。
防火扉は比喩であり、エリアを増やせば必ず正解になるという意味ではない。狙いは、局所的な失敗に反応する範囲を明示し、最短経路だけでは望ましいサービス配分にならない時に上位の制御点を残すことだ。
修復時間が同じ到達性の価値を変える
人員のいるデータセンター内で光モジュールが故障した場合と、長距離ファイバーが損傷した場合では、運用上の時間軸が違う。前者は短時間で交換できる可能性がある。後者は、制約状態が長く続き、残存容量の配分やサービス優先順位が重要になる。
Petach は海をまたぐ経路を例にした。予備容量には大きな費用がかかり、別経路に見える回線でも物理的な共通要因を持ち得る。地域的な障害で複数の容量が同時に失われた時、IS-IS は残った経路へ正しく収束しても、その経路が全トラフィックを運べない可能性がある。
スレッドは特定の海底ケーブル障害を報告しておらず、実測値もない。従って実事故として扱うべきではない。得られる設計課題は、各障害状態に需要行列を適用し、残ったリンクの飽和と、トラフィックエンジニアリングを開始する位置を確認することである。
階層化は状態を閉じ込めるが、情報も削る
RFC 5302は、複数の Level 1エリアを Level 2トポロジーで接続する IS-IS ドメインを説明している。LSP をエリア内に閉じ込めれば、リンクステートデータベースの規模と最短経路計算の対象を制限できる。
同じ RFC は、階層化の代償も明記する。サマリーや抽象化は詳細を失わせ、経路が最適でなくなることがある。詳細なプレフィックスをドメイン全体に広げれば精度は戻るが、メモリー、伝送、計算の負荷が増える。これは安価な安全装置ではなく、拡張性と経路情報の粒度を交換する設計である。
RFC 9377は、一つの IS-IS フラッディングドメインは処理とフラッディングのオーバーヘッドによって最終的に制約されると説明し、複数の L1 ドメインと L2 バックボーンを標準的な拡張方法として挙げる。RFC 8405は、同一エリアまたはレベルの SPF バックオフ値を揃える必要があり、適切な値はネットワークの成長とともに変わるとする。
標準は300台を境界にしていない。確認すべきなのは、ノードとリンク、LSDB の増加、更新頻度、フラッディング時間、SPF の挙動、障害後の実容量である。
レビューを四つの試験に分ける
第一は制御プレーンの余裕だ。稼働中で最も遅い機種を含め、トポロジー変更時の CPU、メモリー、隣接確立、LSP 伝播、フル SPF と増分 SPF を測る。最新機種だけの試験では混在環境を承認できない。
第二は封じ込めである。自動化による誤設定、ルートポリシーの誤り、装置喪失、拠点喪失、共通要因を持つ長距離回線の同時断を試す。それぞれについて、再計算する範囲、影響するサービス、担当チーム、影響を受けてはならない部分を決める。
第三は劣化時容量だ。ルーティングテーブルが一貫してもリンクが飽和すれば合格ではない。サービス優先、流入制御、明示的なトラフィックエンジニアリングをどこで行うかを示す必要がある。
第四は将来の運用可能性だ。Petach は3年、5年、10年を見通すよう促した。増えるのはルーターだけではない。地域、機器世代、保守ドメインが増え、障害時にトポロジーを理解して安全に操作できる人員の条件も変わる。
次に示すべき数字は障害予算
地理的にまとまり、真に多様な経路と十分な予備容量を持つネットワークなら、フラットな設計を続ける合理性はある。広い地域にまたがり、復旧の遅い長距離容量に依存するネットワークなら、制御プレーンの限界より前に境界が必要になる。
NANOG の議論は二つの承認を切り分けた。一つは、プロトコルと機器が300ノードの状態を保持し計算できるという承認。もう一つは、そのトポロジーの障害範囲を組織が受け入れ、劣化時のトラフィックを制御できるという承認である。
従って、次に必要なのは3000ノードの追加事例ではない。想定する障害、最大影響範囲と時間、残存容量、通常の最短経路で足りない時の制御点を記した障害予算である。