- Bird-users - Mailing Lists

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

BIRD 2.0.8
by Ondrej Filip 14 Apr '21

14 Apr '21

Hello! I have great news for you! My colleagues did a fantastic job and after a while we can present a new BIRD release - 2.0.8. Here is a list of changes: o Automatic channel reloads based on RPKI changes o Multiple static routes with the same network o Use bitmaps to keep track of exported routes o Per-channel debug flags o CLI commands show info from multiple protocols o Linux: IPv4 routes with IPv6 nexthops o Filter: Optimized redesign of prefix sets o Filter: Improved type checking of user filters o Filter: New src/dst accessors for Flowspec and SADR o Filter: New 'weight' route attribute o Filter: BGP path mask loop operator o Filter: Remove quitbird command o RIP: Demand circuit support (RFC 2091) o BGP: New 'allow as sets' and 'enforce first as' options o BGP: Support for BGP hostname capability o BGP: Support for MD5SIG with dynamic BGP o BFD: Optional separation of IPv4 / IPv6 BFD instances o BFD: Per-peer session options o RPKI: Allow build without libSSH o RPKI: New 'ignore max length' option o OSPF: Redesign of handling of unnumbered PtPs o OSPF: Allow key id 0 in authentication o Babel: Use onlink flag for routes with unreachable next hop o Many bugfixes Notes: Automatic channel reloads based on RPKI changes are enabled by default, but require import table enabled when used in BGP import filter. BIRD now uses bitmaps to keep track of exported routes instead of re-evaluation of export filters. That should improve speed and accuracy in route export handling during reconfiguration, but takes some more memory. Per-channel debug logging and some CLI commands (like 'show ospf neighbors') defaulting to all protocol instances lead to some minor changes in log and CLI output. Caution is recommended when logs or CLI output are monitored by scripts. So please test it, run it and write your feedback! Cheers Ondrej

15 62

Re: BIRD 2.0.8
by Jakub Ružička 14 Apr '21

14 Apr '21

On 4/14/21 4:24 PM, Ondrej Zajicek wrote: > On Wed, Apr 14, 2021 at 12:45:28PM +0200, Jakub Ružička wrote: >> Oh, I see! I checked history and this versioned requirement was added as >> part of "Bump the dephelper compatibilty level to 12" in Debian package >> which is a change specific to latest debian release. It's quite likely >> that this specific version isn't in fact required so I removed the (>= >> 1.56~) part - it's always worth a try with default available system >> init-system-helpers. I see overly strict requires like this often when >> doing cross-distro packaging. Sometimes they are introduced to dodge >> specific bug but older version might still work. > Hi, some time ago i built Debian packages for older Debians (8, 9) and > did some modifications (including decreasing debhelper compatibility > level) in order to work with unmodified system (without upgrading > init-system-helpers from Backports). It worked without problems (with > init-system-helpers >= 1.22~ requirement), but needed some modifications > to Debian control files. I've also carried out these modifications, see my other thread "BIRD 2.0.8 packaging update", specifically the opened MR: https://gitlab.nic.cz/labs/bird/-/merge_requests/25 These changes would be even more useful if scripts/make-dev-archive.sh (or equivalent script in bird repo) was adjusted to generate same archive from current git repo that is used for official tarballs - maybe you know how that's done? > > So it seems to me that in order to build packages for multiple Debian > versions the simplest way is to have multiple Debian control files. That initially looks like the simplest way but it turns out to be quite the contrary in the long run. If we maintained one branch for each currently active Fedora, Debian, and Ubuntu release we would already be at ~12 branches and that's not counting other distros and their releases. Downstream packaging is already maintained that way and it introduces noticeable burden so for upstream packaging it's easier to have shared packaging sources if possible. Knot DNS and Knot Resolver projects (as well as many others in the wild) have been using shared packaging sources successfully for quite some time and apkg is my effort to create universal standard and format for upstream cross-distro packaging. Using shared packaging files for multiple distros is certainly challenging but I assure you it's *significantly* more manageable than juggling tens of separate diverging packaging branches for each distro release(!). That work is already done by downstream packagers and duplicating it centrally in upstream brings no benefits, only huge amount of overhead. In addition to downstream packaging which is targeted and specialized for individual distro releases, upstream packaging should IMHO be as general as possible in order to work everywhere. It should allow developers to easily build and test packages from source at any point of development and on any system as well as easily provide users with fresh packages when needed (i.e. when when downstream packages aren't available yet). Cheers, Jakub

1 0