Das CIFS-Protokoll implementiert in der aktuellen Version auch Signierung und Crypto Ende zu Ende.
Unzählige Probleme. Das fängt schon dabei an das wenn du Supernode auf einer VM machst und der ganze Host wird beschlagnahmt (es gibt genug Deppen), haftest du oft für den Ausfall und bist ggf. Regresspflichtig gegenüber den anderen VM-Betreibern. In manchen Verträgen ist das geregelt in anderen nicht. Die interessiert nicht warum, wieso, gerechtfertigt oder nicht. Die Abuse-Problematik bleibt ebenfalls die gleiche (Vertrag gekündigt spätestens nach dem 3. Abuse). Ich könnte jetzt noch unendlich weitere Aspekte aufzählen, warum ich denke das es bei dem bestehenden Konstrukten aus FFRL-Exit und VPN-Anbietern bleibt.
4 „Gefällt mir“
@Arwed das sind rechtliche Aspekte, gehört in extra Thread, hier geht es um Technik, alles andere muss ggf. die Gruppe vor Ort entscheiden. Verquick hier bitte keine Themen die separiert gehören.
Edit
m.E. sollte eine klarte „Diskussionshierarchie“, auch getrennt nach Topics, eingehalten werden:
- was ist technisch machbar
- was davon ist rechtlich zulässig
- was von dem, was übrig ist, ist moralisch vertretbar
- das, was dann noch über ist, kann derjenige, der Lust hat, versuchen.
Aber bitte nicht alles im selben Thead diskutieren.
Das hört sich jetzt aber nicht nach einer technischen Änderung an, oder?
Ich halte das in #7 beschriebene Szenario einer 3fach gestaffelten Ausleitung (nach AS-Listen) nach wie vor für gangbar.
Und den Performance-Lack beim Roamen „von Wolke zu Wolke“ muss man halt in Kauf nehmen. Es wäre ja kein abriss.
2 „Gefällt mir“
Bei Freifunk-Frankfurt hat man ein Script, welches sich die AS von Diensten enthält, für die man das Risiko bezüglich Abuse für (heute schon) erträglich hält.
Und die werden von den Supernodes direkt ausgeleitet.
Ähnliches -mit noch restriktiveren Listen- könnte ich mir optional (! d.h. Freiwillig vom Knotenaufstellenden aktivierbar>) auch für „direkt aus dem lokalen DSL/Docsis/LTE ausleiten“ vorstellen.
Die Gluon-Router müssten sich dann nur zu lokalen Gateways aufschwingen, selbst für ihre Wolke einen DNS laufen lassen um sich als IPv4-Gateway zu propagieren und entsprechend für die Clients „hinter sich“ dann wahlweise
a) an die übergeordneten „bisherigen“ Gateways zu (re)routen
b) bei „Hits“ in der Liste der „ungefährlichen AS“ lokales SNAT auf das br-wan durchzuführen.
Jein. Trennt es gerne ab wenn ihr es unpassend findet. Ich weiß allerdings nicht wie ihr das trennen wollt. Ein Balls-Of-Steel Exit (ggf. mit lokalem Supernode) ist auch heute „technisch machbar“ und trotzdem macht man das nicht. Deswegen denke ich, sollte man das zusammen diskutieren und alles gehört zu „technische Änderungen nein oder ja und falls ja welche“.
Außerdem verbessert ein solcher Exit doch auch „nur“ die Latenz und Ausfallsicherheit (wenn FFRL Backbone down ist), oder?
Soweit ich weiß hat der FFRL Exit noch ziemliche Kapazitäten, und es ist für einen Hoster viel einfacher einfach nur mit dem FFRL-Backbone zu peeren um Traffickosten niedrig zu halten.
1 „Gefällt mir“
@yayachiken : nicht nur - wenn du das quasi auf Knoten überträgst gewinnst du zumindest in dem Fall sehr viel wenn da ein Telekom Peering involviert ist. Bsp.
Knotenbetreiber ist beid er Telekom, Freifunk RootServer steht bei Hetzner.
FreifunkServer zu Rheinland/FreieNetze oder sonstwo klappt super … aber der Knotenbetreiber kommt schon nur eher mies bis mau zu dem Hetznerserver (dank Telekompeering).
Wenn der Knoten nun partiell direkt ausleitet, ist die willkürliche Drosselung, bzw nichtbereitstellung von Bandbreite seitens der Telekom eher weniger ein Problem, da ich davon ausgehe das die Telekom nativ nicht ihre Kunden vergraulen will die youtube und co aufrufen, zudem die mit Akamai ja genau daher auch Verträge schliessen.
hoffe das Beispiel war plausibel.
[hätte starkes interesse im größeren Stil dazu mal Daten zu sammeln um dann ne PR bombe daraus zu machen]
Ich meinte das partielle Ausleiten direkt auf dem Supernode, nicht auf dem Knoten. Hab da wohl was im Post von adorfer falsch verstanden.
Was für einer genau? Auf dem Fastd-Supernode oder auf dem lokalen Endkundenprovider-Uplink?
Hi Zusammen,
ich habe diese Form des Exits jetzt seit ca. einem Jahr bei mir laufen.
Bisher gab es da keine Folgen. Mal sehen. Und es performt.
Grüße
Thomas
1 „Gefällt mir“
Nach welchen Kriterien leitest Du Du lokal aus?
Oder einfach „alles“?
Ich leite alles lokal aus.
Nunja, jedes MBit/sec, welches nicht von $Hoster zum FFRL und zurück transportiert werden muß, macht prinzipiell ersteinmal schon Sinn. YouTube, Amazon Prime oder Netflix direkt via Hetzner statt via FFRL laufen zu lassen, klingt einerseits sicher und andererseits nach Performancegewinn. Sollte es letzteres nicht sein, hat Hetzer eigentlich schon ein Problem 
Prinzipiell skaliert das FFRL-Modell nicht. Wir haben z. Zt. 5 Server in GT mit GBit/sec-Anbindung sowie zwei bei Hetzner. Theoretisch könnten wir mit dem FFRL also 7 Gbit/sec austauschen. IIRC sind die »dicksten Röhren« dort derzeit 10 Gbit/sec-Interfaces, rechnerisch belegen wir also 7/10 eines Standortes.
Gut, über die Exits im DC in GT gehen wir direkt raus, davon bekommt der FFRL gar nichts mit. Aber mit zunehmender Zeit und damit zunehmendem Traffic wird es absehbar enger werden beim FFRL. Kann man alles adressieren, kostet aber.
1 „Gefällt mir“
Allein von den Peerings her macht es schon Sinn imo.
Klar ist, der Traffic muss irgendwie von den Supernodes raus, das ist für den Hoster eine Konstante. Jetzt ist natürlich die Frage, wie er raus geht.
Wenn alles in den FFRL Backbone läuft, dann braucht der Hoster exakt ein Peering, was man vielleicht bei günstiger Topologie auch per Hostconnect abwickeln könnte. Um den Rest kümmert sich der Backbone. Es entstehen also keine zusätzlichen Kosten. Da Freifunk schon jede Mischkalkulation gefährdet, ist es auch in unserem Interesse, die Kosten für Geschäftspartner niedrig zu halten.
Wenn man direkt ausleitet müsste der Hoster mit einer Vielzahl von anderen Netzen peeren, um den selben Spareffekt zu bekommen. Und da sowas wie Youtube, Netflix etc. eher „Endverbraucher“-Traffic ist, den man bei einem Hoster mit „normalen“ Servern in der Größenordnung sicher nicht schaufeln muss, kann es gut sein dass da extra für Freifunk Kapazitäten ausgebaut werden müssen, was wieder Aufwand ist (und vor allem ein konkreten Kostenpunkt, den man klar beziffern kann, im Gegensatz zu den allgemeinen Kosten die bei Entscheidern vielleicht noch irgendwo in der Bilanz versickern).
Das größte Problem ist aber immer noch der Traffic zu den Endknoten bei den DSL-Providern mit denen man nicht peeren kann. Da ändert der Backbone leider auch nichts dran 
2 „Gefällt mir“
Und da wäre es eben eine Option, den Knotenaufstellenden verschiedene „Listen“ von Diensten anzubieten, die direkt beim Plasterouter ausgeleitet werden.
Ich könnte mir z.B. vorstellen, dass Whatsapp relativ unproblematisch sein würde. (bringt zwar sicher nicht viel Volumen, besseres Beispiel fällt mir gerade nicht ein)
Aber Netflixx oder dieses Amazon-TV könnte aber wirklich was reissen.
Und die Art der Netflixx-Nutzung für die das SEK oder der auch nur der Abmahnanwalt aktiv wird, die fällt mir gerade nicht ein.
gibts bei den Gateways Statistiken, wie viel Traffic auf was entfällt?
Dazu müsste man eine Monitoring Schnittstelle in die Bridge hängen.
Hätte ich grundsätzlich Bauchschmerzen mit. Ich will gar nicht wissen welcher Traffic zum Exit geleitet wird.
Der lokale Exit am Node ist langfristig gesehen das erstrebenswerteste.
2 „Gefällt mir“
Ist das den so? Ich habe jetzt gerade keine Zahlen im Kopf aber der Traffic den Google (inkl. Youtube), Netflix, Amazon und ein paar andere CDNs fahren dürfte wohl den Großteil an Traffic ausmachen. Alle genannten sind an den großen Internet Exchanges vertreten, haben meist eine sehr offene Peering Policy und es würde mich wundern wenn z.B. Hetzner nicht ohnehin schon mit den meisten davon (public oder privat) Peeren würde.
Den eine gute Verbindung z.B. Google ist ja durchaus auch für Kunden relevant (fließt oder floss ja mal eine Zeit ins Ranking ein) und die bieten ja neben ihren „Consumer“ Sachen auch durchaus andere wichtige Dienste an zu denen man eine gute und stabile Verbindung haben möchte (DNS Server, Cloud Engine, Mailserver). Selbiges gilt auch für Amazon (und Netflix streamt ja alles was nicht aus den lokalen ISP Caches kommt meines Wissens nach immer noch aus AWS), bei der Vielzahl der in AWS gehosten Sachen kann sich doch kein großer Provider mehr erlauben eine schlechte Connectivity zu denen zu haben.
Und ob man jetzt an Port A oder B am ECIX den Traffic ausleitet dürfte den Provider in vielen Fällen egal sein.
will ich auch nicht wissen, ich denke nur an „wieviel wohin in Zeitraum X“, und zwar egal, wer einleitet, von wo das kommt etc.
damit man sieht ob die Diskussion hier obsolet ist (weil keiner so was macht) oder bei besonderen Zielen (halt eben z.B. Amazon TV) ganz besonders sinnvoll wäre.