[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
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
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