Bug 1337855

I would love something like this! Currently it is really hard to get this right in userspace, and just adding an identifier (that is guaranteed to be stable, unique and never reused) to each message would solve the problem very nicely for us.

I spent some time trying to figure out how to do this in networkd (currently it is broken as Thomas points out). For LINK the IFINDEX gives us exactly what we want, for ADDRESS it is fine, as mimicking the equality implemented by the kernel is more or less trivial, but four ROUTE it is really complicated figuring out what exactly the notion of equality the kernel uses (exactly which fields needs to be compared in which circumstances).

If an ID is not possible, then at least some documentation exactly when two {NEW,DEL}ROUTE messages refer to the same, and when to different routes would be nice to have.

As the feature needs updates of both kernel-space and user-space. if kernel-space and user-space all support the feature described in Description, then we can test with the user-space tools: add routes to same destination with different fields, then check if user-space tool can show the all routes.

if user-space not support the feature yet when testing, then we would only check the codes of kernel-space.

set ACK+

This would be very helpful. 

A simple case of adding the same prefix on difference devices 

Example: 
ff00::/8 dev eth0
ff00::/8 dev eth1

cacheManagers like libnl cannot differentiate these 2 routes in its cache. 

As Thomas pointed out, the userspace application does not consider the MULTIPATH attribute, so the 2 routes appear similar to libnl route cache.

Mass-moving bugs RHEL <= 7.6.0 to 7.7.0.
As we are past RFE deadline for 7.7.0 and we should have no new features on 7.8.0, please evaluate if it's still wanted on RHEL7 and contact PM for exception. You may also move it to RHEL8 if that's wanted. Thanks!

RHEL7.. dropping this one in favor of the RHEL8 one, https://bugzilla.redhat.com/show_bug.cgi?id=1722728.

btw, for IPv6 routes there would be something special to consider:


Kernel allows adding two (otherwise identical) routes that only differ by their next-hop.
So one might think that the nexthop is part of the identity of an IPv6 route.

However, look at:


# ip route monitor &
# ip route append a:b:f::/64 nexthop via 1:2:3:4::120 dev v nexthop via 1:2:3:4::121 dev v 
a:b:f::/64 metric 1024 pref medium
        nexthop via 1:2:3:4::120 dev v weight 1 
        nexthop via 1:2:3:4::121 dev v weight 1 
# ip route append a:b:f::/64 nexthop via 1:2:3:4::122
a:b:f::/64 metric 1024 pref medium
        nexthop via 1:2:3:4::120 dev v weight 1 
        nexthop via 1:2:3:4::121 dev v weight 1 
        nexthop via 1:2:3:4::122 dev v weight 1 
# ip route delete a:b:f::/64 nexthop via 1:2:3:4::120
Deleted a:b:f::/64 via 1:2:3:4::120 dev v metric 1024 pref medium
# ip route append a:b:f::/64 nexthop via 1:2:3:4::125 dev v nexthop via 1:2:3:4::121 dev v 
RTNETLINK answers: File exists
a:b:f::/64 metric 1024 pref medium
        nexthop via 1:2:3:4::121 dev v weight 1 
        nexthop via 1:2:3:4::122 dev v weight 1 
        nexthop via 1:2:3:4::125 dev v weight 1 
Deleted a:b:f::/64 via 1:2:3:4::125 dev v metric 1024 pref medium



note that on netlink, kernel exposes one RTM_NEWROUTE instance (with muliple next hops), but
when you append/delete routes, then this route gets mangled. That means, the nexthop is
and is not part of the identifying properties of a IPv6 route.


I think for IPv6 routes, it would be more apt to see all multihop routes a several singlehop
routes, with the twist, that on the netlink API these singlehop routes a notified together.



For this rhbz that would mean, that the identifier for IPv6 is not a toplevel attribute of
the RTM_NEWROUTE, but instead each RTA_MULTIPATH has it's own identifier.

For IPv4 that is not the case, this merging/subtracting does not seem to happen and one RTM_NEWROUTE
message can have one identifier.