[Olsr-users] Sticky gateway [was: olsr and streaming]

Alexander Morlang (spam-protected)
Mon Jan 19 23:08:21 CET 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sven-Ola Tuecke schrieb:
> Hi,
> 
> a tunnel works well - at a first glance. It works, because the gateway-using 
> node has the decision on what gateway it uses. What the nodes in-between 
> think about this decision does not matter.
> 
> At the second glance, auto-tunnels have drawbacks:
> 
> a) difficult to firewall (at least for Gateway-Owner)

can't see that point.

> 
> b) no more traceroute-debugging

not as easy as before, as you have to do the traceroute explicit to the
tunnel endpoint

> 
> c) auto-tunnels do not care about topo.

that is right for the freifunk-gw-tun packet, but it shouldn't. it
depends on implementation, on hysteresis and should be a configuration
parameter with a reasonable default.

> 
> d) tends to be "manually optimized" (or so-to-speak: well optimized, if 
> there's a regulary user, otherwise totally chaotic because it reflects a 
> manual decision in the past)

yes, the "point of view" problem, which occurs, when nodeowner are
starting to "optimize". right now, they do use LQ multiplier, which
messes up routing descisions in the whole neighbourhood, as i recently
had to experience in the marchlewski kiez.

"i want to use _this_ uplink, because it is faster, so i make metrice
bad", which leads to further "optimizations" in the neighbourhood, etc.

in the end, you end up with something which is quasi static routing.

the ability to choose an uplink could lead to better routing, because
user will stop changing metrics for doing that task.

> 
> e) leads to rotten default routes on each node (if that system resource is 
> not used any more by third parties, people start to use default routes as 
> solution for their half-understand routing problems. Which in turn makes 
> default routes for forwarding unusable -> selecting the auto-tunnel route is 
> a one-way-ticket for sure.

this is also a question of the userinterface, it should not support
setting a defaultroute inside the mesh. if you are able to set it
anyway, because you know ssh and shellscripts, you are smart enough to
let it be.

classical layer-8 problem.

> 
> f) if we start auto-tunnels for 0/0 today, tomorrow we use them for /1, then 
> /2 until we reach /32. I'm not sure about the implications.

again a question of user interface. i believe in ssh and shell as a
firewall, so if you want to do stupid things, you should be able to use
the smart tools.

> 
> But yes: it banns the loop-thread for the thesholded default routes and 
> shifts decision from the protocol to the user.
> 

even further, right now, many gateway owner don't care, even know about
netneutrality and are doing heavy firewalling. others might want to
restrict access to the uplink.

without the ability to choose uplinks, there is no possibility to use
uplinks without restrictive policys.
on the other hand, it is not possible to bill uplinks without breaking
connectivity for non paying user.

so, introducing gateway selection gives us a lot to think about social
and organisational issues.

> // Sven-Ola
> 
> ""L. Aaron Kaplan"" <(spam-protected)> schrieb im Newsbeitrag 
> news:(spam-protected)
>> First of all, I want to ask you to elaborate a bit on your claim.
>> Can you give an example? Would be interesting.
>>
>> But so far I think you missed a point from the practical side here :)
>> But I just saw that the others replied to it already.
>>
>>
>> I also recently talked with Hannes - probably the clean way to do that
>> (for NATed networks) is to have an automatic GRE tunnel (or some other
>> tunnel) set up to the default gw which you want to "stick" to.
>> But I guess everybody on the list is open to better proposals.
>>
>> a.
>>
>> summary & short answer from my perspective: "it works reasonably well
>> in all networks in practice which I have encountered for now"
>>
>> -- 
>> Olsr-users mailing list
>> (spam-protected)
>> http://lists.olsr.org/mailman/listinfo/olsr-users 
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkl0+dUACgkQhx2RbV7T5aFgVQCggeUmLd3+wnxl4Kv81o4gNKd8
ClYAoJlF1t42uZCVQHUzP8wUmPaEvgHy
=Ofpg
-----END PGP SIGNATURE-----




More information about the Olsr-users mailing list