<div dir="ltr">Thanks a lot for the explanations!<br>Put like that, things make more sense.<br><br>On restructuring the configuration methodology.<br>Here in my head, separating things and being able to reload only those small separate things makes a lot of sense.<br>But it's become clear that clearing the way for SMP will inevitably clear the way for these other things.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em ter., 28 de mar. de 2023 às 09:24, Maria Matejka <<a href="mailto:maria.matejka@nic.cz">maria.matejka@nic.cz</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
> From simple things like adding a route, updating a prefix-list...<br>
> Even with things like adding a new peer.<br>
> [...]<br>
> This is certainly not a simple thing to address.<br>
> But it is a pain that attacks several scenarios.<br>
> <br>
> I'm sure the developers have already had deep conversations about this, <br>
> and that SMP has a higher priority.<br>
<br>
Well, SMP has a higher priority at least in cases where the changes <br>
collide – we've already stumbled over several merging hells and the <br>
faster SMP gets its stable version, the faster is the other development <br>
as well.<br>
<br>
> But could you just mention what possibilities were considered to resolve <br>
> this issue?<br>
<br>
Mostly there are thoughts about creating a "temporary" static protocol <br>
by a CLI command in some or other way. The discussion mostly hits the <br>
questions of "classical" reconfiguration – the same way as the <br>
enable-disable problem with other protocols, for which there are even <br>
some outstanding patches.<br>
<br>
There are also ongoing discussions on completely changing the config <br>
structure, allowing for back-writing the actual config and being able to <br>
maka all the changes persistent.<br>
<br>
Another colliding topic is the client API; there is a future possibility <br>
of just opening a socket and feeding routes directly, yet also not <br>
exactly specified or well-planned now.<br>
<br>
In all cases, the main question isn't how to add the routes. That's the <br>
simple part. What it is all about, is when and how to safely delete them <br>
with no memory leaks, no use-after-free and no performance penalty on <br>
the hotpath. And that is surprisingly hard to model correctly.<br>
<br>
In fact, most of the time I spent on SMP went exactly to this – how to <br>
safely clean everything up in the right order without impeding <br>
performance badly. And still I'm opening more and more cans of worms.<br>
<br>
After SMP gets stable, our positions on this should clarify a lot as <br>
there are some specific ways how to do stuff inside SMP BIRD <br>
thread-safely and all the other ways just fail badly. Until then, the <br>
dynamic route insertion is just a well concealed footgun.<br>
<br>
Thank you for your understanding.<br>
<br>
Maria<br>
<br>
<br>
> Em ter., 28 de mar. de 2023 às 04:01, Maria Matejka via Bird-users <br>
> <<a href="mailto:bird-users@network.cz" target="_blank">bird-users@network.cz</a> <mailto:<a href="mailto:bird-users@network.cz" target="_blank">bird-users@network.cz</a>>> escreveu:<br>
> <br>
> Hello!<br>
> <br>
> Yes, you shall run "birdc conf" yourself when your conffile is<br>
> ready. What if BIRD started the autoreconfig right when you're<br>
> writing the file? You could easily get strange behavior like<br>
> accidentally removing a bunch of protocols by loading a partial<br>
> config file. You'd have to assure atomic exchange of the file – and<br>
> this way, you may just run the reconfigure command explicitly anyway.<br>
> <br>
> There are some internal drafts on how to dynamically add routes<br>
> without having to reload possibly large config files, yet we haven't<br>
> decided on any approach yet, let aside actually implementing it.<br>
> <br>
> Maria<br>
> <br>
> On 28 March 2023 00:55:04 CEST, "Pedro Henrique de Araújo Marques"<br>
> <<a href="mailto:pedroam27@hotmail.com" target="_blank">pedroam27@hotmail.com</a> <mailto:<a href="mailto:pedroam27@hotmail.com" target="_blank">pedroam27@hotmail.com</a>>> wrote:<br>
> <br>
> Good evening, I'm doing some tests with BIRD for a while now and<br>
> I would like some help with a problem I'm facing. I have the<br>
> following BIRD configuration:<br>
> <br>
> *router id 10.0.0.128;*<br>
> *<br>
> *<br>
> *ipv4 table master4;*<br>
> *ipv6 table master6;*<br>
> *flow4 table flowtab4;*<br>
> *flow6 table flowtab6;*<br>
> *<br>
> *<br>
> *filter subnet_group1{*<br>
> * if(bgp_community.len = 0) then {*<br>
> * bgp_community.add((555,555));*<br>
> * accept;*<br>
> * }*<br>
> * else{ accept; }*<br>
> *<br>
> *<br>
> *};*<br>
> *<br>
> *<br>
> *protocol bgp uplink1{*<br>
> * local as 129;*<br>
> * neighbor 10.0.1.128 as 128;*<br>
> * multihop 1;*<br>
> * ipv4{*<br>
> * import filter { accept; };*<br>
> * export filter subnet_group1;*<br>
> * };*<br>
> * ipv6{*<br>
> * import filter { accept; };*<br>
> * export filter subnet_group1;*<br>
> * };*<br>
> *};*<br>
> *<br>
> *<br>
> *protocol static blackhole_ipv4_routes{*<br>
> * route <a href="http://10.0.90.100/32" rel="noreferrer" target="_blank">10.0.90.100/32</a> <<a href="http://10.0.90.100/32" rel="noreferrer" target="_blank">http://10.0.90.100/32</a>> blackhole;*<br>
> * route <a href="http://10.0.90.99/32" rel="noreferrer" target="_blank">10.0.90.99/32</a> <<a href="http://10.0.90.99/32" rel="noreferrer" target="_blank">http://10.0.90.99/32</a>> blackhole;*<br>
> * ipv4;*<br>
> *};*<br>
> <br>
> I created a script that after some time it inserts some new<br>
> routes into the blackhole_ipv4_routes protocol defined above,<br>
> let's say all of <a href="http://10.0.0.0/24" rel="noreferrer" target="_blank">10.0.0.0/24</a> <<a href="http://10.0.0.0/24" rel="noreferrer" target="_blank">http://10.0.0.0/24</a>> for example.<br>
> Is there an option that I could use in the config file to detect<br>
> this change and update bird accordingly with the new table<br>
> additions, or do I need to always call 'birdc -configure' after<br>
> the script ends?<br>
> <br>
> <br>
> <br>
> -- <br>
> Douglas Fernando Fischer<br>
> Engº de Controle e Automação<br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Douglas Fernando Fischer<br>Engº de Controle e Automação<br><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;color:black;text-align:left;line-height:130%;font-family:"courier new",monospace"></div></div></div>