- Bird-users - Mailing Lists

Functions with 2+ arguments
by Pim van Pelt 23 Oct '24

23 Oct '24

Hoi folks, Consider the following two functions in Bird v2.15.1: function test_ok(int var1) -> bool { if (bgp_large_community ~ [ (50869,1000,var1), (50869,2000,8298) ]) then return true; return false; } function test_nok(int var1; int var2) -> bool { if (bgp_large_community ~ [ (50869,1000,var1), (50869,2000,var2*)* ]) then return true; return false; } The first one parses fine, but the second function yields a parse error on bird: __filename__:199:66 Expression of type int expected Position 199:66 is the closing parenthesis directly after var2. I colored that paren red above. Is my construct or syntax incorrect in the test_nok() case? groet, Pim -- Pim van Pelt PBVP1-RIPE -https://ipng.ch/

2 1

Failing DNS resolution causes BGP sessions to flap
by Ondřej Caletka 21 Oct '24

21 Oct '24

Dear BIRD users, I have recently noticed an interesting issue. A newly set up BGP session between BIRD on our side and a remote party running whatever was taken down every hour or so. The reason for the session being terminated was Received: Hold timer expired. Looking at the logs, it turned out that this was caused by broken DNS resolver on the machine where BIRD is running. Whenever BIRD was trying to resolve the host name of the RPKI Validator cache, it got stuck for 24 seconds. This was apparently enough for the other BGP speaker to consider it dead and take the session down (the hold timers were shortened from the standard values there). Oct 15 13:45:51 vrtr-4.mtg.ripe.net bird[907]: rpki_validator: Cannot resolve hostname 'rpki-validator.mtg.ripe.net': > Oct 15 13:45:51 vrtr-4.mtg.ripe.net bird[907]: I/O loop cycle took 24009.001 ms for 1 events Oct 15 13:45:51 vrtr-4.mtg.ripe.net bird[907]: Kernel dropped some netlink messages, will resync on next scan. Oct 15 13:45:51 vrtr-4.mtg.ripe.net bird[907]: peer_as2852_v4: Received: Hold timer expired Oct 15 13:46:55 vrtr-4.mtg.ripe.net bird[907]: peer_as2852_v4.ipv4: Automatic RPKI reload not active for import This case was fixed by making sure DNS resolver works, but I still wonder whether this is a known limitation or whether this is something that can possibly be improved. -- Best regards, Ondřej Caletka

2 1

Re: Address update causing infinite loop
by Maria Matejka 21 Oct '24

21 Oct '24

Nice, gonna check whether it happens in my case. Thanks for your report, I'll let you know if i need anything more from you. Maria On 20 October 2024 23:25:46 GMT-04:00, benli ye <danielbenliye(a)gmail.com> wrote: >Hi! > >Yes, you are right. Only one thing that I need to correct is that address which is repeated added and deleted is not the next hop address, it’s just a normal address on the interface. >I will try to make it reproduce easily. > >Thanks, >Daniel > > >> On Oct 18, 2024, at 21:03, Maria Matějka <mq(a)jmq.cz> wrote: >> >> Hi! >> >> On Fri, Oct 18, 2024 at 08:50:18PM +0800, benli ye wrote: >> >> Thanks for your response. I have reproduced this issue in our test environment. However, it may not be easy to reproduce again. >> >> Our bird conf example: (image) I have make a shell script to add and remove an IP address of an interface repeatedly. Somehow, I get a 100% cpu issue for bird. >> >> So basically, before we dive into it. >> >> a device and kernel protocol >> a static protocol with lots of multipath routes >> repeatedly adding and deleting one of the nexthop addresses at the interface >> everything else seems irrelevant >> Do I understand that correctly? >> >> The reason why I’m asking – we need to catch the bug way earlier than when it hangs, as the hang is a symptom. The direct cause is somewhere else and it’s hard to find where without an actual reproducer. >> >> Thanks, >> Maria >> >> – >> Maria Matejka (she/her) | https://maria.jmq.cz/ >> > -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

1 0

function return type for enum roa
by James 18 Oct '24

18 Oct '24

Hello, I tried to create a function that returns enum roa. However, I'm encountering difficulties specifying its return type. ``` function check_clearnet_roa() { case net.type { NET_IP4: return roa_check(clearnet_roa_v4, net, bgp_path.last); NET_IP6: return roa_check(clearnet_roa_v6, net, bgp_path.last); else: print "is_roa_invalid: ", "unexpected net.type ", net.type, " ", net; return ROA_UNKNOWN; } } ``` If I use "-> enum roa" as return type, birdcl co ch will return "clearnet.conf:143:34 syntax error, unexpected CF_SYM_UNDEFINED". If I use "-> 'enum roa'" as return type, birdcl co ch will return "clearnet.conf:143:39 Invalid character in apostrophed symbol". If I don't specify its return type, bird issues the warning "clearnet.conf:145:71: Inferring function check_clearnet_roa return type from its return value: enum roa". How should I correctly specify its return type? Regards, James

2 1

Re: Fwd: Address update causing infinite loop
by Maria Matejka 18 Oct '24

18 Oct '24

Hello! On Fri, Oct 18, 2024 at 07:28:02PM +0800, benli ye wrote: > > Subject: Address update causing infinite loop > > > > Hi Maria, > > > > We also encountered an infinite loop issue which is similar to the following link. Could you please share any update about the bug which you mentioned in your mail. > > <https://bird.network.cz/pipermail/bird-users/2022-January/015924.html> There is no update, we couldn't determine anything. > > BIRD version in our environment is 1.6.3-2. BIRD 1 is out of support, please upgrade to BIRD 2. > > ``` > > static void > > static_neigh_notify(struct neighbor *n) > > { > > struct proto *p = n->proto; > > struct static_route *r; > > > > DBG("Static: neighbor notify for %I: iface %p\n", n->addr, n->iface); > > for(r=n->data; r; r=r->chain) ---->>>>>>> by gdb，we check the bird is in this loop. > > { > > static_update_bfd(p, r); > > static_update_rte(p, r); > > } > > } > > ``` With just this information, we can't determine anything, the cause may be anywhere. And AFAIK this is where not only the last report ended as well, but also this is quite a different place and I don't see much more connection than that it has the same symptoms (wasting time in a linked list). Are you able to reproduce this issue with some reasonable probability, so that we could try this in our lab, or is it just a random fail? Could you please at least describe what exactly was happening when this happened? Thanks, Maria -- Maria Matejka (she/her) | https://maria.jmq.cz/

1 0

[PATCH] Fix BGP IPv6 flowspec prefix when offset is not multiple of 8
by Eric Long 16 Oct '24

16 Oct '24

Hi BIRD maintainers, I was messing with BGP flowspec when I encountered BIRD's inconsistencies with RFC. Details and patch is attached below. Thanks! Cheers, Eric From 3008eeb2d4df45b2a4ac78b038f7c830b7495a88 Mon Sep 17 00:00:00 2001 From: Eric Long Date: Mon, 14 Oct 2024 00:30:13 +0800 Subject: [PATCH] Fix BGP IPv6 flowspec prefix when offset is not multiple of 8 Current implementation handles flowspec prefix length and offset only in bytes, but RFC 8956 (Dissemination of Flow Specification Rules for IPv6) Section 3.1 [1] and example in Section 3.8.2 [2] states the pattern should begin right after offset *bits*. For example, pattern "::1:1234:5678:9800:0/60-104" is currently serialized as "02 68 3c 01 12 34 56 78 98", but it should shift its pattern 4 more bits to the left: "02 68 3c 11 23 45 67 89 80". This patch implements shifting left/right for IPv6 type and use it to correct the behaviour. Test data are replaced with the correct ones. [1]: https://www.rfc-editor.org/rfc/rfc8956.html#section-3.1 [2]: https://www.rfc-editor.org/rfc/rfc8956.html#section-3.8.2 --- lib/flowspec.c | 12 +++++------ lib/flowspec_test.c | 4 ++-- lib/ip.h | 50 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 57 insertions(+), 9 deletions(-) diff --git a/lib/flowspec.c b/lib/flowspec.c index df5c8da3..6e693def 100644 --- a/lib/flowspec.c +++ b/lib/flowspec.c @@ -293,13 +293,11 @@ flow_read_ip4_part(const byte *part) static inline ip6_addr flow_read_ip6(const byte *px, uint pxlen, uint pxoffset) { - uint floor_offset = BYTES(pxoffset - (pxoffset % 8)); - uint ceil_len = BYTES(pxlen); ip6_addr ip = IP6_NONE; - memcpy(((byte *) &ip) + floor_offset, px, ceil_len - floor_offset); + memcpy(((byte *) &ip), px, BYTES(pxlen - pxoffset)); - return ip6_ntoh(ip); + return ip6_shift_right(ip6_ntoh(ip), pxoffset); } ip6_addr @@ -476,7 +474,7 @@ flow_validate(const byte *nlri, uint len, int ipv6) uint pxoffset = *pos++; if (pxoffset > IP6_MAX_PREFIX_LENGTH || pxoffset > pxlen) return FLOW_ST_EXCEED_MAX_PREFIX_OFFSET; - bytes -= pxoffset / 8; + bytes = BYTES(pxlen - pxoffset); } pos += bytes; @@ -749,12 +747,12 @@ flow_builder6_add_pfx(struct flow_builder *fb, const net_addr_ip6 *n6, u32 pxoff if (!builder_add_prepare(fb)) return 0; - ip6_addr ip6 = ip6_hton(n6->prefix); + ip6_addr ip6 = ip6_hton(ip6_shift_left(n6->prefix, pxoffset)); BUFFER_PUSH(fb->data) = fb->this_type; BUFFER_PUSH(fb->data) = n6->pxlen; BUFFER_PUSH(fb->data) = pxoffset; - push_pfx_to_buffer(fb, BYTES(n6->pxlen) - (pxoffset / 8), ((byte *) &ip6) + (pxoffset / 8)); + push_pfx_to_buffer(fb, BYTES(n6->pxlen - pxoffset), ((byte *) &ip6)); builder_add_finish(fb); return 1; diff --git a/lib/flowspec_test.c b/lib/flowspec_test.c index 03649b99..ae7444b2 100644 --- a/lib/flowspec_test.c +++ b/lib/flowspec_test.c @@ -533,7 +533,7 @@ t_builder6(void) byte nlri[] = { 27, - FLOW_TYPE_DST_PREFIX, 103, 61, 0x01, 0x12, 0x34, 0x56, 0x78, 0x98, + FLOW_TYPE_DST_PREFIX, 103, 61, 0x22, 0x46, 0x8a, 0xcf, 0x13, 0x00, FLOW_TYPE_SRC_PREFIX, 8, 0, 0xc0, FLOW_TYPE_NEXT_HEADER, 0x80, 0x06, FLOW_TYPE_PORT, 0x03, 0x89, 0x45, 0x8b, 0x91, 0x1f, 0x90, @@ -641,7 +641,7 @@ t_formatting6(void) byte nlri[] = { 0, - FLOW_TYPE_DST_PREFIX, 103, 61, 0x01, 0x12, 0x34, 0x56, 0x78, 0x98, + FLOW_TYPE_DST_PREFIX, 103, 61, 0x22, 0x46, 0x8a, 0xcf, 0x13, 0x00, FLOW_TYPE_SRC_PREFIX, 8, 0, 0xc0, FLOW_TYPE_NEXT_HEADER, 0x81, 0x06, FLOW_TYPE_PORT, 0x03, 20, 0x45, 40, 0x91, 0x01, 0x11, diff --git a/lib/ip.h b/lib/ip.h index f9aa7f66..6282c111 100644 --- a/lib/ip.h +++ b/lib/ip.h @@ -467,6 +467,56 @@ int ip4_pton(const char *a, ip4_addr *o); int ip6_pton(const char *a, ip6_addr *o); +/* + * IPv6 bit shifting + */ + +static inline ip6_addr +ip6_shift_left(ip6_addr a, uint bits) { + int bytes, rem, i; + + if (bits == 0) + return a; + + if (bits > 127) + return IP6_NONE; + + bytes = bits / 32; + rem = bits % 32; + + for (i = 0; i < 3 - bytes; i++) + a.addr[i] = (a.addr[i + bytes] << rem) | + (rem ? (a.addr[i + bytes + 1] >> (32 - rem)) : 0); + + a.addr[3 - bytes] = a.addr[3] << rem; + memset(&a.addr[4 - bytes], 0, bytes * 4); + + return a; +} + +static inline ip6_addr +ip6_shift_right(ip6_addr a, uint bits) { + int bytes, rem, i; + + if (bits == 0) + return a; + + if (bits > 127) + return IP6_NONE; + + bytes = bits / 32; + rem = bits % 32; + for (i = 3; i > bytes; i--) + a.addr[i] = (a.addr[i - bytes] >> rem) | + (rem ? (a.addr[i - bytes - 1] << (32 - rem)) : 0); + + a.addr[bytes] = a.addr[0] >> rem; + memset(&a.addr[0], 0, bytes * 4); + + return a; +} + + /* * Miscellaneous */ -- 2.47.0

2 1

[PATCH] Improved readability of the operator documentation
by Johannes Erwerle 15 Oct '24

15 Oct '24

Hi! Every now and then I have to look up what the ~ operator does exactly. Finding the right combination of types in the long running text is always quite hard. I think that formatting that as a list would make this easier. I also put different kinds of operators into different paragraphs, because I think this also makes it easier to find what you are looking for in this section. For reference: This is the block I am talking about: https://bird.network.cz/?get_doc&v=20&f=bird-5.html#ss5.3 Kind Regards Jo From 08c1e50a97b0afd6522d52ba0f9488c8cc3cb9f8 Mon Sep 17 00:00:00 2001 From: Johannes Erwerle <jo(a)swagspace.org> Date: Sat, 12 Oct 2024 09:07:42 +0200 Subject: [PATCH] Improved readability of the operator documentation --- doc/bird.sgml | 40 +++++++++++++++++++++++++--------------- 1 file changed, 25 insertions(+), 15 deletions(-) diff --git a/doc/bird.sgml b/doc/bird.sgml index 6857452d..7ee066bb 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -1897,21 +1897,31 @@ in the foot). <label id="operators"> The filter language supports common integer operators <cf>(+,-,*,/)</cf>, -parentheses <cf/(a*(b+c))/, comparison <cf/(a=b, a!=b, a<b, a>=b)/. -Logical operations include unary not (<cf/!/), and (<cf/&&/), and or -(<cf/||/). Special operators include (<cf/&tilde;/, -<cf/!&tilde;/) for "is (not) element of a set" operation - it can be used on -element and set of elements of the same type (returning true if element is -contained in the given set), or on two strings (returning true if first string -matches a shell-like pattern stored in second string) or on IP and prefix -(returning true if IP is within the range defined by that prefix), or on prefix -and prefix (returning true if first prefix is more specific than second one) or -on bgppath and bgpmask (returning true if the path matches the mask) or on -number and bgppath (returning true if the number is in the path) or on bgppath -and int (number) set (returning true if any ASN from the path is in the set) or -on pair/quad and clist (returning true if the pair/quad is element of the -clist) or on clist and pair/quad set (returning true if there is an element of -the clist that is also a member of the pair/quad set). +parentheses <cf/(a*(b+c))/, comparison <cf/(a=b, a!=b, a<b, a>=b)/. + +Logical operations include unary not (<cf/!/), and (<cf/&&/), and or +(<cf/||/). + +Special operators include (<cf/&tilde;/, +<cf/!&tilde;/) for "is (not) element of a set" operation - it can be used on: +<itemize> + <item>element and set of elements of the same type (returning true if + element is contained in the given set) + <item>two strings (returning true if first string matches a shell-like + pattern stored in second string) + <item>IP and prefix (returning true if IP is within the range defined by + that prefix), + <item>prefix and prefix (returning true if first prefix is more specific + than second one) + <item>bgppath and bgpmask (returning true if the path matches the mask) + <item>number and bgppath (returning true if the number is in the path) + <item>bgppath and int (number) set (returning true if any ASN from the + path is in the set) + <item>pair/quad and clist (returning true if the pair/quad is element of + the clist) + <item>clist and pair/quad set (returning true if there is an element of the + clist that is also a member of the pair/quad set). +</itemize> There is one operator related to ROA infrastructure - <cf/roa_check()/. It examines a ROA table and does <rfc id="6483"> route origin validation for a -- 2.46.0

2 1

[BIRD] Upgrade Debian
by Jakub Osuch 13 Oct '24

13 Oct '24

Dear BIRD community I would like to upgrade Debian with BIRD. 10 to 11 and finally to 12. I have several VM Debian machines without BIRD and this tutorial works for me. https://www.cyberciti.biz/faq/update-upgrade-debian-11-to-debian-12-bookwor… Can I upgrade my servers Debian 10 with BIRD 1.6.6 to new Debian and BIRD 1.6.8 without problems ? -- Jakub Osuch mobile +48501203739 www.techgroup.pl

2 1

case & string
by Mikhail Mayorov 11 Oct '24

11 Oct '24

Hi! I try use CASE and string variable and a have error.... I checked User's guide 2.0 <https://bird.network.cz/?get_doc&f=bird.html&v=20>.... CASE use operator ~. This operator applies to string variables. What am I doing wrong? [root@wine etc]# cat 123.conf && bird -c ./123.conf -p function teststring(string myvar) -> bool { case myvar { "text A" : print "A"; return true; "text B" : print "B"; return true; "text C" : print "C"; return true; else : print "unknown"; return false; } } bird: ./123.conf:4:12 syntax error, unexpected TEXT -- Regards, Mikhail Mayorov

4 6

Re: BIRD is not prepending ASN on EBGP export.
by Ochalski, Radoslaw 10 Oct '24

10 Oct '24

Thanks Ondrej, So for the routes originating in AS20940, downstream will not be aware of AS20940 in the as-path it will only know private AS4290006033. Kind Regards, Radek On 10/8/24, 5:18 PM, "Ondrej Zajicek" <santiago(a)crfreenet.org <mailto:santiago@crfreenet.org>> wrote: !-------------------------------------------------------------------| This Message Is From an External Sender This message came from outside your organization. |-------------------------------------------------------------------! On Tue, Oct 08, 2024 at 04:46:07PM +0200, Alexander Zubkov via Bird-users wrote: > Hi Radoslaw, > > Do I get it right, that you have 2 bgp peerings here. First your route > passes this peering: > AS8075 <-> AS20940 > then it passes other peering: > AS4290006033 <-> AS4290006002 > > Then it is an expected behaviour. Because the ASN is prepended when > route is exported over eBGP session. And the local ASN is prepended. > So you see that when you receive the route over the first peering, it > is prepended with AS8075. Then it goes over the second peering, where > it is prepended with AS4290006033. Yes, that is true. I would add that one is not supposed to have different local ASNs for different BGP instances that form coherent BGP router, unless it is configured as BGP confederation or manually patched by filters. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago(a)crfreenet.org <mailto:santiago@crfreenet.org>) "To err is human -- to blame it on a computer is even more so."

3 5