- Bird-users - Mailing Lists

Limitations of BGP AS confederations?
by Erik Zscheile (Software Development) 07 Nov '20

07 Nov '20

Hello, in an article [1] (which was one of very few articles which I found about BIRD + BGP AS confederations) it is stated that currently, BGP AS confederations have the following limitation: > Bird won't consider the confederation part while calculating distance, which leads to weird routing results. > Bird neither provides a variable for the filter to calculate confederation length and make manual adjustments. > * bgp_path.len in Bird doesn't contain the length of Confederation, as stated above; (citation from section below "But there is some problem when using Confederation in Bird") The article seems to be tested against BIRD version 2.0.7. I'm not sure if that information is really correct, as I wasn't able to find any other source which stated that, but on the other hand, I also found no other source which explains BIRD + BGP AS confederation equally (or at least) that detailed. I (as of now) wasn't able to test it, but maybe I do that soon. (but I have no lab env running here, and didn't want to disrupt my currently working BGP setup, althrough it is not 'extremely' important if it is interrupted for a short amount of time...) ## If this is still an issue in the master branch: I think it would be a good idea to add an config option to conditionally enable "count confederation AS's in bgp_path.len / distance calculations" (or add another "method" on bgp_path and an option to switch the default AS-path-length calculation to that). * The statements above and the documentation combined sound like the confederation AS's are kept inside an aggregated, (unordered?) AS-set inside of bgp_path. Is that true? (I wasn't able to find any concrete documentation about this, and previously just thought that confederation AS's were kept as an sequence.) In BGP protocol terms [2], this would imply that either: * BIRD only uses AS_CONFED_SET's for the "confederation part" (under the assumption that these are treated like AS_SET), or * BIRD uses AS_CONFED_SEQUENCE as expected, but treats AS_SET, AS_CONFED_SET and AS_CONFED_SEQUENCE equally, even though that doesn't seem like a universally practicable choice. * Is there some easier way to fix this (either via configuration which I just missed or via patching of code)? * If not, is it possible to implement a more complex fix for this in a reasonable timeframe (e.g. not an excessive amount of work for a rather niche feature)? * If it is possible, where should I start implementing it (e.g. which parts of the BGP code are probably related to this, as I don't want to read all the BGP code multiple times just to find those places)? Regards, Erik Zscheile [1]: https://lantian.pub/en/article/modify-website/bird-confederation.lantian/ [2]: RFC 5065, page 5; https://www.rfc-editor.org/rfc/rfc5065.txt

2 3

BGP peer not established
by Truth Seeker 06 Nov '20

06 Nov '20

I am running bird 1.6.6. As shown in the following log messages, I have 2 BGP neighbors configured, but the sessions are not up. I keep getting those connection rejected messages. Anyone knows what’s the cause of it and how to fix it? Thanks in advance, Wei ============================================================================= 2020-10-29 17:58:27 <RMT> bgp1_rdomain_0: Error: Hold timer expired 2020-10-29 17:58:28 <WARN> bgp found listen socket for p:bgp1_rdomain_0 s_node:0000000000693770 s:0000000000693640 2020-10-29 17:58:48 <INFO> bgp1_rdomain_0: Incoming connection sk:0000000000693a30 from 10.0.143.81 (port 37163) rejected 2020-10-29 17:59:01 <INFO> bgp1_rdomain_0: Incoming connection sk:00000000007e6e80 from 10.0.143.81 (port 11955) rejected 2020-10-29 17:59:14 <INFO> bgp1_rdomain_0: Incoming connection sk:0000000000698de0 from 10.0.143.81 (port 43375) rejected 2020-10-29 18:56:28 <RMT> bgp2_rdomain_0: Error: Hold timer expired 2020-10-29 18:56:29 <WARN> bgp found listen socket for p:bgp2_rdomain_0 s_node:0000000000693110 s:0000000000693140 2020-10-29 18:56:59 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000006d39a0 from 10.0.142.81 (port 45446) rejected 2020-10-29 18:57:11 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000007f3de0 from 10.0.142.81 (port 36129) rejected 2020-10-29 18:57:16 <INFO> Processed 2 routes for message of size 40 2020-10-29 18:57:22 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000007f4140 from 10.0.142.81 (port 30384) rejected 2020-10-29 18:57:30 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000008a9d50 from 10.0.142.81 (port 39059) accepted 2020-10-29 18:58:30 <INFO> Processed 2 routes for message of size 40 2020-10-29 19:25:16 <RMT> bgp2_rdomain_0: Error: Hold timer expired 2020-10-29 19:25:17 <WARN> bgp found listen socket for p:bgp2_rdomain_0 s_node:0000000000693110 s:0000000000693140 2020-10-29 19:25:48 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000008a9d50 from 10.0.142.81 (port 32690) rejected 2020-10-29 19:26:02 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000008a9d50 from 10.0.142.81 (port 52332) rejected 2020-10-29 19:55:43 <RMT> bgp2_rdomain_0: Error: Hold timer expired 2020-10-29 19:55:43 <WARN> bgp found listen socket for p:bgp2_rdomain_0 s_node:0000000000693110 s:0000000000693140 2020-10-29 19:55:53 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000008a9d50 from 10.0.142.81 (port 49693) rejected 2020-10-29 19:56:07 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000008a9d50 from 10.0.142.81 (port 34617) rejected 2020-10-29 19:56:21 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000008a9d50 from 10.0.142.81 (port 16554) rejected 2020-10-29 19:56:30 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000008a9d50 from 10.0.142.81 (port 40954) rejected 2020-10-29 19:59:26 <RMT> bgp2_rdomain_0: Error: Hold timer expired 2020-10-29 19:59:26 <WARN> bgp found listen socket for p:bgp3_rdomain_0 s_node:0000000000693110 s:0000000000693140 2020-10-29 19:59:26 <WARN> bgp found listen socket for p:bgp2_rdomain_0 s_node:0000000000693110 s:0000000000693140 2020-10-29 19:59:40 <INFO> bgp2_rdomain_0: Incoming connection sk:0000000000693b40 from 10.0.142.81 (port 48975) rejected 2020-10-29 19:59:50 <RMT> bgp1_rdomain_0: Error: Hold timer expired 2020-10-29 19:59:51 <WARN> bgp found listen socket for p:bgp1_rdomain_0 s_node:0000000000693770 s:0000000000693640 2020-10-29 19:59:52 <INFO> bgp2_rdomain_0: Incoming connection sk:0000000000693b40 from 10.0.142.81 (port 11000) rejected 2020-10-29 19:59:52 <INFO> bgp1_rdomain_0: Incoming connection sk:00000000006a3590 from 10.0.143.81 (port 19880) rejected 2020-10-29 20:00:00 <INFO> bgp1_rdomain_0: Incoming connection sk:00000000006a3590 from 10.0.143.81 (port 25771) rejected 2020-10-29 20:00:01 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000006a3590 from 10.0.142.81 (port 30442) rejected 2020-10-29 20:00:10 <INFO> bgp1_rdomain_0: Incoming connection sk:00000000006a3590 from 10.0.143.81 (port 44408) rejected 2020-10-29 20:00:10 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000006a3590 from 10.0.142.81 (port 47468) rejected 2020-10-29 20:00:18 <INFO> bgp1_rdomain_0: Incoming connection sk:00000000006a3590 from 10.0.143.81 (port 23674) rejected 2020-10-29 20:00:19 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000006a3590 from 10.0.142.81 (port 21274) rejected 2020-10-29 20:00:25 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000006d3b30 from 10.0.142.81 (port 14859) rejected 2020-10-29 20:00:28 <INFO> bgp1_rdomain_0: Incoming connection sk:00000000006d3b30 from 10.0.143.81 (port 43656) rejected 2020-10-29 20:00:33 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000006d3b30 from 10.0.142.81 (port 44701) rejected 2020-10-29 20:00:39 <INFO> bgp1_rdomain_0: Incoming connection sk:00000000006d3b30 from 10.0.143.81 (port 34627) rejected 2020-10-29 20:00:43 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000006d3bc0 from 10.0.142.81 (port 43653) rejected 2020-10-29 20:00:55 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000007f34f0 from 10.0.142.81 (port 53653) rejected 2020-10-29 20:01:07 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000008a9200 from 10.0.142.81 (port 32885) accepted 2020-10-29 20:08:15 <RMT> bgp2_rdomain_0: Error: Hold timer expired 2020-10-29 20:08:16 <WARN> bgp found listen socket for p:bgp2_rdomain_0 s_node:0000000000693110 s:0000000000693140 2020-10-29 20:08:16 <RMT> bgp4_rdomain_0: Received: Hold timer expired 2020-10-29 20:08:16 <WARN> bgp found listen socket for p:bgp4_rdomain_0 s_node:0000000000693110 s:0000000000693140 2020-10-29 20:08:35 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000008a9200 from 10.0.142.81 (port 39637) rejected 2020-10-29 20:08:45 <INFO> bgp2_rdomain_0: Incoming connection sk:000000000089f870 from 10.0.142.81 (port 25534) rejected 2020-10-29 20:08:58 <INFO> bgp2_rdomain_0: Incoming connection sk:000000000089f870 from 10.0.142.81 (port 34717) rejected 2020-10-29 20:09:06 <INFO> bgp4_rdomain_0: Incoming connection sk:000000000089f870 from 10.0.142.50 (port 57037) rejected 2020-10-29 20:09:09 <INFO> bgp2_rdomain_0: Incoming connection sk:000000000089f870 from 10.0.142.81 (port 43132) rejected 2020-10-29 20:09:10 <INFO> bgp4_rdomain_0: Incoming connection sk:000000000089f870 from 10.0.142.50 (port 52005) accepted 2020-10-29 20:12:39 <RMT> bgp3_rdomain_0: Error: Hold timer expired 2020-10-29 20:12:40 <WARN> bgp found listen socket for p:bgp3_rdomain_0 s_node:0000000000693110 s:0000000000693140 2020-10-29 20:13:27 <RMT> bgp4_rdomain_0: Error: Hold timer expired 2020-10-29 20:13:28 <WARN> bgp found listen socket for p:bgp4_rdomain_0 s_node:0000000000693110 s:0000000000693140 2020-10-29 20:14:24 <INFO> bgp4_rdomain_0: Incoming connection sk:00000000007e0710 from 10.0.142.50 (port 43162) accepted 2020-10-29 20:16:40 <RMT> bgp4_rdomain_0: Error: Hold timer expired 2020-10-29 20:16:41 <WARN> bgp found listen socket for p:bgp4_rdomain_0 s_node:0000000000693110 s:0000000000693140

1 0

BIRD2 BFD only listen on IPv6 or IPv4
by Stefan Plug 06 Nov '20

06 Nov '20

Hey guys, BIRD2 2.0.7 I want to run 2 BIRD2 Daemons, one with ipv4 config and one with ipv6 config, just like as with BIRD1 this works fine for BGP. However, I have noticed that it doesn’t seem possible (?) to point BFD within a daemon to only listen to ipv4 or ipv6 which will make both daemons listen to both protocols regardless of if they even have any ipv4 or ipv6 configuration. This means that if daemon1 was first then all BFD packets will got to daemon1 and not to daemon2, so no BFD will come up in daemon2. Is there a way to tell BIRD2 to only listen to ipv4 or ipv6 with BFD? 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.

3 4

How to change route gw on export to BGP neighbor?
by ico 04 Nov '20

04 Nov '20

Hello, I'm trying to to export some routes from our internal OSPF to BGP , both running in the same bird instance. I am able to filter those routes via BGP just fine (some tables connected via pipe). The problem is that all exported routes have private gw addresses (10.x.x.x). I am unable to configure bird to change gw of routes before then get sent to neighbors. Neighbors see original gateways from 10.0.0.0/8 range which is invalid/unreachable from outside of course. Here is also some simplyfied example, not showing OSPF setup etc. In this example I also don't show the pipes between tables. All of those doesn't seem to be important in this case. ######## router id 1.1.1.2; protocol kernel krnl4 { ipv4 { export all; import all; # route 2.2.2.0/24 gets into bird here }; learn; } protocol device { } protocol bgp { local 1.1.1.2 as 65000; neighbor 1.1.1.1 as 65000; strict bind; ipv4 { import none; export filter { # here I want to export routes with changed gateways bgp_next_hop = 1.1.1.5; # sets next hop but not gw gw = 1.1.1.5; # <ERR> filters, line XY: Invalid gw address print "export bgp ", net, " gw ", gw, " bnh ", bgp_next_hop; # <INFO> export bgp 2.2.2.0/24 gw 1.1.1.5 bnh 1.1.1.5 accept; }; }; } ######## With similar setup in a lab I was able to change those gw attributes on RECEIVING side in import filter to any arbitrary value I wanted. In real life I don't manage those BGP routers so I need to make sure to send correct routes. The example config prints changed gw but BGP peer sees the original gw. In some tests I got error "Invalid gw address" but now I don't have that config. Here it just ignores changed gw. Is there a configuration to achieve this? Thanks ico

2 3

BGP session not established correctly
by Truth Seeker 03 Nov '20

03 Nov '20

I am running bird 1.6.6. As shown in the following log messages, I have 2 BGP neighbors configured, but the sessions are not up. I keep getting those connection rejected messages. Anyone knows what’s the cause of it and how to fix it? Thanks in advance, Wei ============================================================================= 2020-10-29 17:58:27 <RMT> bgp1_rdomain_0: Error: Hold timer expired 2020-10-29 17:58:28 <WARN> bgp found listen socket for p:bgp1_rdomain_0 s_node:0000000000693770 s:0000000000693640 2020-10-29 17:58:48 <INFO> bgp1_rdomain_0: Incoming connection sk:0000000000693a30 from 10.0.143.81 (port 37163) rejected 2020-10-29 17:59:01 <INFO> bgp1_rdomain_0: Incoming connection sk:00000000007e6e80 from 10.0.143.81 (port 11955) rejected 2020-10-29 17:59:14 <INFO> bgp1_rdomain_0: Incoming connection sk:0000000000698de0 from 10.0.143.81 (port 43375) rejected 2020-10-29 18:56:28 <RMT> bgp2_rdomain_0: Error: Hold timer expired 2020-10-29 18:56:29 <WARN> bgp found listen socket for p:bgp2_rdomain_0 s_node:0000000000693110 s:0000000000693140 2020-10-29 18:56:59 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000006d39a0 from 10.0.142.81 (port 45446) rejected 2020-10-29 18:57:11 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000007f3de0 from 10.0.142.81 (port 36129) rejected 2020-10-29 18:57:16 <INFO> Processed 2 routes for message of size 40 2020-10-29 18:57:22 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000007f4140 from 10.0.142.81 (port 30384) rejected 2020-10-29 18:57:30 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000008a9d50 from 10.0.142.81 (port 39059) accepted 2020-10-29 18:58:30 <INFO> Processed 2 routes for message of size 40 2020-10-29 19:25:16 <RMT> bgp2_rdomain_0: Error: Hold timer expired 2020-10-29 19:25:17 <WARN> bgp found listen socket for p:bgp2_rdomain_0 s_node:0000000000693110 s:0000000000693140 2020-10-29 19:25:48 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000008a9d50 from 10.0.142.81 (port 32690) rejected 2020-10-29 19:26:02 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000008a9d50 from 10.0.142.81 (port 52332) rejected 2020-10-29 19:55:43 <RMT> bgp2_rdomain_0: Error: Hold timer expired 2020-10-29 19:55:43 <WARN> bgp found listen socket for p:bgp2_rdomain_0 s_node:0000000000693110 s:0000000000693140 2020-10-29 19:55:53 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000008a9d50 from 10.0.142.81 (port 49693) rejected 2020-10-29 19:56:07 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000008a9d50 from 10.0.142.81 (port 34617) rejected 2020-10-29 19:56:21 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000008a9d50 from 10.0.142.81 (port 16554) rejected 2020-10-29 19:56:30 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000008a9d50 from 10.0.142.81 (port 40954) rejected 2020-10-29 19:59:26 <RMT> bgp2_rdomain_0: Error: Hold timer expired 2020-10-29 19:59:26 <WARN> bgp found listen socket for p:bgp3_rdomain_0 s_node:0000000000693110 s:0000000000693140 2020-10-29 19:59:26 <WARN> bgp found listen socket for p:bgp2_rdomain_0 s_node:0000000000693110 s:0000000000693140 2020-10-29 19:59:40 <INFO> bgp2_rdomain_0: Incoming connection sk:0000000000693b40 from 10.0.142.81 (port 48975) rejected 2020-10-29 19:59:50 <RMT> bgp1_rdomain_0: Error: Hold timer expired 2020-10-29 19:59:51 <WARN> bgp found listen socket for p:bgp1_rdomain_0 s_node:0000000000693770 s:0000000000693640 2020-10-29 19:59:52 <INFO> bgp2_rdomain_0: Incoming connection sk:0000000000693b40 from 10.0.142.81 (port 11000) rejected 2020-10-29 19:59:52 <INFO> bgp1_rdomain_0: Incoming connection sk:00000000006a3590 from 10.0.143.81 (port 19880) rejected 2020-10-29 20:00:00 <INFO> bgp1_rdomain_0: Incoming connection sk:00000000006a3590 from 10.0.143.81 (port 25771) rejected 2020-10-29 20:00:01 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000006a3590 from 10.0.142.81 (port 30442) rejected 2020-10-29 20:00:10 <INFO> bgp1_rdomain_0: Incoming connection sk:00000000006a3590 from 10.0.143.81 (port 44408) rejected 2020-10-29 20:00:10 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000006a3590 from 10.0.142.81 (port 47468) rejected 2020-10-29 20:00:18 <INFO> bgp1_rdomain_0: Incoming connection sk:00000000006a3590 from 10.0.143.81 (port 23674) rejected 2020-10-29 20:00:19 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000006a3590 from 10.0.142.81 (port 21274) rejected 2020-10-29 20:00:25 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000006d3b30 from 10.0.142.81 (port 14859) rejected 2020-10-29 20:00:28 <INFO> bgp1_rdomain_0: Incoming connection sk:00000000006d3b30 from 10.0.143.81 (port 43656) rejected 2020-10-29 20:00:33 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000006d3b30 from 10.0.142.81 (port 44701) rejected 2020-10-29 20:00:39 <INFO> bgp1_rdomain_0: Incoming connection sk:00000000006d3b30 from 10.0.143.81 (port 34627) rejected 2020-10-29 20:00:43 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000006d3bc0 from 10.0.142.81 (port 43653) rejected 2020-10-29 20:00:55 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000007f34f0 from 10.0.142.81 (port 53653) rejected 2020-10-29 20:01:07 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000008a9200 from 10.0.142.81 (port 32885) accepted 2020-10-29 20:08:15 <RMT> bgp2_rdomain_0: Error: Hold timer expired 2020-10-29 20:08:16 <WARN> bgp found listen socket for p:bgp2_rdomain_0 s_node:0000000000693110 s:0000000000693140 2020-10-29 20:08:16 <RMT> bgp4_rdomain_0: Received: Hold timer expired 2020-10-29 20:08:16 <WARN> bgp found listen socket for p:bgp4_rdomain_0 s_node:0000000000693110 s:0000000000693140 2020-10-29 20:08:35 <INFO> bgp2_rdomain_0: Incoming connection sk:00000000008a9200 from 10.0.142.81 (port 39637) rejected 2020-10-29 20:08:45 <INFO> bgp2_rdomain_0: Incoming connection sk:000000000089f870 from 10.0.142.81 (port 25534) rejected 2020-10-29 20:08:58 <INFO> bgp2_rdomain_0: Incoming connection sk:000000000089f870 from 10.0.142.81 (port 34717) rejected 2020-10-29 20:09:06 <INFO> bgp4_rdomain_0: Incoming connection sk:000000000089f870 from 10.0.142.50 (port 57037) rejected 2020-10-29 20:09:09 <INFO> bgp2_rdomain_0: Incoming connection sk:000000000089f870 from 10.0.142.81 (port 43132) rejected 2020-10-29 20:09:10 <INFO> bgp4_rdomain_0: Incoming connection sk:000000000089f870 from 10.0.142.50 (port 52005) accepted 2020-10-29 20:12:39 <RMT> bgp3_rdomain_0: Error: Hold timer expired 2020-10-29 20:12:40 <WARN> bgp found listen socket for p:bgp3_rdomain_0 s_node:0000000000693110 s:0000000000693140 2020-10-29 20:13:27 <RMT> bgp4_rdomain_0: Error: Hold timer expired 2020-10-29 20:13:28 <WARN> bgp found listen socket for p:bgp4_rdomain_0 s_node:0000000000693110 s:0000000000693140 2020-10-29 20:14:24 <INFO> bgp4_rdomain_0: Incoming connection sk:00000000007e0710 from 10.0.142.50 (port 43162) accepted 2020-10-29 20:16:40 <RMT> bgp4_rdomain_0: Error: Hold timer expired 2020-10-29 20:16:41 <WARN> bgp found listen socket for p:bgp4_rdomain_0 s_node:0000000000693110 s:0000000000693140

1 0

Delete all BGP communities except
by Brooks Swinnerton 29 Oct '20

29 Oct '20

Hello, Is it possible to delete all BGP communities from prefixes learned from a specific BGP session except ones that start with a given value? For example something like: if (bgp_path ~ 64496) then { bgp_large_community.delete([(!64496, *, *)]); } I haven't tested this syntax, but I can't imagine it would work. I'm mostly curious if there's a concept of "except" when deleting BGP communities.

2 3

Bird 2.0.8 release date question
by Piotr KOWALCZYK 28 Oct '20

28 Oct '20

Dear BIRD IRD developers, Could you please tell us when do you plan to release next 2.0.8 version? There were 0 updates this year and I wonder if this will happen this year? Approximate relase date would be nice -- Best Regards

4 3

Erroneous withdrawls and EOR announcements
by micah anderson 22 Oct '20

22 Oct '20

Hello, We have been experiencing heavy DDoS attacks, and one of the mitigation techniques we've used is to peer with Team Cyrmu's UTRS bgp server[0] in order to announce /32s to null route. We also connect with one of our tranist provider's null route services, and our internet exchange's null route service to push these out when they happen. We were contacted by the UTRS folks because it seems like we are sending 'withdrawl' messages for networks that we do not control that are larger than /32, and EOR announcements. For example, from their logs: 2020-10-20T00:19:21+00:00 xp07-as19 UTRS[6681]: receive-routes: update: withdrawal|16652|198.252.153.1|88.16.0.0/16 Our ASN is 16652, and that 198.252.153 address is ours, but that /16 is not ours. I suspect we might be sending withdrawls for every route in our table. It also appears we are sending "eor" advertisements: 2020-10-21T01:01:29+00:00 xp07-as19 UTRS[6681]: receive-routes: update: announcement|16652|198.252.153.1|eor It seems that neither of these are desired by them, and I'm at a loss as to what I can do to make them stop. My bird configuration looks like this, I would greatly appreciate any help in improving this, we cannot afford to lose our UTRS peer, and I'd like to keep us from polluting our friendly neighborhood logs! define LOOPBACKADDR = 198.252.153.1; protocol kernel { learn; # Learn all alien routes from the kernel preference 10000; scan time 15; # Scan kernel routing table every 20 seconds import all; # Default is import all export where ! our_network(); # set preferred source address of routes, # otherwise connections initiated by router might have the transfernet as source address. export filter { krt_prefsrc = LOOPBACKADDR; accept; }; } protocol device { scan time 15; # Scan interfaces every 10 seconds } protocol static static_bgp { import all; preference 10000; include "static_bgp.conf"; } protocol static static_nullroute { import filter static_nullroutes; include "static_nullroutes.conf"; # example: route xxx.xxx.xxx.xxx/32 blackhole; } define OURNETS = [ xxx+ ]; define PEER1 = [ xxx ]; define PEER_ASNS = [ xxx]; function martians() { return net ~ [ 169.254.0.0/16+, 192.168.0.0/16+, 10.0.0.0/8+, 172.16.0.0/12+, 172.24.0.0/13+, 172.25.0.0/16+, 172.26.0.0/16+, 172.27.0.0/16+, 172.28.0.0/16+, 172.29.0.0/16+, 172.30.0.0/16+, 172.31.0.0/16+, 224.0.0.0/4+, 240.0.0.0/4+, 0.0.0.0/32-, 127.0.0.0/8+ ]; filter static_nullroutes { if proto = "static_nullroute" then { bgp_community = -empty-; bgp_community.add((ASN,666)); accept; } } function our_network() { return net ~ OURNETS; } function rt_export() { if proto = "static_bgp" then return true; if proto = "static_nullroute" then return true; if source != RTS_BGP then return false; if martians() then return false; if bgp_path.len > 64 then return false; return bgp_path.first ~ PEER_ASNS; } function rt_export_all() { if proto = "static_links" then return false; if proto = "static_bgp" then return true; if proto = "static_nullroute" then return true; if source != RTS_BGP then return false; if martians() then return false; if bgp_path.len > 64 then return false; return true; } # for outgoing BGP we do not want to announce anything but our own nets filter bgp_out { # SIX nullrouting: https://www.seattleix.net/blackholing if (ASN,666) ~ bgp_community && net.len = 32 && our_network() then { bgp_community = -empty-; bgp_community.add((65535,666)); } # only allow our networks that are statically configured to be announced if ! rt_export() then { reject; } accept; } filter sink { reject; } # anything that is announced via the UTRS peer that has the community 64496:0 set # and is a /32 is null-routed filter bgp_in_utrs_bl { if (64496,0) ~ bgp_community && net.len = 32 then { dest = RTD_BLACKHOLE; accept; } else reject; } filter bgp_out_utrs_bl { if (ASN,666) ~ bgp_community && net.len = 32 && our_network() then { bgp_community = -empty-; bgp_community.add((ASN,0)); accept; } else reject; } filter bgp_nullroute { if (ASN,666) ~ bgp_community && net.len = 32 && our_network() then { accept; } else reject; } -- micah 0. https://team-cymru.com/community-services/utrs/getting-started/

1 0

A study on community-triggered updates in BGP
by Thomas Krenc 19 Oct '20

19 Oct '20

Dear BIRD users and developers, As a team of researchers from NPS and TU Berlin, we are investigating the impact of BGP community attributes on the update behavior between ASes. We find that when a route is associated with multiple distinct community attributes it does not only lead to multiple announcement at the tagging AS, but also at neighboring ASes, if communities are not filtered properly. This behavior is wide-spread. In order to better understand our observations, we have performed a series of laboratory experiments using Cisco IOS, Junos OS, as well as the BIRD daemon. We find that - by default - all routers generate announcements with changing community attributes, even when other attributes do not change. In addition, when communities are filtered at egress, Cisco und BIRD send duplicate announcements (Juniper does not). Is this side-effect known to the BIRD community and would you consider it a bug or a feature? Since our findings are limited to observations in public data as well as few router implementations, we would like to share our research and kindly ask you to have a look at: https://www.cmand.org/communityexploration/ There, we provide some resources documenting our research, as well as open questions. We greatly appreciate any feedback and insights you can offer. Also, please don't hesitate to contact us directly: communityexploration AT cmand DOT org best regards Thomas Krenc Postdoctoral Researcher Naval Postgraduate School

2 3

roa_check RPKI
by Fabiano D'Agostino 11 Oct '20

11 Oct '20

How does roa_check(roa_table,net,bgp_path.last) work? Having such a ROA as example: origin AS: 64513 prefix: 78.150.40.0/20 max mask: 24 and a BGP announcement: origin AS: 64514 prefix: 78.150.45.0/22 so it's as invalid, but how does this check work? roa_table: validated roa record (validated cache) net: should be the current prefix so 78.150.45.0/22 what is bgp_path.last and how does roa_check function do the check? Thanks, Fabiano

2 3