j.kammer at eurodata
Dec 6, 2006, 7:13 AM
Post #11 of 16
On Wed, Dec 06, 2006 at 01:36:15PM +0000, Paul Jakma wrote:
Re: other solution for bgp stuck in clearing state
[In reply to]
> On Wed, 6 Dec 2006, Juergen Kammer wrote:
> >2006/12/06 09:32:36 BGP: BGPd 0.99.5 starting: vty [at] 260, bgp [at] 17
> >2006/12/06 09:32:39 BGP: 10.1.28.2 [Error] State Idle is not Established,
> >but ro
> >utes were cleared - bug!
> >2006/12/06 09:32:39 BGP: Assertion `peer->status == 6' failed in file
> >c, line 2655, function bgp_clear_route
> Oh, oops, forgot about that ;).
> >bgp_clear_route gets called when we are leaving Idle, oups: you do
> >not check whether you change into Clearing at all there, you
> >unconditionally clear all routes whenever a transition happens, uh,
> D'Oh. Ok, I didn't say I tested it. ;)
> Just curious what you think of the approach at least, given your
> comment on best place to do it.
Hm... to do something whenever the state changes into a specific one
sounds more like sweeping something under the carpet. Would be better
to ensure that we have done the right thing when we transition into
A look into the transition table shows that we are entering Clearing
only after calling:
bgp_stop - does already the right thing
bgp_ignore - happens only in situations when no connection
was there anyway
bgp_fsm_holdtime_expire - does not do the right thing
bgp_stop_with_error - calls bgp_stop, see there
So, if this is right, it should suffice that bgp_fsm_holdtime_expire
does not enqueue BGP_Stop, but call bgp_stop instead (or call only
bgp_clear_route if that suffices).
Does that sound logical?
Juergen Kammer Email: j.kammer [at] eurodata
Quagga-users mailing list
Quagga-users [at] lists