- Bird-users - Mailing Lists

[PATCH] babel: Initialise objects from slab completely
by Toke Høiland-Jørgensen 22 Nov '20

22 Nov '20

The babel protocol code was initialising objects returned from the slab allocator by assigning to each of the struct members individually, but wasn't touching the NODE member while doing so. This leads to warnings on debug builds since commit: baac7009063d ("List expensive check.") So let's change the babel code to make sure we also zero-initialise the list node. For the packet parser, just move the existing memset() out of babel_read_tlv() and in all other places, use struct assignment for initialising members, which is idiomatic for Bird. Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- proto/babel/babel.c | 31 ++++++++++++++++++------------- proto/babel/packets.c | 7 ++++--- 2 files changed, 22 insertions(+), 16 deletions(-) diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 618abaa8a..588b29eaa 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -114,10 +114,12 @@ babel_get_source(struct babel_proto *p, struct babel_entry *e, u64 router_id) return s; s = sl_alloc(p->source_slab); - s->router_id = router_id; - s->expires = current_time() + BABEL_GARBAGE_INTERVAL; - s->seqno = 0; - s->metric = BABEL_INFINITY; + *s = (struct babel_source) { + .router_id = router_id, + .expires = current_time() + BABEL_GARBAGE_INTERVAL, + .seqno = 0, + .metric = BABEL_INFINITY, + }; add_tail(&e->sources, NODE s); return s; @@ -160,10 +162,10 @@ babel_get_route(struct babel_proto *p, struct babel_entry *e, struct babel_neigh return r; r = sl_alloc(p->route_slab); - memset(r, 0, sizeof(*r)); - - r->e = e; - r->neigh = nbr; + *r = (struct babel_route) { + .e = e, + .neigh = nbr + }; add_tail(&e->routes, NODE r); add_tail(&nbr->routes, NODE &r->neigh_route); @@ -326,11 +328,14 @@ babel_add_seqno_request(struct babel_proto *p, struct babel_entry *e, sr = sl_alloc(p->seqno_slab); found: - sr->router_id = router_id; - sr->seqno = seqno; - sr->hop_count = hop_count; - sr->count = 0; - sr->expires = current_time() + BABEL_SEQNO_REQUEST_EXPIRY; + *sr = (struct babel_seqno_request) { + .router_id = router_id, + .seqno = seqno, + .hop_count = hop_count, + .count = 0, + .expires = current_time() + BABEL_SEQNO_REQUEST_EXPIRY, + }; + babel_lock_neighbor(sr->nbr = nbr); add_tail(&e->requests, NODE sr); diff --git a/proto/babel/packets.c b/proto/babel/packets.c index d4ecf649d..98037ce69 100644 --- a/proto/babel/packets.c +++ b/proto/babel/packets.c @@ -1144,7 +1144,6 @@ babel_read_tlv(struct babel_tlv *hdr, return PARSE_ERROR; state->current_tlv_endpos = tlv_data[hdr->type].min_length; - memset(msg, 0, sizeof(*msg)); int res = tlv_data[hdr->type].read_tlv(hdr, msg, state); if (res != PARSE_SUCCESS) @@ -1278,7 +1277,7 @@ babel_send_unicast(union babel_msg *msg, struct babel_iface *ifa, ip_addr dest) struct babel_msg_node *msgn = sl_alloc(p->msg_slab); list queue; - msgn->msg = *msg; + *msgn = (struct babel_msg_node) { .msg = *msg }; init_list(&queue); add_tail(&queue, NODE msgn); babel_write_queue(ifa, &queue); @@ -1305,7 +1304,7 @@ babel_enqueue(union babel_msg *msg, struct babel_iface *ifa) { struct babel_proto *p = ifa->proto; struct babel_msg_node *msgn = sl_alloc(p->msg_slab); - msgn->msg = *msg; + *msgn = (struct babel_msg_node) { .msg = *msg }; add_tail(&ifa->msg_queue, NODE msgn); babel_kick_queue(ifa); } @@ -1387,6 +1386,8 @@ babel_process_packet(struct babel_pkt_header *pkt, int len, } msg = sl_alloc(p->msg_slab); + memset(msg, 0, sizeof(*msg)); + res = babel_read_tlv(tlv, &msg->msg, &state); if (res == PARSE_SUCCESS) { -- 2.29.2

2 1

handling of unreachable routes with gateway direct
by Alexander Zubkov 22 Nov '20

22 Nov '20

Hello, We have some routes that are passed via transit bird bgp-daemons without installing them to the kernel. And for some of these routes we need to keep their next hop attribute, because it is meaningful on the destination host, but may be unreachable on those transit hosts. If we have "gateway recursive" sessions with these transit hosts, then such routes are accepted, just marked unreachable, but we can work with them. And if we make the sessions "gateway direct", then such routes are ignored by the bird with "Invalid NEXT_HOP attribute" messages in log. Looks like it is caused by this piece of code in proto/bgp/packets.c in function bgp_apply_next_hop(): if (!nbr || (nbr->scope == SCOPE_HOST)) WITHDRAW(BAD_NEXT_HOP); It seems reasonable, of course, but it breaks things for our case. So I want to suggest some changes to make our setup possible. At the moment, I consider the possibility of adding something like "gateway <direct_with_recursive_fallback>" so that it would behave like "gateway direct", but in the case of a non-reachable neighbour, it would switch to recursive logic. What do you think? Whether this is a good idea or maybe you can suggest some better variants? We have a couple of reasons why we want "gateway direct": We want to avoid double recursion, which is not allowed - we might have some other recursive routes that use direct routes received in this session. We could make separate sessions for direct and transit routes, but I'm not sure that the whole thing would be simpler. And there is an issue with next-hop resolution when we have the same ips on different interfaces. As I understand, bird daemon currently does not support that case.

2 4

BIRD 2.0.7 Segmentation fault when using receive limit
by Pier Carlo Chiodi 19 Nov '20

19 Nov '20

Hello, I'm getting a "Segmentation fault" error on BIRD 2.0.7 when I use 'receive limit X'. I've got the error when using either 'action block' or 'action disable'. In the same scenario, if I change the config to use 'import limit X' everything works fine. The error happens as soon as the daemon receives the first "extra" route from its peer (in the example, the 5th route while the limit is 4). Output of '-d -f' can be found at the bottom of this msg. If the number of routes received from the peer is equal to the limit, the issue is not hit. I was able to consistently reproduce what I've mentioned above using the following config on a Docker container based on Debian 10.1 (Linux f484b919cd3a 4.19.76-linuxkit #1 SMP Tue May 26 11:42:35 UTC 2020 x86_64 GNU/Linux - Dockerfile can be found here https://github.com/pierky/dockerfiles/blob/master/bird/2.0.7/Dockerfile) BIRD 1.6.8 works fine. Thanks. Pier Carlo router id 192.0.2.2; define rs_as = 999; log "/var/log/bird.log" all; log syslog all; debug protocols { states, routes, filters, interfaces, events }; timeformat base iso long; timeformat log iso long; timeformat protocol iso long; timeformat route iso long; protocol device {}; ipv4 table master4 sorted; ipv6 table master6 sorted; filter receive_from_AS1_1 { if !(source = RTS_BGP ) then reject "source != RTS_BGP - REJECTING ", net; if !(net.type = NET_IP4) then reject "AFI not enabled for this peer - REJECTING ", net; accept; } protocol bgp AS1_1 { local as 999; neighbor 192.0.2.11 as 1; rs client; passive on; ttl security off; interpret communities off; # --------------------------------------- ipv4 { table master4; secondary; receive limit 4 action block; import table on; import keep filtered on; import filter receive_from_AS1_1; export none; # --------------------------------------- }; } Output of '-d -f': root@f484b919cd3a:~# bird -c /etc/bird/bird.conf -d -f bird: device1: Initializing bird: AS1_1: Channel ipv4 connected to table master4 bird: AS1_1: Initializing bird: device1: Starting bird: device1: Scanning interfaces bird: device1: State changed to up bird: AS1_1: Starting bird: AS1_1: State changed to start bird: Started bird: AS1_1: Started bird: AS1_1: Incoming connection from 192.0.2.11 (port 49457) accepted bird: AS1_1: BGP session established bird: AS1_1: State changed to up bird: AS1_1 > added [best] 1.0.1.0/24 unicast bird: AS1_1 < rejected by protocol 1.0.1.0/24 unicast bird: AS1_1 > added [best] 1.0.3.0/24 unicast bird: AS1_1 < rejected by protocol 1.0.3.0/24 unicast bird: AS1_1 > added [best] 1.0.2.0/24 unicast bird: AS1_1 < rejected by protocol 1.0.2.0/24 unicast bird: AS1_1 > added [best] 1.0.5.0/24 unicast bird: AS1_1 < rejected by protocol 1.0.5.0/24 unicast bird: Protocol AS1_1 hits route receive limit (4), action: disable Segmentation fault

2 5

Bird 2 - Diferences between versions, and Roadmap
by Douglas Fischer 19 Nov '20

19 Nov '20

Some projects, like BSDRP, does references on their release do specific "sub-versions" of Bird. I'm trying to find de differences between versions 2.0.7 , 2.0.7_1 , 2.0.7_2. On https://gitlab.nic.cz/labs/bird/-/releases there are no releases available. On https://gitlab.nic.cz/labs/bird/-/commits/master I found some comments about an issue related to the counting of the accepted routes... But I'm not sure if that is the difference between 2.0.7_1 and 2.0.7_2 I also saw in some communications, like this mail-list and slack channels, some references to future versions of Bird 2.0.8. There is any milestone or project defined to that? Roadmap? -- Douglas Fernando Fischer Engº de Controle e Automação

2 1

OSPF v3 DR - intra-area-prefix LSA generation
by Bala Sajja 18 Nov '20

18 Nov '20

I am running bird 2.0.7. Seeing issue with respect to ipv6 address add/delete on DR. This added/deleted ipv6 address prefix convergence is not happening till LSA refresh timer fires . Topology contains 3 routers connected to a switch. Say IPV6 addresses configured on Routers R1(1111::100/64), R2(2222:200/64),R3(3333::300/64). If we are deleting ipv6 addresses other than DR, I could see intra-area-prefix generated by DR and all routers converged with respect to add/deleted ipv6 addresses. With the below change, I could see intra-area-prefix LSA generated on DR also when ipv6 address added/deleted on DR. Please advise if this fix is correct ? --- a/bird-2.0.7/proto/ospf/iface.c +++ b/bird-2.0.7/proto/ospf/iface.c @@ -1187,6 +1187,8 @@ ospf_ifa_notify3(struct proto *P, uint flags, struct ifa *a) /* RFC 5340 4.4.3 Event 5 - prefix added/deleted */ ospf_notify_link_lsa(ifa); ospf_notify_rt_lsa(ifa->oa); + if(ifa->state == OSPF_IS_DR) + ospf_notify_net_lsa(ifa); } } Regards, Bala.

2 3

PATCH: Added BGP attribute example to docs
by Nigel Kukard 18 Nov '20

18 Nov '20

Hi guys, It took me some time to figure this out, perhaps a slight improvement to the docs attached may help. :) -N

2 1

[PATCH v2 0/7] Add MAC authentication support to the Babel protocol
by Toke Høiland-Jørgensen 17 Nov '20

17 Nov '20

This series adds MAC authentication support to the Babel protocol as specified in by the IETF Babel working group in draft-babel-hmac-10: https://tools.ietf.org/html/draft-ietf-babel-hmac-10 This is the follow-up to v1, posted in February[0]. See changelog below. I have performed basic interoperability testing between this implementation and the current babeld HMAC implementation[1]. The two implementations were able to successfully exchange authenticated messages with both HMAC-256 and Blake2s keys. Given the above, and the close-to-final state of the specification at the IETF, I believe this series is ready for merging (subject to review, of course). For those wanting to test the code, a version of Bird with this series applied is available on Github[2] for easy consumption. [0] http://trubka.network.cz/pipermail/bird-users/2020-February/014251.html [1] https://github.com/jech/babeld/pull/52 [2] https://github.com/tohojo/bird/tree/babel-mac-02 Changelog: v2: - Don't reinvent AC_CHECK_FUNCS() for configure - Make sure random_bytes() never fails (without taking the whole daemon with it) - Use existing endianness defines in blake2s code - Just leave MAC-related code in babel.c/packets.c instead of adding a new file - Add blake2s test vectors (new patch 3) - Support supplying mac keys as raw hexadecimal bytes and allow algorithms to validate keys on configure (new patches 4-5) v1: - Add wrapper function to bird sysdep code to pick a suitable source of random bytes - Import reference Blake2 implementations into lib/ - Rename function names and data structures to use an auth_ prefix instead of hmac_ - Perform a separate authentication pass before parsing the packet, and move the authentication-related code to its own source file - Enforce key length recommendation from the specification - Add a 'permissive' configuration mode where outgoing packets are signed but incoming packets are accepted even though they fail authentication - Add user documentation for the authentication configuration, and function docstrings to the main authentication functions - Fix a bunch of nits and code style issues --- Toke Høiland-Jørgensen (7): sysdep: Add wrapper to get random bytes nest: Add Blake2s and Blake2b hash functions mac_test: Add tests for blake2s and blake2b nest: Allow specifying security keys as hex bytes as well as strings config: Allow MAC algorithms to specify a function to validate their keys babel: Refactor TLV parsing code for easier reuse babel: Add MAC authentication support conf/cf-lex.l | 31 + conf/conf.h | 5 + conf/confbase.Y | 2 + doc/bird.sgml | 47 +- lib/Makefile | 2 +- lib/blake2-impl.h | 160 ++ lib/blake2-kat.h | 4111 +++++++++++++++++++++++++++++++++++++++++ lib/blake2-ref.h | 112 ++ lib/blake2.c | 62 + lib/blake2.h | 69 + lib/blake2b-ref.c | 270 +++ lib/blake2s-ref.c | 263 +++ lib/mac.c | 9 + lib/mac.h | 12 + lib/mac_test.c | 91 + lib/string.h | 1 + lib/strtoul.c | 27 + nest/config.Y | 53 +- nest/password.c | 6 + nest/password.h | 1 + proto/babel/Makefile | 2 +- proto/babel/babel.c | 156 +- proto/babel/babel.h | 66 +- proto/babel/config.Y | 45 +- proto/babel/packets.c | 661 ++++++- 25 files changed, 6152 insertions(+), 112 deletions(-) create mode 100644 lib/blake2-impl.h create mode 100644 lib/blake2-kat.h create mode 100644 lib/blake2-ref.h create mode 100644 lib/blake2.c create mode 100644 lib/blake2.h create mode 100644 lib/blake2b-ref.c create mode 100644 lib/blake2s-ref.c

2 10

Tests fail on s390x
by Mark Stopka 16 Nov '20

16 Nov '20

Hi, I am packaging bird 2.0.7 for openSUSE s390x, and the tests are failing with the following: [ 48s] LD -Wl,-z,relro -pie -pthread -o obj/nest/a-path_test obj/nest/a-path_test.o ... [ 48s] obj/filter/tree_test 0.115749752s [ OK ] [ 49s] obj/filter/filter_test 0.700194688s [ OK ] [ 49s] obj/filter/trie_test 0.157692001s [ OK ] [ 49s] obj/lib/heap_test 0.011880888s [ OK ] [ 49s] obj/lib/buffer_test 0.002189509s [ OK ] [ 49s] obj/lib/event_test 0.000482824s [ OK ] [ 49s] obj/lib/flowspec_test 0.001865918s [ OK ] [ 49s] obj/lib/bitops_test 0.001912407s [ OK ] [ 49s] obj/lib/patmatch_test 0.000268604s [ OK ] [ 49s] obj/lib/fletcher16_test: t_fletcher16_compute 0.000228385s [FAIL] [ 49s] obj/lib/fletcher16_test: t_fletcher16_checksum 0.000196775s [FAIL] [ 49s] obj/lib/fletcher16_test 0.000489688s [FAIL] [ 49s] make: *** [Makefile:180: obj/lib/fletcher16_test.ok] Error 1 [ 49s] error: Bad exit status from /var/tmp/rpm-tmp.Y1ueWS (%check) [ 49s] Has anybody looked into that? Fedora "solved it" by simply disabling tests for s390x architecture, Debian and Ubuntu don't build Bird for s390x... -- Best regards / S pozdravem, BSc. Mark Stopka, BBA Managing Partner (at) PERLUR Group mobile: +420 704 373 561 website: www.perlur.cloud

3 5

Typo in doc/bird.conf.example2: MB-BGP -> MP-BGP
by Hexhu 15 Nov '20

15 Nov '20

Hi, In https://gitlab.nic.cz/labs/bird/-/blob/master/doc/bird.conf.example2, the comment says "This is an example configuration file for MB-BGP setting". Shouldn't it be MP-BGP setting? From git blame at https://gitlab.nic.cz/labs/bird/-/blame/master/doc/bird.conf.example2, the commit message says "Doc: Add MP-BGP example config file". It's quite trivial though 😂. Best regards, Hexhu

2 1

Filter route attribute "from"
by Alex Rydzewski 15 Nov '20

15 Nov '20

Good times, bird community! I'm have trouble with filter routes by "from" attribute. Routes in Bird route table have data about router which the route has originated from: 80.239.201.11/32 via 193.124.176.1 on eth1 [kernel1 2020-08-11] * (10) 10.0.0.0/30 via 10.0.0.18 on bond0 [MyOSPF 2020-11-09] * I (150/20) [172.21.1.1] 154.47.36.2/32 via 193.124.176.1 on eth1 [kernel1 2020-08-13] * (10) but if i try get that routes: show route where from = 172.21.1.1 I get empty respond without any errors. When I was add print statement to config for check which "from" attribute supplied to filter: export filter { print "route: ", net, ", ", from, ", ", proto,; accept; }; I was saw that from is 0.0.0.0: ... bird: route: 172.21.24.0/23, 0.0.0.0, MyOSPF The issue is observed with 1.4 and 1.6 bird versions. Explain me please, what i understand wrong about that?

2 1