L3VPN の引き渡し：プライベートルート、デフォルト、それともフルフィード？

回線は上がり、VRF も設定済みで、プロバイダーから設計の残りを決める短い質問が来ます：カスタマーエッジは何を受け取るべきか？よくある答えは三つあり、どれもラベルスタックが存在するという事実から導かれるものではありません。それらは、トラフィックが拠点からどこへ出るかに関するサービス上の判断です。

引き渡しを順にたどるのが、これを正しく終える最も安い方法です。まず何にも一致しないトラフィックの扱いから始め、次にプライベートプレフィックスとその障害時の挙動を書き留め、そのあとでようやく、どれだけ大きなフィードを運ぶ用意があるかを話します。

誰も計画していなかったトラフィックから始める

プレフィックスリストが現れる前に一つ質問をしてください：パケットがどのプライベートルートにも一致しないとき、それはどこへ行くべきでしょうか？独自のインターネット回線を持つ拠点は通常ローカルのデフォルトを保持するため、通常のウェブトラフィックはローカルのファイアウォールから出て、プロバイダーには一切触れません。その設計では、VPN は遠隔のプライベートサイトだけを運び、より具体的なプレフィックスが選択を担います。

中央の出口を使うことを意図した拠点は逆のケースです。そこではデフォルトがサービス側を指し、転送、戻りルーティング、および変換はプロバイダーまたは中央サイトが担います。その担い手を置かずに「VPN にデフォルト」と言うと、名前解決はできても何にも到達しない拠点が出来上がります。

二つの設計は、ルーティング障害がどう見えるかが異なり、だからこそ当て推量は高くつきます。ローカルのデフォルトでは、失われたプライベートルートはそのトラフィックをインターネットへ送り、そこでファイアウォールに捨てられるか、さらに悪ければ意図しない何かが応答します。中央のデフォルトでは、同じ喪失がインターネットアクセスを完全に奪い、チケットは「拠点全体が落ちている」という形で届きます。どちらの障害もそれ自体が誤りではありませんが、販売したサービスに合うのは片方だけで、BGP の設定だけを見てもどちらを構築したかは分かりません。

プライベートプレフィックスを障害ケースとともに書き出す

拠点が到達すべきプレフィックスを列挙し、どれが集約されているかを記します。一ビットでも広すぎる集約は未知の宛先を VPN に引き込みますが、それは遠側が実際にそれを所有し転送している場合にのみ問題ありません。

次に、プライベートサービスが失敗したときの意図した挙動を記述します。保持された破棄ルートは、トラフィックを許可されていない経路に流さず、きれいで予期どおりの停止を生みます。フローティングデフォルトはバックアップ経路へ移ることで可用性を保てますが、そのバックアップ経路がそのトラフィックを運ぶことを許可されている場合に限ります。

可用性と許可されたフォールバックは、引き渡し文書の中で二つの別個の要件として保ってください。それらを統合してしまうチームは、合意したポリシーが実装されたかを確認する代わりに、拠点は落ちるべきだったかを論じ合うことになります。

CE が実際にインストールしたものを確認する

設定の意図と転送状態はしばしば食い違うため、検証はインシデントレビューではなく引き渡しの中に属します。IOS-XE のカスタマーエッジでは、以下の三つのコマンドが三つの異なる問いに答えます：何が提示され、何が受理され、何が実際に使われているかです。

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

引き渡しの当日に、一か月後ではなく、誰かがまだ合意内容を覚えているうちに三つとも実行してください。最初の出力は soft-reconfiguration inbound か保存されたルートリフレッシュに依存し、どちらもなければ CE は拒否したものを示せません。二つ目はポリシー適用後に受理された経路と最良経路を示します。三つ目はデフォルトが実際どこへ行くかを教えてくれ、それが引き渡し全体で最も有用な一行です。

拠点がデュアルホームなら、二台目の CE でも同じ確認を行ってください。二つのエッジ間で受理が非対称になるのは「片方のサーバーからは動くがもう片方からは動かない」のよくある原因で、対称に見える設定差分では見えません。

より大きなフィードを前提にせず適格性を判断する

ポリシールーティングやプレフィックスで振り分ける中央出口のために、VRF の内側でインターネット経路情報を本当に必要とする顧客もいます。それは述べ、範囲を定め、価格を付けるべき要件であり、隠れたデフォルトではありません。RIB と FIB のメモリ、更新のための CPU、フィルターの保守、そして結果としてのテーブルの担当者が伴います。

容量の議論はどちらの方向にも誤ります。フルテーブルは VRF の内側で禁じられてはいませんし、無料でもありません。同様に、古い経路数から現在のコストを推測することはできず、ラベル割り当てを小さくしても経路を保持するコストは消えません。

BGP/MPLS IP VPN の仕様は、VPN サービス自体の隣でいくつかのインターネットアクセスの構成を論じており、すべての顧客にフルテーブルやデフォルトを必須とは宣言していないので、「標準的な慣行」という主張が出たときにはその節を指す価値があります：RFC 4364。

引き渡しの最後に、広告した集合、受信した集合、選択した集合を合意した出口ポリシーの隣に記録し、プライベート宛先を一つ、意図したパブリック宛先を一つ、経路喪失のケースを一つ試してください。それら三つの試験の署名済み記録は、ほとんどのネットワークがどうしているかというどんな言明よりも多くの議論を決着させます。