- Bird-users - Mailing Lists

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

BIRD 3.0.1
by Ondrej Filip 13 Jan '25

13 Jan '25

Dear BIRD Users, let use share with you another announcement today, we are releasing version 3.0.1 of BIRD. We fixed quite some bugs there, as you could already have seen in the list. Most notably, we fixed crashes in dynamic BGP, graceful recovery, deterministic MED, BFD session reconfiguration and kernel path merging. We also fixed inefficiencies in feeds and refeeds and some heap bloating. Last but not least, we fixed the name of the bgp_otc route attribute. The packages are as always in our repository at https://pkg.labs.nic.cz/ and on our website at https://bird.network.cz/ Happy routing! Maria and Ondrej

2 1

porting the MPLS protocol to freebsd
by benoitc＠enki-multimedia.eu 13 Jan '25

13 Jan '25

Hi all, Did anyone tried to port the MPLS protocol to freebsd? What would need to be implemented to make it work? Any guidance is appreciated. Benoît

1 0

BIRD 2.16.1
by Ondrej Filip 11 Jan '25

11 Jan '25

Dear BIRD Users, we are releasing version 2.16.1 of BIRD. We fixed a parser bug in ASPA; the right keyword for aspa providers in static protocol is plural, i.e. providers, not provider as was wrongly enforced in some packages of 2.16. We also fixed crashes on certain ARM architectures due to bad memory alignment, and other minor bugs. The packages are as always in our repository at https://pkg.labs.nic.cz/ and on our website at https://bird.network.cz/ Happy routing! Maria and Ondrej

1 0

[bird graceful restart time] Is there any way to set graceful restart time?
by 이재용 10 Jan '25

10 Jan '25

Hello, We use BIRD for communication with servers with higher-level switches. In our config , there is config to set graceful restart like below. protocol bgp example2 {         import all;         export all;         ...         graceful restart on; } As far as I know, the default value for graceful restart is 120 seconds. But I don't know how to change this time. Please give me some advice on this. Thank you.

2 1

Customer ASN selection from ASPA tables
by Ralph Covelli 10 Jan '25

10 Jan '25

Hello Bird Team! I am able to load my static ASPA tables like normal into the new bird 2.16. bird> show route table at all Table at: 50555 [static1 2024-12-26] * (200) Type: static univ aspa_providers: 970 270470 [static1 2024-12-26] * (200) Type: static univ aspa_providers: 53062 47272 [static1 2024-12-26] * (200) Type: static univ aspa_providers: 174 835 924 1299 6830 6939 20473 21738 25759 34927 35133 41051 48605 50391 50917 52025 52210 58057 210667 212514 212895 However I am unable to select individuals or groups: bird> show route table at all where net.asn = 47272 Table at: bird> show route table at all where net.asn ~ [ 47272 ] Table at: bird> It looks like a spot was missed in filter/f-inst.c or it might have been left out intentionally because net.asn is already used for ROA's. filter/f-inst.c /* Get ROA ASN */ METHOD(T_NET, asn, 0, [[ if (!net_is_roa(v1.val.net)) runtime( "ROA expected" ); RESULT(T_INT, i, (v1.val.net->type == NET_ROA4) ? ((net_addr_roa4 *) v1.val.net)->asn : ((net_addr_roa6 *) v1.val.net)->asn); ]]); + /* Get ASPA ASN */ + METHOD(T_NET, customer_asn, 0, [[ + if (!net_is_aspa(v1.val.net)) + runtime( "ASPA expected" ); + + RESULT(T_INT, i, ((net_addr_aspa *) v1.val.net)->asn); + ]]); I named it customer_asn to avoid the collision but use whatever you want. Everything works great after the small correction: bird> show route table at all where net.customer_asn = 270470 Table at: 270470 [static1 19:05:34.388] * (200) Type: static univ aspa_providers: 53062 bird> show route table at all where net.customer_asn ~ [ 270470, 47272, 19330 ] Table at: 270470 [static1 19:05:34.388] * (200) Type: static univ aspa_providers: 53062 47272 [static1 19:05:34.388] * (200) Type: static univ aspa_providers: 174 835 924 1299 6830 6939 20473 21738 25759 34927 35133 41051 48605 50391 50917 52025 52210 58057 210667 212514 212895 19330 [static1 19:05:34.388] * (200) Type: static univ aspa_providers: 393577 bird> Thanks again for all of your hard work!

1 0

Concerning the structure of ASPA tables and AS0
by Ralph Covelli 09 Jan '25

09 Jan '25

Hello Bird Team! My name is Ralph. I'm a network engineer and C programmer for Hurricane Electric. I am a long time fan of the Bird project! Keep up the great work!! Earlier this year I was tasked with implementing reactive ASPA in our network. My code was based off your older implementation of static ASPA tables here: https://gitlab.nic.cz/labs/bird/-/tree/aspa This older implementation is based off of customer-provider pairs: typedef struct net_addr_aspa { u8 type; u8 padding; u16 length; u32 customer_asn; u32 provider_asn; } net_addr_aspa; I've attached the patch as "bird-2.15.1-aspa-asn-pairs.patch". I took a look at 2.16 and ran into 2 problems. Respectfully, I would like to report two issues with the ASPA code in 2.16. Issue #1) There is no way to tell the difference between a transit entry and an "AS0" entry. $ cat bird-aspa.conf aspa table at; protocol static { aspa; route aspa 12345 transit; route aspa 970 provider 43, 56; route aspa 43970 provider 0; } --- $ ./sbin/birdc BIRD 2.16 ready. bird> show route table at all Table at: 43970 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 0 970 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 43 56 12345 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 0 bird> --- The treatment of AS0 providers is mentioned in section 5 of draft-ietf-sidrops-aspa-verification-19. It is a mechanism for people to announce that "no one should announce this AS". I've attached a snapshot of the global ASPA table as "bird-aspa-v2.16.conf". There is one AS0 announcement as of today. Issue #2) Changes in static ASPA tables are not reflected until entries are removed and re-added. $ cat bird-aspa.conf aspa table at; protocol static { aspa; route aspa 12345 transit; route aspa 970 provider 43, 56; route aspa 43970 provider 0; } bird> show route table at all Table at: 43970 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 0 970 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 43 56 12345 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 0 bird> $ cat bird-aspa.conf aspa table at; protocol static { aspa; route aspa 12345 transit; route aspa 970 provider 43, 56, 78; <---- added AS78 route aspa 43970 provider 0; } $ ./sbin/birdc BIRD 2.16 ready. bird> configure Reading configuration from /home/rpki/bird/etc/bird.conf Reconfigured bird> show route table at all Table at: 43970 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 0 970 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 43 56 <-------- changes not reflected *** 12345 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 0 bird> $ cat bird-aspa.conf aspa table at; protocol static { aspa; route aspa 12345 transit; #route aspa 970 provider 43, 56, 78; <----- remove entries altogether route aspa 43970 provider 0; } $ ./sbin/birdc BIRD 2.16 ready. bird> configure Reading configuration from /home/rpki/bird/etc/bird.conf Reconfigured bird> show route table at all Table at: 43970 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 0 12345 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 0 bird> $ cat bird-aspa.conf aspa table at; protocol static { aspa; route aspa 12345 transit; route aspa 970 provider 43, 56, 78; <------- add entry again route aspa 43970 provider 0; } $ ./sbin/birdc BIRD 2.16 ready. bird> configure Reading configuration from /home/rpki/bird/etc/bird.conf Reconfigured bird> show route table at all Table at: 43970 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 0 970 [static1 20:17:30.142] * (200) Type: static univ aspa_providers: 43 56 78 <--------- changes reflected correctly 12345 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 0 bird> --- This problem does not occur when the ASPA elements are customer-provider pairs. I believe this is an overall design issue, not a simple bug. I will be bringing this issue up with ietf-sidrops. Thanks! -- Ralph Covelli Hurricane Electric / AS6939 Network Engineer

2 8

Bird on Ubuntu VM.
by Mike Neo 09 Jan '25

09 Jan '25

Hi, I currently have 2 servers Dell R310 with Bird 1.6 on Ubuntu (Active/Passive), one full BGP table and one IX, traffic around 400Mbps, simple BGP routing. I also have an HA cluster built on ESXi and I wonder if it would be a good idea to run BIRD (maybe 2.0/3.0?) on a VM (Ubuntu) on this ESXi HA cluster. What are your experiences with this, what are the limitations and recommendations? Kind Regards, Mike

3 4