要約

  • 初期の SNMP カウンターは 32 bit の上限に達するとゼロへ戻る仕様だった。次回値が小さいだけでは、障害、逆向きの通信、再起動のいずれも証明しない。
  • 高速回線では 32 bit の周回が収集間隔より短くなり得た。64 bit の high-capacity counter が観測窓を延ばした一方、旧 manager 向けの下位 32 bit は残された。
  • 周回とリセットは別である。sysUpTime と ifCounterDiscontinuityTime が同じ測定世代を示さない二つの poll から、通信量の差分を作ってはならない。

回線は動いたまま、表示だけが戻った

1 Gb/s のインターフェースを考える。ある poll では 43 億に近いオクテット値が返り、その直後には小さな値が返る。パケット転送は続いているのに、普通の引き算なら負になる。

低下をすべてリセットとみなせば、上限をまたいだ実際の通信を捨てる。すべて一周とみなせば、機器の再起動後に存在しない通信を加える。差分に必要なのは二つの数だけではない。カウンター幅、時間間隔、そして二つが同じ測定履歴に属するという根拠が要る。

グラフは一本の線を描ける。しかし、同じ行を読み続けたことと、同じ蓄積を読み続けたことは同義ではない。

最初の Counter には周回が組み込まれていた

1990 年の RFC 1155 は Counter を、2^32-1 まで単調に増え、その後ゼロから再び増える非負整数として定義した。周回は有限空間の正規動作であり、過去のイベントを取り消す操作でも、ハードウェア故障の通知でもない。

RFC 1213 の MIB-II によって、ifInOctets、ifOutOctets や packet counter がインターフェース管理の日常語になった。同じ MIB には sysUpTime と ifLastChange もあったが、counter 自体は絶対的な開始時刻も、既に何周したかも伝えなかった。

SMIv2 の RFC 2578 は限界を明記する。Counter32 と Counter64 には定義済みの初期値がなく、一つの値だけでは一般に情報にならない。両方とも周回する。64 bit は同じ数を再利用するまでの距離が長いにすぎない。

同一世代で一回だけの周回と確認できれば、modulo の差分を求められる。複数周が入り得る空白では、両端の値から失われた周回数を復元できない。

回線速度が bit 幅を poll の期限に変えた

媒体が速くなるほど、安全な観測時間は縮んだ。RFC 1573 は、最大長 packet が連続するという条件で、32 bit の octet counter が 10 Mb/s Ethernet なら 57 分余り、FDDI なら 5.7 分、1 Gb/s ならおよそ 34 秒で周回し得ると示した。RFC 2863 も同じ問題を引き継いだ。

poll を短くするだけでは限界がある。管理通信と処理が増え、一度の欠測で周回を失う可能性も残る。1,024 octet ごとに一つ数えるような scaling も検討されたが、低レートでは値が長く止まってから跳ね、平坦な通信を burst に見せるため退けられた。

採られたのは 64 bit の high-capacity group だった。RFC 2863 は 20 Mb/s 以下で 32 bit の octet と packet、20 Mb/s を超えると 64 bit octet、650 Mb/s 以上では 64 bit packet も要求した。

これは当時の agent 費用、実装状況、周回時間の折り合いである。64 bit という型だけで測定の正しさが生まれるわけではない。

新しい窓は古い窓を消さなかった

high-capacity object があっても、32 bit object は残る。旧 counter は対応する 64 bit 値の下位 32 bit を報告する。古い manager は読み続けられ、新しい manager は長い無曖昧期間を得る。

二つは 2^32 を法として整合するが、長い欠測後に支えられる履歴は同じではない。collector が ifInOctets から ifHCInOctets へ黙って切り替われば、物理 port が同じでも時系列の証拠能力は変わる。

Counter64 も無限ではない。RFC 2578 は 2^64-1 の後に周回すると定める。幅は通常周回を遠ざけるだけで、再初期化、object 再作成、欠測、意味の変更をなくさない。

インターフェースの同一性は測定より長く続き得た

line card は抜かれて戻る。agent が稼働中でも、hardware counter だけが初期化される。運用上は同じ論理 interface なので ifIndex を保ちたいが、以前の値と新しい値を接続してはならない場合がある。

古い扱いでは、不在中も全 counter を保持するか、新しい index を割り当てる必要があった。RFC 2233 は ifCounterDiscontinuityTime を加え、row identity を維持しながら測定世代の変更を公表できるようにした。

RFC 2863 では、関連する Counter32 または Counter64 のどれかが最後に不連続になった時点の sysUpTime 値である。管理 subsystem の再初期化後に断絶がなければゼロになる。

この分離により、ifIndex は管理 scope 内の interface を指し続けられる。だが、その安定性は counter history の連続性を保証しない。

時刻は断絶を示し、理由までは語らなかった

manager の規則は明快である。二回の poll で ifCounterDiscontinuityTime が違えば、その差分は捨てなければならない。agent 再初期化を見つけるため、sysUpTime も別に確認する。

差分を捨てることは、通信量をゼロと決めることではない。その区間の正確な総量を標準の観測から証明できないという意味である。容量計画の推定値を作るなら、観測値とは別に保存すべきだ。

marker は原因 code でもない。card 交換、software 更新、object 再生成、実装不良を区別しない。RFC 3635 は Ethernet 系 counter に同じ断絶境界を適用するが、診断や認証の機能は与えていない。

marker が変わらないことは、定義されたモデルで比較する材料になる。しかし、製品適合、packet 到達、請求の妥当性、service 効果までは証明しない。

情報源と証拠の限界

閉じた史料集合は RFC 1155、RFC 1213、RFC 1573、RFC 2233、RFC 2578、RFC 2863、RFC 3635 である。型、改訂、manager の義務は確認できるが、現在の普及率、vendor 適合、実際の断絶原因、配送や課金の正しさは証明しない。