So, not that it helps, but solaris does this with ipmp.
If what you want is failover, setup your two LAGS, and set the metric on
one preferred vs the other via a routing statement. Linux lacks this
separation of abstraction of link aggregation and primary/secondary
failover layering, though rumor has it that something might be available
in RH6 down the road:
(http://www.linuxquestions.org/questions/linux-networking-3/bonding-a-bond-running-802-3ad-dynamic-link-aggregation-827395/)
The other way that people have done this is with routing protocols.. You
could have the host participate in OSPF or BGP (quagga) and use the link
state to determine the path. BGP will definitely work for this, may or
may not be fast enough (probably), but requires both sides participate,
as does OSPF for that matter.
There's a "newer" helper to do this involving a little known networking
protocol called BFD.
http://en.wikipedia.org/wiki/Bidirectional_Forwarding_Detection. It's
main purpose is to make things like OSPF failover faster, *much* faster,
sub-second. It looks like there's a Linux kernel module for this. This
probably makes you feel a bit queasy. You wouldn't be alone.
http://kbfd.sourceforge.net/. You still need BGP or OSPF, too. :(
BFD also needs support on the switches.
You *may* be able to do this with just plain old route command with
'metric' and 'if' modifiers. Explicitly pick the interface and give one
a better metric than the other. It should prefer that path. Test. :)
On 1/31/2013 9:02 AM, Andrew Hume wrote:
exactly, derek.
which is why i am gobsmacked that this scenario isn't supported.
On Jan 31, 2013, at 6:40 AM, Derek Balling wrote:
On Jan 31, 2013, at 8:20 AM, "Edward Ned Harvey (lopser)"
<lop...@nedharvey.com <mailto:lop...@nedharvey.com>> wrote:
Why would you want to do that? Why wouldn't you bond all 4
connections together?
ec0 = bond rr eth0 eth1 eth2 eth3
Any one, or two, or three go down, the remaining one(s) still
function as desired...
Well, you might want predictable behavior. Let's say:
eth0/1 go to your "A" side switches
eth2/3 go to your "B" side switches
And "A" is generally where all your activity sits, unless you're doing
maintenance or have an outage on the "A" side, at which point traffic
shifts to the "B" side.
And it could be that the "B" side hardware is less robust,
lower-performance, but "workable" in the event of an A-side outage. Or
it goes to a different upstream router/ISP at a higher cost.
Lots of possibilities.
D
_______________________________________________
Tech mailing list
Tech@lists.lopsa.org <mailto:Tech@lists.lopsa.org>
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
-----------------------
Andrew Hume
623-551-2845 (VO and best)
973-236-2014 (NJ)
and...@research.att.com <mailto:and...@research.att.com>
_______________________________________________
Tech mailing list
Tech@lists.lopsa.org
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
_______________________________________________
Tech mailing list
Tech@lists.lopsa.org
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
