-3

I have debian 8 with two network cards, eth0 and eth1.

eth0 is 192.168.3.43 and eth1 is 192.168.3.44.

Both are configured by dhcp:

auto eth0
iface eth0 inet dhcp

auto eth1
iface eth1 inet dhcp

Here's the routing table:

Destination     Gateway         Genmask         Flags Metric Ref        Use   Iface

0.0.0.0         192.168.3.1     0.0.0.0         UG    0      0        0 eth0
192.168.3.0     0.0.0.0         255.255.255.128 U     0      0        0 eth0
192.168.3.0     0.0.0.0         255.255.255.128 U     0      0        0 eth1

The problem is that if i remove the cable from eth0, i can't ping eth1 even from a machine in the same 192.168.3.x segment.

I would have understood if one of them was in a different segment, since the routing table shows the default gateway lies on eth0, but not when this is happening on the same segment my main machine is.

what do i need to make both cards work independent of each other?

Thiago Rider Augusto
  • 695
  • 1
  • 8
  • 18
fjleon
  • 195
  • 1
  • 8
  • 2
    Why are you doing this? – MadHatter Sep 15 '16 at 21:01
  • What do things look like on that machine when the cable is pulled? Have you done any testing/checking/anything to try and figure out what's going on? – Ryan Babchishin Sep 15 '16 at 21:21
  • @MadHatter i just don't want to depend on a single interface to reach the box. In reality those two interfaces will be on separate networks, but if eth0 goes down i need to be able to reach it through eth1. It's my first experience with two network cards on the same computer – fjleon Sep 16 '16 at 03:15
  • @RyanBabchishin as i said if i ping both interfaces from another computer, ping goes down for both of them even if i just remove the cable from eth0. Originally my test was on different subnets, but since linux only allows one default route per machine, i thought that having both interfaces on the same subnet would have "fixed" this. That's why i am trying to understand what's happening – fjleon Sep 16 '16 at 03:17
  • @fjleon You'll never figure out anything that way... your issue is on the server, not on whatever device is pinging it. It's like trying to figure out what's wrong with Apache by hitting it with a web browser. Anyways, perhaps looking at your arp/routing tables will tell you something? – Ryan Babchishin Sep 16 '16 at 13:48

3 Answers3

6

You are going about this the wrong way. What you want to do is to channel-bond the two interfaces into a single virtual interface, bond0, and give all your IP addresses to bond0. If the bonding is configured in the simplest mode, active-backup, no special configuration of the switch is required; one of the two physical interfaces will be used for all traffic unless and until link goes away, at which time the kernel will switch to using the other interface. If I understand you correctly, this is what you want.

With a more intelligent switch that you have properly configured, you can configure more complex modes to the bonding, which have the effect of using both NICs, and sharing traffic between them according to various algorithms.

If you need the system to have addresses on several different subnets, you should use VLANning on top of bond0; again, the connivance of the switch will be required.

There are many guides out there to configuring channel bonding on debian; the Debian wiki also has a page on the subject.

MadHatter
  • 79,770
  • 20
  • 184
  • 232
  • i'm actually not using stock debian, rather proxmox which is based on debian and by default creates a bridge interface for each physical interface it finds. i'm rather amazed that linux by default relies on eth0 and can't receive packets on eth1 even if everything is on the same subset, however i will see if i can implement bonding or whatever equivalent proxmox uses to solve my problem. thanks – fjleon Sep 16 '16 at 12:24
  • In fairness, you don't know that it can't receive packets on eth1. All you know is that you don't hear any responses, which is by no means the same thing. See Jeremy's comments about routing, which I suspect are valid despite your objections, in order to understand why this might be. – MadHatter Sep 16 '16 at 12:25
  • round-robin bonding doesn't need a special switch (or any switch) and provides redundancy + combines traffic for increased throughput. – Ryan Babchishin Sep 16 '16 at 17:40
  • @RyanBabchishin I agree that some people say that, but [others say otherwise](https://www.ibm.com/support/knowledgecenter/STAV45/com.ibm.sonas.doc/mng_t_pub_netw_bondingmodes2_4.html): "*For Round-robin policy [...] the switch ports to which the bond is connected should be grouped together into a channel group using a method that is compatible with static link aggregation*". I don't have at hand the equipment to test this, so thought I'd play it safe with my advice: active-backup *definitely* doesn't require custom switch config. Readers should note that other modes *may* not require it. – MadHatter Sep 16 '16 at 18:05
  • @MadHatter Ok, understood. You are correct. https://www.kernel.org/doc/Documentation/networking/bonding.txt does say that balance-rr requires some kind of "grouping" and makes reference to trunk groups. However I have used it a few times without making any switch changes, with managed/unmanaged switches and with direct connections and no switch at all. I can't understand why anything special would be required based on the way it works... – Ryan Babchishin Sep 16 '16 at 18:15
  • can anyone comment how Windows does this? I just created a winxp vm, with 2 network cards. I "unplugged" one and the second works fine and viceversa. No tricks, no files, no configuring, just works out of the box as it should. The routing table actually shows up two 0.0.0.0 default routes - one per interface. That's what i want! I tried setup bonding in debian, and it doesn't work. The bond sees that the interface eth0 is down and "enables" eth1, but i can't ping it!. – fjleon Sep 19 '16 at 19:13
3

I think the routing table tells the story: even though the cable is pulled, the computer still prefers the now-dead route via eth0 to the route via eth1. Without NetworkManager or something similar, Linux is not robust about re-routing. Even though you ping eth1's IP address, the computer does not necessarily use that interface for the return packet; rather it constructs a reply to the source IP of the ping and sends, which will use the routing table to decide how to return.

Jeremy Dover
  • 318
  • 1
  • 6
  • that's why i am doing the test within the same subnet. there shouldn't be any routing if i am pinging both interfaces from a different machine that is on the same subnet! I was reading that if i wanted a different default gateway per interface i either use Solaris or the tools in the iproute2 package. The old net-tools package wouldn't work. – fjleon Sep 16 '16 at 03:20
  • 1
    Every packet the computer sends is "routed", if it is using the built-in TCP/IP stack. Based on the destnation IP address, the computer uses its routing table to determine which interface to send the packet out. This choice helps the computer determine the destination MAC address to which to send the resulting frame, since the routing table indicates either a directly connected network, or a next hop. – Jeremy Dover Sep 16 '16 at 11:13
0

To emulate Windows' behaviour, i had to actually create a second routing table using iproute2 following this guide.

echo "1 my_route" >> /etc/iproute2/rt_tables
ip route add 192.168.x.0/24 dev eth1 src 192.168.x.y table my_route
ip route add default via 192.168.x.1 dev eth1 table my_route
ip rule add from 192.168.x.y/32 table my_route
ip rule add to 192.168.x.y/32 table my_route

After doing that i could ping the ip of eth1 even if i removed the cable to eth0. The linked guide also explains how to make these changes permanent.

fjleon
  • 195
  • 1
  • 8