<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Danke für den Test, sehr
aufschlussreich und viele Probleme die es noch zu lösen gilt.<br>
<br>
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. <br>
<br>
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.<br>
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. <br>
<br>
Würde mich interessieren wie es andere sehen, vielen Dank.<br>
<br>
mfg<br>
<br>
Christian Dresel <br>
<br>
Am 09.10.2015 um 15:17 schrieb Tom Green:<br>
</div>
<blockquote cite="mid:5617BE56.6070703@gmx.de" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
Hallo,<br>
<br>
Also hab mal von ca. 14:15 bis 15:05 Uhr den openvpn tunnel ins
Internet für kleev2 gekillt.<br>
<br>
Im Ergebnis:<br>
<ul>
<li>Leitet den Traffic von kleev2 über nue1 nach Berlin</li>
<li>rödelt bei 100% Prozessorlast (!)<br>
</li>
<li>Wechselt kurzzeitig von nue1 auf cdfue1 -> Eingehender
Traffic von cdfue1 ?<br>
</li>
<li>Durchsatz nach nue1 deutlich unter Normal verglichen zu dem,
was sonst durch den Tunnel geht. 220MB vs. 1..2 GB</li>
<li>Stellt nach Wiederbeleben des openVPN-Tunnels die reguläre
Verbindung wieder her.<br>
</li>
</ul>
Plots / Statistiken:<br>
Übersicht: <a moz-do-not-send="true"
class="moz-txt-link-freetext" href="http://10.50.32.7/mrtg/">http://10.50.32.7/mrtg/</a><br>
Traffic Tunnel:
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://10.50.32.7/vnstat/index.php?if=tun0&graph=large&style=light&page=h">http://10.50.32.7/vnstat/index.php?if=tun0&graph=large&style=light&page=h</a><br>
Traffic Nue1:
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://10.50.32.7/vnstat/index.php?if=nue1&graph=large&style=light&page=h">http://10.50.32.7/vnstat/index.php?if=nue1&graph=large&style=light&page=h</a><br>
Traffic cdfue1:
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://10.50.32.7/vnstat/index.php?if=cdfue1&graph=large&style=light&page=h">http://10.50.32.7/vnstat/index.php?if=cdfue1&graph=large&style=light&page=h</a><br>
<br>
Wen es interessiert.<br>
<br>
OLSR: olsr.org -
0.9.0.3-git_0000000-hash_309bb6eddd252f7728c49630bf2a9650 (built
on 2015-10-09 07:01:46 on KleeV2) <br>
<br>
Gruß<br>
Torben <br>
<br>
<div class="moz-cite-prefix">On 09.10.2015 12:24, Tom Green wrote:<br>
</div>
<blockquote cite="mid:561795D8.8080000@gmx.de" type="cite">
<pre wrap="">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@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:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
</pre>
<blockquote type="cite">
<pre wrap="">"Eigentlich" "müsste" wahrscheinlich "nur mal" "jemand" "schnell" das
obere repository bauen.
</pre>
</blockquote>
<pre wrap="">Erledigt :-) Eine 0.9.0.3 gibts unter
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://mifritscher.de/austausch/olsrd/">https://mifritscher.de/austausch/olsrd/</a> . 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
</pre>
</blockquote>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
</body>
</html>