On 12/18/15 08:05, Bjoern Franke wrote:
Am Freitag, den 18.12.2015, 01:30 +0100 schrieb Simon Kurka:
On 17.12.2015 08:15, Bjoern Franke wrote:
- Beim Treffen am Sonntag wurde mir berichtet, dass du beim FFRL
für weitere BGP-Peerings angefragt hast. Für welche Standorte denn?
Anfragen will. Jedes Gateway an alle Standorte, einschließlich Backup-Router.
Alle Standorte? Eigentlich kann man sich immer nur an zwei Standorte verbinden.
Warum nur zwei ?
vg Tarek
Wird inzwischen offenbar anders gehandhabt. Am 21.12.2015 18:46 schrieb "Bjoern Franke" bjo@nord-west.org:
Alle Standorte? Eigentlich kann man sich immer nur an zwei Standorte verbinden.
Warum nur zwei ?
Das wurde seitens Thomas so kommuniziert.
vg
-- xmpp bjo@schafweide.org
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Nein, GW8 fehlt weiterhin und ich gehe stark davon aus, dass ffrl eine Remote IP für den Tunnel braucht oder?
Ich schaue grundsätzlich gerne bei Hetzner, die haben jetzt auch schöne neue Kisten mit Gigabit Anbindung. Webtropia wäre eine Option, ich glaube DUS located. Strato wäre auch gut, da BER. Da kenne ich gerade die Angebote gar nicht.
Sorry gerade vom Handy, sonst besser recherchiert. Am 21.12.2015 19:01 schrieb "Bjoern Franke" bjo@nord-west.org:
Am Montag, den 21.12.2015, 18:48 +0100 schrieb Simon Kurka:
Wird inzwischen offenbar anders gehandhabt.
Hast du die Anfrage mittlerweile gestellt?
-- xmpp bjo@schafweide.org
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
Strato hat nur virtouzzo (openvz) - scheidet damit schon aus. Bei Hetzner denkst du an deren neuen vServer Reihe oder? Die Angebote sind gut und wir hätten da eine andere Location.
Bei myloc stehen bereits 06 und 12.
Am 21. Dezember 2015 19:55:58 MEZ, schrieb Simon Kurka simon@kurka.cc:
Nein, GW8 fehlt weiterhin und ich gehe stark davon aus, dass ffrl eine Remote IP für den Tunnel braucht oder?
Ich schaue grundsätzlich gerne bei Hetzner, die haben jetzt auch schöne neue Kisten mit Gigabit Anbindung. Webtropia wäre eine Option, ich glaube DUS located. Strato wäre auch gut, da BER. Da kenne ich gerade die Angebote gar nicht.
Sorry gerade vom Handy, sonst besser recherchiert. Am 21.12.2015 19:01 schrieb "Bjoern Franke" bjo@nord-west.org:
Am Montag, den 21.12.2015, 18:48 +0100 schrieb Simon Kurka:
Wird inzwischen offenbar anders gehandhabt.
Hast du die Anfrage mittlerweile gestellt?
-- xmpp bjo@schafweide.org
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
... Dedicated ...
webtropia = myLoc, hat aber noch einen günstigeren Dedi, 300 MBit/s garantiert
Strato hat auch im Dedicated Bereich nur Müll.
Hetzner EX41S-SSD finde ich richtig lecker :D, 1 GBit/s garantiert (u. U. Nürnberg, aber anderes Rechenzentrum als netcup). Zum ECIX gibt es einen 10 GBit Uplink. Günstige Latenzen wird es geben, wenn FFRL Frankfurt wieder in Betrieb nimmt.
Mein Votum läge aktuell bei Hetzner.
Hi,
Nein, GW8 fehlt weiterhin und ich gehe stark davon aus, dass ffrl eine Remote IP für den Tunnel braucht oder?
Ich habe gerade mit Thomas geredet. Es ist garkein Problem alle Server anzubinden. Er brauch nur die IP der server. Er hat auch darum gebeten die IPs der Supernodes nach für nach zu ihn zu schicken und nicht alle auf einmal. Eine Einrichtung seitens ffrl dauert 14Tage.
vg Tarek
Am Montag, den 28.12.2015, 17:42 +0100 schrieb Jan-Tarek Butt:
Hi,
Nein, GW8 fehlt weiterhin und ich gehe stark davon aus, dass ffrl eine Remote IP für den Tunnel braucht oder?
Ich habe gerade mit Thomas geredet. Es ist garkein Problem alle Server anzubinden. Er brauch nur die IP der server. Er hat auch darum gebeten die IPs der Supernodes nach für nach zu ihn zu schicken und nicht alle auf einmal. Eine Einrichtung seitens ffrl dauert 14Tage.
Wunderbarst, vielen Dank dafür!
Grüße auf den Congress! bjo
Hi,
sehr gut :) Dann brauchen wir auch nicht mehr den airVPN Umweg zu gehen.
Am 28. Dezember 2015 17:42:26 MEZ, schrieb Jan-Tarek Butt tarek@ring0.de:
Hi,
Nein, GW8 fehlt weiterhin und ich gehe stark davon aus, dass ffrl
eine
Remote IP für den Tunnel braucht oder?
Ich habe gerade mit Thomas geredet. Es ist garkein Problem alle Server anzubinden. Er brauch nur die IP der server. Er hat auch darum gebeten die IPs der Supernodes nach für nach zu ihn zu schicken und nicht alle auf einmal. Eine Einrichtung seitens ffrl dauert 14Tage.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hallo zusammen,
mir sind im Zuge der Entwicklung von Klassenorientierten puppet-Modulen ein guter und ein schlechter Punkt aufgefallen:
Der Gute: Ein Server kann mehrere Hoods parallel verwalten. Folglich können wir auch kleinere Hoods schaffen ohne Geld für Server mit viel zu viel Power zu verschwenden.
Der Schlechte: Mehrere Server pro Hood sind Mist. Die Server pflegen ein Full-Mesh (via tunnel) um das AS-interne Routing sicher zu stellen. Wenn zwei Server für eine Hood zuständig sind, sollten diese Server mit batman verbunden sein; ansonsten läuft man Gefahr, dass ein Teil des eigenen Subnetzes nicht erreichbar ist. Diese Verbindung kann zustande kommen indem man das batman-Interface der jeweiligen Hood mit dem Tunnel-Interface zum zweiten Server bridged. D. h. der Tunnel ist für das batman-Geraffel einer bestimmten Hood reserviert (ansonsten besteht die Gefahr zwei Hoods zu verbinden). Lösen könnte man das in dem man pro Hood eine VLAN ID darüberlegt und so an beiden Enden die Daten aus dem Tunnel auf die verschiedenen Hoods sortieren kann. Alternativ baut man für das batman-Geraffel pro Hood jeweils eigene Tunnel zum zweiten Server auf, was zusätzlichen Overhead mitbringt.
Außerdem habe ich Bauchschmerzen damit batman-Geraffel auf Inter-Server Verbindungen zu haben. batman schafft die Flexibilität einen Router einfach irgendwo mit ins Netz schmeißen zu können. Die Server sind aber wohl definierte Punkte des Netzes, weshalb batman Verbindungen zwischen diesen eigentlich überflüssig sind.
Folglich: Kann man zwar machen, ist aber halt kacke!
Mein Vorschlag: Ein Server pro Hood.
Den Nachteil der fehlenden Redundanz kann man ausgleichen, indem die Router wissen wo sie sich hin verbinden sollen, wenn ihr einziger Server ausfällt (sozusagen eine Backup-Hood). Alternativ (meine Präferenz) könnten sich die VPN Router bei Ausfall zufällig an irgendeine vorhandene Hood dranhängen, dann hätten wir bei Ausfall eines Servers keine punktuelle Mehrbelastung einer bestimmten anderen Hood. In einem bestimmten Intervall (z. B. Täglich) könnten die Router das Vorhandensein ihrer eigenen Hood prüfen und ggf. dahin wechseln.
Das Neu-Verbinden stellt kein zusätzliches Problem dar, da die Router die mit dem ausfallenden Server verbunden sind sich ohnehin neu verbinden müssen. Ob sich die ganze Hood neu verbindet (weil die gesamte Hood an einem Server hängt) oder nur ein Teil der Hood betroffen ist, macht für das Netz keinen Unterschied.
Fragen? Meinungen? Ideen? Verbesserungen?
LG Simon
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 28.01.2016 um 15:54 schrieb Simon Kurka via Dev:
Fragen? Meinungen? Ideen? Verbesserungen?
wie sieht es mit VM aus? genauer: könnte man mehrere VM auf einem server laufen lassen?
supernodes VM hatte ich schon mal ins spiel gebracht mitte ende 2015 siehe ML archiv.
- -- Gruß pic
Xmpp: picard@ffnw.de & picard@fr32k.de @ME https://wiki.nordwest.freifunk.net/picard
Moin,
mir sind im Zuge der Entwicklung von Klassenorientierten puppet-Modulen ein guter und ein schlechter Punkt aufgefallen:
Der Gute: Ein Server kann mehrere Hoods parallel verwalten. Folglich können wir auch kleinere Hoods schaffen ohne Geld für Server mit viel zu viel Power zu verschwenden.
Klingt sehr gut :)
Der Schlechte: Mehrere Server pro Hood sind Mist. Die Server pflegen ein Full-Mesh (via tunnel) um das AS-interne Routing sicher zu stellen. Wenn zwei Server für eine Hood zuständig sind, sollten diese Server mit batman verbunden sein; ansonsten läuft man Gefahr, dass ein Teil des eigenen Subnetzes nicht erreichbar ist. Diese Verbindung kann zustande kommen indem man das batman-Interface der jeweiligen Hood mit dem Tunnel-Interface zum zweiten Server bridged. D. h. der Tunnel ist für das batman-Geraffel einer bestimmten Hood reserviert (ansonsten besteht die Gefahr zwei Hoods zu verbinden). Lösen könnte man das in dem man pro Hood eine VLAN ID darüberlegt und so an beiden Enden die Daten aus dem Tunnel auf die verschiedenen Hoods sortieren kann. Alternativ baut man für das batman-Geraffel pro Hood jeweils eigene Tunnel zum zweiten Server auf, was zusätzlichen Overhead mitbringt.
Ich halte Redundante Server für hoods schon für Wichtig um eben Ausfall Sicherheit vorzubeugen. Es ist in der neuen batman Version ist das VLAN problem behoben das könnten wir nutzen. Andernfalls müsste es auch möglich sein die Supernodes via fastd verbinden zu lassen und darüber den batman traffic pustet. Die Komplexität steigt dadurch zwar stark an allerdings gibt es auch einen single point of Failure weniger. Die Supernodes könnten trotzdem jeweils über Layer 3 mit den andern Supernodes verbunden sein. Es sollte ja kein Problem darstellen mehrere default Adressen zu announcen.
Außerdem habe ich Bauchschmerzen damit batman-Geraffel auf Inter-Server Verbindungen zu haben. batman schafft die Flexibilität einen Router einfach irgendwo mit ins Netz schmeißen zu können. Die Server sind aber wohl definierte Punkte des Netzes, weshalb batman Verbindungen zwischen diesen eigentlich überflüssig sind.
Folglich: Kann man zwar machen, ist aber halt kacke!
Die Problematik liegt in Batman selbst. Besteht diese Layer 2 Verbindung zwischen den Gateways nicht so entsteht Chaos im Routing und die DSL Anschlüsse werden dicht gemacht zudem fangend die Supernodes an sich gegenseitig mit ihrer vollen Anbindung zu DDosen. Das hatten bjo und ich Letztes ja bereits versucht. Dabei sind die Firewalls von Bytemine abgeraucht. War nicht soo cool :D
Mein Vorschlag: Ein Server pro Hood.
Den Nachteil der fehlenden Redundanz kann man ausgleichen, indem die Router wissen wo sie sich hin verbinden sollen, wenn ihr einziger Server ausfällt (sozusagen eine Backup-Hood).
Das führt dazu das wir relativ kleine Hoods haben werden geografisch betrachtet. Pro Server sollten maximal 150 VPN peers bestehen da fastd im userland läuft und auch nur auf singelcore. Es würde bedeuten das deutlich mehr Richtfunkstrecken Statisch eingerichtet werden müssten. Da die hood grenzen in Osnabrück z.B. nichtmal die ganze Stadt bedecken würden.
Alternativ (meine Präferenz) könnten sich die VPN Router bei Ausfall zufällig an irgendeine vorhandene Hood dranhängen, dann hätten wir bei Ausfall eines Servers keine punktuelle Mehrbelastung einer bestimmten anderen Hood. In einem bestimmten Intervall (z. B. Täglich) könnten die Router das Vorhandensein ihrer eigenen Hood prüfen und ggf. dahin wechseln.
Hm ja das ginge auch bin mir nicht ganz sicher ob das eine gute Lösung wäre.
Das Neu-Verbinden stellt kein zusätzliches Problem dar, da die Router die mit dem ausfallenden Server verbunden sind sich ohnehin neu verbinden müssen. Ob sich die ganze Hood neu verbindet (weil die gesamte Hood an einem Server hängt) oder nur ein Teil der Hood betroffen ist, macht für das Netz keinen Unterschied.
Das sehe ich auch nicht als problematisch. Zumal die anzahl der peers pro Server begrenzt ist um eben zu verhindern das Server überlastet werden.
vg Tarek
Hi,
Am 28.01.2016 um 15:54 schrieb Simon Kurka via Dev:
Fragen? Meinungen? Ideen? Verbesserungen?
wie sieht es mit VM aus? genauer: könnte man mehrere VM auf einem server laufen lassen?
supernodes VM hatte ich schon mal ins spiel gebracht mitte ende 2015 siehe ML archiv.
Das hatten wir früher da traten Problematiken auf Bjo weißt du noch was das Problem war ?
vg Tarek
Hi,
Im allgemeinen würde ich auch erst mal vorschlagen das wir nur einzelne hoods Deponien mit paar weisen Servern. Die noch nicht über Routing verbunden sind. Damit schaffen wir überhaupt erst mal ein nutzbares Netz und können auf der stabileren Basis aufsetzen. Quasi nach dem Motto Step by Step.
vg Tarek
Ich denke, das ist etwas für das Treffen mit Whiteboard.
Kein Routing zwischen den Netzen wird nicht funktionieren. Routing muss AS intern laufen und bietet nebenbei gesagt so viele Vorteile. Macht man das nicht, muss man unglaublich viel Aufwand darein stecken, dass ohne überhaupt irgendwas läuft. Am 30.01.2016 11:26 schrieb "Jan-Tarek Butt via Dev" dev@lists.ffnw.de:
Hi,
Im allgemeinen würde ich auch erst mal vorschlagen das wir nur einzelne hoods Deponien mit paar weisen Servern. Die noch nicht über Routing verbunden sind. Damit schaffen wir überhaupt erst mal ein nutzbares Netz und können auf der stabileren Basis aufsetzen. Quasi nach dem Motto Step by Step.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Ja, da gebe ich dir vollkommen Recht. Haben wir für die bird-config fürs interne Routing ein Puppetmodul?
Am 30. Januar 2016 11:33:16 MEZ, schrieb Simon Kurka via Dev dev@lists.ffnw.de:
Ich denke, das ist etwas für das Treffen mit Whiteboard.
Kein Routing zwischen den Netzen wird nicht funktionieren. Routing muss AS intern laufen und bietet nebenbei gesagt so viele Vorteile. Macht man das nicht, muss man unglaublich viel Aufwand darein stecken, dass ohne überhaupt irgendwas läuft. Am 30.01.2016 11:26 schrieb "Jan-Tarek Butt via Dev" dev@lists.ffnw.de:
Hi,
Im allgemeinen würde ich auch erst mal vorschlagen das wir nur
einzelne
hoods Deponien mit paar weisen Servern. Die noch nicht über Routing verbunden sind. Damit schaffen wir überhaupt erst mal ein nutzbares
Netz
und können auf der stabileren Basis aufsetzen. Quasi nach dem Motto
Step
by Step.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Am Samstag, den 30.01.2016, 21:48 +0100 schrieb Jan-Tarek Butt via Dev:
On 01/30/16 20:12, Bjoern Franke via Dev wrote:
Ja, da gebe ich dir vollkommen Recht. Haben wir für die bird-config fürs interne Routing ein Puppetmodul?
Wehn meinst du ??
Simon, auf ihn habe ich geantwortet und ihn zitiert.
vg
Jo, OSPF intern und iBGP für die Borders. Gerade bastel ich an einem ordentlichen network Modul um die Interfaces sowie die nat ip auf dem loopback Interface zu verwalten. Am 30.01.2016 20:17 schrieb "Bjoern Franke via Dev" dev@lists.ffnw.de:
Ja, da gebe ich dir vollkommen Recht. Haben wir für die bird-config fürs interne Routing ein Puppetmodul?
Am 30. Januar 2016 11:33:16 MEZ, schrieb Simon Kurka via Dev < dev@lists.ffnw.de>:
Ich denke, das ist etwas für das Treffen mit Whiteboard.
Kein Routing zwischen den Netzen wird nicht funktionieren. Routing muss AS intern laufen und bietet nebenbei gesagt so viele Vorteile. Macht man das nicht, muss man unglaublich viel Aufwand darein stecken, dass ohne überhaupt irgendwas läuft. Am 30.01.2016 11:26 schrieb "Jan-Tarek Butt via Dev" dev@lists.ffnw.de:
Hi,
Im allgemeinen würde ich auch erst mal vorschlagen das wir nur
einzelne
hoods Deponien mit paar weisen Servern. Die noch nicht über Routing verbunden sind. Damit schaffen wir überhaupt erst mal ein nutzbares
Netz
und können auf der stabileren Basis aufsetzen. Quasi nach dem Motto
Step
by Step.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Moin,
Jo, OSPF intern und iBGP für die Borders. Gerade bastel ich an einem ordentlichen network Modul um die Interfaces sowie die nat ip auf dem loopback Interface zu verwalten.
das haben wir am Freitag nur kurz gestreift. Ich faend es beizeiten nochmal ganz spannend ein Treffen fuer die Netzarchitektur zu machen (kann man ja mit der naechsten Diskussion rund um den Hoodselector etc. kombinieren ;)
felix
-
Bjoern Franke -
Felix Kronlage -
Jan-Tarek Butt -
picard -
Simon Kurka -
Simon Kurka -
Stefan