olsrd_dyn_gw.so.0.5 funktioniert glaub ich nicht wirklich
Christian Dresel
fff at chrisi01.de
Fr Okt 9 16:11:22 CEST 2015
Danke für den Test, sehr aufschlussreich und viele Probleme die es noch
zu lösen gilt.
1. Sache für mich wäre mal ganz wichtig, das die ganzen Gateways in
unseren Netz die aktuell nur sehr knapp ans Internet angebunden sind
(Mullvad, aber evtl. auch nue1?), mal den 0.0.0.0/0 announce rauswerfen
(aka. olsrd_dyn_gw.so.0.5 komplett raus nehmen) bringt ja nix wenn die
Leitung eh schon vollgestopft ist und dann noch announcen "Hey hier
könnt ihr Traffic ins Netz werfen"... wiederspricht sich irgendwie.
Ich hab die Nacht an einem Raspberry Pi 2 das ich mit 100Mbit unmetered
Flat (laut Provider auch auf Nachfrage!) in nen RZ stehen habe
rumgespielt und es hängt mittlerweile in unseren OLSR Netz (nach einigen
Kämpfen, so ein Pi ist halt kein Debian und da muss man einiges
improvisieren/umbauen/aktivieren usw.). Leider muss ich auch bei dem
Teil den Traffic über Mullvad rauswerfen (werde aber evtl. nochmal mit
dem Provider reden was da machbar ist, sprich RIPE Eintrag &co, hoffe da
ein wenig auf Hilfe von Leuten die sich damit auskennen, wenn jemand
helfen will bitte Mail an mich oder Liste) was aber kein Problem ist da
ich 3 Verbindungen von Mullvad bekomme (eine brauch ich noch priv., eine
nutzt mein Hetznergateway und die dritte nutzt nun das Pi). Das Pi
bekommt kein fastd/Batman sondern ist für mich zum testen als
"Trafficabwerfkiste" (aka Internetgateway) aufgebaut. Sowas soll später
ja auch mal ro1 werden (da kann man den 0.0.0.0/0 announce in meinen
Augen auf jeden Fall drinnen lassen, bei nue1 kann ich es nicht
beurteilen) und ich sehe auch den dotmanaged und wavecon Server als
Internetgatway, wobei die 2 nicht meine Entscheidung sind ich vote aber
eindeutig dafür, Supernodes haben wir genug (und sind auch rel. leicht
zu bekommen) aber wir brauchen was wo wir den Internettraffic los werden
und wenn das mit dotmanaged und wavecon "einfach" ist den Traffic ins
Netz zu schicken sollte das in meinen Augen auch deren Hauptaufgabe
sein/werden.
Der Mullvad vom Pi ist also komplett frei (nutzt ja aktuell niemand) und
wenn andere aufhören 0.0.0.0/0 zu announcen kommen irgendwann Supernodes
(ich hab hier 2 Leute im Kopf die zwar nen Hetznerserver haben aber kein
Mullvad und daher noch überlegen wie sie den Traffic los werden genau
das sind in meinen Augen Supernodes, Gruß an Tobias ;)) an meinem Pi
raus die diesen (aktuell komplett freien) Tunnel nutzen könnten. So mal
meine Idee für die Zukunft. Klar bekomm ich durch den Mullvad nicht die
Masse an Traffic raus (außer es findet sich eine Lösung das Problem zu
"umgehen" aka RIPe&co dann ist aber immer noch das Pi2 der begrenzende
Faktor bin mir nicht sicher ob die Kiste die 100Mbit voll packt) aber
als "Backuplösung" oder für erste Versuche (was wir ja aktuell machen)
bestimmt ganz nett.
Würde mich interessieren wie es andere sehen, vielen Dank.
mfg
Christian Dresel
Am 09.10.2015 um 15:17 schrieb Tom Green:
> 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
>>>
>>>
>
>
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20151009/b1a9e8b6/attachment-0002.html>
Mehr Informationen über die Mailingliste franken-dev