[Olsr-dev] gateway code
Tue Jul 24 14:04:37 CEST 2012
On Tue, Jul 24, 2012 at 1:49 PM, Teco Boot <(spam-protected)> wrote:
> Op 24 jul. 2012, om 13:22 heeft Henning Rogge het volgende geschreven:
> > On 07/24/2012 01:15 PM, Teco Boot wrote:
> >>> Has been some time since I even looked into this code... the code
> >>> you removed were responsible for detecting a tunnel going down and
> >>> up again (because I thought it is necessary to set the route into
> >>> the tunnel again).
> >>> Its not really common, but could be potential annoying.
> >>> Can you test if what happens to the smart-gw if you take a tunnel
> >>> down and up again from the shell?
> >> Manual interference with unmanaged tunnels is a request for trouble.
> >> If there is a side effect on tunnel_down (e.g. removed routes), that
> >> is how it is designed. Let's have a clean smart-gw.
> > At the moment there would be no way to restore the route for the tunnel.
> That is why the mechanism was inside.
> Manual ifconfig xxx down ; ifconfig xxx up needs manual ip route add xxxx
> If tunnel can go down caused by unknown reason, and goes up by magic
, then we may needs such.
> Better not depend on magic, and if so, lets task this magic with the
> complete job :-)
> (I could miss something here)
imho if the smartgateway tunnel (which oslrd created) goes down, maybe
olsrd should destroy/remove the tunnel. (-> doing this makes sure it can
not go magically up again,..)
and afterwards (maybe with same delay as on intial olsrd start) look for a
new smart-gateway and if found/choosen create a new tunnel.
> > Similar for mesh interfaces, if they go up again, OLSRd must restore the
> If iface goes down, all neighbor state should be cleaned up.
> After it goes up again, adjacency will follow and routes will be restored.
afair this is exactly what currently happens, isn't it?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Olsr-dev