[Olsr-users] Routing-Problem | olsr.org - 0.6.0 | weight | etx_ff | mode ether

[Saverio Proto (ZioPRoTo)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

we have a network very similar to yours in Ninux.org (AP&STA p2p
links) and we share your some problems.

at the moment we use LinkQualityMult to achieve our goal.

we are planning to write some code for GSoC 2012, that will be
hopefully stable by September. This code will allow you to put manual
metric costs on the links instead of ETX. It will be something similar
to OSPF costs.

I will keep both olsr-user and olsr-devs lists updated on our progress.

regards

Saverio Proto


Il 29/03/12 18.46, Michael Rack ha scritto:
> Ok, but how can i tell olsr to prioritize routing on "vlan4" and
> only take "wan" in case "vlan4" is not available?
> 
> 
> Liebe Grüße aus Freilassing,
> 
> Michael Rack RSM Freilassing -- RSM Freilassing
> Tel.: +49 8654 607110 Nocksteinstr. 13                Fax.: +49
> 8654 670438 D-83395 Freilassing            www.rsm-freilassing.de
> 
> 
> Am 29.03.2012 17:15, schrieb Markus Kittenberger:
>> i guess the weight does/did only with hopcount metric,..
>> 
>> Markus
>> 
>> p.s. true 0.5.5 is a previous version, but this was very very
>> very long ago. (-;
>> 
>> On Thu, Mar 29, 2012 at 3:56 PM, Michael Rack 
>> <(spam-protected) 
>> <mailto:(spam-protected)>> wrote:
>> 
>> Dear olsr-users!
>> 
>> I have a bad behavior and hope to get some help.
>> 
>> I run only P2P Links (AP & STA) via wireless-lan and direct 
>> ethernet connections. Every node runs currently olsr version
>> 0.6.0.
>> 
>> The Problem: I have several upstreams and like to define which
>> upstrem to be used via the weight parameter. In previous versions
>> of olsr this worked fine (as i can remember v0.5.5). Now it
>> dosn't.
>> 
>> My Settings:
>> 
>> Willingness             3 LinkQualityLevel        2 
>> LinkQualityAlgorithm    "etx_ff" UseHysteresis   no TcRedundancy
>> 2 MprCoverage     1
>> 
>> InterfaceDefaults { Ip4Broadcast   255.255.255.2555 HelloInterval
>> 2.0 HelloValidityTime   60.0 TcInterval  5.0 TcValidityTime
>> 120.0 MidInterval 5.0 MidValidityTime 120.0 HnaInterval 5.0 
>> HnaValidityTime 120.0 }
>> 
>> Interface "wan" { Mode "ether" Weight 10 }
>> 
>> Interface "vlan2" { Mode "ether" Weight 2 }
>> 
>> Interface "vlan4" { Mode "ether" Weight 5 }
>> 
>> 
>> But currently the wan-interface is selected. While everything
>> goes via "wan" the routing change to "vlan4" but after a few
>> minutes the routing switch back to "wan" and i get a bad
>> packet-loss for 4 seconds while the routing is switching back to
>> "wan" - but i don't know why because both links are up and
>> running. I don't know where the packets get loosed.
>> 
>> Currently Network-Design:
>> 
>> INTERNET-ROUTER | / ------- / \ ------- \ ROUTER A.1
>> ROUTER B.1 |                     | ROUTER A.2           ROUTER
>> B.2 |                     | ROUTER A.3               | |
>> | \ --------\ / ------- / "vlan4"  |   "wan" ROUTER C | ROUTER D 
>> | CLIENT
>> 
>> 
>> 
>> MTR is done via ROUTER D and the internet. The routing decision
>> is made on Router C that is multihomed (A.3 & B.2).
>> 
>> So what have i to do, to make WEIGHT working?
>> 
>> Liebe Grüße aus Freilassing,
>> 
>> Michael Rack RSM Freilassing -- RSM Freilassing
>> Tel.: +49 8654 607110 <tel:%2B49%208654%20607110> Nocksteinstr.
>> 13                Fax.: +49 8654 670438 
>> <tel:%2B49%208654%20670438> D-83395 Freilassing
>> www.rsm-freilassing.de <http://www.rsm-freilassing.de>
>> 
>> 
>> -- Olsr-users mailing list (spam-protected)
>> <mailto:(spam-protected)> 
>> https://lists.olsr.org/mailman/listinfo/olsr-users
>> 
>> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPeWZCAAoJEH+TbpFmVGcvKh0H/1JgYfaaz++bh+R+eeO1G2w4
b57ZoICnDRSLuFy6GP1bAIEF7Z0fKGZyi031upxLW0TKAiWH4ff74U2CMk/+EQbw
ReowcpcSU+v5bPK4tbvbvMzk64vKLedYFovciTZqcsRzhiL3KhY6C0siPhBkFHaH
wI4PD6bWuY41UAk7jtqbbz5jpsOFaPTOVvLbyA0hxm/0v1PKf9rF8J7K91DTsNiE
q7076Bmv5VJvaCEKzBmsv7Dy49WYgVQ9wMrjmck393fR7UDH30VGS33ub1FQ9TaW
fXBMFYS8fCr5LAtia20agAHoGk3VCewQv1ECCqMGASG9m6MgIEk+iAVn5Z0kan0=
=0wPL
-----END PGP SIGNATURE-----