<div dir="ltr">The queries need to be yielding results based on live data, so dumping the RIB into a file will not work. Regarding using multiple tables and PIPE, can you elaborate? I'm fairly new to BIRD, and I'm not sure I understand how this would work.<div>
<br></div><div>The objective of this is to provide a scalable way to yield real-time route lookups using BIRD. Imagine a looking glass that needs to support tens (or hundreds) of thousands of queries per second. The expected number of routes fed into BIRD currently sits at 7-10 million, which yields 5,000 QPS per core (with PyBird).</div>
<div><br></div><div>The above implementation can be achieved using multiple BIRD processes, with a parent process reflecting its master table to N children/worker processes (using the add-path branch). I'd like to avoid this, as it replicates the memory footprint to each child/worker processes -- not to mention the add-path branch has been segfaulting on me with 'rr client;' enabled.</div>
</div><div class="gmail_extra"><br clear="all"><div><br>-- Eric Cables</div>
<br><br><div class="gmail_quote">On Fri, Aug 23, 2013 at 4:01 PM, Matthew Walster <span dir="ltr"><<a href="mailto:matthew@walster.org" target="_blank">matthew@walster.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">Why not read into multiple tables and then scale out using something like PIPE? Or just dump the RIB into a file and process there? Why do you need so many queries?</p>
<p dir="ltr">Perhaps if we knew what you wanted to achieve we might be able to advise better.</p><span class="HOEnZb"><font color="#888888">
<p dir="ltr">M</p></font></span><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On 23 Aug 2013 21:19, "Eric Cables" <<a href="mailto:ecables@gmail.com" target="_blank">ecables@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Yes, this can work, and will achieve my stated goal. My stated goal, however, does not tell the whole story...<div><br></div><div>I suppose my follow-up to this would be -- Can BIRD run in a shadow/read-only mode, allowing a primary BIRD process to read/write data into memory, but multiple BIRD processes to read the primary's memory space, each with a unique control socket for direct queries?</div>
<div><br></div><div>The above is meant to serve as an extremely scalable system for querying BIRD directly, while distributing queries across multiple read-only workers; at the same time not duplicating the memory space of the parent BIRD process for each worker. As it stands, the BIRD memory space I am trying to query consumes about 1.1GB, and yields 5,000 queries per second before a core reaches 99% CPU. I would like to scale this out, and achieve (5,000 * n) QPS without also consuming (1.1GB * n) memory.</div>
<div><br></div><div>Thoughts?</div></div><div class="gmail_extra"><br clear="all"><div><br>-- Eric Cables</div>
<br><br><div class="gmail_quote">On Fri, Aug 23, 2013 at 7:11 AM, Ondrej Zajicek <span dir="ltr"><<a href="mailto:santiago@crfreenet.org" target="_blank">santiago@crfreenet.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Thu, Aug 22, 2013 at 06:05:01PM -0700, Eric Cables wrote:<br>
> Is it possible to run BIRD in a speaker-only only mode, such that it does<br>
> not bind to a local TCP socket, for the BGP protocol? While i can bind BIRD<br>
> to different TCP ports at start-up, many vendors do not support specifying<br>
> a destination port other than tcp/179.<br>
<br>
</div>There is no option for this, but you could either bind BIRD instances to<br>
a different port or to a different IP (listen option). If you bind BIRD<br>
to a different port, you don't need to configure neighbors - outgoing<br>
connections will be still to tcp/179.<br>
<span><font color="#888888"><br>
--<br>
Elen sila lumenn' omentielvo<br>
<br>
Ondrej 'SanTiago' Zajicek (email: <a href="mailto:santiago@crfreenet.org" target="_blank">santiago@crfreenet.org</a>)<br>
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, <a href="http://wwwkeys.pgp.net" target="_blank">wwwkeys.pgp.net</a>)<br>
"To err is human -- to blame it on a computer is even more so."<br>
</font></span><br>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.9 (GNU/Linux)<br>
<br>
iEYEARECAAYFAlIXbY0ACgkQw1GB2RHercPhPgCdGqQeerR0uZxkUmW7p2MANkx/<br>
V58AniOkTc2pbosmnokAQBVvJi/d/KmJ<br>
=tp7d<br>
-----END PGP SIGNATURE-----<br>
<br></blockquote></div><br></div>
</blockquote></div>
</div></div></blockquote></div><br></div>