Bug 1337860

Summary:	[RFE] missing RTM_DELROUTE event when `ip route change` replaces existing route
Product:	Red Hat Enterprise Linux 7	Reporter:	Thomas Haller <thaller>
Component:	kernel	Assignee:	Sabrina Dubroca <sdubroca>
kernel sub component:	Networking	QA Contact:	Jianlin Shi <jishi>
Status:	CLOSED WONTFIX	Docs Contact:
Severity:	medium
Priority:	medium	CC:	aloughla, atragler, jiji, jpirko, kzhang, mleitner, rkhan, sdubroca, sukulkar, tgraf, tgunders, tobias.jungel
Version:	7.3	Keywords:	FutureFeature
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-12-15 07:41:32 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Thomas Haller 2016-05-20 09:39:32 UTC

As explained in bug 1337855, different routes to the same destination can be added:


    unshare -n
    ip link add name L type dummy
    ip link set L up
    ip addr add 192.168.100.5/24 dev L

    ip route add    192.168.105.0/24 dev L
    ip route append 192.168.105.0/24 dev L advmss 100


After that, we end up with two routes.
# ip route
192.168.100.0/24 dev L  proto kernel  scope link  src 192.168.100.5 
192.168.105.0/24 dev L  scope link 
192.168.105.0/24 dev L  scope link  advmss 100


now, `ip route change` (or `ip route replace`) replaces an existing route with a different one.

    ip monitor &
    ip route change 192.168.105.0/24 dev L advmss 200
    #prints: 192.168.105.0/24 dev L  scope link  advmss 200

Afterwards:
# ip route
192.168.100.0/24 dev L  proto kernel  scope link  src 192.168.100.5 
192.168.105.0/24 dev L  scope link  advmss 200
192.168.105.0/24 dev L  scope link  advmss 100


you see, we got an event RTM_NEW_ROUTE(192.168.105.0/24 dev L advmss 200), but it also replaced an existing route without sending a RTM_DEL_ROUTE(192.168.105.0/24 dev L)


How would user-space know about that?

Well, the RTM_NEW_ROUTE() event above actually has NLM_F_REPLACE set (see for example: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a2bb6d7d6f4249691b6a554cde59969d55b0d9c3 ).
But user-space now only know that this was a replace, it still doesn't know which route exactly was replaced.
Well, it seems that during a dump RTM_GETROUTE,NLM_F_DUMP the routes arrive in a certain order. So, the one that is replaced is the first one that matches in in the attributes family,table,destination/plen,metric.

To properly implement this, user-space must also track the relative order of the routes to know which was replaced. So, it is doable, although difficult (NetworkManager, sd-networkd and libnl3 currently don't even properly implement bug 1337855, so they certainly don't handle this).

(NetworkManager currently requests a new dump when it suspects that the cache might become invalid due to this, which is bad too).



Maybe we could add instead get a new event that indicates *which* route was replaced? Maybe not a RTM_DEL_ROUTE(), because that might disturb existing applications which don't expect that a `ip route change` results in RTM_DELROUTE,RTM_NEWROUTE.
Maybe a new RTM_REPLACEROUTE event?

Comment 2 Tom Gundersen 2016-05-20 14:50:27 UTC

Simply having a route id like you suggested in #1337855 would be sufficient, right? The new route would retain the same ID as the route you replace, so you would immediately know what happened. Or am I missing something?

Comment 3 Thomas Haller 2016-05-20 15:37:31 UTC

(In reply to Tom Gundersen from comment #2)
> Simply having a route id like you suggested in #1337855 would be sufficient,
> right? The new route would retain the same ID as the route you replace, so
> you would immediately know what happened. Or am I missing something?

Yes, that would be one possibility!


But maybe not?


Currently, all/most fields of a route constitute to its ~ID~ (old-ID).
After introducing int64-ID, maybe we still don't want that for a given int64-ID the old-ID can be modified. Maybe, both old-ID and int64-ID should continue to identify a route.


The question is, does `ip route change` update the old-ID fields of an existing route, or does it add a new route and delete another one?
It's a matter of how you look at it, but I dislike the ID of a single route changing (because, then, what is really the determining factor for route_is_equal()?).



I think I'd prefer a netlink event telling that ~another~ route was replaced.

Comment 8 Marcelo Ricardo Leitner 2019-07-03 15:10:37 UTC

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!

Comment 10 Marcelo Ricardo Leitner 2020-10-23 23:51:48 UTC

If this is still wanted, we need to move it to rhel8.

Comment 12 RHEL Program Management 2020-12-15 07:41:32 UTC

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.