要約

  • 稼働中のルールセットは、プロトコルを無視し、送受方向を入れ替えて再試行し、アドレスをマスクし、選んだ属性だけをフローへ押し込むことができた。記録は設定された観測投影である。
  • NeTraMetは同じ属性とマスクを使うテストをハッシュ検索へまとめ、マスクを1バイトの索引に圧縮した。高速化と同時に、コンパイル時の上限が記録の文脈になった。
  • フローテーブルが逼迫すると本番ルールから粗い待機ルール、さらに既定ルールへ切り替わり得た。再起動時も既定ルールから始まり、文書の運用例では本番復帰まで最大5分の欠損が生じた。

数える前に、何を数えるかが決まっていた

RFC 2123は1997年3月、Informational文書として公開された。RTFMの測定アーキテクチャとMeter MIBを実装・運用した3年間の経験を扱う。構成要素は四つだった。Meterがパケットを観測し、Meter Readerが利用データを運び、Managerが両者を設定し、Analysis Applicationが報告へ加工する。

記述された実装ではNeTraMetがMeter、NeMaCがManagerとReaderを兼ねた。NeMaCがダウンロードしたルールセットを、Packet Matching Engineが各パケットに適用する。規則は属性を比較し、値をフローへ格納し、不要なパケットを捨て、別の規則へ移り、あるいはSourceとDestを逆転して二度目の一致を試せた。さらにルールファイルのFormatが、Readerの収集列を指定した。

したがってSourceは、必ずしも回線に刻まれた普遍的な向きではない。ローカルネットワーク、ゲートウェイ、well-known portを基準に、分析しやすい方向へ正規化される場合がある。その判断は有用だが、規則の来歴を失った列名だけでは再現できない。

RFC Editorの記録とIETF Datatrackerが示すのは、標準規格ではなく実装経験という位置づけである。現在の公式RFC 2123 errata検索は該当なしだが、導入先のコードや分析まで正しいと保証するものではない。

興味の外に置かれたパケットは、欠落証拠さえ残さなかった

IPだけを測るなら、NovellやEtherTalkのヘッダを保存して後で解析する必要はない。NeTraMetは有効な規則を見て、対象となるPeer typeを決めた。対象外なら型を識別した時点で処理を終える。Adjacent addressを使う規則がなければ、その値もバッファへコピーしなかった。

これは効率化として合理的である。しかし、後からできる質問も限定した。IPのカウンタが完全でも、同じ区間を別プロトコルが通らなかったとは言えない。抽出前に捨てた属性は、後日の調査で復元できない。

RFC 2063のアーキテクチャは、必要なデータ削減を測定点の近くで行い、転送量と分析負荷を抑える設計だった。RFC 2123は、その利点と不可逆性が同じ選択から生じることを、実装の細部で示した。

高速化は、実行可能な限界も記録へ持ち込んだ

アドレス分類規則は数百件に及び得た。順番に比較する代わりに、NeTraMetは同じ属性と同じマスクを試す規則群を見つけ、ルールセット開始前にハッシュ表へ変換した。小さい群は逐次実行のままで、その境界はコンパイル時の最小サイズで決まった。

マスクも保存コストを持つ。アドレス中の本当のゼロと、マスクで無視されたビットを区別する必要があったからだ。説明された版ではマスク表を作り、フロー構造には1バイトの索引を置いた。利用できるマスク数は最大256までのコンパイル時上限だった。

これらは巧妙で有効な実装である。同時に、記録の意味が実行表現に結びつく理由でもある。残ったアドレスは特定のマスク後の値であり、クラスは特定のルール経路の結果であり、使える規則はビルドの制約内にある。数字だけを抜き出すと、質問の形が消える。

メモリ不足は、止まらずに観測範囲を変えた

フローテーブルの最大数はNeTraMet起動時に設定された。増分ガベージコレクタは、非活動時間と既知Readerの進行状況を見て領域を回収した。収集が遅ければ、新しいフローに使える場所は減る。

活動率がHighWaterMarkを超えると、待機ルールセットへの切り替えが想定された。オークランドでは、本番と似た分類を保ちながら、格納する情報を大幅に減らす待機規則を作れた。Reader停止後もMeterを1～2日動かし、復帰時に累積値を回収できた例がある。

FloodMarkに達すると、NeTraMetは内蔵の既定規則へ切り替えた。ガベージコレクションに処理を奪われ、Managerへ応答できなくなるのを防ぐためである。HighWaterMark 65%、FloodMark 95%が実用上うまく動いたと文書は述べるが、普遍的な安全値ではない。

プロセスが継続しても、意味が連続するとは限らない。本番、待機、既定の各行が内部的に正しくても、粒度と選択対象は異なる。可用性は、同じ問いを測り続けた証拠ではない。

再起動直後には本番方針が存在しなかった

停電などから復帰したMeterは、内蔵ルールセット1をまず実行した。NeMaCは一定間隔でsysUptimeを読み、値が小さくなれば再起動と判断する。その後、バックアップと本番の規則を再送し、本番へ切り替えさせた。

通常例はkeepaliveが5分、収集が15分だった。規則再配布まで最大5分のデータを失う可能性がある、とRFCは書く。この時間は運用設定の結果であり、仕様上の一律保証ではない。さらに既定規則の期間は、本番と別の分類を行う可能性があった。

再起動後にカウンタが再び増えても、それだけで前後が同一系列になるわけではない。ルールID、sysUptime、検出時刻、再配布完了時刻が必要だった。

FlowIndexは再利用される棚番号だった

回収された行のFlowIndexは、別のフローに割り当て直せる。そこでRFC 2123は、FlowRuleSet、FlowIndex、StartTimeの組み合わせを一意識別子とした。index単独は永続的な主体ではない。

収集も全表の原子的スナップショットではなかった。NeMaCはSNMP量を減らすため列単位で読み、先の列を読んだ後に有効化された行は次回へ回した。RFC 2064 Meter MIBは関連する制御対象を定める。1999年のRFC 2722は後の改訂であり、その明確化を1997年の全導入へ遡及させることはできない。

性能値も同じように限定される。10 MHz 286で約750 packet/s、25 MHz 386SXで約1,250 packet/s、40 MHz 486で無損失の約3,000 packet/sピークという報告は、特定ハードウェアと負荷の観測である。全パケットの完全性、請求の正当性、完全性保護、機密性を証明しない。RFC 2123はセキュリティを詳述せず、管理・収集プロトコルに責任を委ねた。

Lu Hengの後年のRunning-Code Primacyは、名称ではなく実際に動いた構成を見るための規律になる。Minimum Initial Specificationは一つの運用判断を普遍化せず、Reality Layersは文書、実装、記録、結果を分ける。これらはRFC執筆者の意図を示す史料ではなく、推論の境界を保つ後代の枠組みである。

RFC 2123が残した中心的教訓は、測定を証拠保全の連鎖として扱うことだった。Managerが問いを選び、Meterが規則で投影し、資源圧力が解像度を変え、Readerが非原子的な像を取得し、Analysisが主張を作る。行の価値は、その連鎖を示せる点にある。回線そのものを装う点にはない。

出典