- Bird-users - Mailing Lists

How to make OSPF routes not more important than "connected routes"
by Lukas Haase 13 Nov '21

13 Nov '21

Hello, This is probably fairly trivial but how can I tell bird (or Linux) that "connected routes" should have higher precedence than the routes from OSPF (even if they may be more specific)? I have the following issue: I have a bunch of connected routers, connected via /31 links. There is also a loop. Now a Mikrotik OSPF node sends me a route (that it can reach) for a station that's actually directly connected. Unfortunately the system takes the OSPF route. But of course, the directly connected interface route should always be preferred. Example: # birdc show ospf neigh BIRD 1.6.8 ready. edge1: Router ID Pri State DTime Interface Router IP 203.0.113.193 1 Full/PtP 00:36 gre1 203.0.113.255 203.0.113.194 1 Full/PtP 00:37 wg1 203.0.113.225 # birdc show route | grep '203.0.113.22\(4\|5\)' 203.0.113.224/32 dev wg1 [edge1 2021-11-12] * I (150/0) [192.168.164.183] 203.0.113.225/32 via 203.0.113.255 on gre1 [edge1 06:18:20] * I (150/110) [203.0.113.194] # ip route list | grep '203.0.113.22\(4\|5\)' 203.0.113.224/31 dev wg1 proto kernel scope link src 203.0.113.224 203.0.113.225 via 203.0.113.255 dev gre1 proto bird Here we can see that to reach 203.0.113.225 (my desired endpoint), there are two routes: 203.0.113.224/31 which is the "connected route" set up automatically by Linux when I create the interface. And "203.0.113.225 via 203.0.113.255" which I receive via OSPF from a Mikrotik router which can also see this node. Even if the OSPF one is more specific, of course, I want the local connected route to have preference. Thanks!

2 1

Bird 2.0.8 - Automatic RPKI reload behaviour
by Tiago Felipe Goncalves 05 Nov '21

05 Nov '21

Hello, I'm curious to understand how "Automatic channel reloads based on RPKI changes" works, as I've noticed that after I enabled RPKI reload, the daemon is constantly reloading the ingress policies/filters. I have set it up in the laboratory and observed that the ingress policies/filters are constantly re-processed even if the following: - We don't have RPKI RTR sessions flapping, being renegotiated, and/or changing state. - We don't have a refresh requested from/to the clients/neighbours BGP sessions. - We don't have BGP updates coming or going from/to BGP clients/neighbours at the moment that I see the ingress policy/filter being re-processed in bird2. - We don't have RPKI ROA update/changes for the specific prefix during this meantime. >From Bird doc: "BIRD offers crude automatic re-validating of affected routes after RPKI update, see option rpki reload. ... In contrast to to other filter operators, this status for the same route may change as the content of ROA tables changes. When this option is active, BIRD activates automatic reload of affected channels whenever ROA tables are updated (after a short settle time)." I sincerely expected that the automatic reload would be triggered after an event (RPKI RTR session flapping/changing state) or if the specific ROA changes (not any ROA changes). For small deployments, the extra load wouldn't be an issue, but I have deployments with 3k active clients/neighbours, and the extra load concerns me to use this function in production. The lab env is using as minimal configuration as possible, doing RPKI validation (one RTR session with routinator), and 2 clients/neighbours. I just added a "print" to ingress protocol filter to see each time that the daemon process it: Oct 26 07:21:19 bird_lab-01 bird: Reconfigured Oct 26 07:21:43 bird_lab-01 bird: Started Oct 26 07:21:48 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path 65002) Oct 26 07:21:48 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path 65003) Oct 26 07:26:43 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path 65002) Oct 26 07:26:43 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path 65003) Oct 26 07:47:21 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path 65002) Oct 26 07:47:21 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path 65003) Oct 26 08:07:52 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path 65002) Oct 26 08:07:52 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path 65003) Oct 26 08:20:39 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path 65002) Oct 26 08:20:39 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path 65003) Oct 26 08:43:35 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path 65002) Oct 26 08:43:35 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path 65003) Oct 26 09:04:07 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path 65002) Oct 26 09:04:07 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path 65003) Oct 26 09:26:56 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path 65002) Oct 26 09:26:56 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path 65003) Oct 26 09:47:28 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path 65002) Oct 26 09:47:28 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path 65003) Oct 26 10:08:00 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path 65002) Oct 26 10:08:00 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path 65003) Oct 26 10:28:36 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path 65002) Oct 26 10:28:36 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path 65003) Oct 26 10:51:29 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path 65002) Oct 26 10:51:29 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path 65003) ... bird> show proto Name Proto Table State Since Info device1 Device --- up 2021-10-26 07:21:43 kernel1 Kernel master4 up 2021-10-26 07:21:43 rpki1 RPKI --- up 2021-10-26 07:21:43 Established TEST BGP --- up 2021-10-26 07:21:47 Established TEST2 BGP --- up 2021-10-26 07:21:47 Established Configuration snippet(not production configuration): ... filter BGP_IN { RPKI_IPV4(65002); print "INGRESS FILTER => ", net, " => ", bgp_path; accept; } protocol bgp TEST from PEERS { neighbor 192.168.242.49 as 65002; ipv4 { import keep filtered on; import table yes; import filter BGP_IN; export all; next hop keep; }; } ... When/if I disable the automatic RPKI reload(comment out import table yes), this behaviour(constantly re-processing ingress filters) is gone. If possible, could you please help me to understand if this is the expected behaviour for the automatic RPKI reload? Thanks in advance! Best regards, Tiago Felipe Gonçalves PGP Fingerprint - A2:82:BD:48:EE:8D:C4:99:C2:4E:81:D4:C4:7B:1C:2E:C7:F3:04:C9

2 2

Configure BGP multihop with version 1.6.8 not working
by Wei Huang 04 Nov '21

04 Nov '21

I am testing with Bird 1.6.8 with the following setup Box 1 with interface VPP0 (192.168.1.6) ----------R--------Box 2 with interface VPP0 (192.168.2.6) Middle router R has IP address 192.168.1.1 and 192.168.2.1 The config for Box 1: table T0; # This pseudo-protocol watches all interface up/down events. protocol device { scan time 10; # Scan interfaces every 10 seconds } # Configure logging log "/home/talariuser/log/dynamic_routing.log" { debug, trace, info, remote, warning, error, auth, fatal, bug } ; router id 198.168.100.5; protocol static { table T0; check link; route 192.168.2.0/24 via 192.168.1.1; # Default route import all; export all; } protocol bgp bgp1 { table T0; import all; # Do not change this parameters without assistance gateway recursive; next hop self; local as 100; hold time 180; source address 192.168.1.6; default bgp_local_pref 100; igp metric on; neighbor 192.168.2.6 as 100; multihop 3; import all; export all; } protocol direct { table T0; interface "vpp0"; } Similar on box2. The BGP stay in connect state. When I try to do packet capture on interface "vpp0", I don't see any packets sent out. Anybody can point out what I did wrong in the config? Thanks in advance, Wei

1 0

unstable BGP sessions after debian 10 -> 11 upgrade
by Christoph 02 Nov '21

02 Nov '21

Hello, we upgraded our debian BGP routers from debian buster to bullseye. On debian 10 they used the repo https://bird.network.cz/debian/ now they use the bird2 package directly from the official debian repos, both repos contain BIRD version 2.0.7. After upgrading and rebooting we noticed that iBGP sessions are constantly dying every few minutes. The logs also show multiple of these log entries: <WARN> Kernel dropped some netlink messages, will resync on next scan. <WARN> Event ... took 31415 ms <WARN> I/O loop cycle took 31529 ms for 9 events <WARN> Netlink: File exists Especially the warning "Kernel dropped some netlink messages" was not new but we previously solved them with these sysctl.conf settings: # solves the "Kernel dropped some netlink messages, will resync on next scan." BIRD Warnings # https://bird.network.cz/pipermail/bird-users/2017-September/011542.html # (we did not change the wmem_default since this is apparently not needed) net.core.rmem_max=4194304 net.core.rmem_default=4194304 net.core.wmem_max=4194304 The most obvious change is the linux kernel version: 4.19.208 (buster) 5.10.70 (bullseye) To avoid constantly dying iBGP sessions we increased the keepalive and hold timers. Are you observing similar issues on your debian 11 systems? Does the newer kernel need higher rmem values? best regards, Christoph

3 3

BIRD 2.0 on FreeBSD, multihop with multiple fibs
by Elmar K. Bins 02 Nov '21

02 Nov '21

Hi everyone, I hope this is not too specific... I'm running into a bit of a pickle here. This is FreeBSD 12.2 with multi-fib enabled; BIRD exporting all its received routes to fib 1, basic kernel routing in fib 0. (The service on the box is in fib 1, of course). I need to configure a multihop session where the BGP partner is not on the same interface as the box's default, but on a pni, which is behind a VLAN-tagged subinterface (i.e., bge0.300) down on a switch somewhere. Also, I can only BGP connect to the partner via the PNI. The interface has no fib tags, so it "exists" in both fibs. Let's say we are bge0.300 5.6.7.7. The other side of the PNI is at 5.6.7.8. Our BGP partner is at 1.2.3.4, reachable through 5.6.7.8. protocol static { ipv4; route 1.2.3.4/32 via 5.6.7.8; } Now, netstat tells me that 1.2.3.4/32 shows up in fib 1, but not in fib 0. BIRD only puts it in fib 1. In this setup, BIRD does not connect to 1.2.3.4 unless I manually add that host route to fib 0. Adding a % 'bge0.300' to the static route line doesn't change a thing, route still only appears in fib 1. Two questions: - why does BIRD put the route in fib 1 when no fib is specified, and the interface is not bound to a fib? - Is there a canonical way of solving this? I have the fib 0 static route configured in the system setup now, which makes it work. It would be nicer to have it thrown in there by BIRD, so the config is self-contained. Any guidance would be highly appreciated. Elmar.

1 0

Redistribution from BGP protocol to OSPF is not working
by keyvan ghadimi 01 Nov '21

01 Nov '21

Hi, I have Three routers in my network like the below diagram. RTR01 has a BGP to RTR02 and RTR02 has an OSPF to RTR03. I wrote a filter to redistribute origin routes from BGP protocol to OSPF in RTR02 but it's not working. ┌───────┐ ┌───────┐ ┌─────┐ │ RTR01. ├──┤ RTR02 ├── ──┤ RTR03 │ └───────┘ └───────┘ └─────┘ 10.2.2.3 -BGP- 10.2.2.2 10.100.100.2 -OSPF- 10.100.100.3 RTR02 Bird config: protocol bgp bgp_to_rtr01{ local as 64513; neighbor 10.2.2.3 as 64512; source address 10.2.2.2; allow local as 64513; multihop; ipv4 { import all; export all; }; } protocol ospf my_ospf { rfc1583compat yes; tick 2; ecmp no; ipv4 { import where proto = "bgp_to_rtr01"; }; area 0.0.0.0 { stub no; interface "dummy0" { type ptp; }; interface "enp0s9" { type broadcast; }; }; } I did the same redistribution to OSPF to announce the default route via OSPF and it is working, but the same filter for redistribution BGP to OSPF is not. Best Regards, Keyvan

2 3

BFD+BGP behavior difference between bird 1.6 and 2.0
by Kseniya Blashchuk 29 Oct '21

29 Oct '21

Hello! After upgrading to 2.0 I have noticed that "bgp on" in BGP peer configuration creates a separate BFD session, however it wasn't like that in bird 1.6, we had to specify neighbors in BFD section. Now for bird 2.0 it looks like specifying neighbors in BFD section is not necessary when "bgp on" is set in BGP configuration. The problem I have faced was "unknown session id" errors between two BGP routers, one running bird 1.6 and another running bird 2.0, same config. It looked like bird 2.0 was creating two BFD sessions comparing to bird 1.6 that created only one. Removing neighbor from BFD section at bird 2.0 fixed the issue. Can anybody tell me if anything has changed in 2.0 or am I missing something? The documentation looks quite similar for both versions in this case.

2 2

How to make bird now its own connectivity (OSPF)
by Lukas Haase 24 Oct '21

24 Oct '21

Hi, Assume the following toy example: R1: R2: 10.1.1.0/24 <--- 10.1.1.1, 192.168.1.1 <---------> 192.168.1.2, 10.1.2.1 ---> 10.1.2.0/24 Net 10.1.1.0/24 has R1 as default route, net 10.1.2.0/24 R2. Since the network connectivity is known, 10.1.2.0/24 could reach 10.1.2.0/24 and vice versa. Of course, R1 and R2 need to exchange that information. It was my understanding that OSPF would do this automatically. But this does not seem to be the case with Bird: Dynamic routes (10.1.1.0/24 and 192.168.1.0/24 for R1 and 192.168.1.0/24 and 10.1.2.0/24 for R2) do not land automatically in bird's routing table. I would like to understand exactly why and what is the "right" way to configure bird. Many protocols have flags to allow this but all say it would only be for "exceptional" purposes. But the above network is pretty much the most common one. Where else would routing information come from if not from the network connectivity? Note that this is not OSPF specific: My Mikrotik router automatically sends me all the routes of its connected networks, as I would expect it. So, I think there are the following options: 1.) The direct protocol. But the doc makes it sound this is not the right path: "[...] Although there are some use cases that use the direct protocol (like abusing eBGP as an IGP routing protocol), in most cases it is not needed to have these device routes in BIRD routing table and to use the direct protocol. [...]" 2.) The kernel protocol. But also here the docs have a strong bias importing dynamic routes (device routes): "[...] Unfortunately, there is one thing that makes the routing table synchronization a bit more complicated. In the kernel routing table there are also device routes for directly connected networks. These routes are usually managed by OS itself (as a part of IP address configuration) and we don't want to touch that. They are completely ignored during the scan of the kernel tables and also the export of device routes from BIRD tables to kernel routing tables is restricted to prevent accidental interference." 3.) The static protocol. I could add something like (for R1): protocol static { export all; route 10.1.1.0/24 via 192.168.1.1; } But then I would manually re-create the already known network connectivity in the config file. Why does no protocol in Bird want to take responsibility for the router's own connectivity? How on earth is this supposed to work? Thanks, Lukas

3 3

Broadcast RIP to each broadcast address on interface with multiple aliases
by bird21＠sensation.net.au 23 Oct '21

23 Oct '21

Hi all, I want to broadcast a last-resort old-school default route via RIPv1. The following config works: filter default_route { if net ~ [ 0.0.0.0/0 ] then { accept; } reject; } # ...snip... protocol rip { export filter default_route; interface "em0" { version 1; mode broadcast; update time 5; }; } ...but it only sends to the broadcast address of the main interface IP. How can I get it to send to the broadcast addresses of the aliases as well? These are the networks on the em0 adapter: x.x.x.192/28 (main) 192.168.x.0/24 (alias) 192.168.y.0/24 (alias) After consulting https://bird.network.cz/doc/bird-3.html#proto-iface , I tried the following to force additional/different addresses: interface x.x.x.193/28 { # actual interface IP/prefix interface x.x.x.192/28 { # network IP/prefix interface x.x.x.x { # interface IP only interface "em0" x.x.x.x { # interface name and IP interface "em0" x.x.x.x/28 { # interface name and IP/prefix All of these are rejected with the error "Interface name/mask expected, not IP prefix", regardless of whether I list the main interface IP, or main plus aliases (comma separated). Am I missing something simple in the syntax, or is the RIPv1 implementation not capable of doing this? Thanks in advance.

2 2

OSPFv3 between BIRD2 and RouterOS (Mikrotik)
by Kees Meijs | Nefos 21 Oct '21

21 Oct '21

Hi list, First of all: I'm very sorry if this has been discussed before. Anyway, we're experiencing possible (configuration) incompatibiliy between BIRD2 and Mikrotik RouterOS. To be precise, we're on BIRD 2.0.7 and RouterOS 6.48.5 (Level 6). Configuration snippet from BIRD: > protocol ospf v3 ospf_v6 { > # Do not generate ECMP (equal-cost multipath) routes. > ecmp no; > > area 0.0.0.0 { > interface "eth0" { > authentication cryptographic; > password "SOMETHING"; > bfd yes; > }; > > interface "eth1" { > authentication cryptographic; > password "SOMETHINGELSE"; > bfd yes; > }; > > interface "dummy0" { > stub; > }; > > interface "eth2" { > stub; > }; > > interface "eth3" { > type pointopoint; > bfd yes; > }; > }; > } The dummy0 interface has bound a /32 IPv4 and a /128 IPv6 address for BGP lookback. OSPFv3 should provide us with IGP in order to facilitate iBGP. Between BIRD nodes this works flawless. When adding the Mikrotik router to the mix, the /128 addresses don't get propagated. Other routes do and OSPFv3 seems to work fine, but the stub routes seem to be ignored. What am I missing here? Thanks! Cheers, Kees -- https://nefos.nl/contact <https://nefos.nl/contact> Nefos IT bv Ambachtsweg 25 (industrienummer 4217) 5627 BZ Eindhoven Nederland KvK 66494931 /Bereikbaar op maandag, dinsdag, donderdag en vrijdag tussen 09:00u en 17:00u./

2 3