Datenreduzierung am Aux-Exit

Sa Jan 2 16:10:12 CET 2016

Hi,

wir können _versuchsweise_ kleev2 mit in die Aux als GW in die Aux
nehmen. Selbstabwurf über Mullvad.
@Christian, Tim: Seit ihr so nett?

Mal schauen was der abfischt, freie Kapazitäten wären da.

Im 2ten Schritt dann entweder
* wieder aus der Aux raus (weil er zuwenig mithilft)
* kleev2 aus Wü oder Fü raus
* kleev2 bleibt in allen 3 Hoods

Ich denke das ist auch ein Problem, dass:
* Flüchtlinge den ganzen Tag nichts anderes zu tun haben
* Das GW einfach schnell ist

Man könnte jetzt auch Drosselkom spielen .... sprich ein QoS entweder
global für fra1 auf 1 TByte pro Tag oder pro VPN-Verbindung (falls
möglich). Auch keine populäre Maßnahme.

Gruß
Torben

On 02.01.2016 13:46, f.schimmer at posteo.de wrote:
> > Ich persönlich glaube nicht, dass wir das Problem mittelfristig mit
Umleiten oder Sperren von bestimmten Traffic oder Hinweisen lösen
können. Wir sollten schon reduzieren, wo es nur geht. Aber wenn ich mich
vor Ort umschaue, ist das gefühlt ganz normaler Traffic auf youtube etc.
Gegen p2p sprechen eigentlich auch die nächtlichen "Einbrüche". Um so
mehr Personen wach sind, um so mehr wird übertragen. Mal raus-messen
wäre trotzdem nicht schlecht. Sollte mit wireshark o.ä. ja recht schnell
auf dem Gw gemacht sein.
dito.
> > Meiner Meinung nach haben wir aber ein anderes Problem: >  Wir
schauen zwar vor Ort, wer die Router bezahlt, wer die Leitung stellt
aber achten nicht auf die Betriebskosten im ff-netz. Außerdem ist das
Erweitern der Kapazität mit Handarbeit verbunden und meist noch eine
Individual-Installation. Beides führt dazu, dass wir in der aux genau
von einem GW versorgt werden und wenn das down, oder der Traffic
verbraucht ist, hunderte (wahrscheinlich langsam über 1000) Leute kein
Internet mehr haben. Die Aux ist momentan n+1 sicher über bbg und fra1.
Ansonsten Zustimmung bei den Betriebskosten.

> Was wir meiner Meinung nach bräuchten, wär ein Projekt pro Installation, bei dem auch sicher gestellt wird, dass die Kapazitäten zur Verfügung stehen und diese auch über einen bestimmten Zeitraum finanziert werden. Das würde dann aber auch bedeuten, dass sich nicht jeder einfach ne aux - fw installieren kann, ohne diese zu registrieren.

> Ich weiß, dass geht recht weit vom uneingeschränkt offenen Netz weg, von selbst-organisation etc., und wird hier nicht bei allen auf Begeisterung stoßen, ich sehe aber sonst keine wirkliche alternative. > > Offenes Feedback willkommen :) > > Liebe Grüße, > Flo > > > Am
02.01.2016 11:03 schrieb delphiN:
> Schönes neues Jahr euch Allen!
>
> Wir haben an unserem, momentan einzigen Aux-Exit mitlerweile ein nicht
> unwesentliches Traffik-Aufkommen. Im Dezember haben wir das vom
> Provider genannte "Soft-Limit" von 20 TB/Monat bereits erreicht und
> werden es im Januar voraussichtlich deutlich überschreiten. Wenn 1000
> neue Flüchtlinge in Fürth dazukommen wirds spannend.
>
> Ich habe den Provider kontaktiert und gefragt ob er mit dem wachsenden
> Datenaufkommen klar kommt und ob das klar geht. Ich geh davon aus, das
> wir hier noch etwas Luft haben.
>
> Trotzdem sollten wir uns mal über Möglichkeiten unterhalten das
> Datenaufkommen an dem Exit zu reduzieren. Ich sehe hier folgende
> Möglichkeiten zur Diskussion:
>
> 1. P2P-Traffic verhindern
> Es gibt das so genannte Zapp-Skript, das in der Lage ist typischen
> P2P-Traffik zu erkennen und den entsprechenden Client für eine gewisse
> zeit zu sperren. Ich bin ein erklärter Gegner von Torrent-Sperren da
> damit auch legale Torrents (z.B. 32C3 Vorträge) gesperrt werden.
> Trozdem finde ich man könnte sowas in diesem speziellen Fall von
> Flüchtlingshilfe zumindest mal diskutieren. Die Abuse-Meldungen würden
> wir zwar trotzdem noch bekommen aber der Traffik wäre weg.
>
> 2. P2P-Traffik umleiten
> Wir könnten bereits an den Layer-2 Gateways ein policy-based-routing
> installieren und zum Beispiel nur noch Daten von bekannten Ports (80,
> 443, 110, 143, 25 usw.)  über den dotManaged Gateway schicken. Alles
> Andere könnten wir dann über einen normalen Schweden-VPN abwerfen.
> Damit würde zwar Torrent und alle anderen seltsamen/unbekannten
> Protokolle sehr langsam werden aber wir würden den Exit entlasten und
> wären zusätzlich die Abuse-Meldungen los. Die fränkischen Gluon
> Kollegen haben so ein Policy based Routing schon lange und damit wohl
> auch sehr gute Erfahrungen gemacht.
>
> 3. Traffik-Control auf Client Ebene
> Es wäre wahrscheinlich auch möglich eine Beschränkung der Datenrate
> für die einzelnen Clients zu bauen. Wenn jeder Client nur noch eine
> reduziere Datenrate zu Verfügung hat würde das das Gesamtaufkommen
> wohl erstmal verringern. Das wäre technisch aber wohl ziemlich
> kompliziert und ich finde wir sollten Nutzen was wir haben. Die
> DSL-Anschlüsse sind doch sowieso schon Beschränkung genug.
>
> 4. Reverse cacheing
> Da haben wir ja schon diskutiert. Es ist durchaus üblich Web-Traffic
> in großem Stil (bei Beachtung von Regeln) zu cachen. Wir könnten uns
> damit wahrscheinlich etwas an Port-80- und evtl. Port-23-Traffik
> sparen. Da mittlerweile alle großen Anbieter aber SSL verwenden finde
> ich das können wir uns sparen!
>
> 5. Neue Exit-Server
> Wie schauts bei wavecon aus?
> 1und1 scheint tatsächlich unbeschränkten Traffik anzubieten und auch
> Dinge wir Tor-Relays und sogar Exit-Nodes durchaus zuzulassen
> (Zumindest bis es zu rechtlichen Problemen kommt). Bei denen scheint
> der Engpass der Speicher und die CPU zu sein. Wenn man da im Rahmen
> bleibt lassen die einem wohl auch großen Traffic durchgehen. Wir
> könnten so einen Server evtl. auf den Namen des Fördervereins laufen
> lassen und z.B. die Kosten selbst übernehmen. Hat das fra1 Team
> nochmal Lust so ein Ding aufzusetzen? Die Kosten könnten wir uns ja
> z.B. teilen oder aus dem Caritas-Topf bezahlen. Auch haben wir noch
> viele viele Spenden.
>
> Wie seht Ihr das?
>
> Gruß,
> delphiN
>

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20160102/cf1cd6cc/attachment-0002.html>