I was able to resolve this by setting ipv4 as the preferred protocol for the machine by editing the prefix policy using netsh in a command window. Apparently the ipv6 loopback network adapter is always active even if ipv6 is disabled for external LAN traffic.
#Unable to ping loopback address windows 10
I also had a similar issue on Windows 10 even after my hosts file was correctly set with the ipv4 address, except that in this case it was resolving to the ipv6 loopback address ::1 even though I had disabled ipv6. hosts file changes should take effect immediately. If it does not, hosts is not being processed. If the IP is made up, you won't get a reply, but you should still be able to see that the name is resolving to whatever IP you put in the hosts file. (some other made up IP address on the network) (made up hostname)Īnd then ping hostname2. One simple test to see if it is being ignored is to add another entry of the form: 192.168.0.XX hostname2 See for more troubleshooting about this issue.
Windows can ignore it if formatting, file permissions, whitespace, etc. If you already added that and are still getting the ipv4 loopback after ping hostname, you should check that windows is not ignoring your hosts file. Where XX is the actual reserved IP ending for that machine on my LAN, and hostname is the hostname of the machine in question. This was fixed on Linux machines and windows 7 by adding a line to the hosts file on each machine that was of the form 192.168.0.XX hostname, I initially had the problem that hostnames, when ping-ed from the same machine, would resolve to the ipv4 loopback address 127.0.0.1. My cluster is a mix of Linux (Ubuntu 18.04), Windows 7, and Windows 10 Pro. I was having the same problem and was able to resolve it.
0 kommentar(er)
