要約

  • 10月27日付のIETF個人ドラフトには、同じプレフィックスP1を持つ四つのVPN経路が登場する。PE1はRD22から来た経路をVPN11へ取り込む。しかしBMPの監視記録が示すのは受け入れ先のRD11で、送り元のRD22は消える。
  • 改訂02は遠隔VRFの識別情報を添える案をEVPN Type-5にも広げた。送信も収集側での利用も任意だ。経路の出所を監視上の必須事項にするかは、ネットワークを運用する側の判断になる。

同じ住所を名乗る四つの経路

草案の例では、PE1にプレフィックスP1の候補が四つ届く。PE2上のVPNインスタンスRD21、RD22、RD23から三つ、PE3上のRD31から一つだ。いずれもVPN11が取り込めるroute targetを持つ。PE1は例としてRD22の経路を選ぶ。そこで監視サーバーへ送られるBMP Loc-RIBの報告には、P1、ネクストホップ、受け入れ先であるRD11が並ぶ。RD22という送り元の名は並ばない。

実際の障害報告ではない。だからこそ、例の構造を正確に読む価値がある。監視室は「VPN11にP1がある」と答えられる。RD21からRD22へ出所が替わったかを問われると、同じ報告だけでは答えられない。三つの候補はPE2から来るため、ネクストホップだけを眺めても識別できない。境界を越えた選択が、到着だけを記録した紙に変わる。

IETF Datatracker上、この文書は個人提出のInternet-Draftだ。RFCとして承認された仕様でも、実ネットワークでの漏出を示す資料でもない。ここで問うべきは技術案の権威ではなく、監視の権限だ。受け入れ先しか言えない仕組みで、誰が「インスタンス間の経路移動を把握している」と言い切れるのか。

選択を見せる表、出身を隠す表

RFC 9069は、BGPのローカルな決定過程が選んだ経路をLoc-RIBとしてBMPへ出す方法を定めた。収集側が全入力候補から選考を再計算しなくてよいという実益がある。一方、VPN経路の報告ではpeer addressがゼロで埋められ、peer distinguisherは報告対象のローカル・インスタンスを指す。今回の例ならRD11だ。PE1が選んだ候補のRD22までは、その欄で表現できない。

ルーターが出所を知らなかったという話ではない。PE1は候補を受け取り、RD22を選んでいる。足りないのは監視サーバーへ渡された選択結果の来歴である。監査担当者が「この経路をどのVRFから取り込んだのか」と尋ねるなら、到着先の名だけを返すのは質問違いになる。

草案はRemote VRF Information TLVを提案する。アドレス族、遠隔BGP識別子、遠隔側のroute distinguisherをLoc-RIBの経路報告に載せる。RD11は受け入れ先、RD22は選ばれた経路の元のインスタンス。二つを同じ記録に置けば、監視室は少なくとも出所をたどる入口を持てる。遠隔VPN経路のMPLSラベルやSRv6 SIDを載せる別の任意TLVもあるが、それらは出所の名札の代わりにはならない。

route targetによってVPN11への取り込みが可能になっていても、どのインスタンスからの取り込みを監視したいかは運用上の別問題だ。同じP1が同じ宛先表に残ったまま、供給元がRD22からRD21へ替わることを考えてみればよい。宛先だけの画面は静かなままだろう。画面の表示が誤りだからではない。肝心の変化を表示する材料が残っていないからだ。

EVPNでは数えられても、名指しできない

改訂01はVPN経路の案を記していた。改訂02はEVPN Type-5のインスタンス間取り込みへ同じ考えを広げる。草案ではPE2のEVI21から来たP1が、IRBを通じてPE1のEVI11へ入る。通常の監視報告に見えるのはEVI11内のP1とPE2へのネクストホップ。EVI21の名は残らない。提案TLVはAFI 25、SAFI 70、遠隔BGP識別子、RD21を運ぶ。

別のEVPN BMP統計草案には、EVI単位で経路を数える設計がある。インスタンス間を移動した経路の数は変化の兆しになる。しかし「このP1を供給したEVIはどれか」という問いは、経路ごとの出所がなければ解けない。人数を数える窓口と身元を確認する窓口は、同じ仕事をしていない。

さらに、Loc-RIBの観測はBGPが選んだ経路を示す。転送表への反映、パケットの通過、利用者のサービス結果までは示さない。出所欄が増えれば選択の説明は強くなるが、到達結果の証明に化けるわけではない。監視ができることを一段ずつ区切ってこそ、使える証拠になる。

任意の欄は二度消せる

提案では拡張に対応したBMP送信側が遠隔VRF情報を添えてもよく、収集側は従来のRFC 9069処理との互換性を保ったまま無視してもよい。IANAの情報タイプも草案段階では未決定だ。仕様案が公開されたこと、BMPセッションが接続中であること、監視システムが健康と表示すること。そのどれも、RD22が保存され検索できる事実を作らない。

草案のセキュリティ節は、認可され信頼できる監視装置とだけセッションを張るよう求める。通信相手の境界は大切だ。だが受信側が遠隔RDを捨てるか、何日残すか、欠落を異常として扱うかは運用者の側に残る。緑の接続ランプの下で、監査に必要な一列だけが消える設計も成立する。

Sources