April 2020 - Bird-users - Mailing Lists

Different OSPF behaviour between Static and Kernel/Pipe
by Asher Baker 07 Apr '20

07 Apr '20

Hi all! I've got a small mesh deployment using BIRD 2.0.7 and OSPFv2 which has been working well for a while now distributing a mix of device and static routes going into the kernel table export-only. I've now run into a need to have a number of "dynamic" static routes managed by an external system and was looking into using a 2nd import-only kernel routing table for that managed via netlink rather than constantly reloading BIRD - but I've run into an issue where things aren't behaving as I'd expect when multiple routers advertise the same route sourced from the kernel protocol. What I'm seeing is that when the route gets added on the first router, it gets exported via BIRD to the kernel table as directly connected (as specified) and on the other router as a next-hop of the first router (as you'd expect). But when the same route is added on the other router (while still on the first one), the kernel routing table of the 2nd router does not change to be direct, it keeps the next-hop of the 1st router. However, if I specify the exact same routes in the static protocol and reload BIRD, everything works correctly and both routers end up with a direct route in the kernel table! (and other routers in the area get multi-path routes via the ones that have it added.) I think I've tracked the behaviour difference down to how they're being added / appearing in OSPF, but I'm not sure why they might be behaving differently (it's as if the static routes get merged with what is already in the table, but the pipe isn't doing that) - I've included the config and some command output: BIRD config (the same apart from id/prefsrc on both I'm testing with, trimmed out of the "production" config which also includes PtMP neighbours on remote routers): router id 172.19.4.2; debug protocols { states, routes, filters, interfaces, events }; ipv4 table clustr; protocol device { } protocol direct { ipv4; interface "ens224"; } protocol kernel { ipv4 { import none; export filter { krt_prefsrc = 172.19.4.2; accept; }; }; merge paths yes; } protocol kernel { ipv4 { table clustr; import all; export none; }; scan time 2; learn yes; kernel table 100; } protocol pipe { table master4; peer table clustr; import all; export none; } protocol ospf v2 { ipv4 { import all; export where dest != RTD_UNREACHABLE; }; area 0 { interface "ens224" { bfd yes; }; }; ecmp yes; merge external yes; } protocol bfd { interface "ens*" { min rx interval 100 ms; min tx interval 200 ms; idle tx interval 1000 ms; }; } protocol static { ipv4; route 172.27.0.0/19 via "ens224"; route 10.0.0.0/8 unreachable; route 100.64.0.0/10 unreachable; route 169.254.0.0/16 unreachable; route 172.16.0.0/12 unreachable; route 192.168.0.0/16 unreachable; } Initial OSPF state: [root@ukdev-bastion-003 ~]# birdc show ospf state all BIRD 2.0.7 ready. area 0.0.0.0 router 172.19.4.2 distance 0 network 172.19.0.0/19 metric 10 stubnet 172.19.2.2/32 metric 0 external 172.19.2.2/32 metric2 10000 external 172.19.0.0/19 metric2 10000 external 172.27.0.0/19 metric2 10000 router 172.19.4.3 distance 10 network 172.19.0.0/19 metric 10 stubnet 172.19.2.3/32 metric 0 external 172.19.2.3/32 metric2 10000 external 172.19.0.0/19 metric2 10000 external 172.27.0.0/19 metric2 10000 network 172.19.0.0/19 dr 172.19.4.2 distance 10 router 172.19.4.2 router 172.19.4.3 Adding a test route on the first router: [root@ukdev-bastion-003 ~]# ip route add 192.168.0.100/32 table 100 dev ens224 proto static metric 32 To avoid overwhelming everyone with lots of repeated birdc show ospf state all output (but do ask if anything would be useful!) I'll describe what happens then: 1. The route shows up in the router section it was added for as an external (as I'd expect). 2. When the same route is added on the 2nd router, there is no change to the OSPF state. 3. When the route is removed from the 1st router (while still on the 2nd) the external is removed from the first router and appears on the 2nd one! 4. Finally, removing it from the 2nd router causes the external to disappear from the OSPF state. The kernel routing table behaviour (described previously) behaves exactly as I'd expect given what OSPF is doing here. But that isn't what I'm trying to achieve, at step 2 I would expect the external network to be registered by both routers simultaneously - and this is how it behaves if the route is configured using the static protocol (as you can see with the 172.27.0.0/19 route). If anyone has any insight as to what I might be doing wrong here (or other ways of accomplishing the same goal) it would be greatly appreciated! I'm no expert and mostly just muddling my way through :) Many thanks, Asher P.S. I think a API-based routing protocol as discussed on the list a few years back would be really cool to see for this sort of stuff. ~~~~~ "Their heads are green, and their hands are blue, And they went to sea in a Sieve." - Edward Lear

1 0

stupid question about OSPF cost and route preference
by Eugene M. Zheganin 07 Apr '20

07 Apr '20

Hello. I have a bunch of birder routers, and the troublesome router is connected to some of them via LAN and to some of them via WAN tunnels. For some reason it always chooses a WAN route, regardless of it's metric: ===Cut=== bird> show route for 10.50.3.0/24 10.50.3.0/24 via 172.16.0.45 on gif1 [ospfv4 18:25:39] * E2 (150/10222/10000) [192.168.57.254] [root@gw /usr/local/etc]# ifconfig gif1 down [root@gw /usr/local/etc]# birdc BIRD 1.6.6 ready. bird> show route for 10.50.3.0/24 10.50.3.0/24 via 192.168.57.254 on vlan57 [ospfv4 18:33:37] * E2 (150/11/10000) [192.168.57.254] [root@gw /usr/local/etc]# ifconfig gif1 up [root@gw /usr/local/etc]# birdc BIRD 1.6.6 ready. bird> show route for 10.50.3.0/24 10.50.3.0/24 via 172.16.0.45 on gif1 [ospfv4 18:34:01] * E2 (150/10222/10000) [192.168.57.254] bird> ===Cut=== And I totally don't understand why (OSPF cost is several times higher !). Config is as follows: === Cut=== filter importospfv4 { if net ~ [ 10.8.1.0/24 ] then { reject; } else { accept; } } filter exportospfv4 { if net ~ [ 192.168.55.254/32, 192.168.57.2/32 ] then { reject; } else { accept; } } protocol ospf ospfv4 { export filter exportospfv4; import filter importospfv4; area 0.0.0.0 { interface "vlan55" { cost 11; }; interface "vlan57" { cost 11; }; }; area 0.0.0.1 { interface "gif0"{ cost 5111; }; interface "gif1" { cost 5111; }; }; } ===Cut=== Thanks. Eugene.

2 3

BGP communities
by Fabiano D'Agostino 06 Apr '20

06 Apr '20

Good evening, could someone explain me the meaning of these lines? function bgp_out(int peeras) { if ! (source = RTS_BGP ) then return false; if peeras > 65535 then return true; ### communities do not support AS32 if (0,peeras) ~ bgp_community then return false; if (myas,peeras) ~ bgp_community then return true; if (0, myas) ~ bgp_community then return false; return true; } Thanks, Fabiano

4 15

bird 2.0: show only IPv4 or IPv6 routes from birdc
by Craig Leres 06 Apr '20

06 Apr '20

We've been using bird 1.6.8 to advertise nullzero routes from a FreeBSD box to our routers for awhile. (We use quagga to the same for IPv4.) We're in the process of upgrading to 2.0.7 and will use bird for IPv4 and IPv6. I'm so far unable to come up with good ways of dumping only IPv4 or IPv4 routes. I can't even find concrete examples of what's possible. A filter example I found is: https://bird.network.cz/?get_doc&v=20&f=bird-5.html#ss5.3 show route filter { if 127.0.0.5 ~ net then accept; } So I for IPv6 I tried: show route filter { if net.len = 128 then accept; } which works but it logs error messages: Filter (unnamed) did not return accept nor reject. Make up your mind This works without errors: show route filter { if net.len = 128 then accept; reject; } As does: show route where net.len = 128 Both seem like hacks to me and do not allow unambiguous printing of IPv4 routes: show route where net.len = 32 In my case I know I won't have any IPv6 routes that are 32 bits but there must be a better way. I also found: show route table master4 show route table master6 I'd rather not depend on the names of default routing tables. I suppose I could explicitly import the kernel routes into v4 and v6 tables but routing works without this extra complexity. One experiment I tried was: show route filter { print "net.type is ", net.type; } which logs 1 or 2 for IPv4 or IPv6: bird: net.type is (enum 36)1 bird: net.type is (enum 36)2 but the obvious commands do not print any routes: show route where net.type = 1 show route where net.type = 2 And anyway I couldn't find any keywords for ipv4 and ipv6. What's the magic I'm missing? How can I dump only IPv4 or dump only IPv6 routes? Craig

2 1

BFD state stuck in INIT
by Nisha Nair 06 Apr '20

06 Apr '20

Hello all, I am using bird 1.6.3 on OpenWRT to use BFD. This is our setup: Ubuntu m/c(BIRD running, BFD configured, interface enp2s0) ----------------------------> OpenWRT Box(BIRD running, BFD configured, interface br-lan) The bird configuration on OpenWRT: protocol device { scan time 10; } protocol bfd { neighbor 172.16.2.4; } Bird configuration on Ubuntu m/c: protocol device { debug all; scan time 10; } protocol kernel { scan time 10; metric 64; # Use explicit kernel route metric to avoid collisions # with non-BIRD routes in the kernel routing table import none; # export all; # Actually insert routes into the kernel routing table } protocol bfd { debug all; interface "enp2s0"; neighbor 172.16.2.1; } When the enp2s0 interface IP on the Ubuntu m/c is changed continuously using the ifconfig command, we can see that after few tries, the bfd session state is stuck at INIT and only a restart of the bird4 daemon brings the bfd session UP. Enabling the bfd debugs on the PC shows the following error: bird: bfd1: Socket error: bind: Cannot assign requested address Debug logs on the Ubuntu m/c: bird: bfd1: Sending CTL to 172.16.2.1 [Up] bird: bfd1: CTL received from 172.16.2.1 [Up] bird: bfd1: Sending CTL to 172.16.2.1 [Up] bird: bfd1: Session to 172.16.2.1 removed bird: bfd1: Session to 172.16.2.1 added bird: bfd1: Sending CTL to 172.16.2.1 [Down] bird: bfd1: Sending CTL to 172.16.2.1 [Down] bird: bfd1: Sending CTL to 172.16.2.1 [Down] bird: bfd1: Session to 172.16.2.1 removed bird: bfd1: Socket error: bind: Cannot assign requested address bird: bfd1: Session to 172.16.2.1 added bird: bfd1: CTL received from 172.16.2.1 [Down] bird: bfd1: Session to 172.16.2.1 changed state from Down to Init bird: bfd1: CTL received from 172.16.2.1 [Down] bird: bfd1: CTL received from 172.16.2.1 [Down] bird: bfd1: CTL received from 172.16.2.1 [Down] bird: bfd1: CTL received from 172.16.2.1 [Down] bird: device1: Scanning interfaces It looks like a timing issue as the number of times we need to change the interface IP to reproduce the issue is different each time, but it is reproduced consistently. These are the steps we repeated on our Ubunutu PC till the state show INIT and is stuck there: 1. ifconfig enp2s0 192.168.2.44 2. ifconfig enp2s0 192.168.2.4 3. birdc4 show bfd session The post https://bird.network.cz/pipermail/bird-users/2020-January/014183.html reports the same issue. There seems to be no suggestions on the thread. It would be really helpful if you could look in to this and let me know if there is any workaround for this problem other than a restart, because we have a script running which polls the bfd status and reports to the application above. It does not seem sensible to just restart the bird daemon when an INIT state is encountered. Any help is much appreciated. Thank you, Nisha Muraleedharan

1 1

[BGP] MRAI connection-based implementation review
by Mattia Milani 06 Apr '20

06 Apr '20

Hello to everyone, in the past months I have implemented the MRAI timer in the BGP protocol and I would like to ask you guys how can I submit this code in order to receive a review form someone more expert than me? My implementation is on a connection-based approach timer and now I'm working on the destination based timer. I have also inserted some new keywords to control this timer from the configuration file. I'm not sure my code is 100% correct, but from the tests that I have done it works. Thanks for the help, Mattia

2 1

Build for Debian MIPS
by Ross Tajvar 05 Apr '20

05 Apr '20

Hi, I am currently using BIRD 1.6.3 on an Edgerouter Pro. The CPU architecture is MIPS and the OS is based on Debian Stretch. Because of the latter, I can use the Debian package repos to install BIRD 1.6.3, however I would like to upgrade to BIRD 2 which does not have a package built. I noticed there is another repo (located at http://bird.network.cz/debian) which maintains BIRD 2 for Debian Stretch, however those packages are not built for the MIPS architecture. I tried building the package myself in a virtual system emulated with qemu, but the build failed with the following error: > obj/lib/fletcher16_test 2>/dev/null && touch obj/lib/fletcher16_test.ok > obj/lib/fletcher16_test: t_fletcher16_compute 0.007899378s > [FAIL] > obj/lib/fletcher16_test: t_fletcher16_checksum 0.004199340s > [FAIL] > obj/lib/fletcher16_test 0.015348769s > [FAIL] > Makefile:180: recipe for target 'obj/lib/fletcher16_test.ok' failed > make[1]: *** [obj/lib/fletcher16_test.ok] Error 1 > make[1]: Leaving directory '/root/src/debian/bird2-2.0.7' > dh_auto_test: make -j1 test VERBOSE=1 returned exit code 2 > debian/rules:21: recipe for target 'build' failed > make: *** [build] Error 2 > dpkg-buildpackage: error: debian/rules build gave error exit status 2 > debuild: fatal error at line 1116: > dpkg-buildpackage -rfakeroot -us -uc -b failed Would it be possible to add MIPS as a build target for the bird.network.cz repo? Thanks, Ross

4 10

How to see as path
by Fabiano D'Agostino 03 Apr '20

03 Apr '20

Good morning, how can I see the as path of a route? I think the command is 'show route' and I get: 192.168.5.0/24 unicast [bgp1 ...]*(100) [AS3i] via.. What is 100? AS3 should be the as path, right? Why is there an 'i'? Thanks, Fabiano

2 2