Namd,
srv10 und srv11 laufen nun als vpn06 und vpn05. Über den AirVPN von vpn06 lassen sich 200Mbit schaufeln. Auf srv10 habe ich nun einen Hurricane-Electric-Tunnel[0] eingeschaltet, der statt des FFRL-Tunnels announced wird - über den Tunnel läufts direkt auf dem Gateway mit 400Mbit.
Nun denkt man sich: Ok, das Netz sollte nun schneller laufen. Aber nope, mein Router an vpn02/srv12 (mit IP von vpn06/srv10, warum auch immer) eiert mit 100-200kb/s von mirror.gnomus.de (beliebter Arch -Mirror) rum.
Grmpf.
bjo
[0]http://bgp.he.net/ip/2001:470:1f0b:59::#_whois
Jap, Uni server schafft leider an den routern auch fast nix. Kannst du da aich nochmal schauen?
Am 16. Juli 2015 22:20:35 MESZ, schrieb Bjoern Franke bjo@nord-west.org:
Namd,
srv10 und srv11 laufen nun als vpn06 und vpn05. Über den AirVPN von vpn06 lassen sich 200Mbit schaufeln. Auf srv10 habe ich nun einen Hurricane-Electric-Tunnel[0] eingeschaltet, der statt des FFRL-Tunnels announced wird - über den Tunnel läufts direkt auf dem Gateway mit 400Mbit.
Nun denkt man sich: Ok, das Netz sollte nun schneller laufen. Aber nope, mein Router an vpn02/srv12 (mit IP von vpn06/srv10, warum auch immer) eiert mit 100-200kb/s von mirror.gnomus.de (beliebter Arch -Mirror) rum.
Grmpf.
bjo
[0]http://bgp.he.net/ip/2001:470:1f0b:59::#_whois
xmpp bjo@schafweide.org
Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
Viele Grüße, Stefan
Hi,
zu Baustellen im VPN-Backbone habe ich mal die vpnkarte im Syncthing aktualisiert und mit kleinen (roten) ToDo's versehen.
Am Donnerstag, 16. Juli 2015, 22:20:35 schrieb Bjoern Franke:
srv10 und srv11 laufen nun als vpn06 und vpn05. Über den AirVPN von vpn06 lassen sich 200Mbit schaufeln. Auf srv10 habe ich nun einen Hurricane-Electric-Tunnel[0] eingeschaltet, der statt des FFRL-Tunnels announced wird - über den Tunnel läufts direkt auf dem Gateway mit 400Mbit.
Nun denkt man sich: Ok, das Netz sollte nun schneller laufen. Aber nope, mein Router an vpn02/srv12 (mit IP von vpn06/srv10, warum auch immer) eiert mit 100-200kb/s von mirror.gnomus.de (beliebter Arch -Mirror) rum.
Bei mir ähnlich und zwar bei der Datenübertragung von srv12 zu einer direkt mit srv12 verbundenen Node. Folgendes habe ich gemacht:
*Node zu srv12 verbinden *mit "batctl tr" prüfen ob eine direkte Verbindung besteht und die Daten nicht irgendeinen lustigen Umweg durchs Netz nehmen *Daten von srv12 zur Node übertragen mit "wget -O /dev/null http://10.18.8.1/speedtest"
Sehr konstant 3-4Mbit/s. 100Mbit/s wären mit meiner Leitung theoretisch Möglich, faktisch schafft mein Router aber nur ca. 10Mbit/s (Erfahrungswert). Bei einer Übertragung außerhalb von Freifunk komme ich auf ca. 25Mbit/s (mein WLAN ist nicht schneller). Insgesamt müsste eigentlich das doppelte oder dreifache übertragen werden.
Für mich sieht es danach aus, als seien langsame Exits gar nicht das Problem sondern eine der beiden Seiten (oder beide) haben ein Problem mit dem Fastd- VPN. Hier müsste jemand testen ob die Probleme auch mit einem Offloader in der Form auftreten.
Mal rein spekulativ überlegt ohne dass ich da übertrieben die Ahnung habe: Wenn wir uns überlegen, was mit einem Datenpaket auf beiden Seiten jeweils gemacht wird, dann würde mich die Datenrate gar nicht unbedingt wundern. Ich kenne da jetzt die Details nicht aber ankommende Daten an einem Router z.B. werden ja erstmal in einem FIFO-Buffer abgelegt. Die Maschine nimmt dann jeweils das vorderste Paket und bearbeitet es. Da Fastd im Userspace läuft sind dafür mindestens 2 Kontextswitche und Rechenzeit zum Entschlüsseln nötig und erst anschließend kommt dann das nächste Paket an die Reihe. Da viele Datenpakete für alles mögliche ankommen, liegt so ein Paket eine ganze weil in einem oder mehreren Puffern und wartet darauf verarbeitet zu werden und im schlimmsten Fall läuft ein Puffer voll und Daten werden verworfen sodass sie neu übertragen werden müssen. Das macht den ganzen Spaß langsam ohne dass die CPU zu 100% ausgelastet ist. Vice Versa natürlich auf einer Supernode.
Auf meiner Node hat fastd eine Grundauslastung von ca. 11%. Das heißt, da kommen die ganze Zeit Pakete für alles mögliche rein. Vielleicht führt das schon dazu, dass Kapazitäten ausgelastet werden und für eine ordentliche Datenübertragung keine Ressourcen zur Verfügung stehen. Muss man wirklich mal testen was ein Offloader zu dem Problem sagt. Der dürfte ja genug Ressourcen haben.
Das war jetzt nur so eine Idee, aber evtl. kennt sich damit ja jemand im Detail aus und kann den Ansatz nachvollziehen?
LG Clemens
Hi,
bei unserem Server der bei der Uni steht the same. Über den Server an die 70mbit, sobald der Router an ist und darüber gezogen wird max 5 mbit.
Irgendwas stimmt hier absolut nicht.
Am 17. Juli 2015 03:08:21 MESZ, schrieb Clemens John clemens.john@floh1111.de:
Hi,
zu Baustellen im VPN-Backbone habe ich mal die vpnkarte im Syncthing aktualisiert und mit kleinen (roten) ToDo's versehen.
Am Donnerstag, 16. Juli 2015, 22:20:35 schrieb Bjoern Franke:
srv10 und srv11 laufen nun als vpn06 und vpn05. Über den AirVPN von vpn06 lassen sich 200Mbit schaufeln. Auf srv10 habe ich nun einen Hurricane-Electric-Tunnel[0] eingeschaltet, der statt des
FFRL-Tunnels
announced wird - über den Tunnel läufts direkt auf dem Gateway mit 400Mbit.
Nun denkt man sich: Ok, das Netz sollte nun schneller laufen. Aber nope, mein Router an vpn02/srv12 (mit IP von vpn06/srv10, warum auch immer) eiert mit 100-200kb/s von mirror.gnomus.de (beliebter Arch -Mirror) rum.
Bei mir ähnlich und zwar bei der Datenübertragung von srv12 zu einer direkt mit srv12 verbundenen Node. Folgendes habe ich gemacht:
*Node zu srv12 verbinden *mit "batctl tr" prüfen ob eine direkte Verbindung besteht und die Daten nicht irgendeinen lustigen Umweg durchs Netz nehmen *Daten von srv12 zur Node übertragen mit "wget -O /dev/null http://10.18.8.1/speedtest"
Sehr konstant 3-4Mbit/s. 100Mbit/s wären mit meiner Leitung theoretisch
Möglich, faktisch schafft mein Router aber nur ca. 10Mbit/s (Erfahrungswert). Bei einer Übertragung außerhalb von Freifunk komme ich auf ca. 25Mbit/s (mein WLAN ist nicht schneller). Insgesamt müsste eigentlich das doppelte oder dreifache übertragen werden.
Für mich sieht es danach aus, als seien langsame Exits gar nicht das Problem sondern eine der beiden Seiten (oder beide) haben ein Problem mit dem Fastd- VPN. Hier müsste jemand testen ob die Probleme auch mit einem Offloader in der Form auftreten.
Mal rein spekulativ überlegt ohne dass ich da übertrieben die Ahnung habe: Wenn wir uns überlegen, was mit einem Datenpaket auf beiden Seiten jeweils gemacht wird, dann würde mich die Datenrate gar nicht unbedingt wundern. Ich kenne da jetzt die Details nicht aber ankommende Daten an einem Router z.B. werden ja erstmal in einem FIFO-Buffer abgelegt. Die Maschine nimmt dann jeweils das vorderste Paket und bearbeitet es. Da Fastd im Userspace läuft sind dafür mindestens 2 Kontextswitche und Rechenzeit zum Entschlüsseln nötig und erst anschließend kommt dann das nächste Paket an die Reihe. Da viele Datenpakete für alles mögliche ankommen, liegt so ein Paket eine ganze weil in einem oder mehreren Puffern und wartet darauf verarbeitet zu werden und im schlimmsten Fall läuft ein Puffer voll und Daten werden verworfen sodass sie neu übertragen werden müssen. Das macht den ganzen Spaß langsam ohne dass die CPU zu 100% ausgelastet ist. Vice Versa natürlich auf einer Supernode.
Auf meiner Node hat fastd eine Grundauslastung von ca. 11%. Das heißt, da kommen die ganze Zeit Pakete für alles mögliche rein. Vielleicht führt das schon dazu, dass Kapazitäten ausgelastet werden und für eine ordentliche Datenübertragung keine Ressourcen zur Verfügung stehen. Muss man wirklich mal testen was ein Offloader zu dem Problem sagt. Der dürfte ja genug Ressourcen haben.
Das war jetzt nur so eine Idee, aber evtl. kennt sich damit ja jemand im Detail aus und kann den Ansatz nachvollziehen?
LG Clemens
Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
Viele Grüße, Stefan
Hi,
ich weis nicht warum, aber irgendwie hat die ML meine Mails geschluckt.
Das ganze muss ja einen Fehler in unserem Transit Netz bedeuten. Die Exits sind da, aber es geht halt nix raus.
Beispiel. Bei unserem Uni-Server habe ich ca 70mbit/s über 10 - hängen die Router daran und wir machen eine Speedtest, max. 3 mbit/s down. Da muss irgendwo ein Problem mit Paketen oder ähnlichem sein.
Wir verwenden ja auf den Routern und Gw´s unterschiedliche Batman Versionen. Kann es damit zusammenhängen?
Vg,
Stefan
Am 17.07.2015 um 03:08 schrieb Clemens John:
Hi,
zu Baustellen im VPN-Backbone habe ich mal die vpnkarte im Syncthing aktualisiert und mit kleinen (roten) ToDo's versehen.
Am Donnerstag, 16. Juli 2015, 22:20:35 schrieb Bjoern Franke:
srv10 und srv11 laufen nun als vpn06 und vpn05. Über den AirVPN von vpn06 lassen sich 200Mbit schaufeln. Auf srv10 habe ich nun einen Hurricane-Electric-Tunnel[0] eingeschaltet, der statt des FFRL-Tunnels announced wird - über den Tunnel läufts direkt auf dem Gateway mit 400Mbit.
Nun denkt man sich: Ok, das Netz sollte nun schneller laufen. Aber nope, mein Router an vpn02/srv12 (mit IP von vpn06/srv10, warum auch immer) eiert mit 100-200kb/s von mirror.gnomus.de (beliebter Arch -Mirror) rum.
Bei mir ähnlich und zwar bei der Datenübertragung von srv12 zu einer direkt mit srv12 verbundenen Node. Folgendes habe ich gemacht:
*Node zu srv12 verbinden *mit "batctl tr" prüfen ob eine direkte Verbindung besteht und die Daten nicht irgendeinen lustigen Umweg durchs Netz nehmen *Daten von srv12 zur Node übertragen mit "wget -O /dev/null http://10.18.8.1/speedtest"
Sehr konstant 3-4Mbit/s. 100Mbit/s wären mit meiner Leitung theoretisch Möglich, faktisch schafft mein Router aber nur ca. 10Mbit/s (Erfahrungswert). Bei einer Übertragung außerhalb von Freifunk komme ich auf ca. 25Mbit/s (mein WLAN ist nicht schneller). Insgesamt müsste eigentlich das doppelte oder dreifache übertragen werden.
Für mich sieht es danach aus, als seien langsame Exits gar nicht das Problem sondern eine der beiden Seiten (oder beide) haben ein Problem mit dem Fastd- VPN. Hier müsste jemand testen ob die Probleme auch mit einem Offloader in der Form auftreten.
Mal rein spekulativ überlegt ohne dass ich da übertrieben die Ahnung habe: Wenn wir uns überlegen, was mit einem Datenpaket auf beiden Seiten jeweils gemacht wird, dann würde mich die Datenrate gar nicht unbedingt wundern. Ich kenne da jetzt die Details nicht aber ankommende Daten an einem Router z.B. werden ja erstmal in einem FIFO-Buffer abgelegt. Die Maschine nimmt dann jeweils das vorderste Paket und bearbeitet es. Da Fastd im Userspace läuft sind dafür mindestens 2 Kontextswitche und Rechenzeit zum Entschlüsseln nötig und erst anschließend kommt dann das nächste Paket an die Reihe. Da viele Datenpakete für alles mögliche ankommen, liegt so ein Paket eine ganze weil in einem oder mehreren Puffern und wartet darauf verarbeitet zu werden und im schlimmsten Fall läuft ein Puffer voll und Daten werden verworfen sodass sie neu übertragen werden müssen. Das macht den ganzen Spaß langsam ohne dass die CPU zu 100% ausgelastet ist. Vice Versa natürlich auf einer Supernode.
Auf meiner Node hat fastd eine Grundauslastung von ca. 11%. Das heißt, da kommen die ganze Zeit Pakete für alles mögliche rein. Vielleicht führt das schon dazu, dass Kapazitäten ausgelastet werden und für eine ordentliche Datenübertragung keine Ressourcen zur Verfügung stehen. Muss man wirklich mal testen was ein Offloader zu dem Problem sagt. Der dürfte ja genug Ressourcen haben.
Das war jetzt nur so eine Idee, aber evtl. kennt sich damit ja jemand im Detail aus und kann den Ansatz nachvollziehen?
LG Clemens
Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
Am Freitag, den 17.07.2015, 07:03 +0200 schrieb Stefan || Freifunk Osnabrück:
Hi,
ich weis nicht warum, aber irgendwie hat die ML meine Mails geschluckt.
Das ganze muss ja einen Fehler in unserem Transit Netz bedeuten. Die Exits sind da, aber es geht halt nix raus.
Beispiel. Bei unserem Uni-Server habe ich ca 70mbit/s über 10 - hängen die Router daran und wir machen eine Speedtest, max. 3 mbit/s down. Da muss irgendwo ein Problem mit Paketen oder ähnlichem sein.
Wir verwenden ja auf den Routern und Gw´s unterschiedliche Batman Versionen. Kann es damit zusammenhängen?
Das betrifft ja garnicht wirklich das Transit-Netz. Auf der Unikiste waren einfach eth1 und batfast in bat0 drin, das ganze als br-mesh und der Traffic wurde auf 10 direkt über AirVPN abgeladen.
Hey,
zu Baustellen im VPN-Backbone habe ich mal die vpnkarte im Syncthing aktualisiert und mit kleinen (roten) ToDo's versehen.
Danke.
Bei mir ähnlich und zwar bei der Datenübertragung von srv12 zu einer direkt mit srv12 verbundenen Node. Folgendes habe ich gemacht:
*Node zu srv12 verbinden *mit "batctl tr" prüfen ob eine direkte Verbindung besteht und die Daten nicht irgendeinen lustigen Umweg durchs Netz nehmen *Daten von srv12 zur Node übertragen mit "wget -O /dev/null http://10.18.8.1/speedtest"
Sehr konstant 3-4Mbit/s. 100Mbit/s wären mit meiner Leitung theoretisch Möglich, faktisch schafft mein Router aber nur ca. 10Mbit/s (Erfahrungswert). Bei einer Übertragung außerhalb von Freifunk komme ich auf ca. 25Mbit/s (mein WLAN ist nicht schneller). Insgesamt müsste eigentlich das doppelte oder dreifache übertragen werden.
Für mich sieht es danach aus, als seien langsame Exits gar nicht das Problem sondern eine der beiden Seiten (oder beide) haben ein Problem mit dem Fastd- VPN. Hier müsste jemand testen ob die Probleme auch mit einem Offloader in der Form auftreten.
Die Exits sind zum Teil auch ein Problem. Auf srv06 mal ausführen: wget --bind-address=10.18.24.1 -O /dev/null http://mirror.de.leaseweb.net/speedtest/100mb.bin
Dann läuft der Traffic über den Tunnel, und liegt gerade zwischen 10 und 20 Mbit, abends dann weniger. Darüber ging jeglicher IPv6-Traffic. Facebook und Google inkl. Youtube nutzen Ipv6, das ist dann entsprechend lahm.
Mit den Routern in Osna am Offloader gibt's aber auch ein Problem. Da kommt auch max. 10 Mbit durch, obwohl auf dem Offloader selbst (131.173.252.88) über fastd zu srv10 und AirVPN 50Mbit durchgehen - selbst zu testen mit wget --bind-address=10.18.80.1 http://mirror.de.leaseweb.net/speedtest/100mb.bin -O /dev/null bzw. ohne --bind-address, um die Ipv6-Konnektivität vom Mesh zu nutzen.
Die Load auf nem CPE ist aber auch nicht gravierend hoch, wenn man nun darüber was zieht (time wget -O /dev/null http://mirror.de.leaseweb.net/speedtest/10mb.bin z.B).
Ratlose Grüße bjo
-
Bjoern Franke -
Clemens John -
Stefan -
Stefan || Freifunk Osnabrück