その活動成果であるntop社の製品をリリースします。
本ブログ記事では、「パケット監視とフロー監視どちらを選択すればよいか？」というユーザーの疑問に対して、ntop社が回答しています。
文：ジュピターテクノロジー よしひろ
本ブログ記事は、ntop社のブログ「Packets vs Flows: Which Option is the Best?」を意訳してご紹介しております。
ネットワーク監視を実装するシナリオで最も難しい選択の1つは、トラフィックを監視する必要がある最適なポイントを見つけ、目的とするトラフィック監視を実現するための最適なソリューションを選択することです。
基本的な選択肢は、以下の２つがあります。
- ミラーポート、ネットワークタップ導入によるパケット収集
- NetFlow/sFlowのフローコレクターの導入
ミラーポート、ネットワークタップ導入によるパケット収集
ミラーポート(SPANとも呼ばれる)やネットワークタップに関しては、過去のブログポスト(英文)で扱っています。
「パケットは嘘をつかない」といった言葉が広く認知されているように、これらのソリューションは、トラブルを分析するベストな方法です。
L2(ミラー)及びL1(タップ)の分析ができるため、「全てのトラフィックを可視化」することができます。
タップ vs SPAN、どちらが良いか？といったトピックに関しては、別途こちらの記事(外部サイト、英文)を参考としてください。
「パケットは嘘をつかない」といった言葉が広く認知されているように、これらのソリューションは、トラブルを分析するベストな方法です。
L2(ミラー)及びL1(タップ)の分析ができるため、「全てのトラフィックを可視化」することができます。
タップ vs SPAN、どちらが良いか？といったトピックに関しては、別途こちらの記事(外部サイト、英文)を参考としてください。
NetFlow/sFlowフローコレクターの導入
フローコレクター方式は、rawパケットに直接アクセスしないので前述のSPAN、タップ方式とは異なります。
ルーターがNetFlow/IPFIXといったプロトコルをサポートしている場合、5つのキー情報(プロトコル、IP、ポート、送信元 、宛先)に従って類似のパケットをグループ化します。
そして、バイトやパケットなどのメトリックを計算します。
つまり、ネットワーク通信のダイジェストを作成するため、NetFlow/IPFIXはトラフィックを「要約」してくれるのです。
一方、sFlowプロトコルはスイッチ内のプローブが「パケットサンプリング」情報を送信します。
スイッチで収集したパケットをsnaplen(通常128バイト)の長さに切り取り、sFlowコレクターにサンプリング情報を送信します。
sFlowをパケットキャプチャ方式と比較すると、完全なパケットの可視性はありません（パケットの長さという点でも、内容という点でもサンプルを見ていることになります)。
しかし、認証済みユーザー名といった追加のメタデータ(例えば、Radiusまたは802.1X利用時)にアクセスできます。
これは、トラブルシューティングやセキュリティ問題の分析に非常に役立つ情報です。
フローコレクター方式では、nProbeがZMQを介してntopngにフローデータを送信します。
複数のNetFlow/sFlow/IPFIXエクスポーターを監視し、すべてを1つのntopngインスタンスに集約できるという利点があります。
パケット収集方式で同じことをする場合、構成が非常に複雑になってしまいます。
フローコレクター方式では、フローを送信しているデバイスから事前フィルタリングおよび事前要約されたトラフィックのみが表示されることに注意してください。
つまり、「完全なパケットの可視性」はなく、要約された情報を可視化するということです。
ルーターがNetFlow/IPFIXといったプロトコルをサポートしている場合、5つのキー情報(プロトコル、IP、ポート、送信元 、宛先)に従って類似のパケットをグループ化します。
そして、バイトやパケットなどのメトリックを計算します。
つまり、ネットワーク通信のダイジェストを作成するため、NetFlow/IPFIXはトラフィックを「要約」してくれるのです。
一方、sFlowプロトコルはスイッチ内のプローブが「パケットサンプリング」情報を送信します。
スイッチで収集したパケットをsnaplen(通常128バイト)の長さに切り取り、sFlowコレクターにサンプリング情報を送信します。
sFlowをパケットキャプチャ方式と比較すると、完全なパケットの可視性はありません（パケットの長さという点でも、内容という点でもサンプルを見ていることになります)。
しかし、認証済みユーザー名といった追加のメタデータ(例えば、Radiusまたは802.1X利用時)にアクセスできます。
これは、トラブルシューティングやセキュリティ問題の分析に非常に役立つ情報です。
フローコレクター方式では、nProbeがZMQを介してntopngにフローデータを送信します。
複数のNetFlow/sFlow/IPFIXエクスポーターを監視し、すべてを1つのntopngインスタンスに集約できるという利点があります。
パケット収集方式で同じことをする場合、構成が非常に複雑になってしまいます。
フローコレクター方式では、フローを送信しているデバイスから事前フィルタリングおよび事前要約されたトラフィックのみが表示されることに注意してください。
つまり、「完全なパケットの可視性」はなく、要約された情報を可視化するということです。
どちらがベストソリューションか？
達成したい監視内容に基づいて、可視化戦略を決定します。
パケット収集方式は、間違いなく優れたオプションですが、混合シナリオといったアイデアもあります。
つまり、一部のネットワークはパケット収集をして監視し、他のネットワークをフローで監視するといった方式があります。
パケット収集方式は、間違いなく優れたオプションですが、混合シナリオといったアイデアもあります。
つまり、一部のネットワークはパケット収集をして監視し、他のネットワークをフローで監視するといった方式があります。
ntop製品を複数組み合わせれば(例: ntopng,nProbe,n2disk)、この混合シナリオをサポートすることが可能です。
本記事で扱っているntop社のnProbe, ntopngという製品ですが、ご興味のある方は以下のリンクから弊社までお問い合わせください！
