フローエクスポート：NetFlow / IPFIX / sFlow の比較

フローエクスポートが解く問題

全パケットを保存するパケットキャプチャは中身まで見える反面、10Gbps級の回線では保存量も処理負荷も非現実的になります。フローエクスポートは、パケットそのものではなく「通信の要約」だけを収集サーバー（コレクター）へ送ることで、ネットワーク全体の通信状況を低コストで把握する手法です。

ここでのフローとは、一定時間内に同じ属性を共有するパケットの集まりを指します。古典的には5タプル、すなわち {送信元IP, 宛先IP, 送信元ポート, 宛先ポート, プロトコル} が同一のパケット群を1フローとして扱います。この粒度はECMPのフローハッシュが経路を選ぶ単位とも一致します。

集約型とサンプリング型という二系統

フローエクスポートには設計思想の異なる2系統があります。集約型（NetFlow / IPFIX）は機器内でフローごとにバイト数・パケット数を積算し、フロー終了時に集計結果を送ります。サンプリング型（sFlow）はパケットをN分の1で無作為抽出し、抽出したパケットの先頭断片をほぼ加工せず即座に送ります。

NetFlow と IPFIX：フローキャッシュの内部

NetFlow系の機器はフローキャッシュを持ちます。パケットが届くたびにキーを5タプルから計算し、既存エントリがあればバイト数・パケット数・フラグ・先頭/末尾タイムスタンプを更新し、なければ新規エントリを作ります。エントリの送出（エクスポート）は次の満了条件で起きます。

• アクティブタイムアウト: 通信継続中でも一定時間（実装により数分〜数十分。古典的なCisco NetFlowでは既定30分）ごとに区切って送る
• インアクティブタイムアウト: 一定時間パケットが来なければ「終了」とみなす
• TCP終了検知: FIN/RST を観測したらフローを閉じる
• キャッシュ枯渇: テーブルが満杯になったら古いエントリを追い出して送る

この満了モデルゆえに、長時間続くフローはアクティブタイムアウト単位の分割レコードとして到着します。コレクター側で同一フローを足し戻す前提で設計します。

NetFlow v5 はフィールドが固定でしたが、v9 でテンプレート機構が導入されました。IPFIX（IP Flow Information Export、RFC 7011）はこの v9 を標準化・拡張したもので、しばしば「NetFlow v10」とも呼ばれます。

テンプレート機構：可変フォーマットの肝

テンプレート方式の要点は、データレコードのフォーマット定義をデータと分離して送ることです。エクスポータはまず「テンプレートレコード」（各フィールドのID・型・長さの並び）を送り、以後はヘッダにテンプレートIDだけを付けた「データレコード」を送ります。コレクターは受け取ったテンプレートを使ってデータを解釈します。

[テンプレートレコード]  ID=256: srcIP(4) dstIP(4) srcPort(2) dstPort(2) proto(1) octets(8) ...
[データレコード ID=256]  10.0.0.1 10.0.0.9 51000 443 6 1048576 ...
[データレコード ID=256]  10.0.0.2 10.0.0.9 51200 443 6 2097152 ...

これにより、固定フォーマットを改版せずに新しいフィールド（送信元/宛先AS番号、TCPフラグ、TTL、MPLSラベル、TOS/DSCP、さらにIPv6やアプリ情報）を柔軟に追加できます。コレクターはテンプレートを受信して初めて後続データを読めるため、UDP転送ではテンプレートを定期再送する必要があります（テンプレートを取りこぼすと、その間のデータは解釈不能になるため）。IPFIX は IANA 登録の Information Element 番号で意味を共有し、企業独自フィールドも Enterprise ID 付きで拡張できます。

sFlow：なぜサンプリングなのか

sFlow はASIC上のカウンタで「Nパケットに1回」を判定し、当たったパケットのヘッダ先頭（規定バイト数）をコレクターへ転送します。機器はフローテーブルを持たず集約もしないため、ラインレートでも追加負荷がほぼ一定で、L2フレームごと送るためVLANやMACといった下位情報も観測できます。代償として個々のフローのバイト数は標本からの推定値になります。

サンプリング率 N に対し、観測された標本数を c とすると、母集団のパケット数は概ね 推定パケット数 = c × N で見積もります。ここで誤差は標本数が物を言います。標本数 c に対する相対誤差はおおむね 相対誤差 ≈ 1 / sqrt(c) のオーダーで縮みます。つまり大量に流れる「象のフロー」は少ない標本でも高精度に捉えられる一方、たまにしか流れない「鼠のフロー」は丸ごと取りこぼし得ます。レート N は「精度」と「コレクター負荷」のトレードオフを決める最重要パラメータです。

可視化と異常検知への応用

コレクターに集まったフロー/標本は、次のような用途で価値を生みます。

• トラフィック可視化: 送信元/宛先・ポート・AS番号別に集計し、帯域上位（Top Talkers）やアプリ構成比をダッシュボード化する
• 異常検知: 短時間に多数の宛先へ向かう小さなフローの急増はスキャンやワーム、単一宛先への大量フローはDDoS増幅攻撃の兆候として捉える
• キャパシティ計画と課金: 区間別の使用量を長期トレンドで見て増速判断や従量課金の根拠にする
• セキュリティ調査: どのホストがいつ外部のどこへ通信したかを、全パケット保存なしに事後追跡する

集約型はフロー単位の正確な総量を出しやすく課金や容量計画に向き、サンプリング型は全ポートを広く・ほぼリアルタイムに見渡せるので大規模網の異常の即時検知に向きます。両者は排他ではなく、コア網は sFlow で広く監視し、境界ルーターは IPFIX で詳細を取る、といった併用が定石です。

設計上の注意点

• UDPは取りこぼす: NetFlow/sFlow とも既定の UDP 転送ではエクスポートパケット自体がロスし得る。IPFIX が SCTP を推奨するのは輻輳制御と信頼性のため
• 時刻の整合: 複数エクスポータのレコードを突き合わせるには時刻同期（NTP/PTP）が前提。ずれると因果関係を誤読する
• 集約型の状態コスト: 多数の短命フロー（SYNフラッド等）はフローキャッシュを膨張させ、機器側でコネクション追跡同様の枯渇リスクを生む。sFlow はこの点に強い
• サンプリング率の固定誤解: N を上げれば負荷は下がるが、稀少イベントの可視性は犠牲になる。「何を見たいか」から逆算して N を決める

「全部を保存する」のではなく「要約を賢く集める」。フローエクスポートはこの発想で、可視化・異常検知・容量計画を現実的なコストで両立させる基盤になります。