On Mon, Apr 29, 2019 at 03:46:09PM +0000, Kenth Eriksson wrote:
On Mon, 2019-04-29 at 15:42 +0200, Ondrej Zajicek wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Mon, Apr 29, 2019 at 01:01:13PM +0000, Kenth Eriksson wrote:
'ip' tool, perhaps harder in other cases). It would be great if there existed sysctl option for default IPv4 route metric.
There is no overwrite involed here. The default route in the kernel here has metric 100. As you said, bird pushes with metric 32 so it should push again.
Well, i misread your mail. If i understand it correctly, the issue is not that routes are not pushed into kernel, but that they are not pushed into master table. I guess you have two routes for the same network in one static protocol. That is not valid case, although we are missing error checks for that configuration.
You could either use two separate static protocol instances, or you could use this patch:
That patch did not work for me, still same issue. I had to add DISTANCE to the CF_KEYWORDS to make it compile. But is it anything else that is required?
Hi The patch should be more-or-less all that is required, but it is not fully ready for master branch, so it has a bit awkward behavior. Namely it requires that preference is specified without '=', like in example i provided:
route 0.0.0.0/0 via 10.210.137.1 { preference 220; }; route 0.0.0.0/0 via 192.168.120.1 { preference 230; };
If you used the same config like without patch (i.e. with 'preference = XXX'), it would not work.
I thought two prefixes differing only on metric should be perfectly valid? The kernel accepts that, so why would bird not?
Mainly implementation reasons. In BIRD, preference is generally not part of key, therefore route update for one network could replace a route for route with different preference (which makes sense with filter-based dynamic preference). Traditionally BIRD supported in one routing table one route per network and protocol instance. With BGP ADD_PATH extension the key was extended with arbitrary u32 distinguisher, which in BGP case is the path ID value from BGP ADD_PATH, but most other protocols does not use that. The patch above uses preference as distinguisher in case of static routes. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."