sFlow とは、NetFlow と同様に、一般に利用されている
トラフィック監視・帯域監視の技術です。

sFlow はInMon 社によって仕様を作成されたサンプリングベースのトラフィック監視技術であり、

• 帯域監視
• リアルタイムトラフィック解析
• 異常検知
• IP レベルの請求

に役立ちます。

NetFlow がCisco社の独自技術であり、基本的にCisco社の機器において利用されているのに対して、sFlow は、RFCの形で仕様が公開され、多くの機器ベンダーが実装しています。

sFlowの基礎となるサンプリングの考え方を簡単に説明し、sFlowとNetFlowとの比較について述べます。

サンプリングとは

sFlow の話題に入る前に、サンプリングについてご説明します。

サンプリングとは、トラフィックを解析するひとつの方法です。
装置のインターフェースを通過するパケットを、N 個に1個の割合で解析ツールへ送ります（パケットベースのサンプリングについての記述になります）。この場合、N がサンプリングレートになります。
このひとつのパケットでの情報に基づいて、サンプル群中の残りのパケットに関するトラフィックパターンを構成します。

ここで、捕捉されてパケット解析用に送信されるのは、実際のデータグラムではないことに注意する必要があります。

sFlow では、装置のインターフェース上で、トラフィックのフローがある場合、サンプリングされたパケットのイーサネット・フレーム（つまりヘッダ情報）の一部を抜き出し、UDP パケットの中に保持します。

サンプルは、サンプリング間隔に基づいて収集され、UDP パケットに追加されます。
UDP パケットのサイズが1500 バイトに達すると、フロー・エクスポーターは、サンプリング率とインターフェース・インデックスのような必須情報を付けて、解析ツールに向けてエクスポートします。

このUDP パケットは、実際のパケットサンプルのフレーム情報と合わせて、sFlow と呼ばれます。

この特徴からsFlow は元々、トラフィック量が極端に多く、フルパケットでの解析が困難だったバックボーンのようなネットワーク上でのトラフィック解析に力を発揮するプロトコルです。

sFlow とNetFlow の差は？

冒頭で述べた通り、トラフィック解析・監視で使用される技術として、sFlowのほかにNetFlowがあります。

NetFlow は、基本的にはフルパケットの解析から生成されるトラフィック監視技術です。
過去には、この点で「ボーダーではNetFlow、コアではsFlow が望ましい」という観点がありました。

しかし、NetFlow においてもサンプリングが実装されて久しく、サンプリングの観点ではsFlow とNetFlow とでの違いはないと言えます。
またCisco機器のハード性能の向上でフルパケットの解析でも高いパフォーマンスを発揮するようになっています。

もう1つあったsFlow とNetFlow との大きな違いとして、
sFlow は、
「レイヤー2 で作動することができて、非IP トラフィックを捕捉する」
こともできる点でした。

sFlow は、レイヤー2 とレイヤー3 で作動可能であり、レイヤー3 ルーティングやnext hop を必要としません。
このことにより、sFlow 収集をレイヤー2 インターフェース上で実行することができ、IPX、Appletalk、XNS などのような非IP プロトコルも含めて、ユーザーのほとんどすべてのネットワークトラフィックをカバーすることができます。

しかし、NetFlow でもv9 からはMACアドレスが乗せられるようになりました。

この点においても、sFlowとNetFlowの差異はなくなったと言えます。

sFlow の動向

sFlow は、2001年にRFC 3176 *1 にて、仕様が策定され、最新バージョンでのv5 の仕様が2004年に公開 *2 されてからは、ワイヤレスネットワーク監視用規格sFlow 802.11 *3 が公開された以外は、新しい動きが見えません。

sFlow は現在でも広く使われているプロトコルですので、sFlowのコミュニティとしては、現在の仕様で十分であるという判断をしているということかも知れません。

sFlow v5 でベンダー独自拡張のサポートが追加されたため、それで十分であると考えている可能性もあるかと思われます。

最も重要なトラフィック監視要件である
「利用帯域において、どのようなプロトコルを使って、どこから、どこまで流しているか」
という内訳情報を知る上では、もちろん仕様作成された当初から十分に満たしています。

サンプリングへの懸念と対応法

sFlow はサンプリングベースであることから、データ精度を心配されるユーザー様もときどきいらっしゃいます。

sFlow は、サンプリングベースであるため、いくらかトラフィック情報の欠落が発生し得ます。
この事象が発生し得るのは、

• 大きな通信に属するパケットがサンプリングされず、そのため大容量のネットワークデータがカウントされなかった場合
• ユーザーのネットワークが数多くの小さい通信を含み、そのためこれらのパケットがサンプル群にて計算されなかった場合

です。

このような事情から、フルパケットでの解析と比べて、まったく同じ精度が確保されるとは言えないでしょうが、サンプリングレートを適切に設定することにより、理論的に、その誤差をある程度抑えることができます。

誤差をできるだけ小さくすることが重要な要件である場合、もちろんsFlow でも、サンプリングレートを小さく設定すれば、理論上は、より高いデータ精度が確保しやすくなります。

確保したい精度と帯域の大きさおよび機器性能から、現実性を判断する必要があります。

通常は、適切なサンプリングレートの目安と、帯域の大きさとの関係の表を参照して決めることが多いと思われます。 *4

ここでの精度が関係する問題とは、

• データ転送容量がどれだけ実際の流量に近いか
• 帯域利用の内訳情報でどれだけ欠損がないか
  (ある通信が見落とされることがないか)

という観点になります。

精度の重要性は、監視の目的に強く依存します。

現在の帯域利用の概要が把握できれば十分という場合は、極端に高い精度は必要ありません。

しかし、セキュリティ目的で詳細な通信利用の調査が必要になる場合、特に帯域利用の内訳情報に欠損があることは許されないでしょう。

最後に

過去、ワールドワイドでは、「トラフィック監視のためにNetFlow とsFlow とでは、どちらが良いか」というお問い合わせもありましたが、特に日本では、まず機器が選定され、それがNetFlow とサポートしているのか、sFlow をサポートしているのかでトラフィック監視用プロトコルが決まることがほとんどだと思われます。

もし、「トラフィック監視のニーズがまず有りき」の場合は、上記内容をご参考にしていただければ幸いです。

*1 https://www.ietf.org/rfc/rfc3176.txt
*2 https://sflow.org/sflow_version_5.txt
*3 https://sflow.org/sflow_80211.txt
*4 https://blog.sflow.com/2009/06/sampling-rates.html

▼▼ トラフィック監視を安価で実現するなら、ManageEngine NetFlow Analyzer ▼▼
NetFlow Analyzer 公式ホームページ
NetFlow Analyzerのダウンロードはこちら ※
NetFlow Analyzer製品概要資料のダウンロードはこちら
※永年無料版の利用をご希望の方は、30日間フル機能ご利用いただける「評価版」をダウンロードしてください。30日が過ぎると自動的に2インターフェースまで監視可能の永年無料版となります。