- Bird-users - Mailing Lists

Current bird via bookworm-backports?
by Oliver Seufer 26 Apr '24

26 Apr '24

Hello, The version 2.0.12 included in Debian Bookworm unfortunately lacks a few current features. I would therefore greatly appreciate it if a Debian package with the latest version could be provided. Either through bookworm-backports or directly through bird.network.cz Is there a possibility that this will be provided by the bird project? Like it was done for Debian Bullseye back then? I greatly appreciate your work on bird, and I also enjoy trying out new features. Best regards, Oliver Seufer

7 11

Re: Current bird via bookworm-backports?
by Chriztoffer Hansen 24 Apr '24

24 Apr '24

Kees, On Wed, 24 Apr 2024 at 14:28, Kees Meijs | Nefos <keesm(a)nefos.nl> wrote: > Would you like a mirror in the Netherlands as well? > > If so, what resources would you need? This is the current size of the individual repo's 679M knot-resolver 3.9G knot-dns 277M bird2 Access via http and https are usually the minimum I see with public repos. ftp, rsync, TOR endpoints are optionally provided. ********************** DotSrc publicises the repo's via http, https, ftp, rsync, and TOR. http://mirrors.dotsrc.org/knot-resolver http://mirrors.dotsrc.org/knot-dns http://mirrors.dotsrc.org/bird2 https://mirrors.dotsrc.org/knot-resolver https://mirrors.dotsrc.org/knot-dns https://mirrors.dotsrc.org/bird2 ftp://mirrors.dotsrc.org/knot-resolver ftp://mirrors.dotsrc.org/knot-dns ftp://mirrors.dotsrc.org/bird2 rsync://mirrors.dotsrc.org/knot-resolver rsync://mirrors.dotsrc.org/knot-dns rsync://mirrors.dotsrc.org/bird2 http://dotsrccccbidkzg7oc7oj4ugxrlfbt64qebyunxbrgqhxiwj3nl6vcad.onion/knot-… http://dotsrccccbidkzg7oc7oj4ugxrlfbt64qebyunxbrgqhxiwj3nl6vcad.onion/knot-… http://dotsrccccbidkzg7oc7oj4ugxrlfbt64qebyunxbrgqhxiwj3nl6vcad.onion/bird2 Cheers, Chriztoffer - Volunteer Foreningen for DotSrc - https://dotsrc.org/

1 0

Re: Current bird via bookworm-backports?
by Chriztoffer Hansen 23 Apr '24

23 Apr '24

A copy to the list On Tue, 23 Apr 2024 at 20:00, <ch(a)dotsrc.org> wrote: > > Dear Jakub, > > Fantastic to hear about the RSYNC option is now available. > > I enabled an RSYNC mirror for our volunteer run MIRROR service - > dotsrc.org - in Denmark. > > https://mirrors.dotsrc.org/bird2/ > > https://mirrors.dotsrc.org/knot-dns/ > > https://mirrors.dotsrc.org/knot-dns/ > > Cheers, > > Chriztoffer - Volunteer > Foreningen for DotSrc - https://dotsrc.org/ > > On Tue, 23 Apr 2024 at 14:50, Jakub Ružička <jakub.ruzicka(a)nic.cz> wrote: > > > > Hello, > > > > I maintain pkg.labs.nic.cz and rsync wasn't supported until today, but > > you're a second user interested in mirroring the repos so I had a look > > and enabled the rsync daemon: > > > > $ rsync rsync://pkg.labs.nic.cz/ > > bird2 "BIRD 2.x Debian & Ubuntu packages repo" > > knot-resolver "Knot Resolver Debian & Ubuntu packages repo" > > knot-dns "Knot DNS Debian & Ubuntu packages repo" > > > > $ rsync -av rsync://pkg.labs.nic.cz/bird2/ bird2-repo > > > > I've also CC'd Arnaud who was interested in this. > > > > Let me know if this setup is working for you, or what needs to be > > changed in order for it to work as users (you) expect. > > > > > > Cheers, > > Jakub Ružička > > > > On 4/18/24 18:41, netravnen%2Bbirdlist(a)gmail.com wrote: > > > Dear Maria, > > > > > > Do you support mirrors (rsync) for your package site at > > > https://pkg.labs.nic.cz/doc/?project=bird ? > > > > > > I am part of a group operating a local mirror in DK. > > > > > > On Thu, 18 Apr 2024 at 14:31, Maria Matejka via Bird-users > > > <bird-users(a)network.cz> wrote: > > >> Hello Oliver, > > >> > > >> On Thu, Apr 18, 2024 at 11:24:31AM +0200, Oliver Seufer via Bird-users wrote: > > >> > > >> Hello, > > >> > > >> The version 2.0.12 included in Debian Bookworm unfortunately lacks a few current features. I would therefore greatly appreciate it if a Debian package with the latest version could be provided. Either through bookworm-backports or directly through bird.network.cz > > >> > > >> Please try this repository:https://pkg.labs.nic.cz/doc/?project=bird > > >> > > >> It should have everything you need. > > >> > > >> Maria > > >> > > >> – Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

1 0

How to interpret `!` in show route when a route was successfully inserted into the kernel table?
by Ivan Kurnosov 22 Apr '24

22 Apr '24

Hi team, can somebody please help interpret the following output: ``` 10.50.0.1/32 unicast [static1 02:16:07.523] * (200) dev xfrm-40 10.240.224.2/32 unicast [hq 02:27:17.417] ! (100/?) [AS65020i] via 10.50.0.1 on xfrm-40 10.240.2.0/24 unicast [hq 02:27:17.417] ! (100/?) [AS65020i] via 10.50.0.1 on xfrm-40 ``` The current (birdc) machine establishes an ipsec tunnel and 10.50.0.1 is a firewall on the other side of the ipsec tunnel. And kernel routes look like ``` 10.50.0.1 dev xfrm-40 proto bird scope link src 10.80.1.76 metric 32 10.240.2.0/24 via 10.50.0.1 dev xfrm-40 proto bird metric 32 10.240.224.2 via 10.50.0.1 dev xfrm-40 proto bird metric 32 ``` So, technically all works: packets flow as expected. It's only the `!` exclamation mark and `(100/?)` question mark that I cannot interpret. Is it something I should worry about? -- With best regards, Ivan Kurnosov

1 1

OSPF bad packet
by Benoit Chesneau 15 Apr '24

15 Apr '24

Hi, I have installed latest bird 2.15.1 with ntet link support on Freebsd and I contunuously get the following messages: ``` 2024-04-14 23:09:12.386 <RMT> ospfv6: Bad packet from fe80::f89b:80ff:fe06:d7f9 via vlan600 - my own router ID (0) 2024-04-14 23:09:12.386 <RMT> ospfv4: Bad packet from 198.19.4.33 via vlan600 - my own router ID (0) 2024-04-14 23:09:12.386 <RMT> ospfv6: Bad packet from fe80::f89b:80ff:fe06:d7f9 via vlan600 - my own router ID (0) 2024-04-14 23:09:12.386 <RMT> ospfv4: Bad packet from 198.19.4.33 via vlan600 - my own router ID (0) 2024-04-14 23:09:18.155 <TRACE> ospfv4: HELLO packet received from nbr 198.19.0.2 on vlan600 2024-04-14 23:09:22.382 <TRACE> ospfv4: HELLO packet sent via vlan600 2024-04-14 23:09:22.383 <RMT> ospfv6: Bad packet from fe80::f89b:80ff:fe06:d7f9 via vlan600 - my own router ID (0) 2024-04-14 23:09:22.383 <RMT> ospfv4: Bad packet from 198.19.4.33 via vlan600 - my own router ID (0) 2024-04-14 23:09:22.383 <RMT> ospfv6: Bad packet from fe80::f89b:80ff:fe06:d7f9 via vlan600 - my own router ID (0)2024-04-14 23:09:22.383 <RMT> ospfv4: Bad packet from 198.19.4.33 via vlan600 - my own router ID ``` What could be the reason for such error? MTU looks fine, and I can retrieve the route via osf. Benoît

3 4

Fwd: Re: babel RTT metric false samples
by Maria Matejka 13 Apr '24

13 Apr '24

(mistakenly sent off-list) -------- Original Message -------- From: Maria Matejka <maria.matejka(a)nic.cz> Sent: 13 April 2024 18:18:05 CEST To: Erin Shepherd <bird-users(a)erinshepherd.net> Subject: Re: babel RTT metric false samples Just quick thought – I think both approaches (timestamping in kernel and in userspace) are actually useful for different purposes. Thus, we shall support both. Transferred to our internal issue: https://gitlab.nic.cz/labs/bird/-/issues/61 Maria On 13 April 2024 16:38:47 CEST, Erin Shepherd <bird-users(a)erinshepherd.net> wrote: >I guess it might not fit with bird's abstractions (or perhaps the Babel protocol), but has thought been given to using SO_TIMESTAMPING to have the kernel compute TX/RX timestamps? > >- Erin > > >On Sat, 13 Apr 2024, at 16:14, Maria Matejka via Bird-users wrote: >> Hello Stephanie, Toke and list, >> >> On Fri, Apr 12, 2024 at 04:22:50PM +0200, Toke Høiland-Jørgensen via Bird-users wrote: >> >>> Stephanie Wilde-Hobbs via Bird-users bird-users(a)network.cz writes: >>> >>>> The babel RTT metric measurements provided by bird appears suspect for my setup. The metric through a tunnel with a latency of about 5ms is shown in babel as 150+ms. >>>> >> […] >> >>>> Debug logs show many RTT samples with approximately correct timestamps (4-6ms) then the occasional IHU with 800-1200ms calculated instead. Calculating the RTT metric by hand using babel packet logs shows that the calculations are correct. By correlating two packet dumps (the machines have <1ms NTP timekeeping) I can also see that the packets for which high RTT is calculated have similar transit times through the tunnel as other packets. Hence, I suspect the accuracy of the packet timestamps recorded by bird. Is the current packet timestamping system giving correct timestamps if the packet arrives while babel is processing another event? >>>> >>> Hmm, so Babel implementation in Bird tries to get a timestamp as early as possible after receiving the packet, and set it as late as possible before sending out the packet. However, the former in practice means after returning from poll(), so if the packet has been sitting around in the OS buffer for a while before Bird gets around to process it, the timestamp is not set until Bird is done processing it. Likewise, if the packet sits around in a socket buffer (or in a lower-level buffer on the sending side) after Bird has sent it out, that time will also be counted as part of the RTT. >>> >> I would suspect that the kernel table prune routine may be the case. It just runs from begin to end synchronously. >> >> I have just fast-tracked Babel in its own thread for BIRD 3, it may be worth checking. (There should be also artifacts from the build process for download available.) This should get you rid of most of the cases of suspiciously high RTT. >> >> `https://gitlab.nic.cz/labs/bird/-/tree/babel-in-threads` >> Just to be noted, updating a route in BIRD 3 is still a locking process so it may still tamper the RTT measurements. At least it should happen only in cases where Babel is doing the update. Anyway, with BIRD 3 internals, it should be possible to easily *detect* such situations and disregard these single measurements as unreliable. (Not implemented, though.) >> >> There are even some thoughts on implementing lockless import queues for routing tables, yet now we have to prioritize BIRD 3 stabilization to actually release it as a stable version. Import queues must wait. >> >> Also with this testing, feel free to report any weird behavior, notably crashes of BIRD 3, as bugs. That would be very helpful with stabilizing BIRD 3. Thanks a lot! >> >> Maria >> >> – Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o. >> -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o. -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

1 0

memcpy uses value of mls (mpls label stack) instead of address
by Ramanathan Selvamani 12 Apr '24

12 Apr '24

Hi Team, I have tried to use mpls_label_stack to keep some meta data for each route. But the values of meta data were not copied correctly. I just found the below code in "rt_next_hop_update_rte" function in rt-table.c memcpy(*mls.**stack*, &a->nh.label[a->nh.labels - mls.len], mls.len * sizeof (u32)); Here the "mls.stack" is passed directly instead of its address in memcpy. Kindly let me know your thoughts on this. Thanks, Ramanathan

2 2

2.0 user's guide shows incorrect date format for passwords
by Pisilä Janne 11 Apr '24

11 Apr '24

Hello, The password protocol option section in user's guide 2.0 https://bird.network.cz/?get_doc&v=20&f=bird-3.html#proto-pass incorrectly shows date format as dd-mm-yyyy when it should be yyyy-mm-dd in BIRD v2. The old format is also shown in protocol configuration examples, for example in OSPF's chapter https://bird.network.cz/?get_doc&v=20&f=bird-6.html#ss6.11

2 1

How to config a ospf stub area?
by chan alfie 10 Apr '24

10 Apr '24

Hi, +-----------------------+ +-------------------+ +-------------------+ +---------------------- - + | 172.16.34.0/30 \ / 172.16.45.0/30 \ / 172.16.56.0/30 \ / 172.16.67.0/30 | | rt3 --------------------- rt4 ------------------- rt5 --------------------- rt6 ------------------- rt7 | | area 172.16.34.0 / \ area 0.0.0.0 / \ area 172.16.56.0 / \ | +-----------------------+ +-------------------+ +----- ---------------+ + ------------------------+ OSPF RIP I would like to config area 172.16.34.0 as a stub area, here is my config: ``` rt3.conf protocol ospf v2 { ipv4 { import all; export all; }; area 172.16.34.0 { stub yes; interface "veth34" { type bcast; # Detected by default cost 10; # Interface metric hello 10; # Default hello perid 10 is too long }; interface "lo3" { stub yes; }; }; } ``` rt4.conf ``` protocol ospf v2 { ipv4 { import all; export all; }; area 172.16.34.0 { stub yes; interface "veth43" { type bcast; # Detected by default cost 10; # Interface metric hello 10; # Default hello perid 10 is too long }; interface "lo3" { stub yes; }; }; area 0.0.0.0 { ... } } ``` rt3 ``` rt3# bird -c /etc/bird/lab/rt3.conf -p bird: /etc/bird/lab/rt3.conf:173:1 ASBR must be in non-stub area ``` rt4 ``` rt4# bird -c /etc/bird/lab/rt4.conf -p rt4# birdc -s /run/bird/rt4.pid configure ``` after that rt4 ``` bird> show ospf lsadb ... area 172.16.34.0 router 172.16.8.4 distance 0 stubnet 172.16.34.0/30 metric 10 xnetwork 0.0.0.0/0 metric 1000 bird> show ospf lsadb area 172.16.34.0 Area 172.16.34.0 Type LS ID Router Sequence Age Checksum 0001 172.16.8.4 172.16.8.4 80000019 616 067e 0003 0.0.0.0 172.16.8.4 80000001 621 1753 ``` rt3 ``` bird> show ospf lsadb area 172.16.34.0 Area 172.16.34.0 Type LS ID Router Sequence Age Checksum 0001 172.16.8.3 172.16.8.3 8000001b 676 1d29 0001 172.16.8.4 172.16.8.4 80000017 1782 2578 0004 172.16.8.5 172.16.8.4 80000016 1777 e089 0004 172.16.8.6 172.16.8.4 80000016 1777 3b24 0002 172.16.34.2 172.16.8.4 80000016 1782 f5d7 0003 172.16.45.3 172.16.8.4 80000017 1782 56f3 0003 172.16.56.3 172.16.8.4 80000016 1777 43f2 0003 4.8.5.3 172.16.8.4 80000016 1777 67b2 0003 4.8.5.4 172.16.8.4 80000016 1777 5dbb 0003 4.8.5.11 172.16.8.4 80000016 1777 17fa 0003 4.8.5.12 172.16.8.4 80000016 1777 0d04 0003 4.8.6.3 172.16.8.4 80000003 2017 e63b 0003 4.8.6.4 172.16.8.4 80000003 2017 dc44 0003 4.8.6.11 172.16.8.4 80000003 2017 9683 0003 4.8.6.12 172.16.8.4 80000003 2017 8c8c bird> show ospf lsadb state syntax error, unexpected STATE bird> show ospf state area 172.16.34.0 router 172.16.8.3 distance 0 stubnet 4.8.3.0/30 metric 10 stubnet 4.8.3.4/30 metric 10 stubnet 4.8.3.8/30 metric 10 stubnet 4.8.3.12/30 metric 10 stubnet 172.16.34.0/30 metric 10 stubnet 4.8.3.100/30 metric 10 bird> ```

2 2

How to idenfity if a router is ABR, ASBR or normal router?
by chan alfie 10 Apr '24

10 Apr '24

Hello, community I am learning ospf on bird, have a question about how to identify a router is ASBR, ABR or normal RT here is my topology: +-----------------------+ +-------------------+ +-------------------+ +---------------------- - + | 172.16.34.0/30 \ / 172.16.45.0/30 \ / 172.16.56.0/30 \ / 172.16.67.0/30 | | rt3 --------------------- rt4 ------------------- rt5 --------------------- rt6 ------------------- rt7 | | area 172.16.34.0 / \ area 0.0.0.0 / \ area 172.16.56.0 / \ | +-----------------------+ +-------------------+ +----- ---------------+ + ------------------------+ OSPF RIP according to the topo, rt4 and rt5 should be ABR, rt6 should be ASBR but how to know it when using ``` show ospf lsadb show ospf state ``` here are some output rt3: ``` bird> show ospf state area 172.16.34.0 router 172.16.8.3 distance 0 network 172.16.34.0/30 metric 10 stubnet 4.8.3.0/30 metric 10 stubnet 4.8.3.4/30 metric 10 stubnet 4.8.3.8/30 metric 10 stubnet 4.8.3.12/30 metric 10 stubnet 4.8.3.100/30 metric 10 router 172.16.8.4 distance 10 network 172.16.34.0/30 metric 10 xnetwork 4.8.5.0/30 metric 20 xnetwork 4.8.5.4/30 metric 20 xnetwork 4.8.5.8/30 metric 20 xnetwork 4.8.5.12/30 metric 20 xnetwork 4.8.6.0/30 metric 30 xnetwork 4.8.6.4/30 metric 30 xnetwork 4.8.6.8/30 metric 30 xnetwork 4.8.6.12/30 metric 30 xnetwork 172.16.45.0/30 metric 10 xnetwork 172.16.56.0/30 metric 20 xrouter 172.16.8.5 metric 10 xrouter 172.16.8.6 metric 20 network 172.16.34.0/30 dr 172.16.8.4 distance 10 router 172.16.8.4 router 172.16.8.3 other ASBRs router 172.16.8.6 external 4.8.7.0/30 metric2 10000 external 4.8.7.4/30 metric2 10000 external 4.8.7.8/30 metric2 10000 external 4.8.7.12/30 metric2 10000 bird> show ospf lsadb Global Type LS ID Router Sequence Age Checksum 0005 4.8.7.3 172.16.8.6 80000015 1640 baee 0005 4.8.7.4 172.16.8.6 80000015 1640 b0f7 0005 4.8.7.11 172.16.8.6 80000015 1640 6a37 0005 4.8.7.12 172.16.8.6 80000015 1640 6040 Area 172.16.34.0 Type LS ID Router Sequence Age Checksum 0001 172.16.8.3 172.16.8.3 80000019 869 0163 0001 172.16.8.4 172.16.8.4 80000016 1211 2777 0004 172.16.8.5 172.16.8.4 80000015 1208 e288 0004 172.16.8.6 172.16.8.4 80000015 1206 3d23 0002 172.16.34.2 172.16.8.4 80000015 1211 f7d6 0003 172.16.45.3 172.16.8.4 80000016 1211 58f2 0003 172.16.56.3 172.16.8.4 80000015 1208 45f1 0003 4.8.5.3 172.16.8.4 80000015 1208 69b1 0003 4.8.5.4 172.16.8.4 80000015 1208 5fba 0003 4.8.5.11 172.16.8.4 80000015 1208 19f9 0003 4.8.5.12 172.16.8.4 80000015 1208 0f03 0003 4.8.6.3 172.16.8.4 80000002 1446 e83a 0003 4.8.6.4 172.16.8.4 80000002 1446 de43 0003 4.8.6.11 172.16.8.4 80000002 1446 9882 0003 4.8.6.12 172.16.8.4 80000002 1446 8e8b ``` rt6: ``` bird> show ospf state area 172.16.56.0 router 172.16.8.5 distance 10 network 172.16.56.0/30 metric 10 xnetwork 4.8.3.0/30 metric 30 xnetwork 4.8.3.4/30 metric 30 xnetwork 4.8.3.8/30 metric 30 xnetwork 4.8.3.12/30 metric 30 xnetwork 4.8.3.100/30 metric 30 xnetwork 4.8.5.0/30 metric 10 xnetwork 4.8.5.4/30 metric 10 xnetwork 4.8.5.8/30 metric 10 xnetwork 4.8.5.12/30 metric 10 xnetwork 172.16.34.0/30 metric 20 xnetwork 172.16.45.0/30 metric 10 xrouter 172.16.8.3 metric 20 xrouter 172.16.8.4 metric 10 router 172.16.8.6 distance 0 network 172.16.56.0/30 metric 10 stubnet 4.8.6.0/30 metric 10 stubnet 4.8.6.4/30 metric 10 stubnet 4.8.6.8/30 metric 10 stubnet 4.8.6.12/30 metric 10 external 4.8.7.0/30 metric2 10000 external 4.8.7.4/30 metric2 10000 external 4.8.7.8/30 metric2 10000 external 4.8.7.12/30 metric2 10000 network 172.16.56.0/30 dr 172.16.8.6 distance 10 router 172.16.8.6 router 172.16.8.5 bird> show ospf lsadb Global Type LS ID Router Sequence Age Checksum 0005 4.8.7.3 172.16.8.6 80000015 1698 baee 0005 4.8.7.4 172.16.8.6 80000015 1698 b0f7 0005 4.8.7.11 172.16.8.6 80000015 1698 6a37 0005 4.8.7.12 172.16.8.6 80000015 1698 6040 Area 172.16.56.0 Type LS ID Router Sequence Age Checksum 0004 172.16.8.3 172.16.8.5 80000015 1267 550d 0004 172.16.8.4 172.16.8.5 80000015 1267 e684 0001 172.16.8.5 172.16.8.5 80000017 1229 ec83 0003 172.16.34.3 172.16.8.5 80000015 1267 321a 0003 172.16.45.3 172.16.8.5 80000015 1315 54f6 0003 4.8.3.3 172.16.8.5 80000015 1267 dd34 0003 4.8.3.4 172.16.8.5 80000015 1267 d33d 0003 4.8.3.11 172.16.8.5 80000015 1267 8d7c 0003 4.8.3.12 172.16.8.5 80000015 1267 8385 0003 4.8.3.100 172.16.8.5 80000006 932 2e91 0003 4.8.5.3 172.16.8.5 80000015 1315 fe25 0003 4.8.5.4 172.16.8.5 80000015 1315 f42e 0003 4.8.5.11 172.16.8.5 80000015 1315 ae6d 0003 4.8.5.12 172.16.8.5 80000015 1315 a476 0001 172.16.8.6 172.16.8.6 80000016 1510 6d45 0002 172.16.56.2 172.16.8.6 80000015 1273 2989 ```

1 0