Do you have some ideas then?
De : Bird-users <bird-users-boun...@network.cz> de la part de Maxime Peim
(mpeim) via Bird-users <bird-users@network.cz>
Date : lundi, 26 mai 2025 à 22:30
À : Yakimus // Netassist NOC <yaki...@netassist.ua>
Cc : bird-users@network.cz <bird-users@network.cz>
Objet : Re: BIRD performance in a dynamic scenario
Sure !
Configuration example:
```
ipv4 table table_1;
protocol bgp {
local 10.0.0.1 as 65000 ;
neighbor range 0.0.0.0/0 internal
dynamic name "peer_";
dynamic name digits 4;
router id 10.0.0.1;
strict bind;
ipv4 {
table table_1;
import filter import_policy_filter;
export all;
next hop address 10.0.0.1;
};
}
function get_community_from_peer_address(ip addr) -> pair {
case addr {
10.0.1.1: (1,1) ;
10.0.2.1: (245, 12434) ;
…
else : (0, 0) ;
}
}
Filter import_policy_filter {
pair comm = get_community_from_peer_address(from);
bgp_community.add(comm);
}
```
I want to modify the route attributes based on the peer, but from a dynamic
neighborship.
You could argue that could just add a new `bgp` protocol with the correct
neighbor address and filter but I work on a porject where we don’t about all
the peers in advance and adding/removing multiple bgp/static/l3vpn protocols
for each peers tends to slow down the process of configuration reloading. Hence
I found a solution of having those functions with switch cases which allow me
to do minimal changes in the configuration file. However, I found it a bit
hacky and wanted your view on that.
De : Yakimus // Netassist NOC <yaki...@netassist.ua>
Date : lundi, 26 mai 2025 à 22:15
À : Maxime Peim (mpeim) <mp...@cisco.com>
Cc : bird-users@network.cz <bird-users@network.cz>
Objet : Re: BIRD performance in a dynamic scenario
Please clarify how do you describe the configuration for your dynamic peers?
--
Mykola Yakymenko
NETassist
On Mon, May 26, 2025 at 06:40:33PM +0000, Maxime Peim (mpeim) wrote:
> Any idea if there is a way for dynamic neighbours?
>
> De : Bird-users <bird-users-boun...@network.cz> de la part de Maxime Peim
> (mpeim) via Bird-users <bird-users@network.cz>
> Date : mercredi, 21 mai 2025 à 14:32
> À : Yakimus // Netassist NOC <yaki...@netassist.ua>
> Cc : bird-users@network.cz <bird-users@network.cz>
> Objet : Re: BIRD performance in a dynamic scenario
> Indeed, if you know the peer in advance, right ?
> What about dynamic neighbor ?
>
> De : Yakimus // Netassist NOC <yaki...@netassist.ua>
> Date : mardi, 20 mai 2025 à 15:56
> À : Maxime Peim (mpeim) <mp...@cisco.com>
> Cc : bird-users@network.cz <bird-users@network.cz>
> Objet : Re: BIRD performance in a dynamic scenario
> Hello!
>
> You can add the comunity directly in the inbound filters of the peer
>
> --
> Mykola Yakymenko
> NETassist
>
> On Tue, May 20, 2025 at 07:43:28AM +0000, Maxime Peim (mpeim) via Bird-users
> wrote:
> > Hi everyone,
> >
> > First of all, thanks a lot for BIRD !
> >
> > I have some questions about the dynamicity of BIRD wiht BGP.
> > In a scenario where routes needs to be updated accondingly depending on
> > some external informations, I find out that those informations would need
> > to be written into the BIRD configuration file.
> >
> > As an example, if we need to add a bgp community based on the peer address
> > (already known), we would need something like that :
> >
> > ```bird
> > function get_community_from_peer_address(ip addr) -> pair {
> > case addr {
> > <addr1> : (1,1) ;
> > <addr2> : (245, 12434) ;
> > …
> > else : (0, 0) ;
> > }
> > }
> > ```
> >
> > And we could update that function if needed in the future but the
> > configuration will need to be parsed each time.
> > If the rate of update is high, it can become a bootleneck.
> >
> > So I would like to know if I am going the right direction doing that way ?
> > Is there a plan for a direct API to BIRD internals instead of passing a
> > configuration file ?
> >
> > Thanks in advance for your answer,
> > Maxime Peim
> >
