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

Printed on: April 24, 2024 at 10:04 o'clock

Member: SeaStorm
SeaStorm Jan 14, 2020 at 10:15:17 (UTC)
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?
Member: Spirit-of-Eli
Spirit-of-Eli Jan 14, 2020 updated at 10:35:14 (UTC)
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.
Member: Spirit-of-Eli
Spirit-of-Eli Jan 14, 2020 at 11:22:56 (UTC)
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!
Member: chgorges
chgorges Jan 14, 2020 at 13:25:16 (UTC)
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).
Member: Spirit-of-Eli
Spirit-of-Eli Jan 14, 2020 at 13:42:02 (UTC)
Goto Top
Die Pakete wurden zwar fragmentiert, aber selbst mit Anpassung auf 1360 haben ich das Problem sobald "hardware large receive offload" deaktiviert ist.
Member: chgorges
chgorges Jan 14, 2020 at 14:00:40 (UTC)
Goto Top
Und bei 1240 oder 1260? Soweit muss ich als runter.
Member: Spirit-of-Eli
Spirit-of-Eli Jan 14, 2020 updated at 14:09:29 (UTC)
Goto Top
Macht keinen unterschied und behebt das Problem nicht. Einzig der ping ohne Last geht um 3ms runter.