☰

ルーター経由の軽いパケット損失

tag-icon • tag-icon ping juniper netscreen packetloss ssg5
ルーター経由の軽いパケット損失

最近、オフィスに光ファイバー回線を設置しましたが、ちょっとしたトラブルを除けば、すべて順調に機能しており、ネットワークの応答も実に素晴らしいです。

私たちが抱えている問題は、時々ルーターが故障してパケットをドロップすることです。回線の問題でもスイッチの問題でもありません。ルーター自体の問題で、ハードウェアを交換しましたが、両方で同じ問題が発生します。使用している機器は Juniper Netscreen SSG5 です。症状は次のとおりです。

私は「内部」インターフェースにpingfloodを実行します。

 ping -f -c 10000 <internal-ip>

そして、10,000 件の応答を受け取ります。毎回です。次に、外部インターフェイスの IP アドレス (ただし、同じデバイス上) を除いて同じことを行います。10,000 パケットのうち 10 ～ 15 パケットがドロップされます。社内の他のすべてのゲートウェイで同じテストを実行しましたが、他にはこの動作は見られません。困惑しています。

ファイバー会社のサポートと話をしましたが、両方のインターフェイスは 100Mb で全二重にハードコードされており、それが問題の原因である可能性もあります。ちなみに、ルーター内部から外部インターフェイスに ping を実行してもパケットが失われることはないので、インターフェイス自体の問題ではないと思います。また、ローカル インターフェイスではパケットが失われることはないので、スイッチの問題ではありません。

正直なところ、ハードウェア自体の設計以外に、どこに問題があるのか​​わかりません。グラフを見てきましたが、pingflood が発生しているときでも、ルーターの CPU やメモリを最大限に活用しているところまでは至っていません。

助言がありますか？

編集

Tom さんへ: ファイバーは 13Mb/s ですが、インターフェイスを ping するとファイバーに渡っていません。ローカル LAN は 100Mb/s で動作しており、内部インターフェイスはすべてのパケットに応答します。別のハードウェアを借りられるかどうか確認する必要がありますが、別のサイトに同じ症状が出ない古いモデルの Juniper (5GT) がいくつかあります。

答え1

次の 2 つの点に留意してください。

  1. SSG5 については詳しくありませんが、ルータはおそらく、そのルータ宛ての ICMP トラフィックを抑制するでしょう。
  2. 140MBit/秒の転送速度は、トラフィックがを通してルータ; トラフィックのアドレス指定にすべてのパケットがルーターの独自の IP スタックに渡され、応答パケットの生成が必要になるため、ルーターではパフォーマンスがさらに低下します。

試すテストをいくつか紹介します。

  1. LANからpingfloodingを試してくださいを通してルーター、おそらく WAN リンクのリモート エンドでしょうか? (サービス プロバイダーが所有している場合は、より処理能力の高いものになると思います。)
  2. 走るiperfオフィス内のノードとインターネット上の外部のノードとの間で、どのような形状にされているかを正確に把握できます。

答え2

単なるアイデアですが、ファイバーの速度はどれくらいですか? ルーターのバックプレーンは実際にその速度でパケットを転送できますか? スイッチポートの接続を最大化することで、Cisco 857 のイーサネット バッファーがいっぱいになるという同様の問題が発生しました。

SSG5 は最新バージョンの ScreenOS を実行していますか? 最新のファームウェア アップデートですか?
仕様では、140Mbit、つまり 1 秒あたり 30k パケットを転送できるとされています。そうではないかもしれませんが、もっと強力なルーターならトラフィックに対応できるかもしれません。
誰かからもっと大きなデバイスを借りることはできますか? Cisco 2811 や Juniper J2320 などはどうでしょうか?

答え3

ファイバー/メトロ イーサネット (AT&T) に移行したときにも同様の問題が発生しました。

ルーターのインターフェースにエラーが表示されていますか? 当社では Cisco を使用しており、インターフェースに応じて CRC エラーまたは入力エラーが表示されます。

最終的に、各拠点で自動、10/半分と全、100/半分と全の間でさまざまなネゴシエーション方法を入れ替えて、自動または 100/全が「動かなくなる」まで試すことで、この問題を解決しました。また、帯域幅制限の問題かどうかを確認するために、プロバイダーに 13Mbps の上限を一時的に削除するよう依頼することもできます。

AT&T は、使用しているスイッチ (これも Cisco) のせいだと主張しましたが、代替モデルと交換することはしませんでした。エラーがなくなり、100/full が機能する (ハード コーディングまたは自動ネゴシエーションのいずれかによる) 限り、私たちは気にしなくなりました。

現在でも、一部のオフィスでは自動、一部のオフィスでは 100/full が残っています。これは、それがうまく機能しており、それを壊したくないからです。

関連情報