From marcelo at gegnet.com.br Mon Mar 1 13:26:21 2021 From: marcelo at gegnet.com.br (Marcelo Balbinot) Date: Mon, 01 Mar 2021 09:26:21 -0300 Subject: multithread support Message-ID: <0a061dd6d25c6cb342d72c29d2b89dc5@gegnet.com.br> 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 From nico.schottelius at ungleich.ch Mon Mar 1 18:38:46 2021 From: nico.schottelius at ungleich.ch (Nico Schottelius) Date: Mon, 01 Mar 2021 18:38:46 +0100 Subject: Release schedule for 2.0.8 Message-ID: <87tupuydsp.fsf@ungleich.ch> 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 From santiago at crfreenet.org Tue Mar 2 05:38:46 2021 From: santiago at crfreenet.org (Ondrej Zajicek) Date: Tue, 2 Mar 2021 05:38:46 +0100 Subject: Release schedule for 2.0.8 In-Reply-To: <87tupuydsp.fsf@ungleich.ch> References: <87tupuydsp.fsf@ungleich.ch> Message-ID: <20210302043846.GE3204@feanor.crfreenet.org> On Mon, Mar 01, 2021 at 06:38:46PM +0100, Nico Schottelius wrote: > > 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. Hi Sorry for the delay. Now we have everything we planned for the 2.0.8, hopefully we can make the release this or next week. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From maria.matejka at nic.cz Tue Mar 2 14:11:32 2021 From: maria.matejka at nic.cz (Maria Matejka) Date: Tue, 2 Mar 2021 14:11:32 +0100 Subject: multithread support In-Reply-To: <0a061dd6d25c6cb342d72c29d2b89dc5@gegnet.com.br> References: <0a061dd6d25c6cb342d72c29d2b89dc5@gegnet.com.br> Message-ID: Hi! On 3/1/21 1:26 PM, Marcelo Balbinot wrote: > > 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? Yes, it is. Be prepared that this will also raise memory usage (current estimates are about >+10% memory) and overall CPU usage (compared to single-thread execution) due to needed synchronization and buffers. This means that if you now consume 20G of memory and 30 minutes of single core time to converge the main table on a rather big node, you're going to consume, let's say, >22G of memory and 3 minutes of 16-core CPU (summing to 48 minutes of CPU time). This is a ball park guess, do not take me much seriously. It may be better, it may be worse. Anyway, there is some code (currently not releasable) that will get to a preview release soon. We'll highly appreciate testing from any user around. Stay tunad! Maria From fischerdouglas at gmail.com Tue Mar 2 16:34:32 2021 From: fischerdouglas at gmail.com (Douglas Fischer) Date: Tue, 2 Mar 2021 12:34:32 -0300 Subject: multithread support In-Reply-To: References: <0a061dd6d25c6cb342d72c29d2b89dc5@gegnet.com.br> Message-ID: This is very good news! I know you said "This is a ball park guess", but I confess that I was a little scared by the proportion of extra CPU usage (30/48 -> +60%). I also know that you said that the code is still "currently not releasable", but I'm curious to know a little more about how this multi-threading was handled. Just to illustrate: Single-Core CPU on BGP is known to be a problem for many engines and vendors. One of the vendors developed a "creative" way to do this load distribution in multiple colors. As I understood it, they made a kind of Affinity CPU by BGP-Peer. In a way that each peer has a BGP process, and that process is "semi-tied" to a core. And they created a mechanism to redistribute these affinities from time-to-time based on the amount of BGP messages per second exchanged on each peer. Em ter., 2 de mar. de 2021 ?s 10:13, Maria Matejka escreveu: > Hi! > > On 3/1/21 1:26 PM, Marcelo Balbinot wrote: > > > > 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? > > Yes, it is. Be prepared that this will also raise memory usage (current > estimates are about >+10% memory) and overall CPU usage (compared to > single-thread execution) due to needed synchronization and buffers. > > This means that if you now consume 20G of memory and 30 minutes of > single core time to converge the main table on a rather big node, you're > going to consume, let's say, >22G of memory and 3 minutes of 16-core CPU > (summing to 48 minutes of CPU time). This is a ball park guess, do not > take me much seriously. It may be better, it may be worse. > > Anyway, there is some code (currently not releasable) that will get to a > preview release soon. We'll highly appreciate testing from any user > around. Stay tunad! > > Maria > -- Douglas Fernando Fischer Eng? de Controle e Automa??o -------------- next part -------------- An HTML attachment was scrubbed... URL: From fischerdouglas at gmail.com Tue Mar 2 16:35:36 2021 From: fischerdouglas at gmail.com (Douglas Fischer) Date: Tue, 2 Mar 2021 12:35:36 -0300 Subject: multithread support In-Reply-To: References: <0a061dd6d25c6cb342d72c29d2b89dc5@gegnet.com.br> Message-ID: sed ?s/colors/cores? Em ter., 2 de mar. de 2021 ?s 12:34, Douglas Fischer < fischerdouglas at gmail.com> escreveu: > This is very good news! > > I know you said "This is a ball park guess", but I confess that I was a > little scared by the proportion of extra CPU usage (30/48 -> +60%). > I also know that you said that the code is still "currently not > releasable", but I'm curious to know a little more about how this > multi-threading was handled. > > > Just to illustrate: > > Single-Core CPU on BGP is known to be a problem for many engines and > vendors. > > One of the vendors developed a "creative" way to do this load distribution > in multiple colors. > As I understood it, they made a kind of Affinity CPU by BGP-Peer. > In a way that each peer has a BGP process, and that process is "semi-tied" > to a core. > And they created a mechanism to redistribute these affinities from > time-to-time based on the amount of BGP messages per second exchanged on > each peer. > > Em ter., 2 de mar. de 2021 ?s 10:13, Maria Matejka > escreveu: > >> Hi! >> >> On 3/1/21 1:26 PM, Marcelo Balbinot wrote: >> > >> > 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? >> >> Yes, it is. Be prepared that this will also raise memory usage (current >> estimates are about >+10% memory) and overall CPU usage (compared to >> single-thread execution) due to needed synchronization and buffers. >> >> This means that if you now consume 20G of memory and 30 minutes of >> single core time to converge the main table on a rather big node, you're >> going to consume, let's say, >22G of memory and 3 minutes of 16-core CPU >> (summing to 48 minutes of CPU time). This is a ball park guess, do not >> take me much seriously. It may be better, it may be worse. >> >> Anyway, there is some code (currently not releasable) that will get to a >> preview release soon. We'll highly appreciate testing from any user >> around. Stay tunad! >> >> Maria >> > > > -- > Douglas Fernando Fischer > Eng? de Controle e Automa??o > -- Douglas Fernando Fischer Eng? de Controle e Automa??o -------------- next part -------------- An HTML attachment was scrubbed... URL: From maria.matejka at nic.cz Tue Mar 2 18:54:54 2021 From: maria.matejka at nic.cz (Maria Matejka) Date: Tue, 2 Mar 2021 18:54:54 +0100 Subject: multithread support In-Reply-To: References: <0a061dd6d25c6cb342d72c29d2b89dc5@gegnet.com.br> Message-ID: Hello! On 3/2/21 4:34 PM, Douglas Fischer wrote: > This is very good news! > > I know you said "This is a ball park guess", but I confess that I was a > little scared by the proportion of extra CPU usage (30/48 -> +60%). This depends much on what kind of load we are speaking about. Generally, if you are a big route server, then 98% of CPU time is probably eaten by complex filters. I would estimate that this may finish anywhere between +10% and -10% due to other structural changes. The parallelization overhead would be minimal. However, if you are a big route reflector, then you're constantly just recomputing the best route, accessing the same table. Then we may get to the +60% estimate. Long story short, the more work you do with one route, the less overhead you get. Remember that BIRD is currently extremely well optimized for single-threaded execution and some parts still heavily depend on being executed that way. We chose first to allow parallel execution of those parts that can be parallelized well, with adding some overhead to other parts. The most critical part of this is route export (from tables to protocols) which is now done synchronously after route import. We decided to decouple it in the multithreaded code, which involves having a route export queue. Hence more memory stores and loads, more cache misses etc. Well ? maybe the +60% is too much, reconsidering that guess. Let's hope it's overestimated. I'd be more concerned about the memory usage. There are some estimations of peak memory usage in worst cases which can be even +100% (for a short time). In case we get to these problems in real world, we'd definitely have to implement algorithms to limit these peaks as swapping to disk is not desirable here at all. Anyway, this is not the problem of today; we still need first to get to a code which at least builds and runs without spitting one core file after another. > I also know that you said that the code is still "currently not > releasable", but I'm curious to know a little more about how this > multi-threading was handled. Basically, one thread per receiving socket, one thread per exporting channel, with some exceptions. One lock per protocol instance, one lock per table. You can lock only one table and one protocol instance at time; protocol goes first. We'll publish more documentation; it's still WIP. For now, I'm just answering a question to say "yes, we're going multithreaded and we're actively working on it". > Just to illustrate: > > Single-Core CPU on BGP is known to be a problem for many engines and > vendors. > > One of the vendors developed a "creative" way to do this load > distribution in multiple colors. > As I understood it, they made a kind of Affinity CPU by BGP-Peer. > In a way that each peer has a BGP process, and that process is > "semi-tied" to a core. > And they created a mechanism to redistribute these affinities from > time-to-time based on the amount of BGP messages per second exchanged on > each peer. If this arises to be a problem, we'll consider this. For now, it just seems that the most critical part is the route itself which is being propagated through BIRD -- which should stay in one thread as long as possible and the threads should keep its CPU (on a well-behaved system) unless moved for a good reason. Maria > > Em ter., 2 de mar. de 2021 ?s 10:13, Maria Matejka > escreveu: > > Hi! > > On 3/1/21 1:26 PM, Marcelo Balbinot wrote: > > > > 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? > > Yes, it is. Be prepared that this will also raise memory usage (current > estimates are about >+10% memory) and overall CPU usage (compared to > single-thread execution) due to needed synchronization and buffers. > > This means that if you now consume 20G of memory and 30 minutes of > single core time to converge the main table on a rather big node, > you're > going to consume, let's say, >22G of memory and 3 minutes of 16-core > CPU > (summing to 48 minutes of CPU time). This is a ball park guess, do not > take me much seriously. It may be better, it may be worse. > > Anyway, there is some code (currently not releasable) that will get > to a > preview release soon. We'll highly appreciate testing from any user > around. Stay tunad! > > Maria > > > > -- > Douglas Fernando Fischer > Eng? de Controle e Automa??o From toke at toke.dk Tue Mar 2 23:15:24 2021 From: toke at toke.dk (Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?=) Date: Tue, 02 Mar 2021 23:15:24 +0100 Subject: [PATCH v4 0/8] Add MAC authentication support to the Babel protocol In-Reply-To: <161072596935.33920.6744176530620496165.stgit@alrua-x1> References: <161072596935.33920.6744176530620496165.stgit@alrua-x1> Message-ID: <87v9a9td6r.fsf@toke.dk> Toke H?iland-J?rgensen writes: > This series adds MAC authentication support to the Babel protocol as specified > in in RFC8967: > > https://www.rfc-editor.org/rfc/rfc8967 > > I have performed basic interoperability testing between this implementation and > the current babeld HMAC implementation[1]. The two implementations were able to > successfully exchange authenticated messages with both HMAC-256 and Blake2s-256 > keys. > > Given the above, and the fact that the RFC was finally published at the the > IETF, I believe this series is ready for merging (subject to review, of course). > For those wanting to test the code, a version of Bird with this series applied > is available on Github[2] for easy consumption. > > [1] https://github.com/jech/babeld/pull/52 > [2] https://github.com/tohojo/bird/tree/babel-mac-04 > > Changelog: > > v4: > - Update RFC references to the published RFC numbers (for both MAC and Babel > itself). > - Rework WALK_TLVS macro to not cast initial argument, and not use goto for > framing errors. > - Change MAC validation logic to just let algorithms specify min/max len and > enforce full key size length even for the smaller-output variants of Blake2. > > v3: > - Add variants with smaller digest sizes for blake2s and blake2b. > - Rebase on current master > > v2: > - Don't reinvent AC_CHECK_FUNCS() for configure > - Make sure random_bytes() never fails (without taking the whole daemon with it) > - Use existing endianness defines in blake2s code > - Just leave MAC-related code in babel.c/packets.c instead of adding a new file > - Add blake2s test vectors (new patch 3) > - Support supplying mac keys as raw hexadecimal bytes and allow algorithms to > validate keys on configure (new patches 4-5) > > v1: > - Add wrapper function to bird sysdep code to pick a suitable source of random > bytes > - Import reference Blake2 implementations into lib/ > - Rename function names and data structures to use an auth_ prefix instead of hmac_ > - Perform a separate authentication pass before parsing the packet, and move the > authentication-related code to its own source file > - Enforce key length recommendation from the specification > - Add a 'permissive' configuration mode where outgoing packets are signed but > incoming packets are accepted even though they fail authentication > - Add user documentation for the authentication configuration, and function > docstrings to the main authentication functions > - Fix a bunch of nits and code style issues Ping? Anyone had a chance to take a look at this? :) -Toke From nico.schottelius at ungleich.ch Thu Mar 4 10:41:16 2021 From: nico.schottelius at ungleich.ch (Nico Schottelius) Date: Thu, 04 Mar 2021 10:41:16 +0100 Subject: Release schedule for 2.0.8 In-Reply-To: <20210302043846.GE3204@feanor.crfreenet.org> References: <87tupuydsp.fsf@ungleich.ch> <20210302043846.GE3204@feanor.crfreenet.org> Message-ID: <87y2f3gssj.fsf@ungleich.ch> Ondrej Zajicek writes: > Hi > > Sorry for the delay. Now we have everything we planned for the 2.0.8, > hopefully we can make the release this or next week. That would be amazing. If we can help by testing anything, just let me know. -- Sustainable and modern Infrastructures by ungleich.ch From tbiswas at fastly.com Thu Mar 4 19:32:16 2021 From: tbiswas at fastly.com (Trisha Biswas) Date: Thu, 4 Mar 2021 10:32:16 -0800 Subject: [PATCH] Add 'preferred' route attribute for selective add-path In-Reply-To: <29478472-E978-4301-B06F-3C8DD496A105@nic.cz> References: <20210226235321.GD3204@feanor.crfreenet.org> <29478472-E978-4301-B06F-3C8DD496A105@nic.cz> Message-ID: Hi Maria, I had a question on (1). By 'primary' did you mean something similar to the 'preferred' keyword described on this thread? If so, does this include surrounding logic to take of scenarios where routes might not get advertised because of RA_ANY behavior? Any idea of when these changes might get merged into master? Thanks! Trisha -- *Trisha Biswas* | Sr. Software Engineer, Network Systems fastly.com | @fastly | LinkedIn On Sat, Feb 27, 2021 at 2:05 AM Maria Mat?jka wrote: > Hello! > I have recently done some substantial changes in route exports (in > separate branches). I'd like to summarize what we are looking for. > > 1) have 'primary' in the filter and decide based on it > 2) export 'first N routes' with sorted table > > I suppose this may be possible in the new code which is currently placed > into the guernsey branch. I'll try to implement something of that while > refactoring exports. > > Maria > > On February 27, 2021 2:26:48 AM GMT+01:00, Trisha Biswas < > tbiswas at fastly.com> wrote: >> >> Hi Ondrej, >> >> Thanks for evaluating the patch. It makes sense to use rte->flags to >> store the preferred path and access that from the filter code to get >> around the first issue. >> >> For the second issue, it almost feels like there should be a separate >> mode of route announcement called RA_SELECTIVE. This would be exactly the >> same as RA_ANY, but in addition it would announce when routes change their >> REF_BEST. The RA_SELECTIVE mode could be enabled with a config option such >> as 'add paths tx selective;', so that we don't end up with lots of >> unnecessary announcements for BGP add-path. Previously, we had tried this >> by making RA_SELECTIVE a clone of RA_OPTIMAL, but that did not work well. >> Do you see issues with this approach up front? >> >> Thanks, >> Trisha >> -- >> >> *Trisha Biswas* | Sr. Software Engineer, Network Systems >> fastly.com | @fastly | LinkedIn >> >> >> >> On Fri, Feb 26, 2021 at 3:53 PM Ondrej Zajicek >> wrote: >> >>> On Fri, Feb 26, 2021 at 01:56:42PM -0800, Trisha Biswas wrote: >>> > 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. >>> >>> Hi >>> >>> I agree this may be a useful feature, but there are two issues with the >>> approach used in the patch: >>> >>> First, we would like not to access rte->net from the filters (outside of >>> net_addr). We plan to remove this ptr and instead have ptr from rte >>> directly to net_addr. >>> >>> Second, RA_ANY mode of route announcement (which is used by BGP add-path >>> and pipes) would not really work with this change in a way how you expect >>> - consider this scenario: route A is added, preferred and accepted for >>> export, then route B is added, not-preferred and not-accepted for export. >>> Then route A is withdrawn and B is selected as preferred. Protocols with >>> RA_OPTIMAL received update with route B as new-preferred (as they accept >>> only preferred one and that changed), but protocols with RA_ANY receive >>> just withdraw for route A (as they accept all routes and only route A was >>> changed, while route B is the same as was announced before), so they do >>> not get notification that route B became preferred and export filter for >>> B is not re-evaluated. >>> >>> The one approach that avoids the first issue is to add REF_BEST flag >>> (in rte->flags) that would be added to mark preferred routes, and this >>> flag can be accessed from the filter code. But that does not fix the >>> second issue. We can add RA_ANY announcement for routes that changed >>> their REF_BEST, but that would add plenty of unnecessary announcements >>> (that are propagated as BGP updates) for BGP add-path that do not >>> use or care about this flag. >>> >>> In general, BGP add-path in BIRD was developed with assumption that >>> routes within one network are handled independently and would need some >>> deeper redesign for other cases. That might be useful (in order to be >>> able to implement things like 'announce best 4 routes for given >>> network'), but i do not see an easy solution to this. >>> >>> -- >>> Elen sila lumenn' omentielvo >>> >>> Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) >>> OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) >>> "To err is human -- to blame it on a computer is even more so." >>> >> >>> On Fri, Feb 26, 2021 at 1:56 PM Trisha Biswas >>> wrote: >>> >>>> 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 | LinkedIn >>>> >>>> >>> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maria.matejka at nic.cz Thu Mar 4 20:38:37 2021 From: maria.matejka at nic.cz (=?UTF-8?Q?Maria_Mat=C4=9Bjka?=) Date: Thu, 04 Mar 2021 20:38:37 +0100 Subject: [PATCH] Add 'preferred' route attribute for selective add-path In-Reply-To: References: <20210226235321.GD3204@feanor.crfreenet.org> <29478472-E978-4301-B06F-3C8DD496A105@nic.cz> Message-ID: Yes, I currently think about something like preexport limit ; export ; postexport limit ; Current secondary policy would be preexport limit any, postexport limit 1. Current RA_OPTIMAL would be preexport limit 1. In the filter, you would have a new readonly attribute 'order'. In case of unsorted table, it would be 0 for best, 1 for others, in case of sorted table it would be the higher order the worse route. If the filter uses the order, it is re-evaluated in each case when the order changes. Don't take me much seriously for now, I'm definitely not promising this. Anyway for now, this seems to be doable. Merge to master? I don't know. If implemented, it is going to be in the first multithreaded version. I have no estimate when we say that the multithreaded version is stable enough to be a master. Maria On March 4, 2021 7:32:16 PM GMT+01:00, Trisha Biswas wrote: >Hi Maria, > >I had a question on (1). By 'primary' did you mean something similar to >the >'preferred' keyword described on this thread? If so, does this include >surrounding logic to take of scenarios where routes might not get >advertised because of RA_ANY behavior? > >Any idea of when these changes might get merged into master? > >Thanks! >Trisha >-- > >*Trisha Biswas* | Sr. Software Engineer, Network Systems >fastly.com | @fastly | LinkedIn > > > >On Sat, Feb 27, 2021 at 2:05 AM Maria Mat?jka >wrote: > >> Hello! >> I have recently done some substantial changes in route exports (in >> separate branches). I'd like to summarize what we are looking for. >> >> 1) have 'primary' in the filter and decide based on it >> 2) export 'first N routes' with sorted table >> >> I suppose this may be possible in the new code which is currently >placed >> into the guernsey branch. I'll try to implement something of that >while >> refactoring exports. >> >> Maria >> >> On February 27, 2021 2:26:48 AM GMT+01:00, Trisha Biswas < >> tbiswas at fastly.com> wrote: >>> >>> Hi Ondrej, >>> >>> Thanks for evaluating the patch. It makes sense to use rte->flags to >>> store the preferred path and access that from the filter code to get >>> around the first issue. >>> >>> For the second issue, it almost feels like there should be a >separate >>> mode of route announcement called RA_SELECTIVE. This would be >exactly the >>> same as RA_ANY, but in addition it would announce when routes change >their >>> REF_BEST. The RA_SELECTIVE mode could be enabled with a config >option such >>> as 'add paths tx selective;', so that we don't end up with lots of >>> unnecessary announcements for BGP add-path. Previously, we had tried >this >>> by making RA_SELECTIVE a clone of RA_OPTIMAL, but that did not work >well. >>> Do you see issues with this approach up front? >>> >>> Thanks, >>> Trisha >>> -- >>> >>> *Trisha Biswas* | Sr. Software Engineer, Network Systems >>> fastly.com | @fastly | LinkedIn >>> >>> >>> >>> On Fri, Feb 26, 2021 at 3:53 PM Ondrej Zajicek > >>> wrote: >>> >>>> On Fri, Feb 26, 2021 at 01:56:42PM -0800, Trisha Biswas wrote: >>>> > 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. >>>> >>>> Hi >>>> >>>> I agree this may be a useful feature, but there are two issues with >the >>>> approach used in the patch: >>>> >>>> First, we would like not to access rte->net from the filters >(outside of >>>> net_addr). We plan to remove this ptr and instead have ptr from rte >>>> directly to net_addr. >>>> >>>> Second, RA_ANY mode of route announcement (which is used by BGP >add-path >>>> and pipes) would not really work with this change in a way how you >expect >>>> - consider this scenario: route A is added, preferred and accepted >for >>>> export, then route B is added, not-preferred and not-accepted for >export. >>>> Then route A is withdrawn and B is selected as preferred. Protocols >with >>>> RA_OPTIMAL received update with route B as new-preferred (as they >accept >>>> only preferred one and that changed), but protocols with RA_ANY >receive >>>> just withdraw for route A (as they accept all routes and only route >A was >>>> changed, while route B is the same as was announced before), so >they do >>>> not get notification that route B became preferred and export >filter for >>>> B is not re-evaluated. >>>> >>>> The one approach that avoids the first issue is to add REF_BEST >flag >>>> (in rte->flags) that would be added to mark preferred routes, and >this >>>> flag can be accessed from the filter code. But that does not fix >the >>>> second issue. We can add RA_ANY announcement for routes that >changed >>>> their REF_BEST, but that would add plenty of unnecessary >announcements >>>> (that are propagated as BGP updates) for BGP add-path that do not >>>> use or care about this flag. >>>> >>>> In general, BGP add-path in BIRD was developed with assumption that >>>> routes within one network are handled independently and would need >some >>>> deeper redesign for other cases. That might be useful (in order to >be >>>> able to implement things like 'announce best 4 routes for given >>>> network'), but i do not see an easy solution to this. >>>> >>>> -- >>>> Elen sila lumenn' omentielvo >>>> >>>> Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) >>>> OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, >wwwkeys.pgp.net) >>>> "To err is human -- to blame it on a computer is even more so." >>>> >>> >>>> On Fri, Feb 26, 2021 at 1:56 PM Trisha Biswas >>>> wrote: >>>> >>>>> 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 | LinkedIn >>>>> >>>>> >>>> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From damian at damianzaremba.co.uk Fri Mar 5 14:41:40 2021 From: damian at damianzaremba.co.uk (Damian Zaremba) Date: Fri, 5 Mar 2021 14:41:40 +0100 Subject: BGP keepalive packets delayed during reconfigure Message-ID: <6ce2844c-ad69-2160-843c-97f901a93266@damianzaremba.co.uk> 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 bgp1: Sending KEEPALIVE 2021-03-05 10:28:34.886 bgp1: Sending KEEPALIVE 2021-03-05 10:28:53.772 bgp1: Sending KEEPALIVE 2021-03-05 10:28:56.259 Reconfiguring 2021-03-05 10:45:13.606 bgp1: Sending KEEPALIVE 2021-03-05 10:45:13.611 I/O loop cycle took 966448 ms for 1016 events 2021-03-05 10:45:13.612 Reconfigured 2021-03-05 10:45:13.612 bgp1: Got KEEPALIVE 2021-03-05 10:45:13.612 bgp1: Got KEEPALIVE 2021-03-05 10:45:13.612 bgp1: Got KEEPALIVE 2021-03-05 10:45:13.612 bgp1: Received: Hold timer expired 2021-03-05 10:46:06.106 bgp1: Sending KEEPALIVE 2021-03-05 10:46:24.541 bgp1: Sending KEEPALIVE 2021-03-05 10:46:42.282 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 bgp1: Error: Hold timer expired 2021-03-05 10:34:05 bgp1: Error: Hold timer expired 2021-03-05 10:39:38 bgp1: Error: Hold timer expired 2021-03-05 10:43:48 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 From damian at damianzaremba.co.uk Fri Mar 5 14:43:05 2021 From: damian at damianzaremba.co.uk (Damian Zaremba) Date: Fri, 5 Mar 2021 14:43:05 +0100 Subject: Static protocol reconfiguration results in sub-optimal route updates Message-ID: <0261ad1e-2bd1-59fa-f4ff-bc9de50898c2@damianzaremba.co.uk> 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 Reconfiguring 2021-03-05 11:57:36.168 Reloading channel pipe1.sec 2021-03-05 11:57:36.168 bgp1: Reconfigured 2021-03-05 11:57:36.168 Reconfigured 2021-03-05 11:57:36.168 bgp1.ipv4 < replaced 203.0.113.0/24 unreachable 2021-03-05 11:57:36.168 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 Reconfiguring 2021-03-05 12:10:39.042 Cannot reconfigure channel static1.ipv4 2021-03-05 12:10:39.042 Restarting protocol static1 2021-03-05 12:10:39.042 bgp1: Reconfigured 2021-03-05 12:10:39.042 bgp1.ipv4 < removed 203.0.113.0/24 unreachable 2021-03-05 12:10:39.042 bgp1: Sending UPDATE 2021-03-05 12:10:39.042 bgp1.ipv4 < added 203.0.113.0/24 unreachable 2021-03-05 12:10:39.042 Reconfigured 2021-03-05 12:10:39.042 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 Reconfiguring 2021-03-05 12:34:40 Reloading protocol static1 2021-03-05 12:34:40 Restarting protocol static1 2021-03-05 12:34:40 bgp1: Reconfigured 2021-03-05 12:34:40 Reconfigured 2021-03-05 12:34:40 bgp1 < removed 203.0.113.0/24 unreachable 2021-03-05 12:34:40 bgp1 < added 203.0.113.0/24 unreachable 2021-03-05 12:34:40 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 From maria.matejka at nic.cz Fri Mar 5 14:59:43 2021 From: maria.matejka at nic.cz (Maria Matejka) Date: Fri, 5 Mar 2021 14:59:43 +0100 Subject: BGP keepalive packets delayed during reconfigure In-Reply-To: <6ce2844c-ad69-2160-843c-97f901a93266@damianzaremba.co.uk> References: <6ce2844c-ad69-2160-843c-97f901a93266@damianzaremba.co.uk> Message-ID: <3c7ef218-f7cd-8ebd-b0fe-107f527ab7a8@nic.cz> Hello! This is simply a result of a large configuration file. BIRD took more than 16 minutes to parse and apply new config. As BIRD is single-threaded, nothing is done while parsing the new config. This is going to be fixed by using more CPU threads. Some preview of a version doing exactly this with configuration may be found in GIT in commit c78f88c91c7b75f530d70d503fa011c20f16f278. Use with caution, we have not finished all tests yet. Maria On 3/5/21 2:41 PM, Damian Zaremba wrote: > 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 bgp1: Sending KEEPALIVE > 2021-03-05 10:28:34.886 bgp1: Sending KEEPALIVE > 2021-03-05 10:28:53.772 bgp1: Sending KEEPALIVE > 2021-03-05 10:28:56.259 Reconfiguring > 2021-03-05 10:45:13.606 bgp1: Sending KEEPALIVE > 2021-03-05 10:45:13.611 I/O loop cycle took 966448 ms for 1016 > events > 2021-03-05 10:45:13.612 Reconfigured > 2021-03-05 10:45:13.612 bgp1: Got KEEPALIVE > 2021-03-05 10:45:13.612 bgp1: Got KEEPALIVE > 2021-03-05 10:45:13.612 bgp1: Got KEEPALIVE > 2021-03-05 10:45:13.612 bgp1: Received: Hold timer expired > 2021-03-05 10:46:06.106 bgp1: Sending KEEPALIVE > 2021-03-05 10:46:24.541 bgp1: Sending KEEPALIVE > 2021-03-05 10:46:42.282 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 bgp1: Error: Hold timer expired > 2021-03-05 10:34:05 bgp1: Error: Hold timer expired > 2021-03-05 10:39:38 bgp1: Error: Hold timer expired > 2021-03-05 10:43:48 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 > From maria.matejka at nic.cz Fri Mar 5 15:11:57 2021 From: maria.matejka at nic.cz (Maria Matejka) Date: Fri, 5 Mar 2021 15:11:57 +0100 Subject: Static protocol reconfiguration results in sub-optimal route updates In-Reply-To: <0261ad1e-2bd1-59fa-f4ff-bc9de50898c2@damianzaremba.co.uk> References: <0261ad1e-2bd1-59fa-f4ff-bc9de50898c2@damianzaremba.co.uk> Message-ID: <54cca16e-4f84-dfc5-56eb-ecb4f4804b5a@nic.cz> Hello! Well, this seems to be a forgotten part of the static protocol. I see the bug, there is a missing reload hook in the appropriate channel. Queuing this to be fixed soon. Thank you for the report! Maria On 3/5/21 2:43 PM, Damian Zaremba wrote: > 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 Reconfiguring > 2021-03-05 11:57:36.168 Reloading channel pipe1.sec > 2021-03-05 11:57:36.168 bgp1: Reconfigured > 2021-03-05 11:57:36.168 Reconfigured > 2021-03-05 11:57:36.168 bgp1.ipv4 < replaced 203.0.113.0/24 > unreachable > 2021-03-05 11:57:36.168 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 Reconfiguring > 2021-03-05 12:10:39.042 Cannot reconfigure channel static1.ipv4 > 2021-03-05 12:10:39.042 Restarting protocol static1 > 2021-03-05 12:10:39.042 bgp1: Reconfigured > 2021-03-05 12:10:39.042 bgp1.ipv4 < removed 203.0.113.0/24 > unreachable > 2021-03-05 12:10:39.042 bgp1: Sending UPDATE > 2021-03-05 12:10:39.042 bgp1.ipv4 < added 203.0.113.0/24 > unreachable > 2021-03-05 12:10:39.042 Reconfigured > 2021-03-05 12:10:39.042 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 Reconfiguring > 2021-03-05 12:34:40 Reloading protocol static1 > 2021-03-05 12:34:40 Restarting protocol static1 > 2021-03-05 12:34:40 bgp1: Reconfigured > 2021-03-05 12:34:40 Reconfigured > 2021-03-05 12:34:40 bgp1 < removed 203.0.113.0/24 unreachable > 2021-03-05 12:34:40 bgp1 < added 203.0.113.0/24 unreachable > 2021-03-05 12:34:40 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 > From bird at bastelfreak.de Fri Mar 5 18:05:45 2021 From: bird at bastelfreak.de (Tim Meusel) Date: Fri, 5 Mar 2021 18:05:45 +0100 Subject: shutdown BGP sessions without administrative shutdown? In-Reply-To: References: Message-ID: <3ac9722e-b454-0328-4e31-7b7b91c6ed8a@bastelfreak.de> Hi, On 23.02.21 00:12, Alexander Zubkov wrote: > Hi, > > As far as I know, when you shut down bird manually, you have to use > "graceful restart" command to stop it instead of "down" command: > https://bird.network.cz/?get_doc&v=20&f=bird-4.html#cli-graceful-restart > And also use "-R" option for the daemon when starting. > Thanks! That works perfectly fine for bird 2. Is that also possible with bird 1.6? It lists support for LLGR in the configuration documentation: https://bird.network.cz/?get_doc&v=16&f=bird-6.html#ss6.3 But the remote control documentation does not list `graceful restart` and it indeed doesn't work: # birdc graceful shutdown BIRD 1.6.8 ready. No such command. Press `?' for help. Cheers, Tim > > On Mon, Feb 22, 2021 at 10:25 PM Tim Meusel wrote: >> >> >> >> Hi! >> I'm running many boxes with Bird 2.x. They all peer with virtual JunOS >> routers via BGP. Each Bird instance announces routes for IP addresses >> from local virtual machines. In case bird dies or gets stopped for >> upgrades, I want that the JunOS route reflectors keep the routes for a >> certain amount of time. My config currently looks like this: >> >> template bgp VMX { >> local $ip as $as; >> multihop; # we don't have a layer 2 connection to the routers >> bfd graceful; >> hold time 240; >> startup hold time 240; >> connect retry time 120; >> graceful restart yes; >> graceful restart time 0; >> long lived graceful restart yes; >> long lived stale time 90; >> ipv4 { >> export filter virtual_machines_v4; >> import none; >> next hop self; >> }; >> ipv6 { >> export filter virtual_machines_v6; >> import none; >> next hop self; >> }; >> } >> >> protocol bgp $peer from VMX { >> description $desc; >> neighbor $ip> as $as; >> } >> >> this works fine if I do: >> * birdc reconfigure >> * kill -HUP on the bird pid >> * killall -9 bird >> >> however if I do a `systemctl stop bird`, it does an administrative >> shutdown and the virtual MX drops the routes. As far as I understand the >> RFC for LLGR this is the correct behavior. Can one of you tell me if >> there is an option on JunOS to keep the routes, even after a ` >> administrative shutdown`, or if I can advice Bird to not cleanly >> shutdown sessions? >> >> Cheers, Tim >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature URL: From bird at m-squa.red Fri Mar 5 18:25:05 2021 From: bird at m-squa.red (Molly Miller) Date: Fri, 5 Mar 2021 17:25:05 +0000 Subject: [PATCH v2] Client: add "show hostname" command, and add client prompt hostname display In-Reply-To: <696c7d0e-21d6-7d4e-1dee-e0d6d9b0ed56@m-squa.red> References: <696c7d0e-21d6-7d4e-1dee-e0d6d9b0ed56@m-squa.red> Message-ID: <6c8d4345-3558-4127-2282-475db0fb36ee@m-squa.red> Hi, This is a small update to the patch I posted previously, as I ran into a compilation error when building in a different environment due to passing a non-const string as the first argument to printf(3) in birdcl. Please see the updated patch below. Thanks, --mm. On 11/02/2021 21:14, Molly Miller wrote: > Hi all, > > The recent patch on the list from Vincent Bernat which added support for the > draft BGP hostname capability [1] reminded me of a thread from last year, in > which there was a feature request for the ability to display the system > hostname in the Bird client prompt [2]. > > This feature doesn't appear to have been implemented since then, and now > that a hostname is tracked internally by Bird, I've written a > proof-of-concept patch (appended inline) which displays the daemon hostname > in the client prompt. > > This patch adds a "show hostname" command to the daemon for convenience, and > modifies the client to automatically issue this command when starting in > interactive mode. The client then intercepts the response (which will either > contain the daemon hostname, or be a syntax error if the daemon does not > understand the command), and then sets the received hostname in the prompt > if the response is a success code. > > (The rationale for not simply calling uname(2) in the client is that the > resulting nodename may not match the hostname configured in the daemon, in > the case where the daemon configuration contains a hostname "" > directive. It's also possible to connect to the daemon over a Unix socket > forwarded over SSH, in which case the client would be running on a separate > system with a different hostname regardless of the daemon configuration -- > thanks to Tim Stallard for pointing this out.) > > I don't know how willing the Bird maintainers would be to commit this patch, > however I thought I'd post it to the list in case anyone else is interested. > > Cheers, > --mm. > > > [1]: https://bird.network.cz/pipermail/bird-users/2021-February/015187.html, > merged as 71423871 > [2]: https://bird.network.cz/pipermail/bird-users/2020-July/014678.html > -- >8 -- Subject: [PATCH v2] Client: add "show hostname" command, and client prompt hostname display. This patch adds a "show hostname" command to the daemon, which returns the server's currently configured hostname, and extends the command line client to issue this command upon connecting to the daemon, in order to retrieve a hostname to display in the client's prompt. A '-p' option has also been added to suppress this behaviour. molly on flywheel ~> birdc BIRD v2.0.7 ready. bird(flywheel)> show hostname Hostname: flywheel bird(flywheel)> exit molly on flywheel ~> birdc -p BIRD v2.0.7 ready. bird> show hostname Hostname: flywheel bird> quit Additionally, the error message generated by older versions of the daemon when running the "show hostname" command is caught, in order to remain interoperable with versions which do not have this patch. The client program does not, however, have any means of detecting whether the hostname changes as part of an online configuration update, so changes in the daemon's hostname will not be propagated to a client which is persistent across the configuration change. --- client/birdc.c | 11 +++++++++-- client/birdcl.c | 8 +++++++- client/client.c | 48 ++++++++++++++++++++++++++++++++++++++++++------ client/client.h | 2 ++ doc/reply_codes | 1 + nest/cmds.c | 7 +++++++ nest/cmds.h | 1 + nest/config.Y | 3 +++ 8 files changed, 72 insertions(+), 9 deletions(-) diff --git a/client/birdc.c b/client/birdc.c index f1aea2fe..b1b9b218 100644 --- a/client/birdc.c +++ b/client/birdc.c @@ -162,7 +162,7 @@ input_init(void) rl_readline_name = "birdc"; rl_add_defun("bird-complete", input_complete, '\t'); rl_add_defun("bird-help", input_help, '?'); - rl_callback_handler_install("bird> ", input_got_line); + rl_callback_handler_install(prompt_string, input_got_line); // rl_get_screen_size(); term_lns = LINES; @@ -184,7 +184,7 @@ input_reveal(void) tcdrain(STDOUT_FILENO); rl_end = input_hidden_end; - rl_expand_prompt("bird> "); + rl_expand_prompt(prompt_string); rl_forced_update_display(); prompt_active = 1; @@ -201,6 +201,13 @@ input_hide(void) prompt_active = 0; } +void +input_reload(void) +{ + input_hide(); + input_reveal(); +} + void input_notify(int prompt) { diff --git a/client/birdcl.c b/client/birdcl.c index 4508185c..d8517acd 100644 --- a/client/birdcl.c +++ b/client/birdcl.c @@ -38,6 +38,12 @@ input_stop_list(void) /* Empty in non-ncurses version. */ } +void +input_reload(void) +{ + /* Empty in non-ncurses version. */ +} + void input_notify(int prompt) { @@ -45,7 +51,7 @@ input_notify(int prompt) if (!prompt) return; - printf("bird> "); + fputs(prompt_string, stdout); fflush(stdout); } diff --git a/client/client.c b/client/client.c index 97cf6639..2f225442 100644 --- a/client/client.c +++ b/client/client.c @@ -37,8 +37,11 @@ #include "sysdep/unix/unix.h" #define SERVER_READ_BUF_LEN 4096 +#define SERVER_PROMPT_LEN 64 +#define SERVER_PROMPT_DEFAULT "bird> " +#define SERVER_HOSTNAME_PREFIX "Hostname: " -static char *opt_list = "s:vrl"; +static char *opt_list = "s:vrlp"; static int verbose, restricted, once; static char *init_cmd; @@ -47,12 +50,15 @@ static int server_fd; static byte server_read_buf[SERVER_READ_BUF_LEN]; static byte *server_read_pos = server_read_buf; -int init = 1; /* During intial sequence */ -int busy = 1; /* Executing BIRD command */ -int interactive; /* Whether stdin is terminal */ +int init = 1; /* During intial sequence */ +int busy = 1; /* Executing BIRD command */ +int hostprompt = 1; /* Whether to show hostname in prompt */ +int interactive; /* Whether stdin is terminal */ +char prompt_string[SERVER_PROMPT_LEN]; /* Prompt string */ static int num_lines, skip_input; int term_lns, term_cls; +static int hostname_read = 0; /*** Parsing of arguments ***/ @@ -60,7 +66,7 @@ int term_lns, term_cls; static void usage(char *name) { - fprintf(stderr, "Usage: %s [-s ] [-v] [-r] [-l]\n", name); + fprintf(stderr, "Usage: %s [-s ] [-v] [-r] [-l] [-p]\n", name); exit(1); } @@ -87,6 +93,9 @@ parse_args(int argc, char **argv) if (!server_changed) server_path = xbasename(server_path); break; + case 'p': + hostprompt = 0; + break; default: usage(argv[0]); } @@ -199,6 +208,12 @@ init_commands(void) exit(0); } + /* Set up local prompt, and attempt to retrieve daemon hostname */ + memset(prompt_string, 0, sizeof(prompt_string)); + strcpy(prompt_string, SERVER_PROMPT_DEFAULT); + if (hostprompt) + submit_server_command("show hostname"); + input_init(); term_lns = (term_lns > 0) ? term_lns : 25; @@ -239,6 +254,16 @@ more(void) more_end(); } +static void +update_prompt(char *x) +{ + if (strncmp(x, SERVER_HOSTNAME_PREFIX, sizeof(SERVER_HOSTNAME_PREFIX)-1) != 0) + return; + + memset(prompt_string, 0, sizeof(prompt_string)); + snprintf(prompt_string, sizeof(prompt_string), "bird(%s)> ", x+sizeof(SERVER_HOSTNAME_PREFIX)-1); +} + /*** Communication with server ***/ @@ -281,7 +306,18 @@ server_got_reply(char *x) (x[4] == ' ' || x[4] == '-')) { if (code) - PRINTF(len, "%s\n", verbose ? x : x+5); + { + if ((code == 1026 || code == 9001) && !hostname_read && hostprompt) + { + hostname_read = 1; + if (code == 1026) { + update_prompt(x+5); + input_reload(); + } + } + else + PRINTF(len, "%s\n", verbose ? x : x+5); + } if (x[4] == ' ') { diff --git a/client/client.h b/client/client.h index f9693def..8de7b38c 100644 --- a/client/client.h +++ b/client/client.h @@ -9,6 +9,7 @@ extern int init, busy, interactive; extern int term_lns, term_cls; +extern char prompt_string[]; /* birdc.c / birdcl.c */ @@ -16,6 +17,7 @@ void input_start_list(void); void input_stop_list(void); void input_init(void); +void input_reload(void); void input_notify(int prompt); void input_read(void); diff --git a/doc/reply_codes b/doc/reply_codes index 02f4e656..47f9d3e8 100644 --- a/doc/reply_codes +++ b/doc/reply_codes @@ -61,6 +61,7 @@ Reply codes of BIRD command-line interface 1023 Show Babel interfaces 1024 Show Babel neighbors 1025 Show Babel entries +1026 Show hostname 8000 Reply too long 8001 Route not found diff --git a/nest/cmds.c b/nest/cmds.c index 18f39eb5..a412faf3 100644 --- a/nest/cmds.c +++ b/nest/cmds.c @@ -95,6 +95,13 @@ cmd_show_memory(void) cli_msg(0, ""); } +void +cmd_show_hostname(void) +{ + cli_msg(-1026, "Hostname: %s", config->hostname); + cli_msg(0, ""); +} + void cmd_eval(const struct f_line *expr) { diff --git a/nest/cmds.h b/nest/cmds.h index 194a9d7f..14c7293d 100644 --- a/nest/cmds.h +++ b/nest/cmds.h @@ -16,6 +16,7 @@ struct f_inst; void cmd_show_status(void); void cmd_show_symbols(struct sym_show_data *sym); void cmd_show_memory(void); +void cmd_show_hostname(void); struct f_line; void cmd_eval(const struct f_line *expr); diff --git a/nest/config.Y b/nest/config.Y index 39bf6149..72ea0726 100644 --- a/nest/config.Y +++ b/nest/config.Y @@ -564,6 +564,9 @@ CF_CLI(SHOW STATUS,,, [[Show router status]]) CF_CLI(SHOW MEMORY,,, [[Show memory usage]]) { cmd_show_memory(); } ; +CF_CLI(SHOW HOSTNAME,,, [[Show current hostname]]) +{ cmd_show_hostname(); } ; + CF_CLI(SHOW PROTOCOLS, proto_patt2, [ | \"\"], [[Show routing protocols]]) { proto_apply_cmd($3, proto_cmd_show, 0, 0); } ; -- 2.20.1 From Joakim.Tjernlund at infinera.com Thu Mar 11 13:35:40 2021 From: Joakim.Tjernlund at infinera.com (Joakim Tjernlund) Date: Thu, 11 Mar 2021 12:35:40 +0000 Subject: OSPFv3 auth problem Message-ID: <90f2251e747b31625a2f5844e260fd5b7c3c70d1.camel@infinera.com> We have a ring of routers(5 of them) running unnumbered pppoe links between them. Adding OSPF authentication (auth trailer) works OK. However, removing OSPFv3 on ONE interface causes big problem in some cases, we loose auth in the whole ring and routing is then kaputt for all routers. We have noted that some PDUs(like LS update) are sent without auth trailer so the receiving nodes complains with "ospfv3_2: Authentication failed for nbr 0.0.139.1 on p1-1-3-1-4 - missing authentication trailer (0)" OSPFv3 Hello is OK though, it still has its auth trailer. Any ideas? Jocke From santiago at crfreenet.org Thu Mar 11 14:26:03 2021 From: santiago at crfreenet.org (Ondrej Zajicek) Date: Thu, 11 Mar 2021 14:26:03 +0100 Subject: OSPFv3 auth problem In-Reply-To: <90f2251e747b31625a2f5844e260fd5b7c3c70d1.camel@infinera.com> References: <90f2251e747b31625a2f5844e260fd5b7c3c70d1.camel@infinera.com> Message-ID: <20210311132602.GA3327@feanor.crfreenet.org> On Thu, Mar 11, 2021 at 12:35:40PM +0000, Joakim Tjernlund wrote: > We have a ring of routers(5 of them) running unnumbered pppoe links between them. Adding OSPF authentication (auth trailer) works OK. > However, removing OSPFv3 on ONE interface causes big problem in some cases, we loose auth in the whole ring > and routing is then kaputt for all routers. > > We have noted that some PDUs(like LS update) are sent without auth trailer so the receiving nodes > complains with "ospfv3_2: Authentication failed for nbr 0.0.139.1 on p1-1-3-1-4 - missing authentication trailer (0)" > > OSPFv3 Hello is OK though, it still has its auth trailer. > > Any ideas? Hello Which version, 2.0.7 or master? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From Joakim.Tjernlund at infinera.com Thu Mar 11 14:45:25 2021 From: Joakim.Tjernlund at infinera.com (Joakim Tjernlund) Date: Thu, 11 Mar 2021 13:45:25 +0000 Subject: OSPFv3 auth problem In-Reply-To: <20210311132602.GA3327@feanor.crfreenet.org> References: <90f2251e747b31625a2f5844e260fd5b7c3c70d1.camel@infinera.com> <20210311132602.GA3327@feanor.crfreenet.org> Message-ID: On Thu, 2021-03-11 at 14:26 +0100, Ondrej Zajicek wrote: > On Thu, Mar 11, 2021 at 12:35:40PM +0000, Joakim Tjernlund wrote: > > We have a ring of routers(5 of them) running unnumbered pppoe links between them. Adding OSPF authentication (auth trailer) works OK. > > However, removing OSPFv3 on ONE interface causes big problem in some cases, we loose auth in the whole ring > > and routing is then kaputt for all routers. > > > > We have noted that some PDUs(like LS update) are sent without auth trailer so the receiving nodes > > complains with "ospfv3_2: Authentication failed for nbr 0.0.139.1 on p1-1-3-1-4 - missing authentication trailer (0)" > > > > OSPFv3 Hello is OK though, it still has its auth trailer. > > > > Any ideas? > > Hello > > Which version, 2.0.7 or master? > almost master, we have 2.0.7 + most ospf patches from master From santiago at crfreenet.org Thu Mar 11 15:50:53 2021 From: santiago at crfreenet.org (Ondrej Zajicek) Date: Thu, 11 Mar 2021 15:50:53 +0100 Subject: OSPFv3 auth problem In-Reply-To: <90f2251e747b31625a2f5844e260fd5b7c3c70d1.camel@infinera.com> References: <90f2251e747b31625a2f5844e260fd5b7c3c70d1.camel@infinera.com> Message-ID: <20210311145053.GB3327@feanor.crfreenet.org> On Thu, Mar 11, 2021 at 12:35:40PM +0000, Joakim Tjernlund wrote: > We have a ring of routers(5 of them) running unnumbered pppoe links between them. Adding OSPF authentication (auth trailer) works OK. > However, removing OSPFv3 on ONE interface causes big problem in some cases, we loose auth in the whole ring > and routing is then kaputt for all routers. > > We have noted that some PDUs(like LS update) are sent without auth trailer so the receiving nodes > complains with "ospfv3_2: Authentication failed for nbr 0.0.139.1 on p1-1-3-1-4 - missing authentication trailer (0)" > > OSPFv3 Hello is OK though, it still has its auth trailer. Hmm, that is strange. There is difference between Hello and LSUpd in OSPFv3 Auth receiver code, but not in sending code. That is essentially: if (ifa->autype != OSPF_AUTH_CRYPT) return; ... attach auth trailer ... > Any ideas? LSUpd packets do not contain explicit flag whether they use OSPFv3 auth trailer. Such information is stored in neighbor structure based on received DBDes packet. So 'missing authentication trailer' for LSUpd really means that such neighbor structure says 'no auth'. But that should not happen as that DBDes packet would be rejected. One idea is that DBDes packets intended for one iface (non-authenticated) were sent to a different iface (authenticated) and they poisoned neighbor structure with 'no auth' info. You say 'loose auth in the whole ring', i can imagine that it will break adjacent links, but it will really break even non-adjacent links? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From Joakim.Tjernlund at infinera.com Thu Mar 11 16:06:53 2021 From: Joakim.Tjernlund at infinera.com (Joakim Tjernlund) Date: Thu, 11 Mar 2021 15:06:53 +0000 Subject: OSPFv3 auth problem In-Reply-To: <20210311145053.GB3327@feanor.crfreenet.org> References: <90f2251e747b31625a2f5844e260fd5b7c3c70d1.camel@infinera.com> <20210311145053.GB3327@feanor.crfreenet.org> Message-ID: <1dbecb519e384b2041bf60c5b72eff57cbd172f7.camel@infinera.com> On Thu, 2021-03-11 at 15:50 +0100, Ondrej Zajicek wrote: > On Thu, Mar 11, 2021 at 12:35:40PM +0000, Joakim Tjernlund wrote: > > We have a ring of routers(5 of them) running unnumbered pppoe links between them. Adding OSPF authentication (auth trailer) works OK. > > However, removing OSPFv3 on ONE interface causes big problem in some cases, we loose auth in the whole ring > > and routing is then kaputt for all routers. > > > > We have noted that some PDUs(like LS update) are sent without auth trailer so the receiving nodes > > complains with "ospfv3_2: Authentication failed for nbr 0.0.139.1 on p1-1-3-1-4 - missing authentication trailer (0)" > > > > OSPFv3 Hello is OK though, it still has its auth trailer. > > Hmm, that is strange. There is difference between Hello and LSUpd in > OSPFv3 Auth receiver code, but not in sending code. That is essentially: > > ??if (ifa->autype != OSPF_AUTH_CRYPT) > ????return; > > ??... attach auth trailer ... > > > > Any ideas? > > LSUpd packets do not contain explicit flag whether they use OSPFv3 auth > trailer. Such information is stored in neighbor structure based on > received DBDes packet. So 'missing authentication trailer' for LSUpd > really means that such neighbor structure says 'no auth'. But that > should not happen as that DBDes packet would be rejected. > > One idea is that DBDes packets intended for one iface (non-authenticated) > were sent to a different iface (authenticated) and they poisoned neighbor > structure with 'no auth' info. > > You say 'loose auth in the whole ring', i can imagine that it will break > adjacent links, but it will really break even non-adjacent links? > Yes, it takes some time(about 30 min) though before the whole ring is gone. All nodes are seeing "missing authentication trailer" msg. From Joakim.Tjernlund at infinera.com Thu Mar 11 16:50:18 2021 From: Joakim.Tjernlund at infinera.com (Joakim Tjernlund) Date: Thu, 11 Mar 2021 15:50:18 +0000 Subject: OSPFv3 auth problem In-Reply-To: <1dbecb519e384b2041bf60c5b72eff57cbd172f7.camel@infinera.com> References: <90f2251e747b31625a2f5844e260fd5b7c3c70d1.camel@infinera.com> <20210311145053.GB3327@feanor.crfreenet.org> <1dbecb519e384b2041bf60c5b72eff57cbd172f7.camel@infinera.com> Message-ID: <77721ed5eef24d8e7f437d4dbc622a7d9fdaa957.camel@infinera.com> On Thu, 2021-03-11 at 15:06 +0000, Joakim Tjernlund wrote: > On Thu, 2021-03-11 at 15:50 +0100, Ondrej Zajicek wrote: > > On Thu, Mar 11, 2021 at 12:35:40PM +0000, Joakim Tjernlund wrote: > > > We have a ring of routers(5 of them) running unnumbered pppoe links between them. Adding OSPF authentication (auth trailer) works OK. > > > However, removing OSPFv3 on ONE interface causes big problem in some cases, we loose auth in the whole ring > > > and routing is then kaputt for all routers. > > > > > > We have noted that some PDUs(like LS update) are sent without auth trailer so the receiving nodes > > > complains with "ospfv3_2: Authentication failed for nbr 0.0.139.1 on p1-1-3-1-4 - missing authentication trailer (0)" > > > > > > OSPFv3 Hello is OK though, it still has its auth trailer. > > > > Hmm, that is strange. There is difference between Hello and LSUpd in > > OSPFv3 Auth receiver code, but not in sending code. That is essentially: > > > > ??if (ifa->autype != OSPF_AUTH_CRYPT) > > ????return; > > > > ??... attach auth trailer ... > > > > > > > Any ideas? > > > > LSUpd packets do not contain explicit flag whether they use OSPFv3 auth > > trailer. Such information is stored in neighbor structure based on > > received DBDes packet. So 'missing authentication trailer' for LSUpd > > really means that such neighbor structure says 'no auth'. But that > > should not happen as that DBDes packet would be rejected. > > > > One idea is that DBDes packets intended for one iface (non-authenticated) > > were sent to a different iface (authenticated) and they poisoned neighbor > > structure with 'no auth' info. > > > > You say 'loose auth in the whole ring', i can imagine that it will break > > adjacent links, but it will really break even non-adjacent links? > > > > Yes, it takes some time(about 30 min) though before the whole ring is gone. > All nodes are seeing "missing authentication trailer" msg. I should mention that a birdc restart/configure(on each node) will correct the problem. From Kenth.Eriksson at infinera.com Fri Mar 12 16:39:06 2021 From: Kenth.Eriksson at infinera.com (Kenth Eriksson) Date: Fri, 12 Mar 2021 15:39:06 +0000 Subject: OSPFv3 auth problem In-Reply-To: <77721ed5eef24d8e7f437d4dbc622a7d9fdaa957.camel@infinera.com> References: <90f2251e747b31625a2f5844e260fd5b7c3c70d1.camel@infinera.com> <20210311145053.GB3327@feanor.crfreenet.org> <1dbecb519e384b2041bf60c5b72eff57cbd172f7.camel@infinera.com> <77721ed5eef24d8e7f437d4dbc622a7d9fdaa957.camel@infinera.com> Message-ID: We can see auth trailer on the hellos, the neighborship is established, but still the trace is appearing. Does that mean that the options on the neighbor object are incorrect? bird> show ospf neighbors ospfv3_2 ospfv3_2: Router ID Pri State DTime Interface Router IP 0.0.139.2 0 Full/PtP 32.725 p1-1-5-1-6 fe80::206:9cff:fe0c:a533 bird> 2021-03-12 16:32:36.564 ospfv3_2: Authentication failed for nbr 0.0.139.2 on p1-1-5-1-6 - missing authentication trailer (0) /k -----Original Message----- From: Bird-users On Behalf Of Joakim Tjernlund Sent: den 11 mars 2021 16:50 To: santiago at crfreenet.org Cc: bird-users at network.cz Subject: Re: OSPFv3 auth problem CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Thu, 2021-03-11 at 15:06 +0000, Joakim Tjernlund wrote: > On Thu, 2021-03-11 at 15:50 +0100, Ondrej Zajicek wrote: > > On Thu, Mar 11, 2021 at 12:35:40PM +0000, Joakim Tjernlund wrote: > > > We have a ring of routers(5 of them) running unnumbered pppoe links between them. Adding OSPF authentication (auth trailer) works OK. > > > However, removing OSPFv3 on ONE interface causes big problem in > > > some cases, we loose auth in the whole ring and routing is then kaputt for all routers. > > > > > > We have noted that some PDUs(like LS update) are sent without auth > > > trailer so the receiving nodes complains with "ospfv3_2: Authentication failed for nbr 0.0.139.1 on p1-1-3-1-4 - missing authentication trailer (0)" > > > > > > OSPFv3 Hello is OK though, it still has its auth trailer. > > > > Hmm, that is strange. There is difference between Hello and LSUpd in > > OSPFv3 Auth receiver code, but not in sending code. That is essentially: > > > > if (ifa->autype != OSPF_AUTH_CRYPT) > > return; > > > > ... attach auth trailer ... > > > > > > > Any ideas? > > > > LSUpd packets do not contain explicit flag whether they use OSPFv3 > > auth trailer. Such information is stored in neighbor structure based > > on received DBDes packet. So 'missing authentication trailer' for > > LSUpd really means that such neighbor structure says 'no auth'. But > > that should not happen as that DBDes packet would be rejected. > > > > One idea is that DBDes packets intended for one iface > > (non-authenticated) were sent to a different iface (authenticated) > > and they poisoned neighbor structure with 'no auth' info. > > > > You say 'loose auth in the whole ring', i can imagine that it will > > break adjacent links, but it will really break even non-adjacent links? > > > > Yes, it takes some time(about 30 min) though before the whole ring is gone. > All nodes are seeing "missing authentication trailer" msg. I should mention that a birdc restart/configure(on each node) will correct the problem. From bird at 2krueger.de Mon Mar 15 06:56:24 2021 From: bird at 2krueger.de (Marcel =?utf-8?Q?Kr=C3=BCger?=) Date: Mon, 15 Mar 2021 06:56:24 +0100 Subject: Weird behavior of link local gateway assignments Message-ID: <20210315055624.c3oi4un4pwmueuls@yoga> Hi, I encountered some issues when trying to set the gateway to a link-local IPv6 address in a filter and am wondering if there is a trick I am missing: When assigning a link-local address (say fe80::4242%eno1) to `gw` in a filter using e.g. gw = fe80::4242%eno1; the config file parser complains about a unexpected "%". Of course, it doesn't work without the `%eno1` either ("Invalid gw address"), so is there other way to pass the intended interface? It seems that the interface doesn't get passed even if assigning from an existing address with correctly set interface, since invoking in a filter gw = gw; fails with "Invalid gw address" too if `gw` has a link local value. Is this intended? Is there some other way to set the gw in a filter to a link local value? Best regards, Marcel From maria.matejka at nic.cz Mon Mar 15 11:42:14 2021 From: maria.matejka at nic.cz (Maria Matejka) Date: Mon, 15 Mar 2021 11:42:14 +0100 Subject: BIRD Journey to Threads: Chapter zero of a blogpost series Message-ID: Hello! As we're working on multithreading support in BIRD, there is a need to document this. There is a user documentation (which almost doesn't change) and a programmer's documentation composed mostly of comments spread across the source code. There is also a kind-of high-level documentation to describe how are the BIRD's internal processes changing. If you're just an ordinary user, you don't need to care much about that. We're sharing this mostly for people who know (or want to know) how BIRD works internally and how it is going to change. The zeroth chapter is here, other chapters should follow soon: https://en.blog.nic.cz/2021/03/15/bird-journey-to-threads-chapter-0-the-reason-why/ (Content: An introduction and summary of previous major BIRD structural changes.) I deeply appreciate your feedback and questions. Maria From Kenth.Eriksson at infinera.com Mon Mar 15 15:25:18 2021 From: Kenth.Eriksson at infinera.com (Kenth Eriksson) Date: Mon, 15 Mar 2021 14:25:18 +0000 Subject: OSPFv3 auth problem In-Reply-To: <77721ed5eef24d8e7f437d4dbc622a7d9fdaa957.camel@infinera.com> References: <90f2251e747b31625a2f5844e260fd5b7c3c70d1.camel@infinera.com> <20210311145053.GB3327@feanor.crfreenet.org> <1dbecb519e384b2041bf60c5b72eff57cbd172f7.camel@infinera.com> <77721ed5eef24d8e7f437d4dbc622a7d9fdaa957.camel@infinera.com> Message-ID: I believe the "options" of the neighbor object is only updated as a result of NEIGHBOR_EXSTART. If the authentication is enabled after unauthenticated neighbor adjacency, then this does not result in a new NEIGHBOR_EXSTART. Thus the options of the neighbor object is stuck 0x113, and not the updated to 0x513 (i.e. OPT_AT) resulting in that OSPF packets are becoming dropped in procedure ospf_pkt_checkauth3 since auth_present is zero. If I manually kick the FSM when authentication is changed by doing ISM_DOWN-> ISM_UP then this works as expected (see pseudo code below). I believe there is some logic missing when changing the autype? Can this be done in some more fine granular way? /* AUTHENTICATION */ if (ifa->autype != new->autype) { OSPF_TRACE(D_EVENTS, "Changing authentication type of %s", ifname); ifa->autype = new->autype; ... ospf_iface_sm(ifa, ISM_DOWN); ospf_iface_sm(ifa, ISM_UP); } Thanks, Kenth -----Original Message----- From: Bird-users On Behalf Of Joakim Tjernlund Sent: den 11 mars 2021 16:50 To: santiago at crfreenet.org Cc: bird-users at network.cz Subject: Re: OSPFv3 auth problem CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Thu, 2021-03-11 at 15:06 +0000, Joakim Tjernlund wrote: > On Thu, 2021-03-11 at 15:50 +0100, Ondrej Zajicek wrote: > > On Thu, Mar 11, 2021 at 12:35:40PM +0000, Joakim Tjernlund wrote: > > > We have a ring of routers(5 of them) running unnumbered pppoe links between them. Adding OSPF authentication (auth trailer) works OK. > > > However, removing OSPFv3 on ONE interface causes big problem in > > > some cases, we loose auth in the whole ring and routing is then kaputt for all routers. > > > > > > We have noted that some PDUs(like LS update) are sent without auth > > > trailer so the receiving nodes complains with "ospfv3_2: Authentication failed for nbr 0.0.139.1 on p1-1-3-1-4 - missing authentication trailer (0)" > > > > > > OSPFv3 Hello is OK though, it still has its auth trailer. > > > > Hmm, that is strange. There is difference between Hello and LSUpd in > > OSPFv3 Auth receiver code, but not in sending code. That is essentially: > > > > if (ifa->autype != OSPF_AUTH_CRYPT) > > return; > > > > ... attach auth trailer ... > > > > > > > Any ideas? > > > > LSUpd packets do not contain explicit flag whether they use OSPFv3 > > auth trailer. Such information is stored in neighbor structure based > > on received DBDes packet. So 'missing authentication trailer' for > > LSUpd really means that such neighbor structure says 'no auth'. But > > that should not happen as that DBDes packet would be rejected. > > > > One idea is that DBDes packets intended for one iface > > (non-authenticated) were sent to a different iface (authenticated) > > and they poisoned neighbor structure with 'no auth' info. > > > > You say 'loose auth in the whole ring', i can imagine that it will > > break adjacent links, but it will really break even non-adjacent links? > > > > Yes, it takes some time(about 30 min) though before the whole ring is gone. > All nodes are seeing "missing authentication trailer" msg. I should mention that a birdc restart/configure(on each node) will correct the problem. From santiago at crfreenet.org Mon Mar 15 15:59:23 2021 From: santiago at crfreenet.org (Ondrej Zajicek) Date: Mon, 15 Mar 2021 15:59:23 +0100 Subject: OSPFv3 auth problem In-Reply-To: References: <90f2251e747b31625a2f5844e260fd5b7c3c70d1.camel@infinera.com> <20210311145053.GB3327@feanor.crfreenet.org> <1dbecb519e384b2041bf60c5b72eff57cbd172f7.camel@infinera.com> <77721ed5eef24d8e7f437d4dbc622a7d9fdaa957.camel@infinera.com> Message-ID: <20210315145923.GC3327@feanor.crfreenet.org> On Mon, Mar 15, 2021 at 02:25:18PM +0000, Kenth Eriksson wrote: > I believe the "options" of the neighbor object is only updated as a > result of NEIGHBOR_EXSTART. If the authentication is enabled after > unauthenticated neighbor adjacency, then this does not result in a new > NEIGHBOR_EXSTART. Thus the options of the neighbor object is stuck 0x113, > and not the updated to 0x513 (i.e. OPT_AT) resulting in that OSPF packets > are becoming dropped in procedure ospf_pkt_checkauth3 since auth_present > is zero. Yes, you are right. If iface is configured to not use auth, adjacency is established (n->options are set to not include OPT_AT) and then reconfigured to use auth, adjacency is kept (because Hello packets are authenticated) but LSUpd and others are ignored (because there is no OPT_AT flag in n->options). RFC 7166 is vague about updating OPT_AT flag, and basic OSPFv2/v3 RFC just describing setting n->options from DBDes during NEIGHBOR_EXSTART. > If I manually kick the FSM when authentication is changed by > doing ISM_DOWN-> ISM_UP then this works as expected (see pseudo code > below). I believe there is some logic missing when changing the autype? > Can this be done in some more fine granular way? I think that the best solution would be to update OPT_AT flag in n->options based on received Hello packets. Will make a patch. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From mellow.drifter at gmail.com Mon Mar 15 16:15:57 2021 From: mellow.drifter at gmail.com (Darren O'Connor) Date: Mon, 15 Mar 2021 11:15:57 -0400 Subject: BIRD Journey to Threads: Chapter zero of a blogpost series In-Reply-To: References: Message-ID: Hey Maria. Great so see the work being done on multithreading! I do have one question but not sure if it's related. I asked a while back if bird would ever support any sort of 'structured output' - i.e. adding the possibility of json or some other output which would make it easier to get the right data. I believe you mentioned it was getting looked at but multithreading was coming first. Any movement on that though? Thanks Darren On Mon, 15 Mar 2021 at 06:45, Maria Matejka wrote: > Hello! > > As we're working on multithreading support in BIRD, there is a need to > document this. There is a user documentation (which almost doesn't > change) and a programmer's documentation composed mostly of comments > spread across the source code. > > There is also a kind-of high-level documentation to describe how are the > BIRD's internal processes changing. If you're just an ordinary user, you > don't need to care much about that. We're sharing this mostly for people > who know (or want to know) how BIRD works internally and how it is going > to change. > > The zeroth chapter is here, other chapters should follow soon: > > > https://en.blog.nic.cz/2021/03/15/bird-journey-to-threads-chapter-0-the-reason-why/ > > (Content: An introduction and summary of previous major BIRD structural > changes.) > > I deeply appreciate your feedback and questions. > > Maria > -------------- next part -------------- An HTML attachment was scrubbed... URL: From santiago at crfreenet.org Mon Mar 15 16:43:19 2021 From: santiago at crfreenet.org (Ondrej Zajicek) Date: Mon, 15 Mar 2021 16:43:19 +0100 Subject: Weird behavior of link local gateway assignments In-Reply-To: <20210315055624.c3oi4un4pwmueuls@yoga> References: <20210315055624.c3oi4un4pwmueuls@yoga> Message-ID: <20210315154319.GD3327@feanor.crfreenet.org> On Mon, Mar 15, 2021 at 06:56:24AM +0100, Marcel Kr?ger wrote: > Hi, > > I encountered some issues when trying to set the gateway to a link-local > IPv6 address in a filter and am wondering if there is a trick I am > missing: > > When assigning a link-local address (say fe80::4242%eno1) > to `gw` in a filter using e.g. > > gw = fe80::4242%eno1; > > the config file parser complains about a unexpected "%". Of course, it > doesn't work without the `%eno1` either ("Invalid gw address"), so is > there other way to pass the intended interface? Hi Unfortunately this does not work and i do not see any workarounds in existing code. Our IP address data type does not keep 'iface' in it, so link-local IPv6 addresses are a bit of problem. Also, setting gw (regular) in reality sets both gw and iface for a nexthop (gw is resolved and appropriate iface is found). It makes sense to add workaround for link-local addresses so that setting link-local gw is resolved in existing iface, so at least things like: ifname = "eno1"; gw = fe80::4242; or gw = gw; would work. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From Joakim.Tjernlund at infinera.com Mon Mar 15 16:54:59 2021 From: Joakim.Tjernlund at infinera.com (Joakim Tjernlund) Date: Mon, 15 Mar 2021 15:54:59 +0000 Subject: OSPFv3 auth problem In-Reply-To: <20210315145923.GC3327@feanor.crfreenet.org> References: <90f2251e747b31625a2f5844e260fd5b7c3c70d1.camel@infinera.com> <20210311145053.GB3327@feanor.crfreenet.org> <1dbecb519e384b2041bf60c5b72eff57cbd172f7.camel@infinera.com> <77721ed5eef24d8e7f437d4dbc622a7d9fdaa957.camel@infinera.com> <20210315145923.GC3327@feanor.crfreenet.org> Message-ID: On Mon, 2021-03-15 at 15:59 +0100, Ondrej Zajicek wrote: > On Mon, Mar 15, 2021 at 02:25:18PM +0000, Kenth Eriksson wrote: > > I believe the "options" of the neighbor object is only updated as a > > result of NEIGHBOR_EXSTART. If the authentication is enabled after > > unauthenticated neighbor adjacency, then this does not result in a new > > NEIGHBOR_EXSTART. Thus the options of the neighbor object is stuck 0x113, > > and not the updated to 0x513 (i.e. OPT_AT) resulting in that OSPF packets > > are becoming dropped in procedure ospf_pkt_checkauth3 since auth_present > > is zero. > > Yes, you are right. If iface is configured to not use auth, adjacency is > established (n->options are set to not include OPT_AT) and then > reconfigured to use auth, adjacency is kept (because Hello packets > are authenticated) but LSUpd and others are ignored (because there > is no OPT_AT flag in n->options). > > RFC 7166 is vague about updating OPT_AT flag, and basic OSPFv2/v3 RFC > just describing setting n->options from DBDes during NEIGHBOR_EXSTART. > > > If I manually kick the FSM when authentication is changed by > > doing ISM_DOWN-> ISM_UP then this works as expected (see pseudo code > > below). I believe there is some logic missing when changing the autype? > > Can this be done in some more fine granular way? > > I think that the best solution would be to update OPT_AT flag in > n->options based on received Hello packets. Will make a patch. What about IPv4? Does it also need some tweaking is this case? Jocke From santiago at crfreenet.org Mon Mar 15 17:06:57 2021 From: santiago at crfreenet.org (Ondrej Zajicek) Date: Mon, 15 Mar 2021 17:06:57 +0100 Subject: OSPFv3 auth problem In-Reply-To: References: <90f2251e747b31625a2f5844e260fd5b7c3c70d1.camel@infinera.com> <20210311145053.GB3327@feanor.crfreenet.org> <1dbecb519e384b2041bf60c5b72eff57cbd172f7.camel@infinera.com> <77721ed5eef24d8e7f437d4dbc622a7d9fdaa957.camel@infinera.com> <20210315145923.GC3327@feanor.crfreenet.org> Message-ID: <20210315160657.GE3327@feanor.crfreenet.org> On Mon, Mar 15, 2021 at 03:54:59PM +0000, Joakim Tjernlund wrote: > > I think that the best solution would be to update OPT_AT flag in > > n->options based on received Hello packets. Will make a patch. > > What about IPv4? Does it also need some tweaking is this case? No, IPv4 behavior is different, used authentication mode is writte in auth_type field in each packet. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From Joakim.Tjernlund at infinera.com Mon Mar 15 17:26:03 2021 From: Joakim.Tjernlund at infinera.com (Joakim Tjernlund) Date: Mon, 15 Mar 2021 16:26:03 +0000 Subject: OSPFv3 auth problem In-Reply-To: <20210315145923.GC3327@feanor.crfreenet.org> References: <90f2251e747b31625a2f5844e260fd5b7c3c70d1.camel@infinera.com> <20210311145053.GB3327@feanor.crfreenet.org> <1dbecb519e384b2041bf60c5b72eff57cbd172f7.camel@infinera.com> <77721ed5eef24d8e7f437d4dbc622a7d9fdaa957.camel@infinera.com> <20210315145923.GC3327@feanor.crfreenet.org> Message-ID: <2ca33666d2371db00aec29ced4cec56f7c445bdd.camel@infinera.com> On Mon, 2021-03-15 at 15:59 +0100, Ondrej Zajicek wrote: > On Mon, Mar 15, 2021 at 02:25:18PM +0000, Kenth Eriksson wrote: > > I believe the "options" of the neighbor object is only updated as a > > result of NEIGHBOR_EXSTART. If the authentication is enabled after > > unauthenticated neighbor adjacency, then this does not result in a new > > NEIGHBOR_EXSTART. Thus the options of the neighbor object is stuck 0x113, > > and not the updated to 0x513 (i.e. OPT_AT) resulting in that OSPF packets > > are becoming dropped in procedure ospf_pkt_checkauth3 since auth_present > > is zero. > > Yes, you are right. If iface is configured to not use auth, adjacency is > established (n->options are set to not include OPT_AT) and then > reconfigured to use auth, adjacency is kept (because Hello packets > are authenticated) but LSUpd and others are ignored (because there > is no OPT_AT flag in n->options). > > RFC 7166 is vague about updating OPT_AT flag, and basic OSPFv2/v3 RFC > just describing setting n->options from DBDes during NEIGHBOR_EXSTART. > > > If I manually kick the FSM when authentication is changed by > > doing ISM_DOWN-> ISM_UP then this works as expected (see pseudo code > > below). I believe there is some logic missing when changing the autype? > > Can this be done in some more fine granular way? > > I think that the best solution would be to update OPT_AT flag in > n->options based on received Hello packets. Will make a patch. Are you thinking something like this? diff --git a/proto/ospf/hello.c b/proto/ospf/hello.c index d094f934..dc3bc912 100644 --- a/proto/ospf/hello.c +++ b/proto/ospf/hello.c @@ -253,6 +253,10 @@ ospf_receive_hello(struct ospf_packet *pkt, struct ospf_iface *ifa, neighbors = ps->neighbors; neigh_count = (plen - sizeof(struct ospf_hello3_packet)) / sizeof(u32); + if (rcv_options & OPT_AT) + n->options |= OPT_AT; + else + n->options &= ~OPT_AT; } if (rcv_helloint != ifa->helloint) From maria.matejka at nic.cz Mon Mar 15 17:07:47 2021 From: maria.matejka at nic.cz (=?UTF-8?Q?Maria_Mat=C4=9Bjka?=) Date: Mon, 15 Mar 2021 17:07:47 +0100 Subject: BIRD Journey to Threads: Chapter zero of a blogpost series In-Reply-To: References: Message-ID: <489A5207-8563-474C-BC38-DDC7F0F93850@nic.cz> Hello! Yes, it is going to happen. The order should be (roughly) as follows: 0) basic multithreading support (already implemented) 1) structural changes in route export enabling table access from multiple threads 2) conversion of 'show route' to the new route export code 3) json route formatter Maria On March 15, 2021 4:15:57 PM GMT+01:00, Darren O'Connor wrote: >Hey Maria. > >Great so see the work being done on multithreading! I do have one >question >but not sure if it's related. I asked a while back if bird would ever >support any sort of 'structured output' - i.e. adding the possibility >of >json or some other output which would make it easier to get the right >data. >I believe you mentioned it was getting looked at but multithreading was >coming first. Any movement on that though? > >Thanks >Darren > >On Mon, 15 Mar 2021 at 06:45, Maria Matejka >wrote: > >> Hello! >> >> As we're working on multithreading support in BIRD, there is a need >to >> document this. There is a user documentation (which almost doesn't >> change) and a programmer's documentation composed mostly of comments >> spread across the source code. >> >> There is also a kind-of high-level documentation to describe how are >the >> BIRD's internal processes changing. If you're just an ordinary user, >you >> don't need to care much about that. We're sharing this mostly for >people >> who know (or want to know) how BIRD works internally and how it is >going >> to change. >> >> The zeroth chapter is here, other chapters should follow soon: >> >> >> >https://en.blog.nic.cz/2021/03/15/bird-journey-to-threads-chapter-0-the-reason-why/ >> >> (Content: An introduction and summary of previous major BIRD >structural >> changes.) >> >> I deeply appreciate your feedback and questions. >> >> Maria >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fischerdouglas at gmail.com Mon Mar 15 18:07:44 2021 From: fischerdouglas at gmail.com (Douglas Fischer) Date: Mon, 15 Mar 2021 14:07:44 -0300 Subject: BIRD Journey to Threads: Chapter zero of a blogpost series In-Reply-To: References: Message-ID: Hello, Maria and everyone on the list... This is Great News! I'm so happy to receive that mail! That part about "Filter Rework" made me a bit anxious! I don't know exactly means the part: "we decided to preprocess the filter internal structure to another structure which is much easier to execute"... But, to me, it sounds like fragmenting, even more, the "test, mark, and actuate" on the filters... Right? Talking about BGP, I love Bird because only with it I know how to do what I call "2 cycles filtering"... - I create several Small Tests, where each route is tested and marked somehow... - On each Peer-Type, import or export(but mostly on import), and I define which tests will be called to be executed on that route, and live their mark on each route. - I here I test, Mask-lenght, AS-Set, AS-Origin, AS-Path, foreigner-communities, internal-communities, a lot of Regex, and all those multiple complex things... - And at the end of the filter-police I do an "IF" that tests on a combined And+Or the marks lived by the previous tests, and based on that do the accept, reject, add-communities, adjust MED/Local-Pref/Etc... That thing with "Lua scripts" that you mentioned, would be something like what I described? Thanks in advance! Em seg., 15 de mar. de 2021 ?s 07:44, Maria Matejka escreveu: > Hello! > > As we're working on multithreading support in BIRD, there is a need to > document this. There is a user documentation (which almost doesn't > change) and a programmer's documentation composed mostly of comments > spread across the source code. > > There is also a kind-of high-level documentation to describe how are the > BIRD's internal processes changing. If you're just an ordinary user, you > don't need to care much about that. We're sharing this mostly for people > who know (or want to know) how BIRD works internally and how it is going > to change. > > The zeroth chapter is here, other chapters should follow soon: > > > https://en.blog.nic.cz/2021/03/15/bird-journey-to-threads-chapter-0-the-reason-why/ > > (Content: An introduction and summary of previous major BIRD structural > changes.) > > I deeply appreciate your feedback and questions. > > Maria > -- Douglas Fernando Fischer Eng? de Controle e Automa??o -------------- next part -------------- An HTML attachment was scrubbed... URL: From santiago at crfreenet.org Mon Mar 15 18:49:39 2021 From: santiago at crfreenet.org (Ondrej Zajicek) Date: Mon, 15 Mar 2021 18:49:39 +0100 Subject: Weird behavior of link local gateway assignments In-Reply-To: <20210315154319.GD3327@feanor.crfreenet.org> References: <20210315055624.c3oi4un4pwmueuls@yoga> <20210315154319.GD3327@feanor.crfreenet.org> Message-ID: <20210315174939.GF3327@feanor.crfreenet.org> On Mon, Mar 15, 2021 at 04:43:19PM +0100, Ondrej Zajicek wrote: > It makes sense to add workaround for link-local addresses so that setting > link-local gw is resolved in existing iface, so at least things like: > > ifname = "eno1"; > gw = fe80::4242; > > or > > gw = gw; > > would work. This patch should fix it: https://gitlab.nic.cz/labs/bird/-/commit/94abefc00bb22b93493831798391d5d5b21f9d4c -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From maria.matejka at nic.cz Mon Mar 15 19:02:35 2021 From: maria.matejka at nic.cz (Maria Matejka) Date: Mon, 15 Mar 2021 19:02:35 +0100 Subject: BIRD Journey to Threads: Chapter zero of a blogpost series In-Reply-To: References: Message-ID: <64568d2a-d55d-0dc5-db7a-e1365e20d7c2@nic.cz> Hello! On 3/15/21 6:07 PM, Douglas Fischer wrote: > That part about "Filter Rework" made me a bit anxious! > I don't know?exactly?means?the part: > ?"we decided to preprocess the filter internal structure to another > structure which is much easier to execute"... > But, to?me, it sounds like fragmenting, even more, the "test, mark, and > actuate" on the filters... Right? This is a work that has been already included in v2.0.x for x ? 4 as far as I can remember. The filter is simply converted (in config time) from an infix structure with lots of pointers to a stack-oriented postfix bytecode. That bytecode is somehow similar to Lua. We also thought about using Lua itself as a filtering language, anyway we had problems with Lua stack initialization. A simple run of an empty filter took at least 2 us on our testing machine, compared to 35 ns of our empty filter. > Talking about BGP, I love Bird because only with it I know how to do > what I call "2 cycles filtering"... > > - I create several Small Tests, where?each route is tested and marked > somehow... > - On each Peer-Type, import or export(but mostly on import), and I > define which tests will be called to be executed on that route, and live > their mark on each route. > ? - I here I test,?Mask-lenght, AS-Set, AS-Origin, AS-Path, > foreigner-communities, internal-communities, a lot of Regex, and all > those multiple complex things... > - And at the end of the filter-police I do an "IF" that tests on a > combined And+Or the marks lived by the previous tests, and based on that > do the accept, reject, add-communities, adjust MED/Local-Pref/Etc... This stays the same, the filter language didn't change, we just reworked the interpreter. To add to this, there are also custom route attributes. It is quite common to do the small test on import, store the results to BGP communities, decide on export based on them and then filter them out. For this use, you can define your own route attributes and you don't mess with the communities at all. (And these are also faster than community list manipulation.) We are thinking about more filtering features like iterating over the community lists or multipath nexthops. Don't worry, the filters are going to stay the same or better. Thank you for your input! Maria From Joakim.Tjernlund at infinera.com Mon Mar 15 20:03:00 2021 From: Joakim.Tjernlund at infinera.com (Joakim Tjernlund) Date: Mon, 15 Mar 2021 19:03:00 +0000 Subject: OSPFv3 auth problem In-Reply-To: <2ca33666d2371db00aec29ced4cec56f7c445bdd.camel@infinera.com> References: <90f2251e747b31625a2f5844e260fd5b7c3c70d1.camel@infinera.com> <20210311145053.GB3327@feanor.crfreenet.org> <1dbecb519e384b2041bf60c5b72eff57cbd172f7.camel@infinera.com> <77721ed5eef24d8e7f437d4dbc622a7d9fdaa957.camel@infinera.com> <20210315145923.GC3327@feanor.crfreenet.org> <2ca33666d2371db00aec29ced4cec56f7c445bdd.camel@infinera.com> Message-ID: <28ca7866463828771a8ae6b13d9f1d50c4089872.camel@infinera.com> On Mon, 2021-03-15 at 17:26 +0100, Joakim Tjernlund wrote: > On Mon, 2021-03-15 at 15:59 +0100, Ondrej Zajicek wrote: > > On Mon, Mar 15, 2021 at 02:25:18PM +0000, Kenth Eriksson wrote: > > > I believe the "options" of the neighbor object is only updated as a > > > result of NEIGHBOR_EXSTART. If the authentication is enabled after > > > unauthenticated neighbor adjacency, then this does not result in a new > > > NEIGHBOR_EXSTART. Thus the options of the neighbor object is stuck 0x113, > > > and not the updated to 0x513 (i.e. OPT_AT) resulting in that OSPF packets > > > are becoming dropped in procedure ospf_pkt_checkauth3 since auth_present > > > is zero. > > > > Yes, you are right. If iface is configured to not use auth, adjacency is > > established (n->options are set to not include OPT_AT) and then > > reconfigured to use auth, adjacency is kept (because Hello packets > > are authenticated) but LSUpd and others are ignored (because there > > is no OPT_AT flag in n->options). > > > > RFC 7166 is vague about updating OPT_AT flag, and basic OSPFv2/v3 RFC > > just describing setting n->options from DBDes during NEIGHBOR_EXSTART. > > > > > If I manually kick the FSM when authentication is changed by > > > doing ISM_DOWN-> ISM_UP then this works as expected (see pseudo code > > > below). I believe there is some logic missing when changing the autype? > > > Can this be done in some more fine granular way? > > > > I think that the best solution would be to update OPT_AT flag in > > n->options based on received Hello packets. Will make a patch. > > Are you thinking something like this? > > diff --git a/proto/ospf/hello.c b/proto/ospf/hello.c > index d094f934..dc3bc912 100644 > --- a/proto/ospf/hello.c > +++ b/proto/ospf/hello.c > @@ -253,6 +253,10 @@ ospf_receive_hello(struct ospf_packet *pkt, struct ospf_iface *ifa, > ? > > > > ?????neighbors = ps->neighbors; > ?????neigh_count = (plen - sizeof(struct ospf_hello3_packet)) / sizeof(u32); > + if (rcv_options & OPT_AT) > + n->options |= OPT_AT; > + else > + n->options &= ~OPT_AT; > ???} > ? > > > > > > > That did a SEGV on a NULL nbr ... Now running this: diff --git a/proto/ospf/hello.c b/proto/ospf/hello.c index d094f934..e103d2fd 100644 --- a/proto/ospf/hello.c +++ b/proto/ospf/hello.c @@ -341,6 +341,11 @@ ospf_receive_hello(struct ospf_packet *pkt, struct ospf_ifa ce *ifa, n->bdr = rcv_bdr; n->priority = rcv_priority; n->iface_id = rcv_iface_id; + if (ospf_is_v3(p)) + if (rcv_options & OPT_AT) + n->options |= OPT_AT; + else + n->options &= ~OPT_AT; /* Update inactivity timer */ ospf_neigh_sm(n, INM_HELLOREC); -- From lists at manon.de Mon Mar 15 20:46:00 2021 From: lists at manon.de (Manon Goo) Date: Mon, 15 Mar 2021 19:46:00 +0000 Subject: Routing decision based on carp status under freebsd Message-ID: <20210315194600.Horde.loNzhCXGinuEb1QMs31WJ5d@portal.dg-i.net> Hello, I would like announce routes differently via bgp (longer AS-Path) depending on, if carp(4) status is "master" or "backup". If the carp status is ?Master? Status the shows up as a kernel route to the carp(4) address. If carp is in "Backup? status the route is removed. **Master Status for carp IP 10.8.15.254** bird> show route 10.8.15.254/32 all 10.8.15.254/32 dev lo0 [kernel1 00:06:42] * (10) Type: inherit unicast univ Kernel.source: 1 Kernel.metric: 0 bird> **Backup Status for carp IP 10.8.15.254** bird> show route 10.8.15.254/32 all Network not in table bird> If possible I would like to check in my bgp export filter if I have a kernel route to my carp address (10.8.15.254) and if possible if this route is via the loopback dev lo0 Is there any function to lookup a route in bird that could be used in the following scenario? filter bgp_export { if ( [ check_if_10.8.15.254/32 is via lo0] ) { bgp_local_pref = 120; accept; } else { bgp_path.prepend(65534); accept; } } Kind regards, Manon From joakim.tjernlund at infinera.com Tue Mar 16 09:31:51 2021 From: joakim.tjernlund at infinera.com (Joakim Tjernlund) Date: Tue, 16 Mar 2021 09:31:51 +0100 Subject: [PATCH] Update IPv6 neighbour authentication state from Hello pkgs Message-ID: <20210316083151.1476-1-joakim.tjernlund@infinera.com> Signed-off-by: Joakim Tjernlund --- proto/ospf/hello.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/proto/ospf/hello.c b/proto/ospf/hello.c index d094f934..51f685e5 100644 --- a/proto/ospf/hello.c +++ b/proto/ospf/hello.c @@ -341,6 +341,8 @@ ospf_receive_hello(struct ospf_packet *pkt, struct ospf_iface *ifa, n->bdr = rcv_bdr; n->priority = rcv_priority; n->iface_id = rcv_iface_id; + if (ospf_is_v3(p)) + n->options = (n->options & ~OPT_AT) | (rcv_options & OPT_AT); /* Update inactivity timer */ ospf_neigh_sm(n, INM_HELLOREC); -- 2.26.2 From Joakim.Tjernlund at infinera.com Tue Mar 16 09:35:20 2021 From: Joakim.Tjernlund at infinera.com (Joakim Tjernlund) Date: Tue, 16 Mar 2021 08:35:20 +0000 Subject: OSPFv3 auth problem In-Reply-To: <28ca7866463828771a8ae6b13d9f1d50c4089872.camel@infinera.com> References: <90f2251e747b31625a2f5844e260fd5b7c3c70d1.camel@infinera.com> <20210311145053.GB3327@feanor.crfreenet.org> <1dbecb519e384b2041bf60c5b72eff57cbd172f7.camel@infinera.com> <77721ed5eef24d8e7f437d4dbc622a7d9fdaa957.camel@infinera.com> <20210315145923.GC3327@feanor.crfreenet.org> <2ca33666d2371db00aec29ced4cec56f7c445bdd.camel@infinera.com> <28ca7866463828771a8ae6b13d9f1d50c4089872.camel@infinera.com> Message-ID: <9c94de324bb13169937fb6423a54dfe02beb5e43.camel@infinera.com> On Mon, 2021-03-15 at 20:02 +0100, Joakim Tjernlund wrote: > On Mon, 2021-03-15 at 17:26 +0100, Joakim Tjernlund wrote: > > On Mon, 2021-03-15 at 15:59 +0100, Ondrej Zajicek wrote: > > > On Mon, Mar 15, 2021 at 02:25:18PM +0000, Kenth Eriksson wrote: > > > > I believe the "options" of the neighbor object is only updated as a > > > > result of NEIGHBOR_EXSTART. If the authentication is enabled after > > > > unauthenticated neighbor adjacency, then this does not result in a new > > > > NEIGHBOR_EXSTART. Thus the options of the neighbor object is stuck 0x113, > > > > and not the updated to 0x513 (i.e. OPT_AT) resulting in that OSPF packets > > > > are becoming dropped in procedure ospf_pkt_checkauth3 since auth_present > > > > is zero. > > > > > > Yes, you are right. If iface is configured to not use auth, adjacency is > > > established (n->options are set to not include OPT_AT) and then > > > reconfigured to use auth, adjacency is kept (because Hello packets > > > are authenticated) but LSUpd and others are ignored (because there > > > is no OPT_AT flag in n->options). > > > > > > RFC 7166 is vague about updating OPT_AT flag, and basic OSPFv2/v3 RFC > > > just describing setting n->options from DBDes during NEIGHBOR_EXSTART. > > > > > > > If I manually kick the FSM when authentication is changed by > > > > doing ISM_DOWN-> ISM_UP then this works as expected (see pseudo code > > > > below). I believe there is some logic missing when changing the autype? > > > > Can this be done in some more fine granular way? > > > > > > I think that the best solution would be to update OPT_AT flag in > > > n->options based on received Hello packets. Will make a patch. > > > > Are you thinking something like this? > > > > diff --git a/proto/ospf/hello.c b/proto/ospf/hello.c > > index d094f934..dc3bc912 100644 > > --- a/proto/ospf/hello.c > > +++ b/proto/ospf/hello.c > > @@ -253,6 +253,10 @@ ospf_receive_hello(struct ospf_packet *pkt, struct ospf_iface *ifa, > > ? > > > > > > > > ?????neighbors = ps->neighbors; > > ?????neigh_count = (plen - sizeof(struct ospf_hello3_packet)) / sizeof(u32); > > + if (rcv_options & OPT_AT) > > + n->options |= OPT_AT; > > + else > > + n->options &= ~OPT_AT; > > ???} > > ? > > > > > > > > > > > > > > > > That did a SEGV on a NULL nbr ... > Now running this: > > diff --git a/proto/ospf/hello.c b/proto/ospf/hello.c > index d094f934..e103d2fd 100644 > --- a/proto/ospf/hello.c > +++ b/proto/ospf/hello.c > @@ -341,6 +341,11 @@ ospf_receive_hello(struct ospf_packet *pkt, struct ospf_ifa > ce *ifa, > ???n->bdr = rcv_bdr; > ???n->priority = rcv_priority; > ???n->iface_id = rcv_iface_id; > + if (ospf_is_v3(p)) > + if (rcv_options & OPT_AT) > + n->options |= OPT_AT; > + else > + n->options &= ~OPT_AT; > ? > > > > ???/* Update inactivity timer */ > ???ospf_neigh_sm(n, INM_HELLOREC); Sent a proper patch, let us know what you think. Jocke From fischerdouglas at gmail.com Tue Mar 16 12:36:37 2021 From: fischerdouglas at gmail.com (Douglas Fischer) Date: Tue, 16 Mar 2021 08:36:37 -0300 Subject: BIRD Journey to Threads: Chapter zero of a blogpost series In-Reply-To: <64568d2a-d55d-0dc5-db7a-e1365e20d7c2@nic.cz> References: <64568d2a-d55d-0dc5-db7a-e1365e20d7c2@nic.cz> Message-ID: I'm trying to understand a bit deeper the new concepts of multithreading of Bird. You mentioned: "and a programmer's documentation composed mostly of comments spread across the source code" So I decided to dig a bit on the code available at https://gitlab.nic.cz/labs/bird/ to look at the comments, try to understand the concepts... But I could not find any tags earlier than 1 year. No releases bigger than 2.0.7. No Milestones. Is reasonable to consider that this innovative part of the code is still no publicly available? How someone that "want to know how BIRD works internally and how it is going to change" could look a bit more directly to that part of the code changes? Em seg., 15 de mar. de 2021 ?s 15:02, Maria Matejka escreveu: > Hello! > > On 3/15/21 6:07 PM, Douglas Fischer wrote: > > That part about "Filter Rework" made me a bit anxious! > > I don't know exactly means the part: > > "we decided to preprocess the filter internal structure to another > > structure which is much easier to execute"... > > But, to me, it sounds like fragmenting, even more, the "test, mark, and > > actuate" on the filters... Right? > > This is a work that has been already included in v2.0.x for x ? 4 as far > as I can remember. The filter is simply converted (in config time) from > an infix structure with lots of pointers to a stack-oriented postfix > bytecode. > > That bytecode is somehow similar to Lua. We also thought about using Lua > itself as a filtering language, anyway we had problems with Lua stack > initialization. A simple run of an empty filter took at least 2 us on > our testing machine, compared to 35 ns of our empty filter. > > > Talking about BGP, I love Bird because only with it I know how to do > > what I call "2 cycles filtering"... > > > > - I create several Small Tests, where each route is tested and marked > > somehow... > > - On each Peer-Type, import or export(but mostly on import), and I > > define which tests will be called to be executed on that route, and live > > their mark on each route. > > - I here I test, Mask-lenght, AS-Set, AS-Origin, AS-Path, > > foreigner-communities, internal-communities, a lot of Regex, and all > > those multiple complex things... > > - And at the end of the filter-police I do an "IF" that tests on a > > combined And+Or the marks lived by the previous tests, and based on that > > do the accept, reject, add-communities, adjust MED/Local-Pref/Etc... > > This stays the same, the filter language didn't change, we just reworked > the interpreter. To add to this, there are also custom route attributes. > It is quite common to do the small test on import, store the results to > BGP communities, decide on export based on them and then filter them > out. For this use, you can define your own route attributes and you > don't mess with the communities at all. (And these are also faster than > community list manipulation.) > > We are thinking about more filtering features like iterating over the > community lists or multipath nexthops. Don't worry, the filters are > going to stay the same or better. > > Thank you for your input! > > Maria > -- Douglas Fernando Fischer Eng? de Controle e Automa??o -------------- next part -------------- An HTML attachment was scrubbed... URL: From maria.matejka at nic.cz Tue Mar 16 15:32:27 2021 From: maria.matejka at nic.cz (Maria Matejka) Date: Tue, 16 Mar 2021 15:32:27 +0100 Subject: BIRD Journey to Threads: Chapter zero of a blogpost series In-Reply-To: References: <64568d2a-d55d-0dc5-db7a-e1365e20d7c2@nic.cz> Message-ID: <34dad870-0992-34b6-2046-8f16163b79d7@nic.cz> Hello! Well, there are several branches spread across the repository, keeping different stages of development, mostly buggy or badly designed in some way, with cherry-picks and rebases everywhere. To see something that seems to be useful (and mostly final) even for now, look at the commit c78f88c91c7b75f530d70d503fa011c20f16f278 (yes, not even a branch, just a commit deep in a repository). The locking code in that branch may get simplified before release. There is also a branch named 'guernsey' (for completely unrelated reasons; yes, it is chaotic) where you can see the (unfinished) next chapter of this series together with lots of other stuff related to route storage. This branch may be rebased or otherwise amended with no warning. There is also some code not to be used, testing some design ideas, like parts of branches 'mq-async-export' and 'jersey'. We may cherry-pick some changes from there. Parts of the code are also still not written (e.g. most of the changes in route export) and I'm going to code these after writing the documentation, instead of documenting what the code does. You are also right that the last version is currently 2.0.7; the pace of ordinary releases has dropped down a bit as we spend quite a lot of time thinking about multithreading design. Maria On 3/16/21 12:36 PM, Douglas Fischer wrote: > I'm trying to understand a bit deeper the new concepts of multithreading > of Bird. > > You mentioned: > "and a programmer's documentation composed mostly of comments spread > across the source code" > > So I decided to dig a bit on the code available at > https://gitlab.nic.cz/labs/bird/ to > look at the comments, try to understand the concepts... > But I could not find any tags earlier than 1 year. No releases bigger > than 2.0.7. No Milestones. > > Is reasonable to consider that this innovative part of the code is still > no publicly available? > > How someone that "want to know how BIRD works internally and how it is > going to change" could look a bit more directly to that part of the code > changes? > > Em seg., 15 de mar. de 2021 ?s 15:02, Maria Matejka > > escreveu: > > Hello! > > On 3/15/21 6:07 PM, Douglas Fischer wrote: > > That part about "Filter Rework" made me a bit anxious! > > I don't know?exactly?means?the part: > >? ?"we decided to preprocess the filter internal structure to another > > structure which is much easier to execute"... > > But, to?me, it sounds like fragmenting, even more, the "test, > mark, and > > actuate" on the filters... Right? > > This is a work that has been already included in v2.0.x for x ? 4 as > far > as I can remember. The filter is simply converted (in config time) from > an infix structure with lots of pointers to a stack-oriented postfix > bytecode. > > That bytecode is somehow similar to Lua. We also thought about using > Lua > itself as a filtering language, anyway we had problems with Lua stack > initialization. A simple run of an empty filter took at least 2 us on > our testing machine, compared to 35 ns of our empty filter. > > > Talking about BGP, I love Bird because only with it I know how to do > > what I call "2 cycles filtering"... > > > > - I create several Small Tests, where?each route is tested and > marked > > somehow... > > - On each Peer-Type, import or export(but mostly on import), and I > > define which tests will be called to be executed on that route, > and live > > their mark on each route. > >? ? - I here I test,?Mask-lenght, AS-Set, AS-Origin, AS-Path, > > foreigner-communities, internal-communities, a lot of Regex, and all > > those multiple complex things... > > - And at the end of the filter-police I do an "IF" that tests on a > > combined And+Or the marks lived by the previous tests, and based > on that > > do the accept, reject, add-communities, adjust MED/Local-Pref/Etc... > > This stays the same, the filter language didn't change, we just > reworked > the interpreter. To add to this, there are also custom route > attributes. > It is quite common to do the small test on import, store the results to > BGP communities, decide on export based on them and then filter them > out. For this use, you can define your own route attributes and you > don't mess with the communities at all. (And these are also faster than > community list manipulation.) > > We are thinking about more filtering features like iterating over the > community lists or multipath nexthops. Don't worry, the filters are > going to stay the same or better. > > Thank you for your input! > > Maria > > > > -- > Douglas Fernando Fischer > Eng? de Controle e Automa??o From santiago at crfreenet.org Tue Mar 16 16:45:32 2021 From: santiago at crfreenet.org (Ondrej Zajicek) Date: Tue, 16 Mar 2021 16:45:32 +0100 Subject: OSPFv3 auth problem In-Reply-To: <9c94de324bb13169937fb6423a54dfe02beb5e43.camel@infinera.com> References: <90f2251e747b31625a2f5844e260fd5b7c3c70d1.camel@infinera.com> <20210311145053.GB3327@feanor.crfreenet.org> <1dbecb519e384b2041bf60c5b72eff57cbd172f7.camel@infinera.com> <77721ed5eef24d8e7f437d4dbc622a7d9fdaa957.camel@infinera.com> <20210315145923.GC3327@feanor.crfreenet.org> <2ca33666d2371db00aec29ced4cec56f7c445bdd.camel@infinera.com> <28ca7866463828771a8ae6b13d9f1d50c4089872.camel@infinera.com> <9c94de324bb13169937fb6423a54dfe02beb5e43.camel@infinera.com> Message-ID: <20210316154532.GG3327@feanor.crfreenet.org> On Tue, Mar 16, 2021 at 08:35:20AM +0000, Joakim Tjernlund wrote: > Sent a proper patch, let us know what you think. Hi Your patch is ok, i just wanted something more verbose (it is IMHO a notable change to log) and there is already a section in ospf_receive_hello() to handle such changes: https://gitlab.nic.cz/labs/bird/-/commit/ae9ae864d3fec20a74ce2567536e186ce178d032 -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From wnt at btconnect.com Wed Mar 17 11:35:05 2021 From: wnt at btconnect.com (W Templeton) Date: Wed, 17 Mar 2021 10:35:05 +0000 Subject: Bird Centos 8 Replacement recommendations request Message-ID: Hiya Guys, Apologies if not the right approach/ protocol, do let me know what is if required. Asks: Pls provide.... 1.Details of what OS and version supported by Bird 2.Any OS preferences or best choice of useful. 3.Any views thoughts on below useful Our draft shortlist is Debian 10.7 Buster Ubuntu 20.04 LTS Leap 15.3 Note did not consider any of the BSD variants, which is an oversight so should be included Background We were close to productionising a network stack around number of sites using Bird2.07 as the Routing daemon on Centos 8. In light of the Centos changes are now looking for a replacement and would like to confirm what is supported by Bird as this is a mandatory prerequisite. Happy for call etc if easier. Thks in advance FYI -I did look at wiki FAQs and was semi generic and possibly not up to date Thks Will +44(0)7967 464459 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dm at belkam.com Wed Mar 17 11:42:37 2021 From: dm at belkam.com (Dmitry Melekhov) Date: Wed, 17 Mar 2021 14:42:37 +0400 Subject: Bird Centos 8 Replacement recommendations request In-Reply-To: References: Message-ID: <1f3b99dc-7e21-4dc2-08bb-4e5a7905e9b2@belkam.com> 17.03.2021 14:35, W Templeton ?????: > > We were close to productionising a network stack around number of > sites using Bird2.07 as the Routing daemon on Centos 8. Why don't use other RHEL clones? Oracle Alma ? From kees at nefos.nl Wed Mar 17 11:49:28 2021 From: kees at nefos.nl (Kees Meijs | Nefos) Date: Wed, 17 Mar 2021 11:49:28 +0100 Subject: Bird Centos 8 Replacement recommendations request In-Reply-To: References: Message-ID: <527c5dae-0949-ec16-a884-12216cde3773@nefos.nl> Hi Will, We proudly use BIRD2 on Debian stable in production with full feed BGP sessions and OSPF. Besides some kernel tweaking (needed in other distributions as well) no special requirements. Cheers, Kees On 17-03-2021 11:35, W Templeton wrote: > Our draft shortlist is > Debian 10.7 Buster > Ubuntu 20.04 LTS > Leap 15.3 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wnt at btconnect.com Wed Mar 17 11:53:31 2021 From: wnt at btconnect.com (W Templeton) Date: Wed, 17 Mar 2021 10:53:31 +0000 Subject: Bird Centos 8 Replacement recommendations request In-Reply-To: <527c5dae-0949-ec16-a884-12216cde3773@nefos.nl> References: , <527c5dae-0949-ec16-a884-12216cde3773@nefos.nl> Message-ID: Hiya Kees, Thks for quick response. Pls can you clarify 1.your OS version 2.Debian kernel tweaking Thks ________________________________ From: Kees Meijs | Nefos Sent: 17 March 2021 10:49 To: W Templeton ; BIRD Users Cc: Will Templeton Subject: Re: Bird Centos 8 Replacement recommendations request Hi Will, We proudly use BIRD2 on Debian stable in production with full feed BGP sessions and OSPF. Besides some kernel tweaking (needed in other distributions as well) no special requirements. Cheers, Kees On 17-03-2021 11:35, W Templeton wrote: Our draft shortlist is Debian 10.7 Buster Ubuntu 20.04 LTS Leap 15.3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kees at nefos.nl Wed Mar 17 11:59:42 2021 From: kees at nefos.nl (Kees Meijs | Nefos) Date: Wed, 17 Mar 2021 11:59:42 +0100 Subject: Bird Centos 8 Replacement recommendations request In-Reply-To: References: <527c5dae-0949-ec16-a884-12216cde3773@nefos.nl> Message-ID: Hi, On 17-03-2021 11:53, W Templeton wrote: > 1.your OS version Sure: > $ cat /etc/debian_version > 10.8 Basicly: Debian stable with current updates. > 2.Debian kernel tweaking Sure: > # cat 99-router.conf > # Enable IP forwarding for IPv4 and IPv6 AF. > net.ipv4.conf.all.forwarding = 1 > net.ipv6.conf.all.forwarding = 1 > > # Send ICMP errors from receiving interface and be a nice netizen. > net.ipv4.icmp_errors_use_inbound_ifaddr = 1 > > # Disable reverse path filtering. > net.ipv4.conf.all.rp_filter = 0 > net.ipv4.conf.default.rp_filter = 0 > > # Allow more IPv6 routes. > net.ipv6.route.max_size = 2147483647 > > # Allow more network neighbours. > net.ipv4.neigh.default.gc_thresh1=16384 > net.ipv4.neigh.default.gc_thresh2=32768 > net.ipv4.neigh.default.gc_thresh3=65536 > net.ipv6.neigh.default.gc_thresh1=16384 > net.ipv6.neigh.default.gc_thresh2=32768 > net.ipv6.neigh.default.gc_thresh3=65536 > # cat 99-tengige.conf > # 10GB/54MB (56623104) > net.core.rmem_max = 56623104 > net.core.wmem_max = 56623104 > net.core.rmem_default = 56623104 > net.core.wmem_default = 56623104 > net.core.optmem_max = 40960 > net.ipv4.tcp_rmem = 4096 87380 56623104 > net.ipv4.tcp_wmem = 4096 65536 56623104 > > # Increase number of incoming connections. The value can be raised to > bursts of request, default is 128 > net.core.somaxconn = 1024 > > # Increase number of incoming connections backlog, default is 1000 > net.core.netdev_max_backlog = 50000 > > # Maximum number of remembered connection requests, default is 128 > net.ipv4.tcp_max_syn_backlog = 30000 > > # Increase the tcp-time-wait buckets pool size to prevent simple DoS > attacks, default is 8192 > net.ipv4.tcp_max_tw_buckets = 2000000 > > # Recycle and Reuse TIME_WAIT sockets faster, default is 0 for both > net.ipv4.tcp_tw_recycle = 1 > net.ipv4.tcp_tw_reuse = 1 > > # Decrease TIME_WAIT seconds, default is 30 seconds > net.ipv4.tcp_fin_timeout = 10 > > # Tells the system whether it should start at the default window size > only for TCP connections > # that have been idle for too long, default is 1 > net.ipv4.tcp_slow_start_after_idle = 0 > > # If your servers talk UDP, also up these limits, default is 4096 > net.ipv4.udp_rmem_min = 8192 > net.ipv4.udp_wmem_min = 8192 > # cat 99-vrrp.conf > # For VRRP. > net.ipv4.ip_nonlocal_bind = 1 Cybertinus: maybe you can give insight in your kernel tweaks as well? (Probably very overlapping.) Cheers, Kees -------------- next part -------------- An HTML attachment was scrubbed... URL: From wnt at btconnect.com Wed Mar 17 12:16:27 2021 From: wnt at btconnect.com (W Templeton) Date: Wed, 17 Mar 2021 11:16:27 +0000 Subject: Bird Centos 8 Replacement recommendations request In-Reply-To: References: <527c5dae-0949-ec16-a884-12216cde3773@nefos.nl> , Message-ID: Thks, I'm new to Bird and certainly Debian so pls bear with me. So below shows a number of Debian network stack tweaks for your specific use case, is that fair ? With kernel tweaks to follow from Cybertinus @Cybertinus - That would be appreciated. FYI Our setup is Anycast based Bird stacks distributed globally linking directly from virtual image to DC hosting provider who we peer with using BGP, with own ASN & IPv4/24 & IPV6/28. Routing wise 1 IPV4 subnet & 1 IPV6 advertised out to DC Host provider to announce on Internet. So basic routing table. Our host address will grow over time up to max 253/4 ish running as dummy entries (in Centos) which are utilised by HAproxy. So a corner case that appears relatively simple routing Bird wise. Appreciate any thoughts etc. Will ________________________________ From: Kees Meijs | Nefos Sent: 17 March 2021 10:59 To: W Templeton ; BIRD Users Cc: Will Templeton Subject: Re: Bird Centos 8 Replacement recommendations request Hi, On 17-03-2021 11:53, W Templeton wrote: 1.your OS version Sure: $ cat /etc/debian_version 10.8 Basicly: Debian stable with current updates. 2.Debian kernel tweaking Sure: # cat 99-router.conf # Enable IP forwarding for IPv4 and IPv6 AF. net.ipv4.conf.all.forwarding = 1 net.ipv6.conf.all.forwarding = 1 # Send ICMP errors from receiving interface and be a nice netizen. net.ipv4.icmp_errors_use_inbound_ifaddr = 1 # Disable reverse path filtering. net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.rp_filter = 0 # Allow more IPv6 routes. net.ipv6.route.max_size = 2147483647 # Allow more network neighbours. net.ipv4.neigh.default.gc_thresh1=16384 net.ipv4.neigh.default.gc_thresh2=32768 net.ipv4.neigh.default.gc_thresh3=65536 net.ipv6.neigh.default.gc_thresh1=16384 net.ipv6.neigh.default.gc_thresh2=32768 net.ipv6.neigh.default.gc_thresh3=65536 # cat 99-tengige.conf # 10GB/54MB (56623104) net.core.rmem_max = 56623104 net.core.wmem_max = 56623104 net.core.rmem_default = 56623104 net.core.wmem_default = 56623104 net.core.optmem_max = 40960 net.ipv4.tcp_rmem = 4096 87380 56623104 net.ipv4.tcp_wmem = 4096 65536 56623104 # Increase number of incoming connections. The value can be raised to bursts of request, default is 128 net.core.somaxconn = 1024 # Increase number of incoming connections backlog, default is 1000 net.core.netdev_max_backlog = 50000 # Maximum number of remembered connection requests, default is 128 net.ipv4.tcp_max_syn_backlog = 30000 # Increase the tcp-time-wait buckets pool size to prevent simple DoS attacks, default is 8192 net.ipv4.tcp_max_tw_buckets = 2000000 # Recycle and Reuse TIME_WAIT sockets faster, default is 0 for both net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_tw_reuse = 1 # Decrease TIME_WAIT seconds, default is 30 seconds net.ipv4.tcp_fin_timeout = 10 # Tells the system whether it should start at the default window size only for TCP connections # that have been idle for too long, default is 1 net.ipv4.tcp_slow_start_after_idle = 0 # If your servers talk UDP, also up these limits, default is 4096 net.ipv4.udp_rmem_min = 8192 net.ipv4.udp_wmem_min = 8192 # cat 99-vrrp.conf # For VRRP. net.ipv4.ip_nonlocal_bind = 1 Cybertinus: maybe you can give insight in your kernel tweaks as well? (Probably very overlapping.) Cheers, Kees -------------- next part -------------- An HTML attachment was scrubbed... URL: From bird at robert-scheck.de Wed Mar 17 12:20:12 2021 From: bird at robert-scheck.de (Robert Scheck) Date: Wed, 17 Mar 2021 12:20:12 +0100 Subject: Bird Centos 8 Replacement recommendations request In-Reply-To: References: Message-ID: <20210317112012.GA25809@hurricane.linuxnetz.de> On Wed, 17 Mar 2021, W Templeton wrote: > We were close to productionising a network stack around number of sites using Bird2.07 as the Routing daemon on Centos 8. In light of the Centos changes are now looking for a replacement and would like to confirm what is supported by Bird as this is a mandatory prerequisite. How about some more patience and switching then from CentOS Linux to Rocky Linux? They are making a good progress and the project is driven by the original founder of the CentOS project. Their goal is to provide a drop-in replacement using one or two commands - and without system re-installation. Regards, Robert From md at Linux.IT Wed Mar 17 12:55:33 2021 From: md at Linux.IT (Marco d'Itri) Date: Wed, 17 Mar 2021 12:55:33 +0100 Subject: Bird Centos 8 Replacement recommendations request In-Reply-To: References: <527c5dae-0949-ec16-a884-12216cde3773@nefos.nl> Message-ID: On Mar 17, Kees Meijs | Nefos wrote: > > # Recycle and Reuse TIME_WAIT sockets faster, default is 0 for both > > net.ipv4.tcp_tw_recycle = 1 > > net.ipv4.tcp_tw_reuse = 1 This is ***BAD***. tcp_tw_recycle is toxic because it breaks NATs, and has even been removed from recent kernels. Do not EVER set it. tcp_tw_reuse is only relevant for outgoing connections. -- ciao, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From kees at nefos.nl Wed Mar 17 13:03:53 2021 From: kees at nefos.nl (Kees Meijs | Nefos) Date: Wed, 17 Mar 2021 13:03:53 +0100 Subject: Bird Centos 8 Replacement recommendations request In-Reply-To: References: <527c5dae-0949-ec16-a884-12216cde3773@nefos.nl> Message-ID: <53936d03-b2a2-4553-f4a6-314c2fa601eb@nefos.nl> Hi Marco, Thanks for pointing out the issue. I'll look into that. However there's no NAT applicable in our specific case. In addition: no trouble so far. But again, good to re-investigate. Maybe it's a nice side thread on the list as well. I'm curious about real life kernel tweaking at other's platform. Cheers, Kees On 17-03-2021 12:55, Marco d'Itri wrote: > This is ***BAD***. > tcp_tw_recycle is toxic because it breaks NATs, and has even been > removed from recent kernels. Do not EVER set it. > tcp_tw_reuse is only relevant for outgoing connections. From bird at bastelfreak.de Thu Mar 18 08:47:30 2021 From: bird at bastelfreak.de (Tim Meusel) Date: Thu, 18 Mar 2021 08:47:30 +0100 Subject: Bird Centos 8 Replacement recommendations request In-Reply-To: References: Message-ID: <184b4c5e-aacf-e7eb-eca0-81d70ce96695@bastelfreak.de> Hi, I've a wild mix of CentOS 7 and Arch Linux nodes running bird with haproxy. I'm in the process of migrating the CentOS boxes to Arch Linux. That just works ?\_(?)_/? cheers, Tim On 17.03.21 11:35, W Templeton wrote: > Hiya Guys, > > Apologies if not the right approach/ protocol, do let me know what is if required. > > Asks: Pls provide.... > 1.Details of what OS and version supported by Bird > 2.Any OS preferences or best choice of useful. > 3.Any views thoughts on below useful > > Our draft shortlist is > Debian 10.7 Buster > Ubuntu 20.04 LTS > Leap 15.3 > > Note did not consider any of the BSD variants, which is an oversight so should be included > > Background > We were close to productionising a network stack around number of sites using Bird2.07 as the Routing daemon on Centos 8. In light of the Centos changes are now looking for a replacement and would like to confirm what is supported by Bird as this is a mandatory prerequisite. > Happy for call etc if easier. Thks in advance > > FYI -I did look at wiki FAQs and was semi generic and possibly not up to date > > Thks > Will > +44(0)7967 464459 > -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature URL: From feela at network.cz Sun Mar 21 23:57:15 2021 From: feela at network.cz (Ondrej Filip) Date: Sun, 21 Mar 2021 23:57:15 +0100 Subject: BIRD 2.0.8 Message-ID: Hello! I have great news for you! My colleagues did a fantastic job and after a while we can present a new BIRD release - 2.0.8. Here is a list of changes: o Automatic channel reloads based on RPKI changes o Multiple static routes with the same network o Use bitmaps to keep track of exported routes o Per-channel debug flags o CLI commands show info from multiple protocols o Linux: IPv4 routes with IPv6 nexthops o Filter: Optimized redesign of prefix sets o Filter: Improved type checking of user filters o Filter: New src/dst accessors for Flowspec and SADR o Filter: New 'weight' route attribute o Filter: BGP path mask loop operator o Filter: Remove quitbird command o RIP: Demand circuit support (RFC 2091) o BGP: New 'allow as sets' and 'enforce first as' options o BGP: Support for BGP hostname capability o BGP: Support for MD5SIG with dynamic BGP o BFD: Optional separation of IPv4 / IPv6 BFD instances o BFD: Per-peer session options o RPKI: Allow build without libSSH o RPKI: New 'ignore max length' option o OSPF: Redesign of handling of unnumbered PtPs o OSPF: Allow key id 0 in authentication o Babel: Use onlink flag for routes with unreachable next hop o Many bugfixes Notes: Automatic channel reloads based on RPKI changes are enabled by default, but require import table enabled when used in BGP import filter. BIRD now uses bitmaps to keep track of exported routes instead of re-evaluation of export filters. That should improve speed and accuracy in route export handling during reconfiguration, but takes some more memory. Per-channel debug logging and some CLI commands (like 'show ospf neighbors') defaulting to all protocol instances lead to some minor changes in log and CLI output. Caution is recommended when logs or CLI output are monitored by scripts. So please test it, run it and write your feedback! Cheers Ondrej -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From bird at robert-scheck.de Mon Mar 22 00:26:26 2021 From: bird at robert-scheck.de (Robert Scheck) Date: Mon, 22 Mar 2021 00:26:26 +0100 Subject: BIRD 2.0.8 In-Reply-To: References: Message-ID: <20210321232626.GA17464@hurricane.linuxnetz.de> On Sun, 21 Mar 2021, Ondrej Filip wrote: > So please test it, run it and write your feedback! I'm sorry, but it looks like an old mistake [1] slipped in again: + ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --runstatedir=/run/bird configure: error: unrecognized option: `--runstatedir=/run/bird' Try `./configure --help' for more information [1] https://bird.network.cz/pipermail/bird-users/2019-August/013629.html Regards, Robert From feela at network.cz Mon Mar 22 00:39:53 2021 From: feela at network.cz (Ondrej Filip) Date: Mon, 22 Mar 2021 00:39:53 +0100 Subject: BIRD 2.0.8 In-Reply-To: <20210321232626.GA17464@hurricane.linuxnetz.de> References: <20210321232626.GA17464@hurricane.linuxnetz.de> Message-ID: On 22. 03. 21 0:26, Robert Scheck wrote: > On Sun, 21 Mar 2021, Ondrej Filip wrote: >> So please test it, run it and write your feedback! > > I'm sorry, but it looks like an old mistake [1] slipped in again: My fault, please reload the source again. :-( Ondrej > > + ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --runstatedir=/run/bird > configure: error: unrecognized option: `--runstatedir=/run/bird' > Try `./configure --help' for more information > > [1] https://bird.network.cz/pipermail/bird-users/2019-August/013629.html > > > Regards, > Robert > -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From santiago at crfreenet.org Mon Mar 22 04:38:50 2021 From: santiago at crfreenet.org (Ondrej Zajicek) Date: Mon, 22 Mar 2021 04:38:50 +0100 Subject: [PATCH v4 0/8] Add MAC authentication support to the Babel protocol In-Reply-To: <87v9a9td6r.fsf@toke.dk> References: <161072596935.33920.6744176530620496165.stgit@alrua-x1> <87v9a9td6r.fsf@toke.dk> Message-ID: <20210322033850.GJ3327@feanor.crfreenet.org> On Tue, Mar 02, 2021 at 11:15:24PM +0100, Toke H?iland-J?rgensen wrote: > Toke H?iland-J?rgensen writes: > > > This series adds MAC authentication support to the Babel protocol as specified > > in in RFC8967: > > > > https://www.rfc-editor.org/rfc/rfc8967 > > > > I have performed basic interoperability testing between this implementation and > > the current babeld HMAC implementation[1]. The two implementations were able to > > successfully exchange authenticated messages with both HMAC-256 and Blake2s-256 > > keys. > > > > Given the above, and the fact that the RFC was finally published at the the > > IETF, I believe this series is ready for merging (subject to review, of course). > > For those wanting to test the code, a version of Bird with this series applied > > is available on Github[2] for easy consumption. > > > > [1] https://github.com/jech/babeld/pull/52 > > [2] https://github.com/tohojo/bird/tree/babel-mac-04 > > > > Ping? Anyone had a chance to take a look at this? :) Hi Sorry for late response. Now with v2.0.8 released i plan to focus on merging this and other pending patches. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From sm at samip.fi Mon Mar 22 05:29:09 2021 From: sm at samip.fi (=?UTF-8?Q?Skyler_M=c3=a4ntysaari?=) Date: Mon, 22 Mar 2021 06:29:09 +0200 Subject: BIRD 2.0.8 In-Reply-To: References: Message-ID: Hello! When should there be a new Debian package built for it? Best regards, Skyler On 22/03/2021 0.57, Ondrej Filip wrote: > Hello! > I have great news for you! My colleagues did a fantastic job and after > a while we can present a new BIRD release - 2.0.8. Here is a list of > changes: > > ? o Automatic channel reloads based on RPKI changes > > ? o Multiple static routes with the same network > > ? o Use bitmaps to keep track of exported routes > > ? o Per-channel debug flags > > ? o CLI commands show info from multiple protocols > > ? o Linux: IPv4 routes with IPv6 nexthops > > ? o Filter: Optimized redesign of prefix sets > > ? o Filter: Improved type checking of user filters > > ? o Filter: New src/dst accessors for Flowspec and SADR > > ? o Filter: New 'weight' route attribute > > ? o Filter: BGP path mask loop operator > > ? o Filter: Remove quitbird command > > ? o RIP: Demand circuit support (RFC 2091) > > ? o BGP: New 'allow as sets' and 'enforce first as' options > > ? o BGP: Support for BGP hostname capability > > ? o BGP: Support for MD5SIG with dynamic BGP > > ? o BFD: Optional separation of IPv4 / IPv6 BFD instances > > ? o BFD: Per-peer session options > > ? o RPKI: Allow build without libSSH > > ? o RPKI: New 'ignore max length' option > > ? o OSPF: Redesign of handling of unnumbered PtPs > > ? o OSPF: Allow key id 0 in authentication > > ? o Babel: Use onlink flag for routes with unreachable next hop > > ? o Many bugfixes > > > > ? Notes: > > > > ? Automatic channel reloads based on RPKI changes are enabled by > ? default, > ?but require import table enabled when used in BGP import > ? filter. > > > > ? BIRD now uses bitmaps to keep track of exported routes instead of > > ? re-evaluation of export filters. That should improve speed and > ? accuracy in > ?route export handling during reconfiguration, but takes > ? some more memory. > > > > ? Per-channel debug logging and some CLI commands (like 'show ospf > ? neighbors') > ?defaulting to all protocol instances lead to some minor > ? changes in log and > ?CLI output. Caution is recommended when logs or > ? CLI output are monitored by > ?scripts. > > > > > So please test it, run it and write your feedback! > > Cheers > ????Ondrej > From fatal at mailbox.org Mon Mar 22 08:32:27 2021 From: fatal at mailbox.org (fatal) Date: Mon, 22 Mar 2021 08:32:27 +0100 Subject: BIRD 2.0.8 In-Reply-To: References: Message-ID: Hey, thanks for the new release, looking forward especially to the RPKI reload! Atm it seems like the debian repo is broken (even though 2.0.8 not being there yet as Skyler pointed out): W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://bird.network.cz/debian buster InRelease: The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key W: Failed to fetch https://bird.network.cz/debian/dists/buster/InRelease The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key Thanks and all the best! u. On 22.03.21 05:29, Skyler M?ntysaari wrote: > Hello! > > When should there be a new Debian package built for it? > > Best regards, > Skyler > > On 22/03/2021 0.57, Ondrej Filip wrote: >> Hello! >> I have great news for you! My colleagues did a fantastic job and after >> a while we can present a new BIRD release - 2.0.8. Here is a list of >> changes: >> >> ? o Automatic channel reloads based on RPKI changes >> >> ? o Multiple static routes with the same network >> >> ? o Use bitmaps to keep track of exported routes >> >> ? o Per-channel debug flags >> >> ? o CLI commands show info from multiple protocols >> >> ? o Linux: IPv4 routes with IPv6 nexthops >> >> ? o Filter: Optimized redesign of prefix sets >> >> ? o Filter: Improved type checking of user filters >> >> ? o Filter: New src/dst accessors for Flowspec and SADR >> >> ? o Filter: New 'weight' route attribute >> >> ? o Filter: BGP path mask loop operator >> >> ? o Filter: Remove quitbird command >> >> ? o RIP: Demand circuit support (RFC 2091) >> >> ? o BGP: New 'allow as sets' and 'enforce first as' options >> >> ? o BGP: Support for BGP hostname capability >> >> ? o BGP: Support for MD5SIG with dynamic BGP >> >> ? o BFD: Optional separation of IPv4 / IPv6 BFD instances >> >> ? o BFD: Per-peer session options >> >> ? o RPKI: Allow build without libSSH >> >> ? o RPKI: New 'ignore max length' option >> >> ? o OSPF: Redesign of handling of unnumbered PtPs >> >> ? o OSPF: Allow key id 0 in authentication >> >> ? o Babel: Use onlink flag for routes with unreachable next hop >> >> ? o Many bugfixes >> >> >> >> ? Notes: >> >> >> >> ? Automatic channel reloads based on RPKI changes are enabled by >> ? default, >> ?but require import table enabled when used in BGP import >> ? filter. >> >> >> >> ? BIRD now uses bitmaps to keep track of exported routes instead of >> >> ? re-evaluation of export filters. That should improve speed and >> ? accuracy in >> ?route export handling during reconfiguration, but takes >> ? some more memory. >> >> >> >> ? Per-channel debug logging and some CLI commands (like 'show ospf >> ? neighbors') >> ?defaulting to all protocol instances lead to some minor >> ? changes in log and >> ?CLI output. Caution is recommended when logs or >> ? CLI output are monitored by >> ?scripts. >> >> >> >> >> So please test it, run it and write your feedback! >> >> Cheers >> ????Ondrej >> From alarig at swordarmor.fr Mon Mar 22 13:21:08 2021 From: alarig at swordarmor.fr (Alarig Le Lay) Date: Mon, 22 Mar 2021 13:21:08 +0100 Subject: BIRD 2.0.8 In-Reply-To: References: Message-ID: Thanks a lot for the new release! I?ve upgraded a RR and a router, the build and the restart didn?t hit any issue so far. Cheers, -- Alarig From toke at toke.dk Mon Mar 22 13:50:34 2021 From: toke at toke.dk (Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?=) Date: Mon, 22 Mar 2021 13:50:34 +0100 Subject: [PATCH v4 0/8] Add MAC authentication support to the Babel protocol In-Reply-To: <20210322033850.GJ3327@feanor.crfreenet.org> References: <161072596935.33920.6744176530620496165.stgit@alrua-x1> <87v9a9td6r.fsf@toke.dk> <20210322033850.GJ3327@feanor.crfreenet.org> Message-ID: <87ft0n8i91.fsf@toke.dk> Ondrej Zajicek writes: > On Tue, Mar 02, 2021 at 11:15:24PM +0100, Toke H?iland-J?rgensen wrote: >> Toke H?iland-J?rgensen writes: >> >> > This series adds MAC authentication support to the Babel protocol as specified >> > in in RFC8967: >> > >> > https://www.rfc-editor.org/rfc/rfc8967 >> > >> > I have performed basic interoperability testing between this implementation and >> > the current babeld HMAC implementation[1]. The two implementations were able to >> > successfully exchange authenticated messages with both HMAC-256 and Blake2s-256 >> > keys. >> > >> > Given the above, and the fact that the RFC was finally published at the the >> > IETF, I believe this series is ready for merging (subject to review, of course). >> > For those wanting to test the code, a version of Bird with this series applied >> > is available on Github[2] for easy consumption. >> > >> > [1] https://github.com/jech/babeld/pull/52 >> > [2] https://github.com/tohojo/bird/tree/babel-mac-04 >> > >> >> Ping? Anyone had a chance to take a look at this? :) > > Hi > > Sorry for late response. Now with v2.0.8 released i plan to focus on > merging this and other pending patches. Cool! (I had hoped it would make it into 2.0.8, but ah well, no biggie :)) -Toke From jared at jared.kiev.ua Mon Mar 22 21:29:46 2021 From: jared at jared.kiev.ua (Pavlo Astakhov) Date: Mon, 22 Mar 2021 21:29:46 +0100 Subject: CentOS to Debian migration issue Message-ID: Hello, all I got a weird question. We recently migrated two our routers from CentOS 7 to Debian 10, installed Bird, placed config files back - and since then we are observing BGP flaps. Moreover, flaps are observed on IPv6 peers only: Name?????? Proto????? Table????? State Since???????? Info device1??? Device???? ---??????? up???? 2021-03-18 15:42:27 direct1??? Direct???? ---??????? up???? 2021-03-18 15:42:27 kernel1??? Kernel???? master4??? up???? 2021-03-18 15:42:27 kernel2??? Kernel???? master6??? up???? 2021-03-18 15:42:27 static1??? Static???? master4??? up???? 2021-03-18 15:42:27 static2??? Static???? master6??? up???? 2021-03-18 15:42:27 UPLINK???? BGP??????? ---??????? up???? 2021-03-18 15:42:31 Established UPLINKv6?? BGP??????? ---??????? up???? 2021-03-22 21:11:12 Established AR1??????? BGP??????? ---??????? up???? 2021-03-18 15:42:31 Established AR1v6????? BGP??????? ---??????? up???? 2021-03-19 23:42:55 Established AR2??????? BGP??????? ---??????? up???? 2021-03-18 15:42:28 Established AR2v6????? BGP??????? ---??????? up???? 2021-03-20 15:37:38 Established BR2??????? BGP??????? ---??????? up???? 2021-03-18 15:42:28 Established BR2v6????? BGP??????? ---??????? up???? 2021-03-21 11:03:33 Established ospf4????? OSPF?????? master4??? up???? 2021-03-18 15:42:27 Running ospf6????? OSPF?????? master6??? up???? 2021-03-18 15:42:27 Running Flaps are unregular, currently we saw no coincedences with anything. The network is stable, our and peers configs were not changed, Bird version too (2.0.7 on both CentOS and Debian). The only message about this in logs is hold-related: 2021-03-22 21:01:10 Kernel dropped some netlink messages, will resync on next scan. 2021-03-22 21:04:33 Kernel dropped some netlink messages, will resync on next scan. 2021-03-22 21:06:10 Kernel dropped some netlink messages, will resync on next scan. 2021-03-22 21:10:12 UPLINKv6: Error: Hold timer expired 2021-03-22 21:10:13 Kernel dropped some netlink messages, will resync on next scan. 2021-03-22 21:10:15 Kernel dropped some netlink messages, will resync on next scan. 2021-03-22 21:10:16 Kernel dropped some netlink messages, will resync on next scan. 2021-03-22 21:10:16 Kernel dropped some netlink messages, will resync on next scan. Could you please suggest some way to go except of returning to CentOS? Thank you in advance. _-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From nat at nat.moe Mon Mar 22 21:49:20 2021 From: nat at nat.moe (Honghao Zeng) Date: Mon, 22 Mar 2021 16:49:20 -0400 Subject: CentOS to Debian migration issue In-Reply-To: References: Message-ID: <30F8853A-2114-4D20-8846-F2836C1629E0@nat.moe> We had a similar issue when we migrated to debain a while back; flapping sessions, weird timeouts, etc. Tweaking `net.ipv6.route.max_size' helped. Some clues: - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861115#10 - https://bird.network.cz/pipermail/bird-users/2020-February/014270.html Regards, Honghao Zeng > On Mar 22, 2021, at 4:29 PM, Pavlo Astakhov wrote: > > Hello, all > > I got a weird question. We recently migrated two our routers from CentOS 7 to Debian 10, installed Bird, placed config files back - and since then we are observing BGP flaps. > > Moreover, flaps are observed on IPv6 peers only: > > Name Proto Table State Since Info > device1 Device --- up 2021-03-18 15:42:27 > direct1 Direct --- up 2021-03-18 15:42:27 > kernel1 Kernel master4 up 2021-03-18 15:42:27 > kernel2 Kernel master6 up 2021-03-18 15:42:27 > static1 Static master4 up 2021-03-18 15:42:27 > static2 Static master6 up 2021-03-18 15:42:27 > UPLINK BGP --- up 2021-03-18 15:42:31 Established > UPLINKv6 BGP --- up 2021-03-22 21:11:12 Established > AR1 BGP --- up 2021-03-18 15:42:31 Established > AR1v6 BGP --- up 2021-03-19 23:42:55 Established > AR2 BGP --- up 2021-03-18 15:42:28 Established > AR2v6 BGP --- up 2021-03-20 15:37:38 Established > BR2 BGP --- up 2021-03-18 15:42:28 Established > BR2v6 BGP --- up 2021-03-21 11:03:33 Established > ospf4 OSPF master4 up 2021-03-18 15:42:27 Running > ospf6 OSPF master6 up 2021-03-18 15:42:27 Running > > Flaps are unregular, currently we saw no coincedences with anything. The network is stable, our and peers configs were not changed, Bird version too (2.0.7 on both CentOS and Debian). > > The only message about this in logs is hold-related: > > 2021-03-22 21:01:10 Kernel dropped some netlink messages, will resync on next scan. > 2021-03-22 21:04:33 Kernel dropped some netlink messages, will resync on next scan. > 2021-03-22 21:06:10 Kernel dropped some netlink messages, will resync on next scan. > 2021-03-22 21:10:12 UPLINKv6: Error: Hold timer expired > 2021-03-22 21:10:13 Kernel dropped some netlink messages, will resync on next scan. > 2021-03-22 21:10:15 Kernel dropped some netlink messages, will resync on next scan. > 2021-03-22 21:10:16 Kernel dropped some netlink messages, will resync on next scan. > 2021-03-22 21:10:16 Kernel dropped some netlink messages, will resync on next scan. > > Could you please suggest some way to go except of returning to CentOS? > > Thank you in advance. > > -- From jared at jared.kiev.ua Mon Mar 22 22:02:35 2021 From: jared at jared.kiev.ua (Pavlo Astakhov) Date: Mon, 22 Mar 2021 22:02:35 +0100 Subject: CentOS to Debian migration issue In-Reply-To: <30F8853A-2114-4D20-8846-F2836C1629E0@nat.moe> References: <30F8853A-2114-4D20-8846-F2836C1629E0@nat.moe> Message-ID: Hello Honghao, Thank you a lot, just set net.ipv6.route.max_size = 1073741824, will look at it now. _-- --------------- Original Message --------------- From: Honghao Zeng [nat at nat.moe] Sent: Mon, 22 Mar 2021 16:49:20 -0400 To: jared at jared.kiev.ua Subject: Re: CentOS to Debian migration issue > We had a similar issue when we migrated to debain a while back; flapping sessions, weird timeouts, etc. Tweaking `net.ipv6.route.max_size' helped. Some clues: > > - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861115#10 > - https://bird.network.cz/pipermail/bird-users/2020-February/014270.html > > Regards, > Honghao Zeng > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kees at nefos.nl Mon Mar 22 22:10:48 2021 From: kees at nefos.nl (Kees Meijs | Nefos) Date: Mon, 22 Mar 2021 22:10:48 +0100 Subject: CentOS to Debian migration issue In-Reply-To: References: <30F8853A-2114-4D20-8846-F2836C1629E0@nat.moe> Message-ID: Hi Pavlo, Please refer to the sysctl settings in a previous thread about CentOS8 replacement; maybe there's more to check out. K. On 22-03-2021 22:02, Pavlo Astakhov wrote: > Thank you a lot, just set net.ipv6.route.max_size = 1073741824, will > look at it now. From stefan.plug at megaport.com Tue Mar 23 16:51:45 2021 From: stefan.plug at megaport.com (Stefan Plug) Date: Tue, 23 Mar 2021 16:51:45 +0100 Subject: BIRD 2.0.8 In-Reply-To: References: Message-ID: <3640C81F-39A3-4DA8-8774-FFF0AA4B2500@megaport.com> Hi all, Thank you all for the hard work! I was just testing this in the lab for: o Automatic channel reloads based on RPKI changes Which to me sounds like we do not have to do ?birdc reload in all? anymore whenever ROAs change, but it doesn't seem to work for me yet :( Am I wrong in thinking that this fixed that or am I doing something wrong? If this is indeed is supposed to work as I think it is but isn?t then I'll open up a new thread :) Kind regards, Stefan -- Stefan Plug Network Engineer (EU) Phone: +49 160 2504854 ECIX, a Megaport company PEERING GmbH Tauentzienstra?e 11 10789 Berlin Germany Office: +49 30 233 24 16-0 Web: www.ecix.net Sitz der Gesellschaft: Berlin, Germany. Registergericht: Amtsgericht Charlottenburg, HRB 97752B Vertretungsberechtigte Gescha?ftsfu?hrung: Vincent English, Bevan Slattery, Prokuristen: Stefan Wahl This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient please delete it and notify the sender. From stefan.plug at megaport.com Tue Mar 23 18:34:09 2021 From: stefan.plug at megaport.com (Stefan Plug) Date: Tue, 23 Mar 2021 18:34:09 +0100 Subject: BIRD 2.0.8 In-Reply-To: <3640C81F-39A3-4DA8-8774-FFF0AA4B2500@megaport.com> References: <3640C81F-39A3-4DA8-8774-FFF0AA4B2500@megaport.com> Message-ID: <04E733BB-014D-4933-B84D-4179408EC159@megaport.com> Hi all Never mind, I found that I should also read the notes :D Notes: Automatic channel reloads based on RPKI changes are enabled by default, but require import table enabled when used in BGP import filter. Looks like this did the trick! Thanks again for the awesome work! -- Stefan Plug Network Engineer (EU) Phone: +49 160 2504854 ECIX, a Megaport company PEERING GmbH Tauentzienstra?e 11 10789 Berlin Germany Office: +49 30 233 24 16-0 Web: www.ecix.net Sitz der Gesellschaft: Berlin, Germany. Registergericht: Amtsgericht Charlottenburg, HRB 97752B Vertretungsberechtigte Gescha?ftsfu?hrung: Vincent English, Bevan Slattery, Prokuristen: Stefan Wahl This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient please delete it and notify the sender. > On 23. Mar 2021, at 16:51, Stefan Plug wrote: > > Hi all, > > Thank you all for the hard work! > > I was just testing this in the lab for: > o Automatic channel reloads based on RPKI changes > > Which to me sounds like we do not have to do ?birdc reload in all? anymore whenever ROAs change, but it doesn't seem to work for me yet :( > Am I wrong in thinking that this fixed that or am I doing something wrong? > > If this is indeed is supposed to work as I think it is but isn?t then I'll open up a new thread :) > > Kind regards, > > Stefan > > -- > Stefan Plug > Network Engineer (EU) > > Phone: +49 160 2504854 > > ECIX, a Megaport company > PEERING GmbH > Tauentzienstra?e 11 > 10789 Berlin Germany > > Office: +49 30 233 24 16-0 > Web: www.ecix.net > > Sitz der Gesellschaft: Berlin, Germany. Registergericht: Amtsgericht Charlottenburg, HRB 97752B > Vertretungsberechtigte Gescha?ftsfu?hrung: Vincent English, Bevan Slattery, Prokuristen: Stefan Wahl > This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient please delete it and > notify the sender. > > From santiago at crfreenet.org Tue Mar 23 19:02:39 2021 From: santiago at crfreenet.org (Ondrej Zajicek) Date: Tue, 23 Mar 2021 19:02:39 +0100 Subject: BIRD 2.0.8 In-Reply-To: <04E733BB-014D-4933-B84D-4179408EC159@megaport.com> References: <3640C81F-39A3-4DA8-8774-FFF0AA4B2500@megaport.com> <04E733BB-014D-4933-B84D-4179408EC159@megaport.com> Message-ID: <20210323180239.GK3327@feanor.crfreenet.org> On Tue, Mar 23, 2021 at 06:34:09PM +0100, Stefan Plug wrote: > Hi all > > Never mind, I found that I should also read the notes :D > Notes: > > Automatic channel reloads based on RPKI changes are enabled by default, > but require import table enabled when used in BGP import filter. > Looks like this did the trick! Hi Yes, you should also get warning ("Automatic RPKI reload not active for import") when run without import table enabled. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From bernat at luffy.cx Tue Mar 23 19:51:00 2021 From: bernat at luffy.cx (Vincent Bernat) Date: Tue, 23 Mar 2021 19:51:00 +0100 Subject: BIRD 2.0.8 In-Reply-To: <20210323180239.GK3327@feanor.crfreenet.org> (Ondrej Zajicek's message of "Tue, 23 Mar 2021 19:02:39 +0100") References: <3640C81F-39A3-4DA8-8774-FFF0AA4B2500@megaport.com> <04E733BB-014D-4933-B84D-4179408EC159@megaport.com> <20210323180239.GK3327@feanor.crfreenet.org> Message-ID: ? 23 mars 2021 19:02 +01, Ondrej Zajicek: >> Never mind, I found that I should also read the notes :D >> Notes: >> >> Automatic channel reloads based on RPKI changes are enabled by default, >> but require import table enabled when used in BGP import filter. >> Looks like this did the trick! > Yes, you should also get warning ("Automatic RPKI reload not active for import") > when run without import table enabled. Hey! How does `import table yes` interacts with `import keep filtered`? They look like the same, except the former is BGP specific. -- It usually takes more than three weeks to prepare a good impromptu speech. -- Mark Twain From santiago at crfreenet.org Wed Mar 24 03:03:38 2021 From: santiago at crfreenet.org (Ondrej Zajicek) Date: Wed, 24 Mar 2021 03:03:38 +0100 Subject: BIRD 2.0.8 In-Reply-To: References: <3640C81F-39A3-4DA8-8774-FFF0AA4B2500@megaport.com> <04E733BB-014D-4933-B84D-4179408EC159@megaport.com> <20210323180239.GK3327@feanor.crfreenet.org> Message-ID: <20210324020338.GL3327@feanor.crfreenet.org> On Tue, Mar 23, 2021 at 07:51:00PM +0100, Vincent Bernat wrote: > >> Never mind, I found that I should also read the notes :D > >> Notes: > >> > >> Automatic channel reloads based on RPKI changes are enabled by default, > >> but require import table enabled when used in BGP import filter. > >> Looks like this did the trick! > > > Yes, you should also get warning ("Automatic RPKI reload not active for import") > > when run without import table enabled. > > Hey! > > How does `import table yes` interacts with `import keep filtered`? They > look like the same, except the former is BGP specific. Hi They are two different ways to get similar results. The 'import keep filtered' keeps filtered routes in main table, while 'import table' keeps all pre-policy BGP routes in separate per-channel table. The 'import keep filtered' uses less memory (each received route is stored one times), while 'import table' stores accepted routes two times (pre-policy and post-policy). Main advantage of 'import table' is that it allows reloading import (e.g. after change of import filter/policy) without externally visible behavior (sending route refresh to peer), while 'import keep filtered' just allows examining rejected routes. They do not interact, you can enable both, but then you end with keeping each received route two times. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From sm at samip.fi Wed Mar 24 06:03:57 2021 From: sm at samip.fi (=?UTF-8?Q?Skyler_M=c3=a4ntysaari?=) Date: Wed, 24 Mar 2021 07:03:57 +0200 Subject: BIRD 2.0.8 In-Reply-To: References: Message-ID: <12d45fd0-922e-7b08-67ed-ca5eda82a052@samip.fi> Hi, Who is responsible for the Debian packages at the moment? I couldn't find the build scripts for those at gitlab.nic.cz and would like to get them so I can setup mips64 and mipsel architecture deb builds. Best regards, Skyler On 22/03/2021 9.32, fatal wrote: > Hey, > > thanks for the new release, looking forward especially to the RPKI > reload! > > Atm it seems like the debian repo is broken (even though 2.0.8 not > being there yet as Skyler pointed out): > > W: An error occurred during the signature verification. The repository > is not updated and the previous index files will be used. GPG error: > https://bird.network.cz/debian buster InRelease: The following > signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG > Automatic Signing Key > > W: Failed to fetch > https://bird.network.cz/debian/dists/buster/InRelease ?The following > signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG > Automatic Signing Key > > Thanks and all the best! > > u. > > > > On 22.03.21 05:29, Skyler M?ntysaari wrote: >> Hello! >> >> When should there be a new Debian package built for it? >> >> Best regards, >> Skyler >> >> On 22/03/2021 0.57, Ondrej Filip wrote: >>> Hello! >>> I have great news for you! My colleagues did a fantastic job and after >>> a while we can present a new BIRD release - 2.0.8. Here is a list of >>> changes: >>> >>> ?? o Automatic channel reloads based on RPKI changes >>> >>> ?? o Multiple static routes with the same network >>> >>> ?? o Use bitmaps to keep track of exported routes >>> >>> ?? o Per-channel debug flags >>> >>> ?? o CLI commands show info from multiple protocols >>> >>> ?? o Linux: IPv4 routes with IPv6 nexthops >>> >>> ?? o Filter: Optimized redesign of prefix sets >>> >>> ?? o Filter: Improved type checking of user filters >>> >>> ?? o Filter: New src/dst accessors for Flowspec and SADR >>> >>> ?? o Filter: New 'weight' route attribute >>> >>> ?? o Filter: BGP path mask loop operator >>> >>> ?? o Filter: Remove quitbird command >>> >>> ?? o RIP: Demand circuit support (RFC 2091) >>> >>> ?? o BGP: New 'allow as sets' and 'enforce first as' options >>> >>> ?? o BGP: Support for BGP hostname capability >>> >>> ?? o BGP: Support for MD5SIG with dynamic BGP >>> >>> ?? o BFD: Optional separation of IPv4 / IPv6 BFD instances >>> >>> ?? o BFD: Per-peer session options >>> >>> ?? o RPKI: Allow build without libSSH >>> >>> ?? o RPKI: New 'ignore max length' option >>> >>> ?? o OSPF: Redesign of handling of unnumbered PtPs >>> >>> ?? o OSPF: Allow key id 0 in authentication >>> >>> ?? o Babel: Use onlink flag for routes with unreachable next hop >>> >>> ?? o Many bugfixes >>> >>> >>> >>> ?? Notes: >>> >>> >>> >>> ?? Automatic channel reloads based on RPKI changes are enabled by >>> ?? default, >>> ??but require import table enabled when used in BGP import >>> ?? filter. >>> >>> >>> >>> ?? BIRD now uses bitmaps to keep track of exported routes instead of >>> >>> ?? re-evaluation of export filters. That should improve speed and >>> ?? accuracy in >>> ??route export handling during reconfiguration, but takes >>> ?? some more memory. >>> >>> >>> >>> ?? Per-channel debug logging and some CLI commands (like 'show ospf >>> ?? neighbors') >>> ??defaulting to all protocol instances lead to some minor >>> ?? changes in log and >>> ??CLI output. Caution is recommended when logs or >>> ?? CLI output are monitored by >>> ??scripts. >>> >>> >>> >>> >>> So please test it, run it and write your feedback! >>> >>> Cheers >>> ?????Ondrej >>> From santiago at crfreenet.org Wed Mar 24 12:56:27 2021 From: santiago at crfreenet.org (Ondrej Zajicek) Date: Wed, 24 Mar 2021 12:56:27 +0100 Subject: BIRD 2.0.8 In-Reply-To: <12d45fd0-922e-7b08-67ed-ca5eda82a052@samip.fi> References: <12d45fd0-922e-7b08-67ed-ca5eda82a052@samip.fi> Message-ID: <20210324115627.GM3327@feanor.crfreenet.org> On Wed, Mar 24, 2021 at 07:03:57AM +0200, Skyler M?ntysaari wrote: > Hi, > > Who is responsible for the Debian packages at the moment? > I couldn't find the build scripts for those at gitlab.nic.cz and would > like to get them so I can setup mips64 and mipsel architecture deb builds. Hi Debian packages on bird.network.cz are done by Ondrej Sury, who is also Debian maintainer for BIRD. Used build scripts are (AFAIK) directly from Debian. In future, we want to add buiding of distribution packages to our CI code, so we would have all packages ready together with src release, but we are not there yet. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From mail at peter-hurtenbach.de Wed Mar 24 20:39:07 2021 From: mail at peter-hurtenbach.de (Peter Hurtenbach) Date: Wed, 24 Mar 2021 20:39:07 +0100 Subject: BIRD 2.0.8 In-Reply-To: <12d45fd0-922e-7b08-67ed-ca5eda82a052@samip.fi> References: <12d45fd0-922e-7b08-67ed-ca5eda82a052@samip.fi> Message-ID: <85b48366-26fd-b106-c9cb-cf7842dce0ed@peter-hurtenbach.de> Hi, You can take a look at the Debian Git repository: https://salsa.debian.org/debian/bird2 Regards, Peter On 3/24/21 6:03 AM, Skyler M?ntysaari wrote: > Hi, > > Who is responsible for the Debian packages at the moment? > I couldn't find the build scripts for those at gitlab.nic.cz and would > like to get them so I can setup mips64 and mipsel architecture deb builds. > > Best regards, > Skyler From lists at manon.de Thu Mar 25 02:31:15 2021 From: lists at manon.de (Manon Goo) Date: Thu, 25 Mar 2021 01:31:15 +0000 Subject: recursive next-hop from filter Message-ID: <20210325013115.Horde.vybICFDa0aKczm82FS9Znyz@portal.dg-i.net> Hallo, Is it possible to set or modify a recursive next-hop and the loop-up table for a route from a filter or function ? Kind regards, Manon From maria.matejka at nic.cz Thu Mar 25 08:12:40 2021 From: maria.matejka at nic.cz (Maria Matejka) Date: Thu, 25 Mar 2021 08:12:40 +0100 Subject: recursive next-hop from filter In-Reply-To: <20210325013115.Horde.vybICFDa0aKczm82FS9Znyz@portal.dg-i.net> References: <20210325013115.Horde.vybICFDa0aKczm82FS9Znyz@portal.dg-i.net> Message-ID: <62cf1bcd-d109-ba8f-f0d8-53cd09b202cf@nic.cz> Hello! If I understand your query corretly, you want to change the "igp table" setting on a per-route basis in filters. This is currently impossible due to the architecture of recursive nexthop resolution. Could you please describe a use case for that? We may find another way to get you to your goal or get a good reason to change the implementation. Maria On 3/25/21 2:31 AM, Manon Goo wrote: > > Hallo, > > > Is it possible to set or modify a recursive? next-hop and the loop-up > table for a route from a filter or function ? > > Kind regards, > Manon > > > > > From lists at manon.de Thu Mar 25 13:50:52 2021 From: lists at manon.de (Manon Goo) Date: Thu, 25 Mar 2021 12:50:52 +0000 Subject: recursive next-hop from filter In-Reply-To: <62cf1bcd-d109-ba8f-f0d8-53cd09b202cf@nic.cz> References: <20210325013115.Horde.vybICFDa0aKczm82FS9Znyz@portal.dg-i.net> <62cf1bcd-d109-ba8f-f0d8-53cd09b202cf@nic.cz> Message-ID: <20210325125052.Horde.vSBQO_nuQl4qRC0nkimSF3x@portal.dg-i.net> Dear Maria, Thanks alot for taking your time for my iussue. let me describe my usecase: we are using carp(4) with freebsd as our first-hop redundancy protocol. I want to have the primary carp node announce his routes with a preferred priority (lower OSPF ospf_metric1 or BGP Community that is evaluated by peer). This works well for a scenario where we are using static recursive routes, but not as well when using routes learnt from an other router. We have two routers each with an interface in our LAN, these routers share one IP address that is installed with the freebsd carp feature (similar to vrrp). This IP Address can be either in MASTER or BACKUP state. When the carp-address is in MASTER state, the Address is learnt via protocol KERNEL and the loopback interface; when the carp-address is in BACKUP state the the Address is learnt via protocol DIRECT and the interface connected to the MASTER. We install the routes with our carp address as recursive next-hop. And when exporting the routes to the OSPF or BGP peers we apply an export filter that checks if ifname is loopback and prefers the routes accordingly: protocol static static_recursive_carp { preference 400; route 192.168.123.0/24 recursive 1.1.1.1 route 0.0.0.0/0 recursive 1.1.1.1 } protocol ospf OSPF_1 { export filter ospf_preferr_carp_master; [...] } filter ospf_preferr_carp_master; { if proto = "static_recursive_carp" && net ~ [ 0.0.0.0/0, 192.168.123.0/24 ] then { if defined(ifname) && ifname = "lo0" then { ospf_metric1 = 10; accept; } ospf_metric1 = 32767; accept; } reject; } filter bgp_preferr_carp_master; { if proto = "static_recursive_carp" && net ~ [ 0.0.0.0/0, 192.168.123.0/24 ] then { if defined(ifname) && ifname = "lo0" then { bgp_local_pref = 120; bgp_community.add(COMM_LP_PREFERRED_120); accept; } bgp_local_pref = 80; bgp_community.add(COMM_LP_PREFERRED_80); accept; } reject; } When the carp BACKUP is promoted to MASTER, the recursive route is re-evaluated by bird and the export filter is re-applied, the new ifname is lo0 and the route is announced with the preferable metric or local pref. I would like to be able to add this behaviour routes learnt from an other protocol. This works with BGP but is rather ugly: - the bgp speaker must announce the route with bgp_next_hop set to the carp address of the bgp peer - the peer must have "gateway recursive" set For OSPF this does not seam possible. What would be helpfull form me: to be able to set a recusive route from a filter or function with a statement like set_recursive(gw, table) or to have an other measure to update routes in case of an event. Perhaps to allow to set a dependency to an other route on a route. And reevaluate the route if the depending route changes. and to have the possibility to access the depending routes attributes perhaps like follows: filter myfilter { set_depend(1.1.1.1, "my_tracking_table_v4") bgp_local_pref = get_depend.bgp_local_pref + 10 } Kind regards, and thanks again for taking your time. Manon Quoting Maria Matejka : > Hello! > > If I understand your query corretly, you want to change the "igp > table" setting on a per-route basis in filters. This is currently > impossible due to the architecture of recursive nexthop resolution. > > Could you please describe a use case for that? We may find another > way to get you to your goal or get a good reason to change the > implementation. > > Maria > > On 3/25/21 2:31 AM, Manon Goo wrote: >> >> Hallo, >> >> >> Is it possible to set or modify a recursive? next-hop and the >> loop-up table for a route from a filter or function ? >> >> Kind regards, >> Manon >> >> >> >> >> From ch at ntrv.dk Thu Mar 25 14:33:40 2021 From: ch at ntrv.dk (Chriztoffer Hansen) Date: Thu, 25 Mar 2021 14:33:40 +0100 Subject: BIRD 2.0.8 In-Reply-To: <85b48366-26fd-b106-c9cb-cf7842dce0ed@peter-hurtenbach.de> References: <12d45fd0-922e-7b08-67ed-ca5eda82a052@samip.fi> <85b48366-26fd-b106-c9cb-cf7842dce0ed@peter-hurtenbach.de> Message-ID: On Wed, 24 Mar 2021 at 20:39, Peter Hurtenbach wrote: > You can take a look at the Debian Git repository: > https://salsa.debian.org/debian/bird2 I suppose the CI/CD script is "slightly" outdated... https://salsa.debian.org/debian/bird2/-/blob/master/.gitlab-ci.yml (No mention of FreeBSD 12, Debian buster, Ubuntu > 16.04, etc.) /CH From santiago at crfreenet.org Thu Mar 25 14:59:02 2021 From: santiago at crfreenet.org (Ondrej Zajicek) Date: Thu, 25 Mar 2021 14:59:02 +0100 Subject: BIRD 2.0.8 In-Reply-To: References: <12d45fd0-922e-7b08-67ed-ca5eda82a052@samip.fi> <85b48366-26fd-b106-c9cb-cf7842dce0ed@peter-hurtenbach.de> Message-ID: <20210325135902.GN3327@feanor.crfreenet.org> On Thu, Mar 25, 2021 at 02:33:40PM +0100, Chriztoffer Hansen wrote: > On Wed, 24 Mar 2021 at 20:39, Peter Hurtenbach wrote: > > You can take a look at the Debian Git repository: > > https://salsa.debian.org/debian/bird2 > > I suppose the CI/CD script is "slightly" outdated... > https://salsa.debian.org/debian/bird2/-/blob/master/.gitlab-ci.yml (No > mention of FreeBSD 12, Debian buster, Ubuntu > 16.04, etc.) This CI/CD script is from upstream, so will be updated with transition to 2.0.8 -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From n.vanlueck at techkings.de Fri Mar 26 08:47:02 2021 From: n.vanlueck at techkings.de (=?utf-8?q?Nils=20van=20L=c3=bcck?=) Date: Fri, 26 Mar 2021 07:47:02 +0000 Subject: Foreign upstream gateway for remote maintenance Message-ID: Hello! I am using the latest Bird version from the git repo under Debian. I have one dedicated NIC for the LAN, one dedicated NIC for BGP sessions and one NIC with an IP from a foreign ASN for remote maintenance. How can I make the routed traffic go through Bird but still connect to a foreign gateway via SSH through another NIC? Also the operating system updates (apt-get) should run over the third NIC and not over the bird routes. NIC 1: LAN / OSPF NIC 2: BGP / Peering / routed traffic over bird NIC 3: foreign gateway fo remote maintenance of the routers debian instance Regards, Nils van L?ck -------------- next part -------------- An HTML attachment was scrubbed... URL: From bena at spreadshirt.net Fri Mar 26 09:58:17 2021 From: bena at spreadshirt.net (Bernd Naumann) Date: Fri, 26 Mar 2021 09:58:17 +0100 Subject: Foreign upstream gateway for remote maintenance In-Reply-To: <5f985bb6-33c7-46b5-8e96-af928926ff32@spreadshirt.net> References: <5f985bb6-33c7-46b5-8e96-af928926ff32@spreadshirt.net> Message-ID: Good morning Nils, On 26.03.21 08:47, Nils van L?ck wrote: > Hello! > > I am using the latest Bird version from the git repo under Debian. I > have one dedicated NIC for the LAN, one dedicated NIC for BGP sessions > and one NIC with an IP from a foreign ASN for remote maintenance. How > can I make the routed traffic go through Bird but still connect to a > foreign gateway via SSH through another NIC? Also the operating system > updates (apt-get) should run over the third NIC and not over the bird > routes. > > NIC 1: LAN / OSPF > NIC 2: BGP / Peering / routed traffic over bird > NIC 3: foreign gateway fo remote maintenance of the routers debian instance > > Regards, > > Nils van L?ck I'm not 100% sure... but I see two two ways, but both with limitations. Maybe someone can comment on these approaches, or provide an alternative better idea. 1) Use different routing tables. This way you can ensure that traffic which hits nic3 goes out of nic3 then. See https://tldp.org/HOWTO/pdf/Adv-Routing-HOWTO.pdf Section 4.2.1. Split access for the general setup But I do not know how you would /tell/ `apt` to use that table or a specific source address (so its traffic would then go out of nic3). However, bird is able to use different tables. 2) Using namespaces Start `sshd` in a separate namespace, and call `apt` also only from within this namespace. This namespace would only have `lo` and `nic3`. See for instance https://lwn.net/Articles/580893/ While using a namespace for sshd and apt, you would not need to configure bird / tell bird about it. Hope this helps somehow. Best, Bernd From bird at 2krueger.de Fri Mar 26 13:00:52 2021 From: bird at 2krueger.de (Marcel =?utf-8?Q?Kr=C3=BCger?=) Date: Fri, 26 Mar 2021 13:00:52 +0100 Subject: A ifname counterpart for the "from" attribute Message-ID: <20210326120052.myi3ogqbngwt5xje@yoga> Hi, is there any way to identify in a filter the interface the route was learned from? So basically an attribute which relates to "from" like ifname and ifindex relate to "gw"? This would be particularly useful when "from" is a link lcal address and therefore might not be enough to identify the source. If this doesn't exists, is there another way to enforce that the "gw" is always on the same interface the route was learned on whithout having to use interface specific configuration (e.g. customized filters or special igp tables in BGP). (I am mostly interested in BGP, but I guess that most solutions would apply more gnerally) If not, would a patch implementing such an route attribute have a chance of being merged? Best regards, Marcel From santiago at crfreenet.org Fri Mar 26 15:48:08 2021 From: santiago at crfreenet.org (Ondrej Zajicek) Date: Fri, 26 Mar 2021 15:48:08 +0100 Subject: Foreign upstream gateway for remote maintenance In-Reply-To: References: <5f985bb6-33c7-46b5-8e96-af928926ff32@spreadshirt.net> Message-ID: <20210326144808.GO3327@feanor.crfreenet.org> On Fri, Mar 26, 2021 at 09:58:17AM +0100, Bernd Naumann wrote: > Good morning Nils, > > On 26.03.21 08:47, Nils van L?ck wrote: > > Hello! > > > > I am using the latest Bird version from the git repo under Debian. I > > have one dedicated NIC for the LAN, one dedicated NIC for BGP sessions > > and one NIC with an IP from a foreign ASN for remote maintenance. How > > can I make the routed traffic go through Bird but still connect to a > > foreign gateway via SSH through another NIC? Also the operating system > > updates (apt-get) should run over the third NIC and not over the bird > > routes. > > > > NIC 1: LAN / OSPF > > NIC 2: BGP / Peering / routed traffic over bird > > NIC 3: foreign gateway fo remote maintenance of the routers debian instance > > > > Regards, > > > > Nils van L?ck > > I'm not 100% sure... but I see two two ways, but both with limitations. > Maybe someone can comment on these approaches, or provide an alternative > better idea. > > 1) Use different routing tables. This way you can ensure that traffic which > hits nic3 goes out of nic3 then. > > See https://tldp.org/HOWTO/pdf/Adv-Routing-HOWTO.pdf Section 4.2.1. Split > access for the general setup > > But I do not know how you would /tell/ `apt` to use that table or a specific > source address (so its traffic would then go out of nic3). > > However, bird is able to use different tables. You can also use VRFs: https://www.kernel.org/doc/Documentation/networking/vrf.txt man ip-vrf That is like different routing tables, but with easier setup (just assign iface to VRF instead of meddling with ip rule table). You can either use default VRF as management (put NIC 3 there), or you can use 'ip vrf exec' to run apt in different VRF. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From santiago at crfreenet.org Fri Mar 26 16:14:00 2021 From: santiago at crfreenet.org (Ondrej Zajicek) Date: Fri, 26 Mar 2021 16:14:00 +0100 Subject: A ifname counterpart for the "from" attribute In-Reply-To: <20210326120052.myi3ogqbngwt5xje@yoga> References: <20210326120052.myi3ogqbngwt5xje@yoga> Message-ID: <20210326151400.GP3327@feanor.crfreenet.org> On Fri, Mar 26, 2021 at 01:00:52PM +0100, Marcel Kr?ger wrote: > Hi, > > is there any way to identify in a filter the interface the route was > learned from? So basically an attribute which relates to "from" like > ifname and ifindex relate to "gw"? This would be particularly useful > when "from" is a link lcal address and therefore might not be enough to > identify the source. > > If this doesn't exists, is there another way to enforce that the > "gw" is always on the same interface the route was learned on whithout > .. > If not, would a patch implementing such an route attribute have a chance > of being merged? Hi Iface associated with 'from' is not stored internally. Check like 'gw = from' work also for link local address, because link-local next_hop is resolved only on the same iface, but that is more strict check that you wanted. We currently do not support iface as a value for regular attributes ('ifname' itself is an exception and only a temporary solution), but we have some pending patches that redesign route attributes. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From sm at samip.fi Fri Mar 26 16:41:30 2021 From: sm at samip.fi (=?UTF-8?Q?Skyler_M=C3=A4ntysaari?=) Date: Fri, 26 Mar 2021 17:41:30 +0200 Subject: BIRD 2.0.8 In-Reply-To: <85b48366-26fd-b106-c9cb-cf7842dce0ed@peter-hurtenbach.de> References: <12d45fd0-922e-7b08-67ed-ca5eda82a052@samip.fi> <85b48366-26fd-b106-c9cb-cf7842dce0ed@peter-hurtenbach.de> Message-ID: <2c5af8a9-bb0a-472b-9337-65e87e260be9@www.fastmail.com> Hi, Thank you for pointing me to the right place, but it seems that it wasn't as straightforward as I had hoped to get a deb out for 2.0.8. It's unable to find some docs related perl nodule? Where should I make a request for CI/CD build of mips64/mips Debian package? That would be really useful for people running Bird on things like EdgeRouter from Ubiquiti. In what kind of timeline does a new deb package get published usually? The current repository's key has expired which would also need to be something done to it. Regards, Skyler On Wed, Mar 24, 2021, at 21:39, Peter Hurtenbach wrote: > Hi, > > You can take a look at the Debian Git repository: > https://salsa.debian.org/debian/bird2 > > Regards, > > Peter > > On 3/24/21 6:03 AM, Skyler M?ntysaari wrote: > > Hi, > > > > Who is responsible for the Debian packages at the moment? > > I couldn't find the build scripts for those at gitlab.nic.cz and would > > like to get them so I can setup mips64 and mipsel architecture deb builds. > > > > Best regards, > > Skyler > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at burble.com Sat Mar 27 16:20:05 2021 From: simon at burble.com (Simon Marsh) Date: Sat, 27 Mar 2021 15:20:05 +0000 Subject: Incorrect setting of BGP Path Attribute Extended Length flag breaks MRT output Message-ID: Hi, i run bird as a route collector in DN42 and so get a variety of different BGP daemons peering with and passing routes to the collector. We recently ran in to an issue where MRT dumps from bird were not readable by any of the common MRT parsers and, on investigation, found a bug in how bird handles the BGP Path Attribute Extended Length flag. The issue occurred because peers using the FRR daemon set the Extended Length flag on the AS PATH attribute by default, regardless of the actual data length. When bird re-encodes the AS Path (for example as part of the MRT dump) it correctly re-calculates whether to use an 8 bit or 16 bit length field for the attribute, but simply copies the flags and does not reset the Extended Length flag in the 8 bit case. This results in an AS PATH attribute being output that has the Extended Length flag set but with the actual length field being only 8 bits. Of course, any parsers trying read this get very confused. A simple fix is to ensure the Extended Length flag is cleared when encoding the 3 byte attribute header: diff --git a/proto/bgp/attrs.c b/proto/bgp/attrs.c index 6752cb7f..5c7b4fdd 100644 --- a/proto/bgp/attrs.c +++ b/proto/bgp/attrs.c @@ -118,7 +118,7 @@ bgp_set_attr(ea_list **attrs, struct linpool *pool, uint code, uint flags, uintp static inline int bgp_put_attr_hdr3(byte *buf, uint code, uint flags, uint len) { - *buf++ = flags; + *buf++ = flags & ~BAF_EXT_LEN; *buf++ = code; *buf++ = len; return 3; Cheers Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From santiago at crfreenet.org Sun Mar 28 13:57:10 2021 From: santiago at crfreenet.org (Ondrej Zajicek) Date: Sun, 28 Mar 2021 13:57:10 +0200 Subject: Incorrect setting of BGP Path Attribute Extended Length flag breaks MRT output In-Reply-To: References: Message-ID: <20210328115710.GQ3327@feanor.crfreenet.org> On Sat, Mar 27, 2021 at 03:20:05PM +0000, Simon Marsh wrote: > Hi, > > i run bird as a route collector in DN42 and so get a variety of different > BGP daemons peering with and passing routes to the collector. > We recently ran in to an issue where MRT dumps from bird were not readable > by any of the common MRT parsers and, on investigation, found a bug in how > bird handles the BGP Path Attribute Extended Length flag. > > The issue occurred because peers using the FRR daemon set the Extended > Length flag on the AS PATH attribute by default, regardless of the actual > data length. When bird re-encodes the AS Path (for example as part of the > MRT dump) it correctly re-calculates whether to use an 8 bit or 16 bit > length field for the attribute, but simply copies the flags and does not > reset the Extended Length flag in the 8 bit case. This results in an AS > PATH attribute being output that has the Extended Length flag set but > with the actual length field being only 8 bits. Of course, any > parsers trying read this get very confused. Hi You are right. Will merge that. I wondered why this issue did not manifest during regular route propagation and that is because attributes are normalized during route export to BGP (but not during MRT table dump). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From pierky at pierky.com Sun Mar 28 15:41:09 2021 From: pierky at pierky.com (Pier Carlo Chiodi) Date: Sun, 28 Mar 2021 15:41:09 +0200 Subject: ignore max length as an argument of roa_check Message-ID: Hello, first, thanks to the devs for 2.0.8! I see the option 'ignore max length' was introduced, and that it's possible to enable it at protocol configuration time. ignore max length switch Ignore received max length in ROA records and use max value (32 or 128) instead. This may be useful for implementing loose RPKI check for blackholes. Default: disabled. I was wondering what other people's feelings would be about having a similar option available at validation time, more specifically as an argument of roa_check. If my understanding is correct, being the current option available only at protocol level, it means that all the ROAs that are present inside the ROA table are used as if the maxLength attribute is not set. This means that it wouldn't be possible to configure a filter to perform a strict OV check (where the maxLength is also taken into account) using ROAs from that table. Having that option available at roa_check time, the same table could be used to perform both strict validation and also a loose validation, for example depending on the presence of the BLACKHOLE BGP community: (pseudo-code follows) # ... regular sanity checks done here... if BLACKHOLE { if (roa_check(ignore_max_lenght=True) = ROA_INVALID) then { reject; } accept; } else { if (roa_check() = ROA_INVALID) then { reject; } accept; } (Assuming ignore_max_lenght has default value == False.) Does it make sense? Thanks Pier Carlo Chiodi -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmaslank at akamai.com Sun Mar 28 23:05:30 2021 From: pmaslank at akamai.com (Maslanka, Pawel) Date: Sun, 28 Mar 2021 21:05:30 +0000 Subject: BMP protocol support - request for review and merge Message-ID: <27A0C0B0-61DD-41A0-95A8-2259F8367550@akamai.com> Hi BIRD devs, Akamai team have implemented basic subset of BMP (BGP Monitoring Protocol) specification for BIRD project (according to RFC 7854). We are happy to share our work with BIRD community and would ask for review patch. Please feel free for modify this patch to meet BIRD source code requirements for merge it to BIRD mainline code since we post this patch under to GPLv2+ license (please look at |proto/bmp/LICENSE|). It worth to note that there are few minor unimplemented things from RFC 7854, but the most important are: - not implemented Route Mirroring message - not implemented Stats Report message This implementation has been tested with open source BMP collectors like OpenBMP and pmacct. This patch is compatible with BIRD v2.0.7 release. Additionally I would like to take the opportunity to thank Ondrej Zajicek for hints to contribution of this patch according to BIRD project specification. Thanks, Pawel Maslanka Software Engineer at Akamai Technologies, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bird_bmp_support.patch Type: application/octet-stream Size: 82340 bytes Desc: bird_bmp_support.patch URL: From dev at kou.li Sun Mar 28 23:28:44 2021 From: dev at kou.li (dev at kou.li) Date: Sun, 28 Mar 2021 23:28:44 +0200 Subject: BGP connect retry time Message-ID: <20210328212843.GA1381@nika.din.cz> Hello, I am running bird's BGP on a slower link with accounted data. I would like to lower connection attempt frequency when the peer is down. I found only two parameters mentioning connection delays: 'connect delay time' and 'connect retry time'. From documentation, I understood to change the 'connect retry time' to slow down failed connection attempts, but the bird seems to use 'connect delay time' repeatedly if the connection fails (test: bird 1.6.6, peer's firewall drops all BGP packets). So, what is the 'connect retry time' used for? Also, if I increase the 'connect delay time' to lower BGP data throughput in case the peer is offline, I introduce also unwanted delay when everything works and only the BGP protocol is restarted... I understand bird 1.6.6 is rather old to ask for any help here. However, it is such a basic functionality I do not believe it to have changed recently. Also, I found no mention of these parameters in the NEWS file. Milan From santiago at crfreenet.org Mon Mar 29 12:19:20 2021 From: santiago at crfreenet.org (Ondrej Zajicek) Date: Mon, 29 Mar 2021 12:19:20 +0200 Subject: BMP protocol support - request for review and merge In-Reply-To: <27A0C0B0-61DD-41A0-95A8-2259F8367550@akamai.com> References: <27A0C0B0-61DD-41A0-95A8-2259F8367550@akamai.com> Message-ID: <20210329101920.GR3327@feanor.crfreenet.org> On Sun, Mar 28, 2021 at 09:05:30PM +0000, Maslanka, Pawel wrote: > Hi BIRD devs, > > Akamai team have implemented basic subset of BMP (BGP Monitoring Protocol) specification for BIRD project (according to RFC 7854). We are happy to share our work with BIRD community and would ask for review patch. Please feel free for modify this patch to meet BIRD source code requirements for merge it to BIRD mainline code since we post this patch under to GPLv2+ license (please look at |proto/bmp/LICENSE|). Hi Thanks for your contribution. As we discussed off-list, i plan to clean-up, finalize and merge it. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From santiago at crfreenet.org Mon Mar 29 14:39:27 2021 From: santiago at crfreenet.org (Ondrej Zajicek) Date: Mon, 29 Mar 2021 14:39:27 +0200 Subject: BGP connect retry time In-Reply-To: <20210328212843.GA1381@nika.din.cz> References: <20210328212843.GA1381@nika.din.cz> Message-ID: <20210329123927.GS3327@feanor.crfreenet.org> On Sun, Mar 28, 2021 at 11:28:44PM +0200, dev at kou.li wrote: > Hello, > > I am running bird's BGP on a slower link with accounted data. I would > like to lower connection attempt frequency when the peer is down. I > found only two parameters mentioning connection delays: 'connect delay > time' and 'connect retry time'. From documentation, I understood to > change the 'connect retry time' to slow down failed connection attempts, > but the bird seems to use 'connect delay time' repeatedly if the > connection fails (test: bird 1.6.6, peer's firewall drops all BGP > packets). So, what is the 'connect retry time' used for? Hi BIRD uses 'connect retry time' for repeated attempts where connection cannot be established, i.e. rather a maximum timeout for an attempt than limit between attempts. When connection attempt explicitly failed (e.g. received ICMP message about port closed), the protocol is restarted and therefore 'connect delay time' is used. (There is also 'error wait time', but that only happens when session falied after being established.) It is kind of counterintuitive oversight and we should add support for something like minimum connect retry time, it was not that important as overhead from unsuccessful connection attempt is usually negligible (compared to say session flapping). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From pwydrych at akamai.com Mon Mar 29 22:31:24 2021 From: pwydrych at akamai.com (Wydrych, Piotr) Date: Mon, 29 Mar 2021 20:31:24 +0000 Subject: [PATCH] MRT: Add overwrite switch (default: off) Message-ID: <6505B7C1-6E3A-495A-B1BD-C4D2B930F8AF@akamai.com> Hello, I was working recently with MRT dumps. I wrote a small patch that allows bird to overwrite the dump file. Piotr -- Piotr 'GhosT' Wydrych ........ Engineering Manager, SDN ......... Akamai ........................................................................ A: Because it messes up the order in which people normally read text. .. Q: Why is top-posting such a bad thing? ................................ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-MRT-Add-overwrite-switch-default-off.patch Type: application/octet-stream Size: 5015 bytes Desc: 0001-MRT-Add-overwrite-switch-default-off.patch URL: From fischerdouglas at gmail.com Tue Mar 30 15:04:08 2021 From: fischerdouglas at gmail.com (Douglas Fischer) Date: Tue, 30 Mar 2021 10:04:08 -0300 Subject: ignore max length as an argument of roa_check In-Reply-To: References: Message-ID: It does make sense! A LOT! It is the only way I see that is possible to use RPKI as a source of information to validate RTBH with the available information existent now. P.S.: I even mentioned some about that on SIDROPS https://mailarchive.ietf.org/arch/msg/sidrops/vbfKT9yduwAtTNQVBoc5KCRPkmM/ That is the same concept that is used on IRR, right? "If is BlackHole route is contained on the Route Objects on IRR, is acceptable..." Em dom., 28 de mar. de 2021 ?s 10:42, Pier Carlo Chiodi escreveu: > Hello, > > first, thanks to the devs for 2.0.8! > > I see the option 'ignore max length' was introduced, and that it's > possible to enable it at protocol configuration time. > > ignore max length switch > > Ignore received max length in ROA records and use max value (32 or > 128) instead. This may be useful for implementing loose RPKI check for > blackholes. Default: disabled. > > I was wondering what other people's feelings would be about having a > similar option available at validation time, more specifically as an > argument of roa_check. > > If my understanding is correct, being the current option available only at > protocol level, it means that all the ROAs that are present inside the ROA > table are used as if the maxLength attribute is not set. This means that it > wouldn't be possible to configure a filter to perform a strict OV check > (where the maxLength is also taken into account) using ROAs from that table. > > Having that option available at roa_check time, the same table could be > used to perform both strict validation and also a loose validation, for > example depending on the presence of the BLACKHOLE BGP community: > > (pseudo-code follows) > > # ... regular sanity checks done here... > > if BLACKHOLE { > if (roa_check(ignore_max_lenght=True) = ROA_INVALID) then > { > reject; > } > accept; > } else { > if (roa_check() = ROA_INVALID) then > { > reject; > } > accept; > } > > (Assuming ignore_max_lenght has default value == False.) > > Does it make sense? > > Thanks > > Pier Carlo Chiodi > -- Douglas Fernando Fischer Eng? de Controle e Automa??o -------------- next part -------------- An HTML attachment was scrubbed... URL: From magr at ripn.net Tue Mar 30 15:20:23 2021 From: magr at ripn.net (Mikhail Grishin) Date: Tue, 30 Mar 2021 16:20:23 +0300 Subject: ignore max length as an argument of roa_check In-Reply-To: References: Message-ID: Hi, We use this option in production environment (2.0.7 with patches) , started in 2020. Some side effects: Doubled number of tcp sessions with validator, doubled number of roa tables (per each BIRD instanse). Wbr, Milkhail, MSK-IX Douglas Fischer ????? 30.03.2021 16:04: > It does make sense! A LOT! > > It is the only way I see that is possible to use RPKI as a source of > information to validate RTBH with the available information existent now. > > P.S.: I even mentioned some about that on SIDROPS > https://mailarchive.ietf.org/arch/msg/sidrops/vbfKT9yduwAtTNQVBoc5KCRPkmM/ > > That is the same concept that is used on IRR, right? > "If is BlackHole route is contained on the Route Objects on IRR, is > acceptable..." > > Em dom., 28 de mar. de 2021 ?s 10:42, Pier Carlo Chiodi > > escreveu: > > Hello, > > first, thanks to the devs for 2.0.8! > > I see the option 'ignore max length' was introduced, and that it's > possible to enable it at protocol configuration time. > > ignore max length switch > > Ignore received max length in ROA records and use max value > (32 or 128) instead. This may be useful for implementing loose > RPKI check for blackholes. Default: disabled. > > I was wondering what other people's feelings would be about having > a similar option available at validation time, more specifically > as an argument of roa_check. > > If my understanding is correct, being the current option available > only at protocol level, it means that all the ROAs that are > present inside the ROA table are used as if the maxLength > attribute is not set. This means that it wouldn't be possible to > configure a filter to perform a strict OV check (where the > maxLength is also taken into account) using ROAs from that table. > > Having that option available at roa_check time, the same table > could be used to perform both strict validation and also a loose > validation, for example depending on the presence of the BLACKHOLE > BGP community: > > (pseudo-code follows) > > # ... regular sanity checks done here... > > if BLACKHOLE { > if (roa_check(ignore_max_lenght=True) = ROA_INVALID) then > { > reject; > } > accept; > } else { > if (roa_check() = ROA_INVALID) then > { > reject; > } > accept; > } > > (Assuming ignore_max_lenght has default value == False.) > > Does it make sense? > > Thanks > > Pier Carlo Chiodi > > > > -- > Douglas Fernando Fischer > Eng? de Controle e Automa??o -------------- next part -------------- An HTML attachment was scrubbed... URL: From santiago at crfreenet.org Tue Mar 30 16:22:07 2021 From: santiago at crfreenet.org (Ondrej Zajicek) Date: Tue, 30 Mar 2021 16:22:07 +0200 Subject: ignore max length as an argument of roa_check In-Reply-To: References: Message-ID: <20210330142207.GT3327@feanor.crfreenet.org> On Tue, Mar 30, 2021 at 10:04:08AM -0300, Douglas Fischer wrote: > It does make sense! A LOT! > > It is the only way I see that is possible to use RPKI as a source of > information to validate RTBH with the available information existent now. > > P.S.: I even mentioned some about that on SIDROPS > https://mailarchive.ietf.org/arch/msg/sidrops/vbfKT9yduwAtTNQVBoc5KCRPkmM/ Hi I am not sure if the RPKI is reasonable way to validate RTBH. We have a request to implement check that ignores max length, so we did it in a way that was the least intrusive (which is in RPKI instead of in filtering code, although i suppose it could be done also there), but i still have doubts about its usefulness and i would like to get opinions of others about that. Here are my comments: Let's assume an IXP has member A who has customer B, who propagates some address range. Who is responsible for originating blackhole route for IP addres from such range propagated to the IXP? As i understood RFC 7999, received blackhole routes are not propagated further (due to NO_ADVERTISE or NO_EXPORT), therefore such blackhole route has to be originated by member A. Which means its AS_PATH whould end with ASN A and even loose RPKI check would fail, because RPKI record specifies prefix range owned by B. The workaround would be that member A could forge ASNs in AS_PATH to end with ASN B, but that is not a good idea. Or let's assume that an IXP has members A and B that both connect customer C and propagate its address range to the IXP. There are two routes for that range, let's assume that route through A is more preferred. But if member B generated blackhole route for IP address from such range, then such blackhole would be active even if associated route is less preferred to route from member A. My conclusion is that proper validation for blackhole routes should follow the same logic as validating flowspec rules, i.e. a blackhole route should be considered valid if received from the same router/AS who is next hop for selected covering route. With this rule, RPKI validation of blackhole routes is pointless, as they are implicitly validated by validating covering route. > That is the same concept that is used on IRR, right? > "If is BlackHole route is contained on the Route Objects on IRR, is > acceptable..." > > Em dom., 28 de mar. de 2021 ?s 10:42, Pier Carlo Chiodi > escreveu: > > > Hello, > > > > first, thanks to the devs for 2.0.8! > > > > I see the option 'ignore max length' was introduced, and that it's > > possible to enable it at protocol configuration time. > > > > ignore max length switch > > > > Ignore received max length in ROA records and use max value (32 or > > 128) instead. This may be useful for implementing loose RPKI check for > > blackholes. Default: disabled. > > > > I was wondering what other people's feelings would be about having a > > similar option available at validation time, more specifically as an > > argument of roa_check. > > > > If my understanding is correct, being the current option available only at > > protocol level, it means that all the ROAs that are present inside the ROA > > table are used as if the maxLength attribute is not set. This means that it > > wouldn't be possible to configure a filter to perform a strict OV check > > (where the maxLength is also taken into account) using ROAs from that table. > > > > Having that option available at roa_check time, the same table could be > > used to perform both strict validation and also a loose validation, for > > example depending on the presence of the BLACKHOLE BGP community: -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From fischerdouglas at gmail.com Tue Mar 30 17:02:05 2021 From: fischerdouglas at gmail.com (Douglas Fischer) Date: Tue, 30 Mar 2021 12:02:05 -0300 Subject: ignore max length as an argument of roa_check In-Reply-To: <20210330142207.GT3327@feanor.crfreenet.org> References: <20210330142207.GT3327@feanor.crfreenet.org> Message-ID: Hi Ondrej! Your analysis is correct, based on RF7999, considering the Well-Know BlackHole community. But each Autonomous System can have its own Traffic Engineering Communities, including RTBH. This is a very useful resource for some type of reaction to attacks. Let's say that I'm an ISP here in Brazil, and I'm Under some type of attack(a silly one). A volumetric attack targeted a specific IP of that /24. My Flow Analysis Tool alow-me presume that 90% of that attack comes from Asia. I contracted a transit provider with very good Traffic Engineer Communities, and I even paid a bit more because of that. One of the communities of that ITP could be "Remote Trigger this /32 only on Asia, and spread that announce to peers just over there." An then my ITP would reannounce that /32 to IXPs in ASIA, removing his own specific community of selective Blackhole, and adding 65535:666. (P.S. This game gets even funnier with large communities.) So, resulting from that selective RTBH, I will need to deal only with 10% of the attack. Is this an ideal solution? NO! But what response to DDoS attacks is Ideal? I Believe that the stupid war between attackers and targets will end when this war stops being profitable to attackers. And one way to do that is to reduce the costs of responses to Attacks. So, resuming the exposed: - Yes, a route with well know RTBH community should not be propagated on eBGP. - But it does not mean that a route with well know RTBH community needs to have a single hop AS-Path. RPKI is Origin Validation, not Path Validation. Em ter., 30 de mar. de 2021 ?s 11:22, Ondrej Zajicek escreveu: > On Tue, Mar 30, 2021 at 10:04:08AM -0300, Douglas Fischer wrote: > > It does make sense! A LOT! > > > > It is the only way I see that is possible to use RPKI as a source of > > information to validate RTBH with the available information existent now. > > > > P.S.: I even mentioned some about that on SIDROPS > > > https://mailarchive.ietf.org/arch/msg/sidrops/vbfKT9yduwAtTNQVBoc5KCRPkmM/ > > Hi > > I am not sure if the RPKI is reasonable way to validate RTBH. We have a > request to implement check that ignores max length, so we did it in a way > that was the least intrusive (which is in RPKI instead of in filtering > code, although i suppose it could be done also there), but i still have > doubts about its usefulness and i would like to get opinions of others > about that. Here are my comments: > > Let's assume an IXP has member A who has customer B, who propagates some > address range. Who is responsible for originating blackhole route for IP > addres from such range propagated to the IXP? As i understood RFC 7999, > received blackhole routes are not propagated further (due to NO_ADVERTISE > or NO_EXPORT), therefore such blackhole route has to be originated by > member A. Which means its AS_PATH whould end with ASN A and even loose > RPKI check would fail, because RPKI record specifies prefix range owned > by B. The workaround would be that member A could forge ASNs in AS_PATH > to end with ASN B, but that is not a good idea. > > Or let's assume that an IXP has members A and B that both connect > customer C and propagate its address range to the IXP. There are two > routes for that range, let's assume that route through A is more > preferred. But if member B generated blackhole route for IP address from > such range, then such blackhole would be active even if associated route > is less preferred to route from member A. > > My conclusion is that proper validation for blackhole routes should > follow the same logic as validating flowspec rules, i.e. a blackhole > route should be considered valid if received from the same router/AS who > is next hop for selected covering route. With this rule, RPKI validation > of blackhole routes is pointless, as they are implicitly validated by > validating covering route. > > > > That is the same concept that is used on IRR, right? > > "If is BlackHole route is contained on the Route Objects on IRR, is > > acceptable..." > > > > Em dom., 28 de mar. de 2021 ?s 10:42, Pier Carlo Chiodi < > pierky at pierky.com> > > escreveu: > > > > > Hello, > > > > > > first, thanks to the devs for 2.0.8! > > > > > > I see the option 'ignore max length' was introduced, and that it's > > > possible to enable it at protocol configuration time. > > > > > > ignore max length switch > > > > > > Ignore received max length in ROA records and use max value (32 or > > > 128) instead. This may be useful for implementing loose RPKI check for > > > blackholes. Default: disabled. > > > > > > I was wondering what other people's feelings would be about having a > > > similar option available at validation time, more specifically as an > > > argument of roa_check. > > > > > > If my understanding is correct, being the current option available > only at > > > protocol level, it means that all the ROAs that are present inside the > ROA > > > table are used as if the maxLength attribute is not set. This means > that it > > > wouldn't be possible to configure a filter to perform a strict OV check > > > (where the maxLength is also taken into account) using ROAs from that > table. > > > > > > Having that option available at roa_check time, the same table could be > > > used to perform both strict validation and also a loose validation, for > > > example depending on the presence of the BLACKHOLE BGP community: > > -- > Elen sila lumenn' omentielvo > > Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) > OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) > "To err is human -- to blame it on a computer is even more so." > -- Douglas Fernando Fischer Eng? de Controle e Automa??o -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierky at pierky.com Tue Mar 30 21:31:32 2021 From: pierky at pierky.com (Pier Carlo Chiodi) Date: Tue, 30 Mar 2021 21:31:32 +0200 Subject: ignore max length as an argument of roa_check In-Reply-To: <20210330142207.GT3327@feanor.crfreenet.org> References: <20210330142207.GT3327@feanor.crfreenet.org> Message-ID: Hi, > Let's assume an IXP has member A who has customer B, who propagates some address range. Who is responsible for originating blackhole route for IP addres from such range propagated to the IXP? FWIW, my understanding of "Local Scope of Blackholes" from https://tools.ietf.org/html/rfc7999#section-3.2 is that it's allowed to cautiously propagate a route tagged with BLACKHOLE when policies are explicitly in place between adjacent networks to treat those routes according to RFC7999. If I got your example right, B originates the BLACKHOLE prefix to ask A to mitigate an attack that they are receiving. B announces it to A. A is a member of IXP, and it has peering relationships with peer n (n could be either another member or a route server). If there is an agreement between A and IXPn to treat BLACKHOLE routes according to RFC7999, in that case (according to my understanding) A could propagate that route to IXPn as it is, with AS_PATH "A, B". The origin AS would still be B. IXPn would be the one in charge of implementing the sanity checks to verify that the route is valid. The point I wanted to raise with my original message is that I believe the current implementation of 'ignore max length' might be a bit too loose. That knob de-facto goes against the way RFC6811 works, and if I understand it correctly, it does it at a very global level, for all the ROAs inside the table. Having a ROA table where the maxLength of all the ROAs is ignored makes that table unusable for strict origin validation, and in my opinion poses an avoidable risk by creating an entity that could still be consumed by roa_check for purposes that are different than the one we're discussing in this thread, that is something-similar-to-origin-validation for blackhole requests handling. On the basis of my experience, sometimes, having a handy solution to quickly solve reachability issues could be seen as the way to go, especially while under pressure, but that would cause more damage than it solves ;-) I believe that turning 'ignore max length' on, seeing that it "solves" the issue, and then forgetting about it could be a very easy and likely path in certain circumstances, and that it could undermine the benefits given by the whole global RPKI/OV deployment effort. To your point, I also believe that RPKI OV as per RFC6811 is not appropriate to handle blackhole requests. In a recent message to Sidrops we can read: > Work in under way to harmonize RPKI & BGP blackholing. The IETF's draft submission window currently is closed, but as soon as it opens, I will upload a document detailing a possible way forward. (1 or 2 weeks from now) (https://mailarchive.ietf.org/arch/msg/sidrops/v0tVaVcT2WHe9vW2x_GKg52KX-E/) It will probably take a bit of time before a solution based on the above will be ready for production, but I believe that in the meantime it could be worth exploring other less intrusive methods to satisfy the request you received, without weakening RPKI OV "too much". If the desire is to really tweak OV in a way that it could deal with such blackhole routes, I'd suggest rethinking the way that config knob is used today. We just heard feedback on this list where the author mentioned the need of dealing with multiple ROAs tables. This seems very suboptimal to me. What do you think about moving that knob to roa_check? That would allow to keep only one ROA table, with all the bits in place to safely perform a strict OV. roa_check could be changed to accept an additional argument, ignore_maxlength, whose default value could be False. Additionally, the code that takes ignore_maxlength=True into consideration could be implemented to kick in only when BLACKHOLE is attached to the route being processed. In my opinion this could be a "good" trade-off solution to still satisfy the original need, while keeping the behaviour of roa_check secure-by-default and not prone to misusage. This seems to me the "least privilege" approach to prefer. Another more drastic proposal could be to just drop the config knob completely and keep the OV implementation secure, leaving it up to other forums to come up with a solution, agreed upon by the community. Discussing this a bit with other people, they proposed the use of SLURM on the receiving network side to tune the RPKI information in a way that the BLACKHOLE routes could still be accepted. I understand that there may be other implications on using a similar approach, which may collide with the original requirement you had, but now that the outcome of the ROAs processing is immediately reflected into the filters it could still be the best trade-off between keeping a secure implementation, not prone to misuse, and a solution able to satisfy the users requirement. WDYT? Cheers, Pier Carlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From santiago at crfreenet.org Wed Mar 31 04:34:12 2021 From: santiago at crfreenet.org (Ondrej Zajicek) Date: Wed, 31 Mar 2021 04:34:12 +0200 Subject: ignore max length as an argument of roa_check In-Reply-To: References: <20210330142207.GT3327@feanor.crfreenet.org> Message-ID: <20210331023412.GU3327@feanor.crfreenet.org> On Tue, Mar 30, 2021 at 09:31:32PM +0200, Pier Carlo Chiodi wrote: > Hi, > > > Let's assume an IXP has member A who has customer B, who propagates some > address range. Who is responsible for originating blackhole route for IP > addres from such range propagated to the IXP? > > FWIW, my understanding of "Local Scope of Blackholes" from > https://tools.ietf.org/html/rfc7999#section-3.2 is that it's allowed to > cautiously propagate a route tagged with BLACKHOLE when policies are > explicitly in place between adjacent networks to treat those routes > according to RFC7999. > > If I got your example right, B originates the BLACKHOLE prefix to ask A to > mitigate an attack that they are receiving. B announces it to A. A is a > member of IXP, and it has peering relationships with peer n (n could be > either another member or a route server). If there is an agreement between > A and IXPn to treat BLACKHOLE routes according to RFC7999, in that case > (according to my understanding) A could propagate that route to IXPn as it > is, with AS_PATH "A, B". The origin AS would still be B. IXPn would be the > one in charge of implementing the sanity checks to verify that the route is > valid. That is pretty clear, but i thought more about the other case - /32 address from B is DDoSed, link from IXP to A is saturated, and A does not wait for B to originate BLACKHOLE route, and originates it themselves and propagates it to IXP. Such blackhole route would have AS_PATH just 'A', so RPKI check would fail (as RPKI registered origin is B). Not sure if this is considered appropriate, but i would say that it is both intentionally valid (provider A says which traffic want and do not want to accept) and allowed by RFC 7999: o The announced prefix is covered by an equal or shorter prefix that the neighboring network is authorized to advertise. (A is authorized to advertise, but not originate such prefix) So my point/idea is that if this case is valid, then using RPKI-style checking for BLACKHOLE is broken idea anyway, and perhaops we should instead focus on implementing (IMHO) proper checking for BLACKHOLE routes, similar to one for flowspec validation: BLACKHOLE route received from A is valid if i have (RPKI-valid) regular route from A for network N covering the BLACKHOLE route and (optionally) such route is best route for network N. I am interested in opinions about this criterion of blackhole validity vs loose/ignore_max_length-RPKI criterion of blackhole validity. But that is probably more a question for SIDROPS mailing list. > The point I wanted to raise with my original message is that I believe the > current implementation of 'ignore max length' might be a bit too loose. > > That knob de-facto goes against the way RFC6811 works, and if I understand > it correctly, it does it at a very global level, for all the ROAs inside > the table. Having a ROA table where the maxLength of all the ROAs is Yes, it is intended for creating separate ROA table just for loose RPKI OV. > On the basis of my experience, sometimes, having a handy solution to > quickly solve reachability issues could be seen as the way to go, > especially while under pressure, but that would cause more damage than it > solves ;-) > I believe that turning 'ignore max length' on, seeing that it "solves" the > issue, and then forgetting about it could be a very easy and likely path in > certain circumstances, and that it could undermine the benefits given by > the whole global RPKI/OV deployment effort. That is a possibility, and probably more likely than using per-roa_check() knob improperly. > To your point, I also believe that RPKI OV as per RFC6811 is not > appropriate to handle blackhole requests. In a recent message to Sidrops we > can read: > > > Work in under way to harmonize RPKI & BGP blackholing. The IETF's draft > submission window currently is closed, but as soon as it opens, I will > upload a document detailing a possible way forward. (1 or 2 weeks from now) > > (https://mailarchive.ietf.org/arch/msg/sidrops/v0tVaVcT2WHe9vW2x_GKg52KX-E/) > > It will probably take a bit of time before a solution based on the above > will be ready for production, but I believe that in the meantime it could > be worth exploring other less intrusive methods to satisfy the request you > received, without weakening RPKI OV "too much". > > If the desire is to really tweak OV in a way that it could deal with such > blackhole routes, I'd suggest rethinking the way that config knob is used > today. > > We just heard feedback on this list where the author mentioned the need of > dealing with multiple ROAs tables. This seems very suboptimal to me. What > do you think about moving that knob to roa_check? Could be done, but adding optional arguments is problematic due to limitations of scripting language, so perhaps just add another operation called roa_loose_check(). > Another more drastic proposal could be to just drop the config knob > completely and keep the OV implementation secure, leaving it up to other > forums to come up with a solution, agreed upon by the community. I am interested in alternate solutions (like flowspec-style validation as i suggested above). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From job at fastly.com Wed Mar 31 08:44:19 2021 From: job at fastly.com (Job Snijders) Date: Wed, 31 Mar 2021 08:44:19 +0200 Subject: ignore max length as an argument of roa_check In-Reply-To: <20210331023412.GU3327@feanor.crfreenet.org> References: <20210330142207.GT3327@feanor.crfreenet.org> <20210331023412.GU3327@feanor.crfreenet.org> Message-ID: On Wed, Mar 31, 2021 at 04:34:12AM +0200, Ondrej Zajicek wrote: > So my point/idea is that if this case is valid, then using RPKI-style > checking for BLACKHOLE is broken idea anyway, Yes, the design pattern of using ROAs for blackholing appears problematic. Mangling ROAs and then using the resulting deteriorated information to 'approve blackholes' appears to defeat the purpose of RPKI ROAs. ROAs exist to help increase network reachability :) > and perhaops we should instead focus on implementing (IMHO) proper > checking for BLACKHOLE routes, similar to one for flowspec validation: > > BLACKHOLE route received from A is valid if i have (RPKI-valid) > regular route from A for network N covering the BLACKHOLE route > and (optionally) such route is best route for network N. +1 The above appears a worthwhile direction, more elegant than overriding a cryptographically signed attestation on the expected prefix length. 'ignore max length' appears to me as a dangerous button. I support Pier's suggestion to remove this config knob because of the risk of unintended consequences. In the below slide deck I've outlined some suggestions to make activation of blackhole requests dependent on 'normal routing', and in doing so - any and all work to improve 'normal routing security' will also improve 'blackholing routing'. http://iepg.org/2019-03-24-ietf104/blackholing_reconsidered_ietf104_snijders.pdf Kind regards, Job