[Babel-users] preferred source address on installed routes

Julien Muchembled jm at jmuchemb.eu
Sun Sep 16 18:57:30 UTC 2012


Hello,


Attached patch is a draft so that Babel can be configured to set the 'src' field on routes it installed. It does what we need, but I would be less ugly if 'in' filter was added a 'src <ip>' action (instead of a command-line option).


In our setup, we are using Babel to build a kind of VPN, with following properties:
- we were given a /48 for our machines, e.g. 2001:db8:42::/48
- each node gets a /64 from this /48
- routing is done by Babel
- when 2 nodes are not in the same LAN, they communicates through a tunnel (tap interface), so Babel actually runs on several interfaces: a LAN one and several taps
- one of the nodes acts as a gateway to the internet

But some machines already has good IPv6 connectivity with their FAI box so for performance reason, we'd like them to still use it when possible.
OTOH, we have machines that would share their /64 with other machines (using radvd/dhcpd6).

Let's see our most complex example:
- sysctl use_tempaddr = 2
- eth0: linked to the FAI box
  - 2001:db8:1:3::5/64 scope global temporary dynamic
  - with a default route via fe80::1
- eth1:
  - 2001:db8:42:2::1/64 scope global
  - radvd/dhcpd6 to other machines
- several tap interfaces for tunnels
- Babel running on eth0 and taps:
  redistribute local deny
  redistribute ip 2001:db8:42:2::/64 eq 64
  redistribute deny

Here is how one would configure routes manually:
# VPN
2001:db8:42:0::/64 src 2001:db8:42:2::1 via fe80::2 dev tapA
2001:db8:42:1::/64 src 2001:db8:42:2::1 via fe80::3 dev eth0
2001:db8:42:2::/64 dev eth1
2001:db8:42:3::/64 src 2001:db8:42:2::1 via fe80::2 dev tapA
2001:db8:42:4::/64 src 2001:db8:42:2::1 via fe80::4 dev tapB
...
unreachable 2001:db8:42::/48
default from 2001:db8:42::/48 via fe80::2 dev tapA
# FAI
2001:db8:1:3::/64 dev eth0
default via fe80::1 dev eth0

Testing:
- ip route get 2001:db8:42:4::1
via fe80::4 dev tapB src 2001:db8:42:2::1
- ip route get ipv6.google.com
via fe80::1 dev eth0 src 2001:db8:1:3::5
- ip route get ipv6.google.com from 2001:db8:42:4::1
via fe80::2 dev tapA


* Why 'src' ? Because most of time, the VPN IP is not on the outgoing interface, the kernel may select the FAI one. Here is what we could get if there was no preferred source [1]:
- ip route get 2001:db8:42:4::1
via fe80::4 dev tapB src 2001:db8:1:3::5
(IOW, a ping to 2001:db8:42:4::1 would fail on the return path)

Our current workaround, because Babel can't set source address, is to use ip-addrlabel. This solves the case for interfaces without any IP (taps). But in the above example, this is not enough for eth0.

* Why 'from' ? Routers may drop packets with unrecognized source address. So when forwarding a packet from the VPN to outside (i.e. the src IP is already to something in 2001:db8:42::/48, unlike the dst IP), the packet must continue its route up to VPN gateway, and only there it will be sent to the internet. Our current workaround is to use ip-rule (and tell Babel to use a separate table). This works perfectly but it would be simpler if Babel could set a 'from' address (e.g. with a additional 'from <prefix>' on input filter).


Regards,
Julien

[1] In fact, there's rule saying the IP with longest matching prefix should be selected, but this is the last one of the RFC, and it's not mandatory. Previous rule may decide to use a temporary address (hence, use_tempaddr=2).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-RTA_PREFSRC.patch
Type: text/x-patch
Size: 4286 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20120916/1b6f889e/attachment.bin>


More information about the Babel-users mailing list