July 2019 - Bird-users - Mailing Lists

BIRD 2.0.4 and protocol RPKI in the config file
by Irene Lalioti 24 Jul '19

24 Jul '19

Hello dear Maria and bird users! I would like to ask you a question while I am experiencing an error all morning long :) I have installed the bird version 2.0.4 on my Linuxbox 4.14.13-x86_64-vmware. In my config file I am setting up the rpki protocol based on the documentation : https://bird.network.cz/?get_doc&v=20&f=bird-6.html#ss6.13 As protocol rpki { debug all; roa4 { table r4; }; roa6 { table r6; }; remote "rpki.lu-cix.lu" port 323; retry keep 5; refresh keep 30; expire 600; } when I run it I receive the syntax error unexpected symbol on the protocol line. -bash-4.2# bird -c /etc/bird.conf -d -f bird: /etc/bird.conf:208:10 syntax error, unexpected SYM I have played around with adding names, removing them, removing the { , then adding it again, but nothing changes. I have found another similar incident here : https://bird.network.cz/pipermail/bird-users/2019-March/013167.html Where Ondrej suggested to fix the ; but in my case I already have them. Is this a known issue? Apparently I am missing something. Thanks a lot in advance, and see you in Amsterdam Kind Regards Irène -- Irene Lalioti Network Engineer Fondation RESTENA 2, avenue de l'Université L-4365 Esch/Alzette Tel: +352 424409 1 Fax: +352 422473

5 10

Re: NSSA translate TYPE7->TYPE5
by Ondrej Zajicek 24 Jul '19

24 Jul '19

> Hello, > > I have problem with selective no-translation TYPE7 LSA to TYPE5 LSA on ABR. > Scheme: https://ibb.co/mhbxwmy Hello Just tested that, works for me (with routes from your example). What is your output of 'show ospf state'? Don't you have any suspicious messages in logs? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago(a)crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."

2 5

Route Flap Dampening
by Matthias Waehlisch 24 Jul '19

24 Jul '19

Hi, any eta when support of route flap dampening will be available? Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl

2 1

lib/printf regression on raspberry
by Maximilian Eschenbacher 17 Jul '19

17 Jul '19

Hey everyone, the following patch creates a testcase on top of the master branch for bsprintf with %lR which fails on both my raspberrys (Raspbian Buster, armv6l and armv7l, gcc version 8.3.0). I noticed it by looking at $ birdc6 show babel entries which prints all router ids as 00:00:00:00:00:00:00:00 (except for the <self> prefixes). The issue exists in both tags v1.6.6 and v2.0.4. Best regards, Max --- diff --git a/lib/printf_test.c b/lib/printf_test.c index a2683d93..c1843f07 100644 --- a/lib/printf_test.c +++ b/lib/printf_test.c @@ -18,6 +18,14 @@ bt_assert_msg(memcmp(buf, res, nw) == 0, "fmt=\"%s\" writes \"%*s\", want \"%*s\"", fmt, (n < nw ? n : nw), buf, nw, res); \ } while (0) +static int +t_router_id(void) +{ + char buf[256]; + BSPRINTF(23, "01:02:03:04:05:06:07:08", buf, "%lR", 0x102030405060708); + return 1; +} + static int t_simple(void) { @@ -74,6 +82,7 @@ main(int argc, char *argv[]) bt_init(argc, argv); bt_test_suite(t_simple, "printf without varargs"); + bt_test_suite(t_router_id, "print router id"); return bt_exit_value(); }

2 1

UPGRADE OS
by Rwakagabo Janvier 17 Jul '19

17 Jul '19

Dear All, I am running BIRD 1.4.0 as a route server on Ubuntu 14.04.2 LTS Server. I am planning OS upgrade to Ubuntu 16.04.4 LTS server Is there any thing I should consider before doing this upgrade? BIRD 1.4.0 will continue to work in Ubuntu 16.04.4 LTS ? Thanks, Regards, Janvier R.

3 3

bfd does not work in a vrf
by Alexander Zubkov 16 Jul '19

16 Jul '19

Hello, I tried to run BFD in a VRF and looks like it is not working. The similar config without VRFs works ok. Config without a VRF: ipv4 table master4; protocol device {} protocol bfd {} protocol bgp b { local 192.168.1.3 as 65003; neighbor 192.168.1.2 as 65002; strict bind yes; bfd yes; ipv4 { table master4; import none; export none; }; } This runs well and I have both BGP established and BFD session up: bird> show protocols Name Proto Table State Since Info device1 Device --- up 11:29:24.831 bfd1 BFD --- up 11:29:24.831 b BGP --- up 11:29:28.638 Established bird> show bfd sessions bfd1: IP address Interface State Since Interval Timeout 192.168.1.2 eth0 Up 11:29:25.574 0.100 0.500 bird> But when it is run in a VRF with such config: ipv4 table master4; protocol device {} protocol bfd { vrf "blue"; } protocol bgp b { vrf "blue"; local 192.168.0.1 as 65001; neighbor 192.168.0.2 as 65002; strict bind yes; bfd yes; ipv4 { table master4; import none; export none; }; } Then BFD session does not go up: bird> show protocols Name Proto Table State Since Info device1 Device --- up 11:29:24.815 bfd1 BFD --- up 11:29:24.815 b BGP --- up 11:29:28.879 Established bird> show bfd sessions bfd1: IP address Interface State Since Interval Timeout 192.168.0.2 eth0 Down 11:29:24.815 1.000 0.000 bird> Adding or removing vrf "blue" to the BFD's config does not change anything. And I am not sure it has to be there because only one BFD instance is allowed. The peer's session is in the "Init" state at the same time: bird> show bfd sessions bfd1: IP address Interface State Since Interval Timeout 192.168.1.3 eth1 Up 11:32:20.861 0.100 0.500 192.168.0.1 eth0 Init 11:32:20.968 1.000 5.000 bird> In tcpdump I see that BFD control messages go in both directions, but looks like the peer in VRD do not receive them. I suppose that it does not binds the socket to listen it in the VRF. Also if I set this sysctl value, the session wents up: net.ipv4.udp_l3mdev_accept = 1

1 0

NSSA translate TYPE7->TYPE5
by Konrad Kręciwilk 12 Jul '19

12 Jul '19

Hello, I have problem with selective no-translation TYPE7 LSA to TYPE5 LSA on ABR. Scheme: https://ibb.co/mhbxwmy R3 announce connected routes by function: function allow_network() prefix set localnet; { localnet = [ 10.0.0.0/8{16,30 ]; ospf_metric1 = 10; if net ~ localnet then return true; else return false; } R3 > show ospf lsadb Area 0.0.0.6 Type LS ID Router Sequence Age Checksum 0007 10.19.15.0 212.127.92.253 8000089c 759 6843 0007 10.19.37.0 212.127.92.253 8000089c 759 7520 0007 10.19.40.255 212.127.92.253 8000089c 759 543e 0007 10.19.41.0 212.127.92.253 8000089c 759 4948 0007 10.19.61.0 212.127.92.253 8000089c 759 6c11 0007 10.19.62.255 212.127.92.253 8000089c 759 611b 0007 10.19.63.0 212.127.92.253 8000089c 759 5625 0007 10.19.64.255 212.127.92.253 8000089c 759 4b2f 0007 10.19.80.255 212.127.92.253 8000089c 759 9acf 0007 10.19.100.255 212.127.92.253 8000089c 759 bd98 0007 10.19.130.255 212.127.92.253 8000089c 759 72c5 0007 10.19.132.255 212.127.92.253 8000089c 759 5cd9 0007 10.19.141.0 212.127.92.253 8000089c 759 f834 0007 10.19.142.255 212.127.92.253 8000089c 759 ed3e 0007 10.19.143.0 212.127.92.253 8000089c 759 e248 0007 10.19.144.255 212.127.92.253 8000089c 759 d752 0007 10.19.145.0 212.127.92.253 8000089c 759 cc5c 0007 10.19.146.255 212.127.92.253 8000089c 759 c166 0007 10.19.147.0 212.127.92.253 8000089c 759 b670 0007 10.19.148.255 212.127.92.253 8000089c 759 ab7a 0007 10.19.149.0 212.127.92.253 8000089c 759 a084 0007 10.19.150.255 212.127.92.253 8000089c 759 958e 0007 10.19.161.0 212.127.92.253 8000089c 759 1cfc 0007 10.19.162.255 212.127.92.253 8000089c 759 1107 0007 10.19.163.0 212.127.92.253 8000089c 759 0611 0007 10.19.184.255 212.127.92.253 8000089c 759 1ee3 R1 (ABR) should translate TYPE7 do TYPE5 (GLOBAL AREA) but he does not do it for all. For example 10.19.80 is only at LSADB AREA6 - TYPE7. Routes for 10.19.80.0/24 looks the same as for translates for example 10.19.141.0/24 R1> show route for 10.19.141.0/24 all 10.19.141.0/24 via xx.xx.92.253 on vlan3960 [XXX 2019-06-17] * E1 (150/20) [212.127.92.253] Type: OSPF-E1 unicast univ OSPF.metric1: 20 OSPF.metric2: 16777215 OSPF.tag: 0x00000000 OSPF.router_id: 212.127.92.253 R1> show route for 10.19.80.0/24 all 10.19.80.0/24 via xx.xx.92.253 on vlan3960 [XXX 2019-06-17] * E1 (150/20) [212.127.92.253] Type: OSPF-E1 unicast univ OSPF.metric1: 20 OSPF.metric2: 16777215 OSPF.tag: 0x00000000 OSPF.router_id: 212.127.92.253 R1> show ospf lsadb Global 0005 10.19.64.255 212.127.92.5 800004c4 235 5304 0005 10.19.100.255 212.127.92.5 800004c4 235 c56d 0005 10.19.130.255 212.127.92.5 800004c4 235 7a9a 0005 10.19.132.255 212.127.92.5 800004c4 235 64ae 0005 10.19.141.0 212.127.92.5 800004c4 235 0109 0005 10.19.143.0 212.127.92.5 80000885 235 5de5 0005 10.19.145.0 212.127.92.5 80000826 235 069a 0005 10.19.146.255 212.127.92.5 80000885 235 3c04 0005 10.19.147.0 212.127.92.5 800004c4 235 be45 0005 10.19.148.255 212.127.92.5 800004c4 235 b34f 0005 10.19.149.0 212.127.92.5 800004c4 235 a859 0005 10.19.150.255 212.127.92.5 800004c4 235 9d63 0005 10.19.161.0 212.127.92.5 80000885 235 969a 0005 10.19.162.255 212.127.92.5 80000826 235 4a45 0005 10.19.184.255 212.127.92.5 800004c4 235 26b8 0005 10.19.15.0 212.127.92.5 800004c4 235 7018 0005 10.19.40.255 212.127.92.5 800004c4 235 5c13 0005 10.19.41.0 212.127.92.5 800004c4 235 511d 0005 10.19.63.0 212.127.92.5 800004c4 235 5ef9 0005 10.19.163.0 212.127.92.5 800004c4 235 0ee5 Area 0.0.0.6 Type LS ID Router Sequence Age Checksum 0007 10.19.15.0 212.127.92.253 800008a3 1286 5a4a 0007 10.19.37.0 212.127.92.253 800008a3 1286 6727 0007 10.19.40.255 212.127.92.253 800008a3 1286 4645 0007 10.19.41.0 212.127.92.253 800008a3 1286 3b4f 0007 10.19.61.0 212.127.92.253 800008a3 1286 5e18 0007 10.19.62.255 212.127.92.253 800008a3 1286 5322 0007 10.19.63.0 212.127.92.253 800008a3 1286 482c 0007 10.19.64.255 212.127.92.253 800008a3 1287 3d36 0007 10.19.80.255 212.127.92.253 800008a3 1287 8cd6 0007 10.19.100.255 212.127.92.253 800008a3 1287 af9f 0007 10.19.130.255 212.127.92.253 800008a3 1286 64cc 0007 10.19.132.255 212.127.92.253 800008a3 1286 4ee0 0007 10.19.141.0 212.127.92.253 800008a3 1286 ea3b 0007 10.19.142.255 212.127.92.253 800008a3 1286 df45 0007 10.19.143.0 212.127.92.253 800008a3 1286 d44f 0007 10.19.144.255 212.127.92.253 800008a3 1286 c959 0007 10.19.145.0 212.127.92.253 800008a3 1286 be63 0007 10.19.146.255 212.127.92.253 800008a3 1286 b36d 0007 10.19.147.0 212.127.92.253 800008a3 1286 a877 0007 10.19.148.255 212.127.92.253 800008a3 1286 9d81 0007 10.19.149.0 212.127.92.253 800008a3 1286 928b 0007 10.19.150.255 212.127.92.253 800008a3 1286 8795 0007 10.19.162.255 212.127.92.253 800008a3 1286 030e config from R1: area 0.0.0.0 { networks { xx.xx.92.4/30; xx.xx.92.8/30; }; interface "vlan3900" { cost 100; type ptp; }; interface "vlan3920" { cost 200; type ptp; }; interface "vlan4050" { stub; }; }; area 0.0.0.6 { nssa; translator yes; networks { xx.xx.92.252/30; }; interface "vlan3960" { type ptp; }; }; it happens on every version that I used (1.6.1, 1.6.4, 1.6.6). After restart bird process, others prefixes are not translated. In effect R2 does not know route for not tranlsated to TYPE5 routes. Regards, Konrad Kręciwilk

1 0

Optional attribute error peering BGP with FRR
by Derrick Lim 11 Jul '19

11 Jul '19

Hello everyone, I’m having an issue with FRR running on Cumulus (4.0+cl3u10), which is peering BGP to BIRD (2.0.2, also tried 1.6.3). When certain routes from FRR are advertised to BIRD (I configured them through vrf leaking on FRR, but not sure if that matters, or its just something with the routes), BIRD terminates the BGP session with an `Optional attribute error` (on BIRD 2.0.2, different error on 1.6.3) when receiving the BGP UPDATE message. I’m not sure if this an FRR or BIRD issue, so I'm hoping someone here could take a look if the UPDATE message from FRR could possibly be malformed, or is BIRD handling this in an odd way. I've attached the tcpdump as well as error logs from BIRD, along with the bird.conf, as well a portion of the FRR config. 100.91.38.1 is the host running BIRD. 100.91.38.61 is the host running FRR. Regards, Derrick

4 5

Mailing list delivery issue
by Ondrej Zajicek 09 Jul '19

09 Jul '19

Hello I just noticed that for about last 3 weeks, mails from bird-users mailing list are not delivered to me. Still working on the issue. So excuse me for not answering to your mails earlier. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago(a)crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."

1 0

Re: [PATCH] Doc: fix typo in BGP dynamic names feature description
by Ondrej Zajicek 09 Jul '19

09 Jul '19

Thanks, merged. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago(a)crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."

1 0