June 2019 - Bird-users - Mailing Lists

Crash when filtering routes in BGP protocol
by Vincent Bernat 08 Jul '19

08 Jul '19

Hey! When filtering routes in BGP, I get the following crash with BIRD master: #v+ Program received signal SIGSEGV, Segmentation fault. 0x000055555558ccdd in rta_free (r=0x55555558adc0 <rte_get_temp+16>) at ../nest/route.h:643 643 static inline void rta_free(rta *r) { if (r && !--r->uc) rta__free(r); } gdb$ bt full #0 0x000055555558ccdd in rta_free (r=0x55555558adc0 <rte_get_temp+16>) at ../nest/route.h:643 No locals. #1 rte_update2 (c=0x5555555f3de0, n=0x7fffffffe2f0, n@entry=0x7fffffffe260, new=<optimized out>, src=0x5555555fec00) at ../nest/rt-table.c:1589 old_attrs = 0x55555558adc0 <rte_get_temp+16> fr = <optimized out> p = <optimized out> stats = 0x5555555f3e78 filter = 0x5555555ed980 dummy = 0x0 nn = 0x7fffffffe210 #2 0x000055555559ca0a in rte_update3 (src=<optimized out>, new=<optimized out>, n=<optimized out>, c=<optimized out>) at ../nest/protocol.h:628 No locals. #3 bgp_rte_update (s=s@entry=0x7fffffffe350, n=n@entry=0x7fffffffe2f0, path_id=path_id@entry=4294959812, a0=a0@entry=0x0) at ../proto/bgp/packets.c:1267 a = <optimized out> e = <optimized out> #4 0x000055555559d6dd in bgp_decode_nlri_ip6 (s=0x7fffffffe350, pos=<optimized out>, len=<optimized out>, a=0x0) at ../proto/bgp/packets.c:1500 net = {type = 2 '\002', pxlen = 48 '0', length = 20, prefix = {addr = {536939960, 3722248192, 0, 0}}} path_id = 4294959812 l = 48 addr = {addr = {3087860000, 56797, 0, 0}} b = <optimized out> #5 0x000055555559aced in bgp_decode_nlri (s=s@entry=0x7fffffffe460, afi=<optimized out>, nlri=0x5555556034d0 "0 \001\r\270\335\335\060 \001\r\270\314\314@\001\001", len=14, ea=ea@entry=0x5555556065f0, nh=<optimized out>, nh_len=32) at ../proto/bgp/packets.c:2351 c = 0x5555555f3de0 a = 0x7fffffffe350 #6 0x000055555559ed64 in bgp_rx_update (conn=conn@entry=0x5555555f3cd8, pkt=pkt@entry=0x555555603490 '\377' <repeats 16 times>, len=91) at ../proto/bgp/packets.c:2448 p = <optimized out> ea = 0x5555556065f0 s = {proto = 0x5555555f3ad0, channel = 0x5555555f3de0, pool = 0x5555556019c0, as4_session = 1, add_path = 0, mpls = 0, attrs_seen = {16390, 0, 0, 0, 0, 0, 0, 0}, mp_reach_af = 131073, mp_unreach_af = 0, attr_len = 68, ip_reach_len = 0, ip_unreach_len = 0, ip_next_hop_len = 0, mp_reach_len = 14, mp_unreach_len = 0, mp_next_hop_len = 32, attrs = 0x5555556034a7 "\220\016", ip_reach_nlri = 0x5555556034eb '\377' <repeats 16 times>, ip_unreach_nlri = 0x5555556034a5 "", ip_next_hop_data = 0x0, mp_reach_nlri = 0x5555556034d0 "0 \001\r\270\335\335\060 \001\r\270\314\314@\001\001", mp_unreach_nlri = 0x0, mp_next_hop_data = 0x5555556034af " \001\r\270\252\252", err_withdraw = 0, err_subcode = 0, err_jmpbuf = {{__jmpbuf = {93824992885456, -942560477419964727, 93824992949408, 93824992885976, 0, 93824992949392, 942560477161682633, 6359628643728717513}, __mask_was_saved = 0, __saved_mask = {__val = {0 <repeats 16 times>}}}}, hostentry = 0x0, mpls_labels = 0x0, last_id = 0, last_src = 0x5555555fec00, cached_rta = 0x5555556075c8} pos = <optimized out> #7 0x000055555559fadb in bgp_rx_packet (len=<optimized out>, pkt=0x555555603490 '\377' <repeats 16 times>, conn=0x5555555f3cd8) at ../proto/bgp/packets.c:3024 type = 2 '\002' type = <optimized out> #8 bgp_rx (sk=0x555555601bb0, size=<optimized out>) at ../proto/bgp/packets.c:3069 conn = 0x5555555f3cd8 pkt_start = 0x555555603490 '\377' <repeats 16 times> end = 0x555555603508 "" i = <optimized out> len = <optimized out> #9 0x00005555555a48da in call_rx_hook (s=0x555555601bb0, size=<optimized out>) at ../sysdep/unix/io.c:1794 No locals. #10 0x00005555555a6db7 in sk_read (s=s@entry=0x555555601bb0, revents=1) at ../sysdep/unix/io.c:1882 c = <optimized out> #11 0x00005555555a781e in io_loop () at ../sysdep/unix/io.c:2344 s = <optimized out> count = 1 poll_tout = <optimized out> timeout = <optimized out> nfds = <optimized out> events = <optimized out> pout = <optimized out> t = <optimized out> s = <optimized out> n = <optimized out> fdmax = 256 pfd = 0x555555601010 #12 0x0000555555560f53 in main (argc=<optimized out>, argv=<optimized out>) at ../sysdep/unix/main.c:906 use_uid = <optimized out> use_gid = <optimized out> conf = 0x5555555eca10 #v- Minimal configuration is: #v+ log "/var/log/bird.log" all; router id 2.2.2.2; filter validated { reject; } protocol device { } protocol bgp { local as 65001; neighbor 2001:db8:aaaa::0 as 65000; ipv6 { import filter validated; export none; }; } #v- I have tried to fix that by initializing `old_attrs` to NULL, but this leads to crash elsewhere. Since I don't know what a temporary attribute is, I may miss the whole picture. -- Don't diddle code to make it faster - find a better algorithm. - The Elements of Programming Style (Kernighan & Plauger)

2 4

Introduce Wireguard support to bird
by Janne Heß 08 Jul '19

08 Jul '19

Hey everyone, as advertised, I have completed the Wireguard support. You might see that I am not really a C expert, but I hope the code is good enough. If you need me to change anything or have additional questions, just let me know. Regards Janne

5 8

Configuration help to split the knowledge
by Mattia Milani 02 Jul '19

02 Jul '19

Hello bird community, I have a little problem with some configuration files in Bird 2.0 The protocol I use is BGP I have a star network with 5 nodes, one in the center with the 4 edges. It's something like this (I'm not sure you will see it correctly): H1 | H2--H0--H3 | H4 Now H1,H2,H3, and H4 will share a network, a basic /24 network, and H0 should share them with these rules: If the network comes from H2 I share it with H1 and the opposite If the network comes from H3 I share it with H4 and the opposite For this reason, I created this configuration for the H1-H0 link: protocol bgp h_0_h_1 { local 10.0.0.1 as 1; neighbor 10.0.0.2 as 2; ipv4{ import filter bgp_in; export where proto = "h_0_h_2"; }; direct; } Obviously, the protocol "h_0_h_2" is the protocol between H0 and H2 that is the same with little differences in addresses and in the export, where proto = "h_0_h_1". I don't think this is the correct way to handle this situation, could you please suggest any other configurations? Thanks a lot for the help, Mattia -- Mattia Milani

3 4

Bird 1.6.3 cycle-restarting with SegFault during load-testing
by David.Garay＠os3.nl 01 Jul '19

01 Jul '19

Dear all, good afternoon New user, excuses in advance if the question has been answered elsewhere - despite not having found anything on the mailing list history. For my Master thesis, I am investigating the impact of configuration changes resulting from IRRDB updates on route server infrastructure. During my experiments I got a segfault from Bird, and wanted to ask a few questions about it. The details of the problem are below. Please let me know if you miss anything, and thank you in advance, David ** Problem description: For load testing, I am having my Bird route server instance peer with other 1100 peers (containers, basic bgp config). CPU utilization and Memory are normal (~5%/30% respectively) and I see BGP session establishments go above 1000 sessions without problems, but at 1013 consistently Bird raises seg-fault and restarts. Output shows: 2019-06-27 12:37:49 <ERR> BGP: Error on listening socket: Too many open files Which seem to be related to dynamic buffers running out due to BGP open sessions. Bird version: 1.6.3 CPU details: Intel(R) Xeon(R) CPU E3-1220L V2 @ 2.30GHz, 4 cores). ** Actions taken: - Resource dump available, also: repeated tests to verify the restart always happen at 1013 bgp sessions. ** Questions: - Is the issue I just described known? - Are there (known) hard-coded limits on Bird? What is the expected behaviour under these conditions? - In general, what are other dimensioning variables to be taken into account with Bird? ** Logs: Zip file containing: resource dump, count of bgp sessions, further analysis. https://we.tl/t-mRmgIgC38a

2 1

[PATCH] Doc: fix typo in BGP dynamic names feature description
by Vincent Bernat 25 Jun '19

25 Jun '19

--- doc/bird.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/bird.sgml b/doc/bird.sgml index edc871fbe7e4..715bf1cf3937 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -2246,7 +2246,7 @@ using the following configuration parameters: <tag><label id="bgp-dynamic-name">dynamic name "<m/text/"</tag> Define common prefix of names used for new BGP instances spawned when - dynamic BGP behavior is active. Actual names also contain numberic + dynamic BGP behavior is active. Actual names also contain numeric index to distinguish individual instances. Default: "dynbgp". <tag><label id="bgp-dynamic-name">dynamic name digits <m/number/</tag> -- 2.20.1

1 0

BIRD 2 does not re-validate RPKI status?
by Tim Bruijnzeels 24 Jun '19

24 Jun '19

Hi, I am not sure if this is an artefact of my set-up, or a missing feature / bug in Bird. I recently set up a lab with Bird 2.0.4, connecting to routinator using the rpki-rtr protocol. All works fine so-far. Many thanks for supporting this! However, I found that when ROAs get updated and the cache has new Verified ROA Payloads (VRPs), the existing routes are not re-evaluated. Bird seems to do this validation only when an actual update is seen. I.e. if a prefix was dropped because it was RPKI invalid it stays dropped even if it is now RPKI valid, and vice versa: if it was accepted because it was (in my config case) RPKI unknown or valid, it stays accepted even if it is now RPKI invalid. According to RFC6811 affected prefixes MUST be re-validated when the cache has changes: https://tools.ietf.org/html/rfc6811#section-4 My work-around was to restart the sessions with peers and this forced re-validation. But it is not the best solution. I also loose all the routes temporarily. Is this a local issue? Did I miss something in my set-up? Or is this expected behaviour in Bird? If so, is supporting re-validation on the roadmap? For a lab this doesn't matter too much, but in a real networking environment I think it's important that this works. Otherwise changes in RPKI only become effective when there are changes in BGP (I assume it's doing validation just when updates are seen), and if wrong ROAs are issued by accident, and fixed again, then prefixes may stay unreachable until a session is restarted. Kind regards, Tim Bruijnzeels

2 2

BIRD support in OpenBSD rpki-client?
by Robert Scheck 20 Jun '19

20 Jun '19

Hello all, the portable variant [1] of the recently developed OpenBSD rpki-client [2] is available, however it only supports OpenBGPD so far. I wonder if somebody already had a look to it regarding BIRD support. I know BIRD consumes libssh (for RTRlib [3], but also for the RIPE NCC RPKI Validator as it seems [4]). While I'm not used to OpenBGPD, it feels like they're using a configuration file generated by the rpki-client to feed ROA data in. As this concept is different from BIRD's [5] (maybe I'm overlooking something?), I would be interested how BIRD support at OpenBSD rpki-client could technically look like (and if there are preferences), given there is also remote control [6] via the Unix socket. [1] https://github.com/kristapsdz/rpki-client [2] https://github.com/openbsd/src/tree/master/usr.sbin/rpki-client [3] https://bird.network.cz/?get_doc&v=20&f=prog-5.html [4] https://github.com/tmshlvck/smart-validator/wiki/Connecting-to-BGP-router [5] https://gitlab.labs.nic.cz/labs/bird/commit/46610354319b55df172be87985455b1… [6] https://bird.network.cz/doc/bird-4.html Regards, Robert

1 0

Prevent duplicate routes with OSPF
by Kees Meijs 20 Jun '19

20 Jun '19

Hi list, This is probably a question that was answered many times before: how can I prevent duplicate routes originating from OSPF? For example, a routing table with BIRD2 shut down: > # ip r s > default via 192.168.255.1 dev eth0 > 192.168.255.0/24 dev eth0 proto kernel scope link src 192.168.255.82 And... with BIRD2 running: > # ip r s > default via 192.168.255.1 dev eth0 > 1.2.3.4 dev dummy0 proto bird scope link metric 32 > 1.2.3.7 via 192.168.255.213 dev eth0 proto bird metric 32 > 192.168.255.0/24 dev eth0 proto kernel scope link src 192.168.255.82 > 192.168.255.0/24 dev eth0 proto bird scope link metric 32 In this example at least 192.168.255.0/24 is a duplicate. Configuration used: > log syslog all; > protocol device { > } > > protocol direct { > disabled; # Disable by default > ipv4; # Connect to default IPv4 table > ipv6; # ... and to default IPv6 table > } > > protocol kernel { > ipv4 { # Connect protocol to IPv4 table by channel > export all; # Export to protocol. default is export none > }; > } > > protocol kernel { > ipv6 { # Connect protocol to IPv4 table by channel > export all; # Export to protocol. default is export none > }; > } > > protocol static { > ipv4; # Again, IPv4 channel with default options > } > > protocol static { > ipv6; > } > > protocol ospf v2 foobar { > area 0.0.0.0 { > interface "dummy0" { > stub; > }; > interface "eth0" { > }; > }; > } How can I prevent direct connected routes from showing up from OSPF as well ending up in duplicates? Thanks in advance! Regards, Kees -- https://nefos.nl/contact Nefos IT bv Ambachtsweg 25 (industrienummer 4217) 5627 BZ Eindhoven Nederland KvK 66494931 /Aanwezig op maandag, dinsdag, woensdag en vrijdag/

2 2

[PATCH 2/3] Fix issue where cli socket buffer may get full
by Kenth Eriksson 14 Jun '19

14 Jun '19

The cli module must reset the socket io buffer rpos when all characters in the socket buffer has been processed. The method cli_get_command is always invoked twice for every CLI command, thus rxpos may also be reset at the second invocation if no newline was found and no new data is input to the socket buffer. Signed-off-by: Kenth Eriksson <kenth.eriksson(a)infinera.com> --- sysdep/unix/main.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/sysdep/unix/main.c b/sysdep/unix/main.c index 921115b1..cf5f4a3c 100644 --- a/sysdep/unix/main.c +++ b/sysdep/unix/main.c @@ -403,7 +403,10 @@ cli_get_command(cli *c) { t++; c->rx_pos = c->rx_buf; - c->rx_aux = t; + if (t < tend) + c->rx_aux = t; + else + c->rx_aux = s->rpos = s->rbuf; *d = 0; return (d < dend) ? 1 : -1; } -- 2.21.0

4 8

string shell pattern match
by Robert Sander 14 Jun '19

14 Jun '19

Hi, according to the documentation for BIRD 1.6 it should be possible to use "shell patterns" with the ~ operator on strings: https://bird.network.cz/?get_doc&v=16&f=bird-5.html#ss5.2 I tried to apply this within a filter but the expression does not match: if ifname ~ "bond0.4[2345]" then { reject; } I can only match if I "unroll" the expression and create four different if statements. What does "shell pattern" from the documentation mean in this case? Are [ and ] not valid here? 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

2 3