[quagga-dev 4389] Re: ospf default-information strangeness

Andrew J. Schorr aschorr at telemetry-investments.com
Sat Sep 23 17:08:58 BST 2006

On Sat, Sep 23, 2006 at 09:58:52AM +0100, Paul Jakma wrote:
> On Fri, 22 Sep 2006, Andrew J. Schorr wrote:
> >Is there any objection to my committing this patch?
> >In other words, is there some good reason to call
> >ospf_external_lsa_refresh_default(ospf) even if the
> >metric-type and metric have not changed (i.e. the
> >user had already run 'default-information originate' with
> >the same metric and metric-type)?
> If those are the only variables of note, makes sense yes (I can't 
> can't think of anything else, but havn't looked at the code to 
> confirm).

Hmmm, now that I look again, I fear the patch is not safe.
There could be a hidden dependency on a change in the routemap,
I think.  So even though the metric and metric-type are the same,
it looks like the result of the call to ospf_external_lsa_refresh_default
may depend on whether the routemap was changed prior to
calling ospf_redistribute_default_set.

In that case, it may make most sense simply to leave the code
as is (but removing the unused 'force' variable from

But even worse, now that I look further, there seems to be a bug in
this function.  The 2nd arg 'originate' seems to be ignored if
ospf_is_type_redistributed(DEFAULT_ROUTE) is already true.  Doesn't
that suggest that changes in that value (DEFAULT_ORIGINATE_ALWAYS
vs. DEFAULT_ORIGINATE_ZEBRA) may be ignored?

And I just confirmed it.  If you set 'default-information originate metric
10 metric-type 1', and then enter the same command again with 'always',
you will not see 'always' in the 'show running-config' output.

And it's not clear to me whether the fix is simply to set default_originate
to the new value.  Is there anything else that may need to be done
in conjunction with this change?  Is calling ospf_external_lsa_refresh_default
sufficient to implement the changed policy?


More information about the Quagga-dev mailing list