要約

  • RFC 9521 では、開始時のセッション識別に VNI と VAP の内側アドレスを用い、遠端 Discriminator が非ゼロになった後はその値だけで多重分離する。
  • Up は当該制御交換の継続性を示すが、別の ECMP 経路を通るテナント通信、全 VAP 組合せ、権限、アプリケーション回復までは示さない。

二つの NVE にそれぞれ多数の VAP があるとき、運用者は全組合せを測るか、代表セッションへ圧縮するかを選ぶ。圧縮は必要な設計になり得る。問題は、圧縮後の十個の緑が、観測していない百個の組合せまで緑に塗ることである。

セッションの名前は途中で変わる

RFC 9521 は非同期 BFD を VAP 間で動かす。通常データが Ethernet なら内側 Ethernet/IP/UDP/BFD、IP なら内側 IP/UDP/BFD を使う。両端は同じ VNI に対応し、同じデータカプセル化方式を採用しなければならない。

Your Discriminator がゼロの初期段階では、受信側は文脈を使う。Ethernet 形式なら VNI、送受信 MAC、送受信 IP、IP 形式なら VNI と送受信 IP が検索キーになる。UDP 送信元ポートを補助に使ってもよい。識別できなければ廃棄し、管理例外を報告する。

非ゼロになった後は規則が反転する。セッションは Discriminator だけで多重分離しなければならない。したがって監査ログには、初期タプルから Discriminator へ移る瞬間が必要だ。最終値だけでは何に結び付いた値か分からず、アドレスだけでは再起動後の値再利用を見抜けない。設定世代と再起動境界も同じ記録に属する。

正しい VNI は権限証明ではない

受信側は Geneve 検証、VNI と宛先 VAP の対応、Protocol Type、UDP 宛先、TTL または Hop Limit を確認する。O ビットは 1、C ビットは 0 である。不一致のパケットは BFD に渡さない。

これはプロトコルの取り違えを防ぐが、テナントの所有者や変更権限を証明しない。Geneve 自体には固有のセキュリティ機構がなく、RFC 9521 は BFD 認証を推奨する。認証済みパケットであっても、経路を外し、顧客を移し、SLA を判定する権限は別途必要である。

N² の負荷を減らすと、見える面も変わる

両 NVE に N 個の Ethernet VAP があれば N² セッションになり得る。RFC 9521 は同時セッション数の制御を勧め、全 VAP を覆う N セッションで足りる場合を示す。ここで必要なのは「覆う」の定義だ。各 VAP が一度観測されることと、全 VAP ペアが観測されることは同じではない。

VNI が同じでも、BFD とデータが同じ ECMP メンバー、LAG、キュー、ACL、サービスチェーンを通るとは限らない。BFD Up と一部データ障害は両立する。逆にプローブ用キューの圧迫による Down と、短時間のアプリケーション成功も両立し得る。

そのため RFC 9521 はレートを要件に含める。BFD が本当に輻輳制御されていない限り、トラフィック管理された環境で送信率を用意し、輻輳と誤検知を避ける。Down は速い観測だが、レート、キュー、損失文脈なしには故障箇所の特定ではない。

七つの記録を接続する

必要なのは、NVE/VAP/VNI マッピング、ゼロ Discriminator の初期識別、非ゼロ値への遷移、プローブの実際の転送処理、VAP とペアのカバレッジ、通知後に権限を得て実行された操作、代表テナント通信とアプリケーション結果である。

RFC 9521 はこの鎖の中央を標準化する。標準が主張しない部分をダッシュボードが補ってはならない。「このセッションが Up」という文は強い。「Geneve サービスが健全」という文には、さらに下流の証拠が要る。

情報源