SFP und SFP+ für Sophos Firewall auswählen und prüfen

Bleibt ein SFP-Port auf Unplugged, flappt der Link oder erreicht er nicht die erwartete Geschwindigkeit, liegt die Ursache meist vor der Firewall-Regel: Porttyp, Transceiver, Faser, Gegenstelle oder Link-Aushandlung passen nicht zusammen.

Die schnellste Prüfung folgt dieser Reihenfolge:

1. Appliance-Modell und Hardware-Port bestimmen: SFP, SFP+, QSFP oder Flexi Port.
2. Unterstützte Geschwindigkeit und Transceiver-Kompatibilität für genau diesen Port prüfen.
3. Transceiver, Faser beziehungsweise DAC und Modul der Gegenstelle abgleichen.
4. Unter Network > Interfaces Link Mode, Auto-Negotiation und FEC kontrollieren.
5. Auf Anforderung des Sophos Supports lesende Diagnosedaten aus der Advanced Shell sichern.
6. Faser, Modul und Gegenstellenport einzeln gegen bekannte, funktionierende Komponenten tauschen.
7. Erst bei stabilem physischem Link VLAN, LAG, IP-Konfiguration, Routing und Firewall-Regeln untersuchen.

Port und Transceiver passend auswählen

SFP, SFP+ und Dual Rate unterscheiden

SFP steht typischerweise für 1 GbE, SFP+ für 10 GbE. Das Pluszeichen ist deshalb relevant: Ein 10G-SFP+-Modul funktioniert nicht in einem reinen 1G-SFP-Port. Umgekehrt unterstützt nicht jeder SFP+-Port automatisch 1-Gbit/s-SFPs.

Einige SFP+-Ports oder Flexi-Port-Module sind Dual Rate und unterstützen 1 sowie 10 GbE. Das darf aber nur für den konkreten Port angenommen werden, wenn Modellhandbuch oder Kompatibilitätsmatrix es bestätigen. Bei grösseren Appliances kommen zusätzlich QSFP-, QSFP+- oder Breakout-Ports hinzu; auch dort müssen Portmodus, Modul und Geschwindigkeit zusammenpassen.

Wie ein unterstützter QSFP- oder FleXi-Port in zwei oder vier Member aufgeteilt, neu gestartet und danach abgenommen wird, erklärt Breakout-Interfaces auf Sophos Firewall konfigurieren.

Die aktuelle Modell- und Transceiver-Matrix ist im Sophos Firewall Config Studio unter Backup-restore compatibility verfügbar. Dort vor Beschaffung oder Umbau Appliance, Flexi-Port-Modul, Portstandard und Transceiver prüfen. Diese dynamische Matrix ist verlässlicher als eine statische Kompatibilitätsliste in diesem Artikel.

Ein nicht gelisteter Drittanbieter-Transceiver kann technisch funktionieren, ist damit aber nicht automatisch von Sophos getestet oder supportet. Einen allgemeinen CLI-Befehl, der einen inkompatiblen SFP freischaltet, gibt es nicht. Für produktive Uplinks sollte deshalb ein geprüftes Modul und ein bekannter Ersatz verfügbar sein.

Bei SG- und XG-Appliances wird der 1-Gbit/s-Betrieb in einem 4-Port-10G-Flexi-Port-Modul nur mit Intel-codierten Transceivern unterstützt. Ein anderer Drittanbieter-Transceiver oder aktiver beziehungsweise passiver DAC mit ähnlicher Codierung kann funktionieren, diese Kombination wurde von Sophos jedoch nicht getestet. Ein erkannter Link belegt daher keinen Support.

Für die dokumentierten 40G-Kombinationen von SG und XG werden QSFP+-Module mit Cisco-, generischer oder anderer Nicht-Intel-Codierung nicht unterstützt. Sophos empfiehlt QSFP+-Glasfaserverbindungen; ein 40G-zu-4x10G-Breakout-Kabel wird am 2-Port-40G-Flexi-Port-Modul nicht unterstützt. Dieselbe Breakout-Einschränkung und Glasfaserempfehlung gelten für die dokumentierten XGS-Appliance-40G-Kombinationen.

Vor einer optischen 100G-Verbindung das Leistungsbudget anhand der konkreten Module und Faser berechnen. Beim gelisteten LR4-WDM-Modul kann eine direkte Verbindung auf jeder Faser eine Dämpfung erfordern; einen Dämpfer nie ohne Modulspezifikationen und berechnetes oder gemessenes Budget auswählen.

Optischen Pfad und Gegenstelle abgleichen

Bei Glasfaser müssen beide Enden denselben Übertragungsstandard verwenden. Vor dem Einstecken prüfen:

• Singlemode oder Multimode
• Geschwindigkeit und Standard, beispielsweise 1G-SX/LX oder 10G-SR/LR
• Wellenlänge und unterstützte Distanz
• Anschluss und passende Patchfaser
• bei zwei Fasern korrekte TX-/RX-Polarität
• bei BiDi-Modulen das zusammengehörende Wellenlängenpaar
• kompatibles Modul und aufeinander abgestimmte Portparameter an der Gegenstelle

Als grobe Orientierung stehen SX und SR meist für kurze Multimode-Strecken, LX und LR meist für längere Singlemode-Strecken. Massgebend bleiben jedoch immer die Angaben des konkreten Transceivers und der Gegenstelle.

Ein typisches 10-Gbit/s-Beispiel für eine kurze Verbindung besteht aus kompatiblen 10G-SR-Transceivern an beiden Enden und einer zur Distanz passenden Multimode-Faser. Ein 10G-LR-Modul auf der einen und ein 10G-SR-Modul auf der anderen Seite passen trotz gleicher Geschwindigkeit nicht zusammen.

Bei DAC oder AOC müssen Kabeltyp, Länge, Portstandard und beide Geräte unterstützt sein. Ein mechanisch passendes Kabel garantiert noch keinen Link.

⚠️ Lasersicherheit: Nie direkt in einen eingeschalteten Transceiver oder ein offenes Faserende schauen. Schutzkappen erst beim Anschliessen entfernen und verschmutzte Stecker mit geeignetem Glasfaserwerkzeug reinigen.

Port in SFOS konfigurieren

In SFOS 22.0 das physische Interface unter Network > Interfaces bearbeiten und Advanced settings > Port settings öffnen. Je nach Appliance erscheinen:

• Link mode: Geschwindigkeit und Duplex
• Auto-negotiation for media type: automatische Aushandlung mit der Gegenstelle
• Forward Error Correction (FEC): Fehlerkorrektur für unterstützte schnelle Ports
• Show recommended settings: empfohlene Werte für den gewählten Portmodus anzeigen
• Load recommended configuration: diese Werte übernehmen

Geschwindigkeit, Duplex, Auto-Negotiation und FEC müssen auf beiden Seiten kompatibel sein. Ein Mismatch kann Link-Abbrüche, Fehler, Latenz oder schlechte Performance verursachen. Bei 25-, 50- und 100-Gbit/s-Ports zuerst den Link Mode speichern, das Interface erneut öffnen und danach die empfohlene Konfiguration laden.

Bei den 4-Port-SFP+- und 2+2-Flexi-Port-Modulen der 1U-Appliances XGS 2100, 2300, 3100 und 3300 müssen alle SFP+-Ports des Moduls mit derselben Geschwindigkeit betrieben werden. Diese Einschränkung gilt nicht pauschal für jeden festen SFP+-Port oder jedes XGS-Appliance-Modell. Wird ein dafür ausgewiesener Transceiver unter 10 Gbit/s betrieben, an beiden Enden eine feste Geschwindigkeit einstellen, um Aushandlungsfehler zu vermeiden.

⚠️ Eine Änderung am Uplink kann den Traffic und den WebAdmin-Zugang sofort unterbrechen. Für produktive WAN-, Core- oder HA-Verbindungen sind ein Wartungsfenster und ein alternativer Adminzugang erforderlich. Vorher die bisherigen Einstellungen und die Verkabelung dokumentieren. Kommt mit den neuen Einstellungen kein stabiler Link zustande, über diesen Zugang das ursprüngliche Modul oder Kabel und die bisherigen Portwerte wiederherstellen und den Traffic prüfen, bevor das Wartungsfenster endet.

Nach dem Speichern unter Network > Interfaces den Hardware-Namen und Status prüfen. Connected bestätigt den physischen Link, aber noch keine korrekte VLAN-, LAG-, IP- oder Policy-Konfiguration. Das Zusammenspiel von Interface, Zone und Regeln erklärt Sophos Firewall Zonen und Interfaces richtig planen.

Link und Modul über die CLI lesen

Hardware-Namen ermitteln

Für die folgenden Befehle wird der Hardware-Name benötigt, nicht der frei vergebene Anzeigename. Er steht unter Network > Interfaces und kann beispielsweise PortF1, PortA1 oder Port1 lauten.

Alternativ zeigt die Device Console die Interfaces:

show network interfaces

Die folgenden Befehle mit ethtool und dmesg laufen unter Device Management > Advanced Shell, nicht in der Device Console. Sie sind ergänzende, lesende Diagnosen und keine dokumentierte, stabile SFOS-CLI-Schnittstelle. Nur auf Anforderung des Sophos Supports ausführen; Verfügbarkeit und Ausgabe können je nach SFOS-Build, Appliance, Porttreiber und Modul abweichen. Die Ausgabe belegt weder Support noch Kompatibilität. Sophos Firewall per SSH verwalten erklärt den Konsolenkontext und den SSH-Zugang.

Link, Speed und Aushandlung prüfen

Beispiel für PortF1:

ethtool PortF1

Der Befehl verändert nichts. Eine gekürzte Ausgabe kann beispielsweise so aussehen:

Speed: 10000Mb/s
Duplex: Full
Auto-negotiation: on
Link detected: yes

In diesem Beispiel besteht ein physischer 10-Gbit/s-Link mit Full Duplex. Ob VLAN, IP-Konfiguration, Routing und Firewall-Regeln stimmen, ist damit noch nicht geprüft. Besonders relevant sind:

• Link detected: yes für einen erkannten physischen Link
• die erwartete Geschwindigkeit, beispielsweise Speed: 10000Mb/s
• Duplex: Full
• unterstützte und aktuell verwendete Link-Modi
• der Zustand von Auto-Negotiation

Diese Werte sind Indizien und müssen zur Gegenstelle passen. Link detected: yes beweist noch keinen funktionierenden Datenpfad. Umgekehrt beweist Speed: Unknown! nicht allein einen defekten Transceiver, weil Treiber und Porttyp die Ausgabe beeinflussen können.

Bleibt ein physisches oder LAG-basiertes XGS-Appliance-10G-Interface mit Auto-negotiation down, beschreibt LAG mit LACP einrichten und testen den weiterhin gelisteten Fehler NC-94073 und den offiziellen manuellen 10-Gbit/s-Workaround.

Transceiver-Daten und optische Werte auslesen

Das EEPROM des Moduls lässt sich, soweit Modul und Treiber es unterstützen, so lesen:

ethtool -m PortF1

Die Ausgabe kann unter anderem zeigen:

• Identifier und Anschluss
• Transceiver-Typ und Wellenlänge
• vorgesehene Faserlänge
• Hersteller, Part Number und Seriennummer
• Temperatur und Spannung
• optische Sende- und Empfangsleistung
• Alarm- und Warning-Grenzen

RX- und TX-Leistung nur gegen die vom konkreten Modul ausgegebenen Grenzwerte oder dessen Datenblatt bewerten. Pauschale dBm-Grenzen wären falsch, weil Standard, Distanz und Optik variieren.

Nicht jedes Modul stellt Digital Diagnostic Monitoring bereit. Eine leere Ausgabe oder Operation not supported bedeutet deshalb nur, dass EEPROM- beziehungsweise Diagnosedaten über diesen Treiber nicht verfügbar sind. Das beweist keinen Defekt. Umgekehrt beweisen lesbare Moduldaten noch keinen stabilen Link.

Die Ausgabe kann Hersteller- und Seriennummern enthalten. Vor einem öffentlichen Screenshot oder Ticket nicht benötigte Gerätedaten schwärzen.

Link-Flaps im Kernelpuffer suchen

Bei kurzen Unterbrüchen hilft eine lesende Suche in der Advanced Shell:

dmesg | grep PortF1

Wiederholte Link-up-/Link-down-Meldungen passen zu Faser-, Modul-, Gegenstellen- oder Aushandlungsproblemen. dmesg enthält nur den aktuellen Kernelpuffer und ersetzt kein langfristiges Monitoring.

Zustandsverändernde oder unterbrechende Varianten wie ethtool -s, ethtool -r oder EEPROM-Änderungen gehören nicht in eine normale Diagnose. Sie können den Link, den Adminzugang oder den Modulzustand verändern.

Fehlenden oder instabilen Link eingrenzen

Die Ergebnisse lassen sich so weiterverfolgen:

• Interface bleibt Unplugged: Porttyp, unterstützte Geschwindigkeit, Modulkompatibilität, Sitz des Transceivers, Faser, TX/RX-Polarität und Gegenstellenport prüfen.
• Moduldaten sind lesbar, aber der Link bleibt down: Gleichen Standard und dieselbe Geschwindigkeit an beiden Enden sicherstellen; Auto-Negotiation und FEC vergleichen. Danach Faser und Module einzeln gegen bekannte, funktionierende Komponenten tauschen.
• Link kommt nur sporadisch hoch: Stecker reinigen, Biegeradius und Temperatur prüfen, RX-/TX-Werte mit Modulgrenzen vergleichen und dmesg auf Flaps kontrollieren.
• Link ist up, aber langsam oder fehlerhaft: Ausgehandelten Speed und Duplex, Switch-Counter, optische Werte und FEC prüfen. Performance erst mit einem zweiten Testgerät bewerten, bevor die Firewall als Ursache gilt.
• Link ist stabil, aber kein Traffic fliesst: Jetzt VLAN-Tagging, LAG, Zone, IP-Adresse, Gateway, Routing und Firewall-Regeln prüfen. Für VLANs hilft Sophos Firewall VLAN einrichten und testen.

Immer nur eine Komponente auf einmal tauschen und das Ergebnis dokumentieren. So bleibt erkennbar, ob Modul, Faser, Firewall-Port oder Gegenstelle die Ursache war.

Wenn ein kompatibles Modul und eine bekannte, funktionierende Faser auch an einem korrekt konfigurierten Port keinen stabilen Link ergeben, Ausgaben, Zeitstempel, SFOS-Version, Appliance-Modell und verwendete Part Numbers sichern. Der weitere Support- und RMA-Ablauf steht unter Technischen Defekt einer Sophos Appliance prüfen.

Zum Prüfzeitpunkt war SFOS 22.0 MR2 Build 546 die neueste aufgeführte Version. Den aktuellen Firmwarestand und die aktuelle Fehlerprüfung beschreibt Sophos Firewall Firmware-Update planen und durchführen. Die folgenden Fehlerdetails entsprechen diesem Prüfstand. Eine beim Fehler genannte Version bezeichnet den von Sophos zugeordneten Build; sie belegt weder, dass nur dieser Build betroffen ist, noch dass spätere Builds den Fehler behoben haben.

Cisco Nexus 9000 an XGS 5500 bis 8500

Sophos führt unter NC-164102 eine konkrete Hardwarekombination: An den fest eingebauten 10-Gbit/s-Ports der XGS 5500, 6500, 7500 und 8500 kann die Verbindung zu einem Switch der Cisco-Nexus-9000-Serie verloren gehen oder wiederholt auf- und abbauen. Sophos nennt dafür weder eine betroffene SFOS-Version noch eine bestätigte Ursache oder Fehlerbehebung.

Der Eintrag spricht nur von den „10Gbit baseboard ports“ dieser 2U-Appliances. Einzelne Portbezeichnungen oder weitere Porttypen nennt er nicht; der Geltungsbereich darf deshalb nicht auf QSFP-Ports oder Flexi-Port-Module erweitert werden.

Passt die Umgebung genau zu dieser Kombination, zuerst die üblichen Ursachen mit den oben beschriebenen Prüfungen ausschliessen. Für die weitere Analyse Appliance-Modell, SFOS-Build, betroffenen Hardware-Port, Nexus-Modell, NX-OS-Version, Switch-Port sowie Hersteller und Part Number der Transceiver oder des DAC dokumentieren. Ausgaben von ethtool, ethtool -m und dmesg nur auf Anforderung des Sophos Supports sichern, dazu die Link-Events und Fehlerzähler des Switchports mit Zeitstempel. Im Supportfall auf NC-164102 verweisen.

Als mögliche Umgehung nennt Sophos ein 4-Port-10-Gbit/s-Flexi-Port-Modul anstelle der fest eingebauten 10G-Ports. Das ist keine garantierte Reparatur. Vor dem Umbau die Kompatibilität von Appliance, Modul und Transceivern im Config Studio prüfen sowie Wartungsfenster und alternativen Adminzugang vorbereiten. Bisherige Portkonfiguration und Verkabelung sichern; bleibt der neue Pfad instabil, den ursprünglichen Baseboard-Port wieder anschliessen, seine Einstellungen wiederherstellen und den Traffic prüfen.

Swisscom XGS-PON-GBIC an XGS Rev. 2

NC-168210 beschreibt für SFOS 21.5 GA Build 171 einen konkreten Schweizer Spezialfall: Das Swisscom-Modul ALL-BM410-XGSPON-GBIC wird in den 1-Gbit/s-SFP-Ports von XGS-Rev.-2-Appliances nicht unterstützt.

Sophos nennt einen 10-Gbit/s-SFP+-Port als Ausweichmöglichkeit, weist aber gleichzeitig darauf hin, dass das Modul dort nicht intern getestet wurde. Der Betrieb ist daher nicht garantiert. Für einen produktiven Anschluss gehören bestätigte Portkompatibilität, ein Wartungsfenster und eine alternative Provideranbindung in den Plan.

Der Fall zeigt den wichtigen Unterschied: Ein Modul kann möglicherweise einen Link aufbauen und trotzdem nicht als getestete, supportete Kombination gelten.