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

Markus Kittenberger (spam-protected)
Wed Dec 14 11:03:28 CET 2011

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

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

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


#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

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>

More information about the Olsr-dev mailing list