Sophos Switch diagnostizieren: Logs und Supportdaten sichern

Eine gute Switch-Diagnose beginnt nicht mit einem Neustart oder maximalem Logging. Dieses Runbook führt vom beobachteten Symptom über einen möglichst kleinen Test zu verwertbaren Belegen. Es behandelt keine vollständige Neuplanung von VLANs, Routing oder Netzwerkarchitektur.

Kurzablauf

1. Symptom und Erfolgskriterium mit der folgenden Tabelle präzisieren.
2. Identität und Grundzustand des Switches prüfen.
3. Zum Symptom passende Zähler vor jeder Änderung sichern.
4. Den kleinsten geeigneten Diagnosetest ausführen.
5. RAM- und Flash-Logs herunterladen; das Log-Level nur bei Bedarf befristet erhöhen.
6. Ergebnis mit dem Erfolgskriterium oder einem gesunden Vergleichsport abgleichen.
7. Temporäres Logging und Remote Assistance zurücknehmen und den Sollzustand kontrollieren.
8. Falls ungelöst, einen Supportfall eröffnen oder das redigierte Beweispaket an den bestehenden Fall anhängen.

Symptome zuerst präzisieren

Vor dem ersten Eingriff einmal vollständig festhalten:

• Beginn und Zeitbezug: erster und letzter beobachteter Zeitpunkt mit Datum und Zeitzone; dauerhaft oder sporadisch;
• Auswirkung: vollständiger Ausfall, Paketverlust, geringe Datenrate, fehlende PoE-Versorgung, fehlende Fusion-Synchronisierung oder nur eine Warnung;
• Umfang: Switch-Seriennummer, Standort, Port, VLAN, angeschlossenes Gerät und Zahl der betroffenen Benutzer oder Dienste;
• Änderung davor: Konfigurations-, Verkabelungs-, Firmware-, Strom- oder Topologieänderung samt Zeitpunkt;
• Reproduktion: konkreter Startpunkt, Ziel, erwartetes Ergebnis, tatsächliches Ergebnis und Häufigkeit;
• Workaround: ob ein anderer Port, Pfad oder eine andere Stromversorgung funktioniert;
• Geschäftsauswirkung: betroffene Standorte und Dienste sowie verfügbare Redundanz.

Den Zeitraum nicht nachträglich aus dem Gedächtnis runden. Exakte Zeiten verbinden Benutzerbeobachtung, Portzähler, Ereignislog, Fusion-Kommunikation und Supportdaten.

Symptom zum ersten Prüfpunkt zuordnen

Ein einzelner Messwert beweist noch keine Ursache. Beispielsweise zeigt ein erreichbares Ping-Ziel nur die Erreichbarkeit für diesen Testzeitpunkt und -pfad. Zähler deshalb in einem definierten Zeitfenster oder gegen einen bekannten gesunden Vergleichsport bewerten.

Zugriff und Rechte klären

Für die zentrale Diagnose muss das Sophos-Fusion-Konto den richtigen Tenant, also die richtige Kundenumgebung, und dort My Products > Switches erreichen. Lesezugriff genügt zum Erfassen sichtbarer Zustände; Änderungen an Log settings, Remote assistance oder anderen Einstellungen erfordern passende Schreibrechte. Fehlt eine Schaltfläche, zuerst Tenant, Gerätezuordnung und Administratorrolle prüfen statt die Rolle pauschal zu erweitern.

Berichte aus Diagnostics öffnen die lokale Admin-Konsole. Dafür muss der Admin-Client den Switch im selben Subnetz erreichen. Eine lokale Anmeldung verwendet ein separates lokales Switch-Konto, nicht automatisch die Sophos ID oder Fusion-Rolle.

Grundzustand in Sophos Fusion prüfen

Den Switch unter My Products > Switches > Switches öffnen und für jeden Fall nur den Pflichtsatz erfassen:

• Serial no., Model, Name, MAC Address und Firmwareversion;
• State, Zeitpunkt des letzten Events und die letzten Kommunikationsereignisse unter System details;
• Zahl und Inhalt der Alerts;
• offene oder fehlgeschlagene Einträge in der Task queue, der Warteschlange für Fusion-Aufträge;
• unter System time den SNTP status (Status der Netzwerk-Zeitsynchronisierung), primäre und sekundäre NTP-Server samt Ports, Timezone und Sommerzeit-Einstellungen;
• Configuration source, also ob die betreffende Einstellung lokal oder zentral verwaltet wird.

Nur symptomabhängig ergänzen: Powered on bei Neustarts, Connection usage bei Verbindungsproblemen, Standort und Tags zur Zuordnung, Parent-Site beziehungsweise Parent-Stack als übergeordnete Standort- oder Stack-Zuordnung sowie verfügbares und aktuell geliefertes PoE-Gesamtbudget bei einem Stromversorgungsproblem.

Zeitstempel nur korrelieren, wenn Zeitzone, Sommerzeitregel und eine beobachtete Abweichung bekannt sind. System time ist kein Beleg für eine sichtbare aktuelle Switch-Uhrzeit. Einen aktuellen Switch-Zeitwert nur aus einem zeitgestempelten Switch-Log beziehungsweise -Event oder einer für Modell und Firmware unabhängig verifizierten lokalen Ansicht erfassen. Eine bekannte Abweichung dokumentieren und die Zeitkonfiguration erst nach der ersten Log-Sicherung korrigieren, sofern das Change-Verfahren dies erlaubt.

Fusion-Zustände einordnen

Sophos Fusion zeigt lokal konfigurierte Werte nur, wenn sie synchronisiert oder in Fusion repliziert wurden. Eine unauffällige zentrale Ansicht schliesst eine lokale Abweichung daher nicht aus. Seite, Feld, Wert und Configuration source zusammen dokumentieren. Danach nur den zum Symptom passenden Zweig bearbeiten.

Diagnoseansichten gezielt einsetzen

Im ausgewählten Switch öffnen die Verknüpfungen unter Diagnostics lokale Berichte in einem neuen Browserfenster. Schlägt nur dieses Öffnen fehl, zuerst die Voraussetzung „gleiches Subnetz“ prüfen; daraus nicht unmittelbar einen Switchausfall ableiten. Open local switch management öffnet auf demselben Weg die lokale Switch-Oberfläche.

Ressourcen, Ports und Adresstabelle

• Resource Usage öffnet lokal Monitor > Realtime Meters und zeigt CPU- und Speichernutzung in Echtzeit. Werte während des Symptoms mit einem unauffälligen Zeitraum vergleichen; ein Einzelwert bleibt eine Beobachtung, keine Ursachenbestätigung.
• MAC Address Table öffnet lokal Monitor > Dynamic MAC Address und Monitor > Static MAC Address. Entspricht die Zuordnung nicht dem erwarteten Port oder VLAN, zuerst Gegenstelle und vorgesehenen Pfad prüfen; andernfalls zum nächsten symptomrelevanten Zweig wechseln.
• Port Statistics öffnet lokal Monitor > Statistics > Ports mit eingehenden und ausgehenden Paketzählern sowie TX- und RX-Fehlern je Port.

Für einen Portfehler den betroffenen Port und einen funktionierenden Vergleichsport lokal erfassen. Im zentralen Management des ausgewählten Switches zusätzlich unter Statistics > Port die Werte RX discard und TX discard für beide Ports sichern. Discard-Werte nur dann einer lokalen Ansicht entnehmen, wenn diese für das eingesetzte Modell und die Firmware unabhängig verifiziert wurde. Nach einem kurzen Testintervall dieselben Werte erneut erfassen und nur die Veränderung im gleichen Zeitfenster vergleichen; kumulative Zähler nicht als momentane Rate ausgeben.

Steigen Fehler- oder Discard-Zähler nur am betroffenen Port, Kabel, Gegenstelle sowie MAC- und VLAN-Zuordnung zuerst dort eingrenzen. Bleiben sie unverändert, nicht allein daraus einen Portdefekt ableiten, sondern den nächsten zur beobachteten Auswirkung passenden Pfad prüfen. Im zentralen Switch-Management stehen dafür unter Statistics zusätzlich L2, L3, 802.1X security, Port und RMON bereit, etwa für beobachtete ungültige BPDUs, verworfene DHCP-Nachrichten oder CRC-Alignment-Fehler.

PoE, Kabel und SFP

• PoE Power Usage öffnet lokal Monitor > Dashboard > PoE Power Settings. Gesamtbudget und Werte für Strom, Spannung und Leistungsaufnahme nur für den betroffenen Port mit einem erwarteten oder funktionierenden Gerät vergleichen.
• Cable Diagnostics öffnet Analyze > Diag Tools. Nur den bekannten Zielport auswählen und Test wählen.
• SFP Module Info öffnet Monitor > SFP Module Information und zeigt die vom Modul bereitgestellten Fähigkeiten und Angaben.

Vor einem Kabeltest prüfen, ob er einen produktiven Link oder den eigenen Managementpfad beeinflussen kann, und Portzähler sowie Linkzustand sichern. Resultat mit Port, Gegenstelle, Kabelstrecke und Testzeit dokumentieren. Weicht nur dieser Pfad vom Vergleich ab, Kabel, Gegenstelle oder Modul gezielt weiter eingrenzen; ein Resultat nicht auf andere Ports übertragen. Bleiben die Beobachtungen gleich, zum nächsten symptomrelevanten Zweig wechseln.

Ping und Traceroute

Network Diagnostics führt lokal zu Analyze > Ping Test und Analyze > Trace Route. Ping prüft die Erreichbarkeit vom Switch aus; Traceroute beobachtet den Layer-3-Pfad.

Für diesen Test zusätzlich festhalten:

• Ziel-IP oder aufgelösten Zielnamen;
• erwarteten Pfad und erwartete Erreichbarkeit;
• Startzeit;
• vollständiges Ergebnis einschliesslich Verlust oder Abbruchstelle.

Zuerst ein bekannt erreichbares Ziel im relevanten Pfad prüfen, danach das Fehlerziel. Erreicht bereits das Vergleichsziel sein Soll nicht, zuerst den gemeinsamen lokalen Pfad untersuchen. Ist nur das Fehlerziel betroffen, an der beobachteten Abweichung weiterarbeiten. Keine beliebigen Internetziele als Beweis für einen internen VLAN- oder Routingfehler verwenden.

Ereignisse und Logs sichern

Event Logging öffnet lokal Monitor > Local Logging für die Ereignisauswahl und Monitor > Log Table für die Einträge. Unter Diagnostics > RAM logs und Diagnostics > Flash logs stehen die jeweiligen Logs mit Download bereit.

• RAM logs enthalten die jüngsten Einträge und gehen bei Neustart oder Ausschalten verloren. Bei einer aktuellen oder gerade reproduzierten Störung sofort herunterladen.
• Flash logs bleiben über Neustart und Ausschalten erhalten. Ausführliches Logging erhöht jedoch die Schreibbelastung.

Volle Logs überschreiben die ältesten Einträge. Deshalb beide Speicher vor weiteren Wiederholungsversuchen sichern.

Log-Level kontrolliert ändern

Unter Diagnostics > Log settings lassen sich benutzerdefinierte Einstellungen ein- oder ausschalten; Not set verwendet die lokale Switch-Einstellung. Die Schweregrade lauten von höchster zu niedrigster Priorität: Emergency (0), Alert (1), Critical (2), Error (3), Warning (4), Notice (5), Info (6) und Debug (7). Ein gewähltes Level schliesst alle höheren Schweregrade ein. Standard für Flash ist Critical.

Nur wenn die vorhandenen Logs das benötigte Ereignis nicht zeigen:

1. Ausgangswerte von custom Log settings, RAM log level und Flash log level erfassen und vorhandene RAM- und Flash-Logs herunterladen.
2. Ein enges Reproduktionsfenster, Abbruchkriterium und verantwortliche Person festlegen.
3. Nur das nötige Level wählen, mit Update speichern und den Aktivierungszeitpunkt notieren. Debug, besonders für Flash, so kurz wie möglich halten.
4. Fehler einmal kontrolliert reproduzieren und RAM- sowie Flash-Logs erneut herunterladen.
5. Sofort die dokumentierten Ausgangswerte wiederherstellen, mit Update speichern, die Seite neu laden und Level sowie On-/Off-/Not-set-Zustand prüfen.

Bei wachsender Auswirkung, Managementverlust oder ungeplantem Dienstabbruch den Test stoppen und die Ausgangswerte wiederherstellen. Ausführliches Flash-Logging nicht bestehen lassen, da die höhere Ereignismenge übermässigen Geräteverschleiss verursachen kann.

Supportfunktionen mit Nebenwirkungen

Sophos error reporting und Remote Assistance

Sophos error reporting ist standardmässig aktiviert. Bei Firmware-Upgradefehlern, Backupfehlern, Trennen und Wiederverbinden des Switches sowie fehlgeschlagener Task-Synchronisierung sendet es Agent-Logs an Sophos Fusion. Laut Funktionsbeschreibung betreffen diese Logs die Kommunikation zwischen Switch und Fusion; sie enthalten keine Konfigurations- oder Netzwerkdaten.

Remote assistance unter Diagnostics nur für einen bestehenden Supportfall freigeben: Case-Nummer, Zweck, Freigabe und Ansprechpartner dokumentieren, die kürzeste geeignete Gültigkeitsdauer wählen, Activate anklicken und Start sowie Ablauf im Case notieren. Nach der Sitzung Deactivate wählen und den angezeigten Status prüfen.

Nur auf Supportanweisung

Diese Aktionen verändern den Diagnosezustand und sind keine allgemeinen Reparaturschritte:

• Take a switch snapshot führt Systembefehle aus; deren Ausgabe erscheint in der Task queue.
• Restart Sophos Fusion agent startet die Fusion-Agent-Prozesse auf dem Switch neu.
• Clear core files löscht Core-Dateien, die beim Nichtreagieren von Prozessen entstanden sind, um Speicherplatz freizugeben.

Vor jeder Aktion Case-Nummer, Supportanweisung, Zeitpunkt, Vorzustand und erwartetes Ergebnis notieren. Vor Clear core files bestätigen lassen, dass diese Belege nicht mehr benötigt werden.

Beweispaket erstellen und redigieren

Originaldateien unverändert in einem zugriffsbeschränkten Arbeitsordner aufbewahren. Für die Weitergabe eine Kopie erstellen und Bearbeitungsschritte protokollieren. Dieses Paket ist die vollständige Übergabe an Support und enthält:

1. Fallübersicht: Fehlerbeschreibung, aktuelle Auswirkung, Beginn mit Zeitzone, Reproduktionsschritte, erwartetes und tatsächliches Ergebnis, Workaround und Geschäftsauswirkung.
2. Geräteidentität: Modell, Seriennummer, Firmware, Fusion-Agent-Version, Standort, Parent, Managementstatus und Laufzeit.
3. Zeitbasis: SNTP-Status, NTP-Server samt Ports, Zeitzone, Sommerzeit-Einstellungen, Konfigurationsquelle und bekannte Abweichung. Einen aktuellen Switch-Zeitwert nur aus einem zeitgestempelten Switch-Log beziehungsweise -Event oder einer unabhängig verifizierten lokalen Ansicht beilegen.
4. Statusbelege: Alarme, letzter Kontakt, Task-Details, betroffene Ports, VLANs und Konfigurationsquelle.
5. Tests und Messdaten: Ziel und Zeitpunkt, vollständiges Resultat sowie Vorher-/Nachher-Zähler; je nach Symptom Ping, Traceroute, Kabel, PoE, SFP oder Ressourcen.
6. Logs: RAM- und Flash-Downloads vor beziehungsweise nach der Reproduktion mit Dateiname und Erfassungszeit.
7. Änderungsprotokoll: jede Diagnoseänderung, Start, Ende, Ergebnis und bestätigte Rücknahme; noch aktive Freigaben wie Remote Assistance samt Ablaufzeit deutlich markieren.
8. Einordnung: beobachtete Fakten klar von Interpretation oder Verdacht trennen und redigierte beziehungsweise pseudonymisierte Inhalte ausweisen.

Vor dem Upload Passwörter, Session-Tokens, API-Bearer-Token, private Schlüssel, SNMP-Communitys und andere nicht benötigte Geheimnisse aus Kopien entfernen; kompromittierte Werte widerrufen oder ändern. Personenbezogene und geschäftsfremde Daten auf das nötige Mass reduzieren.

IP-, MAC-, Port- und Gerätenamen können für die Pfadkorrelation erforderlich sein. Bei einer Pseudonymisierung im ganzen Paket stabile Platzhalter wie CLIENT-A und SWITCH-UPLINK-1 verwenden. Zeitstempel, Zeitzone, Fehlercodes, Zähler und benötigte Beziehungen erhalten. Das unveränderte Original intern aufbewahren, damit eine Redigierung nicht mit einem Gerätefehler verwechselt wird.

An Sophos Support eskalieren

Persönlicher Support und Advanced RMA setzen eine passende Switch Support and Services Subscription pro eingesetztem Switch voraus. Vor der Eskalation den Status prüfen; Details erklärt Wie wird Sophos Fusion lizenziert?. Die lokale Weboberfläche und CLI bleiben davon getrennte Verwaltungswege. Für den Supportfall ist eine Sophos ID mit Zugriff auf den Kunden beziehungsweise Tenant nötig.

Sophos Support hilft bei Installation, Administration, Betrieb, dokumentationswidrigem Produktverhalten und allgemeinen Konfigurationsfragen; Implementierung oder Neueinrichtung gehören nicht zum normalen Supportumfang. Einen technischen Fall mit dem Sophos Support Assistant eröffnen:

1. Mit der Sophos ID anmelden, Problem beschreiben und diagnostische Fragen beantworten.
2. Den Assistant anweisen, bei Bedarf einen Case anzulegen.
3. Angaben prüfen und absenden. Erst wenn eine Case-Nummer erscheint, ist der Fall erstellt.
4. Das Beweispaket und alle weiteren Reproduktionen unter dieser Case-Nummer führen.

Der Support Assistant kann Hinweise und Ressourcen liefern. Eine vorgeschlagene Änderung trotzdem gegen Wartungsfenster, Auswirkung und Rücknahme prüfen. Keine parallelen Cases für dasselbe Ereignis eröffnen. Neue Reproduktionen, höhere Auswirkungen oder weitere Belege dem bestehenden Fall mit genauem Zeitpunkt hinzufügen. Als weitere offizielle Wege stehen Support Portal, Chat und Telefon zur Verfügung; regionale Telefonnummern und Verfügbarkeiten im Sophos-Kontaktbereich prüfen.

Grenze zwischen Supportfall und RMA

Ein nicht erreichbarer Switch, ein fehlerhafter Port oder ein wiederholter Neustart ist noch kein bestätigter Hardwaredefekt. Zuerst Stromversorgung, Verkabelung, Gegenstelle, Firmware- und Synchronisierungszustand sowie Logs dokumentieren. Sophos Support entscheidet nach der Prüfung, ob ein Hardwareaustausch eröffnet wird.

Den Switch davor nicht ungeplant zurücksetzen, öffnen, entsorgen oder versenden. Factory Reset und das Löschen von Core-Dateien können Belege vernichten. Bestätigt Support einen Defekt, Seriennummer, Modell, Supportstatus, Lieferadresse, Datenschutzrisiko und schriftliche Rückgabeanweisung in Sophos Hardwaredefekt und RMA vorbereiten übergeben. Garantie, Supportabdeckung und Advance Hardware Replacement werden dort getrennt geprüft.

Abschlussprüfung und sichere Rücknahme

Zum Abschluss nur den tatsächlichen Betriebs- und Diagnosezustand kontrollieren:

• temporäre RAM-/Flash-Level und custom Log settings entsprechen wieder dem dokumentierten Vorzustand;
• Remote assistance ist deaktiviert oder der genehmigte Ablauf bestätigt, Sophos error reporting gegen den Vorzustand geprüft;
• Managementzugang, Ports, PoE-Geräte und Uplinks befinden sich im erwarteten Zustand;
• die Task queue enthält keinen durch die Diagnose erzeugten unbehandelten Fehler und die Konfigurationsquelle wurde nicht unbeabsichtigt geändert;
• das Erfolgskriterium wurde aus Benutzer- und Netzsicht erneut getestet;
• bei offenem Fehler sind Beobachtungsfenster und nächster Eskalationspunkt festgelegt.

„Nicht reproduzierbar“ ist kein erfolgreicher Fix. Lässt sich eine temporäre Änderung nicht vollständig zurücknehmen, Auswirkung dokumentieren, Change-Verantwortliche informieren und mit dem unabhängigen Managementweg beziehungsweise dem abgestimmten Wiederherstellungsablauf fortfahren.