Datenreduzierung am Aux-Exit

[Christian Dresel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Alex

Am 02.01.2016 um 11:03 schrieb delphiN:
> Schönes neues Jahr euch Allen!

danke das wünsche ich dir und alle anderen die das lesen ebenfalls :)

> 
> 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.

die letzten 3 Tage über 1TB pro Tag, hochgerechnet landen wir da also
bei über 30TB im Januar wenn das so bleiben sollte. Höffner&co noch
gar nicht mit eingerechnet :/ aber vielleicht sollte man so große
Anlagen doch probieren den Internettraffic nach Möglichkeit direkt los
zu werden und nur per Layer3 ans Freifunknetz anbinden? Würde die
Infrastruktur entlasten, also praktisch "ein vor Ort Gateway" oder wie
man auch immer es nennen möchte.

> 
> 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.

verschafft uns etwas Zeit, dennoch sollten wir möglichst bald was
unternehmen, wenn da so weiter steigt sind die 50TB wohl nicht mehr so
weit entfernt :/

> 
> 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.

Pico Peering Agreement 1. Freier Transit? Nein bin ich ehrlich gesagt
dagegen.

> 
> 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.

wo willst du umleiten? Auf fra1? Dann schluckt er den Traffic dennoch,
das müsste wenn dann schon am Router geschehen. Denkbar ja aber dann
stopfen wir uns unsere normalen Freifunk zu wollen wir das? Eine
Lösung ist das nur bedingt.
Wurde der Traffic denn jemals in die Richtung analysiert ob überhaupt
torrent das Problem ist und nicht YouTube & andere Video(streams)? Ich
würde das mal noch nicht auf torrent schieben.

> 
> 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.

seh ich ähnlich wie du

> 
> 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!

ebenfalls gleiche Meinung.

> 
> 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.

bereit wäre ich durchaus, kein Thema. Ich glaub CPU Last ist gar nicht
mehr wirklich das Problem (Boradcastfilter & kleine Hood sei dank),
selbst fra1 langweilt sich ja fast. Traffic ist da mehr das Problem.

mfg

Christian

> 
> Wie seht Ihr das?
> 
> Gruß, delphiN
> 
> 

- -- 
Kontaktmöglichkeiten ChristianD (Christian Dresel):
Jabber: christian at jabber.community
E-Mail: fff at chrisi01.de
Facebook: https://www.facebook.com/christian.chili
Handy/Whatsapp & Festnetz: auf Nachfrage
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWh6lPAAoJEOID5jPgWNLiKfIQAJj6tw2pq2ttahAgP8hvDJaT
CsLI00rmvMs1JUODMZZCTHMWIZUSm5NVjh+FJnlhutFq5Cm2/XL0G00ZQHLdkZAo
PCQmGh6T3db2bOLQdbYq6JMHgdVmMNQNV0jUbGggnXvlMfUjlYRRkSs2LgDlDVX4
5DSk3ogFrJ6m3Io6mpOk4H9BMQyj/0vnjSkgVPM4Kum3JF5g6TqjypX55ebTd6rm
5YRPsR5xbC2bgH57X8YRbQvWqT1q786VatJZQLptplE/VWoNx4xGnKMSjSEfrsOq
DuEDxKB3BvanwpV9eCSWOoCRxWYxQF09lSyWFS0YsCPZAmxWbsx7br9qT5luwAi8
lTKCb47T24zSeIf0BuNuxS64YvQRM50J+MwPrdq30MqTZAdMbIca8FHTodle+KQJ
CjSAwBrJx4Yxo4l+cEwapOPgRq0WQmQq11UFPsEibo3oST+AaUrcLdU8wixaiusM
/hZgjNqX0S4XoV26Pmz6IeyKI78Hljg4aZLEFG8A5uZb0F2X/NAAIcc7wr4FE+iU
wNfUdw1aAwTrKCHxoG9Wu5lCgkS/4CQF5DaZtxf6D6/y1q5VEv48saUwksm6ONRO
k07DAPVCiG9IhqAeyB84/iTaJEs6cl+XhzmqROmG5+M/H3sedqSoAMMH8TyLndOy
A1vUh7rYJFPyaU7zQ25T
=AvJ3
-----END PGP SIGNATURE-----