July 2019 - Bird-users - Mailing Lists

Which linux OS are you using?
by Ondrej Zajicek 09 Jul '19

09 Jul '19

> Hi all and support, > Which OS you prefer to install BIRD2.0? Hi It is mostly developed and tested on Debian, so i would recommend that. Although BIRD supports both Linux and BSDs, Linux support is generally better. -- 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

Which linux OS are you using?
by Isaac HO 09 Jul '19

09 Jul '19

Hi all and support, Which OS you prefer to install BIRD2.0? Thanks, Isaac

7 8

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

implementation proposal form MRAI
by Mattia Milani 07 Jul '19

07 Jul '19

Hello bird community, I'm trying to implement a peer-based MRAI on Bird, but before everything else, I would like to hear from you what do you think about my implementation idea. My idea is to act before *prefixes* go into the *bucket_queue* data structure and using a timer inside the *bgp_channel*. When a new *prefix* arrives to *bgp_rt_notify* function I'll do this checks before the *add_tail(buck->prefixes, px->bucket_node)* I check if there is an actual MRAI timer active on the channel *c* if there is no timer I append the prefix to the prefixes of the *buket_queue* and I set a new timer equal to MRAI. If the timer was set before I have to append this prefix to a different queue, "*pending_buket_queue*", before the append I'll do the correct checks if it already exists with an hash-table in the channel for the pending buckets. When the *timer expires* pending buckets will be transferred to the *bucket_queue*, and now I need to send the updated bucket_queue. After the transmission, the timer will be updated with the MRAI value. If at the timer expiration there are no pending buckets the timer will not be rebooted. My doubts are for the most on the triggered send at the timer expiration, how can I trigger a "*bgp_update_process*"? And what do you think about this way to implement a peer-based MRAI? Obviously, the MRAI timer will be set with a parameter in the conf file. Thanks all, best regards Mattia Milani

1 0

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

06 Jul '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

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