spirit-of-eli
Goto Top

ESXi Management über PfSense (IPsec Tunnel) führt zu Massen an TCP Retransmissions

Moin zusammen,

hier ein kurzer Beitrag zu einem Problem sobald man die Management Seite eines ESXs über einen IPsec Tunnel erreichen möchte.
Bei mir trat dieses Phänomen mit einer PfSense Konstellation auf beiden Seiten der VPN Strecke auf.

Konstellation:
  • Sense1 - local
  • Sense2 - VM auf einem ESX
  • Sense1 und Sense2 sind per IPsec Tunnel miteinander verbunden. Routing ist definiert.
  • Auf dem ESX wurde ein VMKernel Adapter erstellt und ebenfalls an die Firewall-VM gehängt. Über dieses Netz findet der Zugriff statt. Die Routen für entfernte Netze wurde auf dem ESX angelegt.

Dargestellt hat es sich wie folgt:
  • Aufruf der Webseite des ESX (aus dem localen Netz) führt dazu, das die Seite nicht lädt.
  • Auf der Firewall-VM, welche auf der ESX selbst läuft, wird das zusätzliche Interface mit TCP Retransmissions bombadiert und nutzt die vollständig zur Verfüg stehende Bandbreite.
  • Auf der localen Firewall kommt hingegen nichts an.

Eine Analyse mit Wireshark führte schnell zu dem Problem. Die Lösung ist jedoch nicht ganz trivial.

Lösung:
Auf dem ESX muss für die physischen Adapter, sowie VSwitche "TCP Segmentation Offload" deaktiviert werden.
Link zum VMware Artikel: https://kb.vmware.com/s/article/2055140
Die einfachste Variante ist an der Stelle wie folgt: "In the vSphere Web Client, on the Manage tab for the host, click Advanced System Settings and set Net.TcpipDefLROEnabled to 0"
Auf der Firewall VM muss zusätzlich "hardware large receive offload" deaktiviert werden.

Edit1:
Deaktivieren von "LRO" auf dem ESX ist anscheint nicht erforderlich. Die Anpassung der Firewall-VM jedoch schon. Das kann weiterhin zu Performance Problemen führen.

Gruß
Spirit

Content-Key: 534726

Url: https://administrator.de/contentid/534726

Ausgedruckt am: 19.03.2024 um 02:03 Uhr

Mitglied: SeaStorm
SeaStorm 14.01.2020 um 11:15:17 Uhr
Goto Top
Hmm also offloading auf einem esxi, möglichst mit 10G zu deaktivieren ist auch ein fragwürdiger Bugfix. Je nach Traffic auf der Kiste kann sich das schon auf die CPU auswirken. Siehst du einen unterschied?
Mitglied: Spirit-of-Eli
Spirit-of-Eli 14.01.2020 aktualisiert um 11:35:14 Uhr
Goto Top
Ich habe hier gerade keine 10G Karten und auch nicht viel Traffic. Mich hat einfach gewurmt, wieso ich das Management Interface nicht aufrufen kann.
Ich teste derzeit noch aus, ob die Anpassung am ESX in der Form tatsächlich erforderlich ist. Vielleicht reicht es auch aus "LRO" nur auf dem entsprechenden VSwitch für die Verwaltung zu deaktivieren.

Prinzipiell bin bei dir was die Performance an geht. Testen kann ich es hier leider nicht ausgiebig.
Mitglied: Spirit-of-Eli
Spirit-of-Eli 14.01.2020 um 12:22:56 Uhr
Goto Top
Ich habe jetzt weiter herum getestet und zu dem die default Konfig einer PfSense überprüft. Dort ist "hardware TCP segmentation offload" sowie "hardware large receive offload" standard mäßig deaktiviert.

Mit der Konfiguration geht zwar die CPU Last stark hoch, aber der Durchsatz ist deutlich besser.
Keine Ahnung wieso ich das mal raus genommen hatte. Auf dem ESX ist dies definitiv nicht nötig!
Mitglied: chgorges
chgorges 14.01.2020 um 14:25:16 Uhr
Goto Top
Mach mal einen MTU Ping auf den Management Kernel, ob ggf. deine Tunnel-MTU angepasst werden muss.

Ich habe das Problem hin und wieder bei OpenVPN-Tunneln (wobei es eigentlich kein Problem, sondern nur Einstellungssache ist).
Mitglied: Spirit-of-Eli
Spirit-of-Eli 14.01.2020 um 14:42:02 Uhr
Goto Top
Die Pakete wurden zwar fragmentiert, aber selbst mit Anpassung auf 1360 haben ich das Problem sobald "hardware large receive offload" deaktiviert ist.
Mitglied: chgorges
chgorges 14.01.2020 um 15:00:40 Uhr
Goto Top
Und bei 1240 oder 1260? Soweit muss ich als runter.
Mitglied: Spirit-of-Eli
Spirit-of-Eli 14.01.2020 aktualisiert um 15:09:29 Uhr
Goto Top
Macht keinen unterschied und behebt das Problem nicht. Einzig der ping ohne Last geht um 3ms runter.