MPLS VPN における IPv6：三つの選択肢であり、一つのアドレスファミリではない
顧客 VPN の経路、PE 間の BGP セッション、コアのトランスポートは別々の決定である。セッションは一方のファミリで動きながら他方を運べる。
「IPv6 BGP 上で IPv6 L3VPN を動かせ」と設計レビューで言うと、その一文には三つの別々の決定が隠れている。どのプレフィックスが顧客の VPN に属するか、どのアドレスがプロバイダーエッジ間のルーティングセッションを運ぶか、どのコアがラベル付きパケットを運ぶかは、それぞれ独立した選択である。すべてを IPv6 にすることも混在させることもでき、混在は意図的に許されている。この三つを解きほぐすことが、曖昧な要件をプラットフォームで検証できる何かに変える。
三つの仕事を切り分ける
第一の仕事は顧客経路、つまり一つの VPN ルーティングコンテキストに属し、他のどのコンテキストにも漏れてはならない IPv6 プレフィックスである。第二は、それらのプレフィックスを交換するプロバイダーエッジルーター間のルーティング接続である。第三は、ラベル付きの顧客パケットをコア越しに遠隔エッジまで運ぶトランスポートだ。そのうち一つだけを名指ししても、まだ設計にはならない。
| Job | The question it answers | What confusion looks like |
|---|---|---|
| Customer VPN routes | Which IPv6 prefixes belong to each VPN context, and how are they kept apart? | Prefixes leak into the global table and between customers |
| PE-to-PE BGP session | Which addresses carry the routing connection between the two edges? | A session-family mismatch gets chased as a core transport fault |
| Transport to the remote PE | How does the chosen core move the labelled packet to the far edge? | A route is present and unforwardable in the same moment |
どの仕事にも独自のアドレスファミリと故障の仕方があり、多くの場合チームも別だ。表が役立つのは、設計文書の一文が三つの行を一つに押しつぶしがちだからにほかならない。
経路のファミリは IPv6 ユニキャストではなく VPN-IPv6 だ
RFC 4659 BGP/MPLS IPv6 VPN ファミリを定義しており、そこへの所属は IPv6 という語が示すより限定的である。そこでの経路は IPv6 プレフィックスに結合された経路識別子であり、AFI 2 と SAFI 128 の下で符号化される。通常の IPv6 ユニキャストは別のファミリなので、looking glass でプレフィックスに見える広告が同じ対象とは限らない。ファミリを取り違えることが、この設計が最初につまずくところだ。
違いが効くのはエッジであり、経路は何かをする前に正しい VPN コンテキストに収まらなければならない。プレフィックスを受け取ったことは交換が起きた証明であり、インストールについては何も語らない。その隙間が、セッションは上がっているのに顧客はまだ暗いままだという定番の報告を生む。
セッションは VPN とは別のファミリで動いてよい
二つのエッジ間の BGP 接続に、VPN 自身のファミリを使わせるものは何もない。仕様は IPv4 でも IPv6 のセッションも認めており、IPv6 VPN のトランスポート自体が両方のコア種別の上で定義されている。したがって IPv6 セッションは、運ぶ対象のファミリについて何も語らず、データプレーンも選ばない。三つの独立したビットであり、設計はその三つを別々に持つべきだ。
それは解放的であると同時に、同じ呼吸で読み違えやすい。IPv6 の顧客経路は IPv4 アドレスのセッションに乗ることができ、IPv4 の経路は IPv6 のセッションに乗ることができ、その条件はプラットフォームが組み合わせを支え、ネクストホップが解決できることだ。起きてはならないのは、設計文書であれ後からサービスを証明する監視であれ、セッションがペイロードを暗示することだ。
IPv4 コア上のネクストホップには独自の符号化がある
VPN の下のコアが IPv4 のとき、経路は入口エッジがそのまま使えるネクストホップでは現れない。IPv4 にマップされた IPv6 の形で届き、下のトランスポートが IPv4 のときに仕様が出口エッジを表すのはこの形である。入口ルーターはそのマップされたアドレスを、コア越しに実際に到達できる何かに変えなければならず、解決こそが静かに失敗する段階だ。
これは装置間でコピーする文字列ではなく、転送の依存関係として読むべきだ。実際に運用しているプラットフォームで、広告されたネクストホップが使える経路に解決すること、ラベルスタックが受け入れられること、宛先が意図した VPN コンテキストに収まることの三つを確認する。どれか一つが欠ければ健全に見えて何も転送しないセッションが残るのだから、この確認は後日のインシデントではなく受け入れ試験に入る。
要件は四行で書く
試験する価値のある要件は、VPN のファミリ、セッションのトランスポート、ネクストホップの符号化、コアの構成という四つを名指しする。続いて、交換、インストール、ラベル解決、戻り経路を通して端から端まで追う顧客プレフィックスを一つ名指しする。「IPv6 BGP をサポート」では四つのどれも覆えず、食い違いが実際どこにあるかを隠してしまう。
VPN-IPv6 の交換を伴わない健全なセッションは不完全であり、転送が機能しないまま受け取った VPN 経路も同じだけ不完全だ。これらを別々の受け入れ行として保つことは、失敗している行がすでに書かれているので次回のトラブルシューティングを短くする。