OSPFv3 on Bird Needs IPv6 LLA on the Loopback Interface
Wanted to share this “too weird to believe” SNAFU I found when running integration tests with the Bird routing daemon. It’s irrelevant unless you want Bird to advertise the IPv6 prefix configured on the main loopback interface (lo) with OSPFv3.
Late last year, I decided to run netlab integration tests with the Bird routing daemon. It passed most baseline netlab OSPFv3 integration tests but failed those that checked the loopback IPv6 prefix advertised by the tested device (test results).
A quick Google search unearthed a Wisdom of the Ancients email from someone facing the exact same problem, and the replies sent me deep into the “you must be kidding” territory. OSPFv3 requires IPv6 LLA to communicate, and if Bird does not find an LLA on an interface, it ignores the interface even when the interface is configured as a stub interface.
The proposed “solution”: add a static LLA to the loopback interface. It works, but one would have hoped not to encounter this FAD1 in the Bird release shipping with Ubuntu 24.04.
So, just in case you need to get Bird running in this particular scenario, and the loopback interface remains in the “Ignored” state: ip addr add fe80::1/64 dev lo scope link is what you’re looking for. I added that to the Bird initial configuration template, and suddenly, most OSPFv3 tests (for the functionality netlab supports on Bird) passed with flying colors.
-
Functions As Designed ↩︎
Hello Ivan,
good find on this particular BIRD OSPFv3 configuration.It reminded me of my findings when it comes to using BIRD specifically when configuring the Administrative Distance (Cisco term) or Route Preference Value (Juniper term) and its default behaviour in BIRD. I will be using the AD (Administrative Distance) term below to describe the behaviour when dealing with dynamic routing.
Every dynamic routing protocol implementation has following AD default values: a directly connected route - 0, static route - 1, eBGP - 20 and so on, with minor differences between vendors. BIRD's default AD (protocol preference) is upside down. BIRD directly connected route has the default AD - 240, static route - 200, BGP - 100, Unknown - 0. Created a default AD setting overview table listing all the vendors that I could make some hand's on experience.
Addionally every dynamic routing protocol implementation uses the AD like following: the lower the AD the more preferred the routing protocol. BIRD's AD behaviour is the exact opposite - the higher the AD the more preferred the routing protocol, please see this mailing list entry:
Setting up a BIRD router in a multi-vendor netlab running multiple dynamic routing protocols is a very interesting, when purely academic, experience. There are a lot more odd settings and default behaviours in BIRD I do not want to write about here, and the missing pieces in the official documentation makes BIRD not better. BIRD has its own use cases where it does its job good it is the preferred route server for many users.
Thanks a million for the feedback. And yes, I agree with you that the Bird documentation tends to be somewhat laconic ;)