[Olsr-users] OONF equivalent for LinkQualitMult

Henning Rogge (spam-protected)
Mon Oct 15 13:11:32 CEST 2018


Okay...

this is my idea:

you could run a mesh with two topologies, one with the VPN links and
one without the VPN links... if the routing table of the "no VPN"
topology is used first, it should always have priority, not depending
on the metric values.

The only piece that is missing would be a plugin that allow you to
block an interface (in this case the VPN one) for one of the two
topologies. I could solve this "code" problem.

Would you be interested in testing something like this?

Henning
On Mon, Oct 15, 2018 at 11:43 AM Gabriel <(spam-protected)> wrote:
>
> Il 2018-10-15 10:18 Henning Rogge ha scritto:
> > On Fri, Oct 12, 2018 at 4:07 PM Gabriel <(spam-protected)> wrote:
> >>
> >> Hello, i have a management VPN interconnecting many nodes of a WCN. I
> >> need to set a multiplier or an additional weight on the vpn interface
> >> of
> >> each node to avoid traffic going trough it.
> >> In olsrv1 I used the "LinkQualityMult" option with a value of 0.2
> >
> > At the moment there is no "manual metric change" plugin... I didn't
> > implement one because most uses seem to deal with micromanaging the
> > route decision of olsrd(2). In theory you could just set a low
> > link-speed for the VPN link and the DAT metric should automatically
> > give it a higher link-cost.
> >
> > The problem with the link-quality parameter of olsrd1 is that it just
> > doesn't work well, especially for larger networks.
> >
> > I assume you have multiple VPN links to a central server, which also
> > runs olsrd2, right?
> I have a tinc VPN, so the node in the VPN forms a full mesh topology, on
> top of that OLSRv2 runs.
>
>   And that you only want to use these links if no
> > chain of radio links exist towards you target... would you be
> > interested in trying a different solution?
> Yes, that is the idea.
>
> Gabriel



More information about the Olsr-users mailing list