最近、トラフィックフローの機能強化を展開して以来、広く採用されていますが、Netflow / Jflowなどに関するサポートケースも驚くほど多くなっています。 発生した奇妙なケースのいくつかを見ていきます（いいえ、この記事は単なる先祖返りではありません パブリック・エナミーの歌.)
現在、Netflow（またはJflow）は、バージョンが異なっていても、一般的にかなり単純なプロトコルです。 ルーターまたはスイッチはそのトラフィックを調べます。 フロー内のパケットとバイトの数（送信元IPとポート、および宛先IPとポート間の会話）をカウントし、その要約をNetFlowレシーバーに送信します。
物事がうまくいかないXNUMXつのケースは、タイムスタンプにあります。
SonicwallファイアウォールからのNetflowパケットのWireshark検査からの次のキャプチャを確認してください。
これで、Netflowが機能するはずです。ルーターは現在の時刻を送信します（[タイムスタンプ]フィールド：上記の17月1806日）。 また、その時点（1806315秒）で稼働時間を送信します。次に、フローごとに、フローの開始時と終了時に稼働時間カウンターの値を送信します。 したがって、このフローの場合、ルーターは、ルーターの稼働時間が1806秒しかない場合でも、稼働時間の値が20秒のときに開始されたフローを報告します。 したがって、このフローは約XNUMX日後に開始され（同時に終了しました）、LogicMonitorはフローを拒否し、時間の問題を報告しました。 ただし、ファイアウォールが正しく構成されており、トラフィックデータを表示できないため、これはユーザーの役に立ちません。 この種のバグのあるフローオリジネーターを回避するために、デバイスのタイムスタンプを無視し、到着したすべてのフローを今からのものであるかのように扱うオプションを追加します。
もう1つの興味深い問題は、インターフェイスが識別されない場合です。 現在、Netflow（Jflowなど）には、インターフェイス名を識別する方法が直接含まれていません。 代わりに、SNMPインターフェイステーブルインデックスによってインターフェイスを参照します。 上記のパケットキャプチャで確認できます。InputIntの値は1でした。したがって、これはsnmp ifTableのインデックスが0のインターフェイスであり、これを使用してインターフェイスの名前（ethXNUMXなど）を取得できます。
では、次のように、わかりにくい番号として表示されるインターフェイスをどのように作成するのでしょうか。
一部のデバイス（上記はパロアルトファイアウォールからのもの）は、SNMPを介して管理していないインターフェイスからのNetflowトラフィックを報告できることがわかりました。 パロアルトファイアウォールの場合、SNMPテーブルには物理インターフェイスのみが含まれますが、トラフィックフローソースは論理インターフェイス（VLanインターフェイスやサブインターフェイスなど）にすることができます。したがって、デバイスは、で表示されないインターフェイスのインターフェイス識別子を報告します。 SNMPテーブル–したがって、「わかりやすい」名前に関連付ける方法はありません。 （この場合、手動で名前を定義できます。）Palo Altoがインターフェイステーブルに存在しないインターフェイスのNetflow識別子に到達する方法の詳細については、を参照してください。 この文書.
私たちが遭遇する別のケースは、フローサンプリングに関してそれ自体と矛盾するデバイスです。両方ともサンプリングレート（1分の20など）を報告しますが、サンプリング方法は「オフ」（サンプリングが有効になっていないことを意味します）です。これを行うデバイスは、サンプリングレートではなく、サンプリング方法に依存しているようです。 （実際にはサンプリングを行っています。）
幸いなことに、ほとんどのデバイスはトラフィックフローのエクスポートを正しく実装しています。デバイスを通過するトラフィックをこのレベルで可視化すると、トラブルシューティングに大いに役立ちます。 しかし、興味深いので、仕様を誤って実装する方法がいくつあるかを確認してください。 🙂