NSX 環境において HTTP 通信の遅延と TCP Spurious Retransmission (誤った再送) が生じる
Article ID: 435054
Updated On:
Products
Issue/Introduction
免責事項：これは英文の記事「HTTP Communication Latency and TCP Spurious Retransmission in NSX Environments.」の日本語訳です。記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。最新情報は英語版の記事で参照してください。
- NSXへの環境移行後、クライアントとサーバー間のHTTP通信が著しく遅くなった。
- サーバー側でキャプチャされたパケットには、TCP Spurious Retransmission (誤った再送) メッセージが頻繁に記録されている。
- Wiresharkによるトラフィック分析の結果、ACKパケットに多数の[TCP CHECKSUM INCORRECT]エラーが発生しています。
- カプセル化されたパケット（Geneve）には、ゼロ以外のイーサネットトレーラー（eth.trailer）またはそれに類するものが含まれます。
パケットキャプチャの例:tshark -r server.pcapng -o tcp.check_checksum:TRUE -T fields -e frame.number -e frame.time_relative -e eth.trailer -e _ws.col.Source -e _ws.col.Destination -e _ws.col.Protocol -e frame.len -e _ws.col.Info<frame.number> <frame.time_relative> <SERVER_IP> <CLIENT_IP> TCP 54 80 → 23433 [ACK] Seq=26 Ack=890 Win=262656 [TCP CHECKSUM INCORRECT] Len=0<frame.number> <frame.time_relative> <SERVER_IP> <CLIENT_IP> HTTP 4065 HTTP/1.1 200 OK [Unreassembled Packet [incorrect TCP checksum]]<frame.number> <frame.time_relative> fefefefefefe <CLIENT_IP> <SERVER_IP> TCP 60 23433 → 80 [ACK] Seq=890 Ack=4037 Win=8047 [TCP CHECKSUM INCORRECT] Len=0 <=== this packet is ignored by the server.<frame.number> <frame.time_relative> <SERVER_IP> <CLIENT_IP> HTTP 1391 [TCP Spurious Retransmission] HTTP/1.1 200 OK [Unreassembled Packet [incorrect TCP checksum]]<frame.number> <frame.time_relative> <CLIENT_IP> <SERVER_IP> TCP 60 [TCP Dup ACK 280#1] 23433 → 80 [ACK] Seq=890 Ack=4037 Win=8047 Len=0注：イーサネットトレーラーがゼロ以外の場合、「fefefefefefe」などの実際のeth.trailer値が表示されます。
この例では、サーバーによって無視された行のみeth.trailerが表示されています。
イーサネットトレーラーがゼロの場合、コマンド出力は空になります。
Environment
NSX 4.2.1.1
ESX 8.0 U3
Cause
この問題は、特定のNICハードウェア/ファームウェアと、ESXがGeneveカプセル化パケットを処理する方法との間の競合によって発生します。
パケットにゼロ以外のイーサネットトレーラーが含まれている場合、ハードウェアベースのチェックサムオフロード（CSO）は、Geneveトンネルの内部パケットの正しいTCPチェックサムを計算できない可能性があります。受信側は誤ったチェックサムを識別してACKを無視するため、送信側はパケットが失われたと誤認し、誤った再送信が発生します。
この例では:
- クライアントが60バイト未満のイーサネットフレームを送信する。
- ルーターは、60バイトに合うようにゼロではないパディングを追加する。
- NSX Edgeは、イーサネットトレーラーにゼロではないパディングを含むイーサネットフレームをブリッジする。
- vmnic が Geneve パケットの内部 TCP チェックサムを破損します。
Resolution
ESX でこの問題を解決するには、影響を受ける物理アダプタ (vmnic) のハードウェア オフロードに頼るのではなく、ソフトウェアを介して IPv4 チェックサム計算を実行するように ESX ホストを構成します。
- SSH経由で、影響を受けるNSX EdgeノードまたはVMが実行されているESXホストにログインします。
- 物理 NIC のソフトウェア チェックサム オフロードの状態を確認します。
esxcli network nic software list
IPv4 CSO が off の場合、ソフトウェア ベースの IPv4 チェックサム オフロードは無効になります。
出力例:
NIC IPv4 CSO IPv4 TSO Scatter Gather Offset Based Offload VXLAN Encap Geneve Offload IPv6 TSO IPv6 TSO Ext IPv6 CSO IPv6 CSO Ext High DMA Scatter Gather MP VLAN Tagging VLAN Untagging
------ -------- -------- -------------- -------------------- ----------- -------------- -------- ------------ -------- ------------ -------- ----------------- ------------ --------------
vmnic0 off off off off off off off off off off off off on on
vmnic1 off off off off off off off off off off off off on on - Geneveトラフィックの送信に使用される特定のvmnicに対して、ソフトウェアベースのIPv4チェックサムオフロードを有効にします。
esxcli network nic software set --ipv4cso=1 -n vmnicX
注：vmnicXをGeneveパケットを送信する実際のvmnicに置き換えてください。
IPv4 CSOステータスを確認するには、次のコマンドを実行します。 - リスト コマンドを再度実行して変更を確認します。変更された NIC の IPv4 CSO 列に「on」と表示されるはずです。
esxcli network nic software list
IPv4 CSO が on になり、ソフトウェアベースの IPv4 チェックサム オフロードが有効になります。
出力例:
NIC IPv4 CSO IPv4 TSO Scatter Gather Offset Based Offload VXLAN Encap Geneve Offload IPv6 TSO IPv6 TSO Ext IPv6 CSO IPv6 CSO Ext High DMA Scatter Gather MP VLAN Tagging VLAN Untagging
------ -------- -------- -------------- -------------------- ----------- -------------- -------- ------------ -------- ------------ -------- ----------------- ------------ --------------
vmnic0 off off off off off off off off off off off off on on
vmnic1 on off off off off off off off off off off off on on
この例では、vmnic1 でソフトウェアベースの IPv4 チェックサム オフロードが有効になっています。
Additional Information
Feedback
