In looking at the few changes that had taken place nothing that happened should have caused this. It kind of made sense to me, especially since I was seeing ARP being filtered somewhere between the server and the network switch port on Wireshark traces, but what did not make sense was why this would happen seemingly out of nowhere. It could also cause cluster failover issues and Microsoft eventually released a hotfix in 2011. Unfortunately because people expected the behavior to be the same as it was in prior versions of Windows this caused problems for many people. Specifically right around the time Vista and Windows 2008 were released, and more specifically because of a change in the default OS behavior in regards to gratuitous ARP requests, to protect the OS from poisoning the ARP cache. Well this issue was confusing for a couple of weeks but I think I finally found the solution.įirst off searching online found no shortage of people having similar problems going back to about Windows 2008-2009. We also pro-actively picked a few key servers to do this for as well. The fix, though not an acceptable permanent solution, was to add static ARP entries on the affected servers and on the firewall. Needless to say having this happen seemingly at random on a production network is bad news, and of course this usually happens in the middle of the night causing people to be paged/called and woken up.
#Hp nc36t windows 7 x64 drivers 64 Bit
The servers affected were all running Windows 2008, either 32 bit Std SP2 or 64 bit R2.In looking at the problem the pieces of information that stood out (at first, more later) were: Specifically VMs would not communicate to other servers on the same subnet, other servers on the same subnet could not communicate with them, and in some cases servers across subnets could not communicate across routed connections. A few weeks ago a weird network issue began popping up on random VMs on our network.
0 kommentar(er)
