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
address 10.0.0.195
netmask 255.255.255.0
hwaddress ether 40:D8:55:1D:D0:B1
auto eth1
iface eth1 inet static
address 10.0.0.196
netmask 255.255.255.0
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:10.0.0.195 Bcast:0.0.0.0 Mask:255.255.255.0
inet6 addr: fe80::42d8:55ff:fe1d:d0b1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
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:10.0.0.196 Bcast:0.0.0.0 Mask:255.255.255.0
inet6 addr: fe80::42d8:55ff:fe1d:d0b2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
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 10.0.0.195. 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 10.0.0.196.
What is going on? And how can I fix this?
EDIT
As asked:
$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
Best Answer
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.