VRFごとのラベルか、プレフィックスごとか。本当の容量コスト

二つの設計が、同じプロバイダーコア上で同じ顧客プレフィックスを広告している。一方はプレフィックスごとにラベルを割り当て、もう一方はVRF全体に一つのラベルを割り当てる。そして後者はどのスライドでも安く見える。ラベル数は確かに実在するが、通常最初に尽きる予算ではない。両者を選ぶことは、一つではなく四つのリソースを数えることであり、ラベルはその中で最も小さい。

選択は、ラベルを外した後に出口ルーターがパケットをどう扱わなければならないかにも依存する。意思決定を導くべきは、ラベルの算術ではなく、その機能的な違いである。

各割り当てが実際に節約するもの

プレフィックスごとの割り当ては、転送情報をラベルに載せる。出口ルーターは宛先検索なしでパケットを正しい隣接へ直接送れる。そのため大規模なVRFルート集合に対してうまくスケールし、各VRFで広告されるすべてのプレフィックスについて一つのラベルを消費する。VRFごとの割り当て、たとえばJunos vrf-table-labelは、ルーティングインスタンスごとに一つのラベルを広告し、そのラベルをVRFテーブルの選択に使う。その後、ルーターはテーブル内でIP検索を行う。

それはチューニングノブではなく、実際のアーキテクチャの違いである。VRFごとのラベリングは、より小さなラベル空間とより単純なラベル広告をもたらすが、その代償は一回の検索と、宛先について何も語らないラベルである。プレフィックスごとのラベリングは、出口ラインカードにより多くの情報を事前に与え、運ぶルートに比例してラベルを消費する。

ラベルの台帳は小さいほうだ

MPLSラベルは有限だが、ラベル空間は十分に大きいため、通常のサービスプロバイダーが数千のプレフィックスで使い切ることはない。VRFごとのラベリングが本当に役立つのは、ハードウェアのラベルテーブルが小さいプラットフォームや、一つのVRFが完全なインターネットフィードを運び、プレフィックスごとのラベルがルート数だけラベル需要を増やす設計である。これらは実際の制約であり、この機能が存在する理由でもある。そのどれもテーブル内のプレフィックス数についてではない。

選ぶ前に、サービスとトランスポートの両方のラベルを数えよ。VRFごとの設計でも、ループバックと経路上の各ホップにはトランスポートラベルが必要であり、隣接の状態も必要である。設計概要がサービスのラベルのみを数えているなら、節約は間違った台帳で測られている。

ルートフィードはラベルより先にメモリを食う

受け取るすべての経路は、VRFが一つのラベルを使うか一万使うかにかかわらず、コントロールプレーンのメモリ、更新処理、収束時間を消費する。VRF内の完全なインターネットフィードが高くつくのは、BGP経路、RIB、FIBエントリ、およびその背後での変動のためであり、テーブルの前にあるラベルのためではない。同じフィードは、そのテナント内でのルートリークやポリシーミスの影響範囲も広げる。

だから、顧客が実際に何を必要としているかを問うことだ。契約がプライベートサイトとデフォルト出口であれば、完全なテーブルは要件を増やさずにコストだけを増やす。それは商業的な問いであり、前の設計から受け継いだ仮定ではなく、書かれた回答に値する。サービスがポリシーやローカル出口の選択のために本当にフィードを必要とするなら、独自の容量予約と独自の障害時の振る舞いを備えた明示的な項目にすることだ。

VRFごとのラベリングが正しい既定となる場合

プラットフォームがサポート対象として文書化している場合、VRFのルート数が多い場合、出口の検索コストがトラフィックプロファイルにとって許容できる場合には、良い既定である。転送から最後のマイクロ秒を絞り出すことよりも運用の単純さを重視する場合にも自然な選択である。なぜなら、テナントごとに一つのラベルのほうが、プレフィックスごとに一つのラベルより説明と監査が容易だからだ。

プラットフォームの文書がこの機能を特定のハードウェアやリリースの制約に結びつけている場合、あるいは設計が出口でのプレフィックスごとの転送判断に依存する場合には、間違った既定である。振る舞いを仮定する前に、プラットフォーム自身のstatementリファレンスを読むこと。Junosのコマンドは文書化されているが、実際に配備を決めるのはその周囲のハードウェアとリリースの制限である。

弁護できる予算

容量の根拠は五つの別々の数字として組み立てよ。受信経路、選択されたルート、インストールされた転送エントリ、サービスのラベル、トランスポートのラベルである。さらにネクストホップと隣接の状態、テナント数、冗長化モデルを加える。単一のVRFのハッピーパスのスナップショットは規模の数字ではなく、名目上のラベル空間のサイズは利用可能なハードウェアテーブルではない。

次に、定常状態だけでなく障害モードにも合意せよ。フィードが半分増えたとき、テナントが二つ目のVRFを追加したとき、あるいはテーブルのサイズを変えるためにプラットフォームの再起動が必要なとき、何が起こるか。それらの問いに耐える予算は、紙の上でしか動かないラベル数より価値がある。

出口の動作とプラットフォームの制限から割り当てを選び、次にルートフィードを明示的なサービス判断にせよ。ラベルは設計の見える部分であり、ルートは毎日支払わなければならない部分である。