要約

  • 一つの SNMP agent が複数の論理エンティティと多数の物理部品を表せたため、同じインデックスでもスコープが違えば別の対象を指した。
  • 包含、論理―物理対応、別名の各表は参照を復元できる形にしたが、所有権、所在、完全性、agent 間の一致までは証明しなかった。

数字の 5 は正確でも、「何の 5 か」を失えば誤った証拠になる。RFC 2037 の Entity MIB は、その単純な事故を防ぐための構造を持っていた。

例に登場するルーターは二つの自律システムに属し、それぞれに OSPF のバックボーン領域 0.0.0.0 を持つ。一つの筐体が複数の論理ルーター、ブリッジ、リピーターを収容し、一つの管理窓口から見せる場合もある。オブジェクト識別子も整数インデックスも正しく、それでも文脈の外では一意ではない。

命名スコープはキーの一部だった

RFC 2037 は、一回の操作で到達でき、一つの識別空間を共有する管理情報を命名スコープと呼んだ。SNMPv1 と SNMPv2c では entLogicalCommunity が論理エンティティへのアクセスに使う community を示す。

二つの論理ルーターが ifIndex.5 を返しても、同一インターフェースとは限らない。保存すべき証拠は、agent、取得時刻、community、論理インデックスを含む。「インターフェース 5」だけを残す処理は、値を保ちながら住所を捨てている。

同じ community を使う二つの論理エンティティに、管理上の関係は含意されない。表だけではローカル実装か proxy 経由かも分からない。命名スコープ自体の管理も Entity MIB の対象外だった。

空のスロットも観測された構造だった

entPhysicalContainedIn は部品を直近の容器へ結び、ポートからモジュール、スロット、筐体へ遡る木を作る。頂点ではインデックスゼロに到達する。容器は空でも実装済みでも表現しなければならなかった。

したがって、子を持たない既知のスロットと、agent がモデル化していないスロットは異なる。前者は構造内で明示された空き、後者は未対応、古い表示、あるいは部分的な公開かもしれない。ただし、この表は agent の物理モデルであり、現物確認済みの資産台帳ではない。

論理と物理の関係は多対多だった

entLPMappingTable は論理エンティティを、それを支える物理部品へ結ぶ。一つの論理エンティティは複数部品を使え、複数の論理エンティティが同じ部品を共有できる。

これは支援関係であって、独占所有、管理権、契約責任を示す表ではない。関係の性質も論理エンティティ側の MIB から推定する必要があった。

粒度も重要になる。ポートごとにリピーターを切り替えられるハブでは、現在すべてが一つのリピーターに属していても、ポート対応をモジュール一行に畳むべきではない。畳むと、実際に変更可能な制御点が消える。

別名表は外部番号を部品へ戻した

entAliasMappingTable は論理エンティティ、物理部品、別 MIB の識別子を組み合わせる。論理インデックスがスコープを選び、物理インデックスが部品を選び、別名が ifIndex などの外部オブジェクトを指す。

論理インデックスゼロは、より具体的な行がない場合のワイルドカードとして使えた。それは agent 内の既定ルールであり、世界共通の同一性ではない。別名行がない場合も、「別名が公開されていない」としか言えない。

別の agent は別の切り取り方を選べた

重なり合う対象を扱う複数の agent に、等価性や整合性は要求されなかった。任意インデックス、ベンダー識別子、公開する部分集合が異なり得た。agent をまたいだ同じ番号は同一性の証明ではなく、異なる説明も直ちに誤りではない。

照合にはシリアル情報、トポロジー、運用記録など別の根拠が必要になる。その結論は Entity MIB の保証ではなく、照合根拠の強さに依存する。

RFC 2037 が定義したアクセス可能なオブジェクトはすべて読み取り専用だった。読み取り成功が証明するのは、その時点でそのスコープの agent が値を返したことだけである。現在の配備、到達性、完全性、権限は証明しない。後継の RFC 2737 は SNMPv3 の context と書き換え可能な管理項目を加え、RFC 4133、RFC 6933 が続いた。後世の機能を 1996 年版へ遡及させてはならない。

出典