Re: Import directly connected routes
Thank you for your answer. This is really useful and helped me solve a problem that seemed impossible in Quagga. Thanks :) On 09/05/17 08:47 AM, Ondrej Zajicek wrote: On Tue, May 09, 2017 at 08:28:26AM -0400, Damien Clabaut wrote: Hello, Thank you for your answer. Are there some reserved variable names in function arguments ? Yes, unfortunately each keyword is reserved and cannot be used as symbol (variable, argument, protocol, table, ... name). 's' is keyword used for seconds in some time interval options. -- Damien Clabaut R vRouter ovh.qc.ca
Re: Unexpected behavior of static routes
On 2017-05-10 13:16, Ondrej Zajicek wrote: But such design would bring plenty of issues w.r.t. multiple routing tables - may next hops resolve just in the same routing table or also in another routing table? Well, at least in Linux device/direct routes may exist in any table, so where is the difference between device/direct routes and arbitrary next-hop route? How I would implement this: - Try to find if next-hop is routable via any of existing devices (including explicitly routed networks - as in my case); - If it is routable (which also means that device has to be up), install it (so it can be exported to the kernel tables). What if the device route is available, but not exported to kernel? You mean if it is configured but not exported? Then it should be ignored, obviously, though this could happen only in few cases: - device does not exists (yet) - device is not up (kernel will not accept any routes in this case) - protocol is disabled If no kernel export is configured at all then the route does not make any sense anyway. Static onlink routes is something that probably could be implemented and it is a good idea. This could solve one of the most typical scenarios - keep static (local) routes up for specified set of devices/gateways - once they become available. What is interesting, quagga behaves exactly in the same way as bird, and only cisco (well, may be other routers too) does what is (logically) expected - and it allows Linux-like onlink routes, which specify both device and gateway address, and those routes are linked to device state (i.e. exported and used when device is active). --- Best regards, Alexander.
Shell script to monitor BGP sessions thought NRPE
Hi, I didn’t find any script to be executed on the router to monitor BGP sessions on https://gitlab.labs.nic.cz/labs/bird/wikis/Related so I wrote my own: https://www.swordarmor.fr/monitoring-des-sessions-bgp-de-bird-via-nrpe.html The explanations are in french, mainly because I’m french and lazy, but the comments inside the script are in english, so feel free to share an modify it :) -- alarig signature.asc Description: PGP signature
Re: Unexpected behavior of static routes
On 2017-05-10 03:01, Ondrej Zajicek wrote:
It is expected behavior. It is not optimal, but it is how it works.
Is it limitation by design or just "not implemented"?
If you have a recursive route that is resolved to a device route,
then the original gateway is kept.
Yes, indeed, this works (to my surprise), though it starts to produce
"Received route with strange next-hop" errors on every scan (harmless,
but too noisy and incorrect - there is nothing "strange" with that
next-hop).
It does not look clean though - while it works, it looks not "natural"
in configuration ("recursive" instead of "via").
Would it not be an option to implement "onlink" static routes,
i.e. including both device and gateway addresses, or there are arguments
against this?
If you do not want to assign a real address to the iface,
then you could use ptp address like:
This is even less clean, to be honest.
---
With best regards,
Alexander.
