- Bird-users - Mailing Lists

ospfv2 , log neighbour state change
by Dmitry Melekhov 21 May '24

21 May '24

Hello! Could you tell me how can I log neighbour state change to see in logs something like I have with quagga: OSPF: nsm_change_state(192.168.222.199, Full -> Deleted): scheduling new router-LSA origination Thank you!

2 2

Route matching filter not exported
by Nico Schottelius 17 May '24

17 May '24

Hello bird users, I've a strange case in which a router does not export routes that are matched by the export filter. I am using the filter "static_and_bgp" inside our iBGP sessions: -------------------------------------------------------------------------------- bird> show protocol all ibgp_server137 Name Proto Table State Since Info ibgp_server137 BGP --- up 2024-05-12 Established BGP state: Established Neighbor address: 2a0a:e5c0:0:b::89 Neighbor AS: 199553 Local AS: 199553 Neighbor ID: 91.194.139.7 Local capabilities Multiprotocol AF announced: ipv4 ipv6 Route refresh Extended next hop IPv6 nexthop: ipv4 Graceful restart 4-octet AS numbers Enhanced refresh Long-lived graceful restart Neighbor capabilities Multiprotocol AF announced: ipv4 ipv6 Route refresh Extended next hop IPv6 nexthop: ipv4 Graceful restart 4-octet AS numbers Enhanced refresh Long-lived graceful restart Session: internal AS4 Source address: 2a0a:e5c0:0:b::91 Hold timer: 197.601/240 Keepalive timer: 4.476/80 Channel ipv6 State: UP Table: master6 Preference: 100 Input filter: ACCEPT Output filter: static_and_bgp Routes: 204647 imported, 2 exported, 204647 preferred Route change stats: received rejected filtered ignored accepted Import updates: 6285634 0 0 3097 6282537 Import withdraws: 3559063 0 --- 189 3558874 Export updates: 6768067 6387362 37995 --- 342710 Export withdraws: 3370586 --- --- --- 334365 BGP Next hop: 2a0a:e5c0:0:b::91 fe80::2f0:cbff:fefe:b70c IGP IPv6 table: master6 Channel ipv4 State: UP Table: master4 Preference: 100 Input filter: ACCEPT Output filter: static_and_bgp Routes: 947321 imported, 3 exported, 947318 preferred Route change stats: received rejected filtered ignored accepted Import updates: 22332349 0 0 2202 22330147 Import withdraws: 15475598 0 --- 343 15475255 Export updates: 24213451 22602108 0 --- 1611343 Export withdraws: 14527850 --- --- --- 1598351 BGP Next hop: 2a0a:e5c0:0:b::91 fe80::2f0:cbff:fefe:b70c IGP IPv4 table: master4 IGP IPv6 table: master6 -------------------------------------------------------------------------------- As you can see, the router in question only exports 2 IPv6 routes and 3 IPv4 routes and uses the filter "static_and_bgp". When I check the route count matching the filter, the numbers look very different: -------------------------------------------------------------------------------- bird> show route filter static_and_bgp count 2841971 of 2841971 routes for 947325 networks in table master4 613945 of 613983 routes for 204686 networks in table master6 Total: 3455916 of 3455954 routes for 1152011 networks in 2 tables bird> -------------------------------------------------------------------------------- And looking at some routes in detail: -------------------------------------------------------------------------------- bird> show route filter static_and_bgp Table master4: 0.0.0.0/0 unicast [ibgp_server137 11:03:59.224 from 2a0a:e5c0:0:b::89] * (100/?) [AS209898i] via fe80::3eec:efff:fed2:d1e4 on eth0 unicast [outgoing_server120 08:53:28.568] (100) [AS209898i] via 2a0a:e5c0:31:4::1 on tun1 unicast [outgoing_server121 08:55:44.577] (100) [AS209898i] via 2a0a:e5c0:32:4::1 on tun0 49.14.107.0/24 unicast [ibgp_server137 11:03:59.224 from 2a0a:e5c0:0:b::89] * (100/?) [AS45271i] via fe80::3eec:efff:fed2:d1e4 on eth0 unicast [outgoing_server120 08:55:43.482] (100) [AS45271i] via 2a0a:e5c0:31:4::1 on tun1 unicast [outgoing_server121 08:55:44.577] (100) [AS45271i] via 2a0a:e5c0:32:4::1 on tun0 181.123.200.0/22 unicast [ibgp_server137 11:03:59.224 from 2a0a:e5c0:0:b::89] * (100/?) [AS23201i] via fe80::3eec:efff:fed2:d1e4 on eth0 unicast [outgoing_server120 08:55:30.698] (100) [AS23201i] via 2a0a:e5c0:31:4::1 on tun1 unicast [outgoing_server121 08:55:44.577] (100) [AS23201i] via 2a0a:e5c0:32:4::1 on tun0 88.218.186.0/24 unicast [ibgp_server137 11:03:59.224 from 2a0a:e5c0:0:b::89] * (100/?) [AS62240i] via fe80::3eec:efff:fed2:d1e4 on eth0 unicast [outgoing_server120 08:55:22.108] (100) [AS62240i] via 2a0a:e5c0:31:4::1 on tun1 unicast [outgoing_server121 08:55:44.577] (100) [AS62240i] via 2a0a:e5c0:32:4::1 on tun0 -------------------------------------------------------------------------------- I verified that 2a0a:e5c0:31:4::1 and 2a0a:e5c0:32:4::1 are resolvable via OSPF on the other routers: -------------------------------------------------------------------------------- bird> show route for 2a0a:e5c0:32:4::1 Table master6: 2a0a:e5c0:32:4::/64 unicast [ospf6 2024-05-12] * I (150/20) [91.194.139.99] via fe80::2f0:cbff:fefe:b70c on eth2 unicast [outgoing_server120 11:11:16.933] (100) [AS209898i] via 2a0a:e5c0:31:2::1 on oserver120 bird> -------------------------------------------------------------------------------- But this should not matter at this stage, because the originating router does not seem to try to send this route. What am I missing, why is a route matching the same filter not being exported? Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch

2 7

BGP on /32 (/128) interfaces
by Arzhel Younsi 17 May '24

17 May '24

Hi, A message between bug report and feature request, unless it's a silly oversight on my side. On Linux it's possible to configure interfaces with /32 (or v6 /128) IPs. I detailed our use-case and examples on https://phabricator.wikimedia.org/phame/post/view/312/ganeti_on_modern_netw… if you're curious. So focusing on v4 only for now I have this configuration on a VM: testvm2006:~$ ip addr inet 10.192.24.4/32 brd 10.192.24.4 scope global ens13 testvm2006:~$ ip route default via 10.192.24.1 dev ens13 onlink And this on the hypervisor (but it could also be 2 physical servers, or a router and a server) : ganeti2033:~$ ip addr inet 10.192.24.1/32 scope link tap0 ganeti2033:~$ ip route 10.192.24.4 dev tap0 proto static scope link Note that 10.192.24.1 is close to 10.192.24.4, but they could be totally different IPs (see the v6 example bellow). Overall connectivity works well, TCP handshake as well: testvm2006:~$ nc -zv 10.192.24.1 179 Connection to 10.192.24.1 179 port [tcp/bgp] succeeded! The issue is that with a basic configuration like: protocol bgp { ipv4 { import none; export none; }; local 10.192.24.4 as 64613; neighbor 10.192.24.1 external; } Bird 2.0.12 doesn't try to established the session, and waits with: 2024-04-12T08:42:29.497756+00:00 testvm2006 bird: bgp1: Waiting for 10.192.24.1 to become my neighbor For IPv4 it's possible to workaround the issue by setting the session as "multihop;" on both side bgp1: Connecting to 10.192.24.1 from local address 10.192.24.4 bgp1: Connected bgp1: Sending OPEN(ver=4,as=64613,hold=240,id=0ac01804) bgp1: Got OPEN(as=64612,hold=240,id=10.192.21.6) bgp1: Sending KEEPALIVE bgp1: Got KEEPALIVE bgp1: BGP session established But for IPv6, it's cleaner to only require the router's link local address: testvm2006:~$ ip -6 addr inet6 2620:0:860:140:10:192:24:4/128 scope global testvm2006:~$ ip -6 route default via fe80::2022:22ff:fe22:2201 dev ens13 metric 1024 pref medium In Bird: neighbor fe80::2022:22ff:fe22:2201%ens13 external; But then the link local address doesn't work with multihop (for obvious reason). bird: /etc/bird/bird.conf:22:1 Multihop BGP cannot be used with link-local addresses The question is then, would it be possible to support that usecase, something along the lines of if the local IP is a /32 (or v6 /128), Treat the neighbor as directly connected, especially if it's a link local IP (unless nultihop is specified). I haven't looked at BFD yet, so not sure if anything would need to change there as well. Don't hesitate to ask if something needs any clarifications. Thank for that great tool, Bird is awesome, -- Arzhel

5 6

use TCP_NODELAY on TCP sockets?
by Job Snijders 16 May '24

16 May '24

Dear BIRD people, On most systems RFC 896 TCP congestion control is used, also known as "Nagle's algorithm". This algorithm is intended to help coalesce consecutive small packets from userland applications (like BIRD) into a single larger TCP packet. The idea being it reduces bandwidth because there is less TCP overhead if data is bundled into fewer packets. This happens at the cost of an increase in end-to-end latency: the sender will locally queue up data (in the operating system's TCP buffers) until it either receives a TCP Ack from the remote side for all previously sent data, or sufficient additional data piled up to send out a full-sized TCP segment. In my simple testing setup (announce 255 routes to a peer) with this patch it takes ~ 0.007478 seconds after SYN to send the UPDATE message out. Without this patch, it takes ~ 0.206955 seconds to send the UPDATE out (perhaps because of negative interaction between Nagle's algorithm and Delayed Acks?). I think using TCP_NODELAY is interesting to consider, because it seems sensible to try to deliver BGP messages as fast as possible. OpenBGPD and FRR set the TCP_NODELAY socket option. But please be very careful in considering this patch, because it does introduce some subtle changes in the on-the-wire behaviour of BIRD. For example, without this patch an UPDATE for a handful of routes and the End-of-RIB marker might end up in the same TCP packet (if this fits); but with this patch, the End-of-RIB marker ends up in its own TCP packet. As things are today, setting TCP_NODELAY will increase the average number of packets send to peers. Packing multiple BGP messages into fewer TCP frames could perhaps be reintroduced by using writev() instead of write(), when it is known a bunch of messages have been queued up for a peer. Another complex behaviour is that the effect of the Nagle algorithm depends on latency between local system and remote system. Nagle's algorithm makes it so that data is locally buffered as long as the remote side has not yet acked all previously sent data; this means that proportional to the distance (latency) chances of message coalescence increase. Without this patch BIRD will send more individual TCP packets to peers that are close by compared to peers that are far away. But with TCP_NODELAY applied, all peers will receive the same number of TCP packets, regardless of latency. Look forward to hear your thoughts! Kind regards, Job sysdep/unix/io.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/sysdep/unix/io.c b/sysdep/unix/io.c index 9b499020..f9746cb7 100644 --- a/sysdep/unix/io.c +++ b/sysdep/unix/io.c @@ -946,7 +946,7 @@ sock_new(pool *p) static int sk_setup(sock *s) { - int y = 1; + int y = 1, nodelay = 1; int fd = s->fd; if (s->type == SK_SSH_ACTIVE) @@ -1048,6 +1048,10 @@ sk_setup(sock *s) return -1; } + if ((s->type == SK_TCP_PASSIVE) || (s->type == SK_TCP_ACTIVE)) + if (setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &nodelay, sizeof(nodelay)) < 0) + ERR("TCP_NODELAY"); + /* Must be after sk_set_tos4() as setting ToS on Linux also mangles priority */ if (s->priority >= 0) if (sk_set_priority(s, s->priority) < 0)

6 9

Cannot locate output from "birdc dump"
by christian2 14 May '24

14 May '24

Hello, I would like to inspect BIRD's neighbor cache with "birdc dump neighbors". However, I can see no ouput. There are appearances of "<TRACE> CLI: dump neighbors" in the configured log file but no actual dumps. This is also true for "dump resources" and "dump protocols" (even though "show protocols" does list several protocols). What am I missing? This is for BIRD 2.15.1. Thanks/Děkuji, Christian

2 1

community matching
by skanda 11 May '24

11 May '24

Hi Bird experts, If I want match two communities, how does the syntax works in bird ? standard communities to matched 6509:4804 and 6509:4810 Is it like this What are the pair inside the brackets means? Or filter labips { if (([(65001,4809, 4810)] ~ bgp_community) then accept }

2 2

Migration from 1.6.8 to 2.x
by bird21＠sensation.net.au 11 May '24

11 May '24

Hi everyone, I currently have a relatively simple IPv4 BGP setup on BIRD 1 (importing default, advertising a single /24), but now that I will be routing IPv6 for the first time, I thought it may be worth considering moving to BIRD 2. I am having trouble finding information on how to migrate. Although the wiki does contain some notes on this, the sample configs in the wiki are 10 years old and appear to be for BIRD 1 only. It would be really handy to see functionally identical sample configs for both BIRD 1 and BIRD 2 in the wiki; the post in this thread kind of does it: https://bird.network.cz/pipermail/bird-users/2020-January/014171.html I recall a release announcement posted to this list some months ago (maybe even more than a year) which encouraged people to migrate to 2.x, and offered some details on how to do it, but I cannot seem to find it now. Is there a better resource than the wiki for this? ...and since my setup is simple, I'm wondering if maybe I should just run a second 1.6.8 daemon for IPv6...? Thanks.

1 0

Running BIRD on different namespaces
by Vishakha Hegde 08 May '24

08 May '24

Hi all, I'm looking for some guidance on running two separate instances of BIRD in two different network namespaces. Do you think it's better to specify two different config files for each namespace, or can I manage both instances using a single config file? I've tried using the following commands to run different config files: sudo ip netns exec netns1 bird -c /etc/bird/bird1.conf sudo ip netns exec netns2 bird -c /etc/bird/bird2.conf But it gives the error: I found another BIRD running, so it looks like BIRD can have only a single process running at once. Any insights on how to resolve this? Thanks!

2 1

IPv6 OSPF stub interface not taken into account
by Alarig Le Lay 06 May '24

06 May '24

Hello, I have two OSPF protocols, one for IPv4 and one for IPv6. I’ve set the lo interface for both, but it only shows up for IPv4: protocol ospf ospf_ipv4 { merge external; ipv4 { import all; import keep filtered; import limit 200 action block; import filter { if (net ~ [ 0.0.0.0/0 ]) then { reject; } else { igp_metric = ospf_metric1; accept; } }; export all; export filter { if (proto = "kernel_grt_ipv4" || proto = "direct1") then { ospf_metric2 = 64; ospf_tag = 1336561914; accept; } else reject; }; }; area 0.0.0.0 { interface "lo" { stub; }; include "/etc/bird.lag-*.conf"; interface "wg0" { cost 200; }; }; }; protocol ospf v3 ospf_ipv6 { merge external; ipv6 { import all; import keep filtered; import limit 200 action block; import filter { if (net ~ [ ::/0 ]) then { reject; } else { igp_metric = ospf_metric1; accept; } }; export filter { if (proto = "kernel_grt_ipv6" || proto = "direct1") then { ospf_tag = 1336561914; accept; } else reject; }; }; area 0.0.0.0 { interface "lo" { stub; }; include "/etc/bird.lag-*.conf"; interface "wg0" { cost 200; }; }; }; edge03-stolon ~ # birdc BIRD 2.15.1 ready. bird> show ospf interface ospf_ipv6 "lo" ospf_ipv6: bird> show ospf interface ospf_ipv4 "lo" ospf_ipv4: Interface lo (45.91.126.241/32) Type: nbma Area: 0.0.0.0 (0) State: Waiting (stub) Priority: 1 Cost: 10 ECMP weight: 1 Hello timer: 10 Poll timer: 20 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 Designated router (ID): 0.0.0.0 Designated router (IP): 0.0.0.0 Backup designated router (ID): 0.0.0.0 Backup designated router (IP): 0.0.0.0 It looks like a bug to me, but perhaps I missed something. -- Alarig

2 2

EVPN support in BIRD
by Ondrej Zajicek 06 May '24

06 May '24

Hello Recently, we made a beta release of EVPN support in BIRD: https://gitlab.nic.cz/labs/bird/-/tree/evpn (branch 'evpn' in BIRD git repository) You are welcome to try it and give us your feedback and suggestions. The primary documentation is still missing, but there are comprehensive examples and comments here: https://gitlab.nic.cz/labs/bird-tools/-/tree/master/netlab/cf-evpn-bgp (especially bird_m11.conf and bird_m12.conf) For filter expressions related to EVPN, see function t_net_evpn() in: https://gitlab.nic.cz/labs/bird/-/blob/evpn/filter/test.conf If you have any questions, feel free to ask here on the mailing list. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago(a)crfreenet.org) "To err is human -- to blame it on a computer is even more so."

2 3