if large send offload (ipv4) setting is enabled on the server (default nic setting) and disabled on the client (default nic setting) what problems can arise from a mismatched LSO setting if any? is there any indication in WS trace that large send offload (ipv4) is enabled/disabled on the NIC? Thanks asked 27 Oct '10, 10:25  net_tech retagged 07 Jan '11, 02:51  martyvis |
2 Answers:
LSO is an internal process - when the packets go out on the wire, they are not larger than a normal packet. Just like TCP Segmentation Offload and Large Receive Offload, this feature is designed to improve performance by using the brains of the adapter for certain tasks. See http://www.chappellseminars.com/10blog0907.html (and the image of a LSO capture) for the effect of LSO on Wireshark. In essence, if Wireshark is running on the sending machine that supports LSO, Wireshark will see unusually high frame length values when LSO is in use. I don't image mismatched LSO settings should cause a problem because again, on the wire the packets are normal size. answered 27 Oct '10, 12:12  lchappell ♦ |
I am troubleshooting an RDP issue ("Because of an error in data encryption, this session will end. Please try connecting to the remote computer again) and came across a long thread on MS forum, where the problem seem to be related to LSO setting of the NIC. I thought miss-matched LSO setting (server – client) had something to do with it, but apparently not. answered 27 Oct '10, 12:39 net_tech edited 27 Oct '10, 12:41 |
As Laura said, "LSO is an internal process - when the packets go out on the wire, they are not larger than a normal packet." LSO, like TSO and LRO, just hands some of the job of processing packets from the host's TCP/IP stack to the adapter's TCP/IP stack; it doesn't affect what's on the wire, unlike, for example, Ethernet full and half duplex, so there's no need for the settings on the machines to match.
This is almost identical to my problem, the only difference is my Windows 2008 is on VMWare server.
http://www.petri.co.il/network-issues-with-windows-server-2008-rdp-on-dell-servers.htm
What I am getting out of this is that everything that makes logical sense and works on the physical network DOES NOT, when virtualization is involved.