[Olsr-dev] Looking for developer feedback on olsrd.conf values

[Markus Kittenberger]

On Wed, Dec 23, 2009 at 9:06 PM, Fred Moyer <(spam-protected)> wrote:

> On Wed, Dec 23, 2009 at 3:56 AM, Markus Kittenberger
> <(spam-protected)> wrote:
> >
> > On Tue, Dec 22, 2009 at 11:42 PM, Fred Moyer <(spam-protected)> wrote:
> >>
> >> On Tue, Dec 22, 2009 at 2:28 PM, Markus Kittenberger
> >> <(spam-protected)> wrote:
> >> > i think the best solution is to do QOS on your links, and priorize
> olsr
> >> > traffic above antything else
> >>
> >> I'm going to be implementing that but wanted to make sure my config
> >> values were not wildly out of whack to start with.
> >
> > i looked at the config now, did you write it (especially the comments)
> > yourself, or did u find this configuration somewhere?
>
> I wrote it based on the initial conf file I was working with, and
> implemented suggestions found in the README files and the default
> fisheye conf file.  I referenced the code as needed for further
> information on directives that weren't fully documented.
>

hmm exactly the answer i was expecting / afraid of *G

it would be a good idea to produce some new sample config files, with
understandable and coorect comments,..

but as we plan to remove many options in the sometimes ready 1.0 release we
always "forget" to do *G

but i think 1.0 will take another year, so we better add new ones to
0.5.6-r8
maybe u can commit or mail your patches, and ...

>
>  > value is not used any more afaik
>
> Good to know, thank you.  May have some patches to the docs for you.
>
> >> >> # require a 50% link quality difference for route switch
> >> >> # http://www.olsr.org/?q=sticky-gateway
> >> >> NatThreshold 0.5
> >
> > the comment is wrong afaik
> > furthermore the more threshhold you use, the more routing loops you might
> > get,
> > do you have multiple gateways? that are doing nat?
>

this is infact a problem *G

on my nodes i do not use nat-threshold (but our mesh in vienna runs on
public ips and so we dont have to nat on the gateways, so switching gateway
introduces no problems)

nat threshold can cause similar errors as fisheye, some routers behave
different than the others might expect

the value u specify is how much the cost of the current route may be worse
than another, while olsr still uses it, the maximum value is 0.99

the problem is that olsr will create a loop to a target x if the sum of the
link costs for all hops to the target is different to the nexthops point of
view by more than 2 times the link cost to the nexthop

usually this constraint holds even with moderate changes in the network

but if your hop uses natthreshold, you cut out up to 0.99 of this

if your neighbour uses natthreshhold aswell, it might cut out another 0.99,
and then we might get really close to problems

our long-term plan is to replace nat-threshhold on the default route, with
tunnels to the gateway (automatically created by olsrd) which can be as
sticky as the user want them, without interferring with routing decissions

(in fact it would be not very much work (in theory *G) to get this running
with at least ipip tunnels, so if u are interested in helping/testing ... )

for the short term i can only hope that your link costs are stable enough,
and using 0.5 for example is far enough from regulary changing gateways, but
also far enough from routing loops,..

usually it works, but i have no experience with this, as luckily we are not
NATING *GGG

Yes, multiple gateways doing nat.  Do you think 0.5 is ok here for
> multiple gateways on a large network, or would you go smaller?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20091223/3d86b188/attachment.html>