# [Solved] "Address already taken on eth0" and others

## Natureshadow

Hello there,

after installing a new Gentoo box on an AMD 64 (x86_64) stage 3, I got some strange errors concerning networking.

First I should say that everything was fine before the whole /etc directory was filled with wrong config fles by a corrupted backup/restore script. Anyway, we got that fixed, and everting was working, including Samba, SSHd, etc. .

Now, after a reboot (the work before was done remotely), all the daemons suddenly failed to start, saying that net.eth0 was not started. A closer look at that brought up that the interfaces eth0 and eth1 did not exist - although the modules were loaded. Investigation with dmesg showed that udev was renaming the interfaces to eth2 and eth3 right after module loading.

To fix this issue quickly, I unmerged udev, emptied the coniguration directories and re-emerged udev, making the interfaces come up with the normal names afterwards.

But net.eth0 still fails saying

```
* Address 192.168.x.x already taken on eth0
```

which can't be quite accurate. The server should be doing some APIPA querying, there can't be any host on the network using the address (in fact, I disconnected the interface from the switch).

eth1 came up as normal, but still leaving me unable to ping any of the hosts or the gateway on the DMZ.

Thinking the issue could come from the firewall (Shorewall) not starting with the eth0 interface down, I flushed iptables with

```
iptables -F
```

, but still no luck.

Does anyone have any ideas concerning this issue?

Best regards,

NikLast edited by Natureshadow on Tue Jan 22, 2008 9:39 am; edited 1 time in total

----------

## Natureshadow

OK, that's solved. I will leave the topic here because the solution might be interesting for some admin having the same problem.

Basically, it was a stupid problem. We were copying all the stuff from the old hardware to the new, having both servers connected on the DMZ net (eth1). The internal network, eth0, was not connected on the old server, because the new server was already taking over all the services.

We cared about the DMZ interfaces not sharing the same IP address, but we didn't spare a glance at the internal adapters. For some reason now, the interfaces on the new server got created in the wrong order. We didn't notice that because they are the same hardware, leaving us with two interfaces with the same model name.

So now, we had the internal adapter connected to the DMZ network, trying to reserve the internal IP address. With the old serving routing all traffic from the DMZ interface coming inwards during the maintenance, the packets from the internal interface of the new server got routed to the internal interface of the old server, giving us the address conflict.

Now, after swapping the interfaces both in the firewall and the net configuration, everything is fine. Hopefully the interfaces will stay in that order now ...

-nik

----------

