- Bird-users - Mailing Lists

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

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