[prev in list] [next in list] [prev in thread] [next in thread]
List: quagga-dev
Subject: [quagga-dev 3940] Re: OSPF router id. update.
From: gunnar.stigen () axxessit ! no
Date: 2006-01-19 15:20:55
Message-ID: OF2311E0EE.FE4C2389-ONC12570FB.005056AF-C12570FB.00545105 () axxessit ! no
[Download RAW message or body]
This is a multipart message in MIME format.
This is a multipart message in MIME format.
--=_alternative 00545104C12570FB_=
Content-Type: text/plain; charset="us-ascii"
On Sat, 14 Jan 2006, Paul Jakma wrote:
__________________
> There's lots missing I think.
> When new router id. is updated in ospf->router_id, I assume the
> area->t_router_lsa_self threads should be stopped in order to avoid
> the router_lsa_refresh thread to execute before
> ospf->t_router_lsa_update has finished. This avoid the old
> router_lsa to remain in the LSDB forever.
> Ah, likely yes.
> But there's than just the router-LSA though. What about other LSAs
> which might be originated? Where is the old LSA flushed? That has to
> be done with the original ID.
> Also, anybody knows why there must be a delay before
> ospf_router_lsa_update_timer can be run?
> To prevent updates in short succession I'd say.
> Please evaluate if this patch is usable. At least, it works for me.
> Line numbers will not match, as I have removed some private
> comments.
> I think the router-id thing is half-cocked at the moment. We really
> ought to at least try flush out all old self-originated LSAs /before/
> updating the router-ID. I don't see where this happens at the moment.
Neither do I. But even if we try to flush them, there is principally no
guarantee that they are flushed from the AS. However, better trying than
doing nothing..
> What I'd like to see is:
> a) ospf_finish() work correctly/reliably (including flushing)
> b) stuff that is needed for ospfd to go into just a quiscent state
> (everything flushed, etc.), removed from ospf_finish(), so both
> ospf_finish() and router-ID update can use it.
> c) router-ID update to use that new function to quisce OSPF before
> changing the ID, and updating whatever needs updating.
Sounds reasonable
After some unsuccessful attempts, I decided to use ospf_finish followed by
an ospf_get(), update the router_id and reconfigure areas, networks etc,
as
they were before the router id. change.
On my platform, I found no reason trying to flush out the LSAs because
most of the interfaces go down upon the router id. change (as the
interfaces
inherit the same (unnumbered) address Although not optimal, this seems to
work OK. The old LSAs times out in an hour.
regards,
Gunnar
--=_alternative 00545104C12570FB_=
Content-Type: text/html; charset="us-ascii"
<br><font size=2 face="Courier New">On Sat, 14 Jan 2006, Paul Jakma \
wrote:</font><font size=3 face="Times New Roman"> </font> <br><font size=2 \
face="sans-serif">__________________</font> <br><font size=2><tt><br>
> There's lots missing I think.<br>
</tt></font>
<br><font size=2><tt>> When new router id. is updated in ospf->router_id, I \
assume the<br> > area->t_router_lsa_self threads should be stopped in order to \
avoid<br> > the router_lsa_refresh thread to execute before<br>
> ospf->t_router_lsa_update has finished. This avoid the old<br>
> router_lsa to remain in the LSDB forever.<br>
</tt></font>
<br><font size=2><tt>> Ah, likely yes.<br>
</tt></font>
<br><font size=2><tt>> But there's than just the router-LSA though. What about \
other LSAs<br> > which might be originated? Where is the old LSA flushed? That has \
to<br> > be done with the original ID.<br>
</tt></font>
<br><font size=2><tt>> Also, anybody knows why there must be a delay before<br>
> ospf_router_lsa_update_timer can be run?<br>
</tt></font>
<br><font size=2><tt>> To prevent updates in short succession I'd say.<br>
</tt></font>
<br><font size=2><tt>> Please evaluate if this patch is usable. At least, it works \
for me.<br> > Line numbers will not match, as I have removed some private<br>
> comments.<br>
</tt></font>
<br><font size=2><tt>> I think the router-id thing is half-cocked at the moment. \
We really<br> > ought to at least try flush out all old self-originated LSAs \
/before/<br> > updating the router-ID. I don't see where this happens at the \
moment.<br> </tt></font>
<br><font size=2><tt>Neither do I. But even if we try to flush them, there is \
principally no</tt></font> <br><font size=2><tt>guarantee that they are flushed from \
the AS. However, better trying than</tt></font> <br><font size=2><tt>doing nothing.. \
</tt></font> <br>
<br><font size=2><tt>> What I'd like to see is:<br>
</tt></font>
<br><font size=2><tt>> a) ospf_finish() work correctly/reliably (including \
flushing)<br> </tt></font>
<br><font size=2><tt>> b) stuff that is needed for ospfd to go into just a \
quiscent state<br> > (everything flushed, etc.), removed from ospf_finish(), so \
both<br> > ospf_finish() and router-ID update can use it.<br>
</tt></font>
<br><font size=2><tt>> c) router-ID update to use that new function to quisce OSPF \
before<br> > changing the ID, and updating whatever needs updating.<br>
</tt></font>
<br><font size=2><tt>Sounds reasonable</tt></font>
<br>
<br><font size=2><tt>After some unsuccessful attempts, I decided to use ospf_finish \
followed by</tt></font> <br><font size=2><tt>an ospf_get(), update the router_id and \
reconfigure areas, networks etc, as</tt></font> <br><font size=2><tt>they were before \
the router id. change.</tt></font> <br>
<br><font size=2><tt>On my platform, I found no reason trying to flush out the LSAs \
because</tt></font> <br><font size=2><tt>most of the interfaces go down upon the \
router id. change (as the interfaces</tt></font> <br><font size=2><tt>inherit the \
same (unnumbered) address Although not optimal, this seems to</tt></font> <br><font \
size=2><tt>work OK. The old LSAs times out in an hour.</tt></font> <br>
<br><font size=2><tt>regards, </tt></font>
<br><font size=2><tt>Gunnar </tt></font>
<br>
<br>
--=_alternative 00545104C12570FB_=--
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic