[Olsr-dev] SmartGW client side questions

Henning Rogge (spam-protected)
Wed Apr 28 16:59:55 CEST 2010

Am Mittwoch 28 April 2010 15:51:22 schrieb Teco Boot:
> Sorry for not responding earlier. I think this smart-gw is
> very useful. I don't have cycles to check it right now.
> Op 28 apr 2010, om 14:43 heeft Sven-Ola Tuecke het volgende geschreven:
> > Yes - of course. A question: do we need that tnl_$%abcd name for the
> > smargw-client tunnel interface? I only expect one iface (because only one
> > default-route-via-tunnel at a time").
> One tunnel doesn't provide multi-path transport protocols. And cannot
> support seamless handover. For this, we need source address based routing,
> for outgoing tunnel selection. It's a next step.
Or we need to use multiple tunnels. One for the old gateway, one for the new 
one. With a src-based policy routing in the local node.

That's why there is already the option for IPv6 gateways to announce their 
external IPv6 prefix. It allows a client (with the right plugin and scripts) 
to reconfigure it's local IP to fit the external gateway prefix. It just have 
to set a new HNA so that the backward route is established.

But that (or the src-ip based policy routing) is future work. :)

> I proposed BRDP based routing, where instead of a default route,
> packets are routed to a GW that "owns the source address prefix".
> This is proposed for IPv6 / Autoconf and more a long term solution.
> http://tools.ietf.org/id/brdp
> http://www.inf-net.nl/brdp.html
> I think BRDP-based-routing can be used with the smart-gw-tunnels.
> It solves ingress filter problems.
Yes, we dicussed a similar thing... but it cannot be done for kernel 2.4, 
because we cannot do IPv6 policy routing with kernel 2.4.


1) You can't win.
2) You can't break even.
3) You can't leave the game.
— The Laws of Thermodynamics, summarized
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20100428/4b73c735/attachment.sig>

More information about the Olsr-dev mailing list