要約

  • RFC 5240 の四つの表には、候補設定、学習した当選状態、RP集合が収められる。その一部は read-create であり、単なる受動的テレメトリーではない。
  • 当選フラグ、残り時間、通知はいずれも一台の装置と一つのゾーンの証言である。ドメイン全体の収束や実際のマルチキャスト配送は別に立証しなければならない。

見る窓と動かす取っ手

BSR は、マルチキャストのグループをどの Rendezvous Point に対応させるかという情報を配る。RFC 5240 はその仕組みを、Candidate-RP、Elected-BSR の RP 集合、Candidate-BSR、学習済み Elected-BSR という四表で管理できるようにした。

ここで重要なのは、表の整然さではなくアクセス種別である。候補のアドレス、優先度、広告間隔、保持時間、ハッシュマスクには作成・変更できる項目がある。同じ SNMP の入口が「誰が選ばれたか」を答え、「次に誰が選ばれやすいか」を変える要求も受ける。

GET の結果は、あるエージェントがある時刻に返した観測である。SET の成功は、要求を受理したという記録でしかない。そこから選挙、Bootstrap メッセージの配布、他ルータの学習、RP選択、データ配送へ進むには、それぞれ別の証拠が要る。

候補の意図と、観測された当選

Candidate-BSR の行は、このルータが使うアドレス、競争する優先度、広告するハッシュマスク長を持つ。ローカル候補が当選中かどうかは読み取り専用である。Bootstrap タイマーも読み取り専用で、当選していないときはゼロになる。

したがってゼロは停止の証拠ではない。TRUE も全ルータの合意ではない。学習済み Elected-BSR 表にあるアドレス、優先度、マスク長、最小失効時間も、その装置がそのゾーンについて現在持つ見解だ。

収束の主張には、独立した複数ルータの一致か、配布経路でのパケット観測が必要になる。サービス正常性には、さらにグループ–RP対応、PIM Join、実データの到達を結ばなければならない。

数値の向きが同じではない

Candidate-BSR では数値が大きいほど優先度が高い。Candidate-RP では数値が小さいほど優先される。全項目に同じ「優先度を一つ上げる」処理を行う自動化は、片方で意図と逆の結果を生む。

RFC 5240 のセキュリティ節は、この書き込みの影響を具体的に述べる。高い優先度の Candidate-BSR を作成・変更すれば Elected BSR の機能を奪い得る。より小さい優先度値の Candidate-RP は、特定のグループ範囲で自身を選ばせ得る。どちらもサービスを妨げ得る。

権限は「SNMPを使える」だけでは粗すぎる。トポロジーの閲覧、通知の受信、行の作成、アドレスや優先度の変更、削除は別権限である。SNMPv3 の認証と秘匿は通信を守るが、誰にどの操作を許したかまでは自動で正しくしない。

RP集合は配布前の材料である

Elected BSR は Candidate-RP 広告で得た対応やローカル設定を表に置く。その後、ローカルポリシーを適用して、一部または全部を Bootstrap メッセージへ入れる。表にあることと、配布されたことは同義ではない。

配布後にも境界が続く。受信、受理、インストール、選択、Join、データ転送である。単一の「RP active」という表示は、この工程を一つの成功に圧縮する。監査では、表の版、ポリシー、送受信パケット、各受信者の状態、トラフィックを別々に保持すべきだ。

索引も値の一部である。アドレス種別、ゾーン、グループプレフィックスと長さが行を特定する。プレフィックス長より後のビットがゼロでなければ別行になる。IPアドレスだけ抜き出したログは、正確でも帰属不能になる。

通知は一票でもない

任意の診断グループは、候補が勝ったときと現職が負けたときの通知を定義する。通知はローカル遷移の時点を残せるが、実装は任意で配送保証もない。通知がない理由は、変化なし、未実装、未購読、権限による遮断、配送損失のいずれでもあり得る。

通知が届いても、ドメインの合意ではない。一つのエージェントがイベントを出した証拠だ。別のポーリング、他ルータ、パケットが独立した証人にならなければならない。

RFC 5240 は特定製品の事故や侵害を報告していない。規格上の対象と危険を記述する。Lu Heng の「動くコード」を重んじる姿勢を当てはめれば、きれいな画面より帰属可能な結果が優先される。誰が読み、誰が書き、ネットワークが何を実行したのか。その三つを混ぜないことが管理の出発点である。

情報源