Ein Projekt aus der Praxis: ERP, Outlook & Co. streikten: hohe Latenzen, Paketverlust, ratlose Admins

Einleitung / Ausgangslage

Ein langjähriger Kunde meldete seit Monaten sporadische Störungen im Tagesbetrieb. Auffällig: Die Probleme traten wechselnd in verschiedenen Anwendungen auf – letztlich waren alle betroffen. Besonders häufig betroffen waren ältere Anwendungen und Maschinen, das ERP-System sowie Outlook bzw. die Exchange-Anbindung. Trotz Unterstützung durch den IT-Dienstleister blieb die Ursache unklar. Bereits in den ersten Minuten unserer Remoteanalyse zeigten interne Pings untypisch hohe Latenzen und Paketverluste – ein Verhalten, das in einem lokalen LAN nicht tolerierbar ist. Da auch die Produktion beeinträchtigt war, bestand akuter Handlungsbedarf.

Zielsetzung

Ziel war es, die Ursache der Netzwerkstörungen schnell und belastbar zu identifizieren, die Auswirkungen einzugrenzen und das Netz stabil zu betreiben – ohne Eingriffe, die die Produktion weiter gefährden.

Vorgehensweise

Messaufbau und Datenbasis

• Messgerät: Noch am selben Tag per Kurier bereitgestellt, für Remotezugriff und kontinuierliche Aufzeichnung.
• Datenquelle: Traffic-Spiegelung (SPAN) auf einem Hauptswitch zur Live-Analyse des Datenverkehrs.
• Fehlerzähler: Systematische Prüfung der Interface- und Port-Statistiken auf Switches und Servern.
• Protokollanalyse: Korrelation von Paketverlusten, RTT-Auffälligkeiten und TCP Retransmissions.

Methodik

• Ping-Basismessungen zur schnellen Plausibilisierung von Latenz und Loss.
• Paket- und Flow-Analyse zur Identifikation betroffener Protokolle und Sessions (u. a. SMB, Outlook/Exchange, ERP).
• Zeitliche Korrelation von Spanning-Tree-Ereignissen mit Applikationsfehlern.

Analyseergebnisse

1) Signifikante Paketverluste und Retransmissions

Die Fehlerzähler zeigten verworfene Frames auf mehreren relevanten Ports. In den Trace-Daten fiel eine erhöhte Rate an TCP Retransmissions zwischen Servern und Clients auf. Das erklärt die beobachteten Applikationssymptome (Timeouts, Wiederverbindungen, Dialogabbrüche): Retransmissions und temporäre Reachability-Lücken erhöhen die gefühlte Latenz und führen zu Fehlermeldungen insbesondere bei chattigen Protokollen.

2) Spanning-Tree-Topologieänderungen als Auslöser

Kernbefund war ein massives Spanning-Tree-Problem, ausgelöst durch neue Switches im Testlabor, die sich automatisch in die bestehende Domäne integriert hatten. Die Folge: wiederkehrende Topology Changes (RSTP), die – trotz grundsätzlich kürzerer Konvergenz als bei klassischem STP – kurze Unterbrechungen verursachten. Diese äußerten sich als Paketverluste, Port-Blocking/Forwarding-Transitions und CAM-Table-Flushs.

3) Wirkung der STP-Variante auf den Impact

Im vorliegenden Design wirkten Topology Changes netzwerkweit. Anders als bei PVSTP, bei dem eine Störung auf das jeweilige VLAN begrenzt bleibt, bremste hier eine einzelne Änderung faktisch alle VLANs aus. Diese Architekturentscheidung verstärkte die Auswirkungen: Ein lokaler Eingriff im Testlabor konnte globale Effekte im Produktivnetz auslösen.

Maßnahmen

Stabilisierung und Härtung des Spanning-Tree

Nach vollständiger Prüfung wurde die Spanning-Tree-Konfiguration manuell konsolidiert und vereinheitlicht. Die zentralen Schritte umfassten u. a.:

• Eindeutige Root-Bridge-Definition (Primary/Secondary) zur deterministischen Pfadwahl.
• Edge-Port-Behandlung (PortFast/Edge) für reine Endgeräteports zur Vermeidung unnötiger STP-Transitions.
• Aktivierung geeigneter Schutzmechanismen an Access-Ports, z. B. BPDU Guard / Root Guard, um ungewollte STP-Teilnahme externer oder Lab-Switches zu unterbinden.
• Segmentierung des Testlabors bzw. klare Trennung der Domänen, sodass Labor-Änderungen keine Produktiv-Topology-Events auslösen.
• Konsistenzprüfung von STP-Modus und Parametern auf allen beteiligten Switches.

Operative Begleitmaßnahmen

• Fortlaufende Live-Messung über den Spiegelport während der Änderungen zur unmittelbaren Wirkungskontrolle.
• Abgleich der Interface-Fehlerzähler und erneute Trace-Aufnahmen nach jedem Konfigurationsschritt.
• Dokumentation aller Anpassungen und Abstimmung mit dem IT-Dienstleister für die produktive Umsetzung.

Wirkung

• Keine Paketverluste mehr im Normalbetrieb.
• Keine außergewöhnlichen Latenzen; Ping-Werte stabil im für ein LAN erwartbaren Bereich.
• Deutlich reduzierte TCP Retransmissions; stabile Sessions ohne spontane Abbrüche.
• ERP und Outlook/Exchange liefen nach der Stabilisierung ohne die zuvor beobachteten Fehlermeldungen.
• Insgesamt spürbarer Leistungsschub im Netz und deutlich weniger Anwenderbeschwerden.

Fazit

Die Störungen resultierten nicht aus einzelnen „Problem-Anwendungen“, sondern aus wiederkehrenden Spanning-Tree-Topology-Events, getriggert durch automatisch beigetretene Labor-Switches. In einer STP-Topologie ohne VLAN-granulare Instanzen wirken solche Events netzweit und führen zu kurzfristigen Unterbrechungen – sichtbar als Paketverlust, Retransmissions und Applikationsfehler. Entscheidend war die saubere, belastbare Analyse mit Spiegelport-Messung, Fehlerzähler-Prüfung und Protokolltraces: Das Problem konnte am selben Tag eingegrenzt, innerhalb von zwei Tagen nachhaltig behoben und innerhalb von sechs Werktagen eine stabilere, performantere Umgebung hergestellt werden.

Der Fall unterstreicht, wie wichtig eine konsistente STP-Architektur, klare Domänengrenzen und das Härtungskonzept an Access-Ports sind. Kleine Konfigurationsdetails – insbesondere in gemischten oder gewachsenen Umgebungen – entscheiden darüber, ob lokale Tests isoliert bleiben oder das gesamte Produktionsnetz ausbremsen.

‍