NetFlow©エージェント設定およびトラブルシューティングガイド

NetFlow©エージェント設定およびトラブルシューティングガイド

概要

このチュートリアルでは、TrafficSentinelに新しいNetFlow/IPFIXエージェントを追加するためのステップバイステップガイドと、発生する可能性のある問題について説明します。

新しいNetFlow / IPFIXエージェントの追加

推奨手順-ルーター側

  1. デバイスでNetFlow / IPFIXを設定します。このタスクは複雑になる可能性があり、多くの場合、CLIコマンドの複数のページで実行されます。したがって、それぞれのmake+model+ firmwareリビジョンの特性を把握してください。まず最小限のキーと値を提供する最も単純な構成から始めます。後でフィールドを追加することもできますが、最初にこれをサーバーに実行することをお勧めします。
    • Flow Start Time
    • Flow End Time
    • ingress physical ifIndex
    • egress physical ifIndex
    • IP Source
    • IP Destination
    • IP Protocol
    • L4 Source Port
    • L4 Destination Port
    • Frames
    • Bytes
  2. これをすべてのポートの入力トラフィックに適用して、ルーターを通過するすべてのものが1回カウントされるようにします。
  3. デフォルトでは、Traffic SentinelはUDPポート9985（NetFlow）および4739（IPFIX）でリッスンするため、これらのいずれかに送信するようにルーターで設定します。
  4. ”show netflow”コマンドまたは同等の方法で、ルーターがUDPデータグラムをTrafficSentinelサーバーのIPアドレスに送信していることを確認します。

推奨手順-サーバー側

  1. Traffic Sentinelサーバーで、パケットが以下コマンドで到着していることを確認します。
    sudo /usr/sbin/tcpdump -i any udp port 9985 or udp port 4739
  2. ソフトウェアファイアウォールが9985/udpあるいは4739/udpでパケットの通過を許可していることを確認します。
    sudo iptables –list
  3. Traffic Sentinel Web UIで、[イベント]＞[コンフィグレーション]＞[リスト]で、新しいエージェントイベントが表示されることを確認します。コメントフィールドには、データグラムの送信元アドレスが示されます。
  4. 数分経過したのち、新しいエージェントが[トラフィック]＞[ステータス]画面の、設定された[ゾーン]＞[グループ]に表示されることを確認します。
  5. SNMPでの接続機能が動作することを確認します;
    （[ファイル]> [設定]> [ステータス]> [ディスカバー・エージェント]の選択> [SNMPのテスト]）
  6. エージェントデバッグページ（[ファイル]> [設定]> [ステータス]> [ディスカバー・エージェント]の選択(> [SNMPのテスト]))から出力される[NetFlowエンジン]と[NetFlowテンプレート]を確認します。
    NetFlowバージョン1、5、および7の場合、テンプレートはありませんが、バージョン9または10（IPFIX）の場合、ルーターで入力した構成に一致するテンプレートが表示され、最も頻繁に使用されるテンプレートが最初にソートされます。
  7. “Frames per Second”のカウンタートレンド（[トラフィック]>[トレンド]>[エージェント]の選択：表示=”Frames per Second”）をフレーム/秒のトップトーカーのトレンド（[トラフィック]>[トップN]>[エージェント]の選択：単位=”Frames/sec”）と比較計測します。 NetFlowは通常、レイヤー3パケットのみをカウントし、ハードウェアカウンター（SNMP）はすべてのパケットをカウントしますが、ほとんどの場合、2つのグラフのエンベロープはほぼ一致するはずです。
  8. 一致しない場合は、ルーターのパケットサンプリング設定を調整することを検討してください。ルーターが1:1のフローレコードを送信している場合（つまり、パケットサンプリングがない場合）、TrafficSentinel側ではパケットサンプリング処理を実施します。したがって、TrafficSentinel側のサンプリングレートを調整することを検討してください。これは、[ファイル]> [設定]> [サンプリング設定の編集]で設定できます。
  9. 次に、テンプレートに追加するのに役立つフィールドを検討してください。考えられものとしては以下になります。；
    • IP TOS
    • IP TTL
    • Ingress VLAN
    • Ingress MAC source address
    • Ingress MAC destination address
    • IPv6関連のテンプレート

    ルータのハードウェア制限により、一部の組み合わせで不可能な場合があるため、新しいフィールドを1つずつテストすることをお勧めします。

  10. 最後に、以下の一般的な問題のリストをチェックして、さらに修正が必要かどうかを確認します。

一般的な問題

  1. エージェントアドレス：NetFlowの場合、データグラムのソースIPがエージェントアドレスとして常に採用されます。エージェントアドレスが予期しない値に設定され、エージェントが間違ったゾーン+グループに表示される場合があります。エージェントアドレスがCIDR、エージェント範囲、またはエージェントのいずれとも一致しない場合、「other」ゾーンに表示されます。デバイスと通信するためのパラメータが未定義になるため、これは問題のある状態です。送信元アドレスを、TrafficSentinelが常に通信できるloopbackアドレスに設定することをお勧めします。
  2. ダブルサンプリング：[警告フラグ（下記参照）：RetrofitSampling] ルーターがパケットサンプリングを適用しているが、フロー情報としてそれらの詳細が含まれていない場合、Traffic Sentinelは1:1（サンプリングなし）であると想定し、定義されているサンプリングレートを適用します。 [ファイル]>[設定]> [サンプリング設定の編集]。このダブルサンプリングにより、トラフィックをほとんど消滅させるため、エージェントは[トラフィック]> [ステータス]の下に表示されない場合があります。推奨される解決策は、サンプリング情報が含まれるようにルーター設定を変更することです（オプションテンプレートなど）。TrafficSentinel側での回避策として、[ファイル]> [設定]> [サンプリング設定の編集]で該当フローが事前サンプリングされていることをTrafficSentinelに設定することが出来ますが、このアプローチは脆弱です。どちらか側でサンプリングレートを変更すると、正確なサンプリングレートが把握できず、過少カウントまたは過大カウントが発生します。
  3. アクティブタイムアウト：[警告フラグ（下記参照）：CacheTimeout] ルーターのフローキャッシュは、実行時間の長いフロー（長い継続通信のフロー）についてある程度の間隔（粒度）でレポートするように設定する必要があります。問題があるケースとしてはフローの開始から30分後にフロー情報が表示されてしまうような場合です。フローキャッシュのアクティブタイムアウト設定を、5分未満に設定する必要があります。できれば1分です。 Traffic Sentinelは、アクティブなタイムアウトが長いことを検出すると、警告フラグを設定します。 5分より古いすべてのトラフィックが集約され同じ分粒度でプロットされる可能性があるため、このエラーにより、分ごとの傾向チャートに大きな歪みが生じる可能性を警告します。
  4. Missing Keys：[警告フラグ（下記参照）：MissingKeys] Traffic Sentinelは、ネットワーク全体の複数の観測ポイントを通過するトラフィックフローを調整および重複排除します。これを行うには、フローレコードに少なくとも送信元アドレスや宛先アドレスなどの特定のフィールドが含まれている必要があります。 Traffic Sentinelは、この最小限のキーセットを持たないフローレコードを検出すると、警告フラグを設定します。
  5. Missing Times：[警告フラグ（下記参照）：MissingTimes] Traffic Sentinelは、開始時間と終了時間に応じて、フローレコードを1分粒度に分割します。これを行うには、フローレコードに少なくともフロー開始タイムスタンプとフロー終了タイムスタンプが含まれている必要があります。 Traffic Sentinelは、これらのフィールドを持たないフローレコードを検出すると、警告フラグを設定します。
  6. Missing In / Out Ports：[警告フラグ（下記参照）：MissingInOut] NetFlowフォーマットが入力/出力ポート番号を保有していない場合（含まれていたとしてもゼロで設定されている場合）、TrafficSentinelはトラフィックをインターフェースの入力か出力かで分離できません。そのリンクのトラフィックは、クエリをエージェント全体にスコープしたときに存在していても、インターフェースのIN/OUTレベルでは欠落しているように見えます。これは、[トラフィック]> [TopN]> [カスタム]チャートで「I/F In」キーと「I/F Out」キーを使用して判断できます。

稀な問題

  1. 欠落している値：[警告フラグ（下記参照）：PktCtr] Traffic Sentinelは、パケット数とバイト数の両方の統計量を追跡することを期待しています。フローレコードがバイトカウントフィールドのみで構成される場合、Traffic Sentinelは、平均パケットサイズの一般的な見積もりを適用してフレームカウントを見積もります。これにより、ネットワーク全体のパケット数の見積もりが歪む可能性があります。
  2. IP:0トラフィック：protocol (serverport)がIP:0のトラフィックが表示される場合は、IPプロトコルフィールドがテンプレートで構成されていることを確認する必要があります。このフィールドがないと、Traffic SentinelはTCP:53トラフィックとUDP:53トラフィックを区別できない場合があります。
  3. VMWare VDS：VMWare VDSでNetFlowエクスポートを設定する場合、システム全体を1つの大きなスイッチとしてモデル化するチェックボックスをオンにしないでください。各ハイパーバイザーの各仮想スイッチが自身のIPアドレスを使用してエクスポートするため、トポロジ内にそれぞれのデバイスおよび監視ポイントとして表示されるため、TrafficSentinelにとって有益です。
  4. Layer2 NetFlow：変更可能なLayer2トラフィックを監視するようにNetFlowを設定すると、レコードに以下のようなlayer2キーのみしか含まれない場合があります。；
    • Ingress ifIndex
    • Egress ifIndex
    • Ethernet Protocol
    • Source MAC address
    • Destination MAC address
    • VLAN
    • Frames
    • Bytes

    Traffic Sentinelはこれらのレコードを受け入れますが、サイト全体のトラフィックマトリックスを検討する際には注意が必要です。同じトラフィックがsFlow対応スイッチまたはルーターを通過すると、レイヤー4フローとして表示される場合があります。ほとんどの場合、クエリにlayer3またはlayer4キーを含めると、これらのlayer2のみのトラフィック測定は除外されるため、自動的に処理されます。

  5. Martians: パケットをサーバーの間違ったインターフェースで受信した場合、つまり、そのソースIP上のスイッチとの応答に使用されるものではない場合：
    sudo ip route get <sourceIP>
    その後、それらは「Martians」としてサーバーのOSによってドロップされます。スイッチCLIを使用して、別のソースIPまたはコレクターIPに変更する必要があります。

警告フラグ

以下の条件のいずれかが検出されると、エージェントのステータスは黄色（警告）になります。これらの警告フラグのいずれかでフィルターする必要がある場合は、global.prefsでagent.warning.maskを設定できます（[ファイル]> [設定]> [設定の編集]> [ファイルの編集]> [global.prefs]）。たとえば、CacheTimeout、RetrofitSampling、およびSkewedTimesの警告をマスクするには、次のように設定できます。

agent.warning.mask = "CacheTimeout|RetrofitSampling|SkewedTimes"
  • Flow record active cache timeout too long (CacheTimeout)
    フローレコードのアクティブキャッシュタイムアウトが長すぎます
    ルータのアクティブフローキャッシュタイムアウト（active flow cache timeout）設定が5分を超えているように見える場合。
  • Missing flow record keys (MissingKeys)
    フローレコードキーがありません（MissingKeys）
    フローテンプレートに送信元アドレスキーや宛先アドレスキーがない場合。
  • Missing flow record in/out ports (MissingInOut)
    フローレコードの入力/出力ポートがありません（MissingInOut）
    フローテンプレートに入力および出力インターフェイスのifIndex番号がない場合。
  • Missing flow record times (MissingTimes)
    フローレコードタイムの欠落（MissingTimes）
    フローテンプレートにフローの開始/終了タイムスタンプがない場合。
  • Missing flow record packet count (PktCtr)
    フローレコードパケット数の欠落（PktCtr）
    フローテンプレートにパケットカウンタがない場合。
  • Bad flow record values (BadValues)
    不正なフローレコード値（BadValues）
    フローテンプレートにバイトカウンターがないか、パケットあたりのバイト数の推定が不可能な場合。
  • Unsampled flow records (RetrofitSampling)
    サンプリングされていないフローレコード（RetrofitSampling）
    エージェントが1:1フローレコード（パケットサンプリングなし）を送信しているように見えるため、Traffic Sentinelが１:Nサンプリングを適用する場合。これは意図した場合もあれば、NetFlowフォーマットでサンプリングレートを含めるようにルータを設定する必要がある場合もあります。
  • Skewed flow record times (SkewedTimes)
    スキュードフローレコード時間（SkewedTimes）
    エージェントのタイムスタンプとTrafficSentinelサーバーのシステムクロックの間に過度の相違があると思われる場合。解決策は、どちらか一方のクロックを再同期することです。