問題
ktranslate
ネットワーク モニタリング エージェントのインストール後、ネットワーク フロー テレメトリの収集で問題が発生します。
背景
ktranslate
パケット ペイロードを編集せずに、収集された生のフロー テレメトリを返します。すぐにサポートされるフローの種類はいくつかありますが、最も有名なものはNetFlow v5 、 NetFlow v9 、 sFlow 、およびIPFIXです。
すべてのネットワーク フロー テレメトリは、 KFlow イベント タイプに保存されます。これは NRQL で直接クエリできます。このイベント タイプが存在しない場合は、アカウントがデータを受信していないことを示します。
FROM KFlow SELECT *
解決
ktranslate
エージェントは、実行時に-nf.source引数によって構成された 1 種類のフロー テンプレートのみを収集できます。デフォルトはauto
です。これにより、 ktranslate
NetFlow v5
からのテンプレートを期待するように指示されます。 NetFlow v9
| sFlow
| IPFIX
なので、パケットを変換できます。よくある問題は、特定のタイプのフロー テンプレートをリッスンするようにktranslate
を設定し、別のタイプをエージェントにエクスポートすることです。auto
でカバーされていないテンプレートについては、別のコンテナを実行する必要があります。
ここでのもう 1 つのよくある間違いは、複数のポートを宛先としてターゲットにして、フロー テレメトリをktranslate
エージェントにエクスポートすることです。このシナリオでは、実行時に-nf.portの異なる値をそれぞれ設定して、複数のktranslate
エージェントを実行する必要があります (デフォルトは9995
)。特定のポートをターゲットにするために、ソース ネットワーク デバイス上のフロー エクスポーター設定を更新する必要がある場合もあります。
各ベンダーは、ネットワーク フローのエクスポート用にデバイスを適切に構成するための独自のドキュメントを用意しています。NetFlow v9
、 IPFIX
、 sFlow
などのより高度なバージョンには、管理者が収集およびエクスポートされるフィールドをカスタマイズできるオプションがあります。これらを編集すると、 ktranslate
によるフロー レコードを正しく処理する機能が実質的に無効になる可能性があります。
次のフィールドはrequiredです:
- プロトコル (フィールド タイプ番号:
4
) - レイヤ 4 プロトコル - 送信元アドレス (フィールド タイプ番号:
8
、27
) - 送信元 IPv4 または IPv6 アドレス - 送信元ポート (フィールド タイプ番号:
7
) - 送信元 TCP/UDP ポート - 宛先アドレス (フィールド タイプ番号:
12
、28
) - 宛先 IPv4 または IPv6 アドレス - 宛先ポート (フィールド タイプ番号:
11
) - 宛先 TCP/UDP ポート
- Interface Receive (フィールド タイプ番号:
10
) - 入力インターフェイスの SNMP インデックス - インターフェイス送信 (フィールド タイプ番号:
14
) - 出力インターフェイスの SNMP インデックス
- デルタ バイト (フィールド タイプ番号:
1
) - デルタ バイト - 合計バイト数 (フィールド タイプ番号:
85
) - 合計バイト数 - 出力バイト数 (フィールドタイプ番号:
23
) - 出力バイト数 - イニシエーター オクテット (フィールド タイプ番号:
231
) - イニシエーター バイト - レスポンダー オクテット (フィールド タイプ番号:
232
) - レスポンダー バイト
- デルタ パケット (フィールド タイプ番号:
2
) - デルタ パケット - 合計パケット数 (フィールド タイプ番号:
86
) - 合計パケット数 - 出力パケット (フィールド タイプ番号:
24
) - 出力パケット - イニシエーター パケット (フィールド タイプ番号:
298
) - イニシエーター パケット - レスポンダー パケット (フィールド タイプ番号:
299
) - レスポンダー パケット
- ToS (フィールド タイプ番号:
5
) - サービスのタイプ - 送信元 AS (フィールド タイプ番号:
16
) - 送信元 BGP 自律システム番号 - 宛先 AS (フィールド タイプ番号:
17
) - 宛先 BGP 自律システム番号 - ピアソース AS (フィールドタイプ番号:
129
) - ピアソース BGP 自律システム番号 - ピア宛先 AS (フィールド タイプ番号:
128
) - ピア宛先 BGP 自律システム番号
ヒント
ktranslate
レコードが明示的に値egress
を使用しない限り、すべてのフロー レコードはデフォルトでDirection: ingress
になります。これは、フロー レコードがDirection
フィールドなしで送信されるさまざまな状況をカバーします。
各ベンダーには、デバイス CLI/UI を介したフロー エクスポート カウンタの監視に関する独自のドキュメントがあります。デバイス上でカウンタが増加しない場合は、フロー エクスポートがデバイス上で正しく設定されていないことを示します。
ktranslate
の Docker コンテナと Linux サービス デプロイ オプションは両方とも、ホストのネットワークを使用して、マッピングされたポートでデータを受信します。フロー レコードがホストによって受信されていることを検証するには、 tcpdumpユーティリティを使用してパケット キャプチャ ( .pcap
) ファイルを作成し、後でWiresharkで調査できます。
このコマンドを実行すると、ホスト上のすべてのインターフェイスにわたってすべての受信パケットをキャプチャするようにtcpdump
が設定され、出力が現在のディレクトリ内のファイルに書き込まれます。
$sudo tcpdump -s 0 -i any -w dump_capture.pcap
tcpdumpには複数の引数を追加できることに注意してください。ここで最も重要な項目は、後で分析に使用できる出力ファイルです。STDOUT
に結果を出力すると、現在の目的に対して限定された値が作成されます。
このファイルを取得したら、次のセクションで結果を分析する方法を説明します。
ヒント
見つかった最も一般的な問題の 1 つは、ソース ネットワーク デバイスからターゲットktranslate
ホストへのパケットをブロックするネットワーク構成/ファイアウォール ルールです。tcpdump
ユーティリティで結果が得られない場合、トラブルシューティングを始めるのに最適な場所は、ネットワーク ルールとiptables
構成を確認することです。
Wiresharkを使用してパケット キャプチャ ファイルを検査するには、次の手順に従います。
Wireshark アプリケーションを起動し、パケット キャプチャ ファイルを開きます
最初のビューにはキャプチャされたすべてのパケットが表示されますが、フロー分析の場合は、それらを適切にデコードするようにアプリケーションを設定する必要があります。メニューを使用してAnalyze > Decode As...
に移動すると、新しいポップアップが開きます。
ポップアップで、左下のプラス ( +
) アイコンをクリックすると、パネルに新しい行が追加されます。Current
列の最初のオプションは(none)
です。これをクリックしてドロップダウン メニューを開き、 NetFlow
およびIPFIX
の場合はCFLOW
を選択するか、またはsFlow
パケットの場合はsFlow
選択します。右下のOK
クリックしてメイン UI に戻ります。
ヒント
このメニューは、大文字と小文字が区別されてアルファベット順に並べられています。sFlow
オプションはリストの一番下にあります。
メイン UI に、 CFLOW
| が表示されるはずです。 sFlow
個のパケットをProtocol
列で識別できるようになりました。表示フィルタ(cflow or sflow)
を適用すると、必要なパケットがキャプチャ ファイル内のその他のパケットから自動的に分離されます。
次のセクションでは、各パケット タイプを検査する方法の概要を説明します。
NetFlow
IPFIX
プロトコルは、管理者が標準オプションのリストから収集するフィールドを特定できるテンプレート アプローチを使用します。これらのパケットの分析は、 ktranslate
に必要なフィールドがキャプチャされていることを確認するために行われます。
Wireshark のメイン UI で、単一のCFLOW
パケットをクリックして選択し、 FlowSet n
というタイトルのセクションを展開します。ここで、 n
はパケット内の単一のフロー レコードを識別する整数です。次に、 Flow n
サブグループを展開して、このフロー レコードのフィールドを分析します。
ヒント
パケット内のTemplate Frame
リンクをクリックすると、このデバイスからのすべてのフローのテンプレートを含むキャプチャされたパケットに移動することもできます。
sFlow
とより伝統的なNetFlow/IPFIX
プロトコルのプロトコルの違いにより、分析する必要があるフィールドが異なります。
Wireshark のメイン UI で、単一のsFlow
パケットをクリックして選択し、 InMon sFlow
というタイトルのセクションを展開します。次のフィールドが存在する必要があります。
フィールド | 説明 |
---|---|
データグラムのバージョン | この sFlow パケットのバージョン。 |
エージェントのアドレスタイプ | IPv4 (1) または IPv6 (2) |
エージェントのアドレス | フローのエクスポート元の IP アドレス。ここでフロー エクスポーターを構成します。 |
サブエージェントID | sFlow v5 では、複数のエクスポータ プロセスを実行できます。これはそれらの一意の識別子です。 |
シーケンス番号 | エージェントデバイスによって送信された sFlow パケットの数。 |
システム稼働時間 | エージェントデバイスが最後に再起動されてからの時間。 |
サンプル数 | 現在のパケットに含まれる sFlow サンプルの数。 |
Flow sample
というサブグループを展開すると、次の追加フィールドが表示されます。
フィールド | 説明 |
---|---|
企業 | このフィールドは、管理者が sFlow エクスポートを構成するときにオプションで有効にできるカスタム sFlow エンタープライズ構成に注釈を付けます。(デフォルトでは |
sFlowサンプルタイプ | これは、企業が sFlow エクスポートをカスタマイズするときに使用されるサンプルのタイプの指定です。定義はsFlow ドキュメントにあります。 |
サンプルの長さ | サンプルの長さ (バイト単位)。 |
シーケンス番号 | エージェントがサンプルを取得するたびに増加するカウンター値。 |
サンプリングレート |
|
サンプルプール | 実際にサンプリングされたパケットを含む、サンプリングされた可能性のあるパケットの合計。 |
ドロップされたパケット | リソースの制約によりドロップされたパケットの数。 |
入力インターフェース | パケットの到着元インターフェイスの SNMP ifIndex。 |
フロー記録 | このサンプルに含まれるサンプリングされたレコードの数。 |
ヒント
これと同じパターンを、 Decode as...
ステップなしで適用して、syslog データと SNMP トラップ データの両方の受信を検証できます。