- Bird-users - Mailing Lists

Re: [Babel-users] [RFC] Replace WireGuard AllowedIPs with IP route attribute
by Daniel Gröber 22 Nov '23

22 Nov '23

Hi Kyle, On Mon, Aug 28, 2023 at 11:40:48AM -0400, Kyle Rose wrote: > On Sat, Aug 19, 2023 at 5:25 PM Daniel Gröber <dxld(a)darkboxed.org> wrote: > > Having read Kyle's use-case I'm thinking my original plan to extend the wg > > internal source-address filtering to use a rt lookup with our new attribute > > would not be maximally useful so now my thinking is we should just have a > > boolean toggle to disable it explicitly per device. > > If there is interest among the maintainers in eventually merging a > change with a per-interface knob to turn off the source IP check, I > will go through the trouble of putting together an initial pass at > this. I don't want to spend the time if there is firm opposition to > the idea. I think just a patch to turn off the wg source IP check is not very useful at the moment. It would encourage bad source IP filtering practices when multiple peers are involved as no mechanism for identifying the sending peer is available at the policy routing or netfilter level currently. I think such a patch would have to get merged after some kind of mechanism to identify and filter based on the sending wg peer is available. So if you want to move this along I would suggest working on this first. Since I'm also interested in having this feature I'm happy collaborate. It's just hard to find the motivation for writing more wg patches when my pending ones have (mostly) been lying around for a year without a response, but if you're also keen on this feature I'm sure it's easier to stay motivated together :) If my kernel patches go ignored for too long too I'll probably just resort to getting a forked DKMS wireguard module into Debian with this work. Perhaps that approach (or a package in a different distro) would work for your use-case too? --Daniel

5 10

IPv6 routes not imported into Kernel
by Robert Finze 15 Nov '23

15 Nov '23

Hello all, I've decided to learn more about BGP and Bird. To do so I'm currently setting up a small BGP setup with 2 VMs and Bird as routing daemons. While the first server is running smoothly, the second one is not importing IPv6 routes into the kernel. There are no issues with IPv4 routes on either system. The Bird config on both systems is nearly identical (only IPs differ) and also the systems are setup in a similar manner. Both VMs run in ProxmoxCE 8.0.4 The system without issues is running: BIRD 2.14 on Linux version 5.4.0-165-generic (buildd@lcy02-amd64-078) (gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.2)) #182-Ubuntu SMP Mon Oct 2 19:43:28 UTC 2023 The system with issues is running: BIRD 2.14 Linux version 5.15.0-88-generic (buildd@lcy02-amd64-058) (gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #98-Ubuntu SMP Mon Oct 2 15:18:56 UTC 2023 The routes are correctly learned from upstream and exported to the kernel, but the kernel is not "learning" them. The journal shows the following logs: -------------- Nov 04 21:31:51 moon bird[850]: Netlink: Invalid argument Nov 04 21:31:51 moon bird[850]: Netlink: Invalid argument Nov 04 21:31:51 moon bird[850]: Netlink: Invalid argument Nov 04 21:31:51 moon bird[850]: ... Nov 04 21:31:51 moon bird[850]: Netlink: Invalid argument Nov 04 21:31:51 moon bird[850]: ... Nov 04 21:31:52 moon bird[850]: Netlink: Invalid argument Nov 04 21:31:52 moon bird[850]: ... Nov 04 21:31:53 moon bird[850]: Netlink: Invalid argument Nov 04 21:31:54 moon bird[850]: ... -------------- One example route from Birds point of view shows: -------------- bird> show route for 2620:12f:f000::/44 Table master6: 2620:12f:f000::/44 unicast [upstream_1v6 2023-11-04 16:47:37] ! (100) [AS43i] via 2a0d:xxxxx:1 on ens20 unicast [upstream_2v6 2023-11-04 16:47:36] (100) [AS43i] via 2a0d:xxxxx:2 on ens20 -------------- Linux shows: # ip -6 r get 2620:12f:f000:: RTNETLINK answers: Network is unreachable Manually adding the routes to the kernel works: # ip -6 r a 2620:12f:f000::/44 nexthop via 2a0d:xxxx:1 nexthop via 2a0d:xxxx:2 dev ens20 After creating a netlink monitor interface I was able to capture some netlink messages which show that the routes are trying to be created but an error is returned. I don't get from the error message what the issue is. ip link add nl0 type nlmon ip link set nl0 up Netlink route 0000 00 04 03 38 00 00 00 00 00 00 00 00 00 00 00 00 ...8............ 0010 68 00 00 00 18 00 05 05 13 0d 66 02 00 00 00 00 h.........f..... 0020 0a 28 00 00 fe 0c 00 01 00 00 00 00 14 00 01 00 .(.............. 0030 26 07 ff 00 0b 00 00 00 00 00 00 00 00 00 00 00 &............... 0040 08 00 06 00 20 00 00 00 14 00 07 00 2a 0e 39 40 .... .......*.9@ 0050 10 00 00 00 00 00 00 00 00 00 00 02 08 00 04 00 ................ 0060 02 00 00 00 14 00 05 00 2a 0e 39 40 de ad 00 00 ........*.9@.... 0070 00 00 00 00 00 00 00 01 ........ Netlink 0000 00 04 03 38 00 00 00 00 00 00 00 00 00 00 00 00 ...8............ 0010 7c 00 00 00 02 00 00 00 13 0d 66 02 7a 31 09 81 |.........f.z1.. 0020 ea ff ff ff 68 00 00 00 18 00 05 05 13 0d 66 02 ....h.........f. 0030 00 00 00 00 0a 28 00 00 fe 0c 00 01 00 00 00 00 .....(.......... 0040 14 00 01 00 26 07 ff 00 0b 00 00 00 00 00 00 00 ....&........... 0050 00 00 00 00 08 00 06 00 20 00 00 00 14 00 07 00 ........ ....... 0060 2a 0e 39 40 10 00 00 00 00 00 00 00 00 00 00 02 *.9@............ 0070 08 00 04 00 02 00 00 00 14 00 05 00 2a 0e 39 40 ............*.9@ 0080 de ad 00 00 00 00 00 00 00 00 00 01 ............ Happy to forward a pcap or any other information as well. After upgrading to newer Kernel it still shows the same behaviour, that is, "Netlink: Invalid argument" for IPv6 routes.. /proc/version Linux version 6.2.0-36-generic (buildd@lcy02-amd64-050) (x86_64-linux-gnu-gcc-11 (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #37~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Oct 9 15:34:04 UTC 2 It would be great if anyone had any pointer to what I am missing or what is going wrong here. Best, Robert

1 0

[PATCH] OSPF: on PtP ospf_iface with physical PtP links, skip next-hop resolving
by Soha Jin 11 Nov '23

11 Nov '23

Signed-off-by: Soha Jin <soha(a)jin.sh> Co-developed-by: Wende Tan <twd2.me(a)gmail.com> --- proto/ospf/rt.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/proto/ospf/rt.c b/proto/ospf/rt.c index 471bb586..02b2f214 100644 --- a/proto/ospf/rt.c +++ b/proto/ospf/rt.c @@ -1796,7 +1796,12 @@ calc_next_hop(struct ospf_area *oa, struct top_hash_entry *en, if (ifa->type == OSPF_IT_VLINK) return new_nexthop(p, IPA_NONE, NULL, 0); - /* FIXME: On physical PtP links we may skip next-hop altogether */ + /* + * The type of the ospf_iface is PtP and the iface has a physical PtP link, + * so we can simply use the iface, and skip further resolving. + */ + if (ifa->type == OSPF_IT_PTP && !(ifa->iface->flags & IF_MULTIACCESS)) + return new_nexthop(p, IPA_NONE, ifa->iface, ifa->ecmp_weight); if (ospf_is_v2(p) || ospf_is_ip6(p)) { -- 2.39.2

3 5

Problem installation on FreeBSD 13.2
by David S. 10 Nov '23

10 Nov '23

Dear Lists, I'm trying to install a bird-2.14 from the source on FreeBSD 13.2 and found the following error message: make[1]: "/root/installer/bird-2.14/Makefile" line 45: Invalid line type make[1]: "/root/installer/bird-2.14/Makefile" line 47: Invalid line type make[1]: "/root/installer/bird-2.14/Makefile" line 49: Invalid line type make[1]: "/root/installer/bird-2.14/Makefile" line 51: Invalid line type make[1]: "/root/installer/bird-2.14/Makefile" line 53: Invalid line type make[1]: "/root/installer/bird-2.14/Makefile" line 56: Invalid line type make[1]: "/root/installer/bird-2.14/Makefile" line 59: Invalid line type make[1]: "/root/installer/bird-2.14/Makefile" line 61: Invalid line type make[1]: "/root/installer/bird-2.14/Makefile" line 63: Invalid line type make[1]: "/root/installer/bird-2.14/Makefile" line 93: Invalid line type make[1]: "/root/installer/bird-2.14/Makefile" line 95: Invalid line type make[1]: "/root/installer/bird-2.14/Makefile" line 97: Invalid line type make[1]: "/root/installer/bird-2.14/Makefile" line 99: Invalid line type make[1]: "/root/installer/bird-2.14/Makefile" line 102: Invalid line type make[1]: /root/installer/bird-2.14/: read error: Is a directory Step to reproduce the issue: 1. Download Bird-2.14 from https://bird.network.cz/download/bird-2.14.tar.gz 2. tar -zxvf bird-2.14.tar.gz 3. cd bird-2.14 4. ./configure 5. gmake Please see the attached file for the details Thank you. Best regards, David S. ------------------------------------------------ e. david(a)zeromail.us w. pnyet.web.id p. 087881216110

3 3

BIRD and IETF 118
by Maria Matejka 07 Nov '23

07 Nov '23

Hello! Just a short reminder for those attending IETF 118 – we aren't officially attending, anyway, if you wish to meet us, please let us know preferably during this week and we may do some BIRD meetup. Have a nice journey to Prague and remember, we have the 2nd best[1] public transportation network in the world, no need for taxi here ;o) Maria [1] https://www.timeout.com/travel/best-public-transport-in-the-world -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

2 3

BIRD presence on meetings until end of 2023
by Maria Matejka 30 Oct '23

30 Oct '23

Dear BIRD Users, I'd like to let you know that we're planning to visit several meetings before this year ends: * LinuxDays in Prague, October 7 (presentation in Czech), * NANOG 89 in San Diego, October 16 to 18, * Euro-IX 39th Forum in Prague, November 19 to 22, * RIPE 87 in Rome, November 27 to December 1. Feel free to approach us with any questions you have. We are usually pretty busy, so if you'd like to have some time with us guaranteed, we can plan an in-person meeting with you in advance. If you wish to get a Support Package for your BIRD deployment, these are perfect opportunities to discuss your needs with us. There is also IETF 118, November 4 to 10, in Prague. If anyone of you comes to Prague these days and would like to meet us, you're welcome, just let me know in advance and we'll arrange the meeting. And even if you come to Prague outside these dates, don't hesitate to contact us – we can meet anyway. Looking forward to seeing you. Maria -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

5 9

Is it possible to set an IP address to an interface?
by Robért Guhr 26 Oct '23

26 Oct '23

Hi, is it possible to set an ipv4 address (e.g. "10.186.100.11/32" ) via bird on a dummy interface called "anycast"? I mean via the bird config not via bgp/ospf pushes. Background: I have setup four DNS server in two sites. All these DNS servers announces 10.186.100.11/32 (and 10.186.100.12/32) up to the routers to create an anycast environment. Currently 10.186.100.11/32 (and 10.186.100.12/32) are set fixed on the dummy interface. Bird just imports these IP addresses. We would like to use 10.186.100.11/32 and 10.186.100.12/32 as resolver in /etc/resolv.conf But if we stop the local DNS server then the dns resolution is no longer possible because the addresses are hardcoded on the local interface and the other three dns server will not be used. Idee was to set the ip addreses via bird so that when we stop Bird and the local DNS server, we automatically forward the DNS requests to the other three servers. I was hoping the direct protocol converts a route also to an ip address but this seems not to be the case. With the kernel protocol I can export the route to the kernel routing table but that is not was I was want. pns-b2-ns02 ~ # cat /etc/bird.conf # Ansible managed router id 10.186.244.12; protocol device { scan time 10; } protocol direct { ipv4 { import none; export all; }; interface "anycast"; } protocol static { ipv4 { import all; export all; }; route 10.186.100.11/32 via "anycast"; } protocol kernel { ipv4 { import none; export all; }; } pns-b2-ns02 ~ # birdc show route; echo; ip a show dev anycast; echo; ip r | grep 10.186.100 BIRD 2.13.1 ready. Table master4: 10.186.100.11/32 unicast [static1 17:22:18.282] * (200) dev anycast 4: anycast: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether 8e:b5:2b:bf:0d:5e brd ff:ff:ff:ff:ff:ff inet 10.186.100.9/32 scope global noprefixroute anycast # <----- here should also be the address 10.186.100.11/32 valid_lft forever preferred_lft forever 10.186.100.11 dev anycast proto bird scope link metric 32 Regards, Robért

4 6

Babel over br-lan and export via bgp
by Oriol Rico 25 Oct '23

25 Oct '23

Hello everybody I have a bird daemon with this configuration # Configure logging log syslog all; log "/var/log/bird.log" all; log stderr all; #debug protocols { routes, interfaces }; # Override router ID router id 10.20.2.2; # Sync bird routing table with kernel protocol kernel { learn; ipv4 { import all; export all; }; } protocol device { scan time 10; } # Include directly connected networks protocol direct { ipv4; } protocol static static4 { ipv4 { export all;}; route 10.0.0.0/8 via 10.20.2.1; route 0.0.0.0/0 via 10.20.2.1; } protocol babel { interface "wlan0" { type wireless; hello interval 1 s; rx buffer 15000; }; interface "br-lan" { type wired; }; ipv4 { export where (source = RTS_DEVICE) || (source = RTS_BABEL) || (source = RTS_STATIC); }; } filter rr_export { if ( net ~ [ 10.0.0.0/8{24,32} ] ) then { accept; } else{ reject; } } protocol bgp { local 10.20.2.2 as 114108; source address 10.20.2.2; neighbor 10.20.2.1 as 111796; ipv4 { import none; export filter rr_export; }; } I received a route via br-lan with the prefix 10.20.3.32/27 via babel protocol, but when i export via bgp the peer logs a Withdrawn, but when i am in the router with the setup i send i can reach 10.20.3.32/27 via br-lan over babel. I don't know where is the problem. All other config it's ok. Can you help me? Thanks in advanced Oriol

1 1

bird control socket response
by LIU Chris 18 Oct '23

18 Oct '23

Classified as: {OPEN} I want to implement an application to talk to bird daemon, basically like birdc/birdcl. The control socket is TCP stream, it is fine. But the response from bird daemon adds some headers for each line I understand server want to make a boundary/delimiter for stream. Just wondering why not just add how many bytes in the beginning of response, instead of this inconvenient way (have to decode line by line). I am not question bird implementation, just wondering :) Current format like below Show protocols 0001 BIRD 2.0.10 ready. 2002-Name Proto Table State Since Info 1002-device1 Device --- up static_bgp Static master4 up kernel1 Kernel master4 up 0000 With Best Regards, Chris LIU {OPEN} Thales is in the process of carving out its Transportation activity (GTS) from other Thales' activities. In order to prepare this internal restructuring, a new e-mail address has been adopted and your GTS contacts now use urbanandmainlines.com. Please note that their Thales e-mail address remains also valid.

4 5

Proper use of graceful restart functionality
by Pavlos Parissis 17 Oct '23

17 Oct '23

Hi all, I am using latest 2.x version of Bird and I have a question about graceful restart. I have `graceful restart on` for BGP protocol and I currently perform below steps when I want to utilize it: 1. birdc graceful restart 2. systemctl start bird.service According to the documentation I need `-R` command-line option, thus I have adjusted systemd unit file accordingly: ``` ExecStart=/usr/sbin/bird -R -f -u bird -g bird ``` How does the aforementioned command-line option behave when `birdc graceful restart` is not issued? I scanned the code to understand it and I think bird is smart enough to know that a graceful restarted was not requested and it doesn't do anything during the startup. While I was testing graceful restart functionality, I noticed that even without the aforementioned command-line option the upstream peer does not remove the routes until restart timeout expires. So, I was wondering if that option is real needed thus the question. Regards, Pavlos

2 2