minor bird crash
Wolfgang Hennerbichler
wh at univie.ac.at
Mon Mar 22 07:32:18 CET 2010
On Mar 21, 2010, at 23:16 , Arnold Nipper wrote:
> However I still would like to know what an optimal solution could look
> like. I.e. a solution also covering the corner cases.
Don't know if it is optimal, but I can tell you how we do it: Our routes are generated from the RIPEdb (I won't discuss why not RADB, there are a couple of reasons for that). After the generation of the routes (with a script called rpsltool, btw, I refused to go with bloated rrdtool), all the routes are SYNCED to a database (meaning if nothing has changed, the database isn't touched). If something changes in the database (either an add or a delete), a database trigger writes a 'todo' into a database table. A separate job checks the todos, if there are any, it generates the bird configuration file, and writes it to the bird route-server. it also checks which routes have changed, and according to that it reloads only the according protocols and the according pipes. This way the load keeps low, and the job that generates the config files only does it when relevant changes are happening, if there's nothing to do, nothing is done.
> Best regards,
> Arnold
Wolfgang
> --
> Arnold Nipper / nIPper consulting, Sandhausen, Germany
> email: arnold at nipper.de phone: +49 6224 9259 299
> mobile: +49 172 2650958 fax: +49 6224 9259 333
>
--
www.vix.at | www.aco.net
wh at univie.ac.at | WH844-RIPE
Vienna University Computer Center
More information about the Bird-users
mailing list