<br><br><div class="gmail_quote">On Wed, Dec 23, 2009 at 9:06 PM, Fred Moyer <span dir="ltr"><<a href="mailto:fred@slwifi.com">fred@slwifi.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Wed, Dec 23, 2009 at 3:56 AM, Markus Kittenberger<br>
<div class="im"><<a href="mailto:Markus.Kittenberger@gmx.at">Markus.Kittenberger@gmx.at</a>> wrote:<br>
><br>
> On Tue, Dec 22, 2009 at 11:42 PM, Fred Moyer <<a href="mailto:fred@slwifi.com">fred@slwifi.com</a>> wrote:<br>
>><br>
>> On Tue, Dec 22, 2009 at 2:28 PM, Markus Kittenberger<br>
>> <<a href="mailto:Markus.Kittenberger@gmx.at">Markus.Kittenberger@gmx.at</a>> wrote:<br>
>> > i think the best solution is to do QOS on your links, and priorize olsr<br>
>> > traffic above antything else<br>
>><br>
>> I'm going to be implementing that but wanted to make sure my config<br>
>> values were not wildly out of whack to start with.<br>
><br>
> i looked at the config now, did you write it (especially the comments)<br>
> yourself, or did u find this configuration somewhere?<br>
<br>
</div>I wrote it based on the initial conf file I was working with, and<br>
implemented suggestions found in the README files and the default<br>
fisheye conf file.  I referenced the code as needed for further<br>
information on directives that weren't fully documented.<br></blockquote><div><br></div><div>hmm exactly the answer i was expecting / afraid of *G</div><div><br></div><div>it would be a good idea to produce some new sample config files, with understandable and coorect comments,..</div>
<div><br></div><div>but as we plan to remove many options in the sometimes ready 1.0 release we always "forget" to do *G</div><div><br></div><div>but i think 1.0 will take another year, so we better add new ones to 0.5.6-r8</div>
<div>maybe u can commit or mail your patches, and ...</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br> > value is not used any more afaik<br>
<br>
</div>Good to know, thank you.  May have some patches to the docs for you.<br>
<div class="im"><br>
>> >> # require a 50% link quality difference for route switch<br>
>> >> # <a href="http://www.olsr.org/?q=sticky-gateway" target="_blank">http://www.olsr.org/?q=sticky-gateway</a><br>
>> >> NatThreshold 0.5<br>
><br>
> the comment is wrong afaik<br>
> furthermore the more threshhold you use, the more routing loops you might<br>
> get,<br>
> do you have multiple gateways? that are doing nat?<br></div></blockquote><div><br></div><div>this is infact a problem *G</div><div><br></div><div>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) </div>
<div><br></div><div>nat threshold can cause similar errors as fisheye, some routers behave different than the others might expect</div><div><br></div><div>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</div>
<div><br></div><div>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</div>
<div><br></div><div>usually this constraint holds even with moderate changes in the network</div><div><br></div><div>but if your hop uses natthreshold, you cut out up to 0.99 of this</div><div><br></div><div>if your neighbour uses natthreshhold aswell, it might cut out another 0.99, and then we might get really close to problems</div>
<div><br></div><div>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</div>
<div><br></div><div>(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 ... )</div><div><br></div><div>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,..</div>
<div><br></div><div>usually it works, but i have no experience with this, as luckily we are not NATING *GGG</div><div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Yes, multiple gateways doing nat.  Do you think 0.5 is ok here for<br>
multiple gateways on a large network, or would you go smaller?<br>
<div class="im"><br> </div></blockquote></div>