Disclaimer: All postings are provided "AS IS" with no warranties, and confer no rights. This weblog does not represent the thoughts, intentions, plans or strategies of Microsoft. Because a weblog is intended to provide a semi-permanent point-in-time snapshot, you should not consider out of date posts to reflect current thoughts and opinions.
KB 936594 http://support.microsoft.com/kb/936594 and KB 912222 http://support.microsoft.com/kb/912222 both do a great job addressing some of the issues encountered where Service Pack 2 (and the Scalable Networking Pack by default) is installed on some machines in given scenarios. Recently I've found one command that has been very helpful in troubleshooting issues arising from the Scalable Networking Pack being applied that is not documented in either KB. It's allowed me more than once to nail down and resolve the issue quicker than had I not utilized it.
The Scalable Networking Pack allows organizations to take advantage of the ability of newer network cards to speed up the IP stack on servers by offloading some TCPIP processing from the servers CPU to the network card; as well as allowing multi-proc servers to bring more processing power to bear through Receive Side Scaling. Some issues have been seen however in specific configuration scenario's involving an ISA 2004 server that's not fully patched (see KB 930414) or incompatible network cards or outdated drivers.
"Netstat -T" is a command that you can utilize once the Scalable Networking Pack is installed to provide a status of the offloading state of connections on the server in question. So for example... you think you may be experiencing one of the issues that have been seen related to the implementation of the Scalable Networking Pack like:
You cannot RDP to the server
You cannot connect to shares on the server from another machine on the LAN
You can't connect to Exchange with Outlook etc...
Run "Netstat -T" locally on the affected server and examine the output. It will look something like this...
Active Connections
Proto Local Address Foreign Address State Offload State
TCP Server:ldap Server.domain.com:1047 ESTABLISHED InHost
NOTE: The "Offload State" shows to be InHost meaning the server is still handling the load itself. So check this one out...
TCP Server:netbios-ssn Server.domain.com:2151 ESTABLISHED Offloaded
The fact that the affected server(s) show a different "Offload State" in and of itself is obviously not a sure sign that the issue is related to Scalable Networking with SP2. It does however show one server clearly offloading and another (unaffected) server still performing the same functions (InHost)via the CPU.
From this point its simple to utilize Netsh int ip set chimney DISABLED to temporarily turn off TCP Chimney Offload. This command is great because it doesn't require a reboot. KB 912222 details this command http://support.microsoft.com/kb/912222 . Put together KB 912222 and 936594 do a great job detailing the various issues and scenario's likely to be seen when the implementation of the Scalable Networking Pack is an issue. Utilizing the "Netstat -T" command should help you nail down whether or not a potentially affected machine is offloading or not. In my experience turning off TCP Chimney Offload has resolved the problem each time. Happy hunting!
I've become quick to consider disabling the TCP off-loading engine features (or “TOE”) when trouble-shooting
If you would like to receive an email when updates are made to this post, please register here
Subscribe to this post's comments using RSS