Problem with redistribute static routes from venet (openvz pseudointerface)

[Ondrej Zajicek]

On Sun, Mar 20, 2011 at 10:33:12PM +0100, Łukasz Chrustek wrote:
> Hello,
> 
> I would like to import routes (ips exactly, with netmask /32) added by
> openvz virtualization to main ruting kernel table, when the
> virtualization system starts. I don't want to be misunderstand, but in
> quagga it works :), and I would like to test (and switch to) bird.
> Unfortunetly in bird I can't see the routes(ips) from venet0, see
> below. My configuration (most important parts, if You think You will
> need more, please let me now):

Handling device routes in BIRD is a bit tricky - there are two sides
of the problem - import to the BIRD table and export to the kernel table.
(so first is to see the routes in 'show route').

So i understand it correctly that you want to import the routes from
one kernel table and export them to another? (as i see that they already
are in 'ip route ls t 254').

> protocol direct {
>     interface "-eth*", "venet*";    # Restrict network interfaces it works with
> }

Direct would not generate these routes, because they are not addresses assigned
to the iface (in output 'ip a l')

> protocol kernel {
>     learn;          # Learn all alien routes from the kernel
>     persist;        # Don't remove routes on bird shutdown
>     scan time 20;       # Scan kernel routing table every 20 seconds
> #   import none;        # Default is import all
>     import all;
>     export all;     # Default is export none
> #   kernel table 5;     # Kernel table to synchronize with (default: main)
>     kernel table 254;
> }

Kernel protocol with learn may generate these routes, but there is an
exception for device routes in sysdep/linux/netlink/netlink.c:848 :

          /*
           * In Linux IPv6, 'native' device routes have proto
           * RTPROT_BOOT and not RTPROT_KERNEL (which they have in
           * IPv4 and which is expected). We cannot distinguish
           * 'native' and user defined device routes, so we ignore all
           * such device routes and for consistency, we have the same
           * behavior in IPv4. Anyway, users should use RTPROT_STATIC
           * for their 'alien' routes.
           */

	if (i->rtm_protocol == RTPROT_BOOT)
		src = KRT_SRC_KERNEL;

If you remove these two lines and recompile BIRD, you could probably
be able to import device routes.

> protocol static {
>     import all;
>     #route X.Y.10.61/32 via "venet0";
>     #route X.Y.10.60/32 via "venet0";
>     #route 192.168.1.51/32 via "venet0";
>     #route 192.168.1.140/32 via "venet0";
>     #route X.Y.10.64/32 via "venet0";
>     #route X.Y.10.65/32 via "venet0";
> }

This should work (if they are uncommented).


Second thing is to export the routes to the kernel table.
If the routes are from something different than static,
you should use 'device routes' option of kernel protocol
to really allow export of device routes.

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago at 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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20110321/96cacea8/attachment-0001.asc>