How to obtain routing information from a cache object

[Thomas Haller]

On Mon, 2017-04-10 at 13:32 +0100, Thomas Lloyd wrote:
> Hi All,
> 
> I have been looking through the libnl documentation and come across
> the
> cache manager functionality.
> 
> My end goal is to query the next hop for a specific IP address. So
> basically what nl-route-get is providing.
> 
> Is it possible to query the cache rather than send a netlink message
> each
> time I want to query routing information.
> 
> I can imagine that keeping the cache up to date is straight forward
> however I don't see how you use the cache to get the
> routing information rather than sending a nl message.
> 
> I have the nl message sending code working but would it be possible
> to use
> a cache/manager implementation.
> 
> Are there any examples of what I am trying to do or did I
> misunderstand
> how the cache can be used.
> 
> Thanks,
> 
> Tom

Hi,


the kernel exposes the routing table via netlink. So, in principle you
could re-implement the logic for `ip route get` based on that
information. In the simple case that might be straight forward, but the
proper solution could be rather complex (source routing, etc).


From kernel you can dump all routing information with a
RTM_GETROUTE/NLM_F_DUMP message.
If you want to keep the routing cache up to date, you possibly would
also enable nl_socket_add_memberships(RTNLGRP_IPV4_ROUTE), so that you
get events when something changes. You would have to select/poll (or
read synchronously) on the netlink socket and process the events.
Basically, what `src/nl-monitor ipv4-route` does.


libnl3 has an implementation of the cache. So, you could use that.
The cache doesn't give you a functionality like evaluating `ip route
get` locally. It basically just keeps a list of all routes. You'd have
to search it manually to determine which route matches.

Note that the route cache implementation in libnl3 has an issue in that
takes as cache-id for a route the "family,destinaion/plen,metric". That
however is not what kernel does, as you can add two routes that only
differ by some other paramter. libnl3 cache would wrongly map those to
the same  entry.

Have a look at the example programs in "src".


best,
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20170413/df5c7ba2/attachment.sig>