• Thomas Haller's avatar
    platform: add non-exclusive routes and drop route-manager · f0de7d34
    Thomas Haller authored
    Previously, we would add exclusive routes via netlink message flags
    NLM_F_CREATE | NLM_F_REPLACE for RTM_NEWROUTE. Similar to `ip route replace`.
    Using that form of RTM_NEWROUTE message, we could only add a certain
    route with a certain network/plen,metric triple once. That was already
    hugely inconvenient, because
     - when configuring routes, multiple (managed) interfaces may get
       conflicting routes (multihoming). Only one of the routes can be actually
       configured using `ip route replace`, so we need to track routes that are
       currently shadowed.
     - when configuring routes, we might replace externally configured
       routes on unmanaged interfaces. We should not interfere with such
    That was worked around by having NMRouteManager (and NMDefaultRouteManager).
    NMRouteManager would keep a list of the routes which NetworkManager would like
    to configure, even if momentarily being unable to do so due to conflicting routes.
    This worked mostly well but was complicated. It involved bumping metrics to
    avoid conflicts for device routes, as we might require them for gateway routes.
    Drop that now. Instead, use the corresponding of `ip route append` to configure
    routes. This allows NetworkManager to confiure (almost) all routes that we care.
    Especially, it can configure all routes on a managed interface, without
    replacing/interfering with routes on other interfaces. Hence, NMRouteManager
    becomes obsolete.
    It practice it is a bit more complicated because:
     - when adding an IPv4 address, kernel will automatically create a device route
       for the subnet. We should avoid that by using the IFA_F_NOPREFIXROUTE flag for
       IPv4 addresses (still to-do). But as kernel may not support that flag for IPv4
       addresses yet (and we don't require such a kernel yet), we still need functionality
       similar to nm_route_manager_ip4_route_register_device_route_purge_list().
       This functionality is now handled via nm_platform_ip4_dev_route_blacklist_set().
     - trying to configure an IPv6 route with a source address will be rejected
       by kernel as long as the address is tentative (see related bug rh#1457196).
       Preferably, NMDevice would keep the list of routes which should be configured,
       while kernel would have the list of what actually is configured. There is a
       feed-back loop where both affect each other (for example, when externally deleting
       a route, NMDevice must forget about it too). Previously, NMRouteManager would have
       the task of remembering all routes which we currently want to configure, but cannot
       due to conflicting routes.
       We get rid of that, because now we configure non-exclusive routes. We however still
       will need to remember IPv6 routes with a source address, that currently cannot be
       configured yet. Hence, we will need to keep track of routes that
       currently cannot be configured, but later may be.
       That is still not done yet, as NMRouteManager didn't handle this
       correctly either.
nm-iface-helper.c 21 KB