[Olsr-dev] [PATCH v3 1/1] smart gateway: add threshold configuration parameter

[Markus Kittenberger]

btw nice SGW gets finally tested/debugged/fixed,..

and ACK, i would not really consider SGW as "very" stable in olsrd,..
but ...

On Tue, Dec 13, 2011 at 10:31 AM, Ferry Huberts <(spam-protected)> wrote:
how about changing the default to 67 percent for the threshold?
>
> we would really like to change that.
>

... afair the main idea/reasoning for SmartGateways in first place, was to
provide a solution for users suffering from changing gateways (which are
doing NAT), leading to changing "public" ips.
(i.e the same issue Nat-Threshold was aimed at, but ...)

or are there new (widely/predominantly used) SGW usecases, i am not aware
of?

imho the "only" behaviour matching the original goal, is to change the
gateway only if the old one ist lost (or maybe got extremely bad/costly),..
i.e. 0 (or a very low value) would be the "correct" default for the
SGW-Threshold

but imho 0.67 is not!
as it might even cause switching between gateways every some minutes in
some spots in some networks,..

furthermore i really do not get the point of wanting the gateway to switch
that early,. #2

as imho configuring the SGW-Threshold too close to 1 would produce more or
less the same routing results as without using smart-gateway at all! #1

Markus

#1 sure its still far better to turn off NAT-Threshold (and its loop
potential) and use an quite early switching smartgateway,

also as it will only switch your own gateway, not disturbing other
nodes/users,.

And btw in mixed network with "old" nodes having NAT-Threshold active, SGW
is great for "new" nodes too, as they do not suffer from the wrong/looping
default routes a active NAT-Threshold might/will cause on the "old" nodes

#2 of course with multiple tunnels and having the old connections stick to
the old tunnel(s) it would be different, but imho this is only doable with
kernel/nat integration of these SGWs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20111214/4bff688a/attachment.html>