ドロップされたパケット、受信時のみ、Server 2008のみ、ネットワーク速度は100mb / s
私は本当に奇妙なものを持っています。
2つの異なるWindows 2008サーバーからファイルをダウンロード（およびダウンロードのみ）すると、過度の「TCP Dup ACK」と「TCP Fast Retransmission」でパケット損失が発生します。アップロード速度は問題ありません。
これは、クライアントコンピューター（Win7）が100mb/sで接続されている場合にのみ発生します。 1GBで、エラーはなく、フルスピードで動作します。クライアントのnicを100Mb/sに設定すると、多くの「TCP Dup」エラーが発生し、ダウンロード速度が約2〜5MB/sに低下します。アップロード速度は10MB/s以上です。
これは、Windows 2008 Serverボックス（Dellですが、ハードウェアが異なる）でのみ発生します。 Win7クライアントとLinuxサーバー間で送信する場合、この問題は発生しません。
これは、Server 2008がTCPウィンドウを適切にスケーリングできず、スイッチまたは何かに過負荷をかけ、トラフィックを少し一時停止するようなものです。
古い機器が原因でネットワークの一部が100Mb/sで動作しているため、一部の建物で実際に問題が発生しています。
ここからクライアントからpcapファイルをアップロードしました。 https://dl.dropboxusercontent.com/u/24907255/slow.pcap.gz
サーバーに50MBのファイルが書き込まれ、サーバーからエラーが返されて表示されます。
助けてくれてありがとう。私は困惑しています。
11/28/13詳細情報。
1つのクライアントと1つのサーバーだけがネットワーク上にあるように、ネットワーク全体をシャットダウンします。問題に変化はありません。
すべてのインターフェイス、サーバー、クライアント、Cisco 2960スイッチを100Mbsフルに設定すると、問題はなくなります。サーバーを設定し、インターフェイスを自動または1Gbsに切り替えると、問題が再発します。
Netgear 10/100スイッチを使用してスイッチをバイパスし、クライアントとサーバーの両方を自動に設定しても、問題はありません。
私はこれを発見しました。通常のセットアップでは、サーバーが1Gbsで切り替えるときに、クライアントとCiscoスイッチの間にNetgear 10/100スイッチを接続すると、速度の問題はさらに悪化します。速度は5-7MB/sから2-3MB/sになり、はい、固定および自動ネットワーク速度を試しました。これは、2つのスイッチホップがある建物とメインのCiscoスイッチの間に速度の問題が多い建物の理由を説明しています。
Pingに移ります。すべて1GB/sで、私は完全にpingできますTCPペイロード、ping -l 65500と動作します。100Mbsのクライアントでは、pingできる最大サイズは17752です。失敗、Windowsサーバーのみ、Linuxボックスでは問題なしサーバーとクライアント間のNetgear 10/100を使用すると、65500でpingを実行しても問題はありません。
アップデート3
PowerConnect 2748スイッチを交換しました。 1Gbsのサーバーと100Mbsのクライアントで同じ問題があります。私は今17752以上にpingできます。奇妙な。だから私はそれがシスコのスイッチではないと思います。
アップデート4。iprefを使用して、ハードナンバーを取得しようとしています。クライアントを100Mbsに設定し、コマンドipref.exe -c -u -b 10mを実行して、同じスイッチに接続されたすべてのシステム。したがって、サーバーに送信します。 1台のサーバーは現在負荷がかかっていない2008で、もう1台は負荷平均が.20のUbuntuです。
10mで
- Linuxジッタ0.022ms、パケット損失は0/8505
- サーバー2008ジッタ1.859、パケット損失68/8505
100mまで押し上げる
- Linuxジッタ0.445、パケット損失0/26634
- サーバー2008ジッタ0.542、パケット損失94/26596
次に、10分後に統計をクライアントに送信します
- Linuxジッタ0.271 ms、0/8500（0％）1データグラムが順不同で受信
- サーバー2008ジッタ.063、20/8505（0.24％）
100mまで押し上げる
- Linuxジッタ0.230 ms 4083/85443（4.8％）、1つのデータグラムが順不同で受信、95.7Mbs
- サーバー2008ジッタ0.237、28174/81718（47％）、51.1mbs
そのため、Server 2008は一般的に貧弱ですが、接続がクライアントの100 mbsの制限にプッシュされると、47％もの大きなパケット損失が見られます。
アップデート5。
PowerConnect 2748スイッチでテストしたとき、サーバーとスイッチ、およびクライアントとスイッチ間で異なるcat5ケーブルを使用しました。これにより、ケーブル配線やスイッチの問題が排除されます。
この環境には2つのWindows 2008 Serverがあり、異なる時間に、異なるハードウェアにインストールされています。彼らが共有する唯一のものはBroadcomブランドのNICですが、チップセットは異なります。どちらも同じ問題が発生しますが、私はメインのテストを一方で行っているため、問題が発生した場合でも、もう一方は機能します。
1つのサーバーには、2つのポートを備えたBCM5709Cと、同じBCM5709Cチップセットと2つのポートを備えたアドオンカード、pci expressが組み込まれています。私はそれらすべてを試しましたが、問題はまだ存在しています。したがって、これはハードウェアの問題を除外する必要があります。
アップデート6 12/3/13 Intel nicをインストールしました。変化なし。私はctcp設定をいじってみましたが、変更はありません。私もSMB2をオフにし、違いはありません。
100Mbsでさらにテストを行いました。3GBのISOイメージをサーバーにコピーし、ドラッグアンドドロップすると、平均で10MB/sになります。サーバーから同じ3GB ISOイメージをコピーすると、平均で6.3MB/sになります。
すべてのネットワークインターフェイスが自動および1Gbsに設定されている。 ISOをサーバーにコピー、平均101MB/s ISOをサーバーからコピー、平均57MB/s
したがって、サーバーからの読み取り速度は、書き込み速度のほぼ半分です。
これは、衝突と再送信を引き起こす速度/デュプレックスのミスマッチのように聞こえます。サーバーと反対側の間の設定ミスはこれを引き起こす可能性があります。不一致のもう1つの理由は、自動ネゴシエーションの失敗です。
接続の両端が速度とデュプレックスに関して同一に構成されていることを確認してください。
NICドライバー/ Windows NDISオフロード設定のいずれかが問題に関連しているかどうかを調査する必要があると思います。LSO（Large Send Offload）機能は完全に見てきたので、最も疑わしいと思いますすべてのトラブルシューティングブックの定義に反する方法でサービス（Broadcom NICを搭載したDellサーバー）を破壊します。
LSOが機能を強化するのではなく中断した場合の実際の効果は、LSOエンジンがスイッチがサポートするより大きなデータフレームを渡す可能性があることです。これにより、スイッチはこれらのフレームを暗黙的に破棄します。言うまでもなく、これはパフォーマンスの低下とパケット損失を引き起こします。障害は差し迫っている可能性がありますが、断続的に発生することもあり、トラブルシューティングが非常に困難になります。これについては、ここで詳しく説明します。 Large Send Offload and Network Performance
免責事項：これは、問題に対する可能な角度についてのベストエフォートの考えです。以下のいずれかの変更を実装すると、ネットワーク通信が中断されます。設定を適用した後、コンピュータを再起動する必要があります。私は参照用に最も興味深い設定をコピー/貼り付けていますが、リンクにはすべてのハードコア情報と警告が含まれています。公式ドキュメントを変更のベースとして使用することを強くお勧めします。この投稿はチェックリストのようなものです。
これを続行する前に、次のレジストリキーをバックアップしてください。
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
クールでない理由の1つは、以下で説明する公式のバグが原因です。特定の設定がコマンドラインから送信されると、関連のない値が変更されます。
Windows NICドライバGUIとWindowsの両方に設定が存在する場合、GUIとWindows CMD /レジストリの両方で無効にする必要があるかどうかを明確に理解できませんでした。答えを提示した私の読んだブログは、いくつかの細かい点に関して一貫性がなかったので、確信が持てませんでした。今日、私はどこにでも焦点を当てている設定のオプションを見つけて変更を試みます。 GUIオプションはここには示されていませんが、公式ドキュメントに記載されています。
また、同じカードの異なるNICドライバは、GUIの詳細設定でさまざまな粒度を示す場合があります。
タスクオフロードの無効化
このレジストリ設定は、 レジストリ値を使用した接続オフロードの有効化と無効化 で定義されているタスクオフロードを無効にします。
HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\DisableTaskOffload
Setting this value to one disables all of the task offloads from the TCP/IP
transport. Setting this value to zero enables all of the task offloads.
上記の設定で効果がある場合は、リンクで指定されているとおりに詳細を試すことができます。これを管理する設定はかなりたくさんあるので、それらすべてを貼り付けません。
ただし、LSOのものを提供します。
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\LsoV1IPv4
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\LsoV2IPv4
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\LsoV2IPv6
For all three: Enabled = 1(default). Disabled = 0.
接続オフロードの無効化
レジストリ値を使用した接続オフロードの有効化と無効化 で定義されています。
HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\TCPConnectionOffloadIPv4
Describes whether the device enabled or disabled the offload of TCP connections
over IPv4. Enabled = 1 (Default). Disabled = 0.
HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\TCPConnectionOffloadIPv6
Describes whether the device enabled or disabled the offload of TCP connections
over IPv6. Enabled = 1 (Default). Disabled = 0.
無効化TCP Chimney、TOE、およびTSO
無効にする方法TCP Chimney、TCPIPオフロードエンジン（TOE）またはTCPセグメンテーションオフロード（TSO）Win2008ホットフィックスに注意してください
および TCP Windows Server 2008のChimneyオフロード、受信側スケーリング、およびネットワークダイレクトメモリアクセス機能に関する情報 に関する情報。
Windows 2008 Server:
If the operating system is Microsoft Windows Server 2008 (any version
including R2), run the following from a Command Prompt:
1. netsh int tcp set global chimney=disabled
2. netsh int tcp set global rss=disabled
3. netsh int tcp set global netdma=disabled
Note: To display current global TCP settings, use the net Shell command:
netsh int tcp show global
4. Restart the server.
Note: Microsoft has identified an issue running the netsh command to set global
TCP parameters on Windows Server 2008 and Vista machines. Some global
parameters, such as TCPTimedWaitDelay, can be changed from their default or
manually set values to 0xffffffff. Before running the above command, Symantec
recommends reviewing Microsoft KB Article 967224 (support.Microsoft.com/kb/967224).
Upon completion of the above command's execution, Symantec also recommends
reviewing the TCP Parameters noted in the KB Article and applying the hotfix from
the article if needed.
`ホットフィックスはこのように問題を説明します：
After you run the command, the values of the following unrelated settings are
changed to 0xFFFFFFFF:
KeepAliveInterval
KeepAliveTime
TcpTimedWaitDelay
In addition, the "TcpMaxDataRetransmissions" are changed to 0xFF.
繰り返しになりますが、レジストリキー全体をバックアップしてから、何をすることもできます。
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
上からのハイライトのオフロードと一緒に問題をググると、NICオフロードによる同様の問題を説明する投稿、記事、ブログに終わりはありません。それでも機能しない場合はスタックが上に移動して他のことを試すことができると思います。これは、ケーブルが半分切れていないためではないためですNICまたはスイッチポート、そうですか？
常にネットワーキングデバイスで手掛かりを探してください.....したがって、Ciscoの場合は、「show interfaces f0/11」など、ケースに応じて何でも実行してください。再送信は、「クロストーク」などのイーサネットポート/ nic /ケーブルの不良が原因である可能性もあります。スイッチのshow intは、これらのエラー統計を表示するはずです。高すぎる
編集：これはマイクロソフトなので、おそらくそれが問題ですが、それ以外の場合は、通常、レイヤー1から始めて（物理ケーブルが適切であることを確認してください）、スタックを上に向かって作業します（つまり、レイヤー2）。速度/デュプレックス/マックアドレスフラッタリング、..レイヤー3 ip/udp/tcpファイアウォールなど...
これは、PowerManagementの属性やIRQの優先度など、「高度な」NICの属性にすることもできます。同じバージョンのドライバーがあると仮定します。移動：
Device Manager-> Network Interfaces-> Properties NIC-> Advanced Tab。
ここですべての値を確認して比較します。
100/1000ネットワークでジャンボフレームがオフになっていないか確認しましたか？
[〜＃〜]更新[〜＃〜]：
ジャンボフレームが使用されている場合、ブロードキャストドメイン上のすべてのネットワークハードウェアがそれを使用する必要があります。これは、従来の100mbデバイスでは不可能です。
Win2008 tcpが正確にどのように機能するかはわかりませんが、jomboフレームを提供すると、パケットサイズ（通常のパケット数ではない）で送信ウィンドウのスケーリングが開始される場合があります。次に、説明したような状況を観察します。
参考： http://m.windowsitpro.com/windows/q-how-do-i-enable-jumbo-frames
UPD2：
あなたが提供したパケットダンプを調べたところ、長さが1500を超え、チェックサムが不正なパケットがたくさんありました（長さが1500未満のチェックサムでも問題ありません）。それは私の仮定を確認します。
私が理解できない唯一のこと-それらは最初のセッションに関連しています：クライアントからサーバーへ（!!! ???）：
22:25:06.041113 IP (tos 0x0, ttl 128, id 31391, offset 0, flags [DF], proto TCP (6), length 40) 192.168.0.109.49225 > 192.168.0.252.Microsoft-ds: Flags [.], cksum 0x9422 (correct), ack 1453, win 1234, length 0
22:25:06.041223 IP (tos 0x0, ttl 128, id 31392, offset 0, flags [DF], proto TCP (6), length 64280, bad cksum 0 (->285)!) 192.168.0.109.49225 > 192.168.0.252.Microsoft-ds: Flags [.], cksum 0x82c0 (incorrect -> 0xc9bb), seq 718652:782892, ack 1453, win 1234, length 64240SMB-over-TCP packet:(raw data or continuation?
22:25:06.041254 IP (tos 0x0, ttl 128, id 31437, offset 0, flags [DF], proto TCP (6), length 1452) 192.168.0.109.49225 > 192.168.0.252.Microsoft-ds: Flags [P.], cksum 0x0517 (correct), seq 782892:784304, ack 1453, win 1234, length 1412SMB-over-TCP packet:(raw data or continuation?)
22:25:06.041278 IP (tos 0x0, ttl 128, id 31438, offset 0, flags [DF], proto TCP (6), length 2960, bad cksum 0 (->f1df)!) 192.168.0.109.49225 > 192.168.0.252.Microsoft-ds: Flags [.], cksum 0x82c0 (incorrect -> 0xfa12), seq 784304:787224, ack 1453, win 1234, length 2920SMB-over-TCP packet:(raw data or continuation?)
22:25:06.042134 IP (tos 0x0, ttl 128, id 31441, offset 0, flags [DF], proto TCP (6), length 2960, bad cksum 0 (->f1dc)!) 192.168.0.109.49225 > 192.168.0.252.Microsoft-ds: Flags [.], cksum 0x82c0 (incorrect -> 0x1d7e), seq 787224:790144, ack 1453, win 1234, length 2920SMB-over-TCP packet:(raw data or continuation?)
22:25:06.042492 IP (tos 0x0, ttl 128, id 31444, offset 0, flags [DF], proto TCP (6), length 5880, bad cksum 0 (->e671)!) 192.168.0.109.49225 > 192.168.0.252.Microsoft-ds: Flags [.], cksum 0x82c0 (incorrect -> 0xa74e), seq 790144:795984, ack 1453, win 1234, length 5840SMB-over-TCP packet:(raw data or continuation?)
後の調査結果で説明する効果は、IEEE 802.3uの動作方法と一致しています。
一方のインターフェース（NIC/Switchport）の速度をハードに設定し、もう一方をAutoに設定すると、デュプレックスの不一致が発生する可能性があります。
インターフェイスの1つを全二重にハードセットした場合、他のインターフェイスはデュプレックスを自動ネゴシエートできませんが、ハードセットも必要です。
両方のインターフェイスが自動/全二重にハード設定されている場合でも、一部のNIC（または適切に作成されていないWindowsドライバー）は、自動ネゴシエーションを動作モードのままにして、デフォルトで半二重に設定します。
これは私がそれらの事実を得た場所です：
シスコからの2つのドキュメントは、（特に）2900シリーズスイッチとトラブルシューティングNICからスイッチポートの接続問題に関するものです。特に、スイッチ側だけでなくNICについても、具体的なトラブルシューティング手順が含まれています。基本的な前提条件（オートネゴシエーション電気プロトコルなど）の詳細な知識を含む実用的なネットワーク分析をリードしており、PowerConnectが同様の動作条件（同じプロトコル標準に対して開発されている）である可能性が非常に高いです。自由に引用します。完全を期すために、少し後で形を整えますが、ざっと目を通すことをお勧めします。
Cisco CatalystスイッチのトラブルシューティングNIC互換性の問題
イーサネット10/100/1000Mb半/全二重オートネゴシエーションの設定とトラブルシューティング
ここで私は本当に興味深いもののいくつかを引用します：
自動ネゴシエーションの有効な構成テーブル
Speed determination issues can result in no connectivity. However, issues
with autonegotiation of duplex generally do not result in link establishment
issues. Instead, autonegotiation issues mainly result in performance-related
issues. The most common problems with NIC issues deal with speed and duplex
configuration.
Table 1 summarizes all possible settings of speed and duplex for FastEthernet
NICs and switch ports.
次に、書式設定を失うことなく、後でここに移植しようとする、非常に便利なテーブルに従います。この表には、1 Gbpsの速度の組み合わせと、同様の興味深い効果とコメントも含まれています。ただし、主な内容は次のとおりです。
* Configuration NIC (Speed/Duplex): 100Mbps, full duplex
* Configuration Switch (Speed/Duplex): auto
* Resulting NIC Speed/Duplex: 100Mbps
* Resulting Catalyst Speed/Duplex: 100Mbps half duplex
Comments: duplex mismatch (footnote 1)
* Configuration NIC (Speed/Duplex): auto
* Configuration Switch (Speed/Duplex): 100Mbps, full duplex
* Resulting NIC Speed/Duplex: 100Mbps full duplex
* Resulting Catalyst Speed/Duplex: 100Mbps half duplex
Comments: duplex mismatch (footnote 1)
* Configuration NIC (Speed/Duplex): 100Mbps, full duplex
* Configuration Switch (Speed/Duplex): 100Mbps, full duplex
* Resulting NIC Speed/Duplex: 100Mbps, full duplex
* Resulting Catalyst Speed/Duplex: 100Mbps, full duplex
Comments: Correct manual config (footnote 2)
表の脚注は最も興味深いものです。
(1) A duplex mismatch can result in performance issues, intermittent
connectivity, and loss of communication. When you troubleshoot NIC issues,
verify that the NIC and switch use a valid configuration.
(2) Some third-party NIC cards can fall back to half-duplex operation mode,
even though both the switchport and NIC configuration are manually configured
for 100 Mbps, full-duplex. This is because NIC autonegotiation link detection
still operates when the NIC is manually configured. This causes duplex
inconsistency between the switchport and the NIC. Symptoms include poor port
performance and frame check sequence (FCS) errors that increment on the
switchport. In order to troubleshoot this issue, try to manually configure
the switchport to 100 Mbps, half-duplex. If this action resolves the
connectivity problems, this NIC issue is the possible cause. Try to update
to the latest drivers for your NIC, or contact your NIC card vendor for
additional support.
1つのリンクパートナーだけで速度とデュプレックスをハードコードできないのはなぜですか？
As indicated in Table 1, a manual setup of the speed and duplex for
full-duplex on one link partner results in a duplex mismatch. This happens
when you disable autonegotiation on one link partner while the other link
partner defaults to a half-duplex configuration. A duplex mismatch results
in slow performance, intermittent connectivity, data link errors, and other
issues. If the intent is not to use autonegotiation, both link partners must
be manually configured for speed and duplex for full-duplex settings.
NIC互換性リンク の最後のトピック）は、上で引用した節で説明されている効果の技術的背景を持っています。この背景の基礎は、自動ネゴシエーションプロトコルの操作：
(Table of bits shortened down for relevance)
0.13 Rate Selection (least-significant bit [LSB])
0.6 0.13 1 1 reserved
1 0 1000 Mbps : 0 1 100 Mbps : 0 0 10 Mbps
0.12 Autonegotiation Enable
1 = autonegotiaton enabled
0 = autonegotiation disabled
0.8 Duplex Mode 1 = full-duplex 0 = half-duplex
0.6 Rate Selection (most-significant bit [MSB]). See bit 0.13
The register bits relevant to this document include 0.13, 0.12, 0.8, and 0.6.
The other register bits are documented in the IEEE 802.3u specification.
Based on IEEE 802.3u, in order to manually set the rate (speed), the
autonegotiation bit, 0.12, must be set to a value of 0. As a result,
autonegotiation must be disabled in order to manually set the speed and
duplex.
If the autonegotiation bit 0.12 is set to a a value of 1, bits 0.13 and 0.8
have no significance, and the link uses autonegotiation to determine the
speed and duplex. When autonegotiation is disabled, the default value for
duplex is half-duplex, unless the 0.8 is programmed to 1, which represents
full-duplex.
Based on IEEE 802.3u, it is not possible to manually configure one link
partner for 100 Mbps, full-duplex and still autonegotiate to full-duplex
with the other link partner. If you attempt to configure one link partner
for 100 Mbps, full-duplex and the other link partner for autonegotiation,
it results in a duplex mismatch. This is because one link partner
autonegotiates and does not see any autonegotiation parameters from the
other link partner and defaults to half-duplex.
さらに バグレポート はシスコからの同様の効果を見つけましたが、スイッチのハードウェア/ソフトウェア、OSバージョン、NICおよびドライバの組み合わせに関して非常に具体的です。正確な詳細を知らなければ、それはあまりにも投機的になります。
これは、プロトコルの定義とオペランドを使用した、調査結果の確認にすぎないと考えています。
ソリューション
したがって、これが野生の（しかし楽しい）ガチョウの追跡ではなかったと仮定すると、私はあなたを引用します：
1）「すべてのインターフェース、サーバー、クライアント、およびCisco 2960スイッチを100Mbsフルに設定すると、問題は解消されます。サーバーとスイッチのインターフェースを自動または1Gbsに設定すると、問題が再び発生します。」
2）「Netgear 10/100スイッチでスイッチをバイパスし、クライアントとサーバーの両方を自動に設定した場合、問題はありません。」
3）古いスイッチと互換性のあるNIC /ドライバーの組み合わせを見つけてください。必要に応じてご購入ください。
4）必要に応じて、スイッチをアップグレードするための予算を動機付けるために、確かな技術リファレンスと推論を使用してください。