- Bird-users - Mailing Lists

kernel protocol ignores default preference during scan
by Alexander Zubkov 27 Sep '22

27 Sep '22

Hi, Bird from master branch ignores the default preference set in channel for a kernel protocol, like that: protocol kernel { learn yes; ipv4 { preference 200; import all; export none; }; } Version 2.0.10 seems ok. I suppose the change was introduced with this commit: https://gitlab.nic.cz/labs/bird/-/commit/eb937358c087eaeb6f209660cc7ecfe6d6… It adds setting of the preference to the krt_learn_async() function. But as I understand when route is learned with netlink hook it is processed like this: nl_parse_route -> krt_got_route_async -> krt_learn_async But when it is learned from scan, it is processed like this: nl_parse_route -> krt_got_route -> krt_learn_scan And setting preference was not added to krt_learn_scan() function. I also saw that in my test - when I added a new route to the kernel while bird was running, it appeared in bird with correct preference. But some time after, the scan updated the route and it was replaced with the default preference.

2 4

Garbage collection of unused dynamic BGP neighbours
by Tore Anderson 21 Sep '22

21 Sep '22

Hi Is it possible to garbage collect unused dynamic BGP neighbours? In my environment, these come and go because the dynamic BGP neighbours are themselves quite dynamic (orchestrated containers that get a new IP address every time they are updated or restarted). This causes BIRD to accumulate non-Established «dynbgpN» protocol instances. I would like to get rid of them. Ideally the protocol instance would have vanished by itself the moment it exited the Established state, but since that does not happen, I am hoping there might be a way of deleting them manually (e.g., with birdc)? Tore

3 3

Re: MPLS L3VPN using bird
by Jose Miguel Bentue 16 Sep '22

16 Sep '22

Hello, The goal is to gain communication from a linux based host to another PE-CE by using MPLS L3VPN. To your question: * "configure the PE functionality, connecting to other PE via BGP with MPLS (AFI 1 / SAFI 128) + mpls-labeled packets" Yes, I understand that's first step and it is done by using "vpn4 mpls" channel, am I right? Once the BGP session is established, I see the routes in bird's vpn4 table. * " CE via BGP AFI 1 / SAFI 1 (unicast) + normal IP packets" Actually, I don't know. I understand I have to send traffic to PE so it is routed into MPLS L3VPN but I don't know how to do it. I would appreciate if you could clarify. Thanks and Best Regards, -------------------------------------------------- José Miguel Bentué Support Engineer GSM: +34649930789 FIX: +34912032938 FAX: +34916501100 Mail: josemiguel.bentue(a)emea.nec.com NEC IBERICA S.L. c/Anabel Segura, 7 28108-Alcobendas Madrid ________________________________ From: Bird-users on behalf of Maria Matejka Sent: Thursday, September 15, 2022 8:07 PM To: bird-users(a)network.cz Subject: Re: MPLS L3VPN using bird Hello! This part of MPLS is not implemented for now. Yet to clarify this, you want to configure the PE functionality, connecting to other PE via BGP with MPLS (AFI 1 / SAFI 128) + mpls-labeled packets and also to CE via BGP AFI 1 / SAFI 1 (unicast) + normal IP packets? Thanks Maria On 9/15/22 19:33, Jose Miguel Bentue wrote: > Hello, > > I'm trying to establish MPLS L3VPN between bird and another router. > > CE1 -- PE1 --- MPLS VPN --- PE2 -- CE2 > > Can anybody help me with a configuration example? > > I have set the configuration at the end of the mail and can see bird > establish the BGP session and get routes in alt_ipv4_table. But I don't > see the traffic is being routed according to that table. > > Thanks in advance and Best Regards > > =========================================== > vpn4 table alt_ipv4_table; > > log syslog all; > > router id 10.7.3.106; > > protocol device { > scan time 10; > } > > protocol kernel { > learn; > persist; > scan time 2; > ipv4 { > import all; > export all; > }; > graceful restart; > merge paths on; > } > > protocol bgp uplink1 { > description "My BGP uplink"; > local 10.7.3.106 as 64516; > neighbor 10.7.3.180 as 64513; > ipv4 { > import filter {reject;}; > export filter {accept;}; > }; > vpn4 mpls { > table alt_ipv4_table; > import all; > export none; > }; > multihop; > graceful restart; > connect delay time 2; > connect retry time 5; > error wait time 5,30; > } > ============================================ > > > -------------------------------------------------- > > *José Miguel Bentué* > > Support Engineer > > > > ------------------------------------------------------------------------ > *Jose Miguel Bentue *| VAS Support Engineer | NEC Iberica S.A.U. | C/ > Anabel Segura 7, Madrid, 28108, ES | t: +34912032938 | m: +34649930789 | > w: www.nec.com<http://www.nec.com> > > This email (including any attached files) is private and confidential > and the exclusive property of NEC Ibérica S.L.U. This message is > addressed exclusively to its recipient. If you have received this > message by mistake, please notify the sender immediately and proceed to > delete the message. Unless you have express permission to do so, please > do not distribute or copy this email. Except as otherwise stated, the > sender does not intend to create a legal relationship and this email > shall not constitute an offer or acceptance which could give rise to a > contract. View our privacy policy here: > https://es.nec.com/es_ES/emea/privacy/index.html > > Este correo electrónico (incluyendo cualquier archivo adjunto) contiene > información privada y confidencial y es propiedad exclusiva de NEC > Iberica S.L. Este mensaje se dirige exclusivamente a su destinatario. Si > ha recibido este mensaje por error, por favor notifíquelo al remitente > de inmediato y proceda a eliminarlo de su sistema. A menos que tenga > permiso expreso para hacerlo, por favor no distribuya ni copie este > correo electrónico. Salvo que se indique lo contrario, el remitente no > tiene la intención de establecer una relación legal y este correo > electrónico no constituirá una oferta o aceptación que pueda dar lugar a > un contrato. Vea nuestra política de privacidad aquí: > https://es.nec.com/es_ES/emea/privacy/index.html | Registered Office: > NEC Ibérica S.L., Calle Anabel Segura 7, 2ª Plta- 28108 Alcobendas, > Madrid, Spain

2 1

MPLS L3VPN using bird
by Jose Miguel Bentue 15 Sep '22

15 Sep '22

Hello, I'm trying to establish MPLS L3VPN between bird and another router. CE1 -- PE1 --- MPLS VPN --- PE2 -- CE2 Can anybody help me with a configuration example? I have set the configuration at the end of the mail and can see bird establish the BGP session and get routes in alt_ipv4_table. But I don't see the traffic is being routed according to that table. Thanks in advance and Best Regards =========================================== vpn4 table alt_ipv4_table; log syslog all; router id 10.7.3.106; protocol device { scan time 10; } protocol kernel { learn; persist; scan time 2; ipv4 { import all; export all; }; graceful restart; merge paths on; } protocol bgp uplink1 { description "My BGP uplink"; local 10.7.3.106 as 64516; neighbor 10.7.3.180 as 64513; ipv4 { import filter {reject;}; export filter {accept;}; }; vpn4 mpls { table alt_ipv4_table; import all; export none; }; multihop; graceful restart; connect delay time 2; connect retry time 5; error wait time 5,30; } ============================================ -------------------------------------------------- José Miguel Bentué Support Engineer ________________________________ Jose Miguel Bentue | VAS Support Engineer | NEC Iberica S.A.U. | C/ Anabel Segura 7, Madrid, 28108, ES | t: +34912032938 | m: +34649930789 | w: www.nec.com This email (including any attached files) is private and confidential and the exclusive property of NEC Ibérica S.L.U. This message is addressed exclusively to its recipient. If you have received this message by mistake, please notify the sender immediately and proceed to delete the message. Unless you have express permission to do so, please do not distribute or copy this email. Except as otherwise stated, the sender does not intend to create a legal relationship and this email shall not constitute an offer or acceptance which could give rise to a contract. View our privacy policy here: https://es.nec.com/es_ES/emea/privacy/index.html Este correo electrónico (incluyendo cualquier archivo adjunto) contiene información privada y confidencial y es propiedad exclusiva de NEC Iberica S.L. Este mensaje se dirige exclusivamente a su destinatario. Si ha recibido este mensaje por error, por favor notifíquelo al remitente de inmediato y proceda a eliminarlo de su sistema. A menos que tenga permiso expreso para hacerlo, por favor no distribuya ni copie este correo electrónico. Salvo que se indique lo contrario, el remitente no tiene la intención de establecer una relación legal y este correo electrónico no constituirá una oferta o aceptación que pueda dar lugar a un contrato. Vea nuestra política de privacidad aquí: https://es.nec.com/es_ES/emea/privacy/index.html | Registered Office: NEC Ibérica S.L., Calle Anabel Segura 7, 2ª Plta- 28108 Alcobendas, Madrid, Spain

2 1

State of development of the 3.0-alpha1 version
by Maria Matejka 14 Sep '22

14 Sep '22

Hello everybody! After the holiday period is over, I'm returning to occasional reporting of v3.0 development. This is NOT AN ANNOUNCEMENT, just a progress report. If you haven't read my previous reports, my last report is here in the archives: http://trubka.network.cz/pipermail/bird-users/2022-July/016222.html And now let's look at the progress. If you wanna see the commits, look at the thread-next branch. No liability and no guarantee indeed, please don't run that code on a production machine. * There are some backported changes to v2 branches and they'll be included in the next BIRD version, notably some changes in route attribute storage. Their performance impact should be negligible and there should be no changes in visible behavior, yet they'll make future v2 features more likely to be smoothly merged into v3 * The nexthop resolving, flowspec revalidation and also roa-induced autoreload procedures are now better fitting into the asynchronous nature of table change announcements. This will allow easy implementation of future improvements to reload only the affected routes. Now we simply reload everything but the path to partial reloads is open. * There are still pending performance improvements on attribute storage, yet they're to be done after BIRD based on thread-next branch is stable running tables, BGP, RPKI and Pipes in their own threads. * MRT is still insecure but finally quite high on the list. * I spent most of the past 3 months on merging v2 branches and pre-multithreading commits, trying to resolve all the problems. The goal is now to keep pace with the v2 branch tip and actively resolve merging conflicts by suggesting and choosing the right strategy of new feature implementation in v2 branches to be compatible with asynchronicity and locking. * With some help of Santiago, I constructed a lockless event queue, removing one of main problems in 3.0-alpha0 -- locking on event manipulation. Now it's possible for multiple threads to safely enqueue into the same queue without locking, and also to enqueue the same event to the same queue (which is idempotent as it should be). I'll thoroughly describe this data structure in a future blogpost. * We also decided to add another locking layer between Table and Protocol (see my blogpost[1]), called Service. In 3.0-alpha0, the table auxiliary routines (next hop update, route pruning etc.) were executed in an IO loop running on Table level; now it's moved to the Service level, slightly reducing the time when table is locked for maintenance and also fixing some previous problems. * The Service layer will also host some MRT and BMP routines. If we thought more about this formerly, we may have had also BFD on this layer, yet I think it isn't necessary to move BFD there now. * For now, I have BIRD in the state when the Pipes and Tables have their own threads and I'm going to spend like a week or so resetting our performance testing machinery, producing some data and hoping for good BIRD stablility. * After that, I'll continue merging 3.0-alpha0 to thread-next, hoping that I get to RPKI and BGP threads in a meaningful time. In theory, this merge should be smooth, supposing that I'll probably revert most of the commits in 3.0-alpha0, having the issues already solved in thread-next in a different way. * I'm also trying to find some time to reset our issue tracker at gitlab.nic.cz and fill it at least with issues regarding multithreading, better also filling it with our almost infinite backlog. That should be a tool not only for the development organization but also for everybody else who is curious about how BIRD works inside. Let's test it and we'll see the outcomes. So here you are with the report. I hope it's complete. Feel free to ask for clarification. I'd like also to produce some more blogposts, hopefully during the next week. Maria [1] https://en.blog.nic.cz/2022/02/09/bird-journey-to-threads-chapter-3-paralle…

1 0

TEXT in case constraint
by Mikhail Mayorov 03 Sep '22

03 Sep '22

Hi all! I'll try string variables in CASE. But I have error - "syntax error, unexpected TEXT" function casetest(string aaa) { if aaa ~ "a1" then print "ok"; case aaa { "a1" : print "a1"; "b1" : print "b1"; else: print "not a1, nor b1"; } } Sometimes it will be comfortable. Why it is error? -- Regards, Mikhail V. Majorov

2 1

bind RIP protocol to specified address
by Ivan 25 Aug '22

25 Aug '22

Hi all. I use bird2 (2.0.7) on linux, I want to configure the RIP protocol so that it uses the specified source address. I have two addresses assigned on the network interface, for example 192.0.2.1/32 and 198.51.100.1/31. bird chooses 192.0.2.1 as the source address, but I want the source address to be 198.51.100.1. How do I set the source address for the RIP protocol ? Thank you.

2 1

v2.0.10 for bullseye-backports?
by Christoph 15 Aug '22

15 Aug '22

Hi, are there any plans to update bird2 in debian backports from 2.0.8 to 2.0.10? thanks! Christoph

3 2

OSPF default metric
by Marcus Büttemeyer 11 Aug '22

11 Aug '22

Hello again, I'm wondering how OSPF default metrics are calculated by BIRD? Background: I'm running 4 Linux VMs with BIRD under Hyper-V and BIRD gives me a metric of 10 for every connection, be it 10G (which seems to be the default for vSwitches on Hyper-V), 1G or wireless. Even though the physical speed is passed from the hypervisor to the VMs. At least "cat /sys/class/net/INT/speed" gives the proper value. If I knew where the metric comes from, I could try to fix that on the OS-level and save myself separate cost definitions for every interface. Thanks in advance, Marcus Büttemeyer

2 1

On the possibility of updating BGP passwords without network disruption.
by Calvin Zachman 08 Aug '22

08 Aug '22

Hi BIRD users, Does anyone know whether a BGP shared secret can be rotated without incurring any network downtime? I did some testing with the BGP password functionality offered and it appears that any update to the BGP password configuration incurs a brief network outage with both existing/new connections. It seems like something about the way BIRD is restarting is leading to it pulling down learned routes immediately as opposed to letting them live according to the timeout setting. Does BIRD flush all routes it has learned when this configuration changes? Here is a brief excerpt to demonstrate the outage. Take note that the network disruption precisely matches the timestamp at which BIRD is reconfigured: # Logs from calico-node-4w4bv (10.95.14.104) 2022-06-29 18:26:18.836 [INFO][60] confd/client.go 1415: Trigger to recheck BGP peers following possible password update 2022-06-29 18:26:18.836 [INFO][60] confd/client.go 250: Recompute v1 BGP peerings 2022-06-29 18:26:18.836 [INFO][60] confd/client.go 949: Recompute BGP peerings: bird: Reconfiguration requested by SIGHUP 2022-06-29 18:26:18.844 [INFO][60] confd/resource.go 278: Target config /etc/calico/confd/config/bird.cfg has been updated due to change in key: /calico/bgp/v1/global bird: Reconfiguring bird: device1: Reconfigured bird: direct1: Reconfigured bird: Restarting protocol Mesh_10_95_14_105 bird: Mesh_10_95_14_105: Shutting down bird: Mesh_10_95_14_105: State changed to stop bird: Restarting protocol Mesh_10_95_14_110 bird: Mesh_10_95_14_110: Shutting down bird: Mesh_10_95_14_110: State changed to stop bird: Mesh_10_95_14_105: State changed to down bird: Mesh_10_95_14_105: Initializing bird: Mesh_10_95_14_105: Starting bird: Mesh_10_95_14_105: State changed to start bird: Mesh_10_95_14_110: State changed to down bird: Mesh_10_95_14_110: Initializing bird: Mesh_10_95_14_110: Starting bird: Mesh_10_95_14_110: State changed to start bird: Reconfigured bird: Mesh_10_95_14_110: Connected to table master bird: Mesh_10_95_14_110: State changed to feed bird: Mesh_10_95_14_110: State changed to up bird: Mesh_10_95_14_105: Connected to table master bird: Mesh_10_95_14_105: State changed to feed bird: Mesh_10_95_14_105: State changed to up 2022-06-29 18:26:36.079 [INFO][58] monitor-addresses/autodetection_methods.go 117: Using autodetected IPv4 address 10.95.14.104/26 on matching interface eth0 2022-06-29 18:26:54.537 [INFO][62] felix/summary.go 100: Summarising 9 dataplane reconciliation loops over 1m2.1s: avg=5ms longest=21ms (resync-filter-v4,resync-nat-v4) # Connection Tester Daemonset (hitting an echoserver twice a second or so) Wed Jun 29 18:26:17 UTC 2022 Successful echo server connection Wed Jun 29 18:26:17 UTC 2022 Wed Jun 29 18:26:18 UTC 2022 Successful echo server connection Wed Jun 29 18:26:18 UTC 2022 Wed Jun 29 18:26:18 UTC 2022 curl: (28) Connection timed out after 300 milliseconds Failed to connect to echo server Wed Jun 29 18:26:19 UTC 2022 Wed Jun 29 18:26:19 UTC 2022 curl: (28) Connection timed out after 300 milliseconds Failed to connect to echo server Wed Jun 29 18:26:20 UTC 2022 Wed Jun 29 18:26:20 UTC 2022 Successful echo server connection Wed Jun 29 18:26:20 UTC 2022 # For peer /host/10.95.14.81/ip_addr_v4 protocol bgp Mesh_10_95_14_81 from bgp_template { neighbor 10.95.14.81 as 64512; source address 10.95.14.82; # The local address we use for the TCP connection graceful restart time 1800; # This parameter seems to make no difference when changing BGP passwords password "LJiKASiglY+KafEwEn/cSmkiok0zHgpQq5EtYhYgoDcSQwKIpX22Tz7jOzX+"; } I have perused the RFCs for both BGP Graceful Restart (4724) & Secure BGP Sessions (2385) but haven't found a solid answer yet. When the password is changed it makes complete sense that any peers with the new password will refuse to accept any NEW routes received from peers using the old password and vice versa. I don't see the fundamental reason why TCP segments arriving with some unexpected hash necessitates that previously learned routes from that peer need to be flushed with no TTL, but the observance of the outage suggests that is what is happening. One would think that, in principle, it could wait to tear down existing routes until a configurable timeout (say the graceful restart) expires, providing a window in which we can change the password and maintain stable routing. I am relatively new to BGP and am using BIRD indirectly via Calico for container networking inside Kubernetes. I will of course take things up with the guys behind Calico, but is there anything in the BGP spec/BIRD implementation which fundamentally prevents network disruption free secret rotation? Let me know if there is any place I should look for more information on this or any debug logs which would be helpful. Thanks, Calvin

4 3