gateway auf raspi2 (Was: olsrd_dyn_gw.so.0.5 funktioniert glaub ich nicht wirklich)
Tim Niemeyer
tim.niemeyer at mastersword.de
Sa Okt 10 11:12:19 CEST 2015
Hi Christian
Am Freitag, den 09.10.2015, 16:11 +0200 schrieb Christian Dresel:
> 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
Frag halt mal an. Wenn der Provider mit macht, finden wir da sicherlich
eine Lösung. Wir müssten dann nochmal beim Förderverein anfragen, oder
halt warten bis wir einen eigenen Verein/Etc haben.
> 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.
Ich hatte bisher nicht so verstanden, dass wir genug von den dir
genannten Supernodes haben. Immerhin wird da auch ne Menge Traffic
drüber rollen. Wir brauchen für die Aux Hood auch jetzt nicht 10
Supernodes, sondern 2-3 Stück, welche dann aber auch die ausreichende
Leistung bringen. Von dem Wavecon Server gehe ich davon aus, dass der
das packt. Wenn wir aber tatsächlich genug Supernodes (Hood-Server)
haben, dann spricht nichts dagegen auf dem Wavecon Server keine Hood zu
hosten.
Je nach dem wie viel Traffic da so anfällt, und wo der anfällt, erzeugen
wir aber mit der Aufteilung zwischen Hood-Server und Internet-Uplink
mehr Traffic der nicht unbedingt nötig wäre. Die Aufteilung macht
natürlich da Sinn, wo eh eine wäre. In meiner ursprünglichen Überlegen
war das so, weil die Hood-Server ja direkt in den "Aux"-Heimen vor Ort
gestanden hätten. Auch wenn wir für diesen Zweck diese Idee aktuell erst
einmal verworfen haben, wird das so oder so ähnlich bestimmt noch mal
irgendwo aufploppen.
Tim
> 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
> > > >
> > > >
> > > >
> >
> >
> >
> --
> franken-dev mailing list
> franken-dev at freifunk.net
> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname : signature.asc
Dateityp : application/pgp-signature
Dateigröße : 819 bytes
Beschreibung: This is a digitally signed message part
URL : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20151010/54669ecf/attachment-0001.sig>
Mehr Informationen über die Mailingliste franken-dev