- Bird-users - Mailing Lists

OSPF for IPv4 over IPv6 only?
by Nico Schottelius 08 Apr '24

08 Apr '24

Good morning, if we are talking about BGP, IPv4 routing over IPv6 works beautifully. We just add another IPv4 channel and get BGP MP. OSPFv3 works fine on IPv6 and when creating two instances, one for IPv6 one for IPv4, things look correct. But how does OSFPv3 conceptually work if the interface of the ospf area do not have IPv4 addresses themselves? In the BGP case we can use "extended next hop on;" to use the IPv6 nexthop for IPv4, but I did not find a similar setting for OSPF to accept IPv6 nexthops for IGP IPv4 addresses. Is there a way to purely go IPv6 only and still relay stub network IPv4 information via an IPv6 only internal area? Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch

9 20

The bird wikis is broken
by chan alfie 06 Apr '24

06 Apr '24

I am a newbie on bird, found some useful info through google which redirect to bird's wikis, but the wikis seems broken, any possbile to bring it back?

4 4

announce IPV4 loopback via an OSPF v3 backbone
by Benoit Chesneau 05 Apr '24

05 Apr '24

Hi everyone, I was reading the ospv3 spec and this link https://networklessons.com/ospf/ospfv3-for-ipv4- and was wondering if such features is supported in bird 2. Can we announce loopbacks via OSPFv3 and remove the need to use OSPFv2 and ptp subnets ? I see it as a good opportunity to reduce the usage of the IPv4 addresses if we can just advertise loopbacks... Benoît

3 5

Problem with uplink network announcment in IPv6
by Yasen Atanasov 02 Apr '24

02 Apr '24

Hello, I've experienced a strange problem when implementing IPv6 connectivity. My ISP gave me /126 for connection between bgp routers and uplink connectivity. A lot of(but not all) routes couldn't be inserted in the kernel. After some experimentation we realized that administrative route that is created buy the kernel for local networks was overridden by the bird and after that no new routes were inserted in the kernel table. ~# ip r get x::y x::y from :: via x::y dev eth6 proto bird src x::z metric 32 pref medium vs x::y from :: dev eth6 proto kernel src x::z metric 256 pref medium Where x::y is uplink BGP peer and x::z our BGP router. Filtering /126 network from imports resolved the problem Is this normal behavior for Bird or some misconfiguration from our side? Should I report that as misconfiguration to my ISP? I'm using bid 2.0.12 from Devuan 5 repos. Any input will appreciated. Yasen

2 1

Coexistence of multiple babel daemons on the same host
by Daniel Gröber 02 Apr '24

02 Apr '24

Hi Babelers, I've just come across a reason I'd want to run babel with both bird and babeld on the same node and have them become neighbours. The details are tedious -- my usual disclamer applies ;) This got me to think about something I'd observed in the past and been meaning to write about though: when I accidentally had both babeld and bird running on a node it would casuse severe route flapping and consequently packet loss. I wonder if we can do better here? Maybe by warning about this situation in the logs, shutting down both sides or just turning this into a supported use-case? :) >From what I gather by a quick skimming of the relevant details in RFC8966 this could work by assigning each daemon a unique LL address so each gets it's own entry in the neighbour table, right? Thanks, --Daniel

3 4

How to make bird and freebsd carp working together ?
by Arnaud Houdelette-Langlois 01 Apr '24

01 Apr '24

Hi I got two routers running freebsd (BSDRP). Those two are used as redundant site firewalls and main routers / route servers. Both exchange routes between themselves and other routers using Bird (OSPF+BGP). Both serve as gateway for our management network, with carp enabled. I got trouble making CARP and BIRD working together. The carp enabled interface use a dummy network for exchanging carp info (link local adresses : 169.254.1.0/24) Bird Device protocol does not makes any difference between adresses in MASTER or BACKUP vhids, so the route appears in both routers. I tried with recent "learn all" feature of kernel protocol : There, bird only picks up route when its master, but, in case of MASTER failover or preemption, it doesn't remove the route early enough, and freebsd does not seem to replace the route on it’s kernel table, so when birds finally removes the route, we end up with no route at all. (and a non working network segment). Am I the only one facing this issue ? Is there a way to make bird carp aware ? Thanks -- Arnaud Houdelette-Langlois Administrateur des infrastructures systèmes et réseaux Normandie Université

2 1

Babel and Unnumbered interfaces
by Pim van Pelt 30 Mar '24

30 Mar '24

Hoi folks, By means of context, I am working on allowing VPP and Bird2/Babel to program the routing table with IPv6 nexthops for IPv4 destinations. I finished a few small code changes in VPP to allow transit-net-less transport of IPv4 and IPv6 in VPP and wrote about it on https://ipng.ch/s/articles/2024/03/06/vpp-babel-1.html <https://ipng.ch/s/articles/2024/03/06/vpp-babel-1.html>. Considering this dataplane has some different idioms than Linux, it took a bit of work. I thought you might find this VPP + Bird2 + Babel story from the field interesting. I wanted to ask you to read the article, and in particular the /Additional thoughts/ section at the bottom, as it tries to ask for opinions on a somewhat complex topic of unnumbered point-to-point interfaces in VPP. On the VPP side, I have a small change (https://gerrit.fd.io/r/c/vpp/+/40482) that builds support for point-to-point over Ethernet. With this approach, VPP will copy the IPv4 and IPv6 address over from a loopback interface to the ethernet transit networks. In the article above, I mentioned in /Approach 3/, One option is to ask Babel to use |extended next hop| even when IPv4 is available, which would be a change to Bird (and possibly a violation of the Babel specification, I should read up on that). I don't think it's a violation of the Babel protocol to use IPv6 next hops when an IPv4 address is present. However, I noticed that in proto/babel/babel.c function babel_send_update_() the protocol /always/ prefers IPv4 when it's set. My question: would it be feasible to extend the configuration syntax of /extended next hop/ to also allow keyword /always/, in which case the IPv6 nexthop is preferred even if an IPv4 address is present? The logic in proto/babel/babel.c 1039-1950 seems straight-forward to adapt to this case, in a non-intrusive way. I can attempt a patch if the Bird (and Babel) community believes this is a useful behavior. groet, Pim -- Pim van Pelt PBVP1-RIPE -https://ipng.ch/

2 2

Failover BGP servers?
by Yasen Atanasov 29 Mar '24

29 Mar '24

Hello, Lets imagine I have 2 BGP servers announcing same subnet. BGP sessions with upstream are in different VLAN. Both servers have keepalived and all clients are using for default route the virtual address. The idea is if I need to upgrade/rebuild one of the servers the clients will still have connectivity trough the other server. Do I need to do something special in the bird config or just announcing the same net is enough? Regards. Yasen

3 3

Suggestion : Add protocol default preferences to documentation.
by Arnaud HOUDELETTE-LANGLOIS 26 Mar '24

26 Mar '24

Hi I could not found default protocol preferences on the user doc. I had to search the code. I think the defaults (or at least the order of preference) should be somewhere in the documentation. This is the info I was looking for : /* * Default protocol preferences */ #define DEF_PREF_DIRECT 240 /* Directly connected */ #define DEF_PREF_STATIC 200 /* Static route */ #define DEF_PREF_OSPF 150 /* OSPF intra-area, inter-area and type 1 external routes */ #define DEF_PREF_BABEL 130 /* Babel */ #define DEF_PREF_RIP 120 /* RIP */ #define DEF_PREF_BGP 100 /* BGP */ #define DEF_PREF_RPKI 100 /* RPKI */ #define DEF_PREF_L3VPN_IMPORT 80 /* L3VPN import -> lower than BGP */ #define DEF_PREF_L3VPN_EXPORT 120 /* L3VPN export -> higher than BGP */ #define DEF_PREF_INHERITED 10 /* Routes inherited from other routing daemons */ Thanks to the devs for the good work. -- Arnaud HOUDELETTE-LANGLOIS Administrateur systèmes et réseaux informatiques Responsable de la sécurité des systèmes d'information Normandie-Université +33 2 31 56 69 54

1 0

2.15, ospf is broken
by Dmitry Melekhov 26 Mar '24

26 Mar '24

Hello! Just upgraded and got: Mar 19 08:07:46 hohr-vpn-1 bird[1523831]: Started Mar 19 08:07:54 hohr-vpn-1 bird[1523831]: MyOSPF: Unexpected case in next hop calculation Mar 19 08:07:54 hohr-vpn-1 bird[1523831]: MyOSPF: Cannot find next hop for LSA (Type: 2002, Id: 192.168.222.221, Rt: 192.168.22.178) Mar 19 08:07:54 hohr-vpn-1 bird[1523831]: MyOSPF: Unexpected case in next hop calculation etc. on all hosts I upgraded. All of them is alma 9. Downgrade to 2.14 solved problem. Is there fix for this or workaround? Thank you!

6 12