Gigabit technology is hitting the mainstream of IT in full force. More and more manufacturers are shipping server, SANS, and desktop/client hardware with gigabit NIC technology. This new technology is exciting and wonderful; however, it does include its own unique issues when working in a DOS environment.
DOS was created in 1986, and uses a network stack and drivers that have changed little since its introduction. Many manufacturers have either stopped creating DOS drivers or have not performed rigorous testing to verify that the DOS drivers work under heavy load.
Altiris RapiDeploy and Deployment Solution use for the DOS NDIS version 2.0 drivers and the associated Microsoft MS-DOS TCP/IP network stack for imaging as well as the PXE boot environment.
The purpose of this whitepaper by Altiris Technical Support is to help inform you, our client base, as to possible issues that may arise due to this new environment as well as possible solutions
Errors related to this solution:
Deployment Solution 5.6, 6.0, 6.1, 6.5, 6.8, 6.9
TCP/IP CheckSum offloading is enabled by default on most Gigabit NICs.
Disable the TCP Offload Checksum on Gigabit NICs.
This is done by performing the following steps on the server that the image is being saved to:
What does Checksum Offloading do?
Checksum offloading eliminates host-side checksumming overheads by performing checksum computation with hardware assist in the NIC. TCP/IP checksum offloading is supported by a variety of NICs. Primarily high-speed network interfaces including Gigabit Ethernet NICs.
Some 10/100 NICs (Intel Pro100) also have checksum offloading features.
The NIC and the host-side driver must act in concert to implement checksum offloading. Using hardware checksumming for IP protocol family is complicated by three factors:
Movement of each packet may occur in multiple DMA transfers to or from distinct host memory buffers. If the hardware makes each partial checksum available to the NIC firmware separately, then firmware and/or host software must combine these partial checksums (using one's complement addition) to obtain a complete checksum.
TCP or UDP checksumming actually involves two checksums: one for the IP header (including fields overlapping with the TCP or UDP header) and a second end-to-end checksum covering the TCP or UDP header and packet data. In a conventional system, TCP or UDP computes its end-to-end checksum before IP fills in its overlapping IP header fields (e.g., options) on the sender, and after the IP layer restores these fields on the receiver. Checksum offloading involves computing these checksums below the IP stack; thus the driver or NIC firmware must partially dismantle the IP header in order to compute a correct checksum.
Since the checksums are stored in the headers at the front of each IP packet, a sender must complete the checksum before it can transmit the packet headers on the link. If the checksums are computed by the host-NIC DMA engine, then the last byte of the packet must arrive on the NIC before the firmware can determine the complete checksum.
Because of these complications it may be preferable to simply disable TCP checksum offloading and allow the host to perform the checksumming. Generally, if disabling the TCP checksum offloading solves data corruption issues this indicates that the NIC isn't properly performing the checksumming.
From a performance perspective, disabling checksum offloading should have minimal impact on the host computer. There will be some additional load on the computer but it should be negligible in most environments. In theory it should have zero effect on the actual data being sent/received on the wire.