<div><span class="gmail_quote">On 4/18/08, <b class="gmail_sendername">Andrew J. Schorr</b> &lt;<a href="mailto:aschorr@telemetry-investments.com">aschorr@telemetry-investments.com</a>&gt; wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi Ray,<br><br>On Fri, Apr 18, 2008 at 04:24:40PM -0400, Ray Barnes wrote:<br>&gt; Thanks Andy.&nbsp;&nbsp;The issue is that bgpd is simply not aggressive enough in its<br>
&gt; communication attempts toward zebra.&nbsp;&nbsp;If it made an attempt once every 2-3<br>&gt; seconds, that&#39;d surely satisfy my requirement for HA/failover using BGP.<br>&gt; But even with &#39;watchquagga&#39; which I understand to simply restart quagga<br>
&gt; daemons if they fail, that solution is not adequate.&nbsp;&nbsp;Per my previous<br>&gt; message, if zebra is restarted for some reason, it will not receive updates<br>&gt; from bgpd until bgpd has something to update.&nbsp;&nbsp;If bgpd never makes an<br>
&gt; update, zebra will not receive routes.&nbsp;&nbsp;I&#39;ve seen this condition persist<br>&gt; over and over again, for several hours at a time in my environment.<br><br>Frankly, I don&#39;t see in the code why bgpd would connect to zebra even<br>
if it had an update.&nbsp;&nbsp;It looks to me like this connection is attempted<br>only by the bgp_init() function, and bgp_init is called once in main<br>before entering the main event processing loop.&nbsp;&nbsp;So there&#39;s probably<br>
something in the code that I&#39;m missing if the behavior is as you say.<br><br>I&#39;m not a heavy bgpd user, so I&#39;m not 100% clear on the desirability<br>of having bgpd attempt to connect to zebra every few seconds.&nbsp;&nbsp;The patch<br>
to do this would not be difficult, but I don&#39;t know that this would always<br>be desirable behavior for all users.<br><br>Two thoughts spring to mind:<br><br>&nbsp;&nbsp;1. A command-line option could be added to turn on the behavior that you<br>
&nbsp;&nbsp;desire.<br><br>&nbsp;&nbsp;2. An explicit command could be added to the telnet/vtysh interface that<br>&nbsp;&nbsp;would allow you to instruct bgpd to try to connect to zebra.&nbsp;&nbsp;That way,<br>&nbsp;&nbsp;if you have some event that causes you to start up zebra, you could<br>
&nbsp;&nbsp;then simply tell bgpd to connect.<br><br>If you were to submit a patch for either of these approaches, that would<br>be the best way for you to get this functionality added.</blockquote>
<div>&nbsp;</div>
<div>Or perhaps even better, patches for bgpd to simply refresh its routes into zebra every n seconds.&nbsp; 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.</div>
<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">&gt; In fact, the thing that prompted all of this digging on my part, was that my<br>&gt; box lost its default route in zebra.&nbsp;&nbsp;Although bgpd had defaults from both<br>
&gt; peers, the route simply *fell out* of zebra and the kernel.&nbsp;&nbsp;That&#39;s a bug<br>&gt; which will definitely preclude my use of quagga as currently deployed, and<br>&gt; maybe even overall.<br><br>It sounds like this issue requires some debugging.&nbsp;&nbsp;Could you please open<br>
a bugzilla item on this?</blockquote>
<div>&nbsp;</div>
<div>Sure, i&#39;ll&nbsp;tear into the code in the next couple of days and report on the findings.</div>
<div>&nbsp;</div>
<div>-Ray</div></div><br>