Server 2008 R2 NIC in “Unidentified Network” state after connectivity loss is restored

broadcomipv6network-teamingnetworkingwindows-server-2008-r2

I am having trouble with 2 servers, both with the same symptoms. When they are reconnected to the switch after losing connectivity, they stay in an "unidentified network" state. Only after cycling the selection of ipv6 in the NIC or rebooting does it then recognize the domain again and allow connection between the servers.

My temporary fix involved accessing the server via RDP, accessing the NIC settings, and either enabling or disabling IPv6. It doesn't matter if the NIC has IPv6 enabled or disabled – the problem occurs whichever way. I guess changing the IPv6 settings is more of just resetting the NIC than anything. Rebooting also gets the servers back up though takes longer than the IPv6 trick.

Right now all the servers are connected to the same switch, though we're having a problem with it where it still loses power during a generator test despite being connected to a UPS. This is a completely separate issue, but I just want to let you know WHY the servers lose network connectivity.

There are close to 10 servers and only these 2 servers seem to have the problem. They are a database and an app server that talk to eachother. They were both purchased and put in place at the same time. They both have Broadcom NIC teaming enabled, however only have a single cable connected to each leading to the switch. The same problem occured with 4 NIC's connected on each server.

While the NIC's are in an unidentified state, they are unable to ping other servers, I'm guessing because the state puts them in a firewall class that doesn't allow communication to other domain server, because it remains connected to the internet and can be accessed remotely.

The configured DNS server IP's are the same on each: 192.168.X.6, 192.168.X.9 – both internal ADDS servers.

Any idea why this is happening? Hopefully this is enough detail for you. Please let me know if you have any questions.

Best Answer

Well I just realized how old this is... anyways for others out there, might try setting ArpRetryCount to 0. Sometimes the NLA service won't detect a new connection because of some proxy ARP nonsense where the switch isn't passing the correct addresses for a few moments.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
DWORD
ArpRetryCount
0

Also, if you see it happen might try just restarting the NLA service instead of forcing a nic disconnect.