- Bird-users - Mailing Lists

bird logo and name of the bird
by Marek Küthe 19 Jul '23

19 Jul '23

Hello, I hope it's okay that I ask about this on the Mailling list. I'm currently creating a mod for UnCiv in which I'm incorporating various computer themes such as Yumi from Ubuntu Touch or Xue from Xfce Desktop (see https://codeberg.org/mark22k/UnCiv-Logicians/src/branch/main/Inspiration.md) bird also has a logo - a bird and the font "bird" below it (https://bird.network.cz/ico/head.png) I wanted to ask if the bird has a specific name? Furthermore I wanted to ask if the logo is available in a better resolution? I would be very happy about an answer! Greetings Marek Küthe -- Marek Küthe m.k(a)mk16.de er/ihm he/him

1 0

Graceful shutdown request signal
by Erin Shepherd 17 Jul '23

17 Jul '23

Hello, I run bird on a system which uses systemd as a service supervisor, and would like to implement graceful restart in a way which works well with it. In particular, what I'd like to do is: • If I restart the bird service (e.g. for an upgrade), Bird performs a graceful restart • If I manually stop bird (systemctl stop bird2), shutdown the system, or any other action which is liable to cause a longer period of downtime, perform a graceful restart (for BGP at least) Ideally systemd would have an ExecStopRestart option which could be used to distinguish between stops and restarts, but unfortunately it doesn't (I might submit a feature request for this regardless). However, it does support `KillSignal and RestartKillSignal options.` `So therefore I was wondering how the Bird developers and users would feel about introducing a signal (SIGUSR2 maybe?) which can be used to request that Bird perform a graceful restart?` `- Erin`

5 7

systemctl doesn't specify the syntax error during service restart/reload in bird version 2
by Jimmy Lim 05 Jul '23

05 Jul '23

Hi guys, I have just upgraded the bird version to version 2. I just wonder whether there is anything we should configure for systemd to notify us of a syntax error in bird.conf while doing systemctl reload/restart bird? It is no longer informing me somehow now. # systemctl reload bird # # systemctl restart bird Job for bird.service failed because the control process exited with error code. See "systemctl status bird.service" and "journalctl -xe" for details. # systemctl status bird.service ● bird.service - BIRD Internet Routing Daemon Loaded: loaded (/lib/systemd/system/bird.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Wed 2023-07-05 07:15:25 UTC; 9s ago Process: 71401 ExecStartPre=/usr/lib/bird/prepare-environment (code=exited, status=0/SUCCESS) Process: 71409 ExecStartPre=/usr/sbin/bird -p (code=exited, status=1/FAILURE) Jul 05 07:15:25 n246-040-093 bird[27010]: BGP_session1: State changed to down Jul 05 07:15:25 n246-040-093 bird[27010]: BGP_session1: Channel ipv4 removed Jul 05 07:15:25 n246-040-093 bird[27010]: BGP_session2: State changed to down Jul 05 07:15:25 n246-040-093 bird[27010]: BGP_session2: Channel ipv4 removed Jul 05 07:15:25 n246-040-093 bird[27010]: BGP_session3: State changed to down Jul 05 07:15:25 n246-040-093 bird[27010]: BGP_session3: Channel ipv4 removed Jul 05 07:15:25 n246-040-093 bird[27010]: Shutdown completed Jul 05 07:15:25 n246-040-093 systemd[1]: bird.service: Control process exited, code=exited, status=1/FAILURE Jul 05 07:15:25 n246-040-093 systemd[1]: bird.service: Failed with result 'exit-code'. Jul 05 07:15:25 n246-040-093 systemd[1]: Failed to start BIRD Internet Routing Daemon. It is only when I manually enable, it triggers the error line: # /usr/sbin/bird -f -u bird -g bird bird: /etc/bird/bird.conf:4:1 syntax error, unexpected CF_SYM_UNDEFINED I wonder whether I need to configure anything for BIRD 2? Thanks, Jimmy

1 0

Bird does not prefer older eBGP route - RFC5004 and "older prefer on"
by Mazur, Dariusz 03 Jul '23

03 Jul '23

Hello Bird users, Have you ever use RFC 5004 and “older prefer” knob. I am trying to use it but it seems not to work: 1.Router learns the same route from different ebgp peers, it prefers route from r01a and this route is exported to BGP peers 172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 2023-06-14] * (100) [AS4250627481?] via 192.168.196.129 on vlan.201 unicast [192.168.196.131__r01b.tor106 2023-06-14] (100) [AS4250627481?] via 192.168.196.131 on vlan.202 unicast [192.168.196.133__r02a.tor106 2023-06-14] (100) [AS4250627482?] via 192.168.196.133 on vlan.203 2.Once we lose links to r01a and r01b route from r02a is preferred and exported to BGP peers. It is expected 172.232.160.0/19 unicast [192.168.196.133__r02a.tor106 2023-06-14] * (100) [AS4250627482?] via 192.168.196.133 on vlan.203 3.When links to r01a and r01b. are again online route, route from r01a is pricked as primary and exported to BGP. It causes route oscillation 172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 09:14:19.982] * (100) [AS4250627481?] via 192.168.196.129 on vlan.201 unicast [192.168.196.131__r01b.tor106 09:14:19.896] (100) [AS4250627481?] via 192.168.196.131 on vlan.202 unicast [192.168.196.133__r02a.tor106 2023-06-14] (100) [AS4250627482?] via 192.168.196.133 on vlan.203 4.I believe it is default behavior not to prefer older path. According to documentation RFC 5004 and "prefer older on" should fix my problem, but it does not work. Bird doc says: prefer older switch Standard route selection algorithm breaks ties by comparing router IDs. This changes the behavior to prefer older routes (when both are external and from different peer). For details, see RFC 5004. Default: off. 5. According to documentation RFC 5004 and "prefer older on" should fix my problem, but it does not work. a) added "prefer older on", bgp flapped and routes were re-learnt 172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 09:22:12.949] * (100) [AS4250627481?] via 192.168.196.129 on vlan.201 unicast [192.168.196.131__r01b.tor106 09:22:13.527] (100) [AS4250627481?] via 192.168.196.131 on vlan.202 unicast [192.168.196.133__r02a.tor106 09:22:12.683] (100) [AS4250627482?] via 192.168.196.133 on vlan.203 b) shut links to r01a and r01b 172.232.160.0/19 unicast [192.168.196.133__r02a.tor106 09:22:12.683] * (100) [AS4250627482?] via 192.168.196.133 on vlan.203 c) unshut links to r01a and r01b, route from r01a is again preferred, so looks like "older" knob does not work 172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 09:27:55.841] * (100) [AS4250627481?] via 192.168.196.129 on vlan.201 unicast [192.168.196.131__r01b.tor106 09:27:54.448] (100) [AS4250627481?] via 192.168.196.131 on vlan.202 unicast [192.168.196.133__r02a.tor106 09:22:12.683] (100) [AS4250627482?]. ---> this route is older via 192.168.196.133 on vlan.203 Thanks, Dariusz

2 3

typo in the documentation
by Alexander Zubkov 30 Jun '23

30 Jun '23

Hello, I've found a typo in the documenation. The problem is the "/" symbol in the prefix mask that finishes the formatting definition. The patch is attached. Best regards, Alexander Zubkov

2 1

RE: [PATCH] IPv4 over IPv6 nexthop support on FreeBSD
by Alexander Chernikov 24 Jun '23

24 Jun '23

Hi Ondrej, Could you please consider merging IPv4 over IPv6 support for FreeBSD Netlink as well? It seems like the patch slipped through the cracks :-( Sorry for not replying to the thread, it got purged by my email client. The original message: https://bird.network.cz/pipermail/bird-users/2023-April/016857.html /Alexander

3 6

BFD Intermittent Issues
by Richard Laager 23 Jun '23

23 Jun '23

MICE (IXP in Minneapolis, MN, USA) has had a couple reports of participants seeing BFD issues. For the most recent example, the participant's router is sending BFD to the route server (confirmed via a packet capture on the route server), but BIRD simply did not respond. Both their IPv4 and IPv6 sessions to rs1 (the first route server) were acting this way, while both of their sessions to rs2 were fine. I compared the route servers and found two other inconsistencies: one network with IPv4 and one network with IPv6. Here's what the packet capture shows: BFD Control message 001. .... = Protocol Version: 1 ...0 0011 = Diagnostic Code: Neighbor Signaled Session Down (0x03) 01.. .... = Session State: Down (0x1) Message Flags: 0x48, Control Plane Independent: Set 0... .. = Poll: Not set .0.. .. = Final: Not set ..1. .. = Control Plane Independent: Set ...0 .. = Authentication Present: Not set .... 0. = Demand: Not set .... .0 = Multipoint: Not set Detect Time Multiplier: 3 (= 6000 ms Detection time) Message Length: 24 bytes My Discriminator: 0x0000024d Your Discriminator: 0x0c764401 Desired Min TX Interval: 2000 ms (2000000 us) Required Min RX Interval: 2000 ms (2000000 us) Required Min Echo Interval: 0 ms (0 us) This may have started when rs1 was rebooted for patching, or it might have been due to a fiber cut that disconnected this participant from the fabric. We are not sure exactly on the timing. The participant reset their BGP sessions. This caused the BFD session to come up. We are running BIRD 2.0.8 from Ubuntu's repository on Ubuntu 22.04. Note that this BIRD setup is using the IXP Manager templates to generate the config, so there are separate BIRD processes for IPv4 vs IPv6. A different participant noted they had seen BFD issues in the past. They noted this happened in March. That would have been the prior route servers, which were BIRD 1.x (I believe) on FreeBSD. Note that BFD is configured as passive (i.e. the participant has to initiate it). Relevant config bits: protocol bfd { accept ipv4 direct; interface "en*" { passive on; multiplier 3; min rx interval 500ms; min tx interval 500ms; }; } ... protocol bgp pb_0138_as18451 from tb_rsclient { description "AS18451 - LES.NET"; neighbor 206.108.255.175 as 18451; ipv4 { import limit 120 action restart; import filter f_import_as18451; table t_0138_as18451; export filter f_export_as18451; }; bfd on; } Are there interesting fixes since 2.0.8? I looked at the git commit log and I see this (but it doesn't seem like it would apply): commit 99872676df45f1a490d3d63f43081afb41477040 Author: Ondrej Zajicek <santiago(a)crfreenet.org> Date: Sun Jan 22 23:42:08 2023 +0100 BFD: Improve incoming packet matching For active sessions, ignore received packets with zero local id and mismatched remote id. That forces a session timeout instead of an immediate session restart. It makes BFD sessions more resilient to packet spoofing. Thanks to André Grüneberg for the suggestion. The discussion was here: https://lists.iphouse.net/cgi-bin/wa?A2=ind2306&L=MICE-DISCUSS&T=0&F=&S=&P=… <https://lists.iphouse.net/cgi-bin/wa?A2=ind2306&L=MICE-DISCUSS&T=0&F=&S=&P=…> -- Richard

1 0

BIRD 2.13.1 released
by Ondrej Filip 22 Jun '23

22 Jun '23

Dear BIRD users, we're releasing a bugfix version, 2.13.1. When a case statement in filter had an empty branch, it crashed BIRD. This bug applies to versions 2.13 and 2.0.12. Version 2.0.11 is not affected. Also we fixed a bug in BGP Roles manifesting when the other party sent no capabilities at all. Thanks to Kobayashi_Bairuo <noc(a)tohunet.com> for reporting. Ondrej

1 0

Bird routing daemon memory segfault issue submission
by noc＠tohunet.com 22 Jun '23

22 Jun '23

Hello Bird Development Team: We are AS140731, aka TOHUNET, we use bird as our routing program, we have a problem that may be related to the memory address of bird. Here are the problem details: We designed a function for anycast to balance the unequal length ASPATH between different upstreams and different nodes, it has this structure: function anycast(int AS;int Region;int Country;int NodeID) { if net ~ [2406:840:eb8c::/48] then { case NodeID { 1: { case AS { 6939: {bgp_path.prepend(140731);bgp_path.prepend(140731);} } } } } } Among them, AS represents the peer AS of this session, and NodeID represents the ID of this node. After the conditional statement in the case matches the peer AS, as you can see, it will execute bgp_path.prepend, and it works well when the curly braces of the conditional statement are not empty. But the aspath of some of our nodes is long enough that they don't need to be prepend, so we have the following configuration: function anycast(int AS;int Region;int Country;int NodeID) { if net ~ [2406:840:eb8c::/48] then { case NodeID { 1: { case AS { 6939: {} } } } } } Then the problem occurred. In our example, when the Session at 6939 was established, the conditional statement matched 6939, but the content in the curly braces was empty. At this time, bird will be automatically killed and restarted by Linux due to a memory segment fault. The following is the information we get in journalctl: kernel: bird[11433]: segfault at 0 ip 0000559bb2900c28 sp 00007ffcd21d1fc0 error 4 in bird[559bb2886000+9d000] kernel: Code: 8b 7b 04 83 03 01 41 8d 4f ff 0f 1f 84 00 00 00 00 00 89 cd 48 8d 44 6d 00 48 8d 14 c3 4c 8b a2 08 80 01 00 8b 82 10 80 01 00 <41> 3b 04 24 0f > systemd[1]: bird.service: Main process exited, code=killed, status=11/SEGV The version number we are currently using is: v2.13-5-gf8ba8280 debian11, but we have tried to roll back to v2.13 and update to v2.13-10-gf8bcb037, these problems still exist.

2 1

Different export route target for different prefixes of a same VRF
by Ramanathan Selvamani 22 Jun '23

22 Jun '23

Hi Team, I configured l3vpn in BIRD and I was able to see the routes are learnt and advertised based on RT. All the routes in this VRF are advertised with RT (1:11) to neighbors. I have a use case in which I want to apply different RT for different routes belonging to the same VRF. For example, I have the following prefixes in this VRF "vrf2". 101.1.1.0/24 103.1.1.0/24 105.1.1.0/24 I would like to add different "export route target" as below for routes belong to same VRF 101.1.1.0/24 : export RT 1:11 103.1.1.0/24 : export RT 1:20 105.1.1.0/24 : export RT 1:30 Please let me know if there is any way to achieve this with BIRD configuration. protocol l3vpn l3vpn2 { vrf "vrf2"; ipv4 { table vrf2v4; }; ipv6 { table vrf2v6; }; vpn4 { table vpntab4; }; vpn6 { table vpntab6; }; mpls { label policy aggregate; label range vrfrange; }; rd 1:11; import target [(rt, 1, 11)]; export target [(rt, 1, 11)]; } Thanks, Ramanathan

2 2