July 2021 - Bird-users - Mailing Lists

Possibility to treat /32 and /128 non-gateway routes as onlink on BSD?
by Stefan Haller 27 Dec '21

27 Dec '21

Hi everyone, In a recent change in the FreeBSD Wireguard kernel module the POINTTOPOINT interface flag is dropped for wg interfaces[1]. This behaviour will probably not change, because Wireguard is not peer-to-peer or a broadcast domain, but peer-to-multipoint. Hence my previous configuration of setting peer addresses on the interface is not working anymore: ifconfig wg0 inet 192.168.0.10/32 192.168.0.4 The above syntax is for POINTTOPOINT interfaces. In this case 192.168.0.10 is the local address of the interface and 192.168.0.4 is the address of the remote peer. So if one does not want to add a dedicated subnet to every tunnel device, one has to add static host routes similar to these ones: ifconfig wg0 192.168.0.10/32 route add 192.168.0.4 -iface wg0 Note that this actually models the real world better, because Wireguard is not point-to-point but point-to-multipoint. So multiple peers can be done in the following way: ifconfig wg0 192.168.0.10/32 route add 192.168.0.4 -iface wg0 route add 192.168.0.8 -iface wg0 However, this does not work with bird 2.0.8: bird will not recognize the p2p peer addresses as gateways and it will log on kernel table rescan: KRT: Received route 192.168.42.0/24 with strange next-hop 192.168.0.4 KRT: Error sending route 192.168.42.0/24 to kernel: File exists I did have a look why this is happening: bird discards the route, because the gateway does not belong to any of its interface's addresses (the peer address is configured as a static host route and not on the interface). At the same time it forgets that it was bird itself who added the route (because the route is discarded on kernel table rescan, it thinks it is absent in the kernel table but present in bird's internal routing table -> "add" logic triggers) and tries to add the route again (instead of replacing/keeping the route). This explains the cascade of error messages above. While the Linux netlink code allows to handle onlink routes, this functionality is absent in the BSD code path. Unfortunately, on BSD there is no dedicated flag to mark routes as being directly connected onlink routes. On Linux one could add an onlink route like so: ip route add 192.168.0.4 via 192.168.0.4 dev wg0 onlink The command looks quite odd, but it is working. The via clause is necessary in conjunction with onlink. Afterwards a `birdc dump neighbors` verifies that the peer is recognized: 000055db793035c0 192.168.0.4 wg0 wg0 kernel1 000000000000000000000000 scope univ ONLINK (Also the "strange next-hop" message will go away.) I created a patch that emulates the behaviour on FreeBSD. In this patch the onlink setting is heuristically determined by inspecting the RTF_GATEWAY flag (which must be absent) and checking for a /32 or /128 prefix length. I do not see how to handle cases where the destination is a subnet. The patch was tested on FreeBSD 13.0-RELEASE and 14.0-CURRENT. During rescan of the kernel table the above route is now not dropped because the gateway is recognized to be onlink. While in the Linux route the gateway is still set, on FreeBSD it is unset (~RTF_GATEWAY). So I actually use the destination address of the route, because that's the address of the peer. While I tested the functionality on my machines and also checked the output of `birdc dump neighbors`, the patch might be faulty. Please be kind with me and treat it more as a proof of concept. As I am not experienced with bird's code base I do not fully understand how the neighbor cache is working in detail, so the suggested patch might have unexpected side effects. I would appreciate feedback. In case you think the whole idea is not sensible, I would also love to hear suggestions how to get the above setup working. Kind regards, Stefan [1]: https://git.zx2c4.com/wireguard-freebsd/commit/?id=8801509656e955c27ebf4b9b… sysdep/bsd/krt-sock.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sysdep/bsd/krt-sock.c b/sysdep/bsd/krt-sock.c index ea0cc4d9..4a0f3a7a 100644 --- a/sysdep/bsd/krt-sock.c +++ b/sysdep/bsd/krt-sock.c @@ -547,6 +547,12 @@ krt_read_route(struct ks_msg *msg, struct krt_proto *p, int scan) net->n.addr, a.nh.gw); return; } + } else if ((!ipv6 && pxlen == 32) || (ipv6 && pxlen == 128)) { + /* Treat non gateway /32 and /128 routes as onlink routes and inject this + information into neighbor cache. */ + if (!neigh_find(&p->p, idst, a.nh.iface, NEF_ONLINK)) + log(L_ERR, "KRT: Failed to inject onlink neighbor %I for interface %s", + idst, a.nh.iface->name); } done: -- 2.31.1

2 5

bgp_large_community wildcard in conditional
by Brooks Swinnerton 18 Oct '21

18 Oct '21

Hello, I was wondering if it's possible to create a conditional that matches on a wildcard for a part of a BGP large community. For example: if ([*, 600, 6939]) ~ bgp_large_community then reject; This currently results in a syntax error at the position of the comma after the *.

5 7

Compilation directive LOCAL_DEBUG and DBG()
by Senthil Kumar Nagappan 17 Sep '21

17 Sep '21

Hi, To enable debug outputs using DBG macro, it requires LOCAL_DEBUG or GLOBAL_DEBUG to be defined during compilation. 1. Defined it in the Makefile as below. Is there an option without changing the auto generated Makefile? CFLAGS=$(CPPFLAGS) -g -O2 -pthread -fno-strict-aliasing -fno-strict-overflow -flto -Wall -Wextra -Wstrict-prototypes -Wno-parentheses -Wno-pointer-sign -Wno-missing-field-initializers -DLOCAL_DEBUG 2. If we try to define LOCAL_DEBUG in the code, there are undef directive in the different places of the code, so may not work consistently. 3. If we define this LOCAL_DEBUG or GLOBAL_DEBUG, there are compilation errors that needs to be addressed. Thanks and Regards,Senthil

2 4

route reflector setup problem
by SC SCx 28 Aug '21

28 Aug '21

Hi, I am trying to setup two route reflectors (that also pass traffic) that peer with ebgp (and exchange routes via ibgp between themselves). So something like. as100 as200 | | | | ebgp ebgp | | | | RR1(as999)--- ibgp --- RR2(as999) | \ / | | \ / | | \ / | | \ / | | \ / | | \ / | | \ / | | X | | / \ | | / \ | | / \ | | / \ | | / \ | rr client 1 rr client 2 I came up with a config like this (for simplicity's sake I will only show RR1's side since it's the equivalent for RR2 with just slightly different parameters like ip addresses, etc.) # ebgp from RR1 to as100 protocol bgp ebgp_as100 { local as 1000; neighbor 100.100.100.100 as 100; export filter { if PREFIXES_TO_EXPORT() then accept; reject; } import filter { if PREFIXES_TO_IMPORT_LTE_24() then accept; reject; } } # ibgp from RR1 to RR2 protocol bgp ibgp { local as 999; neighbor 10.0.0.2 as 999; source address 10.1.0.1; next hop self; rr cluster id 0.0.0.1; } # RR1 to rr client 1 (also has one for rr client 2) protocol bgp rr_client1{ local as 999; neighbor 10.0.0.3 as 999; source address 10.1.0.1; rr client; rr cluster id 0.0.0.1; # next hop self #??? export filter { if PREFIXES_TO_EXPORT() then accept; reject; }; import filter { if PREFIXES_TO_IMPORT() then accept; reject; }; } ########################################################## # on rr client 1 to RR1 (also has one for RR2) protocol bgp rr1_ibgp { local as 999; neighbor 10.0.0.1 as 999; source address 10.1.0.3; next hop self; export all; import all; } This works, but with some problems. Prefixes learned from AS100 and AS200 that get exported to RR clients are unreachable unless they passed through the IBGP connection between RR1 and RR2. Makes sense, since the IBGP connection between RRs is defined with next hop self, and the RR client connections aren't. So, I went in, and added "next top self" to the connections between RRs and RR clients. It has fixed the unreachable problem but caused another one. Now prefixes that are exported on RR clients to RRs have their next hop changed which is not what I want. I want to leave them intact. (e.g. RR clients can export some private ip ranges which I don't want to be routable on the RRs) So I *think* that I need a way on the RRs to only change next hop of EBGP prefixes that get exported from RRs to RR clients but leave other prefixes unaffected. Is my thinking correct? How can this be achieved? Thanks.

2 3

comparing open source BGP stacks performance
by Justin Pietsch 26 Aug '21

26 Aug '21

Hi all, because I couldn't find many results of performance tests of open source routing stacks, I did some tests and wrote up https://elegantnetwork.github.io/posts/comparing-open-source-bgp-stacks/. It compares BIRD, FRRouting and GoBGP. Justin

7 7

IPv6 BGP & kernel 4.19
by Robert Sander 25 Aug '21

25 Aug '21

Hi, our routers run on Debian stretch with bird 1.6.4 from bird.network.cz/debian. Yesterday I tried kernel 4.19 from backports.debian.org and ran into a weird issue with IPv6 BGP sessions: All Peerings reported "Error: Hold timer expired" ca. every 40 minutes. IPv6 forwarding was flapping all the time. After rebooting into kernel 4.9 everything worked again. IPv4 BGP was not affected and also OSPF (v4 and v6). I could disable all IPv6 BGP peerings on this router and then it forwarded to another router learned via OSPF for IPv6 without issues. Has anyone seen such a behaviour? Regards -- Robert Sander Heinlein Support GmbH Schwedter Str. 8/9b, 10119 Berlin https://www.heinlein-support.de Tel: 030 / 405051-43 Fax: 030 / 405051-19 Amtsgericht Berlin-Charlottenburg - HRB 93818 B Geschäftsführer: Peer Heinlein - Sitz: Berlin

13 39

[PATCH 1/2] Add mips Debian 8 container
by Skyler Mäntysaari 15 Aug '21

15 Aug '21

Hi! I hope that this will work and help with the mips package building. I originially had forgotten to do the pkg gitlab steps too. Please let me know if I can help with that in any other way and disregard the previous patch. This is basically the same one, with both commits. --- .gitlab-ci.yml | 10 ++++++++++ misc/docker/debian-9-mips/Dockerfile | 26 ++++++++++++++++++++++++++ 2 files changed, 36 insertions(+) create mode 100644 misc/docker/debian-9-mips/Dockerfile diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 3642b671..f6a5bb39 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -17,6 +17,7 @@ stages: allow_failure: true script: - $DOCKER_CMD login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.labs.nic.cz + - $DOCKER_CMD --rm --privileged aptman/qus -s -- -p mips # Make sure we refresh the base image if it updates (eg. security updates, etc) # If we do just the build, cache is always reused and the freshness of the # base image is never checked. However, pull always asks and updates the @@ -52,6 +53,11 @@ docker_debian-9-i386: IMG_NAME: "debian-9-i386" <<: *docker_build +docker_debian-9-mips: + variables: + IMG_NAME: "debian-9-mips" + <<: *docker_build + docker_debian-10-amd64: variables: IMG_NAME: "debian-10-amd64" @@ -248,6 +254,10 @@ build-debian-9-i386: <<: *build-linux image: registry.labs.nic.cz/labs/bird:debian-9-i386 +build-debian-9-mips: + <<: *build-linux + image: registry.labs.nic.cz/labs/bird:debian-9-mips + build-debian-10-amd64: <<: *build-linux image: registry.labs.nic.cz/labs/bird:debian-10-amd64 diff --git a/misc/docker/debian-9-mips/Dockerfile b/misc/docker/debian-9-mips/Dockerfile new file mode 100644 index 00000000..1600011b --- /dev/null +++ b/misc/docker/debian-9-mips/Dockerfile @@ -0,0 +1,26 @@ +FROM multiarch/debian-debootstrap:mips-stretch-slim +ENV DEBIAN_FRONTEND noninteractive +RUN sed -i 's/deb.debian.org/ftp.cz.debian.org/' /etc/apt/sources.list +RUN apt-get -y update +RUN apt-get -y upgrade +RUN apt-get -y --no-install-recommends install \ + build-essential \ + flex \ + bison \ + autoconf \ + ncurses-dev \ + libreadline-dev \ + libssh-gcrypt-dev \ + linuxdoc-tools-latex \ + texlive-latex-extra \ + opensp \ + docbook-xsl \ + xsltproc +RUN apt-get -y --no-install-recommends install \ + git \ + dpkg-dev \ + debhelper \ + quilt \ + python3 \ + python3-pip \ + python3-setuptools -- 2.26.3

2 6

BIRD Setup for B.A.T.M.A.N. Advanced network.
by Maurice Smulders 06 Aug '21

06 Aug '21

Network description (simplest form) Two internet gateways GW1: 192.168.30.1/24, DHCP Range 192.168.30.10 ... 192.168.30.39 GW2: 192.168.30.2/24, DHCP Range 192.168.30.40... 192.168.30.70 Both GWs are connected to internet, and are running DNSMasq Client: does a DHCP Request, happens to get 192.168.30.56 , so from GW2 Failure scenarios - GW2 goes down fully - Upstream internet link to GW2 is severed Can BIRD be used to deal with this, i.e. for example have a script / bird ping some known Internet DNS servers, like Google's 8.8.8.8 and 8.8.4.4 and force the client to switch over to GW1 to get a valid internet connection again as fast as possible? For simplicity, I'm looking at RIPv2 - network is small enough, or should I use OSPF? I'm looking for some suggestions/recommendations... Maurice

3 2

How can I set krt_realm in the kernel protocol by gw (nexthop) value?
by Eric Wheeler 30 Jul '21

30 Jul '21

Hello all, I would like to put routes in realms for traffic accounting based on the peer IP provided by a BGP route server on an exchange. I was thinking I could do something like this, but bird gives errors like "syntax error, unexpected KRT_REALM": filter gw_realms { if gw = 1.1.1.1 then return 1; if gw = 2.2.2.2 then return 2; if gw = 3.3.3.3 then return 3; return 0; } protocol kernel kernel_ipv4 { ipv4 { krt_realm filter peer_realms; }; } What is a proper way to dynamically set the krt_realm attribute per gw? Thank you for your help! -- Eric Wheeler

2 2

ospf external type 2 and igp_metric
by Dave Johnson 29 Jul '21

29 Jul '21

Hi, I'm trying to get igp_metric to work for iBGP based on an OSPF metric. Here's my setup: I'm using OSPF for an IGP, eBGP on border machines for internet routes, and iBGP within to select the best border for traffic not covered internally with OSPF. OSPF is using connected IPs for broadcast and tunnel interfaces and each machine also includes a static loopback IP for general communication including iBGP. iBGP is setup to communicate from/to each machine's loopback IP to be immune from any connected network or tunnel disruption. OSPF is propigating reachability to each loopback just ok. I would like to make use of the iBGP igp_metric as a tie-breaker if BGP gets down that far in the route selection process, however I can't seem to get BGP to pick up the OSPF metric for other machine's loopbacks. The loopback is being imported using a proto direct as it's simply from Linux's lo interface: root@archer:~# birdc show route 10.10.10.30/32 all BIRD 1.6.6 ready. 10.10.10.30/32 dev lo [direct1 11:14:34] * (240) Type: device unicast univ root@archer:~# When viewed from another machine via ospf, this route now shows as an external type 2 route. The OSPF.metric1 of 26 is correct: root@ganges:~# birdc show route 10.10.10.30/32 all BIRD 1.6.6 ready. 10.10.10.30/32 via 10.10.13.1 on tun13 [ospf1 11:14:35] * E2 (150/26/10000) [10.10.10.30] Type: OSPF-E2 unicast univ OSPF.metric1: 26 OSPF.metric2: 10000 OSPF.tag: 0x00000000 OSPF.router_id: 10.10.10.30 root@ganges:~# So when I'm trying to use iBGP this OSPF.metric1 should be taken into account as the igp_metric right? I would expect this to work based on rt_get_igp_metric() however that function doesn't include pulling an OSPF metric from RTS_OSPF_EXT2 type routes (only type 1). #ifdef CONFIG_OSPF if ((a->source == RTS_OSPF) || (a->source == RTS_OSPF_IA) || (a->source == RTS_OSPF_EXT1)) return rt->u.ospf.metric1; #endif Is there some reason RTS_OSPF_EXT2 isn't included here? Even RTS_OSPF_EXT2 routes have an OSPF.metric1. For example, here's an arbitrary internet route that has equal local preference, equal path lengths, both IGP, no MED, etc.. so igp would be a deciding factor here. 10.10.10.30 and 10.10.10.31 are border routers, and this command is run on a interior router: root@ganges:~# birdc show route 128.0.128.0/20 table internet all BIRD 1.6.6 ready. 128.0.128.0/20 via 10.10.13.1 on tun13 [bgp_archer 14:50:00 from 10.10.10.30] * (100/?) [AS25513i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 64515 65534 20473 8359 25513 BGP.next_hop: 10.10.10.30 BGP.local_pref: 100 BGP.community: (20473,200) (64515,44) via 10.10.13.1 on tun13 [bgp_reliant 14:50:00 from 10.10.10.31] (100/?) [AS25513i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 65002 65001 21700 8359 25513 BGP.next_hop: 10.10.10.31 BGP.local_pref: 100 BGP.community: (0,199) (8359,100) (8359,5500) (8359,55277) BGP.large_community: (21700, 101, 3) (21700, 102, 840) (21700, 103, 1) root@ganges:~# birdc show route 10.10.10.30/32 all BIRD 1.6.6 ready. 10.10.10.30/32 via 10.10.13.1 on tun13 [ospf1 11:14:35] * E2 (150/26/10000) [10.10.10.30] Type: OSPF-E2 unicast univ OSPF.metric1: 26 OSPF.metric2: 10000 OSPF.tag: 0x00000000 OSPF.router_id: 10.10.10.30 root@ganges:~# birdc show route 10.10.10.31/32 all BIRD 1.6.6 ready. 10.10.10.31/32 via 10.10.13.1 on tun13 [ospf1 2021-07-26] * E2 (150/15/10000) [10.10.10.31] Type: OSPF-E2 unicast univ OSPF.metric1: 15 OSPF.metric2: 10000 OSPF.tag: 0x00000000 OSPF.router_id: 10.10.10.31 root@ganges:~# Note that the igp_metric is '?' for both, and the route via 10.10.10.30 is selected even though the OSPF metric is higher for that. I've tried to work around type by doing 2 things: 1st, trying to get the routes to show up as an external type 1 instead of type 2, but I dont see how in the config. 2nd, setting igp_metric manually in an import/export filter, however that doesn't seem to work either. I'm using debian's bird 1.6. Thoughts? -- Dave

2 2