大規模なハブアンドスポークVPNのサイジング：BGPを選ぶ前に数える

三千支店と聞くと経路の問題に見えるが、実際には簿記の問題として振る舞う。プレフィックスの総数は十分で計算でき、痛みを伴う数字はめったにそれではない。痛むのはセッションあたりの処理、共有コンポーネントが落ちたときの更新のバースト、そして転送が新しいトポロジーに再び一致するまでの時間だ。

だから計算は正しい順序で進める。関係を数え、プレフィックスと代替経路を数え、次に悪い一時間に何が起きるかを数え、そのあとで初めてプロトコルとプラットフォームを比較する。逆の順序でやると、この作業は経路上限をめぐる議論になり、テーブルの上の情報では誰も決着できない。

四つの予算、一つではない

それぞれの予算は別の問いに答え、それぞれが別のプラットフォームで制約になり得る。分けて書けば、一つの大きなプレフィックス数が設計全体の代わりをすることはない。

最後の二つは設計レビューで飛ばされやすい。定常状態でメモリに余裕をもって収まるネットワークでも、四百の支店が二分以内に再接続すると振る舞いが悪くなることがある。処理が制御プレーンより速く到着するからだ。バーストの大きさを数値で書き、サービスをどのくらい劣化させてよいかも併記する。これで漠然とした不安が、実際に実行できる試験になる。

四つすべてにプラットフォームの問いも隠れている。暗号化、転送、経路制御が同じCPUを共有するのか、別の経路を持つのか。同じ経路容量の二つの機器でも、バースト時の挙動は大きく異なり得るし、データシートは買うのがどちらかをほとんど語らない。

自分の数字で計算する

架空の設計を取る。3,000支店、集約前に各三つのプレフィックス、冗長性のために支店ごとに二つのハブ。ハブのペアは要約前に約9,000の支店プレフィックスを保持する必要があり、各支店が両方とピアを張るなら、設計は6,000の支店-ハブセッションを意味する。

次に、プレフィックスではない部分を足す。各セッションは何も変わらなくても状態と定期メッセージを運ぶ。速い切り替えを期待するなら、各ハブはプレフィックスごとに複数の経路を保持でき、代替経路の数が選択数より多くなり得る。そして各スポークの見え方は別個のポリシー判断だ。すべての支店に他のすべての経路を渡すと、ハブ側の数では見えない形で処理が倍増する。

これらは設計の会話のための計画値であり、どの製品の測定でもない。この作業の役に立つ成果は曲線の形であり、特定のルーターがどこで音を上げるかという主張ではない。

BGPがもたらすもの、IGPがもたらすもの

BGPは、ルーターが受け取ったもの、選んだもの、広告するものを分け、それぞれがポリシーで制御される。これは支店網にまさに必要なことで、スポークは通常、デフォルト経路と中央サービス、そしてごくわずかしか見るべきではない。最終テーブルだけを数えると代替経路と広告が隠れ、冗長性を足したときに増えるのはまさにその部分だ。

IGPが自動的に誤りとは限らない。トポロジー、エリア構造、隣接モデルがサービスに合うなら、リンクステートプロトコルは素早く収束し、ポリシーの足場も少なくて済む。罠は、BGPと同じ近隣ごとのエクスポート制御を表現できると仮定することだ。OSPFエリアはフラッディングの境界であり、一つの支店に付けられるフィルターではない。

いずれにせよ、まず可視性のモデルを決める。デフォルト、中央サービスの要約、支店の完全な詳細は三つの異なる製品であり、より具体的な障害を隠す要約は、障害時に発見するのではなく書き留めるべき設計判断だ。

定常状態ではなくバーストを試験する

実際に予想する障害、たとえばハブの停止、地域WANの事象、あるいは半数の拠点を一度にオフラインにする保守時間帯のまわりで比較を組み立てる。支店の視点でアプリケーションも含めて復旧時間を測るが、数秒で収束する制御プレーンもセッションの再確立に数分かかるなら意味が小さい。

show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPF

プラットフォームが静止時ではなくバーストのピークで何をするかを記録し、セキュリティ機能を有効にして繰り返す。静かなテーブルだけを見せる実証はメモリの試験であり、メモリが面白い数字だったことは一度もない。