[Olsr-dev] Meshing over VPNs

[Benny Baumann]

Hi,

Am 09.10.2011 23:25, schrieb ZioPRoTo (Saverio Proto):
>> 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.
> Hello,
>
> at Ninux we have the same setup. Some nodes of the OLSR network have a
> VPN interface done with tinc-vpn. We used as last resort if some links
> fail, like an OOB access.
>
> in the VPN subnet, OLSR see a full mesh of connections among the vpn nodes
Same here without the mentioned plugin.
> to prefer wireless links instead of VPN we used LinkQualityMult
> configured with 0.2
Simular here.
> I dont understand what feature the plugin adds. I cannot achieve the
> same thing configuring olsrd.conf in the VPN nodes with the required
> LinkQualityMult ?
>
> thanks for clarification
Let's assume you have a Tinc network like this:

A <-> B <-> C <-> D

then usually you'd get all Tinc nodes connected to each other ("full
mesh of connections among the VPN nodes").

The plugin now reads the GraphDumpFile from Tinc (enabled on the local
Tinc node) and gets a list of links like this:

A -> B
B -> A
B -> C
C -> B
C -> D
D -> C

Given this information the plugin now creates dynamically (i.e. while
OLSR is running) LinkQualityMultiplier configuration entries that look
like this:

On Node A:
LQM B 1
LQM default 0.01

On Node B
LQM A 1
LQM C 1
LQM default 0.01

On Node C
LQM B 1
LQM D 1
LQM default 0.01

On Node D
LQM C 1
LQM default 0.01

The result of this configuration is that indirect links from A to D are
treated as nearly non-existing, while direct links (as known from the
Graph Dump File) are treated "as-is"; thus even while indirect links are
still known to OLSR to exist the routing table will use the connections
coming from the GraphDumpFile.

So in a nutshell: Given an automatically updated file with a list of
available "preferred" links you can dynamically reconfigure OLSR to
prefer a given subset of links over other, non-mentioned links.

Also, instead of "preferring" the mentioned links you could also
"discourage" a given subset of links, i.e. if they are costy when using
much bandwidth. For such a configuration the meaning of the "default"
and "dynamic" LQM parameters of the plugin just have to be swapped.

I hope this explains the plugin a bit better.
> Saverio :)
>

-------------- 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/20111010/bf08df2f/attachment.sig>