[quagga-dev 11684] Re: link detect enable

Paul Jakma 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 
something like:

   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 
they investigated.

Then eventually the Z release finally could stop the command still being 
written out.

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 mailing list