June 2021 - Bird-users - Mailing Lists

[BMP] BIRD socket best practice
by Maslanka, Pawel 14 Jun '21

14 Jun '21

Hi BIRD team! We found a case when BMP code is trying to connect with BMP collector service with sk_open(), this causes increasing CPU utilization. To reproduce this case, you have just: 1. Server machine where BMP PDU packets will be sent, should be reachable (so it can be pinged). 2. BMP collector service itself should not be running on this server. 3. Run BIRD with enabled BMP protocol. After that you should observe that BIRD process has significantly increased CPU utilization. This is related somehow with “BIRD socket” because when I capture network traffic on host machine (where BIRD is running), I can see massive amount of TCP packets which are exchange between BIRD host machine and BMP collector machine. At the moment socket type related with BMP connection is SK_TCP_ACTIVE. Do you have any idea what is going wrong or how BIRD socket should be properly use? As a temporary fix, I have provided patch allows to avoid this issue but it is very ugly hack because it frees BIRD socket outside of IO code (sk_free()) and initialize again socket again every time when ECONNREFUSED error is passing to err_hook callback. I need also a tip if there is a way to get notification from BIRD socket if we lost connection with BMP collector service? One option is to check if sk_send() failed but what in situation when there are no updates to send by longer time and I would like to get a notification ASAP when I lost connection with BMP collector service. Is this possible with current BIRD implementation or I should to add some timer's callback which will check somehow if BMP collector service is alive? This mechanism is needed for me to synchronize/re-send all BMP data to the collector. Currently we have switched to BMP code provided on bmp branch from gitlab BIRD repo. Additionally I have a question referring to enclosed code. Can I free list node and node data itself when sk_send() returns value greater or equal to 0 (>= 0), like in the below code? WALK_LIST_DELSAFE(tx_data, tx_data_next, p->tx_queue) { ... rv = sk_send(p->sk, data_size); if (rv < 0) { return; } mb_free(tx_data->data); rem_node((node *) tx_data); mb_free(tx_data); if (rv == 0) { return; } ... Or I should to do that only if sk_send() return value greater than 0 (> 0) ? My goal is sending all data from list if there was only "temporary" problem with sk_send(). Thanks, ---- Pawel Maslanka Senior Software Engineer [signature_1256476543] Office: +1.617.444.1234 Cell: +1.617.444.1234 Akamai Technologies 150 Broadway Cambridge, MA 02142 Connect with Us: [signature_580743884]<https://community.akamai.com/> [signature_1866338322] <http://blogs.akamai.com/> [signature_2113959087] <https://twitter.com/akamai> [signature_447607273] <http://www.facebook.com/AkamaiTechnologies> [signature_1901210113] <http://www.linkedin.com/company/akamai-technologies> [signature_1973184621] <http://www.youtube.com/user/akamaitechnologies?feature=results_main>

2 3

Debugging named function filters properly
by Skyler Mäntysaari 14 Jun '21

14 Jun '21

Hi there, How does one debug filters properly as I'm getting lots of: 2021-06-12 09:02:35 <ERR> filters, line 82: Argument 1 of instruction FI_CONDITION must be of type T_BOOL, got 0x00 2021-06-12 09:02:35 <ERR> filters, line 452: Argument 1 of instruction FI_CONDITION must be of type T_BOOL, got 0x00 in logs, but I need it to say which function that is or even file, so how would I debug this properly? Just "debug { filters; }" doesn't help much. I'm using Bird 2.0.7 at the moment.

2 1

[PATCH v4 0/8] Add MAC authentication support to the Babel protocol
by Toke Høiland-Jørgensen 11 Jun '21

11 Jun '21

This series adds MAC authentication support to the Babel protocol as specified in in RFC8967: https://www.rfc-editor.org/rfc/rfc8967 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-256 keys. Given the above, and the fact that the RFC was finally published at the 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. [1] https://github.com/jech/babeld/pull/52 [2] https://github.com/tohojo/bird/tree/babel-mac-04 Changelog: v4: - Update RFC references to the published RFC numbers (for both MAC and Babel itself). - Rework WALK_TLVS macro to not cast initial argument, and not use goto for framing errors. - Change MAC validation logic to just let algorithms specify min/max len and enforce full key size length even for the smaller-output variants of Blake2. v3: - Add variants with smaller digest sizes for blake2s and blake2b. - Rebase on current master 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 (8): 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 babel: Update RFC references to new standards track RFC8966 conf/cf-lex.l | 31 + conf/conf.h | 5 + conf/confbase.Y | 2 + doc/bird.sgml | 49 +- lib/Makefile | 2 +- lib/blake2-impl.h | 160 ++ lib/blake2-kat.h | 4111 +++++++++++++++++++++++++++++++++++++++++ lib/blake2-ref.h | 112 ++ lib/blake2.c | 48 + lib/blake2.h | 65 + lib/blake2b-ref.c | 270 +++ lib/blake2s-ref.c | 263 +++ lib/mac.c | 35 +- lib/mac.h | 11 + lib/mac_test.c | 91 + lib/string.h | 1 + lib/strtoul.c | 27 + nest/config.Y | 54 +- nest/password.c | 6 + nest/password.h | 1 + proto/babel/Makefile | 2 +- proto/babel/babel.c | 162 +- proto/babel/babel.h | 66 +- proto/babel/config.Y | 42 +- proto/babel/packets.c | 667 ++++++- 25 files changed, 6164 insertions(+), 119 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 15

Bird 1.6: OSPF reference bandwidth?
by Cybertinus 08 Jun '21

08 Jun '21

Hello all, I maintain a network with 4 Bird 1.6 routers in it. The 4 routers are connected in a square like this: +-------+ +-------+ | | | | | dc1-1 +--------+ dc2-1 | | | | | +---+---+ +---+---+ | | | | | | +---+---+ +---+---+ | | | | | dc1-2 +--------+ dc2-2 | | | | | +-------+ +-------+ Each link participates in OSPF Area 0. Until last weekend all links were 1 gbit/sec, and all was fine and OSPF did it's thing. Last weekend we upgraded the top link (between dc1-1 and dcg2-1) to 10 gbit/sec, the other 3 links are still 1 gbit/sec. OSPF should take this increased bandwidth into account. But it can only do that if the reference bandwidth is configured correctly. To what is the reference bandwidth set in Bird 1.6 and how can I tweak this? I've checked https://bird.network.cz/?get_doc&v=16&f=bird-6.html#ss6.8 but I couldn't find which option defines the reference bandwidth. Or should I define a cost for each interface now manually, so it gives the 10 gbit/sec link a 10 times lower cost than the other 3? Kind regards, Cybertinus

2 2

The function return true but it could not be export
by 智慧雨泽 08 Jun '21

08 Jun '21

Hi,The function i wrote correctly returns net. bird> show route 2602:feda:ab2::/48 where bgp_export_all() Table master6: 2602:feda:ab2::/48 unicast [LL_IX 02:19:31.236] * (100) [i] via 2602:feda:ab2::1 on ll-ix But it could be export. bird> show route export TOHU_IX for 2602:feda:ab2::/48 bird> I think that should be accept export filter { if bgp_export_all() then accept; # if (roa_check(r6, net, bgp_path.last_nonaggregated) ~ [ROA_INVALID, ROA_UNKNOWN]) then reject; # if is_bogon_asn() then reject; # if is_bogon_prefix() then reject; # accept; }; }; } Why is it not exported? The full configuration is. protocol bgp TOHU_IX { local as LOCAL_ASN; description "tohu ix IX-VPS BGP"; direct; source address 2602:feda:ab5::1; neighbor 2602:feda:ab6::1%'tuhu-ix' as 141011; ipv6 { next hop self; import filter { if is_bogon_asn() then reject; if is_bogon_prefix() then reject; if (roa_check(r6, net, bgp_path.last_nonaggregated) = ROA_VALID) then reject ; accept; }; export filter { if bgp_export_all() then accept; # if (roa_check(r6, net, bgp_path.last_nonaggregated) ~ [ROA_INVALID, ROA_UNKNOWN]) then reject; # if is_bogon_asn() then reject; # if is_bogon_prefix() then reject; # accept; }; }; } function bgp_export() { if net !~ OUR_PREFIXES then return false; if is_bogon_asn() then return false; if is_bogon_prefix() then return false; if net_len_too_long() then { # print "net ", net, " prefix too long"; return false; } if proto = "BGP_Prefix" then return true; if proto = "LL_IX" then{ if bgp_path.len = 0 then{ return true; } } if proto = "TOHU_IX" then{ if bgp_path.len = 0 then{ return true; } } return false; } function bgp_export_all() { if bgp_export() then { return true; } if source != RTS_BGP then{ return false; } if is_bogon_asn() then return false; if is_bogon_prefix() then return false; return true; }

3 4