- Bird-users - Mailing Lists

BGP keepalive packets delayed during reconfigure
by Damian Zaremba 05 Mar '21

05 Mar '21

Hi, I recently observed a case where bird 2.0.7 stopped emitting keepalive packets to configured neighbors during a protocol reconfigure. To replicate this condition I have constructed a single BGP session that is fed a large number of filtered routes, the configuration structure resembles; protocol static -> table source -> protocol pipe [import filters] -> table neighbor -> protocol bgp Changing a route attribute in the source table and calling `reconfigure` results in the following observations; 1. Bird logs on the sender side show a slow reconfigure; 2021-03-05 10:28:19.872 <TRACE> bgp1: Sending KEEPALIVE 2021-03-05 10:28:34.886 <TRACE> bgp1: Sending KEEPALIVE 2021-03-05 10:28:53.772 <TRACE> bgp1: Sending KEEPALIVE 2021-03-05 10:28:56.259 <INFO> Reconfiguring 2021-03-05 10:45:13.606 <TRACE> bgp1: Sending KEEPALIVE 2021-03-05 10:45:13.611 <WARN> I/O loop cycle took 966448 ms for 1016 events 2021-03-05 10:45:13.612 <INFO> Reconfigured 2021-03-05 10:45:13.612 <TRACE> bgp1: Got KEEPALIVE 2021-03-05 10:45:13.612 <TRACE> bgp1: Got KEEPALIVE 2021-03-05 10:45:13.612 <TRACE> bgp1: Got KEEPALIVE 2021-03-05 10:45:13.612 <RMT> bgp1: Received: Hold timer expired 2021-03-05 10:46:06.106 <TRACE> bgp1: Sending KEEPALIVE 2021-03-05 10:46:24.541 <TRACE> bgp1: Sending KEEPALIVE 2021-03-05 10:46:42.282 <TRACE> bgp1: Sending KEEPALIVE 2. Packet capture shows the client receiving no keepalives and then multiple close together; $ cat bgp.pcap | pbgpp --filter-message-type=KEEPALIVE --formatter=LINE - 1614940133.773725 KEEPALIVE None None None 1614940138.282074 KEEPALIVE None None None 1614940154.308565 KEEPALIVE None None None 1614940174.343514 KEEPALIVE None None None 1614940190.374193 KEEPALIVE None None None 1614941113.607580 KEEPALIVE None None None 1614941166.106192 KEEPALIVE None None None 1614941166.106316 KEEPALIVE None None None 1614941183.134392 KEEPALIVE None None None 1614941184.541810 KEEPALIVE None None None 1614941200.157543 KEEPALIVE None None None 1614941202.282814 KEEPALIVE None None None 1614941214.180433 KEEPALIVE None None None 1614941217.732128 KEEPALIVE None None None 1614941234.209164 KEEPALIVE None None None 1614941236.416377 KEEPALIVE None None None 1614941250.233110 KEEPALIVE None None None 1614941253.668823 KEEPALIVE None None None 1614941268.260864 KEEPALIVE None None None 1614941269.668392 KEEPALIVE None None None 1614941285.289222 KEEPALIVE None None None 1614941287.120920 KEEPALIVE None None None 1614941301.314094 KEEPALIVE None None None 1614941302.270840 KEEPALIVE None None None 1614941319.342323 KEEPALIVE None None None 1614941321.92028 KEEPALIVE None None None 1614941335.366858 KEEPALIVE None None None 1614941337.417243 KEEPALIVE None None None 1614941352.392059 KEEPALIVE None None None 1614941356.43815 KEEPALIVE None None None 1614941369.420711 KEEPALIVE None None None 1614941373.705122 KEEPALIVE None None None 1614941386.445406 KEEPALIVE None None None 1614941391.885447 KEEPALIVE None None None 1614941403.473187 KEEPALIVE None None None 1614941407.172799 KEEPALIVE None None None 1614941419.498776 KEEPALIVE None None None The 6th packet is 15min after the 5th packet then they spread back out to the intervals seen in the steady state. 3. Client trips off on timers until we get to a converged state on the sender; 2021-03-05 10:29:53 <RMT> bgp1: Error: Hold timer expired 2021-03-05 10:34:05 <RMT> bgp1: Error: Hold timer expired 2021-03-05 10:39:38 <RMT> bgp1: Error: Hold timer expired 2021-03-05 10:43:48 <RMT> bgp1: Error: Hold timer expired I suspect this is down to the scheduling of BGP packets more generally as we also observed the case where a route addition into a bgp protocol (as reported by trace) was not seen as an UPDATE by the client for multiple minutes during a reconfigure. - Damian

2 1

[PATCH] Add 'preferred' route attribute for selective add-path
by Trisha Biswas 04 Mar '21

04 Mar '21

Hi all, The attached patch adds a 'preferred' route attribute to check whether the route being processed has been selected as the best-path for the network it belongs to. This attribute does not take in a value, and returns a boolean. This is useful for allowing selection in an add-path enabled BGP session. The motivation behind selective add paths is to reduce the number of routes that are shared in an add-path enabled BGP session on a per-prefix basis. Instead of sending all paths to all destinations for an add-path session, we would like to specify prefixes (and/or other route attributes) for which all paths are to be shared. Further, if there are thousands of ways to reach a destination, simply negotiating add paths for a prefix would result in sharing all additional paths to the peer. This in turn would result in a flood of advertisements to be sent between the nodes, and a high memory footprint on the peer. To avoid this, we are considering a filter-based selection criteria that would unlock the potential of purposefully sending additional paths when desired. Adding the 'preferred' keyword allows us to always send the best-path whether or not other criteria in the export filter match. In the following example, a route is exported when it is either the best route or one of 172.16.0.0/16, 10.0.0.0/8{16,24} (regardless of best route status). In the case of 8.8.8.0/24, we export it if it's the best route, or if it additionally has the specified extended community attached to the route. protocol bgp { [....] add paths tx; export filter { if preferred || (net = [172.16.0.0/16, 10.0.0.0/8{16,24}]) then accept; if preferred || (net = 8.8.8.0/24 && (ro, 1, 2) ~ bgp_ext_community) then accept; #remaining filter code reject; } } Cheers, Trisha -- *Trisha Biswas* | Sr. Software Engineer, Network Systems fastly.com | @fastly <https://twitter.com/fastly> | LinkedIn <http://www.linkedin.com/company/fastly>

3 5

Release schedule for 2.0.8
by Nico Schottelius 04 Mar '21

04 Mar '21

Good evening, about a year ago [0] we discussed the lack of support for IPv4 routes via IPv6 in bird 2.0.7, which lead to the hint of support in 2.0.8. As we are in the final phase of removing IPv4 from our network, I was wondering if there is any plan of a 2.0.8 release to support IPv4 routes via IPv6? Bird is the last instance that is still making us rely on IPv4 for internal routers. If there is no plan, is it possible to support the release process somehow? Best regards, Nico [0] https://bird.network.cz/pipermail/bird-users/2020-April/014411.html -- Sustainable and modern Infrastructures by ungleich.ch

2 2

multithread support
by Marcelo Balbinot 02 Mar '21

02 Mar '21

Hi, I already asked this question at some point, but I am curious about the evolution .. About multi thread support (multi-core cpu use). Is this still a possibility? -- Marcelo Balbinot

3 4

Support for ECMP on FreeBSD 13
by Zhenlei Huang 26 Feb '21

26 Feb '21

Hi, Currently Bird 2.x does not support ECMP on FreeBSD system. Thanks Alexander V. Chernikov's work, the feature ECMP route was enabled by default in FreeBSD 13 amd64 GENERIC. Are there any plans Bird2.x will support ECMP on FreeBSD, or at least on FreeBSD 13 ? Links: https://gitlab.nic.cz/labs/bird/commit/f9f2e280ea4fa1af19d8ce9e54abeb495694… https://reviews.freebsd.org/D26449 Thanks, zlei

5 5

Bird pipe/filter change on "external" conditions
by ico 23 Feb '21

23 Feb '21

Hello, Is there some way to change bird's configuration on some external event? I would use it like this: There are 2 routers, active and passive. Active router exports default route for the rest of network. Passive router has exactly the same configuration, but filters out default route. When active/passive switch function, the new active somehow removes default route filter, the new passive adds default route filter. Another usage would be to change interface cost in OSPF at run-time and thus redirecting traffic from that particular interface. Currently I am doing it with rewritting bird's config file and reloading configuration. Is there some better way? Like setting some variable, which causes changes some filter conditions? Thanks ico

3 3

What causes unreachable OSPF neighbor?
by ico 22 Feb '21

22 Feb '21

Hello, I have 10 routers talking OSPF on a switch on network 10.10.4.0/24. Now I want to add 11th and am unable to make it work. I see the new router in neighbors, also other neighbors on the new router. The new router doesn't get any routes from others, because others see it as unreachable (10.10.4.45 is the new router, 10.10.4.48 is one of old working routers): bird> show ospf topology all ... router 10.10.4.45 unreachable network 10.10.4.0/24 metric 10 router 10.10.4.48 distance 10 network 10.8.253.0/26 metric 50 network 10.10.4.0/24 metric 10 ... On the new router - all old routers are unreachable: bird> show ospf topology all ... router 10.10.4.45 distance 0 network 10.10.4.0/24 metric 10 router 10.10.4.48 unreachable network 10.8.253.0/26 metric 50 network 10.10.4.0/24 metric 10 ... The normal traffic (ping, ssh) works of course, IP configuration is currently at minimum (single interface, IP 10.10.4.45/24). OS is Linux 5.10, bird 2.0.7. Thanks for any help with this. ico

1 1

BGP sessions flapping before daemon restart
by Alarig Le Lay 19 Feb '21

19 Feb '21

Hi, Yesterday I added six sessions on a router (3 v4, 3 v6). First, all new sessions were flapping, then the v6 one went stable, but the v4 one were still flapping. I restarted bird and then all the sessions became stable. So I don’t understand why it was limited to IPv4 and why the restart fixed it, and why other sessions weren’t flapping as well (there are 16 in total). Here are pcaps in case I missed something obvious. https://herbizarre.swordarmor.fr/garbage/documents/bird_bgp_flap-1.pcap https://herbizarre.swordarmor.fr/garbage/documents/bird_bgp_flap-2.pcap My side is the Intel MAC. The router has an uptime 147 days, so bird was pretty close to that. I’m running a 4.14.x kernel. Regards, -- Alarig Le Lay

1 0

Next 1.6 release
by Vinod Padmanabhan 18 Feb '21

18 Feb '21

Hi, Are there any plans to release another Bird 1.6 version or will the subsequent releases be based only on Bird 2.x? Thanks, Vinod

2 1

route aggregation
by Kseniya Blashchuk 18 Feb '21

18 Feb '21

Hello! Is there any chance we will have route aggregation for BGP soon? I have found some mentions of it in old emails however it seems that it's not yet implemented. Can anybody share this information? Thanks in advance.

2 1