HOWTO: Learning recursive routes from kernel protocol

[Sergey Popovich]

В письме от 13 мая 2013 21:11:25 пользователь Ondrej Zajicek написал:

> 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.
> 
"onlink" option for ip-route(8) works as expected with IPv4, but current IPv6
implementation does not handle this option, agree.

For IPv6, attached patch works as expected and route learned into BIRD's
routing table from kernel FIB. Thanks for good workaround for current
Linux kernel IPv6 implementation weakness.

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

Oh, this (and many other things with IPv6) is true, thank you againg for 
pointing to this weakness.

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

Good point.

As for me (and from point of our helpdesk) this solution has one big 
disadvantage:
  traceroutes, from external networks to customer network(s) will indicate 
  missing hop - customer gateway, configured with link-local address on its 
  WAN interface (ICMP Destination unreachable dropped by our access server).

There is other minor cases where link-layer address usage is not best choise:    
  - some users like to connect their PC directly to Internet (:-)) (or at 
    least do this to test connectivity and speed).
  - some "network" OS'es in network equipment does not allow (or make things a 
    bit complicated) setting link-layer addresses.

Anyway Ondrej, thank you for taking time on my question and good solution
provided.

-- 
SP5474-RIPE
Sergey Popovich