Citrix-Probleme – und was das mit Nagle, QoS und MTU zu tun hatte

Ein akuter Fall mit langer Vorgeschichte

Als uns der Kunde kontaktierte, war die Lage bereits angespannt. Über Monate hinweg kam es in der Citrix-Workspace-Umgebung zu massiven Performanceproblemen – Eingaben verzögerten sich, Sitzungen froren regelmäßig ein und der Login dauerte ungewöhnlich lang. Die Symptome traten unregelmäßig, aber spürbar auf. Die IT-Abteilung hatte gemeinsam mit einem externen Dienstleister intensiv versucht, die Ursachen zu finden – jedoch ohne durchschlagenden Erfolg.

Auf Empfehlung hin wandte sich der Kunde an uns – mit einem klaren Ziel: eine fundierte, strukturierte und vor allem wirksame Ursachenanalyse. Die Lösung sollte unabhängig von Verantwortlichkeiten, technischen Containern oder Herstellern erfolgen.

Zielsetzung: Transparenz, Verlässlichkeit, Wirkung

Ziel war es, nicht nur Symptome zu dokumentieren, sondern die zentralen, ursächlichen Schwachstellen zu identifizieren – und diese in einer nachvollziehbaren und messbaren Form zu beseitigen. Dabei standen drei Dinge im Fokus:

• Schnelligkeit: Minimierung weiterer Produktivitätseinbußen
• Tiefe: Eine echte Ursachenanalyse statt oberflächlicher Workarounds
• Objektivität: Herstellerunabhängige Bewertung aller technischen Ebenen

Phase 1 – Vorbereitung: Messpunkte & Feedback-Kanäle

Messtechnische Ausstattung

Für die technische Analyse setzten wir zwei Allegro-Messsysteme ein:

• Allegro NMM 3210 im Rechenzentrum
• Allegro NMM 500 an einem Kundenstandort zur Ende-zu-Ende-Messung

Drei passive Netzwerk-TAPs wurden an entscheidenden Punkten installiert:

• WAN-Übergang RZ1 (MPLS)
• DMZ-Firewall RZ1 (LAN)
• LAN-Firewall Remoteoffice (LAN)

Diese müssen zwar aktiv in die Verbindung eingeschliffen werden, erlaubten dann aber eine 100% vollständige und verlustfreie Kopie der Messdaten und im Fall des MPLS Messpunkts (Ohne Firewall) auch ohne Sicherheitsrisiko, da die Messdaten nur in eine Richtung übertragen werden.

Feedbacksystem: Online-Störungsmeldung

Da der ursprüngliche Leidensdruck über Monate hinweg zu abnehmender Rückmeldung der Mitarbeitenden geführt hatte, stellten wir ein gezieltes Online-Formular zur Verfügung. So konnten Probleme konkret, fokussiert und zeitlich exakt gemeldet werden – ein essenzieller Baustein zur Korrelation mit den Messdaten.

Phase 2 – Analyse: Vom Symptom zur Ursache

Menschliche Wahrnehmung trifft Technik

Nutzerbeschwerden wie „es hängt“, „ich werde rausgeworfen“ oder „es reagiert verzögert“ sind typisch – aber technisch zunächst unscharf. Unsere erste Aufgabe: Übersetzung in konkrete Metriken:

• Latenz & Jitter
• Retransmissions & Segmentgrößen
• Packet Loss & RTT-Verläufe

Analyse-Methodik

Unsere Vorgehensweise war dabei strikt strukturiert:

• Trace-Aufzeichnung mit Zeitstempeln und Session-Korrelation
• Port-Mirroring & TAP-Analyse an kritischen Übergabepunkten
• Firewall-Kontrolle (Sophos / Check Point) auf Session-Limits, Memory, NAT-Prozesse
• DNS-Prüfung auf Round Trip-Verhalten, Resolverpfade und Timeouts
• QoS-Überprüfung im RZ zur Priorisierung von Echtzeit-Traffic

Phase 3 – Ergebnisse: Was wirklich gebremst hat

1. Path MTU Discovery blockiert – Folge: Blackhole Drops

Durch ICMP-Filter wurden notwendige PMTUD-Mechanismen blockiert. Große Pakete mit DF-Flag wurden unterwegs verworfen, was zu Retransmissions, variabler RTT und Latenzspitzen führte – ein klassisches Muster hinter „verzögerten Eingaben“.

2. Nagle aktiviert – Interaktive Anwendungen gestört

Im benutzerdefinierten TCP-Profil des Citrix ADC war der Nagle-Algorithmus aktiviert. Kleine Datenpakete wurden gepuffert, bis ein ACK eintraf – ein Mechanismus, der für interaktive Workloads wie ICA/HDX massiv kontraproduktiv ist.

3. QoS-Konfiguration im RZ nicht Citrix-tauglich

Im Rechenzentrum war die QoS-Konfiguration nicht optimal auf interaktive Anwendungen wie Citrix abgestimmt. Zeitweise wurde verfügbare Bandbreite durch nicht-kritische Uploads oder Downloads blockiert, was Echtzeitkommunikation ins Stocken brachte. Die Priorisierungsklassen reflektierten nicht das tatsächliche Verhalten der Anwendungen – mit der Folge, dass Citrix-Traffic nicht zuverlässig bevorzugt behandelt wurde.

4. DNS verursachte zusätzliche Wartezeiten

Die Analyse zeigte inkonsistente Resolverpfade und überflüssige Round Trips bei App-Starts und Logins. Zwar war DNS nicht der Hauptverursacher, trug aber erkennbar zur Gesamtlatenz bei.

5. Netzwerkstrecke mit Mikroverlusten

Die Allegro-Analyse identifizierte vereinzelte Paketverluste auf der Providerseite. Diese standen jedoch nicht im direkten Zusammenhang mit den Zeitpunkten der Hauptprobleme.

Phase 4 – Maßnahmen & Wirkung

Umgesetzte Korrekturen

• PMTUD wiederhergestellt durch Freigabe von ICMP und MTU-Prüfung entlang der Pfade
• Nagle deaktiviert im betroffenen TCP-Profil des Citrix ADC
• QoS im Rechenzentrum optimiert: Priorisierung des Citrix-Traffics angepasst, Low-Priority-Queues für nicht-relevante Bulk-Transfers eingeführt
• DNS-Resolver vereinfacht und Timeouts gesenkt
• Vorher/Nachher-Vergleich dokumentiert: RTT, Loss, Jitter, Throughput und Segmentverhalten

Ergebnisse – messbar und spürbar

• Citrix-Sitzungen stabiler, keine Hänger mehr
• Eingaben sofort wirksam, auch bei hoher Auslastung
• Latenzspitzen verschwanden, deutlich weniger Retransmissions
• Keine Downtime, keine Umbauten notwendig – alle Maßnahmen im Livebetrieb umgesetzt

Fazit: Sorgfalt, Tiefe und Wirkung

Was auf den ersten Blick wie ein „unlösbares Citrix-Problem“ wirkte, war in Wahrheit eine Kombination aus mehreren, aufeinander wirkenden Faktoren: verdeckte Netzwerktechnik (PMTUD, Nagle), nicht angepasste Priorisierung (QoS) und unzureichend gepflegte Infrastrukturkomponenten (DNS).

Die entscheidenden Erfolgsfaktoren:

• Strukturierte Analyse
• Unabhängigkeit von Zuständigkeiten oder Herstellern
• Volle Transparenz und technische Tiefe

Wir zeigen: Performance-Probleme lassen sich nicht mit Tools allein, sondern nur mit einem Methodenbewusstsein und fundierter Praxiserfahrung dauerhaft beheben.

‍