January 2025 - Bird-users

[PATCH] Babel: allow enabling link quality estimation manually
by Nick Cao 09 Apr '25

09 Apr '25

Link quality estimation is useful for link types other than wireless, especially when using babel with tunnels where packet losses do occur. --- doc/bird.sgml | 6 ++++++ proto/babel/babel.c | 19 ++++++------------- proto/babel/babel.h | 1 + proto/babel/config.Y | 5 ++++- 4 files changed, 17 insertions(+), 14 deletions(-) diff --git a/doc/bird.sgml b/doc/bird.sgml index 8041faa9..417ec030 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -2032,6 +2032,12 @@ protocol babel [<name>] { hardware drivers or platforms do not implement this feature. Default: yes. + <tag><label id="babel-link-quality">link quality <m/switch/</tag> + If set, link quality estimation is performed on this interface. + Link quality is measured by packet loss and is used for computing + metrics of routes going through this interface. Default: yes for + wireless interfaces, otherwise no. + <tag><label id="babel-next-hop-ipv4">next hop ipv4 <m/address/</tag> Set the next hop address advertised for IPv4 routes advertised on this interface. Default: the preferred IPv4 address of the interface. diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 7f0cca73..6a238d75 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -593,21 +593,15 @@ babel_update_cost(struct babel_neighbor *nbr) if (!rcv || !nbr->ifa->up) goto done; - switch (cf->type) - { - case BABEL_IFACE_TYPE_WIRED: - case BABEL_IFACE_TYPE_TUNNEL: + if (!cf->link_quality) { /* k-out-of-j selection - Appendix 2.1 in the RFC. */ /* Link is bad if less than cf->limit/16 of expected hellos were received */ - if (rcv * 16 < cf->limit * max) - break; - - rxcost = cf->rxcost; - txcost = nbr->txcost; - break; - - case BABEL_IFACE_TYPE_WIRELESS: + if (!(rcv * 16 < cf->limit * max)) { + rxcost = cf->rxcost; + txcost = nbr->txcost; + } + } else { /* * ETX - Appendix 2.2 in the RFC. * @@ -622,7 +616,6 @@ babel_update_cost(struct babel_neighbor *nbr) */ rxcost = MIN( cf->rxcost * max / rcv, BABEL_INFINITY); txcost = MIN(nbr->txcost * max / rcv, BABEL_INFINITY); - break; } if (cf->rtt_cost && nbr->srtt > cf->rtt_min) diff --git a/proto/babel/babel.h b/proto/babel/babel.h index edde4cab..d152d099 100644 --- a/proto/babel/babel.h +++ b/proto/babel/babel.h @@ -145,6 +145,7 @@ struct babel_iface_config { u8 type; u8 limit; /* Minimum number of Hellos to keep link up */ u8 check_link; + u8 link_quality; uint port; uint hello_interval; /* Hello interval, in us */ uint ihu_interval; /* IHU interval, in us */ diff --git a/proto/babel/config.Y b/proto/babel/config.Y index b8af0267..cbf873c5 100644 --- a/proto/babel/config.Y +++ b/proto/babel/config.Y @@ -26,7 +26,7 @@ CF_KEYWORDS(BABEL, INTERFACE, METRIC, RXCOST, HELLO, UPDATE, INTERVAL, PORT, TYPE, WIRED, WIRELESS, RX, TX, BUFFER, PRIORITY, LENGTH, CHECK, LINK, NEXT, HOP, IPV4, IPV6, BABEL_METRIC, SHOW, INTERFACES, NEIGHBORS, ENTRIES, RANDOMIZE, ROUTER, ID, AUTHENTICATION, NONE, MAC, PERMISSIVE, - EXTENDED, TUNNEL, RTT, MIN, MAX, DECAY, SEND, TIMESTAMPS) + EXTENDED, TUNNEL, RTT, MIN, MAX, DECAY, SEND, TIMESTAMPS, QUALITY) CF_GRAMMAR @@ -72,6 +72,7 @@ babel_iface_start: BABEL_IFACE->rtt_decay = BABEL_RTT_DECAY; BABEL_IFACE->rtt_send = 1; BABEL_IFACE->check_link = 1; + BABEL_IFACE->link_quality = 0; BABEL_IFACE->ext_next_hop = 1; }; @@ -84,6 +85,7 @@ babel_iface_finish: BABEL_IFACE->hello_interval = BABEL_HELLO_INTERVAL_WIRELESS; if (!BABEL_IFACE->rxcost) BABEL_IFACE->rxcost = BABEL_RXCOST_WIRELESS; + BABEL_IFACE->link_quality = 1; } else { @@ -156,6 +158,7 @@ babel_iface_item: | TX tos { BABEL_IFACE->tx_tos = $2; } | TX PRIORITY expr { BABEL_IFACE->tx_priority = $3; } | CHECK LINK bool { BABEL_IFACE->check_link = $3; } + | LINK QUALITY bool { BABEL_IFACE->link_quality = $3; } | NEXT HOP IPV4 ipa { BABEL_IFACE->next_hop_ip4 = $4; if (!ipa_is_ip4($4)) cf_error("Must be an IPv4 address"); } | NEXT HOP IPV6 ipa { BABEL_IFACE->next_hop_ip6 = $4; if (!ipa_is_ip6($4)) cf_error("Must be an IPv6 address"); } | EXTENDED NEXT HOP bool { BABEL_IFACE->ext_next_hop = $4; } -- 2.41.0

4 14

bird 3.0.1 doesn’t compile on FreeBSD
by Olivier Cochard-Labbé 04 Apr '25

04 Apr '25

Hi, bird 3.0.1 include this patch: "Netlink: Handle onlink flag on BSD-Netlink" https://gitlab.nic.cz/labs/bird/-/commit/f9c7861e116ad8dc5e5a2314d0f976bf8c… But this broke FreeBSD build with this error: sysdep/bsd-netlink/netlink.c:1868:10: error: no member named 'nh' in 'struct ea_list Regards, Olivier

3 4

[PATCH v2] Babel: Allow v6 next hop on interfaces with v4 addresses
by Chris Webb 28 Mar '25

28 Mar '25

By default, the Babel protocol will advertise an IPv6 extended next hop address on interfaces which don't have an IPv4 address. This is controlled by the 'extended next hop' option. Add support for 'extended next hop force' which advertises an extended next hop even when IPv4 addresses are present. (They may be temporary, for debugging or otherwise unsuitable for including in an advertisement.) --- v2: use an explicit enum for possible values of ext_next_hop doc/bird.sgml | 9 ++++++--- proto/babel/babel.c | 17 +++++++++++++---- proto/babel/babel.h | 6 ++++++ proto/babel/config.Y | 5 +++-- 4 files changed, 28 insertions(+), 9 deletions(-) diff --git a/doc/bird.sgml b/doc/bird.sgml index 0d1e6f49..cb5fa572 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -2266,7 +2266,7 @@ protocol babel [<name>] { check link <switch>; next hop ipv4 <address>; next hop ipv6 <address>; - extended next hop <switch>; + extended next hop <switch>|force; rtt cost <number>; rtt min <time>; rtt max <time>; @@ -2377,10 +2377,13 @@ protocol babel [<name>] { source for Babel packets will be used. In normal operation, it should not be necessary to set this option. - <tag><label id="babel-extended-next-hop">extended next hop <m/switch/</tag> + <tag><label id="babel-extended-next-hop">extended next hop + <m/switch/|force</tag> If enabled, BIRD will accept and emit IPv4 routes with an IPv6 next hop when IPv4 addresses are absent from the interface as described in - <rfc id="9229">. Default: yes. + <rfc id="9229">. Use <cf/extended next hop force/ to emit IPv4 routes + with an IPv6 next hop even when IPv4 addresses are present on the + interface. Default: yes. <tag><label id="babel-rtt-cost">rtt cost <m/number/</tag> The RTT-based cost that will be applied to all routes from each neighbour diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 4187d258..4db6bd04 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -1836,8 +1836,12 @@ babel_iface_update_addr4(struct babel_iface *ifa) { struct babel_proto *p = ifa->proto; - ip_addr addr4 = ifa->iface->addr4 ? ifa->iface->addr4->ip : IPA_NONE; - ifa->next_hop_ip4 = ipa_nonzero(ifa->cf->next_hop_ip4) ? ifa->cf->next_hop_ip4 : addr4; + if (ipa_nonzero(ifa->cf->next_hop_ip4)) + ifa->next_hop_ip4 = ifa->cf->next_hop_ip4; + else if (ifa->cf->ext_next_hop != BABEL_EXT_NEXT_HOP_FORCE && ifa->iface->addr4) + ifa->next_hop_ip4 = ifa->iface->addr4->ip; + else + ifa->next_hop_ip4 = IPA_NONE; if (ipa_zero(ifa->next_hop_ip4) && p->ip4_channel && !ifa->cf->ext_next_hop) log(L_WARN "%s: Missing IPv4 next hop address for %s", p->p.name, ifa->ifname); @@ -1912,8 +1916,13 @@ babel_add_iface(struct babel_proto *p, struct iface *new, struct babel_iface_con add_tail(&p->interfaces, NODE ifa); - ip_addr addr4 = new->addr4 ? new->addr4->ip : IPA_NONE; - ifa->next_hop_ip4 = ipa_nonzero(ic->next_hop_ip4) ? ic->next_hop_ip4 : addr4; + if (ipa_nonzero(ic->next_hop_ip4)) + ifa->next_hop_ip4 = ic->next_hop_ip4; + else if (ic->ext_next_hop != BABEL_EXT_NEXT_HOP_FORCE && new->addr4) + ifa->next_hop_ip4 = new->addr4->ip; + else + ifa->next_hop_ip4 = IPA_NONE; + ifa->next_hop_ip6 = ipa_nonzero(ic->next_hop_ip6) ? ic->next_hop_ip6 : ifa->addr; if (ipa_zero(ifa->next_hop_ip4) && p->ip4_channel && !ic->ext_next_hop) diff --git a/proto/babel/babel.h b/proto/babel/babel.h index edde4cab..5b397b45 100644 --- a/proto/babel/babel.h +++ b/proto/babel/babel.h @@ -127,6 +127,12 @@ enum babel_ae_type { BABEL_AE_MAX }; +enum babel_ext_next_hop { + BABEL_EXT_NEXT_HOP_OFF = 0, + BABEL_EXT_NEXT_HOP_ON = 1, + BABEL_EXT_NEXT_HOP_FORCE = 2 +}; + struct babel_config { struct proto_config c; diff --git a/proto/babel/config.Y b/proto/babel/config.Y index d412a54b..bdfff203 100644 --- a/proto/babel/config.Y +++ b/proto/babel/config.Y @@ -24,7 +24,7 @@ CF_DECLS CF_KEYWORDS(BABEL, INTERFACE, METRIC, RXCOST, HELLO, UPDATE, INTERVAL, PORT, TYPE, WIRED, WIRELESS, RX, TX, BUFFER, PRIORITY, LENGTH, CHECK, LINK, - NEXT, HOP, IPV4, IPV6, BABEL_METRIC, SHOW, INTERFACES, NEIGHBORS, + NEXT, HOP, FORCE, IPV4, IPV6, BABEL_METRIC, SHOW, INTERFACES, NEIGHBORS, ENTRIES, RANDOMIZE, ROUTER, ID, AUTHENTICATION, NONE, MAC, PERMISSIVE, EXTENDED, TUNNEL, RTT, MIN, MAX, DECAY, SEND, TIMESTAMPS, COST, DELAY) @@ -158,7 +158,8 @@ babel_iface_item: | CHECK LINK bool { BABEL_IFACE->check_link = $3; } | NEXT HOP IPV4 ipa { BABEL_IFACE->next_hop_ip4 = $4; if (!ipa_is_ip4($4)) cf_error("Must be an IPv4 address"); } | NEXT HOP IPV6 ipa { BABEL_IFACE->next_hop_ip6 = $4; if (!ipa_is_ip6($4)) cf_error("Must be an IPv6 address"); } - | EXTENDED NEXT HOP bool { BABEL_IFACE->ext_next_hop = $4; } + | EXTENDED NEXT HOP bool { BABEL_IFACE->ext_next_hop = $4 ? BABEL_EXT_NEXT_HOP_ON : BABEL_EXT_NEXT_HOP_OFF; } + | EXTENDED NEXT HOP FORCE { BABEL_IFACE->ext_next_hop = BABEL_EXT_NEXT_HOP_FORCE; } | AUTHENTICATION NONE { BABEL_IFACE->auth_type = BABEL_AUTH_NONE; } | AUTHENTICATION MAC { BABEL_IFACE->auth_type = BABEL_AUTH_MAC; BABEL_IFACE->auth_permissive = 0; } | AUTHENTICATION MAC PERMISSIVE { BABEL_IFACE->auth_type = BABEL_AUTH_MAC; BABEL_IFACE->auth_permissive = 1; }

3 5

How to upgrade version Bird to 2.15.1
by Nguyen Van Nhan 02 Feb '25

02 Feb '25

Dear Bird Community, I have installed BIRD and tested the configurations related to the operation of this application. I have some questions during the BIRD deployment process, I hope you will give me specific instructions for editing and optimizing in operation. I am installing the default Bird version 2.0.8 on Ubuntu LTS 22.04 operating system 1. Can you provide me with detailed instructions to upgrade Bird to the latest version 2.15.1? I have tried to upgrade but when performing the operation in birdc, it still shows that it is at version 2.0.8. 2. Does Bird support BMP protocol in the latest version? We are researching to use BMP on Bird to get monitoring data via OpenBMP. Is it possible? Thanks and best regards, Nhan Nguyen Email: nhannv(a)vnnic.vn<mailto:nhannv@vnnic.vn> Mobile: +84 905 674 854

2 1

link-local IPv6 address in BGP.next_hop
by Ponikierski, Grzegorz 29 Jan '25

29 Jan '25

Hello all! I have an interesting case of link-local IPv6 address in BGP.next_hop and I would like to know your opinion about that because I cannot tell with 100% confidence if it’s a bug or a feature. Existence of these link-local addresses causes issues of interoperability between Bird and FRR. I have separate discussion about that with FRR folks. Here I would like to now a Bird perspective. Details below. On single router with Bird 2.15 I have multiple IPv4 and IPv6 eBGP sessions, which receives prefixes from the Internet, and IPv4 iBGP session, which forwards these prefixes to BGP collector with FRR, which is separate server somewhere in the Internet many hops away in separate ASN. Session with BGP collector uses both ipv4 and ipv6 channels to send both IPv4 and IPv6 prefixes. IPv6 prefixes received via eBGP have both global IPv6 address and link-local IPv6 address like in an example below: ::/0 unicast [2600:1488:6080::8__r01.fra03.ien 2024-12-06] * (100) [AS3356i] via 2600:1488:6080::8 on ae2 Type: BGP univ BGP.origin: IGP BGP.as_path: 3356 BGP.next_hop: 2600:1488:6080::8 fe80::7a4f:9bff:fed1:2e0d BGP.med: 4294967294 BGP.local_pref: 60 BGP.community: (3356,2) (3356,501) (3356,601) (3356,2065) (20940,30403) (65502,3356) However, prefixes forwarded via iBGP to BGP collector also have both global and link-local addresses like below: ::/0 unicast [2600:1488:6080::8__r01.fra03.ien 2024-12-06] * (100) [AS3356i] via 2600:1488:6080::8 on ae2 Type: BGP univ BGP.origin: IGP BGP.as_path: 3356 BGP.next_hop: 2600:1488:6080::8 fe80::7a4f:9bff:fed1:2e0d BGP.med: 4294967294 BGP.local_pref: 60 BGP.community: (3356,2) (3356,501) (3356,601) (3356,2065) (20940,30403) (65502,3356) (21357,600) On one hand, as per RFC 4271 NEXT_HOP is not changed when prefix is passed from eBGP to iBGP so what we see above it expected. But on the other hand, as per RFC 2545 link-local address must not be there because both sides of iBGP doesn’t share the same IPv6 subnet: “”” The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to. In all other cases a BGP speaker shall advertise to its peer in the Network Address field only the global IPv6 address of the next hop (the value of the Length of Network Address of Next Hop field shall be set to 16). “”” Who is right here? As far I know, both documents are still current standards, and both are implemented by Bird. I don’t see any clear guidelines how to make a clear judgement here. Personally, I would tell that RFC 4271 should be treated as general rule and RFC 2545 as more specific rule so in the end link-local should be removed. After all, link-local addresses do not make sense for multihop sessions. However, these documents don’t refer to each other and I don’t know if authors of these documents knew about each other statements. What do you think? Anyway, when BGP collector with FRR 8.5.2 receives BGP UPDATE for route like presented above, then FRR rejects such UPDATE with treat-as-withdrawn approach but also triggers additional error about invalid prefix length for AFI 1, which finally causes NOTIFICATION (UPDATE Message Error/Invalid Network Field) and session goes down. I cannot rule out implementation bug in FRR version that I use, and I discuss it with FRR folks already. Working workaround that I tested is to apply `next hop self` on Bird side. Probably `bgp_next_hop = bgp_next_hop` in Bird’s export policy will also work but I must test it yet. What do you think? It’s a bug or a feature? Regards, Grzegorz

4 9

OSPfv3 IPV4 over local link on freebds
by benoitc＠enki-multimedia.eu 26 Jan '25

26 Jan '25

Hi all, I am looking at reducing the number of IPv4s I am using but i'ms truggling to have loopback propagation over local link using OSPv3 on freebsd. Did someone tried it? Can you share your related configuration? when i setup the ip on lo1 and pass as stub in the OSPfV3 IPv4 iinstances, no ipv4 route is exported. any hint is welcome. Benoît

3 4

radvd lifetime question
by Nico Schottelius 23 Jan '25

23 Jan '25

Hello, we got a network in which clients using dhcpcd withdraw the router advertisements sent by bird too early: -------------------------------------------------------------------------------- Dec 19 06:33:15 bibimbap daemon.warn dhcpcd[18464]: wlan0: fe80::20d:b9ff:fe48:3bb8: router expired Dec 19 06:33:15 bibimbap daemon.warn dhcpcd[18464]: wlan0: part of a Router Advertisement expired Dec 19 06:38:22 bibimbap daemon.warn dhcpcd[18464]: wlan0: fe80::20d:b9ff:fe48:3bb8: router expired Dec 19 06:38:22 bibimbap daemon.warn dhcpcd[18464]: wlan0: part of a Router Advertisement expired Dec 19 06:39:30 bibimbap daemon.warn dhcpcd[18464]: wlan0: fe80::20d:b9ff:fe46:3bd4: router expired Dec 19 06:39:30 bibimbap daemon.warn dhcpcd[18464]: wlan0: part of a Router Advertisement expired -------------------------------------------------------------------------------- The config in bird is: -------------------------------------------------------------------------------- protocol radv { # Pods / bridge interface "eth0" { max ra interval 10; prefix 2a0a:5480::/64 { preferred lifetime 86400; }; prefix 2a0a:e5c0:13::/64 { skip; }; default preference high; }; rdnss { ns 2a0a:5480:0:a::a; ns 2a0a:5480:0:a::b; lifetime 86400; }; } -------------------------------------------------------------------------------- This causes RAs to be sent that look like this: -------------------------------------------------------------------------------- interface wlan0 { AdvSendAdvert on; # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump AdvManagedFlag off; AdvOtherConfigFlag off; AdvReachableTime 0; AdvRetransTimer 0; AdvCurHopLimit 64; AdvDefaultLifetime 30; AdvHomeAgentFlag off; AdvDefaultPreference low; prefix 2a0a:5480::/64 { AdvValidLifetime 86400; AdvPreferredLifetime 86400; AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; }; # End of prefix definition RDNSS 2a0a:5480:0:a::a 2a0a:5480:0:a::b { AdvRDNSSLifetime 86400; }; # End of RDNSS definition }; # End of interface definition -------------------------------------------------------------------------------- It seems that the "AdvDefaultLifetime 30;" is wrong. Trying to fix it using -------------------------------------------------------------------------------- interface "eth0" { default lifetime 86400; -------------------------------------------------------------------------------- fails as bird reports: -------------------------------------------------------------------------------- /bird/bird.conf:897:31 Default lifetime must be in range 0-9000 -------------------------------------------------------------------------------- I read in the manpage of radvd that indeed 9000 is the max (not sure why that limit is at 9k though...), but what I am wondering is what is the right approach to this? Or is this a bug in dhcpcd? BR, Nico p.s.: A low "max ra interval" allows us to run multiple, active routers in the same network and clients will quickly fall over to the second router, if one is not functioning correctly. -- Sustainable and modern Infrastructures by ungleich.ch

2 1

BIRD 3.0.1 Ignoring GW Attribute
by Hutchinson, Peter 21 Jan '25

21 Jan '25

It seems that BIRD 3.0.1 is ignoring the GW attribute, after upgrading from BIRD 2.16.1 to 3.0.1 all routes are showing as unreachable as shown below. The BGP peers are 3 hops away from BIRD within the same AS hence the need for the GW. Note I did not modify the BIRD configuration in between upgrading from 2.16.1 to 3.0.1. birdc 'show route all for 1.1.1.1' BIRD 2.16.1 ready. Table master4: 1.1.1.0/24 unicast [wel_core30 2025-01-16 from 203.14.14.10] * (100/?) [AS13335i] via 203.41.0.5 on ens3 Type: BGP univ BGP.origin: IGP BGP.as_path: 13335 BGP.next_hop: 203.14.14.65 BGP.local_pref: 100 BGP.aggregator: 172.68.0.1 AS13335 BGP.community: (1221,110) (13335,10084) BGP.originator_id: 203.14.14.65 BGP.cluster_list: 203.14.14.10 unicast [pie_core30 2025-01-16 from 203.14.14.11] (100/?) [AS13335i] via 203.41.0.5 on ens3 Type: BGP univ BGP.origin: IGP BGP.as_path: 13335 BGP.next_hop: 203.14.14.65 BGP.local_pref: 100 BGP.aggregator: 172.68.0.1 AS13335 BGP.community: (1221,110) (13335,10084) BGP.originator_id: 203.14.14.65 BGP.cluster_list: 203.14.14.11 birdc 'show route all for 1.1.1.1' BIRD 3.0.1 ready. Table master4: 1.1.1.0/24 unreachable [wel_core30 11:21:09.045 from 203.14.14.10] * (100) [AS13335i] hostentry: via 203.14.14.65 table master4 preference: 100 igp_metric: 0 from: 203.14.14.10 source: BGP bgp_origin: IGP bgp_path: 13335 bgp_next_hop: 203.14.14.65 bgp_local_pref: 100 bgp_aggregator: 172.68.0.1 AS13335 bgp_community: (1221,110) (13335,10084) bgp_originator_id: 203.14.14.65 bgp_cluster_list: 203.14.14.10 Internal route handling values: 0L 11G 0S id 417853 unreachable [pie_core30 11:21:13.738 from 203.14.14.11] (100) [AS13335i] hostentry: via 203.14.14.65 table master4 preference: 100 igp_metric: 0 from: 203.14.14.11 source: BGP bgp_origin: IGP bgp_path: 13335 bgp_next_hop: 203.14.14.65 bgp_local_pref: 100 bgp_aggregator: 172.68.0.1 AS13335 bgp_community: (1221,110) (13335,10084) bgp_originator_id: 203.14.14.65 bgp_cluster_list: 203.14.14.11 Internal route handling values: 0L 9G 0S id 1516013 The BIRD configuration used is shown below. log syslog all; router id 203.41.0.6; roa4 table roa_v4; roa6 table roa_v6; #Inbound route policy filter rpl_in { gw = 203.41.0.5; accept; } #BGP IPv4 neighbor config template template bgp CORE_PEERS { local as 1221; neighbor as 1221; password REDACTED; ipv4 { import filter rpl_in; export none; }; } #BGP IPv6 neighbor config template template bgp CORE_PEERS_V6 { local as 1221; neighbor as 1221; password REDACTED; ipv6 { import filter rpl_in; export none; }; } #Import device routes for TID interface protocol device { scan time 10; interface "ens3"; } #Import directly connected routes for TID interface protocol direct { ipv4; ipv6; interface "ens3"; } #BGP IPv4 core peer 1 protocol bgp wel_core30 from CORE_PEERS { neighbor 203.14.14.10; } #BGP IPv4 core peer 2 protocol bgp pie_core30 from CORE_PEERS { neighbor 203.14.14.11; } #BGP IPv6 core peer 1 protocol bgp wel_core30_v6 from CORE_PEERS_V6 { neighbor 2001:8000::70:101; } #BGP IPv6 core peer 2 protocol bgp pie_core30_v6 from CORE_PEERS_V6 { neighbor 2001:8000::70:201; } #RPKI cache server 1 protocol rpki rpki_cache_1{ roa4 { table roa_v4; }; roa6 { table roa_v6; }; remote REDACTED port 8323; transport tcp; refresh 300; expire keep 3600; } #RPKI cache server 2 protocol rpki rpki_cache_2{ roa4 { table roa_v4; }; roa6 { table roa_v6; }; remote REDACTED port 8323; transport tcp; refresh 300; expire keep 3600; } Regards, Peter Hutchinson TID Core Internet Edge & Core Global Networks & Technology, Transport & IP [cid:1dfbd70b-26ae-414d-aa87-8a8e859368d7] 0490338570 peter.hutchinson(a)team.telstra.com<mailto:peter.hutchinson@team.telstra.com> www.telstra.com<http://www.telstra.com/> This email may contain confidential information. If I've sent it to you by accident, please delete it immediately. General

1 0

third (?) bug in 3.0.0
by Marek Zarychta 14 Jan '25

14 Jan '25

I tried BIRD 3 on FreeBSD, seems to build fine including both flavors: netlink and rtsock. Only the netlink flavor was tested in runtime. In small, testing scenario with OSPF and BGP it seems to run fine. When deployed in production setup with dual-stack and 2x full-view the daemon crashes almost immediately with SIGSEGV. It was non-debug built, so cores will not be much useful, though I can share them. Cheers -- Marek Zarychta

2 3

igp_metric attribute of bird 3.0.1
by Aihui Sun 13 Jan '25

13 Jan '25

Hi,there! Cannot access value of igp_metric from within filter. e.g igp_metric = igp_metric + 100; The igp_metric value does not change. Is there something wrong with my operation? Thanks

2 1