Picopeering auf verschiedenen Ebenen

Fortsetzung der Diskussion von Was ist los im RBK@wupper.gl?:

Das Credo der Berliner Freifunkenden lautet ja „Maschenvernetzung“ und „Dezentralität“.
Wenn sich also eine Community hinsetzt, die auf Supernodes schon BGP nutzt zur Backbone-Anbindung: Diesen müsste es zumindest technisch -mit gewissen Einschränkungen- möglich sein, Peerings nicht nur mit dem FF-Rheinland, auch z.B. mit anderen IC-VPN-Freifunk-Communities zu fahren.

(Halte ich noch für vergleichsweise unstrittig, hoffe ich mal).

Was ist, wenn die Community sich dann entscheidet, nach Absprache mit den Peering-Partnern ihr Outbound-Internet als Transit über mehr als einen Peering-Partner zu verklappen?
(zumindest für CGN für V4 gibt es auch kaum Seiteneffekte.)

(Will sagen: Auch das halte ich noch für unproblematisch)

Wenn nun aber Nodes beim MeshVPN gleiches tun, also zu Hosts unterschiedlicher Communities Verbindungen aufbauen und das technisch ohne Schäden hinbekommen -das setze ich mal voraus und möchte es auch gar nicht diskutieren, weil es ein Technik-Thema wäre-:

Was spräche aus Sicht des PPA dagegen? (Ausser vielleicht „Solange der Verein X Resourcen für die Communty bereitstellen, so lange machen Sie das gefälligst nicht“, was ich aber zumindest im Sinne des PPA und MoU nicht als valides Argument akzeptieren würde.)

2 Likes

Es geht in dem verlinkten Fall nicht um peerings, die halte ich grundsätzlich auch für wünschenswert.

Es geht darum, dass ein Nutzer eines Freifunk-Rheinland-e.V.-Routers sich auch darauf verlassen können MUSS, dass sein Traffic den geplanten weg via VPN, Backbone und FFRLeV als Provider ins Internet geht.

Wenn aber ein solcher Router durch den Basteltrieb eines Admins, auf einmal zu einem Supernode eines anderen Vereins mit anderen Gegebenheiten verbunden ist, geht der Traffic einen Weg den der Nutzer nicht kannte und der auch für uns nichtmehr kontrollierbar ist.

Ohne dem VfN irgendetwas unterstellen zu wollen, ich habe überhaupt kein Verständnis dafür, wieso der Traffic eines FFRLeV-Nodes über deren Netze laufen sollte, außer das Ziel liegt in deren Netz - wo wir dann wieder beim Peering wären.

Wie bitte? 202020202020

1 Like

Ich setze mal voraus, dass der Traffic über Nodes geht, die sich ans PPA und auch ans MoU gebunden fühlen.
Was nicht zuletzt daran zu erkennen ist, dass sie allesamt von „freifunk.net“ mit Subdomains ausgestattet wurden.

Und wenn ich aus der Sicht der AP-clients schaue: Dort habe ich sowieso keine Kontrolle über das Routing meiner Pakete und muss ich darauf verlassen, dass das mit dem „Best Effort“ ernst genommen wird.

Wenn das wirklich das Problem ist, dürften auch die Supernodes mit Auslands-VPN, die Troisdorf (und IIRC auch andere) für den Notfall bereit halten, nie in Betrieb genommen werden (und dann kann man sich auch das Bereithalten sparen).

3 Likes

Was definiert denn einen Freifunk Rheinland e.V. Node?

Es sind Nodes von Freifunk Leichlingen, nicht Freifunk Rheinland.
Ich zitiere von leichlingen.freifunk.net:

Um bei Freigabe der Internetverbindung die so genannte Störerhaftung zu umgehen, werden VPN-Tunnel durch das Internet verwendet.

Das trifft ja auch beim Freifunk Rheinland zu. Aber eben auch beim Auslands-VPN. So erkläre ich es auch den Usern in Leichlingen. Wenn @Pinky andere Gerüchte auch in Leichlingen (Router Waldhaus) verbreitet ist das nicht meine Sache.

1 Like

In meinen Augen sind das ALLES ganz einfach „Freifunk“ Nodes.

Nicht Nodes von FFRL , nicht von Leichlingen, nicht von Troisdorf … Der sinn ist doch Menschen zugang zu einem Freien Netz und ggf. Internet zu bieten. Das geschieht in beiden Fällen.

3 Likes

Ich halte es -wie eingangs beschrieben- für sinnvoll, auf möglichst vielen Ebenen unserer Infrastruktur ein Mesh-Netz zu bauen.
Das erhöht zumindest die Ausfallsicherheit ein wenig und sorgt auch dafür, Netzzugang mit möglichst wenig Hierachie und Abhängigkeiten von einzelnen Personen, Organisationen und Firmen zu ermöglichen.

3 Likes

Es geht in dem Fall weder um unterschiedliche Backbone Uplinks, noch Schweden Tunnel, sondern um das Layer2 Bricken von 2 Vereinen - noch genauer sogar um das Bricken zweier batman virtualisierter Infrastrukturen, was bedeutet das grundsätzlich erst einmal davon auszugehen ist, dass die Instanzen beider Seiten uneingeschränkten Zugriff auf sämtliche Ressourcen beider Seiten haben.

Für die Show 2 Tunnel zu unterschiedlichen Domänen / Communities / Vereinen zu haben, blacklisten wir seit geraumer Zeit Router, damit diese bei uns nicht mehr connecten können, um genau diese Kopplung zu eliminieren!

Zum einen verstößt das ohnehin schon mal gegen die Policy des Rheinland Backbone die eine unerlaubte mittel- und unmittelbare Weitergabe des Uplinks untersagt, zum Anderen würde ich das wenn überhaupt als Domänen Thema in der Verantwortung der Domänen Admins (bspw. @phip für Wupper) sehen, sich mit solchen Experimenten zu beschäftigen, da diese das Spektakel im Endeffekt auch verantworten müssen.

Meinst Du „bridgen“? Oder wirklich „bricken“, also kaputt machen?

1 Like

Das schließt sich aus meiner Sicht nicht unweigerlich gegenseitig aus

Er denkt der VfN ist eine fette Domäne und kippt dann ganz viel Traffic über Wupper ab

Einen günstigen Fall unterstellt, wäre das eine - wenn auch nicht statthafte - zumindest mögliche Konsequenz.

Ich möchte darum bitten, Euch von einem „was macht hier gerade wer wo“ zu lösen, das hat mit dem Thema dieses Threads nichts zu tun. Sorry.

Die Frage lautet: Was geht nach PPA und was nicht?

(Falls eine -mir nicht bekannte- Policy des FF-RL mit dem PPA nicht vereinbar wäre, das wäre sehr bedauerlich und vermutlich ein Tätigkeitsfeld für diese neue Council, wenn dem so sein sollte.)

P.S. ich werde die Beiträge, die hier im falschen thread sind gern wieder in den Nachbarthread verschieben.

Ich hab 3 Beiträge in ein vorhandenes Thema verschoben: Was ist los im RBK@wupper.gl?

Ich hab 3 Beiträge in ein vorhandenes Thema verschoben: Was ist los im RBK@wupper.gl?

Das PPA bezieht sich auf Eigentümer individueller Netzwerkknoten. Mit dem Betrieb von Supernodes und Internetbackbone ist es inkompatibel. da sind immer Gatekeeper drin.

Sowohl diese als auch die grundlegende Fragestellung müssten überarbeitet werden, denn der Fall aus dem Parallelthread hat nichts mit dem PPA zu tun.

Darüber hinaus regelt das PPA weder das zur Verfügung Stellen von Ressourcen, noch das Gewähren eines Zugangs zu einem Exit VPN oder dem Rheinland Backbone.

Das PPA und MoU in Kombination würde es ermöglichen unterschiedliche VPN Exits zu nutzen, um den freien Transit ebenfalls in Richtung Internet (was nicht mehr zum PPA / MoU zählt, wurde ausgeschlossen) abzuführen.

Klassische Beispiele hierfür sind imho ein GRE IP Tunnel über das Rheinland Backbone, ein Schweden VPN IP Tunnel, ein IP Tunnel zum Förderverein, usw. Nicht hinzu zählen Layer2 Vernetzungen, die das Potential haben personalisierte Dienste entgegen ihrer Bestimmung zu nutzen oder andere Freifunk Communities zu beeinträchtigen.

Man könnte es auch aufgliedern nach

  • Peering ist nicht Transit
  • das PPA untersagt nicht
  • Transit an Bedingungen zu knüpfen
    • Geld
    • Mitgliedschaften
    • „Nichtpeering“ mit bestimmten anderen Netzen.