[Olsr-dev] Meshing over VPNs

[Benny Baumann]

Hi Markus,

Am 04.10.2011 11:23, schrieb Markus Kittenberger:
> On Tue, Oct 4, 2011 at 2:00 AM, Benny Baumann <(spam-protected)
> <mailto:(spam-protected)>> wrote:
>
>     Hi guys,
>     (well, several of our routers died regularly from the routing tables
>     being too large).
>
> hmm why are the routing tables getting too large?
When doing FIBMetric "correct" the RT not only holds one route per
destination, but one route per distance and host. So sometimes we get up
to 2 or 3 routes per host.
> olsrd would anyways just create as many routes as there are targets
> (hosts)
> (regardless of the topology)
Yes, but using the plugin we can somehow channel these routes somewhat
and make some of them appear as "INFINITE" so OLSR knows the host is
there, but doesn't try to route directly to it. And that's what wwe
wanted to get.
> but the with such a huge layer2 broadcast domain, olsrds network
> topology gets bigger (and therefore the olsrd memeory consumption) 
> furthermore the number of olsrd messages might get very unfunny)
Problems arose for us at only about 10-15 nodes in the Tinc network. A
live graph can be seen at http://graph.chemnitz.freifunk.net/ffc.svg The
plugin doesn't run on all the (pink) nodes yet, but on those which have
it you'll see no gray lines (which are the virtual connections Tinc
introduces). The pink lines are direct Tinc connections. BTW: This
drastically reduces the size of TC messages which are much more common
than the HELLO messages (I sent the stats for our network previously on
the list). For all the Tinc nodes we use HELLO intervals of sometimes up
to 5 minutes thus there's not much concern regarding HELLO messages;
more regarding TC. Currently we have 4.5KB/s TC down and 0.5KB/s TC up;
which makes using the network on Edge links feasable (not quite nice,
but feasable).
> 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)
But as far as I understand it OLSR doesn't include INFINITE/non-SYMM
links in the HELLO-message. And as we are dropping default quality down
to INFINITE those get removed.
>
>     One solution we (Nemesis, Florz and me) now implemented is using the
>     Link Quality Multiplier to worsen the percieved link quality of links
>     inside the Tinc cloud where links we know to be direct connections of
>     Tinc nodes are treated like normal, but non-direct links get a
>     penalty.
>     The way this was implemented was by asking Tinc to dump a
>     GraphDumpFile
>     every minute (unfortunately you can't make this more often) and
>     reconfiguring the link quality multiplier per link dynamically. The
>     resulting plugin has been in production for about 4 weeks now and no
>     major fuckups have been found.
>
> but honestly, this approach doesn`t sound very well,..
We tried the other way around by trying to figure out a way to
distribute broadcasts via Tinc only to directly connected routes. But
Tinc doesn't allow this in a nice manner. The way we didn't try was
blocking 655/udp in iptables at chain FORWARD ... But I doubt this would
have worked, nor that this would be a nice way to go.
> Markus
BenBE.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 479 bytes
Desc: OpenPGP digital signature
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20111004/17b7e285/attachment.sig>