olsrd_dyn_gw.so.0.5 funktioniert glaub ich nicht wirklich
Tom Green
koe_fue at gmx.de
Mi Okt 14 14:07:04 CEST 2015
hallo,
die hohe cpu last kam daher, dass nach update auf olsr 0.9 das dotdraw
plugin sekündlich ausgeführt wurde. normal ist alle 5 minuten.
ich hab es jetz deaktiviert. jetzt ist wieder alles im normalbereich. es
hat entsprechend auch eine illuste anzahl an dot Dateien auf der HDD
hinterlassen.
torben
On 09.10.2015 17:38, Tom Green wrote:
> # Polling rate in seconds(float).
> # Default value 0.05 sec
>
> #Pollrate 0.1
> Pollrate 0.5
>
>
> On 09.10.2015 17:35, Michael Fritscher wrote:
>> Hi,
>>
>> was meinst du mit poll rate? Den Parameter Intervall bei dyn_gw?
>>
>> Da würde ich nicht unter 5 sec gehen, weil der Aufruf des ping-Programs
>> sowie des pings an sich schon Zeit benötigt. Wenn der ping in ein Timeout
>> läuft kann man schonmal mit 3 Sekunden rechnen. Vermutlich waren die
>> Ping-Prozesse zu schnell wieder weg als du sie in top o.ä. gesehen hast.
>>
>> Viele Grüße,
>> Michael
>>
>>> Hi,
>>>
>>> also ich glaube, das olsr sorgt für ordentlich prozessorlast.
>>>
>>> olsrd 0.6 ohne funktionierendes dyn_gw= 30%
>>> olsrd 0.9 mit funktionierendes dyn_gw / (poll rate=0.1sec)= 100%
>>> olsrd 0.9 mit funktionierendes dyn_gw / (poll rate=0.5sec)= 50%
>>>
>>> wenn ich es olsrd 0.9 kille, bin ich wieder bei 30%.
>>>
>>> Das Merkwürdige ist, die Last taucht nicht bei den Einzelprozessen auf.
>>> D.h. olsr selber wird < 1% angezeigt und die Summe aller Prozesse ist so
>>> 30%. Trotzdem steht die globale Anzeige dann höher. Auch sehr strange
>>> iwie.
>>>
>>> So...genug rumgespielt :)
>>>
>>> Gruß
>>> Torben
>>>
>>> On 09.10.2015 15:17, Tom Green wrote:
>>>> Hallo,
>>>>
>>>> Also hab mal von ca. 14:15 bis 15:05 Uhr den openvpn tunnel ins
>>>> Internet für kleev2 gekillt.
>>>>
>>>> Im Ergebnis:
>>>>
>>>> * Leitet den Traffic von kleev2 über nue1 nach Berlin
>>>> * rödelt bei 100% Prozessorlast (!)
>>>> * Wechselt kurzzeitig von nue1 auf cdfue1 -> Eingehender Traffic von
>>>> cdfue1 ?
>>>> * Durchsatz nach nue1 deutlich unter Normal verglichen zu dem, was
>>>> sonst durch den Tunnel geht. 220MB vs. 1..2 GB
>>>> * Stellt nach Wiederbeleben des openVPN-Tunnels die reguläre
>>>> Verbindung wieder her.
>>>>
>>>> Plots / Statistiken:
>>>> Übersicht: http://10.50.32.7/mrtg/
>>>> Traffic Tunnel:
>>>> http://10.50.32.7/vnstat/index.php?if=tun0&graph=large&style=light&page=h
>>>> Traffic Nue1:
>>>> http://10.50.32.7/vnstat/index.php?if=nue1&graph=large&style=light&page=h
>>>> Traffic cdfue1:
>>>> http://10.50.32.7/vnstat/index.php?if=cdfue1&graph=large&style=light&page=h
>>>>
>>>> Wen es interessiert.
>>>>
>>>> OLSR: olsr.org -
>>>> 0.9.0.3-git_0000000-hash_309bb6eddd252f7728c49630bf2a9650 (built on
>>>> 2015-10-09 07:01:46 on KleeV2)
>>>>
>>>> Gruß
>>>> Torben
>>>>
>>>> On 09.10.2015 12:24, Tom Green wrote:
>>>>> Hi,
>>>>>
>>>>> sehr sehr geil. es klappt.
>>>>>
>>>>> gerade den openvpn gekillt. neue default route in der fff-Tabelle:
>>>>> nue1.
>>>>> Das Standard-GW aus der HNA Tabelle ausgetragen.
>>>>>
>>>>> Und der Traffic geht über nue1 auch raus:
>>>>> traceroute to web.de (82.165.230.17), 30 hops max, 60 byte packets
>>>>> 1 10.50.32.7 (10.50.32.7) 49.031 ms 58.299 ms 58.704 ms
>>>>> 2 10.50.32.2 (10.50.32.2) 52.360 ms 56.693 ms 57.065 ms
>>>>> 3 * * *
>>>>> 4 bgp02.berlin.freifunk.net (77.87.49.65) 71.193 ms 72.389 ms
>>>>> 73.993 ms
>>>>> 5 syseleven-k15.bcix.de (193.178.185.48) 77.885 ms 80.462 ms
>>>>> 81.308 ms
>>>>> 6 ae0-0.bki1-r2.syseleven.net (77.247.83.197) 82.286 ms 61.621 ms
>>>>> 55.522 ms
>>>>> 7 xe-1-0-0-0.bgr1-r1.syseleven.net (37.49.152.237) 67.371 ms 67.859
>>>>> ms 83.447 ms
>>>>> 8 amsix.bb-c.nkf.ams.nl.oneandone.net (80.249.208.220) 86.577 ms
>>>>> 90.020 ms 91.124 ms
>>>>> 9 ae-6.bb-c.act.fra.de.oneandone.net (212.227.120.130) 92.113 ms
>>>>> 92.755 ms 96.683 ms
>>>>> 10 ae-11.bb-c.bs.kae.de.oneandone.net (212.227.120.18) 102.691 ms
>>>>> 103.886 ms 93.043 ms
>>>>> 11 ae-3.bb-c.bap.rhr.de.oneandone.net (212.227.120.71) 82.322 ms
>>>>> 100.314 ms 100.898 ms
>>>>> 12 ae-4.gw-diste-a.bap.rhr.de.oneandone.net (212.227.121.161) 209.359
>>>>> ms 207.703 ms 203.049 ms
>>>>> 13 bap.web.de (82.165.230.17) 94.552 ms 98.365 ms 98.422 ms
>>>>>
>>>>> allein der squid auf kleeV2 blockiert den Mechanismus z.Zt. noch. ohne
>>>>> klappt es.
>>>>>
>>>>> openvpn tunnel wieder gestartet: beide GWs als default eingetragen
>>>>> root at KleeV2:~# ip route show table fff | grep default
>>>>> default via 10.8.8.29 dev tun0
>>>>> default via 10.50.252.19 dev nue1 proto gated metric 2 onlink
>>>>>
>>>>> Dank der besseren Metric routet er wieder über den VPN Tunnel:
>>>>> traceroute to web.de (82.165.230.17), 30 hops max, 60 byte packets
>>>>> 1 10.50.32.7 (10.50.32.7) 54.452 ms 58.998 ms 59.876 ms
>>>>> 2 * * *
>>>>> 3 po66.evo-hv15.leaseweb.com (95.211.205.126) 76.840 ms 80.600 ms
>>>>> 80.931 ms
>>>>> 4 xe-2-2-2.evo-hvc2.leaseweb.net (81.17.33.58) 81.881 ms
>>>>> xe-4-0-0.evo-hvc1.leaseweb.net (81.17.33.44) 88.665 ms
>>>>> xe-3-0-3.evo-hvc1.leaseweb.net (81.17.33.46) 89.921 ms
>>>>> 5 tengige0-2-0-2.bb03.ams-01.leaseweb.net (31.31.38.16) 90.643 ms
>>>>> tengige0-2-0-3.bb03.ams-01.leaseweb.net (31.31.38.18) 92.004 ms
>>>>> tengige0-0-0-6.bb03.ams-01.leaseweb.net (31.31.38.32) 92.765 ms
>>>>> 6 amsix.bb-c.nkf.ams.nl.oneandone.net (80.249.208.220) 102.124 ms
>>>>> 58.475 ms 58.718 ms
>>>>> 7 ae-6.bb-c.act.fra.de.oneandone.net (212.227.120.130) 70.568 ms
>>>>> 71.178 ms 72.433 ms
>>>>> 8 ae-11.bb-c.bs.kae.de.oneandone.net (212.227.120.18) 83.909 ms
>>>>> 93.405 ms 96.000 ms
>>>>> 9 ae-3.bb-c.bap.rhr.de.oneandone.net (212.227.120.71) 86.480 ms
>>>>> 87.068 ms 92.271 ms
>>>>> 10 ae-5.gw-diste-a.bap.rhr.de.oneandone.net (212.227.122.1) 101.313
>>>>> ms 92.526 ms 62.426 ms
>>>>> 11 bap.web.de (82.165.230.17) 64.141 ms 67.265 ms 69.874 ms
>>>>>
>>>>>
>>>>> Sehr schön. Danke Tobias, Christian, Jan & Michael :)
>>>>>
>>>>> sieht erstmal nicht verkehrt aus....
>>>>>
>>>>> Gruß
>>>>> Torben
>>>>>
>>>>> On 09.10.2015 10:36, Michael Fritscher wrote:
>>>>>> Hi,
>>>>>>> "Eigentlich" "müsste" wahrscheinlich "nur mal" "jemand" "schnell" das
>>>>>>> obere repository bauen.
>>>>>> Erledigt :-) Eine 0.9.0.3 gibts unter
>>>>>> https://mifritscher.de/austausch/olsrd/ . Das bauen war sehr einfach,
>>>>>> weil
>>>>>> die debian-buildscripte schon existierten. Ich musste nur die
>>>>>> Changelog-Datei ergänzen, damit das Buildsystem weiß, dass es die
>>>>>> 0.9.0.3
>>>>>> ist (sonst wäre ein Paket rausgekommen, wo zwar 0.6.6.2-1 draufsteht,
>>>>>> aber
>>>>>> 0.9.0.3 drin ist^^)
>>>>>>
>>>>>> Ist völlig ungetestet und derzeit nur 64 Bit. Auf Anfrage kompiliere
>>>>>> ich
>>>>>> aber auch x86 32 Bit. Ich werde es heute Abend mal kurzzeitig auf
>>>>>> meinem
>>>>>> Gateway hauen und schauen, ob es funktioniert - und ob es mit der
>>>>>> 0.6er
>>>>>> Version kompatibel ist.
>>>>>>
>>>>>> Viele Grüße,
>>>>>> Michael
>>>>>>
>>>>>>
>>>>
Mehr Informationen über die Mailingliste franken-dev