Snow Leopard Software Update VERY slow

Question

I'm running snow leopard 10.6.8 server and am having some very strange problems with my software updates.
I have all the settings set right (I believe) and I have made the adjustments to allow Lion clients to upgrade from it as well.
The problem I'm having is that when a client running either 10.6 or 10.7 is in the "checking for updates" portion of the update process it takes a very VERY long time to get the the next screen. The clients running 10.6 will show the bar going across at a snails pace for about 10-15 minutes then give the updates report showing my correct updates server at the top of the window.
The clients running 10.7 show the blue bar only going about 1/8-1/3 of the way in, then it stops, and sits there literally for hours before completing the check, then giving me the status and it also does show my correct update server.
I am connected through 1GB Ethernet from my clients to the server so that's not an issues and the speed is good when doing a file transfer. I can transfer 3GB to the server in less than 40 seconds, and pull that same 3GB back to the client in about 30 seconds. I can see and ping the update server. I can access the Xserve web site on my server... and the weird thing is it didn't always do this, it's only been the last month or so.
I have thought it might be a bad or corrupt OS so I reinstalled the OS and all services.
The clients are not managed by Microsoft AD & GP not by the apple servers.
As I said this used to be so much faster then using the apple servers in our organization, but now it's grossly slower then going out to the apple site.
Any help is appreciated.
Thank you, Mike

Answer 1

Asking for the server by IP does mean you're avoiding a DNS lookup.
It doesn't mean that the target OS X Server box won't avoid errors due to a DNS server or network error, nor that any parallel connections that might be initiated at the client or at the server won't encounter DNS errors or network errors; whatever is going on here, and whatever is triggered by the initial IP-based access.
One of the DNS translations that can arise - even when the client is specifying an IP address - is on the remote end of the connection, when that system performs what is called a reverse look-up; translating the client IP address to the client IP name.  If there's a reverse translation arising and and if there's a DNS error or DNS timeout or a network error, then things will (still) be slow, even if the initial access was via IP.
If you're running a NAT'd private network, that means local DNS services are necessary and (at least to start with) no references to DNS servers off your NAT'd LAN.
If DNS services aren't quite right, the rest of the network stack gets flaky, and DNS errors look like delays, sluggist networks, and network errors. 
There are most certainly other triggers for network slowness ranging from moisture in cables to WiFi interference to a truck that drove through the path of the WISP link, but DNS services are always a good potential culprit until proven otherwise.
Valid DNS services have become much like IP routing; a fundamental part of a modern IP network.  This particularly as distributed security, certificate-based encryption, user authentication and access delegation become more and more important within the network environment.