Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Linux Software

Network Adapter Failover in Linux? 19

Brian the Wise asks: "Is there anything avaible for Linux that can compare to the IP Multipathing in Solaris 8? I need it specifically for the active/passive failover of ethernet interfaces. A search around the net has only come up with HA Linux and LVS, but they're both talking about complete machine failover. All I want is for the system to move the IP configuration from one ethernet interface to a dormant one on the same machine when it detects the link going down on a single machine. Is there anything with a proven track record out there?"
This discussion has been archived. No new comments can be posted.

Network Adapter Failover in Linux?

Comments Filter:
  • failoverd (Score:4, Informative)

    by b-side.org ( 533194 ) <bside&b-side,org> on Sunday November 04, 2001 @10:32PM (#2520956) Homepage
    [ps-ax.com]
    http://ps-ax.com/failoverd/failoverd-pod.html


    and it needs an owner.
  • Routing protocol (Score:3, Informative)

    by brunson ( 91995 ) on Sunday November 04, 2001 @10:49PM (#2521000) Homepage
    They typical router solution is to have the dual hosted box participate in a routing protocol like OSPF using gated or something similar. Configure your routing daemon to have each physical interface advertise a zero cost route to a loopback address configured on the unix box then always use that loopback address to connect to it. If an iterface fails, the routing protocol converges and you maintain your connection.

    Depending on the routing daemon and the OS you can even get load balancing between the equal cost routes when both interfaces are up.
  • Another idea. (Score:4, Informative)

    by MindStalker ( 22827 ) <mindstalker@@@gmail...com> on Sunday November 04, 2001 @10:50PM (#2521001) Journal
    Something elhse you might want to try is having both ethernet devices have the same IP. Its possible, look into it, most switches (as it hub/switch) nowadays support it, I know the linksys ones do atleast. That way you actually get a faster output from the machine, AND you get failover at the same time.
    • Re:Another idea. (Score:2, Informative)

      by jannotti ( 37522 )
      Linux calls this bonding. Cisco calls it EtherChannel. Either way, I'm not sure it's smart enought to actually failover. I *think* it might just round robin between the multiple interfaces. But, like you say, it's something to investigate. I can at least confirm that it works with Cisco hardware. (Although you have to tell the switch to do it, the "automatic" configuration would only work if Linux spoke Cisco's little protocol for detecting bonded interfaces.)
    • Re:Another idea. (Score:3, Informative)

      by phroseph ( 249631 )
      You can't simply give two NICs the same address. You'll have to compile support into your kernel for channel bonding. Plus, the switch you're connected to has to support trunking.

      So, the in-kernel channel bonding driver _does_ have support for two active paths, and claims to detect path failure and take corrective actions, but I have no experience with it.
  • APD (Score:3, Interesting)

    by j.e.hahn ( 1014 ) on Monday November 05, 2001 @12:44AM (#2521232)
    Do a search on freshmeat.net for apd. (the alternate pathing daemon.) I'm using it quite successfully on linux and solaris 7 (in test bed only right now though). It's not bad.
  • Other slashdotters have already postet links to very interesting programs, but I'm not shure if those take the physical link-status in account (which I whould find very interesting).

    But if you want to do some programming on your own you should look at mii-diag which can monitor your ethernet-card's physical interface and tell you when your link goes down (physically).

    Using this as a basis, you could write a very simple eth-phy-daemon which could start a script whenever your physical link goes up/down. Then you could change your network-config with those.
    • I forgot the URL!!!! (Score:2, Interesting)

      by cnvogel ( 3905 )
      http://www.scyld.com/diag/
    • I'm not sure physical link status is enough. In a failure you may not lose link (which is a purely electrical phenomenon) but you may lose network connectivity. It's definitely a good criterion, but I sure wouldn't rely on it as my sole means of detection.

      That being said it would hurt to detect physical link failure, but I wouldn't rely on it as a single method. Also, realize that if you lose link, you should at the very least experience persistent packet loss. And that's a sure sign of a failure somewhere. (it'd be nice if the kernel could be configured to return Dest. Unreachable messages if link was down, but alas...)
  • I'm mostly a windows 2000 guy so this may be wrong, but does Linux have a way to set an Interface Metric?

    Basically that means you assign each eth adapter a number (metric). If more than one is set up with a route to your destination, it tries them in order of lowest metric to highest metric. Simply set up the failover adapter with a metric one higher than the standard one and you're set.
    • Re:IF Metric? (Score:2, Insightful)

      by Paul Jakma ( 2677 )
      yes linux supports metrics.

      however, this method will only work for physical link failures that are detected. (and i dont think linux does much even if it does detect a link failure).

      needless to say the vast majority of network failures tend not to be detected link failures.

      my suggestion would be to use OSPF for link state and route failure detection and failover.
  • The higher end server ethernet cards tend to do this automatically; they generally create a virtual NIC for the OS to use, then do it all transparently to the OS. This allows for clustering and for failover of NICs. Said highend cards are also often multiport. Dells, for example, tend to use the Intel ones.
  • pickup a few intel ee-pro/100 adaptors, and then use intel's advanced networking services module - the cards will support fault tolerance, load balancing, and link aggregation. you'll need to use intel's own e100 kernel module (not the eepro100 module included in the main kernel tree), though i haven't had any problems with it.

    http://support.intel.com/support/network/adapter /a ns/linux/linansoverview.htm
    • Yup, I use this on a few of my servers, and it works just fine. It creates a virtual ethernet device, which you can call anything you want. (I use fte0 for Fault Tolerent Ethernet) and you treat fte0 just like you would an actual network card. If one network cable gets unplugged, it fails over to the other NIC. The best part is, it works with ANY switch or HUB even. It is not a vendor specific solution like "EtherChannel"
  • Convolo has support for NIC failover which is modeled after Solaris's mpathd. Unfortunately, this only works in a clustered environment, so it may not be exactly what you're looking for.
  • Try VRRPd [arobas.net] if you just want failover between boxes, but a better solution is to dynamically load-balance over the two interfaces using a routing protocol.

A morsel of genuine history is a thing so rare as to be always valuable. -- Thomas Jefferson

Working...