AFI と SAFI: サービス名より先に組を読む

セッションが上がり、経路が現れるのを見ても、なお間違ったサービスを読んでいることがある。各アナウンスの先頭にある数字の組、アドレスファミリ識別子と後続アドレスファミリ識別子が、どのパーサがペイロードを読むか、どのテーブルが結果を保持するかを決める。組を誤れば、インポートポリシー、ルートターゲットの照合、ネクストホップの探索はどれも誰も広告していない構造に対して走る。以下の道筋はその組から始まり、転送結果で終わる。

経路がどのテーブルに入るかは二つの数字が決める

組は二度現れる。マルチプロトコル能力の内部で話者がファミリを広告する箇所と、そのファミリが運ぶすべての NLRI の手前である。したがってこれは経路の属性であり、起点ボックスの設定ではない。ベンダは Address family VPNv4 Unicast のような名前で印字し、数字は据え置かれたまま、言い回しだけがリリース間で移ろう。

四つの符号化がほとんどの企業案件を覆う。MPLS ラベルの付いた VPN-IPv4 には 1 と 128、IPv6 の相当物には 2 と 128、BGP で信号される VPLS には 25 と 65、EVPN には 25 と 70 である。第一の誤りは、すべての Layer 2 サービスが 25 と 65 の背後にあるとみなすことで、これが EVPN を隠す。第二は、二つの IP ファミリを、より長いアドレスを持つ一つのファミリとして扱うことだ。両者は別々に折衝され、異なるピアで受け入れられ得る。第三は、片方しか知らないリリースからテンプレートを複製したときに現れる。レジストリを引けば、サービスの名前に基づく推測より速く三つとも片付く。

四つの行は IANA レジストリからの例であり、レジストリそのものではない。見覚えのない番号に突き当たったら、それを中心にポリシーを組む前に調べる。

AFI 25 は無関係な二つの NLRI 形式を運ぶ

Layer 2 の二つのファミリはどちらも AFI 25 の下にあり、似ているのはそこまでだ。RFC 4761 section 3.2.2 の VPLS NLRI は長さ、経路識別子、VE ID、VE ブロックオフセット、VE ブロックサイズ、ラベル基底を運び、これらが合わせて pseudowire の端点とそのラベルを名指す。EVPN は AFI 25 を保ったまま SAFI 70 に移り、ペイロードは経路種別になる。イーサネット自動探索、MAC/IP 広告、包括的マルチキャスト、イーサネットセグメント、IP プレフィックスである。したがって同じバイトオフセットが二つのファミリで別の意味を持つ。片方のために書かれたパーサはもう片方を咎めずに読み、無意味な結果を出す。組は解釈が誤っていることを示す唯一の警告である。

一方のファミリで VE ブロックオフセットを意味するフィールドは他方に対応物がなく、MAC/IP 広告経路は EVPN にしかない。両方に当てはまるかのように属性を引くことが、キャプチャレビューを誤らせる道である。

キャプチャやベンダの表を渡されたら、その属性がどのファミリのものか尋ねる。次に、受け取る実装がそのファミリを支えていることを確かめる。データシートのサービス名ではない。二つのプラットフォームがどちらも VPLS 対応を名乗りながら、異なる信号ファミリを実装していることがある。組はそれらを分け、製品ラベルは分けない。

セッション自身のアドレスファミリは別の問いである

VPN-IPv6 は TCP 接続が IPv4 上を走るセッションで日常的に広告される。これは支持された設計であり、障害ではない。したがってセッション要約だけを読んでも、ピアがどの VPN ファミリを交換しているかは分からない。

NLRI ファミリ、トランスポートファミリ、転送ファミリは三つの独立した判断である。ルータはピアと IPv4 で話し、VPN-IPv6 の到達性を受け入れ、意図しなかった経路で到達できる IPv6 アドレスをネクストホップとする経路を導入できる。各層はそれぞれの確認を要する。広告が正しく見えるのに IPv6 宛先に届かないと報告する拠点は、たいていファミリの折衝ではなくネクストホップの解決を失っている。

セッションのアドレスファミリを単独で試し、次にそれが運ぶファミリを、次にコアが転送できるものを試す。三つを切り離しておけば、正しい広告を IPv6 が端から端まで動く証拠と読み違えるよくある誤診を防げる。広告は、一方のピアが他方にプレフィックスを伝えたことしか証明しない。

折衝済み、受信済み、インポート済み、インストール済み

期待する一つの経路について、四つの状態が順に成り立たねばならず、どれも観測できる。ファミリがそのピアと折衝されていること、経路が届くこと、ルートターゲットが意図した文脈にインポートすること、そして経路が入るようネクストホップが解決することだ。第一の状態を飛ばすと残り三つは答えられない。折衝されていないファミリは調べる経路を生まないからだ。Cisco 流のプラットフォームでは、ファミリ要約とピアごとの能力は別のコマンドである。

show bgp all summary
show bgp vpnv4 unicast all summary
show bgp l2vpn evpn summary
show bgp neighbors <peer-address> | include Address family

折衝はピアごとに印字される能力交換に現れ、ファミリが一つも並ばない確立済みセッションは求めたものを何も運ばない。インポートは拡張コミュニティとして運ばれるルートターゲットが決めるので、正しい組でもターゲットを打ち間違えればテーブルは空のまま残る。その後のインストールは受信側の文脈でネクストホップが解決するかにかかり、広告がどれも完璧に見えるのに失敗し得る。

データプレーンは最後に確認する。テーブルにある経路は主張であり、配送ではない。同じ四つの状態がどのファミリにも当てはまり、変わるのはコマンドとテーブル名だけだ。

ファミリの組が決して証明しないもの

組を正しく読むことは、その後に続く経路情報をどう解釈するかを教える。それが主張のすべてである。到達性についても、ポリシーについても、データプレーンの健全性についても何も言わない。両者を混同すると、誰も検証していないネットワークについて自信ありげな言明が生まれる。ルートターゲットの不一致と壊れたネクストホップは、組だけを見れば同じに見える。組は読み方の指示であり、判決では決してない。

エスカレーションするときは、組、ルートターゲット、解決済みのネクストホップを同じメモに置く。次の技術者はサービスの名前を読み直す代わりに、独立した三つを試せる。折衝がなければ即座に分かり、ターゲットが誤っていればインポートが目に見えて欠け、ネクストホップが未解決なら経路はあっても使えない。