Ich hab mich immer gefragt, was eigentlich die Anzahl der Tunnel begrenzt? Mögliche Kandidaten
physikalische Netzwerkkarte bzw. die vielen kleinen Pakete
Problem im Linux-Netzwerkstack (FreeBSD ist dafür bekannt, da besser zu sein)
Probleme mit L2TP im Kernel
Tunneldigger
Wenn ich das hier so lese, scheint es wirklich am Tunneldigger zu liegen? Ich kann mir irgendwie nicht vorstellen, dass es heutzutage, auf einem leistungsstarken Rechner, nicht möglich wäre, eine „Tunnelverwaltung“ für weit über 1000 Tunnel zu schreiben, wenn die anderen Nadelöhre nicht dazwischen funken.
Eventuell sollte man den serverweitigen Broker auch mal in C schreiben?
@descilla plant für nächsten Mittwoch eine kleine Einführung in perf um mal zu versuchen, zu schauen, was die Tunnelzahl auf 250-300 begrenzt. Der Durchsatz alleine ist es definitiv nicht.
Der Broker schafft einfach nicht mehr in dem Kontext, wir nutzen ja nur einen UDP Port. Irgendwann gehen dann mal UDP Pakete verloren.
Der einfachste Weg mehr Tunnel zu unterstützen ist mehrere Broker zu starten Einfach auf ein paar verschiedenen Ports.
Leider nicht. Wir haben bei uns für jede Domäne einen eigenen Broker auf einem anderen Port. D. h. die 300 oder mehr Knoten verteilen sich auf 10-15 Tunneldigger. Das bringt kaum eine messbare Verbesserung.
Ja, mit doppelten Kosten lassen sich viele Probleme verringern ;).
Es geht mir eher darum, warum man nur 300 Knoten bzw. 150-200 Mbit/s Batmantraffic durch eine Netzwerkkarte kriegt. Gerouteter Traffic geht mehr, es scheint also keine reine Limitierung der Bandbreite seitens des Hosters zu sein. Sondern eher ein Treiberengpass bei den vielen kleinen Paketen und oder bei den vielen Tunneln.
Dazu haben wir noch keine Testreihe gemacht. Was auf jeden Fall sehr schlecht performt, ist wenn an mehrere VMs einfach über eine Brücke anbindet. Das muss dann schon virtuell geroutet werden.
Ich habe das mal ausgegliedert, damit wir die Dokumentation nicht so vollmüllen.
@adorfer, wie sieht die genaue Netztopologie bei dir aus?
Bei uns ist das so:
Blech → Brücke mit eth0 und der virtuellen Netzwerkkarte → Gateway-VM → 10-15 Batinterfaces und endsprechend viele Tunneldigger
Alternativ hatten wir getestet, zwei Gateway-VMs mit jeweils halb so vielen Knoten aufzusetzen. Das performte aber meiner Erinnerung nach nicht besser.
Diese Konstruktion lahmt sowohl mit einer Ralink als auch mit einer Internetzwerkkarte und jeweils Virtio ab 300 Knoten. Es gehen auch 500, aber da kommt einfach kein vernünftiger Durchsatz mehr bei rum. Durchsatzziel bei uns ist so, dass jeder Knoten 20-30 Mbit/s abrufen kann.
Leider nicht. Wir haben bei uns für jede Domäne einen eigenen Broker auf einem anderen Port. D. h. die 300 oder mehr Knoten verteilen sich auf 10-15 Tunneldigger. Das bringt kaum eine messbare Verbesserung.
das ist ein Proxmox mit VMs in einer VMBR mit virtio-netzwerkkarten.
Zumindest 300MBit/s gehen damit in vielen Dutzend L2TP-Sesstions.
Und mehr also 250MBit/s Dauerstrick giber Host leider nicht her, die 500MBit/s macht er nur „peak“.
Da ich bei 300MBit/s noch keine Probleme sehe, die ich dem L2TP oder dem Broker zuordne, vermute ich, dass da noch nicht das Limit ist.
o.k. das ist dann in der Tat eine andere Hausnummer.
Ich hatte vermutet, dass das erwähnte 200MBit/s-Limit an „einer VM“ liegen würde und nicht „an einem Blech“.
Jo, das Hauptproblem ist halt, die Begrenzung der Nat-IP durch das FFRL-Backbone. Die werden zu recht halt relativ sparsam vergeben, daher versuchen wir so viel Durchsatz wie möglich aus denen, die wir haben, zu pressen.
ok, ist das nur l2tp traffic oder der gesamt traffic, bei uns gibts noch bridges und so wie in http://vps296458.ovh.net/ zu sehen ( ok der hat nur ne 100Mbit Karte drin) und die tunnels sind nicht aktuell weil die sich immer auf und abbauen)
Vielleicht um die Statistik von @corny456 mal ein wenig zu erklären: Das Gateway bzw. die VM hat zwei Aufgaben:
Tunnelendpunkt für die Domänen die direkt hierauf liegen (Layer 2)
Weiterleitung und Nat für andere Gateways, die keine direkte FFRL-Anbindung haben (Layer 3)
Letzteres läuft total gut und wie man sieht geht der Durchsatz teilweise rauf auf 450 Mbit/s in beide Richtungen. Das ist schon ganz ordentlich und wir können fleißig Münzen bei Hetzner für Zusatzvolumen einwerfen.
Das geroutete performt gut und würde vermutlich noch weiter hoch gehen, wenn wir Server mit garantierter Gigabitanbindung nähmen.
Dagegen kann es auf anderen Gateways die viele Tunnel aber weniger Durchsatz haben, viel schlechter aussehen. Und die Ursache dafür würde ich gerne mal finden :).
Einfach auf ein paar verschiedenen Ports.
ist das auf die ganze maschine bezogen oder nur auf eine vm?