2008 R2 Server cannot ping itself

Dell servers have something called DRAC that tends to use the same IP Address as Windows and cause a few issue like this, another possibility would be a recent windows update, or someone or something has made a change to the window firewall that is blocking all pings for that server.

Do you have Windows Firewall turned on?

can you ping other adresses ? if yes, forget the following

try these in whatever order seems suitable to you (i suggest in the following order)
- destroy the NIC in windows components, reboot, and let windows reinstall it and reassing a new id
- remove tcp from the NIC and add it again (through the connection's properties dialog, uncheck tcp/ip, click ok, and do the reverse)
- use this command as admin "netsh int ip reset c:\resetlog.txt" it should reset the tcp network stack

can you do arp queries ? use the "arp -a" command to see all arps known to your system

as a side note, pinging your own ip should be only using the loopback and not the nic. not really sure in windows, though. this means it could also be a firewall issue. can you deactivate the windows firewall and recheck ? maybe the "local" interface is limited to 127.0.0.0/8 and you cannot use it to reach other adresses

If your firewall is on, check and try this:

Removed both NIC cards on the 2950, did a shutdown on the box , On Reboot disabled all Firewall Features. Looked at the Arp Entries and non are found.  One thing that is sort of strange is it keeps coming up with an IP Address Conflict, but we do not see any conflicts.

Disable DRAC in BIOS

Is DRAC something that is actually a BIOS Setting?  If so Where is at on the Bios, I did not see it.

Can be different system to system:

While at the terminal...
Restart the system
Press Ctrl-D after "Dell Embedded Remote Access Controller" is displayed
Press "E" to enable/disable RAC
Press "R" to reset the Interface
Press "Y" to save

if DRAC were to be the issue, it would definitely be a problem when pinging to/from remote machines, but not likely localhost. i can believe that windows handle local adresses through the network card (and that is not weird compared to the use of the loopback stack) but sending arp queries to the wild for local addresses seems absolutely crazy

as far as i remember, (and that is not much), you can access drac config by pressing a couple of keys after the post screen and before the network boot prompt. you also should have access through the OS (not sure in the case of DRAC) and obviously by accessing the DRAC interface itself from a remote machine.

For all who helped on this I appreciate very much the notes.  Here is the resolution on this machine.  The Symantec Enpoint Protection client was loaded the day before, then the server rebooted.  Evidentially somewhere during the load or the reboot the Winsock and Winsock2, network config and other registry entries were corrupted.  To get this machine backup, the sysmantec enpoint protection software was removed, The Winsock, Winsock2 registry entries were copied from a duplicate machine and imported to this machine as well as other registry entries for the network. Then reloading the symantec client, reseting all of the network elements again using netsh int ip reset, allowed the Network to come back.  Was a bit of a weird scenario, again thanks to everyone that helped on this.

so symantec probably assumed that the interface ip should not be allowed when using loopback or something similar. so-called security.

thanks for the insight

as a side note, i'd strongly urge all admins to move quickly away from software that takes decision without your knowlege, without documentation, and without a good reason... i believe symantec would hate me here and possibly other posters, but the best way to prevent such problems is basically not to use such software (which definitely includes all of symantec's security suite).

reloading the reigistry items probably would not work anyway if this is caused by symantec.

i guess symantec users feel safer now that they know you can bypass security by disabling the NIC for a few seconds... not sure this solution could be assumed to be workable in a production environment as symantec may notice it has been bypassed at some point...

i believe your true answer should be somewhere in symantec's gui. most likely something like an anti-spoof or back-routing feature.

I ran this on 2 other Windows 2008 R2 machines with the same symptoms. I opened a ticket with MS and  after disableing the NIC on both, then re-enabling the NIC both machines they proceeded to funciton normally.  Could find no other solution for this problem other than disable/enable, Microsoft Engineer agreed this was a fix for this problem.