- Bird-users - Mailing Lists

Per-route MTU for static route
by Tibor Kiss 05 May '21

05 May '21

Hello All, I wanted to configure per-route MTU for a static route, something I'd configure manually like this: ip route add 10.88.152.0/24 mtu 1600 \ nexthop via 172.17.3.1 \ nexthop via 172.17.3.2 Which would result in this: [root@workerbm-6 ~]# ip route <...> 10.88.152.0/24 mtu 1600 nexthop via 172.17.3.1 dev vlan97 weight 1 nexthop via 172.17.3.2 dev vlan97 weight 1 I figured this is not possible with BIRD right now, MTU cannot be defined for a static route. Did I miss something? Or any chance this would be added in the future? Thank you, Tibor

2 2

Missing bable routes after configure - bug in bird 2.0.8?
by Nico Schottelius 30 Apr '21

30 Apr '21

Hello, we are using direct + babel as an IGP and today something "funky" happened: the routes of one router disappeared and on other routers the babel entries contained empty router IDs in babel: bird> show babel entries babel1: Prefix Router ID Metric Seqno Routes Sources 185.203.114.0/23 00:00:00:00:93:4e:c3:fb 0 2204 4 0 195.141.230.102/31 <none> - - 1 0 185.203.112.0/24 <none> - - 2 0 147.78.195.224/27 00:00:00:00:93:4e:c3:fb 0 2204 7 0 193.192.225.72/31 <none> - - 1 0 94.78.2.168/29 00:00:00:00:93:4e:c3:fb 0 2204 4 0 147.78.195.0/29 <none> - - 1 0 185.155.31.0/24 00:00:00:00:93:4e:c3:fb 0 2204 4 0 45.134.132.0/29 00:00:00:00:93:4e:c3:fb 0 2204 4 0 185.155.31.0/26 00:00:00:00:93:4e:c3:fb 0 2204 4 0 2a0a:e5c0:1:f::/64 <none> - - 1 0 2a0a:e5c0:1:e::/64 <none> - - 1 0 2a0a:e5c0:1:d::/64 00:00:00:00:93:4e:c3:fb 0 2204 5 0 2a0a:e5c0:0:9::/64 00:00:00:00:00:00:00:2f 96 1 1 0 2a0a:e5c0:1:8::/64 00:00:00:00:93:4e:c3:fb 0 2204 10 0 2a0a:e5c0:0:6::/64 00:00:00:00:00:00:00:2e 96 2 1 0 2a0a:e5c0:0:5::/64 <none> - - 2 0 2a0a:e5c0:0:4::/64 00:00:00:00:00:00:00:2f 96 1 1 0 2a0a:e5c0:1:4::/64 00:00:00:00:93:4e:c3:fb 0 2204 5 0 2a0a:e5c0:0:3::/64 00:00:00:00:00:00:00:2e 96 2 1 0 2a0a:e5c0:0:2::/64 <none> - - 2 0 2a0a:e5c0:2:2::/64 00:00:00:00:93:4e:c3:fb 0 2204 5 0 2a0a:e5c0:10:1::/64 <none> - - 1 0 After restarting the router, the entries are correct now (router id 00:00:00:00:93:4e:c3:e3): bird> show babel entries babel1: Prefix Router ID Metric Seqno Routes Sources 185.203.114.0/23 00:00:00:00:93:4e:c3:fb 0 2204 4 0 195.141.230.102/31 <none> - - 1 0 185.203.112.0/24 <none> - - 2 0 147.78.195.224/27 00:00:00:00:93:4e:c3:fb 0 2204 7 0 193.192.225.72/31 <none> - - 1 0 94.78.2.168/29 00:00:00:00:93:4e:c3:fb 0 2204 4 0 147.78.195.0/29 00:00:00:00:93:4e:c3:e3 96 1 1 0 185.155.31.0/24 00:00:00:00:93:4e:c3:fb 0 2204 4 0 45.134.132.0/29 00:00:00:00:93:4e:c3:fb 0 2204 4 0 185.155.31.0/26 00:00:00:00:93:4e:c3:fb 0 2204 4 0 2a0a:e5c0:1:f::/64 00:00:00:00:93:4e:c3:e3 96 1 1 0 2a0a:e5c0:1:e::/64 00:00:00:00:93:4e:c3:e3 96 1 1 0 2a0a:e5c0:1:d::/64 00:00:00:00:93:4e:c3:fb 0 2204 5 0 2a0a:e5c0:0:9::/64 00:00:00:00:00:00:00:2f 96 1 1 0 2a0a:e5c0:1:8::/64 00:00:00:00:93:4e:c3:fb 0 2204 10 0 2a0a:e5c0:0:6::/64 00:00:00:00:00:00:00:2e 96 2 1 0 2a0a:e5c0:0:5::/64 <none> - - 2 0 The "funny" part is that bird 2.0.8 on that router was up and running, it did see babel neighbors, it did BGP, however only after restarting bird, the routes were correctly received be neighboring routers. As you can see in above table there is at least another router that is affected. I tried `disable babel1` and `enable babel1` on it, however that did not fix the problem. We did some amount of `configure` commands on the bird process, but my understanding was that it should be very similar to restarting it, without the loss of sessions. The babel protocol *did* previously export the routes correctly to other routers, but I am 99% sure that it did stop doing it, until we hard restarted bird. The babel configuration we use on most of our routers looks like this: protocol direct { ipv4; ipv6; interface "bond0.*"; } protocol babel { interface "bond0.*" { type wired; }; ipv4 { export where (source = RTS_DEVICE); }; ipv6 { export where (source = RTS_DEVICE); }; } So we are not re-babling like babeld, but only inject local device routes, as we have 2 redundant routers per network. Is there a conceptual problem or is this a bug in bird 2.0.8 and in either way, is there anything we can do to fix it besides restarting bird on router propagation error? Best regards, Nico p.s.: In case it matters, we are running bird on alpine/musl. -- Sustainable and modern Infrastructures by ungleich.ch

2 3

I admit I am rookie to IP routing. Looking for a little bet of simple help configuring BIRD for simple routing.
by Myron 29 Apr '21

29 Apr '21

I am trying to learn how to set-up a router and maintain a configuration and I'm hoping someone can help me. I'm that sort of person who learns by example. The configuration is a bit nn standard and will be only used on a local area network. Essentially, how would I configure BIRD to route everything except DHCP traffic between networks 192.168.0.0/16, 192.168.30.0/16, 192.168.31.0/16 and packets for any other network get sent to 192.168.0.1? So, as an example, a device on 192.168.31.4 can talk to 192.168.0.33? All using a subnet mask of 255.255.255.0. I will try and read through the user guide, but at this moment I'm not sure what I need to do to get it to work.

3 3

Configure igmp/pim using BIRD
by Dhruv Bhagadia 26 Apr '21

26 Apr '21

Hi all, Thanks Ondrej for giving insights to my previous query. Your guess as to the neighbor AS having low hold time was correct and when I reduced keep-alive time on my end, I could bypass the Hold timer expired issue. I write this mail to address another query of mine. Is it possible to configure multicast routing protocols like igmp/pim through BIRD. I saw on the future work page that support for multicasting protocol is yet to be added to BIRD, also couldn't find the protocol implementation in the source code still wanted to confirm. If the support is not added can I make use of some other already supported routing protocol to address the issue? I want the server on which BIRD is configured to listen to mcast data. Also, on researching I could find out this thesis <https://is.cuni.cz/webapps/zzp/download/130183774> Do we plan to in-coporate these changes into BIRD anytime soon? Thanking you, Dhruv Bhagadia.

1 0

Not able to configure bgp with BIRD
by Dhruv Bhagadia 23 Apr '21

23 Apr '21

Hi all, I was trying to configure bgp using BIRD on a server running rhel 7.6. The issue I am facing is that the neighbor AS seems to be rejecting the routes sent by my local AS. However, my server seems to be learning routes sent by the neighbor AS router. Have provided some details from the logs below. I wanted to ask what could be the probable reason that the remote is rejecting the packets? 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.1.192/28 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.1.192/28 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.1.200/30 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.1.200/30 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.1.200/29 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.1.200/29 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.1.201/32 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.1.201/32 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.42.0/24 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.42.0/24 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.43.0/24 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.43.0/24 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.44.0/24 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.44.0/24 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.48.0/24 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.48.0/24 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.42.101/32 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.42.101/32 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.42.102/32 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.42.102/32 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.42.103/32 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.42.103/32 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.42.104/32 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.42.104/32 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.42.105/32 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.42.105/32 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.43.101/32 via 10.33.5.33 on enp26s0d1 In consequence to this, BIRD throws an error after sometime saying `*bgp1: Error: Hold timer expired *` and `bgp1: Received: Hold timer expired` However from the logs I figured out that the difference between most latest KEEPALIVE message and the error being thrown is 2 secs. Since I have set HOLD time to 180 sec in config shouldn't this error be never thrown since the KEEPALIVE message will reset it? Sharing that logs too below 2021-04-22 20:12:44 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:45 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:46 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:47 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:48 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:49 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:50 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:51 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:53 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:53 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:55 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:56 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:57 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:59 <RMT> bgp1: Error: Hold timer expired I am new to configuring routing and hence my understanding can be wrong somewhere. Please feel free to correct me and ask for more details if required. Thanks in advance. Thanking you, Dhruv Bhagadia.

2 2

All BFD sessions are handled on single thread?
by Sema Boyko 20 Apr '21

20 Apr '21

Hi, I have the following configuration on one of my servers ("10.1.0.1"): *protocol bfd { interface "eth0" { min rx interval 200 ms; min tx interval 1000 ms; idle tx interval 1 s; multiplier 5; }; neighbor 10.1.0.2; neighbor 10.1.0.3; neighbor 10.1.0.4; ** ..... (here about 1000 records)* * neighbor 10.1.3.251;* * neighbor 10.1.3.252;* * neighbor 10.1.3.253;* * neighbor 10.1.3.254;* *}* And I configured the second server ("10.1.0.2") as a neighbor with the following config: *protocol bfd { interface "eth0" { min rx interval 200 ms; min tx interval 1000 ms; idle tx interval 1 s; multiplier 5; }; neighbor 10.1.0.1;}* For some reason I have random session expire events on the second server and BFD sessions get UP -> DOWN, DOWN -> UP events. *bird: bfd1: Session to 10.1.0.1 expiredbird: bfd1: Session to 10.1.0.1 changed state from Init to Downbird: bfd1: Session to 10.1.0.1 changed state from Down to Initbird: bfd1: Session to 10.1.0.1 expiredbird: bfd1: Session to 10.1.0.1 changed state from Init to Downbird: bfd1: Session to 10.1.0.1 changed state from Down to Init* This happens only if I specify a lot of neighbors in the config. For example the following config on first server ("10.1.0.1") works fine: *protocol bfd { interface "eth0" { min rx interval 200 ms; min tx interval 1000 ms; idle tx interval 1 s; multiplier 5; }; neighbor 10.1.0.2; neighbor 10.1.0.3;}* Looks like all BFD sessions are handled on a single thread. Could someone, please, confirm that BIRD isn't designed to handle a huge amount of BFD sessions simultaneously? Or possibly I can enable some options to handle this case in my env?

4 4

[PATCH] babel: Drop check for IF_MULTICAST interface flag
by Toke Høiland-Jørgensen 19 Apr '21

19 Apr '21

The babel protocol code was checking interfaces for the IF_MULTICAST flag and refusing to run if this isn't present. However, there are cases where this flag doesn't correspond to the actual capability of sending multicast packets. For instance, Wireguard interfaces on FreeBSD doesn't set the required flags, but Babel will run just fine over such an interface given the right configuration. Since we're also checking for the presence of a link-local addresses right below the flag check, we don't really need it. So let's just drop the check and trust that users will only configure Babel on interfaces that can handle the traffic. Reported-by: Stefan Haller <stefan.haller(a)stha.de> Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- proto/babel/babel.c | 8 -------- 1 file changed, 8 deletions(-) diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 4b6b9d7f9f6f..297b86b06a46 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -1658,10 +1658,6 @@ babel_if_notify(struct proto *P, unsigned flags, struct iface *iface) if (!(iface->flags & IF_UP)) return; - /* We only speak multicast */ - if (!(iface->flags & IF_MULTICAST)) - return; - /* Ignore ifaces without link-local address */ if (!iface->llv6) return; @@ -1736,10 +1732,6 @@ babel_reconfigure_ifaces(struct babel_proto *p, struct babel_config *cf) if (!(iface->flags & IF_UP)) continue; - /* Ignore non-multicast ifaces */ - if (!(iface->flags & IF_MULTICAST)) - continue; - /* Ignore ifaces without link-local address */ if (!iface->llv6) continue; -- 2.31.1

2 4

CI: distro releases coverage
by Jakub Ružička 19 Apr '21

19 Apr '21

Hello, I was pleased to discover BIRD has a very good distro coverage in its [CI] (~25 different releases). [CI] https://gitlab.nic.cz/labs/bird/-/pipelines However, some latest releases are missing so I suggest adding support for following currently officially supported distros when opportunities arise: * Ubuntu 20.04 Focal Fossa - latest LTS * Ubuntu 20.10 Groovy Gorilla - latest release * Fedora 32 * Fedora 33 - latest release * Fedora 34 (optional) is already branched in preparation for release soon, you can consider enabling it too already * openSUSE 15.2 (optional) * openSUSE 15.3 - latest release * openSUSE Tumbleweed - rolling release (optional) Also, following distros are either at End of Life or close and can be removed: * Fedora 25 - 31 EOL * Ubuntu 14.04 EOL (16.04 soon) * Debian 8 is two releases and 6 years old with Debian 11 releasing soon There is nothing wrong with testing older releases as long as they don't slow down development by requiring backports and hacks. In such case it might be a better choice to simply drop support/disable CI for that EOL distro as opposed to wasting time backporting to dead platforms. Cheers, Jakub Ružička CZ.NIC packager 📦

2 1

[PATCH] BSD: Fix invalid pointer derefence in logging code
by Stefan Haller 19 Apr '21

19 Apr '21

For logging purposes a stack allocated net_addr struct was passed by value as vararg (instead of the expected pointer). This resulted in a segfault when the specific error condition got logged. --- sysdep/bsd/krt-sock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sysdep/bsd/krt-sock.c b/sysdep/bsd/krt-sock.c index c2faa23d..ea0cc4d9 100644 --- a/sysdep/bsd/krt-sock.c +++ b/sysdep/bsd/krt-sock.c @@ -453,7 +453,7 @@ krt_read_route(struct ks_msg *msg, struct krt_proto *p, int scan) net_fill_ip4(&ndst, ipa_to_ip4(idst), pxlen); if ((flags & RTF_GATEWAY) && ipa_zero(igate)) - { log(L_ERR "%s (%N) - missing gateway", errmsg, ndst); return; } + { log(L_ERR "%s (%N) - missing gateway", errmsg, &ndst); return; } u32 self_mask = RTF_PROTO1; u32 alien_mask = RTF_STATIC | RTF_PROTO1 | RTF_GATEWAY; -- 2.31.1

2 1

Bird 2.0.7 and Bird 2.0.8 config comparability
by Skyler Mäntysaari 19 Apr '21

19 Apr '21

Hi there, Is it just me or does 2.0.8 bring breaking changes to config structure? The following function does not appear to work anymore. -------------------------------------------------------------- function prefix_is_bogon() { if net.type = NET_IP4 then if net ~ BOGONS_4 then return true; if net.type = NET_IP6 then if net ~ BOGONS_6 then return true; return false; } ------------------------------------------------------------- Neither does: ------------------------------------------------------------- # --- RPKI --- roa4 table RPKI4; roa6 table RPKI6; protocol rpki { roa4 { table RPKI4; }; roa6 { table RPKI6; }; remote "<snip>" port 8083; retry keep 90; refresh keep 900; expire keep 172800; } ------------------------------------------------------------------ The RPKI one complains about the roa tables.

1 1