March 2021 - Bird-users - Mailing Lists

Static protocol reconfiguration results in sub-optimal route updates
by Damian Zaremba 05 Mar '21

05 Mar '21

Hi, I recently observed a case where bird 2.0.7 emits sub-optimal route updates during a reconfiguration. Using the sample configuration of e.g. ipv4 table seed; ipv4 table announce; protocol static { route 203.0.113.0/24 unreachable; ipv4 { table seed; }; } protocol pipe { table announce; peer table seed; import filter { bgp_large_community.add((65000, 1, 1)); accept; }; } protocol bgp { debug all; ipv4 { table announce; export all; }; local 10.240.0.226 as 65000; neighbor 10.240.1.59 as 65000; } When the pipe configuration is updated to e.g. import filter { bgp_large_community.add((65000, 1, 2)); accept; }; Bird replaces the route into the BGP protocol; 2021-03-05 11:57:36.168 <INFO> Reconfiguring 2021-03-05 11:57:36.168 <INFO> Reloading channel pipe1.sec 2021-03-05 11:57:36.168 <TRACE> bgp1: Reconfigured 2021-03-05 11:57:36.168 <INFO> Reconfigured 2021-03-05 11:57:36.168 <TRACE> bgp1.ipv4 < replaced 203.0.113.0/24 unreachable 2021-03-05 11:57:36.168 <TRACE> bgp1: Sending UPDATE And emits a single update as expected; $ cat bgp.pcap | pbgpp --filter-message-type=UPDATE - [BGPMessage UPDATE] - 63 Bytes |- MAC: 42:01:0a:f0:00:01 -> 42:01:0a:f0:01:3b |- IP: 10.240.0.226:32871 -> 10.240.1.59:179 |- Timestamp: 2021-03-05 12:04:50.255913 (1614945890.255913) | |- Update Message Sub-Type: ANNOUNCE |- Withdrawn Routes Length: 0 Bytes |- Total Path Attribute Length: 36 Bytes |- Prefix (NLRI): |--- 203.0.113.0/24 |- Path Attributes: |--- ORIGIN: IGP |- Path Attributes: |--- AS_PATH: |- Path Attributes: |--- NEXT_HOP: 10.240.0.226 |- Path Attributes: |--- LOCAL_PREF: |- Path Attributes: |--- LARGE_COMMUNITIES: 65000:1:2 However if we directly feed the table from a static protocol e.g. ipv4 table announce; protocol static { route 203.0.113.0/24 unreachable; ipv4 { table announce; import filter { bgp_large_community.add((65000, 1, 1)); accept; }; }; } protocol bgp { debug all; ipv4 { table announce; export all; }; local 10.240.0.226 as 65000; neighbor 10.240.1.59 as 65000; } The same filter update results in a protocol restart e.g. 2021-03-05 12:10:39.042 <INFO> Reconfiguring 2021-03-05 12:10:39.042 <INFO> Cannot reconfigure channel static1.ipv4 2021-03-05 12:10:39.042 <INFO> Restarting protocol static1 2021-03-05 12:10:39.042 <TRACE> bgp1: Reconfigured 2021-03-05 12:10:39.042 <TRACE> bgp1.ipv4 < removed 203.0.113.0/24 unreachable 2021-03-05 12:10:39.042 <TRACE> bgp1: Sending UPDATE 2021-03-05 12:10:39.042 <TRACE> bgp1.ipv4 < added 203.0.113.0/24 unreachable 2021-03-05 12:10:39.042 <INFO> Reconfigured 2021-03-05 12:10:39.042 <TRACE> bgp1: Sending UPDATE And our client receives 2 distinct UPDATE packets, the first being an explicit withdrawal, followed by an announcement; [BGPMessage UPDATE] - 27 Bytes |- MAC: 42:01:0a:f0:00:01 -> 42:01:0a:f0:01:3b |- IP: 10.240.0.226:48185 -> 10.240.1.59:179 |- Timestamp: 2021-03-05 12:10:39.43871 (1614946239.43871) | |- Update Message Sub-Type: WITHDRAWAL |- Withdrawn Routes Length: 4 Bytes |- Total Path Attribute Length: 0 Bytes |- Withdrawn Routes: |--- 203.0.113.0/24 [BGPMessage UPDATE] - 63 Bytes |- MAC: 42:01:0a:f0:00:01 -> 42:01:0a:f0:01:3b |- IP: 10.240.0.226:48185 -> 10.240.1.59:179 |- Timestamp: 2021-03-05 12:10:39.44893 (1614946239.44893) | |- Update Message Sub-Type: ANNOUNCE |- Withdrawn Routes Length: 0 Bytes |- Total Path Attribute Length: 36 Bytes |- Prefix (NLRI): |--- 203.0.113.0/24 |- Path Attributes: |--- ORIGIN: IGP |- Path Attributes: |--- AS_PATH: |- Path Attributes: |--- NEXT_HOP: 10.240.0.226 |- Path Attributes: |--- LOCAL_PREF: |- Path Attributes: |--- LARGE_COMMUNITIES: 65000:1:2 When this happens during a long converge, the clients can experience a significant gap between the withdrawal and announcement causing sub-optimal state on the clients; we have observed this to be more than 10min in edge cases. Under Bird 1.6.5 we see the same restart & route remove/add in the log however we see only 1 UPDATE emitted reflecting the attribute change e.g. 2021-03-05 12:34:40 <INFO> Reconfiguring 2021-03-05 12:34:40 <INFO> Reloading protocol static1 2021-03-05 12:34:40 <INFO> Restarting protocol static1 2021-03-05 12:34:40 <TRACE> bgp1: Reconfigured 2021-03-05 12:34:40 <INFO> Reconfigured 2021-03-05 12:34:40 <TRACE> bgp1 < removed 203.0.113.0/24 unreachable 2021-03-05 12:34:40 <TRACE> bgp1 < added 203.0.113.0/24 unreachable 2021-03-05 12:34:40 <TRACE> bgp1: Sending UPDATE $ cat bgp.pcap | pbgpp --filter-message-type=UPDATE - [BGPMessage UPDATE] - 63 Bytes |- MAC: 42:01:0a:f0:00:01 -> 42:01:0a:f0:01:3b |- IP: 10.240.0.226:52101 -> 10.240.1.59:179 |- Timestamp: 2021-03-05 12:34:41.414028 (1614947681.414028) | |- Update Message Sub-Type: ANNOUNCE |- Withdrawn Routes Length: 0 Bytes |- Total Path Attribute Length: 36 Bytes |- Prefix (NLRI): |--- 203.0.113.0/24 |- Path Attributes: |--- ORIGIN: IGP |- Path Attributes: |--- AS_PATH: |- Path Attributes: |--- NEXT_HOP: 10.240.0.226 |- Path Attributes: |--- LOCAL_PREF: |- Path Attributes: |--- LARGE_COMMUNITIES: 65000:1:2 - Damian

2 1

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