タグ付けされた質問 「packet-loss」

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Network Engineering Stack Exchangeのトピックになるようにします。 11か月前に閉鎖されました。 たぶん私はかなり基本的なものを見逃しているかもしれませんが、私にはわからないので、私は尋ねると思いました。 テストの観点から、さまざまなTDMoEがBERとパケット遅延にどの程度敏感であるかについて、イーサネットレベルで遅延とランダムなパケットドロップをシミュレートする方法を検討しています。これらのテストでは、同様のStackOverflowの質問で説明されているように、おそらくiptablesを実行するだけです。ただし、ここでは機能しますが、より一般的なケースで機能するかどうかはわかりません（おそらく、Windowsサーバーなどの間でBERトレランスをテストします）。だから、これは私に考えさせられました。 テストプロトコルにストレスをかけ、遅延とパケット損失に対する感度を評価するために、人為的にパケットを遅延またはドロップできる安価なネットワークテストデバイスはありますか？ 私の要件は、これをイーサネットレベルで実行できるようにすることです。特定のデバイス、ブランドなどをそれほど探しているわけではありません。もしそうなら、それらがどのようなものであるかのいくつかの一般的なアイデア。私は、これを行うためにLinuxとiptablesを実行する単純なブリッジの構築を主に検討しています。これが正しい方法かどうか疑問に思っています。

23 ethernet  ber  packet-loss  testing 

レイヤ2トランスペアレントモードでCisco ASA 5585を使用します。構成は、ビジネスパートナーdmzと内部ネットワークの間の2つの10GEリンクのみです。シンプルなマップは次のようになります。 10.4.2.9/30 10.4.2.10/30 core01-----------ASA1----------dmzsw ASAには8.2（4）およびSSP20があります。スイッチは、12.2を備えた6500 Sup2Tです。スイッチまたはASAインターフェイスでのパケットドロップはありません!! スイッチ間の最大トラフィックは約1.8Gbpsで、ASAのCPU負荷は非常に低くなっています。 奇妙な問題があります。nms管理者は、6月に開始された非常に悪いパケット損失を見ています。パケット損失は非常に急速に増加していますが、その理由はわかりません。ファイアウォールを通過するトラフィックは一定のままですが、パケット損失は急速に増加しています。これらは、ファイアウォールを介して発生するnagios pingの失敗です。Nagiosは、すべてのサーバーに10のpingを送信します。一部の障害ではすべてのpingが失われますが、すべての障害で10個のpingがすべて失われるわけではありません。 奇妙なことは、nagiosサーバーからmtrを使用する場合、パケット損失はそれほど悪くないということです。 My traceroute [v0.75] nagios (0.0.0.0) Fri Jul 19 03:43:38 2013 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Drop Last Best Avg Wrst StDev 1. 10.4.61.1 0.0% 1246 0 0.4 0.3 …

19 cisco  switch  cisco-asa  firewall  packet-loss 

ルートの輻輳とパケット損失が原因で遅延とStDevが増加していますが、フォワードパスとリバースパスが異なるネットワーク（例：init7.net、もう1つはhe.net）を経由するため、理解するのが非常に困難ですどのネットワークまたはホストが、輻輳、パケット損失、ジッター、および遅延の増加を引き起こしています。 フォワードとリバースmtrが正確な原因を特定できず、NOC @の連絡先が応答しないか、問題のパスで損失がないと主張した後、責任を絞り込む方法はありますか？（私はOpenBSDを使用しています。） 私はmtr、輻輳が発生している可能性がある2つのネットワークの両方の一部の顧客に直接実行してみましたが、特に、たとえばhe.netには多くのPOPがあり、しばしば特定の入口と出口POPの間で異なるルートが取得されるためmtr、ネットワークでパケットを失う可能性のある出口POPで直接ホスト（tservなど）にアクセスしようとすると、別のhe.netパスが到達するまったく同じPOPであり、パケット損失は発生しません。これは、何も問題がないことを証明します（一部のルートが実際に過負荷になり、他のルートが混雑しないようにする一方で、非顧客からのNOC @要求を無視する可能性があるという示唆以外）。

10 latency  packet-loss  mtr 

モデムにルーターを接続しています。私の意図は、約200フィート離れたオフィスから2つの壁を介してこのルーターに接続することです。 ルーターの信号はリモートの場所に到達するのに十分ではないので、間にレンジエクステンダーを挿入しました。 非常に混乱しているのは、私のコンピューター（または任意のクライアント）が隣に座っている間にエクステンダーに接続すると、完全に機能する（pingの時間は約30ミリ秒）ことです。 ただし、リモートの場所に移動すると、wifi信号の強度が3/4または4/4バーのいずれかであっても、パケット損失は大きく、レイテンシは大幅に変化します。しかし、その後は800以上に低下し、約10％でパケットが完全にタイムアウトします。 だから、私の質問は...信号強度が良い場合、なぜこの距離がそのような恐ろしいパケット損失を引き起こすのでしょうか？そして、何がそのような干渉を引き起こす可能性がありますか？私は住宅街にいますが、ラップトップと信号中継器の間に2つの壁以外の見通し線はありません（電気配線が何であれ）。

10 wireless  packet-loss 

WiresharkでTCP duplicate ACK、受信者から送信者に送信されるパケットを確認します。どういう意味ですか？パケット損失を意味しますか？ ありがとうございました

10 cisco  tcp  packet-loss  transport-protocol 

エンドツーエンドではなく、ネットワークのリンクごとのレイテンシ、ジッター、パケット損失を測定する必要があります。たとえば、次のようにします。 s1-eth0 <-> s2-eth0（平均レイテンシ20µs、標準偏差10µs、57％パケットロス/最後の秒） s2-eth1 <-> s3-eth0（平均待ち時間〜25µs、標準偏差5µs、21％パケット損失/最後の秒） ... 私が見つけることができたすべての解決策は、学術的な提案であるか、アクティブなプロービングに専用ハードウェアを使用することを含みました。 これは私の研究によるとうまくいかないことの要約です： NetFlow：待ち時間情報なし、エンドツーエンドのみ アクティブプローブ：ネットワークの構成を変更することはできません 往復時間の測定：リンクごとの統計は提供されません 上記の統計のすべてまたは少なくとも一部を提供するネットワークプロトコル、測定ツール、またはその他の機能はありますか？

9 router  switch  monitoring  latency  packet-loss 

Sup 720を搭載したCisco 6500で、10gb / sインターフェイスで特定の数のパケットがドロップされました。カウンターをクリアした後、1分以内にドロップされたパケットの数の下に表示されます。 パフォーマンスの低下は見られず、お客様からの不満はありません。これは今後深刻な問題になるのでしょうか？キューに1つのパケットを表示したことはありません。デフォルトでは75パケットであるため、入力キューのサイズを1024に変更することを検討していますが、ドロップされる前にパケットがキューに入らないのはなぜでしょうか。1gb / sインターフェースでは、ドロップされたパケットはまったく見られず、すべて正常です。キュードロップに関する問題の解決を手伝ってください。 sh int TenGigabitEthernet1/1 Hardware is C6k 10000Mb 802.3, address is 000f.3589.ac00 (bia 000f.3589.ac00) Description: transit Internet address is 192.0.2.1/24 MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec, reliability 255/255, txload 84/255, rxload 3/255 Encapsulation ARPA, loopback not set Keepalive not set …

9 cisco  cisco-6500  packet-loss 

最近、いくつかのMetroE回路（L2接続）を100Mbpsから1Gbpsにアップグレードした後、一部のサイト間で大きなファイル転送が失敗することに気付きました。ただし、転送は方向にのみ失敗します。たとえば、次の例を考えてみましょう。 から->へ A-> B =失敗 B-> A =成功 A-> C =成功 C-> A =成功 B-> C =成功 C-> B =成功 各サイトは、サイトにあるL3スイッチの背後にあるルーティングされたセグメントです。L3スイッチはプロバイダーのCPEメディアコンバーターに接続し、CPEメディアコンバーターはファイバーを介してプロバイダーのネットワークに接続します。静的ルーティングは、L3スイッチ間で使用されます。 *Site A* *Site B* L3 Switch <-> CPE <--- Provider ---> CPE <-> L3 Switch | CPE | L3 Switch *Site C* プロバイダーはCPEからの回線のエンドツーエンドのテストを実行し、損失は報告していません。ただし、転送が失敗する前に、ホスト上のパケットキャプチャに重複したACKが多数表示されます。 式からL3スイッチを削除し、2つのホストを各サイトのCPEデバイスに直接接続すると、ファイル転送は正常に完了します。 Host A <-> CPE <--- …

8 packet-loss  metro-ethernet 

英国と米国の農場にいくつかの組み込みPCがあります。他の接続の中で、これらは20秒ごとに小さなデータパケット（100〜600バイト）を送信するサーバーと通信します。 DSLではこれで問題ありません。衛星接続では、ほとんどのパケットが失われます。 TCPを使用しており、クライアントのtcpdumpでシーケンスが表示されます。 -> syn (send) <- syn ack (receive) -> ack -> push ack <- ack (spoofed?) -> fin ack <- ack (spoofed?) <- fin ack -> ack ただし、サーバーには次のように表示されます。 <- syn (receive) -> syn ack (send) <- ack <- fin ack -> fin ack <- ack 接続を高速化するために、クライアントが受信する余分なackがサテライトエンドポイントによって偽装されていると私は思う 100を超えるDSLサイトと3つの衛星があります。DSLはすべて問題なく、衛星はすべて同じように壊れています。 データはどうなっていますか？20回に1回ぐらいです。 …

8 tcp  packet-loss 

ホスト間の2つのリンクの助けを借りて、ルート障害検出のための時間遅延なしに、TCP接続のフォールトトレランスを実現するテクノロジーを探しています。このようなもの： link1 packet1copy1-> -------------------------- packet1-> / \ packet1copy1/packet1copy2-> host1--------router1 router2 ------------------------host2 \ link2 packet1copy2-> / -------------------------- host1とhost2を介して接続されているrouter1とrouter2、それらの間に2つのリンクで。各ルーターは、ホストからのすべてのパケットを複製してから、両方のリンクに同時に転送します。次に、ピアルーターまたは宛先ホストIPスタックのいずれかが、冗長パケットの除去を処理します。 編集： これは実際には、TCP（IP）トランスポート用のレプリケーションによる汎用のフォールトトレランスソリューションの検索です。ソリューションは、BGP / OSPF / Cisco IP SLAなどの適度に高速なリカバリアプローチとは対照的に、リカバリが不要なタイプである必要があります。一部の独自仕様のパケット冗長ソリューションは、あまり知られていませんが、すでに知られています。特に、Engage CommunicationはVoIP用のIP Tube Protectorを提供しています。残念ながら、このソリューションは、1）標準テクノロジーよりも多くの機器であり、2）VoIPドメインのみに限定されています。ジュニパーパケット冗長テクノロジーも注目に値するかもしれませんが、冗長リンクではなく単一リンクのみに限定されているように見えます。 なぜCiscoから同様のものが見つからないのでしょうか...標準または少なくとも汎用のテクノロジーはこれに対処しますか？

7 tcp  redundancy  failover  architecture  packet-loss