HOWTO: Learning recursive routes from kernel protocol

[Ondrej Zajicek]

On Mon, May 13, 2013 at 06:13:16PM +0400, ???????????? ?????????????? wrote:
>  Deploying VLAN per user with IP unnumbered schema using Linux as access server
> we face with following problem:
> 
>   BIRD's kernel protocol does not learn routes with nexthop, that resolves trought
>   another route (recursive routes).
..
> 
> Any ideas about solution/other workarouns for this problem are welcome.

Hello

This is essentially a sanity check for validity of next hops. On IPv4,
you could disable it by using 'onlink' option for a route, but it seems
that Linux does not support 'onlink' option for IPv6. The simplest
workaround would be just to disable the check with attached patch.

BIRD does not really need the check, it is enough when there is an
explicitly specified iface in the route. But i guess there would be many
compatibility issues with such kinds of routes - for example, IPv6 Linux
(as i just tested) requires that 'parent' route have to be inserted
before 'child' route, while BIRD kernel protocol does not enforce any
order when exporting routes to kernel.


BTW, it seems that such routes are not really much recursive, if i do
this sequence of commands:

ip -6 route add fd11::2/128 dev eth0
ip -6 route add fd22::/64 via fd11::2
ip -6 route del fd11::2/128 dev eth0
ip -6 route add fd11::2/128 dev eth1

Then kernel reports that fd22::/64 points still to eth0.

> So for typical IPv6 deplyment with IP unnumbered schema we need:
> # ip -6 route add fd11::2/128 dev vlan10 proto static src fd11::1
> # ip -6 route add fd22::/64 dev vlan10 via fd11::2 proto static src fd11::1

BTW, why not to use link-local addressess as a next-hop? That would also
solve the problem in a cleaner way. If you don't want to track automatic
(MAC-based) link-local addres, you could use preconfigured link-local
addresses (fe80::1/64, fe80::2/64) on the 'ptp' vlan. In that case, it
would be enough to assign /64 prefix for a client (no need to assign a
separate /128 IP).

-- 
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: not-check-gw.patch
Type: text/x-diff
Size: 978 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20130513/70cc3d8f/attachment-0001.patch>