[PATCH] Netlink: Propagate ecmp nexthop weight to kernel for inet6 routes

[dxld at darkboxed.org]

Hi Ondrej,

did you ever see my v2 patchset?

    [PATCH v2 1/2] Netlink: Drop ECMP route splitting hacks
    [PATCH v2 2/2] Netlink: Propagate ECMP nexthop weight to kernel for inet6 routes

Since I never heard back on that.

--Daniel

On Mon, May 23, 2022 at 02:36:49AM +0200, Ondrej Zajicek wrote:
> On Sun, May 22, 2022 at 10:28:12PM +0200, dxld at darkboxed.org wrote:
> > After looking at this more I realise now how bird is splitting multiple
> > ipv6 nexthops into sequences of route updates for the same prefix.
> > 
> > Consequently the code doing this should also be removed. Though it seems it
> > works just fine either way but I get errors for the (now redundant) route
> > removals.
> > 
> > Are we even OK with raising the kernel version required or should I try to
> > preserve support for the old kernel interface?
> 
> Hi
> 
> The initial IPv6 multipath support required several ugly hacks in Netlink
> code, which i would be happy to get rid of. When Linux came with IPv6
> RTA_MULTIPATH support, the initial versions were somewhat buggy, so we
> kept using the old API for updates (splitting multipath routes to
> sequences of route updates), while accepting RTA_MULTIPATH routes in
> scans / notifications. My notes say that minimal reliable kernel version
> for IPv6 RTA_MULTIPATH is 4.11.
> 
> As a rule of thumb, i target compatibility for ~5 year old systems that
> are not EOL, for example Debian LTS. Current Debian LTS is Debian 9
> (Stretch), which uses kernel 4.9, but it will be EOL in a ~month, while
> Debian 10 uses kernel 4.19. For kernel itself, ~5 year old LTS release
> would be 4.14.
> 
> So i would be OK with targeting 4.14 / 4.19 as the oldest supported
> version and switching completely to RTA_MULTIPATH code in Netlink.
> 
> -- 
> Elen sila lumenn' omentielvo
> 
> Ondrej 'Santiago' Zajicek (email: santiago at 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."