【大規模プロジェクト対応】Observation Pointを使って、数百台のルーターからのフローを収集しよう!

  • 公開
  • 更新

本ブログ記事は、ntop社のブログ「Collecting Flows from Hundred of Routers Using Observation Points」を意訳してご紹介しております。

文:ジュピターテクノロジー よしひろ

はじめに

本日は、これまでntopngの弱点でもあった数百台といったネットワーク機器からのフロー受信を打開する方式として、ntop社が提案するObservation Pointの仕組みについて説明します。

大規模案件でも安心してntopngをご採用頂けるといったイメージを本ブログで持っていただければ幸いです。

Observation Pointを使って、数百台のルーターからのフローを収集しよう!

何百ものルーターが存在する大規模なネットワークでフローを収集することは、困難な場合があります。

収集するフロー数に加えもう 1 つの重要なポイントは、情報をシンプルかつ効果的な方法で視覚化できることです。

ntopng を使用すると、収集されたフローのマージを回避するために使用できる最大 32 個(ntopng Enterprise Lの場合。XLは、64個まで拡張された)の仮想フローコレクションインターフェイス(以下、仮想フローIF)を作成することができます。

残念ながら、100 台以上のルーターからフローを収集する場合は、この仮想フローIFでは十分ではありません。

最新の ntopng および nProbe では、Observation Pointの概念を実装しました。これはIPFIXで定義され、パケットを観測できるネットワーク内の場所として定義されています。

図1 Observation Pointアーキテクチャ例

私たちが解決したい問題は次のとおりです:

  • 発信元のプローブ IP に関係なく、同じサイトからのフローをクラスター化する方法
  • 他のサイトからのフローとのマージを回避する方法。しかし、フローが収集されるインターフェイスレベルで可視化できること

各 nProbe インスタンスは、サイトを一意に識別するObservation Point Id の数値を設定するように構成できます。

サイトのサイズに応じて、サイトは 1 つまたは複数のプローブを持つことができます。nProbe では、observationPoint は次のように -E フラグで設定します。

 
ローマ
nprobe -E 0:1234 --zmq tcp://192.168.1.100:1234 --zmq-probe-mode -i eth1
nprobe -E 0:1234 --zmq tcp://192.168.1.100:1234 --zmq-probe-mode -i eth2
nprobe -E 0:1234 --zmq tcp://192.168.1.100:1234 --zmq-probe-mode -i eth3

パリ
nprobe -E 0:1235 --zmq tcp://192.168.1.100:1234 --zmq-probe-mode -i eno1

ベルリン
nprobe -E 0:1236 --zmq tcp://192.168.1.100:1234 --zmq-probe-mode -i enp2s0f0
nprobe -E 0:1236 --zmq tcp://192.168.1.100:1234 --zmq-probe-mode -i enp2s0f1

セントラル ntopng フロー コレクター
ntopng -i tcp://92.168.1.100:1234c

フローが nProbe によって送信されると、フロー収集中に ntopng と通信し、Web インターフェイスで報告されるObservation Point Id で一意にマークされます。

図2 ntopngでのObservation Pointの識別

上部のメニューバーで、ntopng はドロップダウン メニューに既知のすべてのObservation Point ID を一覧表示します。

このようにして、ネットワーク アナリストは、別の観察ポイントからのフローを非表示にしながら、視覚化したい観察ポイントを選択できます。

左側のサイドバーの [プローブ] メニューでは、既知のすべてのObservation Point ID を一覧表示し、ホイール アイコンをクリックしてカスタム名を設定し、グラフアイコンをクリックしてトラフィック統計を視覚化することができます。

図3 Observation Pointの一覧表示

フローは分割されたままですが、ホスト、AS、ネットワークなどのトラフィックは、それを発信したObservation Point ID に関係なく、インターフェイスレベルでマージします。

この選択により、異なるObservation Pointからのホストが一緒に話すときに統計が重複しないようにすることができます。

たとえば、ローマのサイトのホストが www.google.com と通信しており、ベルリンのホストも www.google.com と通信している場合、ntopng は単一の www.google.com ホスト エントリをメモリに保持します。

トラフィックのフローがrawフロー保存されている場合、フローは両方とも、Observation Point Id と、それをエクスポートしたプローブ IP アドレスを持っています。

これにより、ネットワーク アナリストは問題をドリルダウンして (たとえば、ntopng によって生成されたアラートで報告)、トラフィックの起点まで掘り下げることができます。

図4 Probe IPアドレスとObservation Point IDが表示されている様子

最後に

Observation Pointを利用すれば、ホスト、AS、およびネットワークの一貫したカウンターを維持しながら、サイトに従ってトラフィックを分割できます。

アドレスが重複するネットワークの場合 (たとえば、アドレスが 192.168.1.1 の 2 つのホストが 2 つの異なる場所に展開されている場合)、同じ IP を持つが物理的に異なるホストのトラフィックをマージすることを避けるために、異なる仮想フローIFを活用することを推奨します!

ntop製品のお問い合わせ

ntop社製品にご興味のある方は、以下リンクよりいつでも弊社までお問い合わせください。

10分間機能制限なし!無償でご利用いただける評価版も以下のダウンロードリンクにご用意しております。簡単に検証が開始できますので、評価ガイド(PDF)を参考にぜひお試しください!

こんな記事も読まれています

最新記事

おすすめ記事

  1. 「リモートデスクトップの操作が遅い!」の原因を高速特定!ntopngによる輻輳原因の究明アプローチを実例でご紹介

  2. フリーWi-Fiに潜む悪魔の双子(エビルツイン)とは。加害者・被害者にならないために知るべきこと

  3. 「疑わしい」Windowsイベントログを抽出して、イベントログを活用する

製品カテゴリー

JTC IT用語集
TOP