要約
- RFC 1286 は 1991 年 12 月に標準化トラックで発行され、IEEE 802.1d を参照するブリッジの管理オブジェクトを SNMP MIB に追加した。必要最小限で有用かつ非冗長な集合とし、重要部分への重い計測を避ける方針を明記している。
- ブリッジ・ポートは interfaces-group のインターフェースと結び付くが、複数ポートの共有が可能で、ポート番号と
ifIndexに必須の対応関係はない。カウンタはブリッジ対象プロトコルだけを対象とし、転送表のポートは送信元を見た地点、または情報があっても学習済みポートがない状態を表す。
「小さい MIB」は情報不足ではなく、主張の設計だった
RFC 1286 は透明ブリッジとソースルート・ブリッジのための管理オブジェクトを扱う。接続先が LAN だけとは限らないことにも触れる。それでも、仕様の出発点は網羅ではない。障害・構成管理に有用な本質的オブジェクトを小さな集合として選び、利用実績や実用性を考え、総数を制限し、重複・導出可能・無益なものを省き、クリティカルな部分を過度に計測しない、としている。
この節制は、管理表の一項目をどのように読むかを決める。値は定義済みの観測または制御の面であって、筐体、配線、利用者、回線上の全プロトコルを写した模型ではない。表にないものが存在しないのではなく、表にあるものも仕様で定められた範囲より広い事実にはならない。共通 MIB の強さは、全知のふりをしないところにある。
接続先の参照と、対象の同一化は別の操作である
MIB-II の interfaces group とブリッジ・ポートの関係は、その境界をよく示す。RFC はインターフェースを subnetwork に接続されたものとして扱い、これは IP subnet と同義ではないと注意する。各ブリッジ・ポートはインターフェースに関連付けられ、dot1dBasePortIfIndex が対応する ifIndex を返す。
ただし RFC は、ここで同一化を止めている。一つのインターフェースに複数ポートを関連付けられ、例として一つのインターフェース上の複数 X.25 仮想回線を挙げる。ポート番号はポートごとに一意だが、インターフェース番号との必須関係はない。ある実装でポート 8 と interface 8 が一致しても、それは読みやすい偶然であって、物理コネクタや単一の機能を証明する規則ではない。
管理者が得るべきなのは、二つの表面を接続して調べる方法であり、一方を他方へ消去する許可ではない。ポート行はブリッジ機能のためのポート情報、インターフェース行は interfaces-group の情報を表す。関連付けがあるからこそ、両者の違いも残る。
カウンタの外側には、同じインターフェースを通る別の仕事がある
RFC 1286 は、同じインターフェース上で装置がブリッジ以外の仕事をする場合を明記する。例は IP データグラムをルーティングし、それ以外のプロトコルをブリッジするエンティティである。このとき Bridge MIB が対象とするのは後者だけだ。Bridge MIB、特にそのカウンタは、ブリッジされるプロトコルのために送受信されたデータにだけ適用され、インターフェースが送受信したすべてのデータを必ずしも表さない。
つまりカウンタは、橋渡し機能の処理量については根拠になりうる。一方で、それだけを回線全体のトラフィック、アプリケーションの量、帯域利用率、他の通信がなかったことの証明にすることはできない。数値の精度と母集団の広さを取り違えてはならない。仕様が守ったのは、まさにこの分母である。
転送表は「見た」という状態を保存し、所在を保証しない
透明ブリッジの転送データベースでは、dot1dTpFdbAddress は転送またはフィルタ情報を持つユニキャスト MAC アドレスである。dot1dTpFdbPort は、そのアドレスを送信元とするフレームを見たポート、またはゼロを返す。ゼロは情報がないという意味ではない。静的な転送・フィルタ情報を持ちながら、学習したポート番号を持たないことがある。
状態には other、invalid、learned、self、mgmt がある。invalid は、以前に学習され、エージング後にもまだ表から消去されていないエントリでありうる。learned は記録したポートを学習し使用中であること、self はブリッジ自身のアドレス、mgmt は静的アドレスのインスタンスとの結び付きを示す。
ここで得られるのは、ブリッジが自身の規則に従って保存した観測または状態である。それは人や組織がその MAC を支配すること、機器が今もその場所にいること、宛先に届いたこと、別の装置も同じものを見たこと、管理上の許可があったことを示さない。古くなったエントリが見えている場合、テーブル上の可視性と現在性は明確に異なる。
一意なブリッジ参照は、運用上の権利証ではない
dot1dBaseBridgeAddress は、ブリッジを一意に参照する必要があるときの MAC アドレスである。RFC は、ブリッジのポート MAC のうち数値的に最小のものを選ぶことを推奨するが、要求はしない。これは spanning-tree priority と合わせて Spanning Tree Protocol の BridgeIdentifier を作る。
プロトコルが対象を区別するために不可欠でも、その値は所有権、認証、現存する物理機器、収束したトポロジー、転送成功の根拠にはならない。RFC 1286 の方法は、一意な参照を必要な場所に置き、そこから余分な権限を発生させないことだった。
情報源と証拠の限界
本稿は RFC 1286 — Definitions of Managed Objects for Bridges に基づく。この資料は 1991 年の Bridge MIB の範囲、ポートとインターフェースの関連、カウンタの機能範囲、一意なブリッジ・アドレス、転送データベースの状態を裏付ける。現在のブリッジ、インターフェース、ポート、MAC、ホスト、所有者、全トラフィック、トポロジー、認可、配送、導入状況は裏付けない。
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
