web-dev-qa-db-ja.com

ネットワークトラフィックの監視

ネットワーク全体(いくつかのサブネット)のネットワークトラフィックを監視/分析するための最良のツールは何ですか?

たとえば、ユーザーが「ネットワークが遅い」と不平を言い始めたときに、帯域幅の問題を解決するのに役立つ何かを探しています。

18
Brent

私はあなたが市販のルーター/スイッチを持っていると仮定しています、それはおそらく [〜#〜] snmp [〜#〜] を持っています [〜#〜] mrtg [ 〜#〜] ニースのトラフィックグラフの場合。

10
Adam Gibbins

私はあなたの最善の策は CactiNtop の混合になると思います。

ntopは、最も消費しているホストなど、ネットワーク上のトラフィックに関する情報を提供します...どのトラフィックが速度低下を引き起こしているのかなど...

Cactiは、帯域幅の消費に関する長期的な傾向を示し、ネットワークトラフィックが時間の経過とともにどのように変化したかを知ることができます。

10
Mark Turner

「ネットワークの問題」を報告するユーザーがいる場合、問題は多数の問題(ルーティング、スイッチング、ホスト構成、ユニキャスト、マルチキャスト、セキュリティポリシー、ハードウェア障害)に関連している可能性があります。さまざまな潜在的な問題をすべて監視する1つのソフトウェアを見つけることはほとんどありません。

代わりに、2つのことに焦点を当てます。

  • Instrumentation:定期的に発生する障害を事前に監視できる監視戦略を考え出します。詳細はこちら 前の回答 を参照してください。

  • トラブルシューティング:問題が発生している可能性のある場所をすぐに特定して公開するために実行できる、迅速で標準的な一連のテストを考え出します。ユーザー。

いくつかのテスト例:

  • デフォルトゲートウェイにpingを実行します
  • 同じサブネット上の別のホストにpingを実行する
  • サブネット外のホストにpingを実行する
  • どのようなパケット損失が発生していますか?
  • 結果はパケットサイズによって異なりますか?
  • コマンドラインから宛先IP /ポートに正常にTelnetできますか?

これらの種類の単純な診断は、多くの場合、正しい方向に非常に迅速に対応できます。最後に、可能であれば、常に送信元IP、宛先IP、および宛先ポートを取得します。ユーザーを教育してみてください。 「ネットワークが遅い」などのあいまいな苦情は簡単に診断できません。

4
Murali Suriar

[〜#〜] mrtg [〜#〜] および/または ntop を試してください。

3
Node

私は、中小規模のネットワーク(〜500ユーザー)と約12の/ 24サブネット(およびNATの背後にある少数の小規模なサブネット)を持つ組織で働いています。私たちはさまざまな監視ソフトウェアを使用して、ネットワークのリモート部分を監視し、問題にプロアクティブに対応できるようにしています。

  • [〜#〜] snmp [〜#〜] -これは、監視システムの基礎を形成します。すべてのネットワークインフラストラクチャは、少なくともSNMPをサポートし、syslogを介して中央サーバーにロギングする必要があります。
  • OpenNMS -主にイベントの監視に使用されますが、資産とパフォーマンスの追跡に使用され始めています。私は常にOpenNMSを監視しています。ネットワークに問題がある場合は、誰かに電話される前にそのことを知りたいです。
  • SFlow /Netflow-これは、ネットワークのどの部分を通過するトラフィックの量と、そのトラフィックを生成しているホスト(つまり、トップトーカー/トップリスナー)を判別するのに非常に役立ちます。
  • スモーキング -これは主に遅延と接続の追跡に使用され、特にワイヤレスブリッジやその他の厄介な接続に使用されます。
  • [〜#〜] mrtg [〜#〜] --SFlow/Netflowをサポートしないインフラストラクチャデバイスでのトラフィック監視はMRTGで行われます。
  • Linuxネットワークの「プローブ」-ネットワークの一部は設計上到達できず、物理的に個別の接続があります。両方のネットワークセグメントにポイントオブプレゼンスがあるLinuxインストールの古いワークステーションでは、前述のSmokepingやMRTGなどのツールだけでなく、ntop、tcpdump、などの便利なコマンドラインツールを使用してこれらのセグメントを監視できます。 tcptraceroute、httping、および由緒あるping。
  • TippingPoint IPS System -基本的には Snort in ブラックボックス 。パターン認識に完全に依存していますが、 TippingPointシステムはネットワークエッジ上にあり、興味深いレイヤー7イベント(マルウェア、スキャン、TCP/IPの異常など)を探すことができます。
  • BlueCoat Packeteer -これは主にQoSおよびWebフィルタリングデバイスですが、レイヤー7の入力および出力トラフィックが何に分類されるかについての優れた高レベルのビューを提供します。例:入力トラフィックの80%がHTTPであることは当然のことですが、そのどれだけがFacebook、Pandora、YouTubeなどですか?また、アプリケーションごとのトップトーカー/トップリスナーのリストも提供します。これも興味深い情報です。
  • Wavemon そして、適切なワイヤレスカードを備えたラップトップは、802.11ワイヤレスの監視とトラブルシューティングに実質的により安価な代替品として使用されます Fluke AirCheck 。 Flukeは5Ghz(一部のワイヤレスブリッジで使用)をサポートし、801.11以外のトラフィックを拾うことができ、便利なRFツールですが、費用。
2
user62491

私は自宅で smoothwall を使用して大成功を収めています。これは、トラフィックを監視するのに最適です。

それは、いくつかのより凝ったことをする企業版でもあります。

なぜ帯域幅が不足し続けたのか(オーストラリアでは制限があります)、それが私のせいであることが判明した理由を理解しようとしていました:)

2
Sam Saffron

VSS Monitoring の製品をチェックしてください。ネットワークトラフィックをリモートで監視するためのインラインフェイルセーフ製品がいくつかあります。ネットワークとバックボーンをピアリングしたら、そこにいるのと同じくらい良いです。

1
Tall Jeff

Netflowを報告できるルーターがある場合は、netflowハンドラーを調べます。 MRTGがリンクの使用率を提供する場合、netflowsはルーターを流れるIPおよびプロトコルの使用状況を報告します。したがって、「スージーが大量のトラフィックを使用してアカウンティングを行っている」または「WAPが使用されているポートの使用率が高い」の代わりに、「スージーがアカウンティングで10%のLANトラフィック、40%のストリーミングメディア、50%のインターネットを使用しているHTTPトラフィック。

残念ながら、フリーフローアグリゲーターの推奨事項はありません。ネット監視会社が私の会社にソリューションを販売しようとし、製品全体がネットフローに基づいていると判断した後、私はそれらを調査するようにメモしました。私がそれに取り掛かる前に、フローアグリゲーターも含む別のNOCソリューションを購入しました。

1
jj33

Wireshark を何年も使用しています。大好きです。

1
Spencer Ruport

まず第一に、彼らはあなたのローカルネットワークについて不平を言っているユーザーですか?

ファイルサーバーが遅いです!

または彼らはリモートのウェブサイトについて不平を言っていますか?

Facebookは遅いです!仕事ができない!

前者の場合は、問題のファイルサーバーから始めて、逆方向に作業します。まず最初にファイルサーバーをチェックします、それは通常の使用率ではありませんか?ユーザートラフィックが流れるインターフェイスを確認します。固定されていますか?オートネゴシエーションは有効になっていますか?両端で有効になっていますか...

すべてが正常に見え、サーバーに過度の負荷がかかっていない場合は、ユーザーとサーバーの間のパスにあるルーターとスイッチを試してください。それらは過負荷ですか?自動否定が有効ですか?インターフェイスカウンタにエラーがないか確認してください。

それが問題ではないと思われる場合、問題はユーザーのワークステーションに起因している可能性があります。過度の負荷がかかっていますか?ハードウェアエラー(ファームウェアの再試行中にブロッキングを引き起こすディスクエラー)はありますか?彼らのマシンは実際のメモリが不足していますか(Firefoxのページングは​​ハードです)?

これは通常、問題の99%を解決します。

これらのリクエストを処理する必要がある頻度によっては、これらの手順の順序を逆にすることをお勧めします。

または、リモートサイトに問題がある場合は、ネットワークをデバッグした後、ユーザーのワークステーションでmtrなどのツールを試して、ユーザーとリモートサイト間のパケット損失を検出します。問題がネットワークに限定されていない場合、オプションはおそらくプロバイダーにケースを記録するか、リモートサイトが問題を解決するまで待つことに限定されます。

1
Dave Cheney