December 2023 - Bird-users

BGP: Only possible to set neigbor once
by Nico Schottelius 31 Dec '23

31 Dec '23

Hello again, in the bird documentation for BGP it says: -------------------------------------------------------------------------------- neighbor [ip | range prefix] [port number] [as number] [internal|external] ... Like local parameter, this parameter may also be used multiple times with different sub-options. ... -------------------------------------------------------------------------------- That is however not possible, as can be seen : -------------------------------------------------------------------------------- blind:/home/nico# bird -c ./bird.conf bird: ./bird.conf:3:28 Only one neighbor per BGP instance is allowed blind:/home/nico# cat bird.conf protocol bgp client1 { neighbor 10.0.1.1 as 65000; neighbor 10.0.1.2 as 65000; ipv4; } -------------------------------------------------------------------------------- So my question is, is - a) the documentation wrong - b) the code wrong or - c) the reader wrong? Best regards, Nico p.s.: tested on bird 2.14 -- Sustainable and modern Infrastructures by ungleich.ch

3 2

Filters for decentralised networking
by Nico Schottelius 29 Dec '23

29 Dec '23

Hello everyone, I was wondering how you typically handle announcing a decentralised infrastructure to its upstreams / the Internet and how you handle receiving your own routes again on other upstreams. The scenario is as follows: CUSTOMER PEERINGS 1 ------ AS P6 --- CUSTOMER PEERINGS 2 | / | / AS P5 ---- AS P10 --- UPSTREAM 1 | \ / \ | AS P7---\ \ |------------ AS P15 --- UPSTREAM 2 \ ---- UPSTREAM 3 \ ---- UPSTREAM 4 So essentialy the different AS are somewhat connected internally (*) (not full mesh due to physical constraints) and the objective is to announce all internal and all customer peerings to all upstreams. Do you a) use sophisticated filters including path length / specific ASN entries to announce to upstreams? One particular issue this approach is that the path lengths vary a bit, depending on where you are and where the upstream is and whether it's a customer announced route or an internally (*) announced one. b) use a separate routing table that you announce fully to the upstreams? c) do something completely differently? And what is your approach to prevent receiving and re-announcing your own (*) routes from upstreams? From my perspective sometimes it might be better to use the upstream for internal routes, if the internal network has trouble, but re-announcing it to the outside is certainly not wanted. Looking forward to read how you solve this in your setups! Best regards, Nico (*) With "own" and "internal" I do not refer to iBGP, as the network consists of multiple AS, all carrying an individual ASN themselves. While they are all controlled by us, they are using eBGP between the different locations. -- Sustainable and modern Infrastructures by ungleich.ch

2 2

OSPF: neighborship issues with interfaces bound to VRF
by Erik Stomp 29 Dec '23

29 Dec '23

Hello, I'm trying to establish OSPFv3 neighborships between hosts connected with PTP tunnels. The OSPF instances using interfaces that are attached to a VRF on each host. There was a similar thread in 2020, however the author didn't respond to a question by Ondrej: https://bird.network.cz/pipermail/bird-users/2020-March/014384.html I can confirm that the issue exists at least on Wireguard and GRE PTP tunnels fully attached to the VRF master interface. This issue only exists with interfaces bound to a VRF. A similar OSPF instance with interfaces that arent bound to a VRF works flawlessly. This is the relevant configuration for the instance: "SRV-FRA1": protocol ospf v3 dfz { vrf "vrf-dfz"; area 0 { interface "lodfz" { stub; }; interface "wgdfzhome" { type ptmp; cost 20; neighbors { fe80::f806:ac67:55bb:847; }; }; interface "dfznbg1" { type ptp; }; }; ipv6 { table dfz6; import where net != ::/0; export where source = RTS_STATIC && net = ::/0; }; } "SRV-NBG1": protocol ospf v3 dfz { vrf "vrf-dfz"; area 0 { interface "lodfz" { stub; }; interface "wgdfzhome" { type ptmp; cost 20; neighbors { fe80::6af0:4be5:bd4a:eff7; }; }; interface "dfzfra1" { type ptp; }; }; ipv6 { table dfz6; import where net != ::/0; export where source = RTS_STATIC && net = ::/0; }; } The interfaces "dfznbg1" and "dfzfra1" are GRE tunnel interfaces connected to each other. The neighbourship fully establishes when I'm using the PTMP type with a fixed neighbor definition instead (like interface "wgdfzhome" - different host). It doesn't matter, if the protocol has the vrf parameter configured or not (I think in this configuration it's optional nevertheless). The hosts however, get Hello messages from each other in ptp mode: root@srv-fra1:~# tcpdump -vni dfznbg1 tcpdump: listening on dfznbg1, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes 11:46:19.563505 IP6 (class 0xc0, flowlabel 0x6da57, hlim 1, next-header OSPF (89) payload length: 36) srv-fra1 > ff02::5: OSPFv3, Hello, length 36 Router-ID 10.242.1.3, Backbone Area Options [V6, External, Router, AFs Support] Hello Timer 10s, Dead Timer 40s, Interface-ID 0.0.0.46, Priority 1 11:46:22.224801 IP6 (class 0xc0, flowlabel 0x50f52, hlim 1, next-header OSPF (89) payload length: 36) srv-nbg1 > ff02::5: OSPFv3, Hello, length 36 Router-ID 10.242.1.2, Backbone Area Options [V6, External, Router, AFs Support] Hello Timer 10s, Dead Timer 40s, Interface-ID 0.0.0.17, Priority 1 11:46:29.563357 IP6 (class 0xc0, flowlabel 0x6da57, hlim 1, next-header OSPF (89) payload length: 36) srv-fra1 > ff02::5: OSPFv3, Hello, length 36 Router-ID 10.242.1.3, Backbone Area Options [V6, External, Router, AFs Support] Hello Timer 10s, Dead Timer 40s, Interface-ID 0.0.0.46, Priority 1 11:46:32.224643 IP6 (class 0xc0, flowlabel 0x50f52, hlim 1, next-header OSPF (89) payload length: 36) srv-nbg1 > ff02::5: OSPFv3, Hello, length 36 Router-ID 10.242.1.2, Backbone Area Options [V6, External, Router, AFs Support] Hello Timer 10s, Dead Timer 40s, Interface-ID 0.0.0.17, Priority 1 11:46:39.563020 IP6 (class 0xc0, flowlabel 0x6da57, hlim 1, next-header OSPF (89) payload length: 36) srv-fra1 > ff02::5: OSPFv3, Hello, length 36 Router-ID 10.242.1.3, Backbone Area Options [V6, External, Router, AFs Support] Hello Timer 10s, Dead Timer 40s, Interface-ID 0.0.0.46, Priority 1 root@srv-nbg1:~# tcpdump -vni dfzfra1 tcpdump: listening on dfzfra1, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes 11:46:19.573221 IP6 (class 0xc0, flowlabel 0x6da57, hlim 1, next-header OSPF (89) payload length: 36) srv-fra1 > ff02::5: OSPFv3, Hello, length 36 Router-ID 10.242.1.3, Backbone Area Options [V6, External, Router, AFs Support] Hello Timer 10s, Dead Timer 40s, Interface-ID 0.0.0.46, Priority 1 11:46:22.230884 IP6 (class 0xc0, flowlabel 0x50f52, hlim 1, next-header OSPF (89) payload length: 36) srv-nbg1 > ff02::5: OSPFv3, Hello, length 36 Router-ID 10.242.1.2, Backbone Area Options [V6, External, Router, AFs Support] Hello Timer 10s, Dead Timer 40s, Interface-ID 0.0.0.17, Priority 1 11:46:29.573123 IP6 (class 0xc0, flowlabel 0x6da57, hlim 1, next-header OSPF (89) payload length: 36) srv-fra1 > ff02::5: OSPFv3, Hello, length 36 Router-ID 10.242.1.3, Backbone Area Options [V6, External, Router, AFs Support] Hello Timer 10s, Dead Timer 40s, Interface-ID 0.0.0.46, Priority 1 11:46:32.230598 IP6 (class 0xc0, flowlabel 0x50f52, hlim 1, next-header OSPF (89) payload length: 36) srv-nbg1 > ff02::5: OSPFv3, Hello, length 36 Router-ID 10.242.1.2, Backbone Area Options [V6, External, Router, AFs Support] Hello Timer 10s, Dead Timer 40s, Interface-ID 0.0.0.17, Priority 1 11:46:39.572741 IP6 (class 0xc0, flowlabel 0x6da57, hlim 1, next-header OSPF (89) payload length: 36) srv-fra1 > ff02::5: OSPFv3, Hello, length 36 Router-ID 10.242.1.3, Backbone Area Options [V6, External, Router, AFs Support] Hello Timer 10s, Dead Timer 40s, Interface-ID 0.0.0.46, Priority 1 It seems to me that bird doesn't process the multicast packets when interfaces are bound to a VRF. But that's just a speculation. root@srv-fra1:~# bird --version BIRD version 2.0.12 "Since I get a fully functional neighborhood with the above PTMP configuration, this is certainly not critical (even considering the protocol differences between modes) - but I think it's worth a look?" If you need more information, just let me know. Best wishes for 2024 from Germany. Regards, Erik

1 0

Use of Alice-LG and birdwatcher in the Bird2 series
by まほろば工房後迫 26 Dec '23

26 Dec '23

Hello all, I have been using Bird1 series + Alice + birdwatcher configuration as ULG. With Bird2 series, since Bird does not separate processes by IPv4 and IPv6, will it be impossible to separate the display method in Alice by IPv4 and IPv6? I changed the birdwatcher to the Docker one that is said to support the Bird2 series, but there is no sample configuration of Alice for the Bird2 series, and I do not know how to separate the API specification for IPv4 and IPv6.

1 0

Routes aggregation
by Dmitry Galenko 23 Dec '23

23 Dec '23

Hello, may someone explain how to correct use of new aggregation protocol? I need aggregate all routes from table all_bg and push result to all_bg_aggr, for now look like aggregation is not working. May someone explain what I do wrong? Here is my bird.conf: ```log "/var/log/bird.log" { debug, trace, info, remote, warning, error, auth, fatal, bug }; router id 192.168.111.10; # debug protocols all; # debug protocols { events, states }; # watchdog warning 5 s; # watchdog timeout 30 s; ipv4 table all_bg_aggr; ipv4 table all_bg; filter NEXT_HOP_OVERRIDE { if ( true ) then { gw = 192.168.111.254; accept; } reject; } protocol device { } protocol direct { disabled; ipv4; ipv6; } protocol kernel { ipv4 { import none; export none; }; } protocol static legacy_bg { ipv4 { table all_bg; import filter NEXT_HOP_OVERRIDE; }; include "/etc/bird/legacy.conf"; } protocol static custom_bg { ipv4 { table all_bg; import filter NEXT_HOP_OVERRIDE; }; include "/etc/bird/custom.conf"; } protocol static aws_bg { ipv4 { table all_bg; import filter NEXT_HOP_OVERRIDE; }; include "/etc/bird/aws.conf"; } protocol static fastly_bg { ipv4 { table all_bg; import filter NEXT_HOP_OVERRIDE; }; include "/etc/bird/fastly.conf"; } protocol static cloudflare_bg { ipv4 { table all_bg; import filter NEXT_HOP_OVERRIDE; }; include "/etc/bird/cloudflare.conf"; } protocol static mailru_vk_bg { ipv4 { table all_bg; import filter NEXT_HOP_OVERRIDE; }; include "/etc/bird/vk-mrg.conf"; } # Get routes from Antifilter.download protocol bgp antifilter_d_bg { local as 64900; neighbor 45.154.73.71 as 65432 external; multihop; hold time 240; graceful restart; ipv4 { table all_bg; import filter NEXT_HOP_OVERRIDE; export none; }; } # Get routes from Antifilter.network protocol bgp antifilter_n_bg { local as 64900; neighbor 51.75.66.20 as 65444 external; multihop; hold time 240; graceful restart; ipv4 { table all_bg; import filter NEXT_HOP_OVERRIDE; export none; }; } # Aggregate routes protocol aggregator all_bg_aggregator { table all_bg; peer table all_bg_aggr; export all; aggregate on net; merge by { print "Merging all these: ", routes; bgp_med = 0; for route r in routes do { if ! defined(r.bgp_med) then { unset(bgp_med); accept; } print r, " bgp_med: ", r.bgp_med; bgp_med = bgp_med + r.bgp_med; bgp_community = bgp_community.add(r.bgp_community); } accept; }; } # Export routes to Cisco C8000v protocol bgp rr_bg { local as 64900; neighbor 192.168.111.1 as 65137; graceful restart; ipv4 { table all_bg_aggr; import none; export all; }; } ```

1 0

notification scripts ?
by Jérôme Loyet 15 Dec '23

15 Dec '23

Hello, i'm using bird as BGP/BFD client and I'd like to exec some command when something happens in bird. Like up/down script or something like that. Is there something close to that or another notification mechanism that exists ? Thanks ++ jerome

4 6

logging via udp
by Alexander Zubkov 13 Dec '23

13 Dec '23

Hello, Made some dirty patch for myself to allow bird to send logs via udp. But it may be useful not only for me, so posting it here. It could be useful when server experiencing high IO-load. As syslog and file operations in bird are blocking, it can be blocked on writing to it for indefinite time, which could lead to various problems like protocol timeouts. So udp logging comes in handy here. The tradeoff is that we can miss some logs if they are not processed in time. You can specify udp log destination like that: log udp [host IP|"hostname"] [port NUMBER|"portname"] ... By default it uses destination ip 127.0.0.1 and port 514. There are some constraints like not much error handling. And this destination replaces file destination, i.e. you can not use those simultaneously and it may leak descriptors and some memory probably if both are specified. It also makes a new socket every time configuration is reloaded even if there is no change in options, but this is not a great deal.

2 9

Re: notification scripts ?
by Maria Matejka 13 Dec '23

13 Dec '23

Hello! On 2023-12-13 10:19, Kees Meijs | Nefos wrote: > Hi, > > On 12-12-2023 17:20, Maria Matejka via Bird-users wrote: >> We're prototyping a machine-friendly interface which should include, >> in some later versions, also subscribing to various notifications. > > Hear hear! Probably asked before, but being integrated (albeit with a > shim) in SNMP would be lovely. We are finishing some SNMP support as well but mostly we're trying to have a YANG-defined API encoded in CBOR. And because this is quite a new technology, we may create some relevant tools during the process; if anybody is interested in some specifics, we may keep you informed about the development. Maria -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

3 3

wireguard + multihop BGP = route rejected, but route created
by Ivan Agarkov 10 Dec '23

10 Dec '23

Hello! I'm creating a BGP lab for my students and found interesting and unexpected behavior. I'm getting reject message when receiving route: 2023-12-10 15:10:53.724 <TRACE> isp1.ipv4 > added [best] 10.200.0.0/16 0L 4G unicast 2023-12-10 15:10:53.724 <TRACE> isp1.ipv4 < rejected by protocol 10.200.0.0/16 0L 4G unicast But then the route appears in ip route: 10.200.0.0/16 dev 201 proto bird scope link metric 32 I've dug into the source code and found that the reject is happening here: proto/bgp/attrs.c:1641 if (src == p) return -1 into bgp_preexport function. The question is: what is happening and does it look valid/expected? Wireguard configuration is the same on all peers: [Interface] Address=10.10.10.201/32 PrivateKey=****** Table=off [Peer] Endpoint=******* PublicKey=***** PersistentKeepalive=25 AllowedIPs=0.0.0.0/0 My configuration for BIRD peers: ==== local bird.conf ==== log stderr all; router id 10.10.10.201; protocol device { scan time 10; } protocol kernel { ipv4 { import all; export all; }; learn; } protocol static { ipv4; route 10.201.0.0/16 via "wlp41s0"; # wifi device route 10.10.10.0/24 via "201"; # wireguard device } protocol bgp isp1 { router id 10.10.10.201; local 10.10.10.201 as 65201; neighbor 10.10.10.200 as 65200; source address 10.10.10.201; multihop; ipv4 { import filter { if net ~ 10.0.0.0/8 then accept; else reject; }; export filter { if net ~ 10.201.0.0/16 then accept; else reject; }; }; debug all; } ==== /client bird.conf ==== ==== remote bird.conf ==== log stderr all; protocol kernel { learn; # Learn all alien routes from the kernel persist; # Don't remove routes on bird shutdown scan time 20; # Scan kernel routing table every 20 seconds import all; # Default is import all export all; # Default is export none # kernel table 5; # Kernel table to synchronize with (default: main) } protocol device { scan time 10; } protocol static { export all; route 10.10.10.0/24 via "200"; # wireguard device route 10.200.0.0/16 via 10.200.200.200; # virtual network } template bgp cpr_ne { local as 65200; router id 10.10.10.200; multihop; source address 10.10.10.200; import filter { if net ~ 10.201.0.0/16 then accept; else if net ~ 10.202.0.0/16 then accept; else if net ~ 10.203.0.0/16 then accept; else if net ~ 10.204.0.0/16 then accept; else if net ~ 10.205.0.0/16 then accept; else if net ~ 10.206.0.0/16 then accept; else if net ~ 10.207.0.0/16 then accept; else if net ~ 10.208.0.0/16 then accept; else reject; }; export filter { if net ~ 10.200.0.0/16 then accept; else reject; }; } protocol bgp cpr201 from cpr_ne { neighbor 10.10.10.201 as 65201; } protocol bgp cpr202 from cpr_ne { neighbor 10.10.10.202 as 65202; } protocol bgp cpr203 from cpr_ne { neighbor 10.10.10.203 as 65203; } protocol bgp cpr204 from cpr_ne { neighbor 10.10.10.204 as 65204; } protocol bgp cpr205 from cpr_ne { neighbor 10.10.10.205 as 65205; } protocol bgp cpr206 from cpr_ne { neighbor 10.10.10.206 as 65206; } protocol bgp cpr207 from cpr_ne { neighbor 10.10.10.207 as 65207; } protocol bgp cpr208 from cpr_ne { neighbor 10.10.10.208 as 65208; } ==== remote bird.conf ====

2 1

dump size in bgp_log_error()
by Marco d'Itri 07 Dec '23

07 Dec '23

bgp_log_error() in proto/bgp/packets.c attempts to dump the message received from the neighbor, in this case containing the BGP attribute considered invalid: bird[681]: PEERNAME: Received: Malformed AS_PATH: 40021a020600001b1b00008b0e00008b but the hex dump is limited to 16 characters and this makes impossible to know exactly what the neighbor is complaining about: if (len > 16) len = 16; It makes sense to limit the size of log messages, but please make the limit much higher because I am sure that we can all spare the space. -- ciao, Marco

2 1