2

My apologies if this is an obvious question, I'm a newbie as far as redundant networking goes, and I'm not sure what keywords to Google for. My application scenario is this:

  • The system consists of a small number of Linux-based servers (anywhere from 1 to 20)
  • Each server has two physical Ethernet jacks on it
  • The system runs on an isolated LAN -- it's not connected to the Internet in any way
  • The (custom/in-house) application software that runs on each server communicates with its peers on the other servers via persistent TCP connections and/or UDP multicasting.
  • All communication happens via IPv6
  • The obvious thing to do in order to get network redundancy is to have two high-speed Ethernet switches, and connect each Linux server to both switches. That way if one of the switches fails, or somebody accidentally cuts through an Ethernet cable, communication can continue via the other cable/switch, and the system will remain fully functional.

    My question is, is there a way to make the redundancy 100% transparent to the application software? (By transparent, I mean that the application software shouldn't have to know or care that there is more than one Ethernet port; ideally it would only see an eth0 and not an eth1... and if data stops flowing over one of the two physical Ethernet ports for whatever reason, the application software shouldn't have to detect the fault or do anything special in order to keep working).

    Extra bandwidth isn't important for my purposes (one "lane" of gigabit ethernet is fast enough), but simplicity and reliability are.

    4
    • Just curious but why IPv6? It's certainly not needed for what you have described and merely adds to the network overhead. Is it perhaps for some future use of the application? Oct 2, 2009 at 3:16
    • 1
      It's allegedly to make autoconfiguration of the system easier (e.g. with IPv6 we can use stateless autoconfiguration, the router advisement daemon, etc). We'll see if that plays out in practice or not... Oct 27, 2009 at 18:46
    • Is the system running on a single isolated LAN or does each ethernet jack connect to a separate isolated LAN? Apr 15, 2013 at 0:24
    • Don't forget that you need independent power (phase) and PSU for each switch as well.
      – Zac67
      Mar 3, 2023 at 9:35

    2 Answers 2

    5

    The google juice you want is "Ethernet bonding". It's a work of art.

    3
    • 2
      Or Link Aggregation. I believe LACP (802.3ad) supports failover mode as well. Oct 2, 2009 at 0:37
    • 2
      The Linux bonding driver supports LACP as one of it's bonding methods (along with a host of other possibilities).
      – womble
      Oct 2, 2009 at 1:03
    • 2
      I like that the Linux LAGG interfaces also support nic-mixing (so you don't have to have all cards from the same manufacturer). That'll be a 4Gb ethernet link to the iSCSI server, thankyouverymuch Oct 2, 2009 at 1:26
    0

    If you want simplicity and reliability, just get two switches that support multi-chassis link aggregation (vendors have their own names for it, sometimes it's just "stacking") and support enough Link Aggregates per switch to meet your needs. The set up LACP on the switch ports and servers so all your applications see is a single "bond0" interface on each server.

    Linux also supports something called "adaptive load balancing", which still looks like one "bond0" interface to the application layer, but does not use LACP nor does it require switches with multi-chassis link aggregation support (but the switches must be cross-connected with good bandwidth). This mode uses ARP tricks to direct incoming traffic to each physical interface instead of using the link-layer bonding standards. It only requires dumb switches with no special features, and works well for us in production with IPv4, not sure about IPv6.

    You must log in to answer this question.

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