Hohe CPU Last OpenVPN
-
Nach viel Recherche und Lesen komme ich nun zu dem Schluss: Das ist normal, leider. Es lässt sich noch etwas mehr mit ein paar Tweaks im Bereich der MTU rausholen (ca. 160 Mbit/s), aber dann ist auch Schluss.
Testweisweise habe ich auch mal eine IPSEC ike2 Site 2 Site Verbindung aufgebaut und damit ein wenig rumgespielt. Maximum ist hier ca. 250 Mbit/s bei einer ähnlichen CPU Auslastung. Ich stelle also fest, dass man für Gigabitanbindungen tatsächlich richtig fette Hardware braucht. -
OpenVPN ist zwar keine Rakete und hat viel Overhead, aber 120 Mbit/s ist definitiv zu wenig bei deiner CPU.
Schau mal hier rein: https://forum.netgate.com/topic/135822/openvpn-durchsatz-wie-200mbit-schaffen-Rico
-
Tja, nur wie soll ich den Flaschenhals finden? Die Verschlüsselung ist es nicht, denn selbst ohne bleiben die Werte gleich. Der OpenVPN Prozess dreht einfach immer auf 100%.
-
Ich vermute es liegt am Hyper-V aber ist nur so ein Gefühl. ;-)
-Rico
-
Ich weiß es nicht. Die openssl Benchmarks sind recht gut. Die Leistung kommt also durchaus in den VMs an. Zudem habe ich bereits auch mit den CPU Ressourcen rumgespielt. Die Gewichtung der beiden Kerne der pfsense VM habe ich z.B. mal testweise verachtfacht. Das wirkt sich eher gar nicht aus. Ich wüsste gerne womit sich der openvpn Prozess so sehr beschäftigt. Eigentlich bleibt ja fast nur, dass das Paketeverschieben alleine ihn so stark auslastet, aber was hat das dann mit Hyper-V zu tun?
Und von der Virtualisierung komme ich auf beiden Seiten nicht weg. Das ganze Konzept funktioniert nur so, zumal ich auf der einen Seite nur 1HE habe und mir eine Hardware Appliance nur für die pfsense zu teuer vom Stellplatz her wäre.
Momentan sind 160 MBit/s mit OpenVPN durchaus auch ok, aber da wird in den nächsten Jahren noch ein wenig was dazu kommen. Daher würde es sich schon lohnen da ein wenig Aufwand und Mühe in eine Verbesserung zu stecken. -
@Rossi said in Hohe CPU Last OpenVPN:
Ich weiß es nicht. Die openssl Benchmarks sind recht gut.
Zeig bitte wie das getestet wurde.
-
Ich habe hiermit getestet (das sind die Werte der alten DL360G6):
openssl speed -elapsed -evp aes-128-cbc
Ergebnis:
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 82806425 aes-128-cbc's in 3.02s
Doing aes-128-cbc for 3s on 64 size blocks: 33180915 aes-128-cbc's in 3.02s
Doing aes-128-cbc for 3s on 256 size blocks: 9307965 aes-128-cbc's in 3.01s
Doing aes-128-cbc for 3s on 1024 size blocks: 2396353 aes-128-cbc's in 3.02s
Doing aes-128-cbc for 3s on 8192 size blocks: 304137 aes-128-cbc's in 3.01s
Doing aes-128-cbc for 3s on 16384 size blocks: 154589 aes-128-cbc's in 3.09s
OpenSSL 1.1.1a-freebsd 20 Nov 2018
built on: reproducible build, date unspecified
options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: clang
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-cbc 438210.75k 704191.85k 792216.62k 811614.42k 828339.63k 820750.96kEdit: Und das sind die Werte der DL360G10:
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 2453744 aes-128-cbc's in 3.05s
Doing aes-128-cbc for 3s on 64 size blocks: 2155135 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 1968569 aes-128-cbc's in 3.02s
Doing aes-128-cbc for 3s on 1024 size blocks: 1435283 aes-128-cbc's in 3.01s
Doing aes-128-cbc for 3s on 8192 size blocks: 414843 aes-128-cbc's in 3.08s
OpenSSL 1.0.2o-freebsd 27 Mar 2018
built on: date not available
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx)
compiler: clang
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-cbc 12885.30k 45976.21k 167114.17k 488637.44k 1104046.73k -
Ok, das ist in Ordnung.
Dann schließe Ich mich an bei Rico. -
Ohne AES NI Support sieht es übrigens schon viel deutlicher nach den Werten aus, die ich tatsächlich auch kriege:
openssl speed aes-128-cbc:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128 cbc 92290.28k 100538.64k 104060.39k 208777.11k 211984.38k 209988.98kSieht man in den OpenVPN Prrotokollen auf einem entsprechenden verbose Level ob er die Hardwarebeschleunigung auch wirklich verwendet?
-
Nein kann man nicht sehen.
Und "Hardware Crypto" muss auf "No Hardware Crypto Acceleration" stehen am server und client.
Kontrolle mit kldstat.
OpenVPN benutzt OpenSSL fürs crypto und diese hat eigene code um mit AES-NI zu "sprechen".Sonst hast jetzt was zum suchen, "HyperV AES-NI FreeBSD" :)
-
Hallo,
@Rossi said in Hohe CPU Last OpenVPN:
Sieht man in den OpenVPN Prrotokollen auf einem entsprechenden verbose Level ob er die Hardwarebeschleunigung auch wirklich verwendet?
du kannst aber beim OpenSSL Speedtest AES-NI deaktivieren. Bei deinen Testeinstellungen würde das dann so aussehen:
OPENSSL_ia32cap="~0x200000200000000" openssl speed -elapsed -evp aes-128-cbcWurde beim Test zuvor AES-NI verwendet, müsste dieses Ergebnis deutlich schlechter ausfallen.
Grüße
-
Siehe zwei Postings weiter oben. Das sind die Werte ohne AES NI. Die sind recht nah dran an dem, was ich tatsächlich erreiche.
-
Alles klar. Warum dann die Frage. Wenn es hier verwendet wird, wird es auch von OpenVPN verwendet.
-
Weil meine tatsächlich erreichbaren Werte eher dem entsprechen, was ohne AES NI zu schaffen ist. Mit AES NI geht der Benchmark ja eher Richtung 1 Gbit/s.
