[Olsr-users] OLSR setup with VPN interface for management

[Markus Kittenberger]

just do not use 0.1, use at least 0.11 *G

as every link with lq or nlq <0.1 is not used by olsrd for routing anymore.

that means a single lost packet (e.g. ETX 0.99 * 0.1) stops olsrd from using
your vpn link for some minutes,..

Markus

On Mon, Jan 24, 2011 at 11:56 AM, ZioPRoTo (Saverio Proto) <
(spam-protected)> wrote:

> Hello,
>
> at Ninux.org we many nodes of our mesh with also a VPN Interface
> (Internet Tunnel). The VPN is full mesh using tinc.
>
> On the VPN subnet we speak OLSR, because there are some mesh islands
> not connected via radio links.
>
> The problem is that sometimes, between two nodes, there are al least
> two paths, one using only radio links, and another one using the VPN.
>
> To force the traffic to use the VPN only when it is the only possible
> way, the used LinkQualityMult on every node accessing the VPN, putting
> this kind of value on the VPN Interface block.
>
> LinkQualityMult default 0.1
>
> The problem now is that ETX gets so big that no route is added to the
> routing table. We found out that this happens when we have the
> following configuration:
>
> LinkQualityAlgorithm    "etx_fpm"
>
> Commenting this everything works with links with ETX > 100
>
> What is the upped bound of the ETX value for a route to be inserted in
> the routing table ? And so what would be a suggested value for
> LinkQualityMult ?
>
> There is a better way to handle this scenario that is not using
> LinkQualityMult ?
>
> thanks
>
> Saverio
>
> PS our current network is this:
> http://tuscolomesh.ninux.org/images/topology.png
> you can see the VPN links with ETX 104.039
>
> --
> Olsr-users mailing list
> (spam-protected)
> http://lists.olsr.org/mailman/listinfo/olsr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20110124/7716fc73/attachment.html>