要約

  • RFC 1215 の TRAP-TYPE は、登録権限、順序付き変数、文章による意味、整数値を SNMPv1 Trap-PDU の各欄へ対応させた。マクロ展開は実装時であり、事象発生時ではない。
  • トラップが示すのは、送信側アプリケーションまたはプロトコル実体が認識した状態である。物理障害、原因、利用者影響、送信者の認証を独立に証明するものではない。
  • SNMPv1 は信頼性を保証しないデータグラムを使い、宛先選択も実装依存だった。定義、認識、生成、送信、受信、確認、措置、復旧は同じ事実ではない。

空の様式は障害より先に完成する

RFC 1215 は、TRAP-TYPE の展開が概念上、実行時ではなく実装時に行われると明記する。この一文だけで、定義と発生の境界が見える。

実装者は、リンクが一度も落ちていない段階で myLinkDown を定義できる。enterprise を割り当て、変数を並べ、説明を書き、管理ツールに表示規則を用意できる。そこまでの成果は、将来届くかもしれないインスタンスを読むための様式であって、センサー値ではない。

混同が起きやすいのは、説明文が事象を語るからだ。整数は事故コードのように見え、変数一覧は証拠一式のように見える。しかし、定義には将来の具体値がない。出来事を記録したのではなく、記録の型を決めている。

RFC Editor の記録は1991年3月の Informational 文書とし、IETF Datatrackerも同じ文書を保存している。本文はトラップ利用を「論争的」と述べ、強く非推奨とした。目的は既存トラップを簡潔に定義することで、新規トラップを増やすことではなかった。

これはトラップが使われなかったという証明ではない。文書が担ったのは記述上の便宜であり、標準化や全面的な推奨ではなかったという範囲の話である。

enterprise は登録先であって本人確認ではない

必須の ENTERPRISE 節は、そのトラップをどの管理企業の登録権限の下で定義したかを示し、Trap-PDU の enterprise 欄へ入る。

登録名前空間は送信者認証ではない。企業 OID を見ても、特定の人やプロセスがそのデータグラムを送ったこと、現在の所有者、操作権限までは分からない。標準 SNMP トラップを表す特別な規約では sysObjectID が入るが、これも構成されたオブジェクト種別の手掛かりであり、署名ではない。

定義者、製品の現所有者、設置者、宛先を設定した管理者、実際にパケットを作ったプロセスは別々になり得る。OID 一つにその全員の権限を読み込むことはできない。

RFC 1215 のセキュリティ節は、セキュリティ問題を論じないとだけ述べる。そこから発信元認証、完全性、機密性、再送耐性を推定してはならない。

変数の順番は最低限の契約だった

VARIABLES 節は、そのトラップ型の全インスタンスに含まれる MIB オブジェクトを順序付きで定める。各オブジェクトは順番どおり variable-bindings に入る一方、エージェントは末尾へ追加変数を置ける。

したがって、定義済みの一覧は「必ず入る骨格」であり、運用上必要なすべての事実とは限らない。将来インスタンスの値も含まない。追加変数を異なる管理器が同じ意味で扱う保証もない。

ifIndex は構成上のインターフェースを特定する。それだけで物理ケーブル、回線、経路、顧客サービスのどれが壊れたかは確定しない。

DESCRIPTION は型の意味を文章で表し、REFERENCE は別モジュールのトラップ、事象、アラームへ参照を張れる。文章と参照はいずれも定義間の関係であり、現場の独立測定ではない。

整数値は enterprise-specific の場合 specific-trap へ入り、generic-trap は enterpriseSpecific(6) になる。snmp 規約では整数が generic-trap へ入り、specific-trap はゼロになる。これは名前空間の番号であり、重大度、確信度、件数、時系列、影響範囲ではない。

linkDown が語るのは送信側の認識である

RFC 1215 の myLinkDown は、送信 SNMP アプリケーション実体が、エージェント構成に表された通信リンクの障害を認識したことを意味する。

重要なのは主語だ。認識したのは送信側アプリケーションである。ドライバー状態、しきい値、カウンター、局所的な遷移を判断材料にした可能性がある。トラップは物理層の独立検査でも、原因分析でも、利用者影響の測定でもない。

RFC 1157 の一般 linkDown も、送信プロトコル実体が障害を認識したと定義し、最初の variable-binding に対象 ifIndex を置く。インデックスは構成記録を指すが、故障全体を説明しない。

Trap-PDU の時刻も限定的である。最後の再初期化からトラップ生成までの経過時間を表す。物理条件が最初に生じた時刻、アプリケーションが気付いた時刻、送信時刻、受信時刻を同一にしてはならない。

生成にはアプリケーションの依頼が必要だった

RFC 1157 では、プロトコル実体は SNMP アプリケーション実体の依頼があって初めて Trap-PDU を生成する。どの宛先へ送るかも実装固有である。

つまり、定義からパケットまでの間に検出方針と構成が挟まる。条件を認識しない、生成を依頼しない、送信を抑止する、宛先を設定しない、古い管理器へ送る、受信側が企業固有の意味を知らない、といった経路がある。

authenticationFailure の例は沈黙の曖昧さを明示する。実装はこのトラップを生成できなければならないが、実装固有の仕組みで送信を抑止する能力も必要だった。トラップがないことは、認証失敗がなかった証拠にならない。

UDP 162 は受領証ではなかった

SNMPv1 は、各メッセージを一つのデータグラムとして運ぶ信頼性非保証のサービスだけを要求した。RFC 1157 はトラップ報告を UDP 162 で受け、後続処理へ回すとした。

ポート番号は入口の約束にすぎない。待受プロセス、到達経路、バッファ、解析、保存、画面表示、人の注意を証明しない。送信記録があっても受信記録にはならない。

受信した場合、プロトコル実体は内容を SNMP アプリケーションへ提示する。ここで初めて受信側の段階が一つ進む。それでも相関、チケット、判断、修復、回復確認は後ろに残る。

後年の RFC 2578 は RFC 1215 を SMIv1 の一部として扱い、SMIv2 では NOTIFICATION-TYPE によって通知の構文と意味を記述した。新しいマクロも型を定義するのであって、出来事を生成しない。

RFC 3416 は SNMPv2-Trap に配達確認がないと明記する。InformRequest は確認型だが、それでも配達保証はない。受信側は内容をアプリケーションへ渡し Response-PDU を返す。

Response はプロトコル交換の証拠を強める。しかし元の状態が真であること、担当者が解釈に同意したこと、復旧が完了したことまでは証明しない。

一つのトラップには複数の管理者がいた

モジュール作者は意味を、登録権限者は名前を、エージェントアプリケーションは認識を、実装は生成・抑止・宛先を、ネットワークは配送機会を、受信側は処理を、運用者は行動を管理する。

RFC 1215 が共有したのは一つの型であって、一つの全能な権限ではない。トラップは、独立したポーリング、カウンター、経路状態、サービス試験と結び付いたときに証拠価値を増す。単独では、送信側に由来する範囲限定の主張である。

出典