This bug has been migrated to another issue tracking site. It has been closed here and may no longer be being monitored.

If you would like to get updates for this issue, or to participate in it, you may do so at Red Hat Issue Tracker .
Bug 2167766 - fix handling onlink route flag for ECMP routes
Summary: fix handling onlink route flag for ECMP routes
Keywords:
Status: CLOSED MIGRATED
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: NetworkManager
Version: 9.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: NetworkManager Development Team
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-02-07 13:41 UTC by Thomas Haller
Modified: 2023-08-17 08:08 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-08-17 08:07:56 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker NMT-704 0 None None None 2023-08-07 10:49:06 UTC
Red Hat Issue Tracker   RHEL-1402 0 None None None 2023-08-17 08:07:55 UTC
Red Hat Issue Tracker RHELPLAN-164722 0 None None None 2023-08-07 10:53:04 UTC

Description Thomas Haller 2023-02-07 13:41:18 UTC
in kernel, the onlink flag (RTNH_F_ONLINK) is associated with each next hop (and not for the route alone).

Unlike for NetworkManager currently, where there is only one route-wide NMPlatformIP4Route.r_rtm_flags field.

---

1)

Note that the onlink flag is part of the identity of a route, that means, you can add two routes that only differ in their next-hop, like:

  # ip route append 1.2.3.4 nexthop via 192.168.9.1 dev v nexthop via 192.168.9.1 dev v
  # ip route append 1.2.3.4 nexthop via 192.168.9.1 dev v nexthop via 192.168.9.1 dev v onlink

gives:

  1.2.3.4 
          nexthop via 192.168.9.1 dev v weight 1 
          nexthop via 192.168.9.1 dev v weight 1 
  1.2.3.4 
          nexthop via 192.168.9.1 dev v weight 1 
          nexthop via 192.168.9.1 dev v weight 1 onlink 


NetworkManager currentlty cannot express that (see also NM_PLATFORM_IP_ROUTE_CMP_TYPE_ID). The effect is, that to NetworkManager those two routes look identical and they get combined as one entry in the platform cache. This needs fixing, by tracking the next hop flags per next-hop. Otherwise, cache inconsistencies can happen.


--

2) Also note that for single hop routes without gateway, kernel (pointlessly) does not allow setting the onlink flag:

  # ip route append 1.2.3.4 dev v onlink
  Error: Invalid flags for nexthop - PERVASIVE and ONLINK can not be set.
  # ip route append 1.2.3.4 nexthop dev v onlink
  Error: Invalid flags for nexthop - PERVASIVE and ONLINK can not be set.
  # ip route append 1.2.3.4 nexthop via 192.168.9.1 dev v onlink nexthop dev v onlink
  Error: Invalid flags for nexthop - PERVASIVE and ONLINK can not be set.

NetworkManager works around that by ignoring the "onlink" flag for IPv4 routes which don't have a gateway: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/58011fe88dd8e2601e0919bb9eb8549908957d63

---

3)

Also, NetworkManager can merge ECMP routes "weight". For that, it uses NM_PLATFORM_IP_ROUTE_CMP_TYPE_ECMP_ID. Note that two routes can only be merged to an ECMP route, if they agree in the onlink flag.

With point 2), this also means that a route without gateway cannot merge to an ECMP route with a route that has a gateway and the onlink flag set. That is a big limitation.



Points 1) and 3) need fixing.

Comment 2 RHEL Program Management 2023-08-17 07:27:45 UTC
Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.


Note You need to log in before you can comment on or make changes to this bug.