olsrd_dyn_gw.so.0.5 funktioniert glaub ich nicht wirklich
Tim Niemeyer
tim.niemeyer at mastersword.de
Sa Okt 10 10:36:01 CEST 2015
Hi
Am Samstag, den 10.10.2015, 10:30 +0200 schrieb Tom Green:
> Heute morgen ist der Tunnel ausgefallen (8:45 http://10.50.72.7/mrtg/).
>
> Also das Device und die Route war noch da, aber ging nix mehr durch.
>
> Die gute Nachricht:
> -> Das Default-GW verschwand aus dem HNA4
> -> Eine zusätzliche Default Route wurde entweder über ro1, cdfue1 oder
> nue1 aufgebaut
>
> Die schlechte Nachricht:
> -> Es ging trotzdem nichts durch. Vermutlich hat er weiterhin versucht
> über den Tunnel zu gehen
Ich denke mal das Up-Script vom OpenVPN trägt statisch eine Route in die
fff Tabelle ein. Daran wird das wohl liegen. Michael hat das Szenario ja
schon beschrieben und wollte ein Script dafür/dagegen schreiben.
Tim
> VG
> Tom
>
> On 10.10.2015 09:40, Michael Fritscher wrote:
> > Guten Morgen,
> >
> > das Umschalten zwischen lokalem Gateway über OpenVPN und Gateway über
> > olsrd funktioniert tatsächlich ebenfalls mit der 0.6.8.1. Das
> > Zurückumschalten auf OpenVPN benötigt nur irgendwas um die 1-2 Minuten,
> > was aber nicht schlimm ist. Nachdem bei dieser Version auch sonst alles zu
> > funktionieren scheint ist es wohl am besten diese Version zu verwenden.
> >
> > Zwei Probleme verbleiben aber:
> > * Lokale VPNs sollten vor dem Start von olsrd gestartet werden. Sonst
> > jagt olsrd für paar Sekunden alles über andere Freifunk-GWs, nur um
> > danach aufs lokale Gateway über OpenVPN umzuschalten. Das bekommt den
> > Verbindungen dann nicht besonders gut.
> > * Die OpenVPN-Route wird nicht gelöscht, wenn OpenVPN zwar läuft, aber
> > keine Daten mehr übertragen werden. Olsrd kann dies nicht übernehmen, da
> > es von dieser Route ja nichts weiß. Da werde ich im Laufe des Tages ein
> > kleines Script für basteln.
> >
> > Viele Grüße,
> > Michael
> >
> >
> >> Hi,
> >>
> >> ich habe testweise mal 0.6.8.1 gebaut und unter
> >> http://mifritscher.de/austausch/olsrd hochgeladen. Das Umschalten scheint
> >> zumindest insofern zu funktionieren, als dass beim killen vom VPN-Tunnel
> >> ein anderes Standard-Gateway verwendet wird. Wenn ich openvpn wieder
> >> starte merkt olsrd davon aber anscheinend nichts, sodass ich 2
> >> defaultrouten habe (eine Richtung VPN, eine Richtung anderen freifunk-GW).
> >> Die Statistik tut in dieser Version.
> >>
> >> Viele Grüße,
> >> Michael
> >>
> >>
> >>
> >>> 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 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/0f0eedc9/attachment-0002.sig>
Mehr Informationen über die Mailingliste franken-dev