<div><br><div class="gmail_quote">On Tue, Oct 4, 2011 at 2:00 AM, Benny Baumann <span dir="ltr"><<a href="mailto:BenBE1987@gmx.net">BenBE1987@gmx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi guys,<br>(well, several of our routers died regularly from the routing tables<br>
being too large).<br></blockquote>hmm why are the routing tables getting too large?<div><br></div><div>olsrd would anyways just create as many routes as there are targets (hosts)</div><div>(regardless of the topology)</div>
<div><br></div><div>but the with such a huge layer2 broadcast domain, olsrds network topology gets bigger (and therefore the olsrd memeory consumption) </div><div>furthermore the number of olsrd messages might get very unfunny) </div>
<div><br></div><div>and also olsrd can not split hello messages (so they can`t get bigger than 1500bytes), so the number of neighbours that olsrd can handle is limited awell. (with ipv6 even more as with ipv4)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
One solution we (Nemesis, Florz and me) now implemented is using the<br>
Link Quality Multiplier to worsen the percieved link quality of links<br>
inside the Tinc cloud where links we know to be direct connections of<br>
Tinc nodes are treated like normal, but non-direct links get a penalty.<br>
The way this was implemented was by asking Tinc to dump a GraphDumpFile<br>
every minute (unfortunately you can't make this more often) and<br>
reconfiguring the link quality multiplier per link dynamically. The<br>
resulting plugin has been in production for about 4 weeks now and no<br>
major fuckups have been found.<br></blockquote><div>but honestly, this approach doesn`t sound very well,..</div><div><br></div><div>Markus</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br></blockquote></div></div>