Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-1402

fix handling onlink route flag for ECMP routes

Linking RHIVOS CVEs to...Migration: Automation ...Sync from "Extern...XMLWordPrintable

    • None
    • Moderate
    • 1
    • rhel-net-mgmt
    • ssg_networking
    • 3
    • False
    • False
    • Hide

      None

      Show
      None
    • No
    • NMT SST - Future releases
    • Hide

      Definition of Done:

      Please mark each item below with ( / ) if completed or ( x ) if incomplete:

      ( ) The acceptance criteria defined below are met.

      Given a system administrator on a  system with the NetworkManager, and the kernel supports the onlink flag (RTNH_F_ONLINK) associated with each next hop,

      When the system administrator attempts to append two routes that only differ in their next-hop,

      Then the NetworkManager should correctly differentiate between the two routes and not combine them as one entry in the platform cache

      Given a system administrator on a  system with the NetworkManager, and the kernel supports the onlink flag (RTNH_F_ONLINK) associated with each next hop,

      When a route without a gateway is being merged with an ECMP route that has a gateway and the "onlink" flag set

      Then NetworkManager should not combine them due to their differing "onlink" flag states.

      Definition of Done:

      • The implementation meets the acceptance criteria
      • Unit tests and integration tests are written and passed
      • The code is part of a build attached to an errata

      ( ) Code changes are included in a downstream build attached to an errata.

      ( ) All required testing (manual and/or automated) passes successfully.

      ( ) Related documentation updates (if applicable) have been completed.

      Show
      Definition of Done: Please mark each item below with ( / ) if completed or ( x ) if incomplete: ( ) The acceptance criteria defined below are met. Given a system administrator on a  system with the NetworkManager, and the kernel supports the onlink flag (RTNH_F_ONLINK) associated with each next hop, When the system administrator attempts to append two routes that only differ in their next-hop, Then the NetworkManager should correctly differentiate between the two routes and not combine them as one entry in the platform cache Given a system administrator on a  system with the NetworkManager, and the kernel supports the onlink flag (RTNH_F_ONLINK) associated with each next hop, When a route without a gateway is being merged with an ECMP route that has a gateway and the "onlink" flag set Then NetworkManager should not combine them due to their differing "onlink" flag states. Definition of Done : The implementation meets the acceptance criteria Unit tests and integration tests are written and passed The code is part of a build attached to an errata ( ) Code changes are included in a downstream build attached to an errata. ( ) All required testing (manual and/or automated) passes successfully. ( ) Related documentation updates (if applicable) have been completed.
    • None
    • None
    • None
    • 0

      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:

      1. ip route append 1.2.3.4 nexthop via 192.168.9.1 dev v nexthop via 192.168.9.1 dev v
      2. 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:

      1. ip route append 1.2.3.4 dev v onlink
        Error: Invalid flags for nexthop - PERVASIVE and ONLINK can not be set.
      2. ip route append 1.2.3.4 nexthop dev v onlink
        Error: Invalid flags for nexthop - PERVASIVE and ONLINK can not be set.
      3. 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.

              rh-ee-sfaye Stanislas Faye
              thaller@redhat.com Thomas Haller (Inactive)
              Network Management Team Network Management Team
              Desktop QE Desktop QE
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

                Created:
                Updated: