[Olsr-dev] Use Case for rttable_tunnel

[Markus Kittenberger]

On Wed, Mar 3, 2010 at 11:46 AM, Sven-Ola Tuecke <(spam-protected)> wrote:

> Hey,
>
> the (new) rttable_tunnel parameter as well as the following defaults will
> break some features:
>
> #define DEF_RTTABLE_DEFAULT  112
> #define DEF_RTTABLE_TUNNEL   113
>
> Obviously, the tunnel-default-route should not be executed if olsrd sets a
> standard default route. I presume, the author has some "ip rules add" in
> mind
> otherwise it's useless...?
>
olsrd can create a basic set of policy rules on its own,  but more complex
will require manual configuration f the rules

maybe rules and tables dyn_gw needs can also be easily integrated in the
"default" rules olsrd generates (when smartgateway is used)

>
> Where I expect conflicts: at a given time only ONE default route will be
> used
> by a particular station/user. I use that rttable_default setting for users
> which will join the mesh but do not want to share their inet connection
> (aka.
>
just put the default route for the user in a table at which a rule with prio
< olsrd tables rule priorities that matches only "lan" interface (and in
this case you could additianlly turn off smartgateway anyway as the users
doesn need/want it)

> my-Internet-for-me-alone). He/she will (of course) not block inet traffic
> generated by others. As a second use case, there is the "dyn_gw_plain"
> stuff.
> Which (if the gateway is unusable) shifts the 254-default route in a
> background table only valid for the current device.

which one? does it create/configure this table alone? (or does it require
external configuration)

> This is necessary,
> otherwise you cannot determine if that gateway will come up again.
>
in theory there are not much problems,..

it a default route is in maintable it will be found first (and if dyn_gw
moves this route into some other table to make it used only locally it will
work (as long as an mathing policy rule makes sure this other table is for
local traffic only and inspected before the other olsrd tables))

imho the rtTable_default table ist used very exactly as the old one, and it
has precedence to the smartgateway table for all traffic coming from olsr
neighbours

only the local nodes traffic is put into its own tunnel

(above is only the case in the policyrouting mode of smartgateway, it can
also put everthing into one table (which is not recommended (but there are
some exceptions)))

>
> Can someone shed some light on this setting? (BTW: there will be no
> IPv6-ipip-tunnel without backporting some 2.6.x code to linux-2.4)
>
the real problem of 2.4 + ipv6 is its lack of policy routing (and routing
tables) (there's at least one insane workaround i know)

but in genreal on 2.4 kernels only ipv4 tunnels are reasonable/available (at
the moment)

Markus

p.s. i think there will be some readme about this, (which henning wanted to
write (maybe its already done?), but i found non in the repo)
at least there is a google wave document describing operation/specification
of smartgateway

ask henning or me if u want to read this wave (as it might need changes for
your use-cases)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20100303/c58bcba4/attachment.html>