January 2024 - Bird-users

Re: Re: Exporting a larger prefix if a smaller prefix is being exported
by Alexander Zubkov 15 Jan '24

15 Jan '24

On Mon, Jan 15, 2024, 10:15 Lukas Haase <lukashaase(a)gmx.at> wrote: > Hi Alexander, > > Thank you so much! > Debian has bird2 package as well so I migrated and indeed it works!! > There must be a bug in bird1 that causes recursive routes in static > protocol not to resolve... > As just a minor change to your solution, I changed the export filter in > the bgp protocol to: > > if(net ~ [192.0.2.0/24{24,32} <http://192.0.2.0/24%7B24,32%7D>]) then > accept; > > because I actually want to export the sub prefixes AND the /24. > Sure, if you need those. It is slightly out of scope of the topic, so I did not included them in my filter. :) BTW ”x.x.x.x/24{24,32}” id equivalent to ”x.x.x.x/24+”. > Sorry, there is just one last thing: Currently I define my /24 like this: > > protocol static static_bgp > { > ipv4; > route 192.0.2.0/24 via Public-Ip-As-Seen-By-Peer; > } > > How do I make sure that whatever route is sent has the public IP as > next-hop? Since I am using recursive now, I do not have control over it. > Will this be set automatically to what I set as "source address" in the > bgp peer definition? > Or should I explicitely add "next hop self"? Or should I explicitly modify > "bgp_next_hop = ..." in the export filter of the bgp peer? > You can check the docs for the defaults. "next hop self" might be the default for eBGP, but I do not remember exactly. You can set it explicitly also. And yes, you can either use this option or override the next hop in the effort filter. > Thanks, > Luke > > > Gesendet: Montag, 15. Januar 2024 um 00:11 Uhr > > Von: "Alexander Zubkov" <green(a)qrator.net> > > An: "Lukas Haase" <lukashaase(a)gmx.at> > > Cc: bird-users(a)network.cz > > Betreff: Re: Exporting a larger prefix if a smaller prefix is being > exported > > > > Hi, > > > > I cannot tell for bird1, unfortunately. It might not work there at > > all. Here is working example for bird2, I tested it and it seems > > valid. I export smaller routes to a separate table, so that static > > protocol use only those routes for recursive resolution, otherwise it > > will also try to use default route and itself too. I also put static > > routes to a separate table and pipe from it and filtering out the > > unreachable ones. Because otherwise an unreachable route could be > > selected the best (they all have the same metric) and not exported to > > bgp. So check for unreachable in bgp export does not work well > > actually, if there are more than one static route to choose from. > > For bird1 please note, that it is announced EOL already. And it is > > highly recommended to migrate to bird2. > > > > ipv4 table aggr_src; > > ipv4 table aggr; > > > > protocol bgp test > > { > > local as 64512; > > source address 10.55.55.251; > > ipv4 { > > import none; > > export filter { > > if(net = 192.0.2.0/24) then accept; > > reject; > > }; > > }; > > neighbor 10.55.55.250 as 65534; > > password "xyz"; > > multihop 2; > > } > > > > protocol static prefix_aggregation > > { > > ipv4 { table aggr; }; > > igp table aggr_src; > > route 192.0.2.0/24 recursive 192.0.2.207; > > route 192.0.2.0/24 recursive 192.0.2.208; > > route 192.0.2.0/24 recursive 192.0.2.209; > > } > > > > protocol device {} > > protocol direct { ipv4; } > > > > protocol pipe pipe_aggr_src > > { > > table master4; > > peer table aggr_src; > > export filter { > > if (net ~ [192.0.2.0/24{25,32} > <http://192.0.2.0/24%7B25,32%7D>]) then accept; > > reject; > > }; > > import none; > > } > > > > protocol pipe pipe_aggr > > { > > table master4; > > peer table aggr; > > export none; > > import where dest != RTD_UNREACHABLE; > > > > } > > > > On Mon, Jan 15, 2024 at 8:59 AM Lukas Haase <lukashaase(a)gmx.at> wrote: > > > > > > Hi Alexander > > > > > > > Gesendet: Sonntag, 14. Januar 2024 um 23:03 Uhr > > > > Von: "Alexander Zubkov" <green(a)qrator.net> > > > > An: "Lukas Haase" <lukashaase(a)gmx.at> > > > > Cc: bird-users(a)network.cz > > > > Betreff: Re: Re: Exporting a larger prefix if a smaller prefix is > being exported > > > > > > > > Hi Lukas, > > > > > > > > Two questions. > > > > You add dummy interface on another node that propagates it via ospf > to > > > > your border? > > > > > > I do not, it's added locally. Same machine as bird is running. I just > need > > > > > > interface "dum0" { stub yes; }; > > > > > > to bring it into bird's routing table. I could also use protocol > "direct" but to simulate it as close as possible to my actual use case > (where the possible smaller prefixes will come over OSPF) I wanted to use > OSPF. > > > > > > But in my understanding, it shouldn't matter where the route comes > from. > > > > > > > And the most important one - you use bird version 1? > > > > > > Yes, it's the version included in Debian/Ubuntu stable. As long as I > am not hitting a huge roadblock I'd really like to keep it. > > > > > > Thanks, > > > Luke > > > > > > > On Mon, Jan 15, 2024 at 6:23 AM Lukas Haase <lukashaase(a)gmx.at> > wrote: > > > > > > > > > > Hi Alexander, > > > > > > > > > > Thank you again, this is really promising and I think I get the > gist of it. > > > > > I have just one issue left: The /24 prefix keeps showing as > unreachable. > > > > > > > > > > I have set up a test peer (both sides) to verify that routes come > through. > > > > > > > > > > Here is my config: > > > > > > > > > > protocol bgp test > > > > > { > > > > > local as 64512; > > > > > source address 10.55.55.251; > > > > > import none; > > > > > export filter { > > > > > # announce all of our sub-prefixes > > > > > if(net ~ [192.0.2.0/24{25,32} > <http://192.0.2.0/24%7B25,32%7D>]) then accept; > > > > > > > > > > # if at least one of them is reachable, announce > the entire /24 > > > > > if(net = 192.0.2.0/24 && dest != RTD_UNREACHABLE) > then accept; > > > > > > > > > > reject; > > > > > }; > > > > > neighbor 10.55.55.250 as 65534; > > > > > password "xyz"; > > > > > multihop 2; > > > > > } > > > > > > > > > > protocol static prefix_aggregation > > > > > { > > > > > route 192.0.2.0/24 recursive 192.0.2.0; > > > > > route 192.0.2.0/24 recursive 192.0.2.1; > > > > > route 192.0.2.0/24 recursive 192.0.2.2; > > > > > route 192.0.2.0/24 recursive 192.0.2.3; > > > > > route 192.0.2.0/24 recursive 192.0.2.4; > > > > > route 192.0.2.0/24 recursive 192.0.2.5; > > > > > route 192.0.2.0/24 recursive 192.0.2.6; > > > > > route 192.0.2.0/24 recursive 192.0.2.7; > > > > > route 192.0.2.0/24 recursive 192.0.2.8; > > > > > route 192.0.2.0/24 recursive 192.0.2.9; > > > > > route 192.0.2.0/24 recursive 192.0.2.10; > > > > > route 192.0.2.0/24 recursive 192.0.2.11; > > > > > route 192.0.2.0/24 recursive 192.0.2.12; > > > > > route 192.0.2.0/24 recursive 192.0.2.13; > > > > > route 192.0.2.0/24 recursive 192.0.2.14; > > > > > route 192.0.2.0/24 recursive 192.0.2.15; > > > > > route 192.0.2.0/24 recursive 192.0.2.16; > > > > > route 192.0.2.0/24 recursive 192.0.2.17; > > > > > route 192.0.2.0/24 recursive 192.0.2.18; > > > > > route 192.0.2.0/24 recursive 192.0.2.19; > > > > > route 192.0.2.0/24 recursive 192.0.2.20; > > > > > route 192.0.2.0/24 recursive 192.0.2.21; > > > > > route 192.0.2.0/24 recursive 192.0.2.22; > > > > > route 192.0.2.0/24 recursive 192.0.2.23; > > > > > route 192.0.2.0/24 recursive 192.0.2.24; > > > > > route 192.0.2.0/24 recursive 192.0.2.25; > > > > > route 192.0.2.0/24 recursive 192.0.2.26; > > > > > route 192.0.2.0/24 recursive 192.0.2.27; > > > > > route 192.0.2.0/24 recursive 192.0.2.28; > > > > > route 192.0.2.0/24 recursive 192.0.2.29; > > > > > route 192.0.2.0/24 recursive 192.0.2.30; > > > > > route 192.0.2.0/24 recursive 192.0.2.31; > > > > > route 192.0.2.0/24 recursive 192.0.2.32; > > > > > route 192.0.2.0/24 recursive 192.0.2.33; > > > > > route 192.0.2.0/24 recursive 192.0.2.34; > > > > > route 192.0.2.0/24 recursive 192.0.2.35; > > > > > route 192.0.2.0/24 recursive 192.0.2.36; > > > > > route 192.0.2.0/24 recursive 192.0.2.37; > > > > > route 192.0.2.0/24 recursive 192.0.2.38; > > > > > route 192.0.2.0/24 recursive 192.0.2.39; > > > > > route 192.0.2.0/24 recursive 192.0.2.40; > > > > > route 192.0.2.0/24 recursive 192.0.2.41; > > > > > route 192.0.2.0/24 recursive 192.0.2.42; > > > > > route 192.0.2.0/24 recursive 192.0.2.43; > > > > > route 192.0.2.0/24 recursive 192.0.2.44; > > > > > route 192.0.2.0/24 recursive 192.0.2.45; > > > > > route 192.0.2.0/24 recursive 192.0.2.46; > > > > > route 192.0.2.0/24 recursive 192.0.2.47; > > > > > route 192.0.2.0/24 recursive 192.0.2.48; > > > > > route 192.0.2.0/24 recursive 192.0.2.49; > > > > > route 192.0.2.0/24 recursive 192.0.2.50; > > > > > route 192.0.2.0/24 recursive 192.0.2.51; > > > > > route 192.0.2.0/24 recursive 192.0.2.52; > > > > > route 192.0.2.0/24 recursive 192.0.2.53; > > > > > route 192.0.2.0/24 recursive 192.0.2.54; > > > > > route 192.0.2.0/24 recursive 192.0.2.55; > > > > > route 192.0.2.0/24 recursive 192.0.2.56; > > > > > route 192.0.2.0/24 recursive 192.0.2.57; > > > > > route 192.0.2.0/24 recursive 192.0.2.58; > > > > > route 192.0.2.0/24 recursive 192.0.2.59; > > > > > route 192.0.2.0/24 recursive 192.0.2.60; > > > > > route 192.0.2.0/24 recursive 192.0.2.61; > > > > > route 192.0.2.0/24 recursive 192.0.2.62; > > > > > route 192.0.2.0/24 recursive 192.0.2.63; > > > > > route 192.0.2.0/24 recursive 192.0.2.64; > > > > > route 192.0.2.0/24 recursive 192.0.2.65; > > > > > route 192.0.2.0/24 recursive 192.0.2.66; > > > > > route 192.0.2.0/24 recursive 192.0.2.67; > > > > > route 192.0.2.0/24 recursive 192.0.2.68; > > > > > route 192.0.2.0/24 recursive 192.0.2.69; > > > > > route 192.0.2.0/24 recursive 192.0.2.70; > > > > > route 192.0.2.0/24 recursive 192.0.2.71; > > > > > route 192.0.2.0/24 recursive 192.0.2.72; > > > > > route 192.0.2.0/24 recursive 192.0.2.73; > > > > > route 192.0.2.0/24 recursive 192.0.2.74; > > > > > route 192.0.2.0/24 recursive 192.0.2.75; > > > > > route 192.0.2.0/24 recursive 192.0.2.76; > > > > > route 192.0.2.0/24 recursive 192.0.2.77; > > > > > route 192.0.2.0/24 recursive 192.0.2.78; > > > > > route 192.0.2.0/24 recursive 192.0.2.79; > > > > > route 192.0.2.0/24 recursive 192.0.2.80; > > > > > route 192.0.2.0/24 recursive 192.0.2.81; > > > > > route 192.0.2.0/24 recursive 192.0.2.82; > > > > > route 192.0.2.0/24 recursive 192.0.2.83; > > > > > route 192.0.2.0/24 recursive 192.0.2.84; > > > > > route 192.0.2.0/24 recursive 192.0.2.85; > > > > > route 192.0.2.0/24 recursive 192.0.2.86; > > > > > route 192.0.2.0/24 recursive 192.0.2.87; > > > > > route 192.0.2.0/24 recursive 192.0.2.88; > > > > > route 192.0.2.0/24 recursive 192.0.2.89; > > > > > route 192.0.2.0/24 recursive 192.0.2.90; > > > > > route 192.0.2.0/24 recursive 192.0.2.91; > > > > > route 192.0.2.0/24 recursive 192.0.2.92; > > > > > route 192.0.2.0/24 recursive 192.0.2.93; > > > > > route 192.0.2.0/24 recursive 192.0.2.94; > > > > > route 192.0.2.0/24 recursive 192.0.2.95; > > > > > route 192.0.2.0/24 recursive 192.0.2.96; > > > > > route 192.0.2.0/24 recursive 192.0.2.97; > > > > > route 192.0.2.0/24 recursive 192.0.2.98; > > > > > route 192.0.2.0/24 recursive 192.0.2.99; > > > > > route 192.0.2.0/24 recursive 192.0.2.100; > > > > > route 192.0.2.0/24 recursive 192.0.2.101; > > > > > route 192.0.2.0/24 recursive 192.0.2.102; > > > > > route 192.0.2.0/24 recursive 192.0.2.103; > > > > > route 192.0.2.0/24 recursive 192.0.2.104; > > > > > route 192.0.2.0/24 recursive 192.0.2.105; > > > > > route 192.0.2.0/24 recursive 192.0.2.106; > > > > > route 192.0.2.0/24 recursive 192.0.2.107; > > > > > route 192.0.2.0/24 recursive 192.0.2.108; > > > > > route 192.0.2.0/24 recursive 192.0.2.109; > > > > > route 192.0.2.0/24 recursive 192.0.2.110; > > > > > route 192.0.2.0/24 recursive 192.0.2.111; > > > > > route 192.0.2.0/24 recursive 192.0.2.112; > > > > > route 192.0.2.0/24 recursive 192.0.2.113; > > > > > route 192.0.2.0/24 recursive 192.0.2.114; > > > > > route 192.0.2.0/24 recursive 192.0.2.115; > > > > > route 192.0.2.0/24 recursive 192.0.2.116; > > > > > route 192.0.2.0/24 recursive 192.0.2.117; > > > > > route 192.0.2.0/24 recursive 192.0.2.118; > > > > > route 192.0.2.0/24 recursive 192.0.2.119; > > > > > route 192.0.2.0/24 recursive 192.0.2.120; > > > > > route 192.0.2.0/24 recursive 192.0.2.121; > > > > > route 192.0.2.0/24 recursive 192.0.2.122; > > > > > route 192.0.2.0/24 recursive 192.0.2.123; > > > > > route 192.0.2.0/24 recursive 192.0.2.124; > > > > > route 192.0.2.0/24 recursive 192.0.2.125; > > > > > route 192.0.2.0/24 recursive 192.0.2.126; > > > > > route 192.0.2.0/24 recursive 192.0.2.127; > > > > > route 192.0.2.0/24 recursive 192.0.2.128; > > > > > route 192.0.2.0/24 recursive 192.0.2.129; > > > > > route 192.0.2.0/24 recursive 192.0.2.130; > > > > > route 192.0.2.0/24 recursive 192.0.2.131; > > > > > route 192.0.2.0/24 recursive 192.0.2.132; > > > > > route 192.0.2.0/24 recursive 192.0.2.133; > > > > > route 192.0.2.0/24 recursive 192.0.2.134; > > > > > route 192.0.2.0/24 recursive 192.0.2.135; > > > > > route 192.0.2.0/24 recursive 192.0.2.136; > > > > > route 192.0.2.0/24 recursive 192.0.2.137; > > > > > route 192.0.2.0/24 recursive 192.0.2.138; > > > > > route 192.0.2.0/24 recursive 192.0.2.139; > > > > > route 192.0.2.0/24 recursive 192.0.2.140; > > > > > route 192.0.2.0/24 recursive 192.0.2.141; > > > > > route 192.0.2.0/24 recursive 192.0.2.142; > > > > > route 192.0.2.0/24 recursive 192.0.2.143; > > > > > route 192.0.2.0/24 recursive 192.0.2.144; > > > > > route 192.0.2.0/24 recursive 192.0.2.145; > > > > > route 192.0.2.0/24 recursive 192.0.2.146; > > > > > route 192.0.2.0/24 recursive 192.0.2.147; > > > > > route 192.0.2.0/24 recursive 192.0.2.148; > > > > > route 192.0.2.0/24 recursive 192.0.2.149; > > > > > route 192.0.2.0/24 recursive 192.0.2.150; > > > > > route 192.0.2.0/24 recursive 192.0.2.151; > > > > > route 192.0.2.0/24 recursive 192.0.2.152; > > > > > route 192.0.2.0/24 recursive 192.0.2.153; > > > > > route 192.0.2.0/24 recursive 192.0.2.154; > > > > > route 192.0.2.0/24 recursive 192.0.2.155; > > > > > route 192.0.2.0/24 recursive 192.0.2.156; > > > > > route 192.0.2.0/24 recursive 192.0.2.157; > > > > > route 192.0.2.0/24 recursive 192.0.2.158; > > > > > route 192.0.2.0/24 recursive 192.0.2.159; > > > > > route 192.0.2.0/24 recursive 192.0.2.160; > > > > > route 192.0.2.0/24 recursive 192.0.2.161; > > > > > route 192.0.2.0/24 recursive 192.0.2.162; > > > > > route 192.0.2.0/24 recursive 192.0.2.163; > > > > > route 192.0.2.0/24 recursive 192.0.2.164; > > > > > route 192.0.2.0/24 recursive 192.0.2.165; > > > > > route 192.0.2.0/24 recursive 192.0.2.166; > > > > > route 192.0.2.0/24 recursive 192.0.2.167; > > > > > route 192.0.2.0/24 recursive 192.0.2.168; > > > > > route 192.0.2.0/24 recursive 192.0.2.169; > > > > > route 192.0.2.0/24 recursive 192.0.2.170; > > > > > route 192.0.2.0/24 recursive 192.0.2.171; > > > > > route 192.0.2.0/24 recursive 192.0.2.172; > > > > > route 192.0.2.0/24 recursive 192.0.2.173; > > > > > route 192.0.2.0/24 recursive 192.0.2.174; > > > > > route 192.0.2.0/24 recursive 192.0.2.175; > > > > > route 192.0.2.0/24 recursive 192.0.2.176; > > > > > route 192.0.2.0/24 recursive 192.0.2.177; > > > > > route 192.0.2.0/24 recursive 192.0.2.178; > > > > > route 192.0.2.0/24 recursive 192.0.2.179; > > > > > route 192.0.2.0/24 recursive 192.0.2.180; > > > > > route 192.0.2.0/24 recursive 192.0.2.181; > > > > > route 192.0.2.0/24 recursive 192.0.2.182; > > > > > route 192.0.2.0/24 recursive 192.0.2.183; > > > > > route 192.0.2.0/24 recursive 192.0.2.184; > > > > > route 192.0.2.0/24 recursive 192.0.2.185; > > > > > route 192.0.2.0/24 recursive 192.0.2.186; > > > > > route 192.0.2.0/24 recursive 192.0.2.187; > > > > > route 192.0.2.0/24 recursive 192.0.2.188; > > > > > route 192.0.2.0/24 recursive 192.0.2.189; > > > > > route 192.0.2.0/24 recursive 192.0.2.190; > > > > > route 192.0.2.0/24 recursive 192.0.2.191; > > > > > route 192.0.2.0/24 recursive 192.0.2.192; > > > > > route 192.0.2.0/24 recursive 192.0.2.193; > > > > > route 192.0.2.0/24 recursive 192.0.2.194; > > > > > route 192.0.2.0/24 recursive 192.0.2.195; > > > > > route 192.0.2.0/24 recursive 192.0.2.196; > > > > > route 192.0.2.0/24 recursive 192.0.2.197; > > > > > route 192.0.2.0/24 recursive 192.0.2.198; > > > > > route 192.0.2.0/24 recursive 192.0.2.199; > > > > > route 192.0.2.0/24 recursive 192.0.2.200; > > > > > route 192.0.2.0/24 recursive 192.0.2.201; > > > > > route 192.0.2.0/24 recursive 192.0.2.202; > > > > > route 192.0.2.0/24 recursive 192.0.2.203; > > > > > route 192.0.2.0/24 recursive 192.0.2.204; > > > > > route 192.0.2.0/24 recursive 192.0.2.205; > > > > > route 192.0.2.0/24 recursive 192.0.2.206; > > > > > route 192.0.2.0/24 recursive 192.0.2.207; > > > > > route 192.0.2.0/24 recursive 192.0.2.208; > > > > > route 192.0.2.0/24 recursive 192.0.2.209; # <-- this one should > be reachable > > > > > route 192.0.2.0/24 recursive 192.0.2.210; > > > > > route 192.0.2.0/24 recursive 192.0.2.211; > > > > > route 192.0.2.0/24 recursive 192.0.2.212; > > > > > route 192.0.2.0/24 recursive 192.0.2.213; > > > > > route 192.0.2.0/24 recursive 192.0.2.214; > > > > > route 192.0.2.0/24 recursive 192.0.2.215; > > > > > route 192.0.2.0/24 recursive 192.0.2.216; > > > > > route 192.0.2.0/24 recursive 192.0.2.217; > > > > > route 192.0.2.0/24 recursive 192.0.2.218; > > > > > route 192.0.2.0/24 recursive 192.0.2.219; > > > > > route 192.0.2.0/24 recursive 192.0.2.220; > > > > > route 192.0.2.0/24 recursive 192.0.2.221; > > > > > route 192.0.2.0/24 recursive 192.0.2.222; > > > > > route 192.0.2.0/24 recursive 192.0.2.223; > > > > > route 192.0.2.0/24 recursive 192.0.2.224; > > > > > route 192.0.2.0/24 recursive 192.0.2.225; > > > > > route 192.0.2.0/24 recursive 192.0.2.226; > > > > > route 192.0.2.0/24 recursive 192.0.2.227; > > > > > route 192.0.2.0/24 recursive 192.0.2.228; > > > > > route 192.0.2.0/24 recursive 192.0.2.229; > > > > > route 192.0.2.0/24 recursive 192.0.2.230; > > > > > route 192.0.2.0/24 recursive 192.0.2.231; > > > > > route 192.0.2.0/24 recursive 192.0.2.232; > > > > > route 192.0.2.0/24 recursive 192.0.2.233; > > > > > route 192.0.2.0/24 recursive 192.0.2.234; > > > > > route 192.0.2.0/24 recursive 192.0.2.235; > > > > > route 192.0.2.0/24 recursive 192.0.2.236; > > > > > route 192.0.2.0/24 recursive 192.0.2.237; > > > > > route 192.0.2.0/24 recursive 192.0.2.238; > > > > > route 192.0.2.0/24 recursive 192.0.2.239; > > > > > route 192.0.2.0/24 recursive 192.0.2.240; > > > > > route 192.0.2.0/24 recursive 192.0.2.241; > > > > > route 192.0.2.0/24 recursive 192.0.2.242; > > > > > route 192.0.2.0/24 recursive 192.0.2.243; > > > > > route 192.0.2.0/24 recursive 192.0.2.244; > > > > > route 192.0.2.0/24 recursive 192.0.2.245; > > > > > route 192.0.2.0/24 recursive 192.0.2.246; > > > > > route 192.0.2.0/24 recursive 192.0.2.247; > > > > > route 192.0.2.0/24 recursive 192.0.2.248; > > > > > route 192.0.2.0/24 recursive 192.0.2.249; > > > > > route 192.0.2.0/24 recursive 192.0.2.250; > > > > > route 192.0.2.0/24 recursive 192.0.2.251; > > > > > route 192.0.2.0/24 recursive 192.0.2.252; > > > > > route 192.0.2.0/24 recursive 192.0.2.253; > > > > > route 192.0.2.0/24 recursive 192.0.2.254; > > > > > route 192.0.2.0/24 recursive 192.0.2.255; > > > > > } > > > > > > > > > > I then set up a dummy device (and add it to OSPF so that it lands > in birds routing table): > > > > > > > > > > # ip link add dum0 type dummy > > > > > # ip addr add 192.0.2.209/28 dev dum0 > > > > > # ip link set dev dum0 up > > > > > # ping -c1 192.0.2.209 > > > > > PING 192.0.2.209 (192.0.2.209) 56(84) bytes of data. > > > > > 64 bytes from 192.0.2.209: icmp_seq=1 ttl=64 time=0.022 ms > > > > > > > > > > --- 192.0.2.209 ping statistics --- > > > > > 1 packets transmitted, 1 received, 0% packet loss, time 0ms > > > > > rtt min/avg/max/mdev = 0.022/0.022/0.022/0.000 ms > > > > > > > > > > But then: > > > > > > > > > > # birdc show route | grep '^192\.0\.2\.' > > > > > 192.0.2.208/28 dev dum0 [ospf 04:57:58] * I (150/10) > [14x.xxx.223.80] > > > > > 192.0.2.0/24 unreachable [prefix_aggregation 04:57:57] * > (200) > > > > > # > > > > > > > > > > The 192.0.2.208/28 shows up in the routing table, so it IS > reachable and hence at least one of the 192.0.2.0/24 route entries much > be reachable. Yet, 192.0.2.0/24 shows up as unreachable. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > Luke > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gesendet: Sonntag, 14. Januar 2024 um 00:24 Uhr > > > > > > Von: "Alexander Zubkov" <green(a)qrator.net> > > > > > > An: "Lukas Haase" <lukashaase(a)gmx.at> > > > > > > Cc: bird-users(a)network.cz > > > > > > Betreff: Re: Exporting a larger prefix if a smaller prefix is > being exported > > > > > > > > > > > > Hi Lukas, > > > > > > > > > > > > On Sun, Jan 14, 2024 at 6:23 AM Lukas Haase <lukashaase(a)gmx.at> > wrote: > > > > > > > > > > > > > > Hi Alex, > > > > > > > > > > > > > > > Gesendet: Samstag, 13. Januar 2024 um 06:31 Uhr > > > > > > > > Von: "Alexander Zubkov" <green(a)qrator.net> > > > > > > > > An: "Lukas Haase" <lukashaase(a)gmx.at> > > > > > > > > Cc: bird-users(a)network.cz > > > > > > > > Betreff: Re: Exporting a larger prefix if a smaller prefix > is being exported > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > You cannot do "direct" prefix aggregation to a lager prefix > in Bird > > > > > > > > yet. But there are some ways to workaround it. You can > define a static > > > > > > > > route with recursive nex-hop like 192.0.2.x, and filter it > out when it > > > > > > > > is not reachable, but for any subprefix in /24 you would > need to > > > > > > > > define 256 of such static routes. So it is up to you how > practical it > > > > > > > > is. > > > > > > > > > > > > > > Interesting idea, this would be practical for me but I do not > completely understand yet what you mean. > > > > > > > Which routes would I define and what would be the next hop > ("like 192.0.2.x")? > > > > > > > > > > > > > > As an example, suppose the following prefixes are in my > routing table and are directly or indirectly reachable: 192.0.2.208/28, > 192.0.2.250/31, 192.0.2.184/29, 192.0.2.254/31, 192.0.2.176/29. > > > > > > > > > > > > > > Are you proposing? > > > > > > > > > > > > > > protocol static prefix_aggregation > > > > > > > { > > > > > > > route 192.0.2.0/24 via 192.0.2.209; > > > > > > > route 192.0.2.0/24 via 192.0.2.250; > > > > > > > route 192.0.2.0/24 via 192.0.2.285; > > > > > > > route 192.0.2.0/24 via 192.0.2.254; > > > > > > > route 192.0.2.0/24 via 192.0.2.177; > > > > > > > } > > > > > > > > > > > > Yes, something like that. But it needs to be "recursive" not > "via". > > > > > > And your routes need not to be recursive already (for example > iBGP > > > > > > makes such routes by default), because double recursion won't > work. > > > > > > > > > > > > > > > > > > > > If so, how do I avoid that 192.0.2.0/24 will be exported five > times? > > > > > > > > > > > > Yes, you'll have multiple similar routes. But if you do not have > > > > > > add-path on your BGP session, only one of them will be exported. > Also > > > > > > in the recent version there is some aggregation support of > same-net > > > > > > prefixes, it can be helpful here too. > > > > > > > > > > > > > And how do I set up an export filter on "next-hop is not > reachable"? > > > > > > > > > > > > You need to check the corresponding attribute of the prefix. See > the > > > > > > example later. > > > > > > > > > > > > > > > > > > > > By the way, the sub-prefixes, would I just export via a filter > like this? > > > > > > > > > > > > Yes, this filter seems to cover the sub-prefixes. But not sure > what is > > > > > > the nature of this question. > > > > > > > > > > > > > > > > > > > > export filter { > > > > > > > if (net ~ [192.0.2.0/24{25,32} > <http://192.0.2.0/24%7B25,32%7D>]) then { > > > > > > > accept; > > > > > > > } > > > > > > > reject; > > > > > > > } > > > > > > > > > > > > > > > > > > > Here is a config example I can imagine, not tested it at all. > > > > > > Something like that works for us. But I would test it first that > it > > > > > > correctly adds/reverts the "aggregated" prefix. It adds static > > > > > > prefixes in a separate table, but it can also be done in the main > > > > > > table and reachability tested in bgp export filter for example. > > > > > > > > > > > > > > > > > > ipv4 table aggr; > > > > > > > > > > > > protocol static prefix_aggregation > > > > > > { > > > > > > ipv4 { table aggr4; }; > > > > > > route 192.0.2.0/24 recursive 192.0.2.209; > > > > > > ... > > > > > > } > > > > > > > > > > > > protocol pipe pipe_aggr > > > > > > { > > > > > > table master4; > > > > > > peer table aggr; > > > > > > export filter { > > > > > > if (net ~ [192.0.2.0/24{25,32} > <http://192.0.2.0/24%7B25,32%7D>]) then { > > > > > > accept; > > > > > > } > > > > > > reject; > > > > > > }; > > > > > > import filter { > > > > > > if dest = RTD_UNREACHABLE then reject; > > > > > > if (net = 192.0.2.0/24) then accept; > > > > > > reject; > > > > > > }; > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > Luke > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You can also make some external daemon watching your kernel > routes > > > > > > > > and adding/deleting the aggregate route to the table. > > > > > > > > > > > > > > > > Regards, > > > > > > > > Alexander > > > > > > > > > > > > > > > > On Sat, Jan 13, 2024 at 2:05 AM Lukas Haase via Bird-users > > > > > > > > <bird-users(a)network.cz> wrote: > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > Is is somehow possible to export a larger prefix if one or > more sub-prefixes (subnets) are exported ... but also remove that prefix if > no smaller subnet exist any more? > > > > > > > > > > > > > > > > > > Example: As soon as 192.0.2.44/32 or 192.0.2.208/28 (or > any other prefix inside 192.0.2.0/24) is exported via eBGP, also export > prefix 192.0.2.0/24. If no sub-prefixes are left, also remove 192.0.2.0/24 > from export. > > > > > > > > > > > > > > > > > > Background for my question is BGP. As is well known, the > smallest prefix I can announce over eBGP is /24. I use bird as a border > gateway and I announce various smaller prefixes via iBGP. The smaller > prefixes will take precedence in my peering neighboring AS but the /24 is > required to announce my network farther out. > > > > > > > > > > > > > > > > > > But why would I want that? Because there are actually two > border gateways. If all internal links to one of these gateways breaks, the > full subnet should not be announced any more (otherwise the traffic would > be dropped). If at least one subnet is announced, I assume that the > internal mesh is strong enough to find its way. > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Luke > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

1 0

Exporting a larger prefix if a smaller prefix is being exported
by Lukas Haase 15 Jan '24

15 Jan '24

Hi, Is is somehow possible to export a larger prefix if one or more sub-prefixes (subnets) are exported ... but also remove that prefix if no smaller subnet exist any more? Example: As soon as 192.0.2.44/32 or 192.0.2.208/28 (or any other prefix inside 192.0.2.0/24) is exported via eBGP, also export prefix 192.0.2.0/24. If no sub-prefixes are left, also remove 192.0.2.0/24 from export. Background for my question is BGP. As is well known, the smallest prefix I can announce over eBGP is /24. I use bird as a border gateway and I announce various smaller prefixes via iBGP. The smaller prefixes will take precedence in my peering neighboring AS but the /24 is required to announce my network farther out. But why would I want that? Because there are actually two border gateways. If all internal links to one of these gateways breaks, the full subnet should not be announced any more (otherwise the traffic would be dropped). If at least one subnet is announced, I assume that the internal mesh is strong enough to find its way. Thanks, Luke

3 8

BGP Peering shuts down with "add paths tx;"
by Tim Weippert 14 Jan '24

14 Jan '24

Hi All, i try to activate "add paths tx;" from my Bird2 (2.0.12) Routeserver to a Cisco IOS-XR Systems (7.9.2), after i add the config on Bird side, the IOS-XR shuts down the peering: %ROUTING-BGP-3-MALFORM_UPDATE : Malformed UPDATE message received from neighbor <IPV6-RR> (VRF: INTERNET) - message length 160 bytes, error flags 0x00000008, action taken "Reset". Error details: "Error 0x00000008, Field "MP_REACH-NLRI", Attribute 14 (Flags 0x00, Length 0), Data [6d]". NLRIs: [IPv4 Unicast] %ROUTING-BGP-5-ADJCHANGE : neighbor <IPV6-RR> Down - BGP Notification sent, illegal network (VRF: INTERNET) (AS: 65000) %ROUTING-BGP-3-MALFORM_UPDATE : Malformed UPDATE message received from neighbor <IPV6-RR> (VRF: INTERNET) - message length 160 bytes, error flags 0x00000008, action taken "Reset". Error details: "Error 0x00000008, Field "MP_REACH-NLRI", Attribute 14 (Flags 0x00, Length 0), Data [6d]". NLRIs: [IPv4 Unicast] %ROUTING-BGP-5-NBR_NSR_DISABLED_STANDBY : NSR disabled on neighbor <IPV6-RR> on standby RP due to BGP Notification sent (VRF: INTERNET) %ROUTING-BGP-5-ADJCHANGE : neighbor <IPV4-RR> Down - BGP Notification sent, illegal network (VRF: INTERNET) (AS: 65000) I found some hints on the following bug id from cisco: https://bst.cisco.com/quickview/bug/CSCvy23472 There it states: --- Under add-path send/receive enable scenario, when IOS-XR BGP received update message whose path-id is missed in NLRI, BGP think this message to be malformed and reset this BGP session. This behavior is expected behavior. --- Does this means, that bird doesn't add the path-id as expected? Is there some known caveouts around? Same configuration on BGP Peerings to Cisco IOS-XE are working fine and accept the additional paths. Thanks, tim -- Tim Weippert http://weiti.org - weiti(a)weiti.org GPG Fingerprint - E704 7303 6FF0 8393 ADB1 398E 67F2 94AE 5995 7DD8

2 2

Re: Exporting a larger prefix if a smaller prefix is being exported
by Maria Matejka 13 Jan '24

13 Jan '24

Sorry, sent this off-list by mistake. Maria On 13 January 2024 18:11:07 CET, Maria Matejka <maria.matejka(a)nic.cz> wrote: >Hello! > >This will be possible in version 3, maybe not fully automatic in the first stable versions. There is some code (indirectly) enabling this, waiting for some finishing touches amd merging. You may expect to have an opportunity to test it with the next alpha version of BIRD 3. > >With BIRD 2, to some extent it may be also possible directly with the upcoming prefix aggregation feature. Not yet available now. > >Maria > >On 13 January 2024 01:56:50 CET, Lukas Haase via Bird-users <bird-users(a)network.cz> wrote: >>Hi, >> >>Is is somehow possible to export a larger prefix if one or more sub-prefixes (subnets) are exported ... but also remove that prefix if no smaller subnet exist any more? >> >>Example: As soon as 192.0.2.44/32 or 192.0.2.208/28 (or any other prefix inside 192.0.2.0/24) is exported via eBGP, also export prefix 192.0.2.0/24. If no sub-prefixes are left, also remove 192.0.2.0/24 from export. >> >>Background for my question is BGP. As is well known, the smallest prefix I can announce over eBGP is /24. I use bird as a border gateway and I announce various smaller prefixes via iBGP. The smaller prefixes will take precedence in my peering neighboring AS but the /24 is required to announce my network farther out. >> >>But why would I want that? Because there are actually two border gateways. If all internal links to one of these gateways breaks, the full subnet should not be announced any more (otherwise the traffic would be dropped). If at least one subnet is announced, I assume that the internal mesh is strong enough to find its way. >> >> >>Thanks, >>Luke >> >> > >-- >Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o. -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

1 0

bird 2.14 as docker image
by Nico Schottelius 13 Jan '24

13 Jan '24

Hello bird users, this is a short announcement that bird-2.14 is now available in a docker container on https://hub.docker.com/r/ungleich/bird/tags . As usual the image is based on the latest Alpine Linux version, this time 3.19. Attached you find the latest Dockerfile in case you want to rebuild it yourself. Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch

1 0

Direct vs kernel 'learn all'
by Chris Webb 11 Jan '24

11 Jan '24

Very happy long-term bird user here - thanks for a great routing daemon! In the changelog for 2.14, I noticed https://gitlab.nic.cz/labs/bird/-/commit/e83beb70bd14923cece5b35411606ade6f… which introduces 'learn all' for the kernel protocol, allowing device routes to be imported as with the direct protocol. Is there any reason/situation to prefer either the direct protocol or 'learn all' on the v4/v6 kernel protocol? If not, is your intention that direct be retired in favour of kernel 'learn all' eventually? Many thanks, Chris.

2 2

Inject default route via OSPF, but only to specific OSPF peer and contingent on BGP session established
by Lukas Haase 11 Jan '24

11 Jan '24

Hi, I have two "border gateways"; each establishes a BGP session to the outside world. An internal router connects to each of the border gateways and uses OSPF to exchange routes. (Note, other OSPF links may exist as well). Both border gateways act as default gateways for the internal router. In order to create redundancy, each border gateway should send the default route via OSPF to the internal router. However, the default route should not be sent to any other device (otherwise it would mess up everything, incl tunnels). Additionally, injecting the default route should be contingent on having the BGP session established successfully (only then I can assume the route to the internet is good). This is my current bird.conf (most relevant parts): protocol bgp vultr { local as xxx; source address xxx; import none; export filter { if(proto = "static_bgp") then { accept; }; }; graceful restart on; multihop 2; neighbor xx yy; password "xxxx"; }; protocol static static_bgp { route 192.0.2.0/24 via xxxx; }; protocol ospf internal { import all; export none; area 0.0.0.0 { interface "wg-introuter" { cost 100;hello 10;retransmit 5;wait 5;dead 40; type broadcast; authentication cryptographic; password "xxx" { id 1; }; }; }; }; Thanks, Luke

3 3

bird and on-interface p2p routes
by Eugene M. Zheganin 11 Jan '24

11 Jan '24

Hello, youm this question was asked like a gazillion times, but so far I faled to google the answer. So, I have a network softrouter on Linux which was clearly written by some ignorant folks; it operates the p2p tunX interface that doesn't have the remote IP set, only a local one. So bird does complain about "strange next-hop" when walking through the kernel routing table and seeing the local/self address as a gateway. Still, this is partially valid setup, because the hosts this softrouter injects into the kernel RT are reachable via p2p interface directly. I can declare these as a static routes reachable via tunX, but this setup lacks the automation (I will had to refresh thhe routes manually). So, my though is like this: is it possible to convert these from "strange next-hop" routes to this ===Cut=== 10.24.123.0/21 unicast [direct1 2023-12-07] * (200) dev tun0 ===Cut=== via the export filter ? I tried the following approach but it seems like I'm missing something: ===Cut=== filter exportkernelv4 { if ifname = "tun0" then { print "attempting to change route attributes: ifname ", ifname, ", gw: ", gw, ", dest: ", dest; onlink = true; #unset(gw); } accept; }; protocol kernel { learn; persist; scan time 20; ipv4 { import all; export filter exportkernelv4; }; } ===Cut=== What am I missing ? Seems like for some reason I just cannot merey unsert the gw attribute. Thanks. Eugene.

3 6

ripng on sit tunnel interface
by Ivan 11 Jan '24

11 Jan '24

Hello. I am using bird 1.6 on Linux. If I run the ripng protocol on the sit tunnel interface, until an IPv6 LinkLocal address is assigned to the interface, the ripng protocol does not start (does not receive or send messages). Even if a static unicast IPv6 address is assigned to the sit interface. Example configuration: protocol rip rip_v6 { ecmp no; interface "sit-r1"{ mode multicast; version only yes; metric 1; }; export filter x; import filter y; } Linux interface: sit-r1@eno1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1480 state UNKNOWN qlen 1000 inet6 2001:db8::2/124 scope global valid_lft forever preferred_lft forever Can ripng in bird 1.6 implementation use an interface with static unicast address but without LinkLocal ? Thank you.

2 1

How to inject default route only to specific peer contingent on BGP session
by Lukas Haase 09 Jan '24

09 Jan '24

Hi, I have two "border gateways" running bird; each establishes a BGP session to the outside world. An internal router connects to each of the border gateways and uses OSPF to exchange routes. (Note, other OSPF links may exist as well). Both border gateways act as default gateways for the internal router. In order to create redundancy, each border gateway should send the default route via OSPF to the internal router. However, the default route should not be sent to any other device (otherwise it would mess up everything, incl tunnels). Additionally, injecting the default route should be contingent on having the BGP session established successfully (only then I can assume the route to the internet is good). This is my current bird.conf (most relevant parts): protocol bgp vultr { local as xxx; source address xxx; import none; export filter { if(proto = "static_bgp") then { accept; }; }; graceful restart on; multihop 2; neighbor xx yy; password "xxxx"; }; protocol static static_bgp { route 192.0.2.0/24 via xxxx; }; protocol ospf internal { import all; export none; area 0.0.0.0 { interface "wg-introuter" { cost 100;hello 10;retransmit 5;wait 5;dead 40; type broadcast; authentication cryptographic; password "xxx" { id 1; }; }; }; }; Thanks, Luke

1 0