Problem with redistribute static routes from venet (openvz pseudointerface)

[Łukasz Chrustek]

Witam,

> 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').

I want to see routes from venet0 in main kernel ruting table

# ip route ls t 254
X.Y.10.61 dev venet0  scope link
X.Y.10.60 dev venet0  scope link
192.168.1.51 dev venet0  scope link
192.168.1.140 dev venet0  scope link
X.Y.10.64 dev venet0  scope link
X.Y.10.65 dev venet0  scope link
X.Y.11.0/29 dev eth0  proto kernel  scope link  src X.Y.11.3
10.1.1.0/24 dev eth1  proto kernel  scope link  src 10.1.1.0
default via X.Y.11.1 dev eth0 onlink

in ruting table in bird (to use them to redistribute to ospf latly),
but in bird I see only those routes:


bird> show route
0.0.0.0/0          via X.Y.11.1 on eth0 [kernel1 22:10] * (10)
10.1.1.0/24        dev eth1 [MyOSPF 22:10] * I (150/10) [X.Y.11.3]
X.Y.11.0/29     dev eth0 [MyOSPF 22:10] * I (150/10) [X.Y.11.3]

>> 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')

Ok, I understand and I figure this out by bringing up another iface on
this server (eth1), the 10.1.1.0/24 route shows up in bird routing
table.

>> 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.

OK, if there won't be any other solution I will check it, thank You.

>> 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).

Unfortunetly, it doesn't work either.

> 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.

OK, I will try this in a moment.


-- 
Regards,
 Łukasz Chrustek