This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/
[atlas] Link aggregation for anchors?
- Previous message (by thread): [atlas] Link aggregation for anchors?
- Next message (by thread): [atlas] Link aggregation for anchors?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tore Anderson
tore at fud.no
Thu Jul 20 08:24:42 CEST 2017
* Gert Doering <gert at space.net> > Linux bonding can do ARP probing on both member interfaces, which does > the most important "real world" part of the error detection - "will > this port work for me to reach the default gateway?" (so you can even > failover on an uplink outage). I've seen, but it seems a bit of a hack to me, one that I'd be reluctant to see implemented in all the Anchors. I'd rather go without those X pps of extra broadcast traffic on my network, to be honest. There's also the risk that some networks rate-limit ARP and/or broadcast traffic in general which would make the approach unreliable. Further, it is a layering violation. In particular, if there's an IPv4 outage and ARPs go unanswered on one or more interfaces, that shouldn't have any impact on IPv6 whatsoever. Active/passive (using link down events to trigger fail-over) is probably the way to go. KISS and all that. Tore
- Previous message (by thread): [atlas] Link aggregation for anchors?
- Next message (by thread): [atlas] Link aggregation for anchors?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]