…habe ich auf unserer Webseite mal aufgeschreiben.
perfekt geschrieben 
wobei ich persönlich festgestellt habe,
Thin Clients (günstig in der Bucht zu bekommen (<20€) CPU technisch zu den FF Routern sehr stark, RAM ist das kleinste übel dabei) sind für Gluon ziemlich gut geeignet - gerade in Anbetracht des Stromverbrauchs bei lokalen (Super)Nodes.
Allerdings gibt es da eine Einschränkung: Verkrüppeltes BIOS, und Exoten Hardware sind zumindest in der x86 Variante ein ganz klares No Go!
Zu diesen Exoten gehört beispielsweise der Fujitsu Futro S450. OpenWRT bootet - doch gibt es Probleme bezüglich der „Festplatte“ - die verbaute Compact Flash / IDE Schnittstelle mag OpenWRT nicht und steckt beim mounten von / fest.
Das dem so ist ist für mich nicht tragisch, da ich dieses Gerät kostenlos bekommen habe, und nun mit Voyage Linux (extrem abgespecktes Debian) als lokaler Mailproxy läuft.
Ebenalls in der Bucht konnte ich einen HP/Compaq T5530 sowie einen Igel 2110 beide jeweils mit Versand für 8,90€ ergattern. Sowohl bei HP als auch bei IGEL weiss ich, dass die keinen grossartigen „Crap“ mit BIOS Modifikationen betreiben.
Wenn mich nicht alles täuscht, hat dieser IGEL sogar noch einen PPCI Slot, so dass das Testen mit einer zweiten Netzwerkkarte im System weitergehen kann. Ich werde berichten.
Ich befürchte, du hast mich nicht verstanden 
doch doch
es bringt nicht wirklich viel, lokal etwas am start zu haben wenn die grossen supernodes die last nicht aufnehmen können.
dennoch kann manchmal eine lokale supernode manchmal sinnig sein…
oben geschriebenes waren lediglich meine erkenntnisse zur hardware
p.s.: ich bin selber „bastler“ und mag frickelsysteme - und x86 Gluon ist definitiv so ein Kandidat…daher auch mein interesse dafür
Ich mag’s nicht hier kommentieren, hab’s im IRC getan, Bezug wäre dann
http://[2a03:2260:40:0:e809:f6ff:fe4f:b2c2]/
(So wie das Bezugsposting „mit den Gedanken“ auch nicht hier im Forum steht)
1 „Gefällt mir“
Das ist eine nette Annahme, nicht aber generell korrekt.
Welcher „ordentliche Router“ deckt denn derzeit VDSL50 ab? AFAIK keiner, bei VDSL25 ist rauchende Schicht im Schacht. Ich habe „Supernodes“ mit GBit-Uplink. die laste ich mit bitte welchem Router aus?
seufz
Das ist nicht der Flaschenhals.
Dahin gibt es Dutzende Vernbindungen, und wenn man 25mBit/s erreicht, ist das doch prima!
Für einen Suoernode mit Gbit-Anbindung bedeutet das max. 40 Clients bei Vollast.
nice2have
25mBit/s wären ein tolles Ziel, wenn man das flächendeckend erreichen könnte.
Schade, daß mein Beitrag so wenig verstanden wird…den muß ich wohl noch mal überarbeiten.
Performance ist nur eine Frage des Hardware-Einsatz, und nicht mein Thema!
Mir geht es mehr um eine generische Lösung für Offloader und/oder lokale Supernodes.
Also bei uns in Münster gehen die Überlegungen Richtung Tunnelprotokoll, dass im Kernel läuft, um die Kernelswitches zu vermeiden oder was mit AES-NI zu bauen. Alles andere ist nicht wirklich schnell, wenn man es wirklich praktisch einsetzt. Wir haben da derzeit ein Gateway, dass nur Testverbindungen hat derzeit und daher gut zum Testen geeignet ist. Ein Kollege testet da derzeit mit rum, das ist so das einzige, was sich bisher als praktikabel sinnvoll erwiesen hat.
[quote=„DerTrickreiche, post:7, topic:4373“]
Das ist nicht der Flaschenhals.[/quote]
Nein, der Weg dorthin ist es, richtig. Wir haben nun einmal Installationen, wo 30+ Leute hinter einem 100+ MBit/sec-Anschluß hängen. Im Durchschnitt ist der Traffic zu vernachlässigen - ganz wie zu Hause -, aber im Peak (Pausen) sind die rd. 16 MBit/sec eines 3600 einfach sehr, sehr wenig. Horizontal skalieren funktioniert da nicht, daher steht da nun ein x86-Offloader an. Vorzugsweise hätte ich da auch einen „Knoten“, der sich per Autoupdate aktualisiert - derzeit wird’s wohl eine Bastellösung werden, die traditionell administriert wird.
[quote=„MPW, post:8, topic:4373“]
Also bei uns in Münster gehen die Überlegungen Richtung Tunnelprotokoll, dass im Kernel läuft, um die Kernelswitches zu vermeiden[/quote]
IPSec? Könnten das die kleinen Kisten schneller?
[quote=„MPW, post:8, topic:4373“]
oder was mit AES-NI zu bauen[/quote]
Nützt das was auf Geräten, die kein AES können?
Lies nochmal den Thementitel, es geht hier um x86, Offloader und lokale Supernodes ;).
[quote=„MPW, post:10, topic:4373“]
Lies nochmal den Thementitel,[/quote]
Und lies Du bitte den zitierten Kontext:
[quote=„wusel, post:9, topic:4373“]
[quote=„MPW, post:8, topic:4373“]
Also bei uns in Münster gehen die Überlegungen Richtung Tunnelprotokoll, dass im Kernel läuft, um die Kernelswitches zu vermeiden[/quote]
IPSec? Könnten das die kleinen Kisten schneller?[/quote]
Ich kenne nur IPsec als zumindest kernelnahes VPN. Daher die Frage. Sofern IPsec performanter ist als fastd auf den Plasteroutern, spricht ja nichts dagegen, darüber das VPN zu realsieren. Insbesondere nach den Ergebnissen von Felix mit fastd+batman_adv verglichen mit nur fastd auf dem BananaPi:
[quote=„Felix, post:142, topic:3270“]
Freifunk-like Setup (über BATMAN 2014.4.0 via fastd v17 salsa2012+umac):[/quote]
Mir wäre nicht bekannt, dass IPSEC Layer2-Frames transportieren kann. Somit scheidet es für Freifunk in der derzeitigen Form (L2 Netz) aus.
IPSec arbeitet auf Layer 3, kann also keine Layer2 Frames tunneln.
Das ist dann Tunnel im Tunnel.
Aber irgendwie scheint es immer noch nicht angekommen zu sein, daß es mir eben nicht um die Geschwindigkeit geht!
Diese ganze Diskussion über Geschwindigkeit ist so lange komplett überflüssig, wie man kein vernünftiges ProofOfConcept für so eine Installation hat.
1 „Gefällt mir“
Full ACK. Ich habe den Eindruck, das ganze IPSEC-Gefasel kommt von Leuten, die noch nie damit gearbeitet haben. Sonst wüssten diese, was sie sich da ans Bein binden. Aber ich will ja nicht unbelehrbar sein. Somit warte ich mit Freude und Neugier auf die Referenzimpelementation der IPSEC-Apologeten.
3 „Gefällt mir“
OpenVPN arbeitet auch außen auf Layer 3, und tunnelt mir ein Layer 2-Segment von Gütersloh nach Frankfurt … Wo ein WIlle ist, ist auch ein Tunnel.
Wobei ich noch nicht gehört habe, daß man tap mit IPSec ohne Userspace verheiratet hätte (darum ging’s ja), und ich mag IPsec auch wegen der einfachen Erkenn- und Sperrbarkeit nicht, von der Unsichtbarkeit in der Linux-Routingtabelle ganz zu schweigen *grusel*.
fastd.ko? Oder doch mit Client-Hostrouten und OLSR arbeiten? *duck* Ja, anderes Thema („dezentrale Meshes“ oder so). Bin auf die Ergebnisse des WCW gespannt.
Kannst du dieses Thema bitte in eurem Speed-Thread weiter führen!
Hier geht es um etwas völlig Anderes!
So lange du nicht so tief eingestiegen bist, daß du in der Lage bist ein Batman und/oder fastd from Scratch aufzusetzen, mußt du auch nicht über Tunneling-Protokolle philosophieren;
und schon gar nicht in diesem Thread!
1 „Gefällt mir“
Been there, did that. Have you?
Ja, weil man bei OpenVPN zwischen Layer3 und Layer2 per --dev Option umschalten kann:
tun devices encapsulate IPv4 or IPv6 (OSI Layer 3) while tap devices encapsulate Ethernet 802.3 (OSI Layer 2).
Das gibt es bei IPSEC nicht.
Genau das ist der Punkt. Es ist irgendein Userspace erforderlich, der die Ethernetframes durch den L3-Tunnel schickt(kapselt). Debuggbarkeit, Performance, my ass!
ESP. Hinter Plaste NAT Router. Diese Schmerzen! Und damit es nicht langweilig wird gibts auch noch NAT-T. Vielleicht haben wir aber auch Glück und es geht schon die Phase1 (IKE) udp/500 schief. Dann brauchen wir die Phase 2 nicht debuggen. Ich gehe davon aus, dass jeder weiss, das es IKE in zwei Varianten (IKEv1 und IKEv2) gibt und dass die Proposels (Hash-Algorithmus, Encryption-Algorithmus, DH-Group, Encryption Domain) auf beiden Seiten stimmig sein müssen, sonst ist Schluss.
Sehr beliebt sind auch Rekeying Probleme (sowohl für Phase1 als auch für Phase2). Alles schon selber gesehen/gehabt. Alles geht, bleibt dann aber nach dem Rekeying stehen. Man merkt das nicht sofort. Gerade Phase1 hat üblicherweise längere Zeiten. Der Tunnel ist dann plötzlich nach einem Tag kaputt.
Zum Schluss (das es nicht langweilig wird), gibt es dann noch optionale (manchmal auch herstellerspezifische) Anbauten/Erweiterungen, wie z.B. Dead Peer Detection (DPD) und TFC.
Aber ist ja alles kein Problem. Die IPSEC-Apologeten hier machen das sicher alles ganz locker.