Leitfaden zur Netzwerkfehlerbehebung

Prev Next
Technical users

This guide is for customer network teams.

Dieser Leitfaden beschreibt die gemeinsamen Schritte, die zur Diagnose und Behebung von Problemen mit der Netzwerkleistung erforderlich sind. Er ist als priorisiertes Flussdiagramm aufgebaut, das mit den einfachsten und häufigsten Problemen beginnt, bevor es zu komplexeren Untersuchungen übergeht.

NOTE

The information in this guide includes step to debug your network with best practices for cloud solutions. You should run through these steps prior to contacting the Tulip support team for networking issues.

Voraussetzung: Best Practices für Anwendungen prüfen

Bevor Sie mit einer eingehenden Netzwerkuntersuchung fortfahren, müssen Sie sicherstellen, dass Ihre Anwendung auf optimale Leistung ausgelegt ist. Viele Leistungsprobleme lassen sich durch Anpassungen am Anwendungsdesign beheben, beispielsweise bei hochfrequenten API-Aufrufen oder ineffizienten Triggern.

Lesen Sie hier den Leitfaden zum Anwendungsdesign.

Wenn Ihre App diese Richtlinien bereits befolgt, fahren Sie mit den folgenden Phasen der Netzwerkuntersuchung und den darauf folgenden Schritten fort:

Phase 1: Grundlegende Überprüfungen

Schließen Sie lokale, clientseitige und Probleme auf der physikalischen Ebene mit minimalem Aufwand schnell aus.

1. Führen Sie aktuelle Diagnosen von der betroffenen Station aus durch

  • Maßnahme: Führen Sie die folgenden Befehle sowohl für den Ziel-Dienst als auch für einen stabilen, öffentlichen Endpunkt mit hoher Bandbreite (z. B. google.com oder cloudflare.com) zum Vergleich aus.
  • Erweiterter Ping (50–100 Pings oder mehr), um minimale, durchschnittliche und maximale Latenz sowie Paketverluste anzuzeigen.
  • ping 1.1.1.1 (Cloudflare)
  • ping 8.8.8.8 (Google)
  • pathping (unter Windows)
  • DNS-Abfragen: nslookup, dig, drill
  • Grund für die Priorität: Dies sind die am schnellsten zu erfassenden Daten. Der Vergleichstest ist entscheidend und zeigt Ihnen sofort, ob das Problem spezifisch für den Dienstpfad ist oder ob es sich um ein allgemeines Internetproblem an diesem Standort handelt.
  • Maßnahme – Verwenden Sie den Tulip „Netzwerkcheck“
    • Option 1 – Rufen Sie in einem Browserfenster https://{Ihre Tulip Instance}.tulip.co/networkCheck auf
    • Option 2 – Klicken Sie im Tulip Player auf das Menü „Extras“ und dann auf „Netzwerkprüfung“.
    • Überprüfen Sie die Ergebnisse
      • Prüfen Sie, ob alle Tests erfolgreich sind. Falls dies nicht der Fall ist, erstellen Sie einen Screenshot dieses Bildschirms und klicken Sie auf „Diagnosedaten herunterladen“. Senden Sie den Screenshot und die Diagnosedatei an support.tulip.co, damit ein Tulip-Mitarbeiter Ihnen weiterhelfen kann.
      • Sie können diese Dateien auch an Ihr internes IT-Team weiterleiten, damit dieses Ihnen bei der Behebung des Problems helfen kann.

2. Führen Sie eine physische Hardware-Überprüfung durch

  • Maßnahme: Führen Sie eine gründliche physische Hardwareprüfung für die betroffenen Stationen durch. Überprüfen Sie, ob Ethernet-Kabel defekt sind, Netzwerkkarten nicht richtig eingesteckt sind oder Probleme mit dem physischen Switch-Port vorliegen.Grund für die Priorität: Probleme auf der physikalischen Ebene sind grundlegender Natur und können komplexere Netzwerkprobleme vortäuschen. Wenn Sie diese zuerst ausschließen, vermeiden Sie Zeitverschwendung bei der Diagnose auf Softwareebene.

3. Überprüfen Sie die lokale Konfiguration des Arbeitsplatzes

  • Maßnahme: Überprüfen Sie die DNS-Einstellungen des Arbeitsplatzes, lokale Proxy-Konfigurationen (auf eventuelle Umleitungen), lokale Sicherheits-/Firewall-Software und untersuchen Sie die DHCP-Server-Protokolle, um sicherzustellen, dass am Arbeitsplatz keine häufigen DHCP-Neuverhandlungen stattfinden.
  • Grund für die Priorität: Hierbei handelt es sich um client-spezifische Einstellungen, die bei einem einzelnen Benutzer Probleme verursachen können, ohne das gesamte Netzwerk zu beeinträchtigen. Dies ist der nächste logische Schritt, nachdem physische und allgemeine Internetprobleme ausgeschlossen wurden.

4. Lokale Systemprotokolle auf aktuelle Ereignisse überprüfen

  • Maßnahme: Überprüfen Sie auf dem betroffenen Rechner die Systemereignisprotokolle (z. B. Windows-Ereignisanzeige, macOS-Konsole oder Linux journalctl/dmesg) auf aktuelle netzwerkbezogene Fehler, Warnungen oder wesentliche Änderungen, die mit dem Auftreten des Leistungsproblems zusammenfallen. Achten Sie auf Ereignisse im Zusammenhang mit Statusänderungen der Netzwerkadapter, fehlgeschlagenen DHCP-Leases, Problemen bei der DNS-Auflösung oder Warnmeldungen der Firewall bzw. der Sicherheitssoftware.
  • Grund für die Priorität: Dies hilft festzustellen, ob es sich um ein neu aufgetretenes Problem handelt oder ob es mit einer kürzlich vorgenommenen Konfigurationsänderung oder einem vorangegangenen lokalen Netzwerkproblem zusammenhängt, das möglicherweise Spuren auf dem Client-Rechner hinterlassen hat.

Phase 2: Korrelierte Infrastrukturanalyse

Nutzen Sie spezifische Ereignisdaten, um die gemeinsam genutzte Netzwerkinfrastruktur zu untersuchen. Diese Phase erfordert IT-Zugriff und Zusammenarbeit.

5. Zeitstempel lokalisieren und interne Protokolle überprüfen

  • Maßnahme: Korrelieren Sie die von Benutzern gemeldeten Verzögerungszeiten mit den Protokollen der internen Netzwerkgeräte. Achten Sie auf:
  • Starker Netzwerk -Jitter
  • Paketverlust oder hohe Wiederholungsraten
  • Überprüfen Sie das Netzwerkdiagramm und stellen Sie Protokolle bereit
  • Netzwerkprotokolle aus dem Zeitraum des Problems (ggf. einschließlich Proxy)
  • Vorfälle lokaler Netzwerküberlastung oder Bandbreitensättigung
  • Grund für die Priorität: Dadurch konzentriert sich die Untersuchung auf bestimmte Zeitpunkte, was weitaus effizienter ist als das Durchsuchen von Protokollen über mehrere Tage hinweg. Dies muss erfolgen, bevor externe Parteien hinzugezogen werden.

6. Überprüfung der Leistung von Firewall und Sicherheitsgeräten

  • Maßnahme: Überprüfen Sie während der Zeitfenster, in denen das Problem auftrat, die Firewall-/Proxy-Protokolle auf blockierte TCP-/UDP-Verbindungen und kontrollieren Sie die Ressourcen der Geräte (CPU, RAM, Verbindungen). Stellen Sie außerdem sicher, dass alle erforderlichen Tulip-IP-Adressen und -Domains derzeit auf der Whitelist stehen und keiner übermäßig aggressiven Überprüfung unterliegen, die zu zusätzlicher Latenz führen könnte. Achten Sie auf proxyspezifische Kennzahlen wie Verbindungslimits, gleichzeitige Sitzungen und durch Deep Packet Inspection verursachte Latenz.
  • Grund für die Priorität: Sicherheitsgeräte stellen häufig einen Engpass dar. Hiermit wird sowohl auf explizite Blockierungsregeln als auch auf Leistungseinbußen durch überlastete Hardware oder eingreifende Überprüfungsrichtlinien geprüft.

7. Konfiguration der Dienstgüte (Quality of Service, QoS) überprüfen

  • Maßnahme: Wenn Sie QoS-Richtlinien implementiert haben, überprüfen Sie, wie der Datenverkehr zu und von den Diensten der Anwendung kategorisiert wird. Stellen Sie sicher, dass er nicht versehentlich herabgestuft wird.
  • Grund für die Priorität: Eine fehlerhafte QoS-Konfiguration ist eine spezifische und oft übersehene Ursache für Probleme mit der Anwendungsleistung, insbesondere in Zeiten hoher Netzwerkaktivität.

8. Analyse der Gesamtbandbreite und der SNMP-Daten

  • Maßnahme: Überprüfen Sie die standortweite Spitzenbandbreitennutzung und kontrollieren Sie die SNMP-Daten von Routern/Switches auf hohe Auslastung oder Fehler während der Problemzeiten.
  • Grund für die Priorität: Dadurch lässt sich feststellen, ob das Problem mit der Gesamtkapazität des Netzwerks oder mit Überlastung zusammenhängt.

9. Netzwerkpfad des Internetdienstanbieters analysieren

  • Maßnahme: Wenden Sie sich an Ihren Internetdienstanbieter (ISP) und teilen Sie ihm die genauen Zeitstempel der hohen Latenz mit.
  • Spezifische Hinweise für den Internetdienstanbieter: Bitten Sie ihn, nach suboptimalem Routing, Überlastung an Peering-Punkten, Paketverlusten/erhöhter Latenz auf seinen Segmenten oder Transitpfaden sowie nach relevanten Netzwerkrichtlinien zu suchen , die zu diesen bestimmten Zeitpunkten aktiv waren.
  • Grund für die Priorität: Hier ist ein externer Partner beteiligt, und die Zusammenarbeit ist am effektivsten, wenn Sie ihm präzise Daten und Zeitstempel aus Ihrer internen Untersuchung zur Verfügung stellen können.

Phase 3: Vertiefte Analyse

Setzen Sie hochtechnische, ressourcenintensive Methoden ein, um die am schwersten aufzuspürenden Probleme zu finden.

10. Erweiterte eingehende Analyse auf Paketebene

  • Maßnahme: Führen Sie während eines Verzögerungsereignisses eine vollständige Paketaufzeichnung (pcap) auf einem betroffenen Rechner durch. Entscheidend ist dabei die gezielte Korrelation von Zeitstempeln über alle Analyseebenen hinweg. Analysieren Sie die Aufzeichnung auf Paketmanipulationen (z. B. TTL-Änderungen), Protokollfehler (TCP-Wiederholungsübertragungen) oder spezifische ICMP-Fehlermeldungen.
  • Grund für die Priorität: Dies ist der komplexeste Schritt. Er liefert die endgültige „Ground Truth“, ist jedoch nur dann vorgesehen, wenn alle anderen Untersuchungen die Ursache nicht ermitteln konnten.