March 2023 - Bird-users - Mailing Lists

[PATCH] Fixed crash when requesting a BFD session on an unnumbered interface
by Miao Wang 30 Mar '23

30 Mar '23

Hi, The bug can be reproduced with the following steps: 1. create an unnumbered interface: # ip link add dummy0 type dummy # ip link set dummy0 up # ip neigh replace 169.254.0.1 lladdr <some:mac:add:ress> dev dummy0 2. Create a static route via this interface and request a bfd session protocol device { } ipv4 table main4; protocol bfd bfd1 { strict bind; accept direct; } protocol static { ipv4{ table main4; export all; }; route 1.2.3.4/32 via 169.254.0.1%dummy0 onlink bfd; } The crash happens when dereferencing nb->ifa in static protocol module. nb->ifa is null pointer in this case. This patch also contains a fix in sk_setup(). When the source address and the destination address of a socket are both zero, the socket will be judged as an IPv6 socket since zero address is not a v4-mapped address. As a result, IPV6_V6ONLY is set on this socket. This patch prevents IPV6_V6ONLY from being set when both source address and destination address are zero. With below patch, I can confirm that bird won't crash and BFD packets can be successfully sent. Cheers, Miao Wang --- proto/static/static.c | 3 ++- sysdep/unix/io.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/proto/static/static.c b/proto/static/static.c index bb93305e..f2bb98c7 100644 --- a/proto/static/static.c +++ b/proto/static/static.c @@ -206,7 +206,8 @@ static_update_bfd(struct static_proto *p, struct static_route *r) if (bfd_up && !r->bfd_req) { // ip_addr local = ipa_nonzero(r->local) ? r->local : nb->ifa->ip; - r->bfd_req = bfd_request_session(p->p.pool, r->via, nb->ifa->ip, + r->bfd_req = bfd_request_session(p->p.pool, r->via, + nb->ifa ? nb->ifa->ip : IPA_NONE, nb->iface, p->p.vrf, static_bfd_notify, r, NULL); } diff --git a/sysdep/unix/io.c b/sysdep/unix/io.c index e131ca41..8075c2bd 100644 --- a/sysdep/unix/io.c +++ b/sysdep/unix/io.c @@ -996,7 +996,7 @@ sk_setup(sock *s) if (sk_is_ipv6(s)) { - if ((s->type == SK_TCP_PASSIVE) || (s->type == SK_TCP_ACTIVE) || (s->type == SK_UDP)) + if (((s->type == SK_TCP_PASSIVE) || (s->type == SK_TCP_ACTIVE) || (s->type == SK_UDP)) && (ipa_nonzero(s->saddr) || ipa_nonzero(s->daddr))) if (setsockopt(fd, SOL_IPV6, IPV6_V6ONLY, &y, sizeof(y)) < 0) ERR("IPV6_V6ONLY"); -- 2.39.0

2 4

[PATCH] doc: weight should be followed by a number in static route
by Miao Wang 29 Mar '23

29 Mar '23

This patch fixes a mis-spelling in the doc. --- doc/bird.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/bird.sgml b/doc/bird.sgml index f75fa9fe..5ac32e9e 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -5326,7 +5326,7 @@ options (<cf/bfd/ and <cf/weight 1/), the second nexthop has just <cf/weight 2/. interface must be attached to nexthop IP address using link-local-scope format (e.g. <cf/192.0.2.1%eth0/). Default value is no. - <tag><label id="static-route-weight">weight <m/switch/</tag> + <tag><label id="static-route-weight">weight <m/num/</tag> For multipath routes, this value specifies a relative weight of the nexthop. Allowed values are 1-256. Default value is 1. </descrip> -- 2.39.0

1 0

VRF separated BGP neighborships over a logical interface
by Ramanathan Selvamani 29 Mar '23

29 Mar '23

Hi Team, I would like to bring up 2 VRF separated BGP neighborship between two routers as below R1 [eth1.55]-------------------------[eth1.55] R2 B_VRF_BLUE<---------------------> B_VRF_BLUE B_VRF_RED <---------------------> B_VRF_RED I created two VRFs red and blue in the kernel. ip link add red type vrf table 100 ip link set dev red up ip link add blue type vrf table 200 ip link set dev blue up Then i enslaved the logical interface to both VRFs red and blue. ip link set dev eth1.55 master red ip link set dev eth1.55 master blue ---> enslaving to red is overridden by blue after this /tmp # ip link show eth1.55 14: eth1.55@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue *master blue * At R1, I could see B_VRF_BLUE is established and at R2 B_VRF_RED is established. R1 == bird> show protocols Name Proto Table State Since Info B_VRF_RED BGP --- start 23:54:26.660 Idle Received: Cease B_VRF_BLUE BGP --- up 23:54:42.207 Established R2 ==== bird> show protocols Name Proto Table State Since Info B_VRF_RED BGP --- up 23:58:44.611 Established B_VRF_BLUE BGP --- start 23:58:39.842 Active Socket: Connection closed Either one of the BGP sessions is established on both ends. The other session is not getting established. Please let me know if I am missing anything here. Also I noticed that L3VPN support was added into BIRD recently. Is there any support added to handle multiple VRF separated BGP neighborships during this commit ? Please clarify. Below are the configurations used. R1 ==== ipv4 table T_VRF_RED; ipv4 table T_VRF_BLUE; protocol kernel K_VRF_RED { vrf "red"; kernel table 100; scan time 20; ipv4 { table T_VRF_RED; import all; export all; }; } protocol kernel K_VRF_BLUE { vrf "blue"; kernel table 200; scan time 20; ipv4 { table T_VRF_BLUE; import all; export all; }; } protocol direct C_VRF_RED { vrf "red"; ipv4 { table T_VRF_RED; }; } protocol direct C_VRF_BLUE { vrf "blue"; ipv4 { table T_VRF_BLUE; }; } protocol static S_VRF_RED { vrf "red"; ipv4 { table T_VRF_RED; }; route 10.10.1.0/24 blackhole; } protocol static S_VRF_BLUE { vrf "blue"; ipv4 { table T_VRF_BLUE; }; route 10.10.1.0/24 blackhole; } protocol bgp B_VRF_RED { vrf "red"; router id 10.16.44.216; local 55.0.0.1 as 100; neighbor 55.0.0.2 as 100; enable as4 on; hold time 90; keepalive time 30; direct; # regular IPv4 unicast (1/1) ipv4 { table T_VRF_RED; import all; export all; }; } protocol bgp B_VRF_BLUE { vrf "blue"; router id 10.16.44.216; local 55.0.0.1 as 100; neighbor 55.0.0.2 as 100; enable as4 on; hold time 90; keepalive time 30; direct; # regular IPv4 unicast (1/1) ipv4 { table T_VRF_BLUE; import all; export all; }; } R2 ==== ipv4 table T_VRF_RED; ipv4 table T_VRF_BLUE; protocol kernel K_VRF_RED { vrf "red"; kernel table 100; scan time 20; ipv4 { table T_VRF_RED; import all; export all; }; } protocol kernel K_VRF_BLUE { vrf "blue"; kernel table 200; scan time 20; ipv4 { table T_VRF_BLUE; import all; export all; }; } protocol direct C_VRF_RED { vrf "red"; ipv4 { table T_VRF_RED; }; } protocol direct C_VRF_BLUE { vrf "blue"; ipv4 { table T_VRF_BLUE; }; } protocol static S_VRF_RED { vrf "red"; ipv4 { table T_VRF_RED; }; route 10.10.1.0/24 blackhole; } protocol static S_VRF_BLUE { vrf "blue"; ipv4 { table T_VRF_BLUE; }; route 10.10.1.0/24 blackhole; } protocol bgp B_VRF_RED { vrf "red"; router id 10.16.44.217; local 55.0.0.2 as 100; neighbor 55.0.0.1 as 100; enable as4 on; hold time 90; keepalive time 30; direct; # regular IPv4 unicast (1/1) ipv4 { table T_VRF_RED; import all; export all; }; } protocol bgp B_VRF_BLUE { vrf "blue"; router id 10.16.44.217; local 55.0.0.2 as 100; neighbor 55.0.0.1 as 100; enable as4 on; hold time 90; keepalive time 30; direct; # regular IPv4 unicast (1/1) ipv4 { table T_VRF_BLUE; import all; export all; }; } Thanks, Ramanathan

2 2

RIP protocol packet maximum length checking
by Mingwei Zheng 29 Mar '23

29 Mar '23

Hi, I noticed that you have defined RIP_MAX_PKT_LENGTH = 532 in rip.h. It seems that this value isn’t used. So I am wondering how do you check the maximum length in RIP protocol implementation, thanks Best, Mingwei

1 0

Force bird to update bgp route configuration after X seconds
by Pedro Henrique de Araújo Marques 28 Mar '23

28 Mar '23

Good evening, I'm doing some tests with BIRD for a while now and I would like some help with a problem I'm facing. I have the following BIRD configuration: router id 10.0.0.128; ipv4 table master4; ipv6 table master6; flow4 table flowtab4; flow6 table flowtab6; filter subnet_group1{ if(bgp_community.len = 0) then { bgp_community.add((555,555)); accept; } else{ accept; } }; protocol bgp uplink1{ local as 129; neighbor 10.0.1.128 as 128; multihop 1; ipv4{ import filter { accept; }; export filter subnet_group1; }; ipv6{ import filter { accept; }; export filter subnet_group1; }; }; protocol static blackhole_ipv4_routes{ route 10.0.90.100/32 blackhole; route 10.0.90.99/32 blackhole; ipv4; }; I created a script that after some time it inserts some new routes into the blackhole_ipv4_routes protocol defined above, let's say all of 10.0.0.0/24 for example. Is there an option that I could use in the config file to detect this change and update bird accordingly with the new table additions, or do I need to always call 'birdc -configure' after the script ends?

5 7

duplicate device routes on linux
by ico 24 Mar '23

24 Mar '23

Hello all, Here at $work we are using bird for OSPF at some 30 linux boxes. Works great. But there is a thing that confuses me: Let's have some simple linux box: # ip addr 1: lo: ...rest of loopback output 2: eth0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 86:37:65:15:fa:d9 brd ff:ff:ff:ff:ff:ff link-netns r2 inet 10.0.0.1/24 scope global eth0 valid_lft forever preferred_lft forever # ip route 10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.1 As you can see, there is single interface with single address, single device route automatically generated by kernel. Simple bird config: # cat bird.conf # BEGIN bird config router id 10.0.0.1; protocol device { scan time 3; } protocol kernel krnl4 { ipv4 { table master4; import all; export all; }; learn; } protocol ospf ospf1 { ipv4 { table master4; import all; export all; }; area 0.0.0.0 { stub no; interface "eth0" { stub yes; }; }; } # END bird config When I run bird with this configuration, it inserts another route: # ip route 10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.1 10.0.0.0/24 dev eth0 proto bird scope link metric 32 Is this expected/correct behaviour? Or should I somehow filter those device routes out? I want those device routes to be read by OSPF, of course, just not to output them back. What is the best way to get rid of them? Another unrelated question: When I run bird, it logs this: bird: KRT: Netlink strict checking failed, will scan all tables at once bird: Started Should I do something about that failed strict check? Is it important or only some info message I shouldn't worry about? Thank you ico

4 5

ip rule cannot match based on the source IPv4 address
by Brandon Zhi 20 Mar '23

20 Mar '23

Hi guys, I'm doing a "split routing table" on my router, and I'm importing routes into specific kernel routing tables via bird. So I'm doing some strange routing by using ip rule. [root@archlinux ~]# ip -4 rule 0: from all lookup local 32751: from 134.195.121.118 lookup 101 32752: from all iif Tanuki_IX lookup 147 32753: from all iif ens19 lookup 147 32754: from all iif cu_gre6 lookup 247 32755: from all iif cu lookup 147 32756: from all iif openvpn_stuix.5 lookup 247 32757: from all iif openvpn_stuix lookup 147 32758: from all iif openvpn_c1v lookup 147 32759: from all iif openvpn_c1v.5 lookup 247 32760: from all iif openvpn_Eric.5 lookup 247 32761: from all iif openvpn_Eric lookup 147 32762: from all iif ll-ix lookup 147 32763: from all iif ll-ix_gre6 lookup 247 32764: from all iif KSKB lookup 147 32765: from all iif KSKB_gre6 lookup 247 32766: from all lookup main 32767: from all lookup default As you could see, IPv4 from 134.195.121.118/32 will using table 101 which only contain [root@archlinux ~]# ip -4 route show table 101 default via 33.0.0.6 dev openvpn_Eric [root@archlinux ~]# When I am mtr to 8.8.8.8, it still uses the main route table NOT table 101 which does not follow the ip rule. [root@archlinux ~]# mtr -a 134.195.121.118 8.8.8.8 [root@archlinux ~]# tcpdump -i any host 134.195.121.118 tcpdump: data link type LINUX_SLL2 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes 13:30:11.991460 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33008, length 44 13:30:11.998947 openvpn_Eric Out IP archlinux.palace-2 > 172.17.0.1.palace-2: UDP, length 28 13:30:11.999059 openvpn_Eric Out IP archlinux.33915 > 172.17.0.1.palace-2: UDP, length 28 13:30:11.999384 openvpn_Eric Out IP archlinux.27004 > 172.17.0.1.palace-2: UDP, length 28 13:30:12.006020 openvpn_Eric Out IP archlinux.palace-2 > 59.200.0.1.palace-2: UDP, length 28 13:30:12.006096 openvpn_Eric Out IP archlinux.33915 > 59.200.0.1.palace-2: UDP, length 28 13:30:12.006136 openvpn_Eric Out IP archlinux.27004 > 59.200.0.1.palace-2: UDP, length 28 13:30:12.017489 openvpn_Eric Out IP archlinux.palace-2 > 208.99.49.1.palace-2: UDP, length 28 13:30:12.017628 openvpn_Eric Out IP archlinux.33915 > 208.99.49.1.palace-2: UDP, length 28 13:30:12.017650 openvpn_Eric Out IP archlinux.27004 > 208.99.49.1.palace-2: UDP, length 28 13:30:12.023034 openvpn_Eric Out IP archlinux.palace-2 > 172.23.89.1.palace-2: UDP, length 28 13:30:12.023147 openvpn_Eric Out IP archlinux.33915 > 172.23.89.1.palace-2: UDP, length 28 13:30:12.023202 openvpn_Eric Out IP archlinux.27004 > 172.23.89.1.palace-2: UDP, length 28 13:30:12.027182 openvpn_Eric Out IP archlinux.palace-2 > 172.17.0.1.24452: UDP, length 28 13:30:12.027203 openvpn_Eric Out IP archlinux.33915 > 172.17.0.1.24452: UDP, length 28 13:30:12.027212 openvpn_Eric Out IP archlinux.27004 > 172.17.0.1.24452: UDP, length 28 13:30:12.031218 openvpn_Eric Out IP archlinux.palace-2 > 59.200.0.1.24452: UDP, length 28 13:30:12.031235 openvpn_Eric Out IP archlinux.33915 > 59.200.0.1.24452: UDP, length 28 13:30:12.031243 openvpn_Eric Out IP archlinux.27004 > 59.200.0.1.24452: UDP, length 28 13:30:12.036170 openvpn_Eric Out IP archlinux.palace-2 > 208.99.49.1.24452: UDP, length 28 13:30:12.036192 openvpn_Eric Out IP archlinux.33915 > 208.99.49.1.24452: UDP, length 28 13:30:12.036200 openvpn_Eric Out IP archlinux.27004 > 208.99.49.1.24452: UDP, length 28 13:30:12.040852 openvpn_Eric Out IP archlinux.palace-2 > 172.23.89.1.24452: UDP, length 28 13:30:12.040873 openvpn_Eric Out IP archlinux.33915 > 172.23.89.1.24452: UDP, length 28 13:30:12.040881 openvpn_Eric Out IP archlinux.27004 > 172.23.89.1.24452: UDP, length 28 13:30:12.046089 openvpn_Eric Out IP archlinux.palace-2 > 172.17.0.1.24453: UDP, length 28 13:30:12.046119 openvpn_Eric Out IP archlinux.33915 > 172.17.0.1.24453: UDP, length 28 13:30:12.046138 openvpn_Eric Out IP archlinux.27004 > 172.17.0.1.24453: UDP, length 28 13:30:12.051427 openvpn_Eric Out IP archlinux.palace-2 > 59.200.0.1.24453: UDP, length 28 13:30:12.051453 openvpn_Eric Out IP archlinux.33915 > 59.200.0.1.24453: UDP, length 28 13:30:12.051467 openvpn_Eric Out IP archlinux.27004 > 59.200.0.1.24453: UDP, length 28 13:30:12.055046 openvpn_Eric Out IP archlinux.palace-2 > 208.99.49.1.24453: UDP, length 28 13:30:12.055075 openvpn_Eric Out IP archlinux.33915 > 208.99.49.1.24453: UDP, length 28 13:30:12.055085 openvpn_Eric Out IP archlinux.27004 > 208.99.49.1.24453: UDP, length 28 13:30:12.058847 openvpn_Eric Out IP archlinux.palace-2 > 172.23.89.1.24453: UDP, length 28 13:30:12.058874 openvpn_Eric Out IP archlinux.33915 > 172.23.89.1.24453: UDP, length 28 13:30:12.058886 openvpn_Eric Out IP archlinux.27004 > 172.23.89.1.24453: UDP, length 28 13:30:12.091913 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33009, length 44 13:30:12.096047 openvpn_Eric Out IP archlinux.palace-2 > 7.254.0.1.palace-2: UDP, length 28 13:30:12.096081 openvpn_Eric Out IP archlinux.33915 > 7.254.0.1.palace-2: UDP, length 28 13:30:12.096092 openvpn_Eric Out IP archlinux.27004 > 7.254.0.1.palace-2: UDP, length 28 13:30:12.101389 openvpn_Eric Out IP archlinux.palace-2 > 7.254.0.1.24452: UDP, length 28 13:30:12.101409 openvpn_Eric Out IP archlinux.33915 > 7.254.0.1.24452: UDP, length 28 13:30:12.101422 openvpn_Eric Out IP archlinux.27004 > 7.254.0.1.24452: UDP, length 28 13:30:12.192666 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33010, length 44 13:30:12.293006 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33011, length 44 13:30:12.393416 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33012, length 44 13:30:12.494029 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33013, length 44 13:30:12.607660 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33014, length 44 13:30:12.679414 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33015, length 44 13:30:12.966665 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33019, length 44 13:30:13.039053 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33020, length 44 13:30:14.045371 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33034, length 44 13:30:14.116878 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33035, length 44 13:30:14.188702 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33036, length 44 13:30:14.260455 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33037, length 44 13:30:14.332277 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33038, length 44 13:30:14.404019 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33039, length 44 13:30:14.475861 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33040, length 44 13:30:14.547705 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33041, length 44 13:30:14.619529 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33042, length 44 13:30:14.691361 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33043, length 44 13:30:14.763157 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33044, length 44 13:30:14.834959 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33045, length 44 13:30:14.906978 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33046, length 44 13:30:14.978577 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33047, length 44 13:30:15.050371 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33048, length 44 13:30:15.122227 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33049, length 44 13:30:15.193915 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33050, length 44 13:30:15.265629 ens18 Out IP archlinux > dns.google: ICMP echo request, id 65299, seq 33051, length 44 13:30:15.325557 openvpn_Eric Out IP archlinux.palace-2 > root-mia-01.zerotier.com.palace-2: UDP, length 137 13:30:15.325578 openvpn_Eric Out IP archlinux.33915 > root-mia-01.zerotier.com.palace-2: UDP, length 137 13:30:15.325586 openvpn_Eric Out IP archlinux.27004 > root-mia-01.zerotier.com.palace-2: UDP, length 137 13:30:15.328638 openvpn_Eric Out IP archlinux.palace-2 > root-zrh-01.zerotier.com.palace-2: UDP, length 137 13:30:15.328657 openvpn_Eric Out IP archlinux.33915 > root-zrh-01.zerotier.com.palace-2: UDP, length 137 13:30:15.328667 openvpn_Eric Out IP archlinux.27004 > root-zrh-01.zerotier.com.palace-2: UDP, length 137 13:30:15.329981 openvpn_Eric Out IP archlinux.palace-2 > root-sgp-01.zerotier.com.palace-2: UDP, length 137 13:30:15.329998 openvpn_Eric Out IP archlinux.33915 > root-sgp-01.zerotier.com.palace-2: UDP, length 137 13:30:15.330007 openvpn_Eric Out IP archlinux.27004 > root-sgp-01.zerotier.com.palace-2: UDP, length 137 13:30:15.332916 openvpn_Eric Out IP archlinux.palace-2 > 104.194.8.134.palace-2: UDP, length 137 13:30:15.332934 openvpn_Eric Out IP archlinux.33915 > 104.194.8.134.palace-2: UDP, length 137 13:30:15.332941 openvpn_Eric Out IP archlinux.27004 > 104.194.8.134.palace-2: UDP, length 137 As you could see, the package still using the default route table not table 101. This happens on Debian at the same time, and I think it's a problem about Linux, not just ArchLinux. I also tested passing ip -6 rule add from some ipv6 address table 101. It can work normally, that is to say, there is a matching problem with ipv4 in ip rule, but this phenomenon does not exist in ipv6. Best, *Brandon Zhi* HUIZE LTD www.huize.asia <https://huize.asia/>| www.ixp.su | Twitter This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus.

2 2

First Time Bird - Failing To Start
by support＠orcacomputers.com 18 Mar '23

18 Mar '23

Hello, I am setting up bird daemon for the first time. I have built a BGP Neighborship in /etc/bird6.conf and now attempting to start the bird daemon but unsuccessful and do not know why. When I "systemctl start bird" I get failed start. | I am uncertain if I am supposed to have a file in /usr/lib/systemd/system/ for bird. The guidance I've been given so far says no file in /usr/lib/systemd/system/. I have /etc/bird.conf6 file created

3 3

[PATCH] Add missing reference to "show route in" in cli-help and doc
by Johannes Moos 18 Mar '23

18 Mar '23

Hi, please find a patch attached that adds missing references to "show route in" (introduced with v2.0.9) in the cli-help and doc. Johannes

2 1

BIRD 3 STATUS
by Marcelo Balbinot 17 Mar '23

17 Mar '23

Hi BIRD dev team, Any news for bird 3 (multithreaded version)?

2 1