RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1337860 - [RFE] missing RTM_DELROUTE event when `ip route change` replaces existing route
Summary: [RFE] missing RTM_DELROUTE event when `ip route change` replaces existing route
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kernel
Version: 7.3
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Sabrina Dubroca
QA Contact: Jianlin Shi
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-20 09:39 UTC by Thomas Haller
Modified: 2023-08-04 13:40 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-12-15 07:41:32 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

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.
Note You need to log in before you can comment on or make changes to this bug.