こんにちは，トゥワイズラボの山居です。前回までの第2部では，「SNMP RMON」について解説しました。RMONは，インターネット標準の管理技術SNMPを基盤としているトラフィック管理技術であるため，多くの企業向けLANスイッチが実装しています。しかし，第2部第2章で説明したように，現状でRMONを使う場合には以下のような問題点があります。

・ RMON-1のホスト・テーブル，マトリックス，RMON-2のプロトコル別統計などを実装するためには，多くのリソース（メモリー，CPUパワー）が必要であり，コスト的な問題で，完全な実装が行われていない。
・ 取得する情報量が多い場合，取得に時間がかかり，リアルタイムな解析ができない。

　これらの問題を解決するトラフィック管理技術として登場したのが，sFlowとNetFlowです。今回は，この二つのうち前者の「sFlow」について解説します。

sFlowとは

　sFlowは，米インモンが開発したパケット・サンプリングに基づくトラフィック管理技術です。sFlowは，米ファウンドリや日立製作所，米HPといったLANベンダーが販売するLANスイッチに実装されています。

　sFlowが基盤としているパケット・サンプリング技術は，1990年代の初めから研究されていましたが，研究者以外にはあまり注目されていませんでした。ところが，LANの回線速度の主流が100Mビット/秒から1Gビット/秒以上に移行し始めた2000年代に入ると，需要が急速に高まってきました。当初あまり注目を集めなかった理由は，100Mビット/秒以下のLANの場合は，前回説明したRMONなど既存の管理技術で十分だったからだと思います。

　sFlowの仕様は，2001年にRFC3176としてファウンドリ製のLANスイッチへの実装と同時に公開されました。「RFC化されている」と聞くと，インターネットの標準規格になっている，あるいは標準化途中の技術だと思われがちですが，必ずしもそうではありません。単にベンダーが独自仕様を情報として公開しているだけのようなRFCもたくさんあります。

　実際に，このRFC3176はインモンが情報を公開するための「Informational」RFCです。このRFC3176では，sFlow Ver.4の仕様について規定しています。このsFlow Ver.4の仕様を公開した3年後の2004年には，次のバージョンであるsFlow Ver.5の仕様が更新されましたが，実はRFCとしては公開されませんでした。

　おそらくは，Ver.4のRFCに対する反応が少なかったことから，Ver.5についてはRFC文書化することを見送ったのではないでしょうか。その代わりに最新のsFlow Ver.5の仕様書は，sFlow普及を目指す業界団体であるsFlow.orgのWebサイトから入手できます。同サイトでは，Ver.4のRFC文書や関連文書のPDFファイルなども配布しているので（こちらから入手できます），興味のある人はぜひ一度のぞいてみることをお勧めします。

　ちなみに，sFlowの仕様書を翻訳したものは弊社のWebサイトから入手できます。英語はちょっと苦手だという人はこちらを参考にしてください。なお，今回は主にsFlow Ver.5の仕様を基に解説していきます。

sFlowの基本的なしくみ

　sFlowは，LANスイッチやルーターなどを流れるトラフィックをモニターして，トラフィックに関する情報を送信するsFlowエージェントと，トラフィック情報を受信して解析するsFlowコレクタで構成します（図1）。sFlowエージェントは，主にLANスイッチに内蔵する形で実装されています。この場合，sFlowのモニター機能（パケットのサンプリングおよびトラフィック量のカウント）は，ハードウエア（ASICなど）で実現しています。

図1●sFlowの概要
図1●sFlowの概要 　[画像のクリックで拡大表示]

　第2部第5章で解説したRMONと異なり，sFlowのモニター機能がハードウエアで実現可能なのは，このあと説明するようにsFlowエージェント側の処理が非常にシンプルだからです。ハードウエアで実現できれば，ネットワークの高速大容量化への対応が容易になると同時に，製品の価格を安く抑えることができます。なお，sFlowもRMONの場合と同じように，LANスイッチのモニター・ポートに接続する形態の専用プローブや，パソコン（サーバー）上で動作するソフトウエアとして実装している場合があります（図2）。

図2●sFlowの主な実装形態
図2●sFlowの主な実装形態 　[画像のクリックで拡大表示]

　sFlowエージェントからsFlowコレクタに送信されるトラフィック情報は，大きく分けて以下の3種類があります。

（1） 送受信パケット数やバイト数，エラー数などモニターしているポートでの通信量を示す情報
（2） 各種パケットのヘッダーなどサンプリングしたパケットに関する情報
（3） LANスイッチのVLAN構成状況に関する情報や，ネットワークの経路（ルート）に関連する情報などサンプル・パケットの情報を補助する情報

一般に，企業ネットワークのトラフィックは，（1）のポートごとの通信量と（2）のサンプリングしたパケットに関する情報があればほとんど解析できます。プロバイダなどの大規模なネットワークで，トラフィックを詳細に解析する場合には，（3）の補助的な情報も利用します。

コラム1：トラフィック管理とプライバシ保護

　トラフィック管理を行う場合，LANアナライザやパケット・キャプチャ・ソフトを使うと，流れるパケットの内容すべてを見ることができるため，プライバシ上問題になるケースがあります。管理者が特定のユーザーの電子メールの内容などをのぞき見ることができてしまうからです。とくにプロバイダやASP事業者では，顧客のプライバシを侵害することになるため大きな問題になり得ます。

　こうしたケースで使うトラフィック管理技術は，トラフィックの解析はできてもプライバシを侵害しないことが要求されます。sFlowの場合，サンプリングしたデータ（とびとびのパケット）を扱い，また，ほとんどの場合ヘッダー・サンプル（パケットの先頭128バイト）しか解析しないので，顧客の通信の内容を把握することは困難です（やりとりしたデータや通信のシーケンスを全部再構築することができないという意味においてです）。

　したがって，sFlowによるトラフィック状況の調査では，プライバシ侵害の問題はないと言えます。ちなみに，前回解説したRMONの場合も，RMON-1のパケット・キャプチャ機能はほとんど実装されていませんし，トラフィック情報は集計したものになるので問題は起こりません。第4部で解説するNetFlowについても，sFlow同様に集計したトラフィック情報だけを扱うので問題ありません。

山居 正幸

（有）トゥワイズ・ラボ代表取締役
1961年北海道生まれ。北見工業大学卒業後，日立エンジニアリング，アスキー，ソリトンシステムズを経て，1999年7月トゥワイズ・ラボを設立。現在は，SNMP関連の管理ソフトや安価なWindows版侵入検知ソフトの開発を行っている。TCP/IPやSNMPに関連する著書もある。趣味はサッカー観戦で，浦和レッズを家族ぐるみで応援している。