On Thu, Sep 15, 2016 at 06:05:27PM +0200, Vincent Bernat wrote:
The general-purpose scope attribute is detailed in the documentation as an attribute that BIRD won't set and won't use. Therefore, to expose the scope of a kernel route, this commit adds a new attribute, krt_scope. Its possible values are the numeric values for SCOPE_* variables (1 is SCOPE_LINK for example), not the values from the kernel (253 is RT_SCOPE_LINK). Both import and export are supported.
Hi 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 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.
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? 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. 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. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."