Run external script after accepting BGP update or withdraw
Hi, Does BIRD support to run external command after BGP update or withdraw message received (and accepted by filter) with arguments or env variables with details of received announce message?
On Thu, Jul 17, 2014 at 09:15:04AM +0300, Stanislav Datskevich wrote:
Hi, Does BIRD support to run external command after BGP update or withdraw message received (and accepted by filter) with arguments or env variables with details of received announce message?
Maybe ExaBGP is more suited for this: https://github.com/Exa-Networks/exabgp
Hi, Baptiste, I know about ExaBGP, but I'm using BIRD to do all the BGP stuff: loadbalancing via ecmp at webfrontends, routeservers, soft routers etc, and now I need an external announces handling, so I've placed a feature request here :). If honored BIRD developers will decide to not implement this feature, I will look at another routing software. 2014-07-17 11:08 GMT+03:00 Baptiste Jonglez <bjonglez@illyse.org>:
On Thu, Jul 17, 2014 at 09:15:04AM +0300, Stanislav Datskevich wrote:
Hi, Does BIRD support to run external command after BGP update or withdraw message received (and accepted by filter) with arguments or env variables with details of received announce message?
Maybe ExaBGP is more suited for this:
So, this feature will not be implemented? I think BIRD will turn into BGP swiss-knife if it will be. 2014-07-17 12:26 GMT+03:00 Stanislav Datskevich <sdatskevich@gmail.com>:
Hi, Baptiste, I know about ExaBGP, but I'm using BIRD to do all the BGP stuff: loadbalancing via ecmp at webfrontends, routeservers, soft routers etc, and now I need an external announces handling, so I've placed a feature request here :). If honored BIRD developers will decide to not implement this feature, I will look at another routing software.
2014-07-17 11:08 GMT+03:00 Baptiste Jonglez <bjonglez@illyse.org>:
On Thu, Jul 17, 2014 at 09:15:04AM +0300, Stanislav Datskevich wrote:
Hi, Does BIRD support to run external command after BGP update or withdraw message received (and accepted by filter) with arguments or env variables with details of received announce message?
Maybe ExaBGP is more suited for this:
On 18.7.2014 10:50, Stanislav Datskevich wrote:
So, this feature will not be implemented? I think BIRD will turn into BGP swiss-knife if it will be.
I think, this sounds interesting to me. And it shouldn't be very complicated to code it. I will look at it. Ondrej
2014-07-17 12:26 GMT+03:00 Stanislav Datskevich <sdatskevich@gmail.com <mailto:sdatskevich@gmail.com>>:
Hi, Baptiste, I know about ExaBGP, but I'm using BIRD to do all the BGP stuff: loadbalancing via ecmp at webfrontends, routeservers, soft routers etc, and now I need an external announces handling, so I've placed a feature request here :). If honored BIRD developers will decide to not implement this feature, I will look at another routing software.
2014-07-17 11:08 GMT+03:00 Baptiste Jonglez <bjonglez@illyse.org <mailto:bjonglez@illyse.org>>:
On Thu, Jul 17, 2014 at 09:15:04AM +0300, Stanislav Datskevich wrote: > Hi, > Does BIRD support to run external command after BGP update or withdraw > message received (and accepted by filter) with arguments or env variables > with details of received announce message?
Maybe ExaBGP is more suited for this:
Ondrej, On 18 Jul 2014, at 17:44, Ondrej Filip <feela@network.cz> wrote:
On 18.7.2014 10:50, Stanislav Datskevich wrote:
So, this feature will not be implemented? I think BIRD will turn into BGP swiss-knife if it will be.
I think, this sounds interesting to me. And it shouldn't be very complicated to code it. I will look at it.
Can I suggest you make the syntax such that a script is but one option? I can see a good case for (e.g.) triggering a little lua to run, which would not involve a fork() and be much faster. Clearly someone else would have to code that bit, but generalising this might be useful. This way you could get your lua to filter out 99% of things before running (e.g.) a script. We have some experience integrating lua things and whilst I can't guarantee it, we may be prepared to take a look. -- Alex Bligh
❦ 18 juillet 2014 18:01 +0100, Alex Bligh <alex@alex.org.uk> :
On 18.7.2014 10:50, Stanislav Datskevich wrote:
So, this feature will not be implemented? I think BIRD will turn into BGP swiss-knife if it will be.
I think, this sounds interesting to me. And it shouldn't be very complicated to code it. I will look at it.
Can I suggest you make the syntax such that a script is but one option? I can see a good case for (e.g.) triggering a little lua to run, which would not involve a fork() and be much faster. Clearly someone else would have to code that bit, but generalising this might be useful. This way you could get your lua to filter out 99% of things before running (e.g.) a script. We have some experience integrating lua things and whilst I can't guarantee it, we may be prepared to take a look.
Another way to avoid forking is to allow a long-running process to receive data, either through a socket or by spawning it and communicating with it on stdin/stdout. -- panic("aha1740.c"); /* Goodbye */ 2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
Hi Vincent, Alex, I'm not a C programmer, so, could you please explain why fork() is the problem? I see this feature work this way: 1. Place "run external command" statement into "if" statement inside the filter or function, so it will be ran only on the specific updates/withdraws. 2. When update/withdraw message is arrived, BIRD runs external command, passes message details to it as environment variables and forks it. After fork BIRD is not blocked by child execution, so it will not be a performance impact. Please clarify if I missed something. 2014-07-18 20:40 GMT+03:00 Vincent Bernat <bernat@luffy.cx>:
❦ 18 juillet 2014 18:01 +0100, Alex Bligh <alex@alex.org.uk> :
On 18.7.2014 10:50, Stanislav Datskevich wrote:
So, this feature will not be implemented? I think BIRD will turn into BGP swiss-knife if it will be.
I think, this sounds interesting to me. And it shouldn't be very complicated to code it. I will look at it.
Can I suggest you make the syntax such that a script is but one option? I can see a good case for (e.g.) triggering a little lua to run, which would not involve a fork() and be much faster. Clearly someone else would have to code that bit, but generalising this might be useful. This way you could get your lua to filter out 99% of things before running (e.g.) a script. We have some experience integrating lua things and whilst I can't guarantee it, we may be prepared to take a look.
Another way to avoid forking is to allow a long-running process to receive data, either through a socket or by spawning it and communicating with it on stdin/stdout. -- panic("aha1740.c"); /* Goodbye */ 2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
❦ 20 juillet 2014 10:05 +0300, Stanislav Datskevich <sdatskevich@gmail.com> :
Hi Vincent, Alex, I'm not a C programmer, so, could you please explain why fork() is the problem? I see this feature work this way: 1. Place "run external command" statement into "if" statement inside the filter or function, so it will be ran only on the specific updates/withdraws. 2. When update/withdraw message is arrived, BIRD runs external command, passes message details to it as environment variables and forks it. After fork BIRD is not blocked by child execution, so it will not be a performance impact.
When a lot of updates are happening, you'll have to do a lot of fork/exec which will put pressure on the system, slowing it down. If you are worried about using stdin instead of arguments or environment variables, that's not really more complex. Instead of having a script which does: echo $1 $2 >> /var/log/something You do: while read a b; do echo $a $b >> /var/log/something done Moreover, this allows bidirectional communication. Your script can send routes to be advertised. At least, it should make your life easier by handling one route at a time without locking. In the first example, parallel execution of such a script would lead to a mangled log file. -- Make sure comments and code agree. - The Elements of Programming Style (Kernighan & Plauger)
At least, it should make your life easier by handling one route at a time without locking. In the first example, parallel execution of such a script would lead to a mangled log file.
Actually, on any modern system append mode guarantees not to corrupt from parallel execution as long you are only adding a single whole line at time, and the file is not on a NFS mount.
❦ 20 juillet 2014 12:00 GMT, "Lauro, John" <jlauro@umflint.edu> :
At least, it should make your life easier by handling one route at a time without locking. In the first example, parallel execution of such a script would lead to a mangled log file.
Actually, on any modern system append mode guarantees not to corrupt from parallel execution as long you are only adding a single whole line at time, and the file is not on a NFS mount.
Good to know. I suppose this is not a whole line but less than X bytes (likely 4096). -- panic("Oh boy, that early out of memory?"); 2.2.16 /usr/src/linux/arch/mips/mm/init.c
Stanislav, On 20 Jul 2014, at 08:05, Stanislav Datskevich <sdatskevich@gmail.com> wrote:
I'm not a C programmer, so, could you please explain why fork() is the problem? I see this feature work this way: 1. Place "run external command" statement into "if" statement inside the filter or function, so it will be ran only on the specific updates/withdraws. 2. When update/withdraw message is arrived, BIRD runs external command, passes message details to it as environment variables and forks it. After fork BIRD is not blocked by child execution, so it will not be a performance impact.
If you are carrying a large routing table of many hundreds of thousands of routes, losing an interface (or regaining it) will result in hundreds of thousands (if not millions) of withdrawals or advertisements, which will in turn result in hundreds of thousands of calls to fork() in order to run the external script. That will be very slow. Of course one answer is 'don't do that then'. But another possibility is to allow whatever hook is put in not only to run a script, but also (e.g.) to call a little bit of lua. Provided you already have your luaState (meaning the lua VM is already initialised), the overhead in calling one function in lua is tiny. This would allow this idea to scale to hundreds of thousands or millions of routes without difficulty. The lua could be used to (e.g.) log certain route changes to a file. For instance, anyone interested in logging any advertisement of a route which has been both withdrawn and advertised more than twice in the last 10 minutes (a.k.a. a flap)? Or in logging receipt from other than the customer of a more specific route than one of one's customers routes that are not in a pre-agreed list? Or do some matching on the above and only in respect of /some/ of the routes, run a script? These would be simple little programs in lua (tens of lines maximum), but doubtless are not things that the members of the Ondrej Aggregate will want to take code for on a case by case basis into bird. -- Alex Bligh
On Fri, Jul 18, 2014 at 06:01:19PM +0100, Alex Bligh wrote:
On 18 Jul 2014, at 17:44, Ondrej Filip <feela@network.cz> wrote:
On 18.7.2014 10:50, Stanislav Datskevich wrote:
So, this feature will not be implemented? I think BIRD will turn into BGP swiss-knife if it will be.
I think, this sounds interesting to me. And it shouldn't be very complicated to code it. I will look at it.
Can I suggest you make the syntax such that a script is but one option? I can see a good case for (e.g.) triggering a little lua to run, which would not involve a fork() and be much faster. Clearly someone else would have to code that bit, but generalising this might be useful. This way you could get your lua to filter out 99% of things before running (e.g.) a script. We have some experience integrating lua things and whilst I can't guarantee it, we may be prepared to take a look.
LUA in BIRD for stuff like this would make for extreme versatility, good suggestion! Kind regards, Job
Hi, You have convinced me, LUA support will be great for BIRD, waiting for it impatiently :) 2014-07-21 12:29 GMT+03:00 Raphael Mazelier <raph@futomaki.net>:
LUA in BIRD for stuff like this would make for extreme versatility, good suggestion!
+1
Lua in bird will be the killer feature.
-- Raphael Mazelier
participants (8)
-
Alex Bligh -
Baptiste Jonglez -
Job Snijders -
Lauro, John -
Ondrej Filip -
Raphael Mazelier -
Stanislav Datskevich -
Vincent Bernat