[quagga-dev 11684] Re: link detect enable
paul at jakma.org
Wed Oct 29 10:50:02 GMT 2014
On Wed, 29 Oct 2014, David Lamparter wrote:
> It's not actually difficult to do in Quagga, we just need to have it
> first thing on top of the config so that it can influence defaults of
> objects being created further down the config loading process.
> (Flipping it run-time would keep all settings and only affect new
> things, which IMHO is actually a nice thing to do.)
Hmm, to be honest, I'm not keen on adding another command to control
whether or not to set this as default. It just adds another config command
that we'll have to keep around forever more, and it doesn't solve the
problem: Our default is ungood and unexpected for (I'd suspect) most
My preferred approach would be to just set the default, and document
link-detect is on by default, this will cause local IP addresses on
physical interfaces to not be advertised to routing if the interface
does not detect that it's link is up.
As a result, some users may need to reconfigure some IP addresses as
loopback addresses, where they intend traffic to those addresseses to be
able to follow changes in routing.
Note that IP addresses configured on non-loopback generally can
*not* be relied on to remain reachable, even with dynamic routing,
because at least some operating systems will *always* send traffic to a
host on a locally connected IP subnet out via that subnet, and will
*never* reroute via a dynamic route.
Otherwise, I'd prefer to leave it alone for now, because I'd hope one day
we'd agree we /could/ just flip the default and document that, and so
avoid more config commands. ;)
I wouldn't stop someone adding a global link-detect default on/off switch,
but then we still just end up one day back here at the same argument about
changing its default.
The only precedent I can think of is we once had a bug in (IIRC) RIP auth
where we had to change behaviour incompatibly, and we had to go through
several releases with:
* Release X: Add a "broken behaviour on/off" command, that was on by
default and whose state was *always* explicitly written out to config.
* Release Y: Change the default of "broken behaviour ..." to off.
* Release Z: No longer explicitly write out the "broken behaviour ..."
command, but only if its state was != default.
Where X, Y and Z weren't necessarily consecutive releases (I can't
The idea being that those already running ripd and depending on the broken
behaviour might upgrade to X and at some point doing 'write file', so
getting the "broken behaviour on" command in their permanent config. After
which the Y release could change the default without breaking at least
some of the X users. If it did break (e.g. new install talking to pre-X
neighbours), at least there'd be a strange new command in the config when
Then eventually the Z release finally could stop the command still being
That's very tedious, but every ripd auth user depended on the borken
behaviour and it wasn't their fault - it was a stupid ripd bug (mine I
think, not 100% certain).
In this case, the default is affecting all users, and every new user has
to learn about the desirability of setting this flag. However anyone
depending on it is almost certainly doing so by mistake.
Paul Jakma paul at jakma.org @pjakma Key ID: 64A2FF6A
The grass is always greener on the other side of your sunglasses.
More information about the Quagga-dev