[Olsr-dev] [PATCH 2/4] smart gateway: do not stop choosing a new (better) gateway

Teco Boot (spam-protected)
Thu Dec 8 14:12:18 CET 2011

I saw a "bug" in old behavior. When first selected SGW was lost, no new SGW was selected. The patch in default SGW code should check current tunnel, and set up new one if it was lost.

A more advanced SGW would switch when a far better SGW is available, e.g. < 70% of current SGW costs (70% would be a parameter, similar to NAT-Threshold). < 0% would disable switchover, this could be the default.

Even more advanced: set up multiple SGW tunnels, use best SGW for new connections and keep using these for those connections. How to do this needs more thoughts.

Thanks, Teco

Op 8 dec. 2011, om 13:50 heeft Ferry Huberts het volgende geschreven:

> On 12/08/2011 08:51 AM, Henning Rogge wrote:
>> On 12/08/2011 08:44 AM, Ferry Huberts wrote:
>>>> Have to look at this more closely. The idea behind the "default" gateway
>>>> selector is to select a gateway and stick with it until its gone. Maybe
>>>> "gone" is a bit too late, but if we start choosing another gateway too
>>>> early, we might get gateway-flapping again.
>>> Agree.
>>> However, in our highly mobile networks we have to do something.
>>> This is a short term solution to make it work, and sending out the
>>> patches was also meant to start a discussion on the best solution ;-)
>>> The usual solution is to use some form of hysteresis. We might do
>>> something like 'if there is a better gateway for at least x seconds,
>>> then switch to it'.
>>> What do you think?
>> I think there should be some API calls to overwrite the gateway selector
>> from a plugin, so maybe we could put your selector into one so users can
>> choose between them.
>> At least that was the plan when I designed the code, I don't think
>> anyone has ever wrote a Smart-GW plugin.
> so how do you propose we continue this?
> -- 
> Ferry Huberts
> -- 
> Olsr-dev mailing list
> (spam-protected)
> https://lists.olsr.org/mailman/listinfo/olsr-dev

More information about the Olsr-dev mailing list