Making the equivalent of iproute2's "bridge mdb|fdb" commands using libnl

Thomas Graf tgraf at suug.ch
Mon Oct 6 04:04:16 PDT 2014


On 10/03/14 at 12:13pm, Thomas Haller wrote:
> On Wed, 2014-10-01 at 20:41 -0400, Laine Stump wrote:
> > In libvirt, I need to be able to get and set the unicast and multicast
> > tables of an interface from within libvirt. Since libvirt uses libnl, it
> > would be most consistent to use libnl to do this; iproute2's "bridge
> > mdb|fdb" command does this, so it could be used as an example, but that
> > is all written to directly use netlink (with help from libnetlink.c in
> > the iproute2 source). I see from that source that the  RTM_GETNEIGH and
> > RTM_GETMDB messages are used to request these tables, but I've been
> > unable to find any examples of using RTM_GETNEIGH or RTM_GETMDB with
> > libnl. Looking at neigh.c in libnl, it seems the information of
> > RTM_GETNEIGH might be stored in a cache by libnl, but I'm not even sure
> > that's the same information that bridge fdb is retrieving, and looking
> > for parallel use of RTM_GETMDB, I see nothing in libnl.
> > 
> > So can anyone unconfuse me? Is there a reasonable example of retrieving
> > these tables using libnl anywhere?
> 
> 
> Hi Laine,
> 
> 
> I am not entirely sure, but...
> 
> 
> 
> libnl3 doesn't even mention the RTM_GETMDB message. So you have to do it
> yourself -- unless you send us a patch for libnl to support it (patches
> welcome).
> 
> 
> But still, using libnl probably helps you significantly with that.
> 
> Have a look at this random patch from NetworkManager, that parses
> netlink messages itself (using libnl3):
> https://git.gnome.org/browse/network-manager-openswan/commit/?h=dcbw/cleanups&id=b8fab11967ff4cbb05bfc170c8590c3d1233c67a
> 
> 
> 
> 
> Regarding RTM_GETNEIGH, neigh.h should give you all you need.
> Looking at neigh.c which reads:
> 
> 
>  * @par 1) Retrieving information about configured neighbours
>  * @code
>  * // The first step is to retrieve a list of all available neighbour within
>  * // the kernel and put them into a cache.
>  * struct nl_cache *cache = rtnl_neigh_alloc_cache(sk);
>  *
>  * // Neighbours can then be looked up by the interface and destination
>  * // address:
>  * struct rtnl_neigh *neigh = rtnl_neigh_get(cache, ifindex, dst_addr);
>>  * // After successful usage, the object must be given back to the cache
>  * rtnl_neigh_put(neigh);
>  * @endcode
> 
> 
> Putting tgraf in CC. @Thomas, please correct me if I am wrong.

Adding support for RTM_GETMDB to libnl would be very straight forward.



More information about the libnl mailing list