要約

  • MSDP mesh-group 内では、あるメンバーから受けた Source-Active メッセージを他のメンバーへ再転送しない。発信者が全員へ直接送る完全メッシュであることが、この抑制の根拠である。
  • セッション欠落やメンバー認識の不一致は、誤った SA を作らなくても知識を分断する。SA が見えないことは、源がないこと、受信要求がないこと、あるいはデータが流れていないことの証明にならない。

障害はパケットを壊さなかった

三台の RP が同じ mesh-group に属している。A は新しい (S,G) を知り、B はそれを受信した。C との一つのピアリングだけが、設定ミスで成立していない。B は RFC 3618 の規則に従い、同じ mesh-group の C へ SA を再転送しない。A が全員に直接送ったはずだからだ。

どの SA も破損していない。peer-RPF 違反も発生しない。B のキャッシュは新しく、A の送信カウンタも増える。それでも C は源を知らない。障害は誤ったメッセージではなく、正しい抑制と破れた前提の組み合わせにある。

RFC 3618 は 2003 年 10 月に Experimental として公開された IPv4 の MSDP 仕様であり、Internet Standard ではない。PIM-SM ドメイン間で active source の情報を共有し、各ドメインが独自の RP を維持できるようにする。実装経験を記録した仕様だからこそ、前提が運用事実と一致しているかが重要になる。

mesh-group はトポロジー契約だった

通常の peer-RPF 洪水では、SA は発信 RP から離れる方向へ隣接ピアに送られ、受信側は RP への経路に対応するピアから来たコピーだけを受け入れる。mesh-group は内部の重複を減らすため、別の規則を加える。

同じグループのメンバーから SA を受けた RP は、その SA をグループ外へは転送するが、グループ内の他メンバーへは送らない。外部ピアから来て peer-RPF を通った SA は、mesh の全メンバーへ送られる。この対称性が成り立つには、各メンバーが互いに直接ピアリングする必要がある。

「mesh-group」という設定名は、その必要条件を実測しない。構成ファイル上のメンバー集合、実際に Established である TCP セッション、使用される送信元アドレス、認証方針、相手側のメンバー認識が一致して初めて、完全メッシュという運用事実になる。

したがって、監査対象は名前ではなく辺である。全ペアの期待接続と現実接続を比較し、片方向の認識差も記録しなければならない。

SA 不在には複数の原因がある

RP はローカルの新しい送信元を知ると、source address、group address、RP address を含む Source-Active メッセージを作る。受信ドメインに (*,G) の関心があれば、そこから (S,G) Join が起動され、PIM が源方向の木を作る。

C のキャッシュに SA がないとき、少なくとも次の仮説がある。源が停止した。A が源を観測していない。A が SA を生成しなかった。A-C セッションがない。別の経路を通ったコピーが peer-RPF で落ちた。フィルターまたは状態上限が拒否した。mesh の抑制により B が補完しなかった。キャッシュが期限切れになった。

これらは同じ「行がない」という画面になるが、責任主体も修復方法も異なる。源を再起動すべき場合もあれば、ピアリングを直すべき場合、ポリシーを修正すべき場合、何もしなくてよい場合もある。

欠如を根拠にするなら、観測範囲を明記する必要がある。「C の SA cache に、時刻 T、設定版 V、接続集合 E のもとで項目がなかった」は証拠である。「源は存在しない」はそこから自動的には得られない。

キャッシュ再送はメッシュを治すとは限らない

MSDP は SA のキャッシュを必須とし、RP は active とみなす源を 60 秒周期で再広告する。接続成立時には、キャッシュされた SA を送ることが推奨される。これにより一時断の回復が速くなる。

しかし、どの接続が復旧したかで効果は異なる。欠けていた A-C が戻れば、A のキャッシュ再送が C を更新できる。B-C だけが戻っても、同一 mesh-group 内の抑制規則により B が A の SA を送らない可能性がある。セッションが Established になった事実と、欠けていた source knowledge が埋まった事実は別である。

さらに、再接続直後の SA は新しい源観測ではなくキャッシュ再生かもしれない。受信時刻を source-last-seen と表示すると、回復操作が源の活動を新しく見せる。キャッシュの起源、最初の受信、最後の再広告、再生理由を分けて保存すべきである。

Anycast RP は共有名と個体証拠を分けた

RFC 3446 の Anycast RP は、複数の RP が同じ anycast address をサービスとして提示し、MSDP で source state を共有する。DR や受信者は近い RP に到達でき、障害時の集中点を減らせる。

ところが SA の RP address に anycast address を使ってはならない。peer-RPF がメッセージの実際の発信元へ向かう経路を選べなくなるからだ。SA では各 RP の個別アドレスを用いる。

これは重要な設計原則を示す。利用者向けのサービス識別子は共有できても、制御証拠の発信者は個別に帰属できなければならない。anycast address が到達可能であることは、全 RP のキャッシュが同期したことを示さない。フェイルオーバー後に同じ source set を知っているか、同じ Join を作れるか、受信が継続したかを別に測る必要がある。

peer-RPF と認証も完全性を作らない

mesh の外では peer-RPF が SA の受入方向を選ぶ。これは洪水のループを制御するための規則であり、source truth の審査ではない。RFC 4611 が示すように、BGP、IGP、ピアアドレス、default peer などで判断経路は変わる。

RFC 3618 は TCP MD5 Signature Option の実装を要求する。期待した秘密を持つピアとの接続であることや、途中の単純な改変を防ぐ助けになる。しかし、認証された RP が誤った観測や広すぎるポリシーを持つ可能性は残る。ピアの身元と SA の意味は別の証拠である。

状態爆発に対しては source/group filter、SA-state 上限、生成レート制限が推奨される。これらは資源保護の決定である。filter pass は source authorization ではなく、limit drop は source false の証明でもない。

運用画面は、接続認証、peer-RPF 結果、mesh 完全性、filter 判定、cache age、PIM state、packet arrival、application outcome を一つの健康値に畳み込むべきではない。

木ができても受信はまだ証明されない

SA を知った RP は、ローカルに関心があると (S,G) Join を起動する。そこから先は PIM の RPF 選択と枝状態に依存する。木が作られ、パケットが最後のルータへ届き、受信ホストへ配られ、アプリケーションが正しい内容として受理するまで、証拠は連続していない。

SA は任意で IPv4 パケットを内包でき、木が完成する前の短い burst を運べる。最初のデータが見えたとしても、その後の持続的な木が成立したとは限らない。逆に、内包データがなくても通常の Join でサービスが成立し得る。

Heng Lu の running-code の考え方は、仕様名より実装された挙動を見るよう促す。ただし running code も観測範囲以上のことは証明しない。SA を正しく送受信するコードは、アプリケーションの成功まで観測していない。

RFC 3618 が提供したのは、ドメインを越えて source knowledge を動かす最小共通機構である。その知識が欠けたとき、最初に問うべきは源の有無ではない。どの前提が、その沈黙を作ったのかである。

Sources