Hi, I'm having my bird6 nearly up and running, and just stumbled across the following minor crash. I have a filter defined like this: filter bgp_in_AS1853x104 prefix set allnet; { if ! defined (bgp_med) then bgp_med = 0; if ! (avoid_martians()) then reject; if ! (bgp_path ~ [= 1853 * =]) then reject; if ! (net ~ allnet) then { bgp_community.add((1121,1)); } accept; } You see that I compare allnet to the current net, but allnet isn't set anywhere (due to my forgetfulness). Having this filter in place crashes bird upon the first received route. This is of course rather a human error, and I just wanted to tell the Ondrej's in case they want to fix this bug. I personally don't care if they do, I guess there are more ways of a broken configuration to break bird :) Wolfgang, all excited about his working bird6. -- www.vix.at | www.aco.net wh@univie.ac.at | WH844-RIPE Vienna University Computer Center
On 18.03.2010 15:25 Wolfgang Hennerbichler wrote
I'm having my bird6 nearly up and running, and just stumbled across the following minor crash.
just curious ... what is a _minor_ crash? Sounds like a little bit pregnant ;-) SCNR, Arnold btw: why don't you make your filter a function? You only would have to define it once and use it several times? But perhaps I'm not getting the whole picture ... -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333
On Mar 18, 2010, at 21:03 , Arnold Nipper wrote:
On 18.03.2010 15:25 Wolfgang Hennerbichler wrote
I'm having my bird6 nearly up and running, and just stumbled across the following minor crash.
just curious ... what is a _minor_ crash? Sounds like a little bit pregnant ;-)
heh :) a minor crash in my little world is a crash that is caused by a stupid user, not a gifted software developer.
SCNR, Arnold btw: why don't you make your filter a function? You only would have to define it once and use it several times? But perhaps I'm not getting the whole picture ...
yeah, there's more to that than just the part you've seen. it also contains a set of ip adresses generated from the ripedb to mark them as 'good' routes, checks if the as-path is valid and so on...
-- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333
-- www.vix.at | www.aco.net wh@univie.ac.at | WH844-RIPE Vienna University Computer Center
On 19.03.2010 08:10 Wolfgang Hennerbichler wrote
... checks if the as-path is valid ...
you really do that? We only do something like case bgp_path.last { 13238: if pref_AS13238() then accept; 43247: if pref_AS43247() then accept; } where pref_ASyyyy() simply matches against all prefixes found in RADB for AS yyyyy. Best regards, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333
On Mar 19, 2010, at 08:47 , Arnold Nipper wrote:
On 19.03.2010 08:10 Wolfgang Hennerbichler wrote
... checks if the as-path is valid ...
you really do that? We only do something like
case bgp_path.last { 13238: if pref_AS13238() then accept; 43247: if pref_AS43247() then accept; }
we filter on prefixes, but we only mark them good or "not in RIPE". A customer can select in the webinterface if he would like to receive only good routes, all routes or he can do a per-peer selection. what I meant by checking the as-path was if the peer-as was in the as-path: if ! (bgp_path ~ [= 1120 * =]) then reject;
where pref_ASyyyy() simply matches against all prefixes found in RADB for AS yyyyy.
our members decided to not filter on RADB but RIPE and rather use the solution above instead of dropping prefixes. Out of curiosity: How often do you rebuild your filters, and if you do are you clearing the bgp sessions (in bird-speak reloading the protocols)?
Best regards, Arnold
cu soon, Wolfgang
-- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333
-- www.vix.at | www.aco.net wh@univie.ac.at | WH844-RIPE Vienna University Computer Center
On 19.03.2010 09:03 Wolfgang Hennerbichler wrote
On Mar 19, 2010, at 08:47 , Arnold Nipper wrote:
what I meant by checking the as-path was if the peer-as was in the as-path:
if ! (bgp_path ~ [= 1120 * =]) then reject;
ic ...
where pref_ASyyyy() simply matches against all prefixes found in RADB for AS yyyyy.
our members decided to not filter on RADB but RIPE and rather use the solution above instead of dropping prefixes.
afaik RIPE is a subset of what you get from RADB. I like RADB because of its features like being able to do whois -h whois.radb.net \!ias-telia,1 or whois -h whois.radb.net \!gas1299 for example. Piping to some sed and tr and you are done ;-)
Out of curiosity: How often do you rebuild your filters,
We did it only once the day, but current plans are to do it more often. Perhaps every 2h or so. Sebastian did not only work on Hoofprints but also spent some time on re-writing the filter generation software (incl. an aggregate6). Rebuilding the filters for ~370 AS-SETs now takes a little more than five minutes.
and if you do are you clearing the bgp sessions (in bird-speak reloading the protocols)?
good question :-) My impression was that "configure soft" should do the trick, but I'm not sure whether this really is true. Reloading the pipes for instance generates a mssive route update afais. That's definitely not what we want. I have even added "prefer older on;" to the bgp protocol section to make prefixes more stable across the IXP. Documentation says: Changes in filters usually lead to restart of affected protocols. If soft option is used, changes in filters does not cause BIRD to restart affected protocols, therefore already accepted routes (according to old filters) would be still propagated, but new routes would be processed according to the new filters. However with _our_ current model, we only filter between customer table and master table, accepting everything from customer side. From what I've seen (more precise: meant to have seen) applying new filters does not trigger importing routes to the master table. Another question: what exactly is reloading a table doing. Best regards, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333
On Fri, Mar 19, 2010 at 01:57:25PM +0100, Arnold Nipper wrote:
and if you do are you clearing the bgp sessions (in bird-speak reloading the protocols)?
good question :-) My impression was that "configure soft" should do the trick, but I'm not sure whether this really is true. Reloading the pipes for instance generates a mssive route update afais. That's definitely not what we want. I have even added "prefer older on;" to the bgp protocol section to make prefixes more stable across the IXP.
Essentially, you have three options what to do after a change in filters: 1) restart a protocol All routes from the protocol are withdrawn from the connected table and will appear later (after restart) If these routes are primary routes in that table, other protocols connected to that table receive two notifications (first about route disappear and later about route appear). 2) reload a protocol All routes are repropagated through the protocol If these repropagations does not change primary route in the connected tables, the event wouldn't be propagated tho other connected protocols. I will write more about it later. 3) do nothing (and have an inconsistent state of propagated routes) If you use 'configure soft' command, BIRD ignore changes in filters and in that case it does nothing. But it is expected that operator restarts or reloads affected protocols. The main reason for 'configure soft' is that BIRD can't decide whether the change in filters is important enough. For example if you found that you have a bug in common 'martians' filter function and you found that one BGP neighour sent you a martian route, then you update the common filter function but you know that you have to restart/reload just that one BGP neighbour. But if you use 'configure', BIRD decides to restart/reload all protocols that use the common filter function. For older (before 1.2.1) versions, 'configure' does not use protocol reload (just a restart [*]), so there was another reason for 'configure soft' (to choose reload instead of restart). [*] or reconfigure, which is used for OSPF and RIP and is unrelated to BGP or pipe.
Documentation says: Changes in filters usually lead to restart of affected protocols. If soft option is used, changes in filters does not cause BIRD to restart affected protocols, therefore already accepted routes (according to old filters) would be still propagated, but new routes would be processed according to the new filters.
However with _our_ current model, we only filter between customer table and master table, accepting everything from customer side. From what I've seen (more precise: meant to have seen) applying new filters does not trigger importing routes to the master table.
Another question: what exactly is reloading a table doing.
There is no such thing like reloading a table - we speak about reloading a protocol. As i wrote eariler, it is essencially repropagating routes through a protocol. There are two subcases - reload-in (used when import filter changes) and reload-out (used when export filter changes): reload-in for BGP protocol - BGP protocol sends route-refresh request and then the other side sends updates for all prefixes. reload-out for BGP protocol - BGP protocol sends updates for all prefixes in connected table (and accepted by export filter). reload-in/out for pipe protocol - all routes from one table are repropagated to the other table. This should not have direct impact on external behavior of route server (just causes some CPU load). In all cases that change a state of some routing table (reload-in for BGP and reload-in/out for a pipe), the repropagation of route might change primary route in that routing table and in that case the change is propagated to other protocols (and might cause sending updates for BGP protocols).
Reloading the pipes for instance generates a mssive route update afais.
That is strange, just reloading a pipe (if there is no real change in export/import) may cause some CPU load, but the primary routes should not change and therefore connected BGP protocols should not send any updates. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On 19.03.2010 15:02 Ondrej Zajicek wrote
On Fri, Mar 19, 2010 at 01:57:25PM +0100, Arnold Nipper wrote:
and if you do are you clearing the bgp sessions (in bird-speak reloading the protocols)?
good question :-) My impression was that "configure soft" should do the trick, but I'm not sure whether this really is true. Reloading the pipes for instance generates a mssive route update afais. That's definitely not what we want. I have even added "prefer older on;" to the bgp protocol section to make prefixes more stable across the IXP.
Essentially, you have three options what to do after a change in filters:
thank you for the detailled explanation. One final question: what does the timestamp attached to routes mean? Like show route 194.0.194.0/24 via 80.81.192.35 on eth0 [R192_35 2010-03-14 16:22:10] * (100) [AS42315?] TIA, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333
On 19.03.2010 15:02 Ondrej Zajicek wrote
reload-in/out for pipe protocol - all routes from one table are repropagated to the other table. This should not have direct impact on external behavior of route server (just causes some CPU load).
According to the documentation for pipe protocol there is no in/out: "Note that for the pipe protocol, both directions are always reloaded together (in or out options are ignored in that case)." Anyway, doing "configure soft" followed by reloading all pipes leads to re-installing every single route. That definitely is not what I want the routeserver to do. For now I guess I will live with "configure soft". According to our paradigmam that a route is only announced when added to a RIR DB well in advance, no inconsistency could show up. However I still would like to know what an optimal solution could look like. I.e. a solution also covering the corner cases. Best regards, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333
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@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333
-- www.vix.at | www.aco.net wh@univie.ac.at | WH844-RIPE Vienna University Computer Center
On 22.03.2010 07:32 Wolfgang Hennerbichler wrote
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,
I guess you mean prefix filters, not routes. Right?
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)
I guess you mean IRRToolSet, and I guess too that rpsltool is a NIH-tool, isn't it ;-) Otherwise: not sure, whether this approach is worth the effort. Best regards, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333
On Mar 22, 2010, at 09:26 , Arnold Nipper wrote:
On 22.03.2010 07:32 Wolfgang Hennerbichler wrote
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,
I guess you mean prefix filters, not routes. Right?
prefixes, pardon, it was way too early in the morning when I was answering :)
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)
I guess you mean IRRToolSet, and I guess too that rpsltool is a NIH-tool, isn't it ;-)
I don't know what NIH means, but you are correct that I meant the IRR-stuff. God, where was my brain this morning, haha.
Otherwise: not sure, whether this approach is worth the effort.
we designed it to work like this from scratch, so the effort in our case was a patch of the code that cost me one hour or so.
Best regards, Arnold
Wolfgang
-- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333
-- www.vix.at | www.aco.net wh@univie.ac.at | WH844-RIPE Vienna University Computer Center
On Sun, Mar 21, 2010 at 11:16:49PM +0100, Arnold Nipper wrote:
Anyway, doing "configure soft" followed by reloading all pipes leads to re-installing every single route. That definitely is not what I want the routeserver to do.
Re-installing means that these routes are sent as updates by BGP protocol to BGP neighbors? Such behavior is unexpected and is different that i see in my testing configuration. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On 22.03.2010 13:49 Ondrej Zajicek wrote
On Sun, Mar 21, 2010 at 11:16:49PM +0100, Arnold Nipper wrote:
Anyway, doing "configure soft" followed by reloading all pipes leads to re-installing every single route. That definitely is not what I want the routeserver to do.
Re-installing means that these routes are sent as updates by BGP protocol to BGP neighbors? Such behavior is unexpected and is different that i see in my testing configuration.
Re-installing means that every single route has gotten its timestamp updated. Both master table as well as each per peer table. From that I also conclude that these routes are are sent as updates by BGP protocol to BGP neighbors. Best regards, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333
On Mon, Mar 22, 2010 at 11:25:07PM +0100, Arnold Nipper wrote:
On 22.03.2010 13:49 Ondrej Zajicek wrote
On Sun, Mar 21, 2010 at 11:16:49PM +0100, Arnold Nipper wrote:
Anyway, doing "configure soft" followed by reloading all pipes leads to re-installing every single route. That definitely is not what I want the routeserver to do.
Re-installing means that these routes are sent as updates by BGP protocol to BGP neighbors? Such behavior is unexpected and is different that i see in my testing configuration.
Re-installing means that every single route has gotten its timestamp updated. Both master table as well as each per peer table. From that I also conclude that these routes are are sent as updates by BGP protocol to BGP neighbors.
No, the timestamp is updated, but the route is the same and therefore is not propagated to other protocols (BGP). You can check that using counters in BGP protocols. Perhaps the fact that timestamp is updated even in this case is misleading. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On 23.03.2010 08:26 Ondrej Zajicek wrote
No, the timestamp is updated, but the route is the same and therefore is not propagated to other protocols (BGP). You can check that using counters in BGP protocols. Perhaps the fact that timestamp is updated even in this case is misleading.
Definitely imho ... change request: don't do that :-) Best regards, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333
On Thu, Mar 18, 2010 at 03:25:09PM +0100, Wolfgang Hennerbichler wrote:
You see that I compare allnet to the current net, but allnet isn't set anywhere (due to my forgetfulness). Having this filter in place crashes bird upon the first received route. This is of course rather a human error, and I just wanted to tell the Ondrej's in case they want to fix this bug. I personally don't care if they do, I guess there are more ways of a broken configuration to break bird :)
Thank you for the note, we will fix this. Definitely, broken configuration should not crash BIRD. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (3)
-
Arnold Nipper -
Ondrej Zajicek -
Wolfgang Hennerbichler