Doc suggestion - clarifying behaviour when routes are moving between protocols

Alexander Zubkov green at qrator.net
Thu Feb 8 12:27:38 CET 2024


Hi Mark,

Actually the best route selection algorithm can be found here:
https://bird.network.cz/?get_doc&v=20&f=bird-2.html#ss2.1

And the preference is clearly noticed there. Have you looked for it in
some other place? If you describe how did you try to find it, I
believe it might help the developers to better structure the
documentation.

Best regards,
Alexander

On Thu, Feb 8, 2024 at 11:41 AM Mark Shuttleworth
<mark.shuttleworth at canonical.com> wrote:
>
> Hi folks
>
> Thank you for Bird, I have enjoyed working with it over the holidays for a personal project routing between offices. Along the way I got stuck on an issue that might catch other people as well, so I thought to describe it here in the hope that docs are updated to make the behaviour more clear.
>
> I have a metropolitan area network between a few sites. Each of those sites has its own internet connection, but the MAN is much faster, so my goal was to route traffic to whichever exit point had the best bandwidth, using the different sites as backup internet gateways. At each site, I was testing the local connectivity (looking beyond simple link up to whether I could reach common sites) and then, if the link was good, adding a static route out from that location.
>
> I wanted to use Bird to export and distribute those static routes to other sites, with custom metrics to prioritise the gateways that had the best bandwidth.
>
> The expected behaviour for me was that a local, statically defined default route would be imported and have the custom metric set based on its bandwidth, and that the 'best' route would then win and be distributed by OSPF to the other sites.
>
> The problem I ran into was that the implicit protocol preference comparison prevented the local route from even being considered at all. So once a route had propagated to a site with Bird, it could not be displaced by a 'better' static route, because of the relative preferences.
>
> I ended up with a config like this, where the explicit preference solved the issue:
>
> protocol kernel {
>         learn;                  # Learn alien routes from the kernel
>         ipv4 {                  # Connect protocol to IPv4 table by channel
>                 import filter {
>                         if net = 0.0.0.0/0 then { # We only want default routes added manually to this machine
>                                 ospf_metric2 = 1000;
>                                 preference = 150;
>                                 accept "Accepted default route from kernel";
>                         }
>                         reject;
>                 };
>                 export all;     # Install all Bird routes in kernel
>         };
> }
>
> I couldn't find any documentation that explained the role of 'preference' in the import process, so I was stuck on this for an embarrassing amount of time :blush: In the end, this blog https://mk16.de/blog/bird-preference/ and some tangential comments in mailing lists led me to try the explicit preference, and that solved the issue. Apologies if I missed this in the docs, but if it isn't already covered, perhaps a more detailed explanation of the way routes are compared for import into a table would help others.
>
> Again, thank you for Bird! I think we might build it into Ubuntu in some interesting ways :)
>
> Mark



More information about the Bird-users mailing list