要約

  • GetNext は、要求された名前の直後にある「その要求からアクセス可能な」OID と値を返し、その応答名が次の要求のカーソルになった。
  • 概念表の行番号を事前列挙しなくても、OID の辞書順を反復すれば表を走査できる。対象サブツリーを外れた名前も重要な終了証拠だった。
  • SNMPv2 は endOfMibView を個々の変数バインディングに置き、GetBulk で往復を減らしたが、ビューと時刻を越える完全性は与えなかった。

装置だけが知っている接尾辞

管理アプリケーションが知っているのは、たとえば経路の宛先列や次ホップ列を表す OID である。具体的な行は、その装置の現在の状態から作られるインスタンス接尾辞で区別される。列名だけを GetRequest しても、まだ具体的な変数名ではない。

1988 年の RFC 1067 は GetNextRequest を、関連する MIB view で get 可能な名前の辞書順から、要求名の直後のものを選ぶ操作として定義した。応答は値だけでなく、選ばれた完全な名前も返す。

管理側は、その名前を次の要求へ入れる。返ってきた次の名前を、また次へ渡す。一度の応答が自分の後継を指すため、未知の個数の行を、行数を尋ねる専用コマンドなしでたどれる。

表機能を重くしなかった理由

MIB は仮想的な情報ストアとして記述されたが、関係データベースではない。RFC 2578 の SMIv2 では、概念表と INDEX が、オブジェクト型の OID にインスタンス識別子を付ける構造を与える。

初期 RFC の経路表例では、管理側が複数列の OID を同時に送り、エージェントが最初の索引付き変数を返す。次の要求には、その三つの返却名が入る。こうして列の対応を保ちながら次の行へ進む。順序は、人間向けのシンボル名の辞書順ではなく、OID を構成する数値列の順序である。

この仕組みは、エージェントを簡素に保つ SNMP の出発点と合っていた。ネットワークの詳細な状態は管理センターが主にポーリングし、少数の trap はその焦点や時機を変える。共通層は「次」を返すだけでよく、複雑な一覧構成は管理側が担えた。

別の列へ進むことは故障ではない

ある列の最後の行の次には、次の列の最初のインスタンスがあるかもしれない。表全体の後には、まったく別の MIB オブジェクトが続く。OID 空間は、画面上の表境界を知らない。

RFC 3416 の例は、IP のアドレス対応表を走査した後、応答が次の列へ折り返し、さらに表外のオブジェクトへ出る様子を示す。表外の値は誤答ではない。返却 OID が期待したプレフィックスを外れたことが、管理側にとって終了の証拠になる。

したがって、対象プレフィックスを決めて停止する権限と責任は管理側にある。エラーになるまで進み続ける実装は、隣接サブツリーを誤って同じインベントリへ取り込む。

SNMPv1 の終端はより大まかだった。RFC 1157 では、要求内の一つでもアクセス可能な後継を持たなければ、noSuchName と error-index を持つ応答になる。複数列のうち一つが先に尽きた場合、他の有用な進行まで扱いにくくなった。

「終わり」を変数ごとに分けた SNMPv2

RFC 1448 は SNMPv2 で endOfMibView を導入した。後継がない変数バインディングだけがこの例外値を持ち、同じ応答の別のバインディングは通常の名前と値を返せる。RFC 1905 を経て、この規則は RFC 3416 に受け継がれた。

ここで終わるのは「装置」ではなく、当該要求から見える順序のその軌跡である。一列が終了しても別の列は進める。endOfMibView は物理的な情報の不存在を証明しない。

GetBulk は同じ後継探索をまとめた。non-repeaters に該当する先頭のバインディングは一つずつ後継を求め、残りは max-repetitions の範囲で複数の位置を求める。往復回数は減るが、一回答での完全取得は保証されない。応答サイズの制約で少なくなることがあり、RFC 1905 は大きな反復値による IP 断片化の危険も指摘する。

見つかったものは、認可されたビューの内容である

GetNext の定義は、単に「全 OID の次」ではなく、この要求からアクセス可能な変数の次を選ぶ。RFC 3415 の VACM は、context ごとに、含めるサブツリーと除外するサブツリーから MIB view を構成し、グループ別の読み取り範囲を決める。

同じ装置、同じ開始 OID でも、異なる正当な権限を持つ管理者は別の後継を受け取り得る。除外されたオブジェクトは、その要求の順序集合には入らない。あるビューで末尾に達したことから、別 context、非公開モジュール、より強い権限で見える情報の不存在を結論できない。

さらに walk は時間を消さない。複数回の応答の間に表は変化し得る。GetBulk もスナップショット分離を与えない。RFC 3416 の例が表の値とともに sysUpTime を読むのは観測時点を考える助けになるが、別々の応答を一つの原子的な台帳には変えない。

根拠資料の範囲

歴史と動作は RFC 1067、RFC 1157、RFC 1448、RFC 1905、RFC 2578、RFC 3415、RFC 3416 から確認できる。これらは現行製品の実装品質、普及率、既定設定、安全な配送、読み取り値の業務上の正しさまでは立証しない。