Beiträge von mindtec

Zitat

Warum eigentlich?

Wie gesagt - ich hatte zwischen den Systemen praktisch keine Bandbreite und nach vergleichbaren Problemen im Netz gesucht.
Die Performance-Probleme entsprechen auch den anderen Fragestellern in diesem Thread.

Primär findet man im Netz als Antworten:
1. Offloading & Co. überprüfen und abschalten (vgl. https://imgur.com/a/vt4tAMD)

2. Andere MTU sowie MSS testen - die empfohlenen Werte in verschiedenen Foren- und Blogbeiträgen sind alle ziemlich "random"

Mangels besseren Wissen und Erfahrung hab ich dann jede Menge Werte nach dem try&error-Prinzip ausprobiert...

Zitat

Zur Erkennung einer geringeren MTU gibt es die pMTUd (path MTU discovery) [...]

Top - da werde ich mich einlesen. Ich finde es super, dass Du wertvolle Hinweise gibst, wie man tiefer in die Materie einsteigen und den Problemen auf den Grund gehen kann. Danke dafür!
Der Artikel zu dem Thema sieht vielversprechend aus: https://blog.cloudflare.com/path-mtu-discovery-in-practice/

Zitat

OpenVPN ist in manchen Versionen auch bei funktionierendem ICMP störisch

Gut, in meinem Fall ging es nicht um OpenVPN, sondern um die Performance im VLAN - das lies sich ja über den Kontakt zum Netcup-Support im Backend lösen und somit auch ausschließen, dass es an der MTU lag

Ich habe nun die MTU 1492 getestet und erhalte dadurch nach wie vor super Werte.

Ursprünglich hatte ich auf der FW und auf dem Server als MTU 1400 auf dem jeweiligen LAN-Interface eingestellt. Wenn ich nun mit einer höheren Paketgröße gepingt habe, kam die Meldung "local error".

Nach dem Hochschrauben auf die MTU 1492 geht die Paketgröße 1464 Byte jedoch problemlos durch - alles darüber hinaus nicht mehr.

Zitat

Wenn Du einen „local error“ siehst, dann ist bereits der Host, von dem der Test ausgeht, in der MTU beschränkt. Über den Zielhost sagt das noch nichts aus.

Da es offenbar auch an den Einstellungen der VMs hängt (wie gerade durch die Einstellungsänderung getestet), bin ich mir nicht sicher, ob die Beschränkung bereits durch den Host kommt bzw. die Fehlermeldung dadurch ausgelöst wird.

Hi eripek,


Danke für Deine Antwort und Rückfragen - auf letztere gehe ich weiter unten ein.

Vorweg: das Problem ist in meinem Fall gelöst.

Ablauf:
Ich hatte gestern nochmal den Support angeschrieben und auch auf diesen Thread verwiesen. Heute morgen kam die Frage vom Support, welche Server betroffen seien. Parallel hatte ich die Performance im VLAN nochmal getestet und war bei 100 Kbit/s. Im Laufe des Nachmittags kam die Meldung vom Support, dass sie auf dem betreffenden Hostsystem keine Performance-Probleme feststellen können und hatten auch einen iperf-Log mitgeschickt:

Zitat

auf Host Ebene können wir das Problem nicht nachvollziehen. Wir bekommen konstant gute Geschwindigkeiten.

Hier der Output von iperf3:

[ ID] Interval Transfer Bandwidth Retr Cwnd

[ 4] 0.00-1.01 sec 86.3 MBytes 718 Mbits/sec 126 190 KBytes

[ 4] 1.01-2.01 sec 86.7 MBytes 726 Mbits/sec 0 226 KBytes

[ 4] 2.01-3.00 sec 91.8 MBytes 776 Mbits/sec 0 241 KBytes

[ 4] 3.00-4.01 sec 84.3 MBytes 701 Mbits/sec 0 258 KBytes

[ 4] 4.01-5.00 sec 89.2 MBytes 758 Mbits/sec 0 293 KBytes

[ 4] 5.00-6.01 sec 88.6 MBytes 737 Mbits/sec 0 319 KBytes

[ 4] 6.01-7.01 sec 83.2 MBytes 696 Mbits/sec 212 275 KBytes

[ 4] 7.01-8.01 sec 68.0 MBytes 573 Mbits/sec 0 285 KBytes

[ 4] 8.01-9.00 sec 72.7 MBytes 615 Mbits/sec 0 309 KBytes

[ 4] 9.00-10.01 sec 69.8 MBytes 578 Mbits/sec 0 321 KBytes

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval Transfer Bandwidth Retr

[ 4] 0.00-10.01 sec 821 MBytes 688 Mbits/sec 338 sender

[ 4] 0.00-10.01 sec 821 MBytes 688 Mbits/sec receiver

iperf Done.

Alles anzeigen

Ich habe dann direkt nochmal die Performance geprüft und kam auf sehr gute Werte:

iperf3 -c [server-ip] -p [server-port]

Zitat

Connecting to host 192.168.1.1, port 5201 [ 4] local 192.168.1.102 port 57292 connected to 192.168.1.1 port 5201

[ ID] Interval Transfer Bandwidth Retr Cwnd

[ 4] 0.00-1.00 sec 13.5 MBytes 113 Mbits/sec 0 440 KBytes

[ 4] 1.00-2.00 sec 11.5 MBytes 96.8 Mbits/sec 0 496 KBytes

[ 4] 2.00-3.00 sec 11.6 MBytes 97.3 Mbits/sec 0 574 KBytes

[ 4] 3.00-4.00 sec 11.4 MBytes 95.2 Mbits/sec 0 577 KBytes

[ 4] 4.00-5.00 sec 11.4 MBytes 95.7 Mbits/sec 0 595 KBytes

[ 4] 5.00-6.00 sec 11.5 MBytes 96.8 Mbits/sec 0 638 KBytes

[ 4] 6.00-7.00 sec 11.1 MBytes 93.2 Mbits/sec 0 638 KBytes

[ 4] 7.00-8.00 sec 11.6 MBytes 97.3 Mbits/sec 0 638 KBytes

[ 4] 8.00-9.00 sec 11.4 MBytes 95.3 Mbits/sec 0 638 KBytes

[ 4] 9.00-10.00 sec 11.4 MBytes 95.2 Mbits/sec 0 638 KBytes

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval Transfer Bandwidth Retr

[ 4] 0.00-10.00 sec 116 MBytes 97.6 Mbits/sec 0 sender

[ 4] 0.00-10.00 sec 114 MBytes 95.9 Mbits/sec receiver

iperf Done.

Alles anzeigen

An den Systemeinstellungen hatte ich seit meinem Beitrag in diesem Thread nichts mehr geändert.

Zu Deinen Fragen:

Zitat

Offloading trotz VM aktiviert? Oder Offloading ohne virtio? TCP Checksums?

Warum setzt Du die MSS um 100Byte kleiner als die MTU - anstelle von 60 (TCP/IPv4) oder 80 (TCP/IPv6)

- Offloading ist bei OpnSense scheinbar schon per default deaktiviert - hatte die Einstellungen aufgrund dieses Threads schon gestern geprüft und sie waren schon deaktiviert, obwohl ich vorher nichts dran gedreht habe.

Siehe auch: https://imgur.com/a/vt4tAMD

- Als Netzwerk-Interface ist auf beiden betreffenden Systemen "virtio" aktiviert

Zum Thema MTU vs. MSS:
Hier hast Du mich kalt erwischt... ich habe tatsächlich kein Verständnis davon und habe Werte nur nach dem Try&Error-Prinzip ausprobiert.
In der Vergangenheit bin ich diesbezüglich auch noch nie in Sachen Performance auf Probleme gestoßen. Daher vielen Dank für den Hinweis.

Ich habe mir folgenden verständlichen Artikel zu Gemüte geführt und verstehe nun mehr: https://www.elektronik-kompendium.de/sites/net/0812211.htm

Aus dem Artikel entnommen:

ping -c 1 -s $((1500-28)) -M do [ip-von-anderem-host]

Zitat

PING 192.168.1.1 (192.168.1.1) 1472(1500) bytes of data.

ping: local error: Message too long, mtu=1400

Die fürs VLAN bei Netcup optimale MTU scheint also bei 1400 zu liegen.

Ich kann mit einem Windows-System auf Basis RS 500 SAS G8 dienen.

So ermittelt:
https://www.heise.de/tipps-tricks/Festplatten-Geschwindigkeit-testen-so-geht-s-4184627.html

PS C:\WINDOWS\system32> winsat disk -seq -read -drive c
Windows-Systembewertungstool
> Wird ausgeführt: Featureaufzählung ''
> Laufzeit 00:00:00.00
> Wird ausgeführt: Speicherbewertung '-seq -read -drive c'
> Laufzeit 00:00:10.58
> Dshow-Videocodierzeit                        0.00000 s
> Dshow-Videodecodierzeit                      0.00000 s
> Media Foundation-Decodierzeit                0.00000 s
> Disk  Sequential 64.0 Read                   135.61 MB/s          7.0
> Gesamtausführungszeit 00:00:11.72

PS C:\WINDOWS\system32> winsat disk -seq -write -drive c
Windows-Systembewertungstool
> Wird ausgeführt: Featureaufzählung ''
> Laufzeit 00:00:00.00
> Wird ausgeführt: Speicherbewertung '-seq -write -drive c'
> Laufzeit 00:00:07.63
> Dshow-Videocodierzeit                        0.00000 s
> Dshow-Videodecodierzeit                      0.00000 s
> Media Foundation-Decodierzeit                0.00000 s
> Disk  Sequential 64.0 Write                  144.30 MB/s          7.1
> Gesamtausführungszeit 00:00:09.34

Hallo zusammen,


mein Problem ist vergleichbar -

Setup:
- OpnSense als Firewall
- 100 MBit/s CloudVLAN - innerhalb des VLANs kommt lediglich IPv4 zum Einsatz
- Debian-Server hinter der Firewall innerhalb des VLANs

Getestet habe ich verschiedene Punkte:
- Up- und Download-Raten vom Server durch die OpnSense -> ~90 MBit/s up&down
- Up- und Download-Raten über das WAN-Interface vom Server (habe es testweise aktiviert) -> ~90 MBit/s up&down

Also an sich super Werte...

Aber:
Mittels iPerf3 komme ich zwischen dem Linux-Server und der OpnSense lediglich auf eine Bandbreite von 100 Kbit/s

Die MTU ist auf dem LAN-Interface bei der OpnSense auf 1500 eingestellt. Beim Debian-Server genauso.
Wechsele ich die MTU auf beiden System zu 1300 (und MSS bei der OpnSense auf 1200), fällt die Bandbreite auf ~70 Kbit/s

Willkommen in ISDN-Zeiten...

Erklären kann ich mir das nicht wirklich.
Besonders interessant ist die Tatsache, dass Upload- und Downloadrate durch die Firewall hindurch sehr gut sind.


Falls jemand auf ähnliche Probleme stößt, noch ein paar Tipps zu iPerf3.
1. Ist als Plugin auf der OpnSense problemlos installierbar. Findet sich dann unter Interfaces > Diagnostics > iPerf
2. Auf Linux-System idR schnell per Paket-Manager installiert (z.B. apt install iperf)
3. Auf einem System einen iPerf-Server starten: iperf -s (dort erhält man einen Port angezeigt)
4. Auf dem anderen System den iPerf als Client starten: iperf -c [ip-adresse-vom-server] -p [vom-server-angezeigten-port]

----

Jedenfalls habe den Support heute dazu schon angerufen. Man verwies darauf, dass ich bitte einmal im Forum nachhaken soll, ob auch andere Kunden dieses Problem haben bzw. was noch getestet oder analysiert werden könnte. Falls ich hier nicht weiter kommen sollte, soll ich ein Ticket beim Support erstellen.


Liebe Community, habt ihr dazu eine Idee?
Welche Informationen könnt ihr zwecks Analyse gebrauchen?

Viele Grüße
Volker