[PATCH] Netlink: add krt_scope attribute

[Vincent Bernat]

 ❦ 15 septembre 2016 20:36 CEST, Ondrej Zajicek <santiago at crfreenet.org> :

> Thans for the patch. I agree that we should handle the attribute
> if it has some usage. I have some questions/comments:
>
> Perhaps we should use the same approach like we use for krt_realm?
> i.e., handle krt_scope as an integer variable and import constants
> from /etc/iproute2/rt_scopes. So we could handle all values as the
> Linux kernel and we would be consistent with iproute2 tools.

I didn't know that scope names could be defined in this file. So, yes,
we should.

> I don't really understand how Linux handles scope argument. If i
> remember correctly, the idea is that next hop of a route could be
> resolvable through a route with higher scope value, but it seems
> that it distinguish only host (internal), link and anything other.

At least, Linux will refuse to install a route "scope global" when the
next-hop is "scope global" too.

>> A typical use case is to install "scope link" routes for directly
>> connected destinations, as the kernel won't accept routes with a broader
>> scope when issuing an internal lookup.
>
> You mean for regular routes (with next hop) or device routes?

Device routes.

> I though that kernel sets scope link automatically for device routes,
> but in reality it is done by ip tool. Perhaps we should do that too.

For device routes created by the kernel, scope is link, but if you
create them manually, you get a global scope.

> I could create regular routes with scope link directed to device routes
> with scope link (which is a bit strange) and then create regular routes
> with normal scope directed on them, but i cannot get more hierarchy.

In fact, I need top copy device routes from main table to other tables
(to workaround a limitation with Linux kernel before 3.15). Currently,
they are copied with "scope global". I need them to copy them with
"scope link", otherwise BIRD won't be able to install routes with a
next-hop in the connected subnet.
-- 
10.0 times 0.1 is hardly ever 1.0.
            - The Elements of Programming Style (Kernighan & Plauger)