If you are running VMWare ESXi, after you make certain configuration changes that doesn’t have anything to do with ip-address change, you might get the following error message during the system startup.
“Bringing up interface eth0: Error, Some other host already uses address 192.168.101.10 [FAILED]”
As you can imagine, this will not start the network, and you cannot connect to the host node that is running on the VMWare ESXi.
Most of the time, this particular issue happens on ESXi host that is running Linux distros. In this particular example, I had this issue on CentOS 6 host.
In this quick article, we’ll explain how to fix this issue.
Change the ip-address to verify the problem
In my case, for this particular VM host, I increased the RAM from 2GB to 4GB and restarted the VM, which gave that error message.
In this case, eventhough nothing in the network setting including the ip-address was changed, just to eliminate the above error message, I changed the ip-address of the machine to something different. (i.e from 192.168.101.10 to 192.168.101.20).
# cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 BOOTPROTO=static ONBOOT=yes HWADDR=ab:60:61:bc:cf:d5 IPADDR=192.168.101.20 NETMASK=255.255.255.0
After changing the ip-address, now I’ve started getting the “RTNETLINK answers: File exists” error message during the host restart:
RTNETLINK answers: File exists
Since the change in ip created this new error, I went and changed the ip-address of the VM host back to its original ip (i.e to 192.168.101.10), and when I restarted the host VM, I again got the original error message, which is the following:
# cat /etc/sysconfig/network-scripts/ifcfg-eth0 .. IPADDR=192.168.101.10 ..
The following error came again after reverting back to original ip-address:
Bringing up interface eth0: Error, Some other host already uses address 192.168.101.10 [FAILED]
In your case, if you can afford to change the ip-address of the VMware host, and if you are not receiving the above “RTNETLINK answers: File exists” error message on the new ip, then you can just change the ip-address and leave it there. Or, you can revert back to the old ip-address, and continue to the next step.
Check arping response
At this stage, I kind of realized that this has something to do with ARP address caching, or proxy ARP, or something else related to ARP in the VM host.
From a different server, I sent an ARP ping to this failed ip to see what happens.
# arping -c 2 -w 3 -D -I eth0 192.168.101.10 ARPING 192.168.101.10 from 0.0.0.0 eth0 Sent 4 probes (4 broadcast(s)) Received 0 response(s)
As you see from the above output, it didn’t receive any ARP response for that ip-address.
Now, I logged into the console of the VM host that was giving the error message, and tried the arpping command there and got the following response.
ARPING 192.168.101.10 from 0.0.0.0 eth0 Unicast reply from 192.168.101.10 [50:3D:E5:1E:A9:1B] 0.743ms Sent 1 probes (1 broadcast(s)) Received 1 response(s)
Temporary Solution to the Problem
I went looking for the script that is throwing the “Error, Some other host already uses address” message.
In this example, the ifup-eth script, located under /etc/sysconfig/network-scripts/ directory is getting called during startup to start the network interface is throwing our error message.
The following is the code-snippet from the ifup-eth file that is throwing out our error message:
# cat /etc/sysconfig/network-scripts/ifup-eth if ! arping -q -c 2 -w 3 -D -I ${REALDEVICE} ${IPADDR} ; then echo $"Error, some other host already uses address ${IPADDR}." exit 1 fi
In my case, I know for sure this particular issue has nothing to do with ip-address conflict, because I never used the 192.168.101.10 on our network anywhere else.
So, on this particular host VM as a temporary work-around, I went and ignored this error message and moved on.
For this, I commented-out the “exit 1” in the following block as shown below.
# cat /etc/sysconfig/network-scripts/ifup-eth if ! arping -q -c 2 -w 3 -D -I ${REALDEVICE} ${IPADDR} ; then echo $"Error, some other host already uses address ${IPADDR}." #exit 1 fi
So, in this case, during system startup, it showed that error message, and continued to start the network without any other errors.
After this, I was able to connect to the host using that ip-address without any issues.
In my case, after few days, I noticed that on the console, I didn’t get that error message anymore. So, I went and un-commented it after a week or so.
Sometimes this might happen when you are on a particular VLAN. If you try to change your VLAN, this error might go-away, but when you come back to your original VLAN, you’ll see this error message again.
Also, note that in your case, you may also get this issue if you are doing some kind of NIC bonding, or NIC aggregation, NIC teaming, etc, or some other 3rd party software that does some networking HA management on your system.
But, now at least you can try to do the above temporary work-around and see if it helps.