- Bird-users - Mailing Lists

Overloading RTR to load IRR (Was: Defines for mixed IPv6/IPv4)
by Job Snijders 25 Jan '24

25 Jan '24

On Thu, Jan 25, 2024 at 11:13:51AM +0100, Jeroen Massar via Bird-users wrote: > a quick stab at generating the slurm file: why use SLURM though? SLURM doesn't have a 'maxLength' field like the regular JSON input formatted in this style has: https://console.rpki-client.org/rpki.json - which might help with aggregation. More importantly, a risk I perceive with overloading RTR functionality to load IRR data into routers is in the realm of fail-safes: For RPKI-derived data, most ISPs do something along the lines of: if (roa_check(rpki, net, bgp_path.last) = ROA_INVALID) then reject; For IRR-derived data, you'd have to do: if (roa_check(irr, net, peerasn) != ROA_VALID) then reject; The above means that suddenly your EBGP routers/route servers have a very hard dependency on the IRR RTR session being up in order to accept routes (fail closed), whereas how the RPKI-derived data is used is in a 'fail open' fashion. The above friction goes back to RPKI ROAs being defined as "if ROAs exist, all BGP routes that do not match any of the ROAs are invalid" (following the RFC 6811 algorithm), but for IRR route/route6 objects such a definition was never established, those predate the RFC 6811 algorithm. Kind regards, Job

4 9

Defines for mixed IPv6/IPv4
by Nico Schottelius 25 Jan '24

25 Jan '24

Hello bird users, I am wondering how you handle matching both IPv6 and IPv4 prefixes efficiently. We have tons of blocks in our config like these: define net_genauso_v6 = [ 2a0a:5480::/29+ ]; define net_genauso_v4 = [ 185.203.113.0/24, 185.116.114.0/24 ]; And then later we have a function that combines them like this: function is_genauso() -> bool { if ((net ~ net_genauso_v6) || (net ~ net_genauso_v4)) then { return true; } return false; } And then much later, we have various filters utilising the function, the most simple one being: filter genauso { if(is_genauso()) then accept; reject; } Which is then used in both IPv4 & IPv6 channels: protocol bgp incoming_r2ge { ... ipv6 { import filter genauso; export none; }; ipv4 { import filter genauso; export none; extended next hop on; }; } Instead of writing a wrapper function for each peer/constellation, it would be great if we could do something like that: define net_genauso = [ 2a0a:5480::/29+, 185.203.113.0/24, 185.116.114.0/24 ]; ... filter genauso { if(net ~ net_genauso) then accept; reject; } ... However as of bird 2.14, this results in the following error: bridge:~nico# bird -f -c ./bird.conf bird: ./bird.conf:208:23 Mixed IPv4/IPv6 prefixes in prefix set. So my question is, how do you usually match on the two families? Do you also write a wrapper function like above? Or do you have a smarter way? BR, Nico -- Sustainable and modern Infrastructures by ungleich.ch

6 8

BIRD at CSNOG and NANOG
by Maria Matejka 24 Jan '24

24 Jan '24

Dear BIRD Users, during the next week, you may expect our presence at CSNOG in Zlin, Czechia, where also Ondrej Zajicek is going to present about upcoming EVPN and MPLS capabilities of BIRD. This talk is expected to be in Czech. I'm also going to attend NANOG 90 in Charlotte, NC, USA; if you wish to meet me there, just catch me … or send me an e-mail in advance to arrange a meeting. Please note that we probably aren't attending NANOG 91 in Kansas City in person. See you in Zlin or in Charlotte! Maria -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

5 6

Re: Bug in bfd implementation: Wrong TTL on bfd control packets (was: Re: BFD sessions with FFR (VyOS) won't establish)
by Alexander Zubkov 20 Jan '24

20 Jan '24

Hi Lukas, Actually I saw support for TTL security in BFD code: https://gitlab.nic.cz/labs/bird/-/blob/master/proto/bfd/packets.c#L496 And I see in your config example that you use multihop BFD, but RFC you refer is talking about single-hop BFD usage. So it does not seem like a bug here. Maybe the other side does not consider this BFD sessions multihop and thus applying the TTL security policy? Regards, Alexander On Sat, Jan 20, 2024 at 11:18 AM Lukas Haase <lukashaase(a)gmx.at> wrote: > > Hi, > > After long debugging I finally figured out why Bird's bfd cannot establish a session with FRR (VyOS): Packets are sent with TTL 64. However, according to https://datatracker.ietf.org/doc/rfc5881/, Section 5: "If BFD authentication is not in use on a session, all BFD Control packets for the session MUST be sent with a Time to Live (TTL) or Hop Limit value of 255". > > This is the reason why FRR just drops packets received from bird and the session never establishes. > > As a quick workaround, I could get it working with: > > sysctl -w net.ipv4.ip_default_ttl="255" > > However, bird should set TTL appropriately. > > Is this something that was missed or is there an setting I am missing? > > Thanks, > Luke > > > > > > > Gesendet: Mittwoch, 17. Januar 2024 um 01:24 Uhr > > Von: "Lukas Haase via Bird-users" <bird-users(a)network.cz> > > An: "Alexander Zubkov" <green(a)qrator.net> > > Cc: bird-users(a)network.cz > > Betreff: Re: BFD sessions with FFR (VyOS) won't establish > > > > Hi Alexander, > > > > Thanks. I have tried > > > > sysctl -w net.ipv4.ip_local_port_range="49152 65535" > > > > but unfortunately no change. > > What I do not understand is that Interval and Timeout is wrong on the non-working peer: > > > > # birdc show bfd sess > > BIRD 2.0.8 ready. > > bfd1: > > IP address Interface State Since Interval Timeout > > 172.20.215.130 --- Up 2024-01-16 0.100 0.500 > > 172.20.215.131 --- Init 2024-01-16 1.000 10.000 > > > > Do these parameters need to be identical among peers, similar as with OSPF? Note, they are identical to my knowledge but could there be any implicit setting that causes discrepancy between the peers and would cause a connection being stuck in "Up"? For example, in bird I have "idle tx interval 500 ms" but I could not find a corresponding option in VyOS/FFR. > > > > Could you think of any tcpdump/netcat debug? > > > > Thanks, > > Luke > > > > > > > > > Gesendet: Mittwoch, 17. Januar 2024 um 00:35 Uhr > > > Von: "Alexander Zubkov" <green(a)qrator.net> > > > An: "Lukas Haase" <lukashaase(a)gmx.at> > > > Cc: bird-users(a)network.cz > > > Betreff: Re: BFD sessions with FFR (VyOS) won't establish > > > > > > Hi, > > > > > > There were reports here in the list that some BFD peers do not allow > > > connections from non-standard ports and bird do not choose source port > > > specifically. So you might need to tune your sysctl like that: > > > > > > net.ipv4.ip_local_port_range = 49152 65535 > > > > > > Not sure if this is the case, but I would try that first. > > > > > > Regards, > > > Alexander > > > > > > On Tue, Jan 16, 2024 at 9:15 AM Lukas Haase via Bird-users > > > <bird-users(a)network.cz> wrote: > > > > > > > > Hello, > > > > > > > > My BFD session between bird work fine but the ones but the ones to VyOS (which uses FFR) just won't connect: > > > > > > > > # birdc show bfd sess > > > > BIRD 2.0.8 ready. > > > > bfd1: > > > > IP address Interface State Since Interval Timeout > > > > 172.20.215.131 --- Init 10:39:14.183 1.000 10.000 > > > > 172.20.215.130 --- Up 10:42:03.901 0.100 0.500 > > > > > > > > 172.20.215.131 is here a VyOS box and its FFR config looks like: > > > > > > > > ! > > > > bfd > > > > peer 172.20.215.129 multihop local-address 172.20.215.131 > > > > detect-multiplier 10 > > > > transmit-interval 100 > > > > receive-interval 100 > > > > exit > > > > ! > > > > exit > > > > ! > > > > end > > > > > > > > > > > > For reference, my bird config is trivially: > > > > > > > > protocol bfd > > > > { > > > > interface "local-ibgp" { > > > > min rx interval 100 ms; > > > > min tx interval 100 ms; > > > > idle tx interval 500 ms; > > > > multiplier 10; > > > > }; > > > > neighbor 172.20.215.130 local 172.20.215.129 multihop; > > > > neighbor 172.20.215.131 local 172.20.215.129 multihop; > > > > } > > > > > > > > > > > > I have turned off firewall. What else could go wrong? > > > > > > > > > > > > Thanks, > > > > Luke > > > > > > >

2 1

Dynamic routing for wireguard tunnels
by Julian Zielke 20 Jan '24

20 Jan '24

Hi, I have an issue with two machines connected via GRE exchanging routes via OSPF. Both server have wireguard tunnels to the same external endpoints, so a request from an endpoint may come in through tunnel 1 to server A, forwarded to wan and the reply may enter through server B and tunnel 2 back to the endpoint. All routes are exported to a custom kernel routing table by bird2. For example: * Server A’s wireguard network is: 10.100.0.0/24 * GRE IP of server A is 10.0.1.1 * GRE IP of server B is 10.0.1.2 The problem I’m facing is, that bird2 respects the local interface route of server A but on server B, while the wireguard interface also having the same subnet (10.100.0.0/24), bird2 adds a route which says the nexthop for this subnet is through 10.0.1.1 (the GRE tunnel). I only managed to solve this by excluding the wireguard subnet with an export filter. What I am expecting (or actually want) is bird respecting the local interface route on both servers and only, if a tunnel goes offline (no peer connected), changes the route through the GRE tunnel. I’m not sure, whether a part of this solution can be done solely by using bird. I know that wireguard tunnels do not have states, so post-up/post-down stuff is out of the question. Any solutions?

1 0

BFD sessions with FFR (VyOS) won't establish
by Lukas Haase 17 Jan '24

17 Jan '24

Hello, My BFD session between bird work fine but the ones but the ones to VyOS (which uses FFR) just won't connect: # birdc show bfd sess BIRD 2.0.8 ready. bfd1: IP address Interface State Since Interval Timeout 172.20.215.131 --- Init 10:39:14.183 1.000 10.000 172.20.215.130 --- Up 10:42:03.901 0.100 0.500 172.20.215.131 is here a VyOS box and its FFR config looks like: ! bfd peer 172.20.215.129 multihop local-address 172.20.215.131 detect-multiplier 10 transmit-interval 100 receive-interval 100 exit ! exit ! end For reference, my bird config is trivially: protocol bfd { interface "local-ibgp" { min rx interval 100 ms; min tx interval 100 ms; idle tx interval 500 ms; multiplier 10; }; neighbor 172.20.215.130 local 172.20.215.129 multihop; neighbor 172.20.215.131 local 172.20.215.129 multihop; } I have turned off firewall. What else could go wrong? Thanks, Luke

2 2

Version numbers
by Ray Bellis 15 Jan '24

15 Jan '24

Hi BIRD folks! Could you please consider using consistent semantic versioning in your release numbers? (see semver.org) Up until 2.13 all releases used the x.y.z format, with a trailing .0 for the first release in each minor release. However the the 2.13 and 2.14 releases did not - they just used x.y This broke our deployment code that uses semantic version aware checks to tell whether the running daemon is not the same as the available package. A formally adopted (and documented) version numbering policy would be of great use to system administrators. thanks, Ray

4 3

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