I'm trying to get 2 ethernet adapters to work. The first one, eth0, works out of the box. The second one, eth1, acts weird. This port uses the LAN9512. This is my /etc/network/interfaces file:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        hwaddress ether 40:D8:55:1D:D0:B1

auto eth1
iface eth1 inet static
        hwaddress ether 40:D8:55:1D:D0:B2

This are the relevant pieces of the bootlog when I boot the hardware with cables plugged in both ethernet adapters:

macb f802c000.ethernet (unnamed net_device) (uninitialized): invalid hw address, using random
libphy: MACB_mii_bus: probed
macb f802c000.ethernet eth0: Cadence MACB rev 0x0001010c at 0xf802c000 irq 35 (42:8a:61:6e:a2:bb)
macb f802c000.ethernet eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=f802c000.etherne:01, irq=-1)
usbcore: registered new interface driver smsc95xx
usb 1-1: New USB device found, idVendor=0424, idProduct=9512
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 3 ports detected
usb 1-1.1: new high-speed USB device number 3 using atmel-ehci
usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.1: Product: LAN9512
usb 1-1.1: Manufacturer: SMSC
usb 1-1.1: SerialNumber: 00951370
smsc95xx v1.0.4
smsc95xx 1-1.1:1.0 eth1: register 'smsc95xx' at usb-700000.ehci-1.1, smsc95xx USB 2.0 Ethernet, 00:80:0f:95:13:70
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
smsc95xx 1-1.1:1.0 eth1: hardware isn't capable of remote wakeup
IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
macb f802c000.ethernet eth0: link up (100/Full)
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Starting sshd: IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
smsc95xx 1-1.1:1.0 eth1: link up, 100Mbps, full-duplex, lpa 0x45E1

ifconfig returns expected output:

eth0      Link encap:Ethernet  HWaddr 40:D8:55:1D:D0:B1  
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::42d8:55ff:fe1d:d0b1/64 Scope:Link
          RX packets:1795 errors:0 dropped:2 overruns:0 frame:0
          TX packets:1671 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:108141 (105.6 KiB)  TX bytes:115881 (113.1 KiB)
          Interrupt:35 Base address:0xc000 

eth1      Link encap:Ethernet  HWaddr 40:D8:55:1D:D0:B2  
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::42d8:55ff:fe1d:d0b2/64 Scope:Link
          RX packets:1352 errors:0 dropped:2 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:70740 (69.0 KiB)  TX bytes:762 (762.0 B)

Now my problem. Pinging from a different host to both IPs works fine. But when I've only plugged a cable in to eth0 I still can ping both IPs. Whereas I expected to be able to ping only When I've only plugged in a cable in eth1 I can't ping none of both IPs, now I expected to be able to ping

What is going on? And how can I fix this?


As asked:

$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface   U         0 0          0 eth0   U         0 0          0 eth1
  • can you edit you post with the result of netstat -rn ?
    – Archemar
    Sep 11, 2015 at 11:42
  • Use an alias on eth0, I think it also works in /etc/network/interfaces. It also works with ifconfig eth0:0 netmask
    – ott--
    Sep 11, 2015 at 12:25

1 Answer 1


There is a Linux-feature which makes your machine reply for every IP address assigned, on every interface, when they share the same IP subnet, regardless of the particular IP-interface assignments. This may or may not be desirable for you.

This feature is switched on by default, and you can configure it through sysctl.

For the output traffic, your machine works like this: for every interface configured as UP, a route entry will be inserted into the routing table, regardless of whether there is link or not, and regardless of whether any other nodes are reachable through that interface or not. Since you have two interfaces for the same IP subnet, you'll have two identical routes in the routing table. The OS will only use one of them, and you have no control over which one will be used! Also, which one will get used is independent from the incoming address of the packet in reply to which the output packet will be sent. This means, that failover in general does not work as you'd expect.

arp_filter - BOOLEAN

1 - Allows you to have multiple network interfaces on the same subnet, and have the ARPs for each interface be answered based on whether or not the kernel would route a packet from the ARP'd IP out that interface (therefore you must use source based routing for this to work). In other words it allows control of which cards (usually 1) will respond to an arp request.

0 - (default) The kernel can respond to arp requests with addresses from other interfaces. This may seem wrong but it usually makes sense, because it increases the chance of successful communication. IP addresses are owned by the complete host on Linux, not by particular interfaces. Only for more complex setups like load-balancing, does this behaviour cause problems.

arp_filter for the interface will be enabled if at least one of conf/{all,interface}/arp_filter is set to TRUE, it will be disabled otherwise

arp_announce - INTEGER

Define different restriction levels for announcing the local source IP address from IP packets in ARP requests sent on interface:

0 - (default) Use any local address, configured on any interface

1 - Try to avoid local addresses that are not in the target's subnet for this interface. This mode is useful when target hosts reachable via this interface require the source IP address in ARP requests to be part of their logical network configured on the receiving interface. When we generate the request we will check all our subnets that include the target IP and will preserve the source address if it is from such subnet. If there is no such subnet we select source address according to the rules for level 2.

2 - Always use the best local address for this target. In this mode we ignore the source address in the IP packet and try to select local address that we prefer for talks with the target host. Such local address is selected by looking for primary IP addresses on all our subnets on the outgoing interface that include the target IP address. If no suitable local address is found we select the first local address we have on the outgoing interface or on all other interfaces, with the hope we will receive reply for our request and even sometimes no matter the source IP address we announce.

The max value from conf/{all,interface}/arp_announce is used. Increasing the restriction level gives more chance for receiving answer from the resolved target while decreasing the level announces more valid sender's information.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .