[quagga-dev 5310] Re: intermittent communication between bgpd and zebra?
rrb at colo4jax.com
Fri Apr 18 21:57:43 BST 2008
On 4/18/08, Andrew J. Schorr <aschorr at telemetry-investments.com> wrote:
> Hi Ray,
> On Fri, Apr 18, 2008 at 04:24:40PM -0400, Ray Barnes wrote:
> > Thanks Andy. The issue is that bgpd is simply not aggressive enough in
> > communication attempts toward zebra. If it made an attempt once every
> > seconds, that'd surely satisfy my requirement for HA/failover using BGP.
> > But even with 'watchquagga' which I understand to simply restart quagga
> > daemons if they fail, that solution is not adequate. Per my previous
> > message, if zebra is restarted for some reason, it will not receive
> > from bgpd until bgpd has something to update. If bgpd never makes an
> > update, zebra will not receive routes. I've seen this condition persist
> > over and over again, for several hours at a time in my environment.
> Frankly, I don't see in the code why bgpd would connect to zebra even
> if it had an update. It looks to me like this connection is attempted
> only by the bgp_init() function, and bgp_init is called once in main
> before entering the main event processing loop. So there's probably
> something in the code that I'm missing if the behavior is as you say.
> I'm not a heavy bgpd user, so I'm not 100% clear on the desirability
> of having bgpd attempt to connect to zebra every few seconds. The patch
> to do this would not be difficult, but I don't know that this would always
> be desirable behavior for all users.
> Two thoughts spring to mind:
> 1. A command-line option could be added to turn on the behavior that you
> 2. An explicit command could be added to the telnet/vtysh interface that
> would allow you to instruct bgpd to try to connect to zebra. That way,
> if you have some event that causes you to start up zebra, you could
> then simply tell bgpd to connect.
> If you were to submit a patch for either of these approaches, that would
> be the best way for you to get this functionality added.
Or perhaps even better, patches for bgpd to simply refresh its routes into
zebra every n seconds. Not as a default behavior, but as you said,
something that could be triggered by a command-line option as a stop-gap
solution to hopefully prevent this issue and the one I mentioned below.
> In fact, the thing that prompted all of this digging on my part, was that
> > box lost its default route in zebra. Although bgpd had defaults from
> > peers, the route simply *fell out* of zebra and the kernel. That's a
> > which will definitely preclude my use of quagga as currently deployed,
> > maybe even overall.
> It sounds like this issue requires some debugging. Could you please open
> a bugzilla item on this?
Sure, i'll tear into the code in the next couple of days and report on the
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Quagga-dev