Dobór i diagnostyka SFP oraz SFP+ w Sophos Firewall

Jeśli port SFP pozostaje w stanie Unplugged, łącze ciągle się zrywa albo nie osiąga oczekiwanej prędkości, przyczyna zwykle występuje przed regułą zapory: typ portu, transceiver, włókno, urządzenie po drugiej stronie lub negocjacja łącza nie są ze sobą zgodne.

Najszybsza diagnostyka przebiega w następującej kolejności:

Ustalić model appliance i port sprzętowy: SFP, SFP+, QSFP albo Flexi Port.
Sprawdzić obsługiwaną prędkość i zgodność transceivera dokładnie dla tego portu.
Porównać transceiver, włókno lub DAC oraz moduł urządzenia po drugiej stronie.
W Network > Interfaces sprawdzić Link mode, Auto-negotiation i FEC.
Na żądanie wsparcia Sophos zebrać diagnostykę tylko do odczytu z Advanced Shell.
Osobno podmienić włókno, moduł i port po drugiej stronie na znane, sprawne komponenty.
Dopiero przy stabilnym łączu fizycznym analizować VLAN, LAG, konfigurację IP, routing i reguły zapory.

Dobór właściwego portu i transceivera

Rozróżnienie SFP, SFP+ i Dual Rate

SFP oznacza zwykle 1 GbE, a SFP+ — 10 GbE. Znak plus ma więc znaczenie: moduł 10G-SFP+ nie działa w porcie wyłącznie 1G-SFP. Z drugiej strony nie każdy port SFP+ automatycznie obsługuje moduły SFP 1 Gbit/s.

Niektóre porty SFP+ lub moduły Flexi Port działają w trybie Dual Rate i obsługują 1 oraz 10 GbE. Można to jednak założyć dla konkretnego portu tylko wtedy, gdy potwierdza to instrukcja modelu lub macierz zgodności. W większych appliances występują również porty QSFP, QSFP+ i Breakout; także w ich przypadku tryb portu, moduł i prędkość muszą być zgodne.

Konfiguracja interfejsów breakout w Sophos Firewall opisuje podział obsługiwanego portu QSFP lub FleXi na dwa albo cztery members, restart appliance i weryfikację wyniku.

Aktualna macierz modeli i transceiverów jest dostępna w Sophos Firewall Config Studio, w sekcji Backup-restore compatibility. Przed zakupem lub przebudową należy tam sprawdzić appliance, moduł Flexi Port, standard portu i transceiver. Ta dynamiczna macierz jest bardziej wiarygodna niż statyczna lista zgodności w artykule.

Transceiver innego producenta, którego nie ma na liście, może technicznie działać, ale nie oznacza to automatycznie, że został przetestowany lub jest wspierany przez Sophos. Nie istnieje ogólne polecenie CLI odblokowujące niezgodny moduł SFP. Dlatego dla produkcyjnych uplinków powinien być dostępny sprawdzony moduł oraz znany, sprawny moduł zapasowy.

W appliance SG i XG działanie z prędkością 1 Gbit/s w 4-portowym module Flexi Port 10G jest obsługiwane tylko z transceiverami kodowanymi jako Intel. Inny transceiver producenta trzeciego albo aktywny lub pasywny DAC o podobnym kodowaniu może działać, ale Sophos nie testował tej kombinacji. Wykryte łącze nie jest więc dowodem wsparcia.

W udokumentowanych kombinacjach SG i XG 40G moduły QSFP+ z kodowaniem Cisco, generycznym lub innym niż Intel nie są obsługiwane. Sophos zaleca połączenia QSFP+ przez światłowód, a kabel breakout 40G do 4x10G nie jest obsługiwany z 2-portowym modułem Flexi Port 40G. To samo ograniczenie breakout i zalecenie światłowodu dotyczą udokumentowanych kombinacji XGS Appliance 40G.

Przed zestawieniem optycznego połączenia 100G należy obliczyć budżet optyczny dla konkretnych modułów i włókna. W przypadku wymienionej jednostki LR4 WDM bezpośrednie połączenie może wymagać tłumienia na każdym włóknie; nie wolno dobierać tłumika bez specyfikacji modułu i obliczonego lub zmierzonego budżetu.

Porównanie toru optycznego i urządzenia po drugiej stronie

W przypadku światłowodu oba końce muszą używać tego samego standardu transmisji. Przed włożeniem modułu należy sprawdzić:

singlemode albo multimode
prędkość i standard, na przykład 1G-SX/LX albo 10G-SR/LR
długość fali i obsługiwany dystans
złącze i właściwy patchcord
przy dwóch włóknach prawidłową polaryzację TX/RX
przy modułach BiDi odpowiadającą sobie parę długości fal
zgodny moduł i dopasowane parametry portów po drugiej stronie

Orientacyjnie SX i SR zwykle oznaczają krótkie połączenia multimode, a LX i LR — dłuższe połączenia singlemode. Decydujące są jednak zawsze dane konkretnego transceivera i urządzenia po drugiej stronie.

Typowe krótkie połączenie 10 Gbit/s składa się ze zgodnych transceiverów 10G-SR na obu końcach oraz włókna multimode odpowiedniego dla danej odległości. Moduł 10G-LR po jednej stronie i 10G-SR po drugiej nie są zgodne, mimo tej samej prędkości.

W przypadku DAC lub AOC muszą być obsługiwane typ i długość kabla, standard portu oraz oba urządzenia. Mechanicznie pasujący kabel nie gwarantuje zestawienia łącza.

⚠️ Bezpieczeństwo lasera: Nie wolno patrzeć bezpośrednio w aktywny transceiver ani otwarte zakończenie włókna. Zaślepki należy zdejmować dopiero przy podłączaniu, a zabrudzone złącza czyścić odpowiednimi narzędziami do światłowodów.

Konfiguracja portu w SFOS

W SFOS 22.0 należy edytować interfejs fizyczny w Network > Interfaces i otworzyć Advanced settings > Port settings. W zależności od appliance dostępne są:

Link mode: prędkość i dupleks
Auto-negotiation for media type: automatyczna negocjacja z urządzeniem po drugiej stronie
Forward Error Correction (FEC): korekcja błędów dla obsługiwanych szybkich portów
Show recommended settings: wyświetlenie zalecanych wartości dla wybranego trybu portu
Load recommended configuration: zastosowanie tych wartości

Prędkość, dupleks, Auto-negotiation i FEC muszą być zgodne po obu stronach. Niezgodność może powodować zrywanie łącza, błędy, opóźnienia lub słabą wydajność. W przypadku portów 25, 50 i 100 Gbit/s należy najpierw zapisać Link mode, ponownie otworzyć interfejs, a następnie wczytać zalecaną konfigurację.

W 4-portowych modułach SFP+ i modułach Flexi Port 2+2 w appliance 1U XGS 2100, 2300, 3100 i 3300 wszystkie porty SFP+ modułu muszą pracować z tą samą prędkością. Ograniczenie to nie dotyczy ogólnie każdego stałego portu SFP+ ani każdego modelu XGS Appliance. Jeśli wskazany jako zgodny transceiver pracuje poniżej 10 Gbit/s, należy ustawić stałą prędkość po obu stronach, aby uniknąć niezgodności negocjacji.

⚠️ Zmiana uplinku może natychmiast przerwać ruch i dostęp do WebAdmin. W przypadku produkcyjnego połączenia WAN, core lub HA potrzebne są okno serwisowe i alternatywny dostęp administracyjny. Najpierw należy zapisać pierwotne ustawienia i schemat okablowania. Jeśli nowe ustawienia nie zapewnią stabilnego łącza, trzeba przez ten dostęp przywrócić pierwotny moduł lub kabel i poprzednie ustawienia portu, a przed zakończeniem prac sprawdzić ruch.

Po zapisaniu należy sprawdzić nazwę sprzętową i stan w Network > Interfaces. Connected potwierdza łącze fizyczne, ale jeszcze nie poprawną konfigurację VLAN, LAG, IP ani policy. Zależność między interfejsem, strefą i regułami opisuje artykuł Prawidłowe planowanie stref i interfejsów Sophos Firewall.

Odczyt łącza i modułu przez CLI

Ustalenie nazwy sprzętowej

Do kolejnych poleceń potrzebna jest nazwa sprzętowa, a nie dowolnie nadana nazwa wyświetlana. Jest widoczna w Network > Interfaces i może mieć na przykład postać PortF1, PortA1 albo Port1.

Interfejsy można też wyświetlić w Device Console:

show network interfaces

Poniższe polecenia ethtool i dmesg uruchamia się w Device Management > Advanced Shell, a nie w Device Console. Są to dodatkowe polecenia diagnostyczne tylko do odczytu, a nie udokumentowany i stabilny interfejs CLI SFOS. Należy je wykonywać wyłącznie na żądanie wsparcia Sophos; dostępność i wynik mogą zależeć od buildu SFOS, appliance, sterownika portu i modułu. Wynik nie potwierdza wsparcia ani zgodności. Artykuł Zarządzanie Sophos Firewall przez SSH wyjaśnia kontekst konsol i dostęp SSH.

Kontrola łącza, prędkości i negocjacji

Przykład dla PortF1:

ethtool PortF1

Polecenie nie wprowadza zmian. Skrócony wynik może wyglądać na przykład tak:

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

W tym przykładzie działa fizyczne łącze 10 Gbit/s w trybie Full Duplex. Nie potwierdza to jeszcze prawidłowej konfiguracji VLAN, IP, routingu ani reguł zapory. Szczególnie istotne są:

Link detected: yes oznaczające wykryte łącze fizyczne
oczekiwana prędkość, na przykład Speed: 10000Mb/s
Duplex: Full
obsługiwane i aktualnie używane tryby łącza
stan Auto-negotiation

Wartości te są wskazówkami i muszą odpowiadać konfiguracji po drugiej stronie. Link detected: yes nie dowodzi jeszcze, że ścieżka danych działa. Z drugiej strony samo Speed: Unknown! nie dowodzi uszkodzenia transceivera, ponieważ na wynik mogą wpływać sterownik i typ portu.

Jeżeli fizyczny albo oparty na LAG interfejs XGS Appliance 10G pozostaje down przy Auto-negotiation, artykuł Konfiguracja i testowanie LAG z LACP opisuje nadal widniejący błąd NC-94073 oraz oficjalny ręczny workaround dla 10 Gbit/s.

Odczyt danych transceivera i parametrów optycznych

EEPROM modułu można odczytać w następujący sposób, o ile obsługują to moduł i sterownik:

ethtool -m PortF1

Wynik może zawierać między innymi:

identyfikator i złącze
typ transceivera i długość fali
przewidzianą długość włókna
producenta, Part Number i numer seryjny
temperaturę i napięcie
optyczną moc nadawania i odbioru
progi alarmowe i ostrzegawcze

Moc RX i TX należy oceniać wyłącznie względem progów podawanych przez konkretny moduł lub jego kartę katalogową. Ogólne wartości graniczne w dBm byłyby błędne, ponieważ różnią się standard, dystans i optyka.

Nie każdy moduł udostępnia Digital Diagnostic Monitoring. Pusty wynik lub Operation not supported oznacza zatem tylko, że dane EEPROM albo dane diagnostyczne nie są dostępne przez ten sterownik. Nie dowodzi to uszkodzenia. Z drugiej strony możliwość odczytu danych modułu nie dowodzi jeszcze stabilności łącza.

Wynik może zawierać nazwę producenta i numery seryjne. Przed umieszczeniem publicznego zrzutu ekranu lub załączeniem go do zgłoszenia należy zamazać zbędne dane urządzenia.

Wyszukiwanie zerwań łącza w buforze jądra

Przy krótkich przerwach pomaga następujące polecenie tylko do odczytu w Advanced Shell:

dmesg | grep PortF1

Powtarzające się komunikaty link-up/link-down wskazują na problemy z włóknem, modułem, urządzeniem po drugiej stronie lub negocjacją. dmesg zawiera tylko bieżący bufor jądra i nie zastępuje długoterminowego monitoringu.

Warianty zmieniające stan lub przerywające działanie, takie jak ethtool -s, ethtool -r albo modyfikacje EEPROM, nie należą do zwykłej diagnostyki. Mogą zmienić stan łącza, dostęp administracyjny lub stan modułu.

Diagnostyka brakującego lub niestabilnego łącza

Wyniki można dalej analizować w następujący sposób:

Interfejs pozostaje w stanie Unplugged: sprawdzić typ portu, obsługiwaną prędkość, zgodność modułu, osadzenie transceivera, włókno, polaryzację TX/RX i port po drugiej stronie.
Dane modułu są czytelne, ale łącze pozostaje down: zapewnić ten sam standard i prędkość po obu stronach; porównać Auto-negotiation i FEC. Następnie osobno podmienić włókno i moduły na znane, sprawne komponenty.
Łącze zestawia się tylko sporadycznie: wyczyścić złącza, sprawdzić promień gięcia i temperaturę, porównać wartości RX/TX z progami modułu oraz skontrolować dmesg pod kątem flapów.
Łącze jest up, ale działa wolno lub z błędami: sprawdzić wynegocjowaną prędkość i dupleks, liczniki przełącznika, parametry optyczne i FEC. Najpierw ocenić wydajność przy użyciu drugiego urządzenia testowego, zanim uzna się zaporę za przyczynę.
Łącze jest stabilne, ale ruch nie przepływa: teraz sprawdzić tagowanie VLAN, LAG, strefę, adres IP, Gateway, routing i reguły zapory. W przypadku VLAN pomaga artykuł Konfiguracja i testowanie VLAN w Sophos Firewall.

Zawsze należy wymieniać tylko jeden komponent naraz i dokumentować wynik. Dzięki temu wiadomo, czy przyczyną był moduł, włókno, port zapory czy urządzenie po drugiej stronie.

Jeżeli zgodny moduł i znane, sprawne włókno nie zapewniają stabilnego łącza również na prawidłowo skonfigurowanym porcie, należy zabezpieczyć wyniki poleceń, znaczniki czasu, wersję SFOS, model appliance i używane Part Numbers. Dalszy proces supportu i RMA opisuje artykuł Diagnostyka usterki technicznej appliance Sophos.

W dniu przeglądu SFOS 22.0 MR2 Build 546 była najnowszą wymienioną wersją. Aktualny stan firmware i przegląd problemów opisuje artykuł Planowanie i przeprowadzanie aktualizacji firmware Sophos Firewall. Poniższe szczegóły problemów odzwierciedlają stan z tego przeglądu. Wersja podana przy problemie wskazuje build przypisany przez Sophos; nie dowodzi, że dotyczy to wyłącznie tej kompilacji ani że późniejsze kompilacje zawierają poprawkę.

Cisco Nexus 9000 z XGS 5500–8500

Sophos opisuje pod identyfikatorem NC-164102 konkretną kombinację sprzętową: na wbudowanych portach 10 Gbit/s urządzeń XGS 5500, 6500, 7500 i 8500 połączenie z przełącznikiem z serii Cisco Nexus 9000 może zostać utracone albo wielokrotnie zestawiać się i zrywać. Sophos nie podaje wersji SFOS, której dotyczy problem, ani potwierdzonej przyczyny czy poprawki.

Wpis mówi jedynie o „10Gbit baseboard ports” tych urządzeń 2U. Nie podaje oznaczeń poszczególnych portów ani innych typów portów, dlatego jego zakresu nie należy rozszerzać na porty QSFP ani moduły Flexi Port.

Jeżeli środowisko dokładnie odpowiada tej kombinacji, należy najpierw wykluczyć typowe przyczyny za pomocą opisanych wyżej testów. Do dalszej analizy trzeba udokumentować model appliance, kompilację SFOS, port sprzętowy, którego dotyczy problem, model Nexus, wersję NX-OS, port przełącznika oraz producenta i Part Number transceiverów lub DAC. Wyniki ethtool, ethtool -m i dmesg należy zebrać tylko na żądanie wsparcia Sophos, razem ze zdarzeniami łącza i licznikami błędów portu przełącznika ze znacznikami czasu. W zgłoszeniu do wsparcia należy powołać się na NC-164102.

Jako możliwe obejście Sophos wskazuje 4-portowy moduł Flexi Port 10 Gbit/s zamiast wbudowanych portów 10G. Nie jest to gwarantowana naprawa. Przed przebudową należy sprawdzić w Config Studio zgodność appliance, modułu i transceiverów oraz przygotować okno serwisowe i alternatywny dostęp administracyjny. Trzeba zapisać obecną konfigurację i schemat okablowania; jeśli nowa ścieżka nie będzie stabilna, ponownie podłączyć pierwotny port baseboard, przywrócić jego ustawienia i sprawdzić ruch.

Swisscom XGS-PON-GBIC w XGS Rev. 2

NC-168210 opisuje konkretny przypadek ze Szwajcarii dotyczący SFOS 21.5 GA Build 171: moduł Swisscom ALL-BM410-XGSPON-GBIC nie jest obsługiwany w portach SFP 1 Gbit/s urządzeń XGS Rev. 2.

Sophos wskazuje port SFP+ 10 Gbit/s jako rozwiązanie alternatywne, ale jednocześnie zaznacza, że moduł nie został tam wewnętrznie przetestowany. Działanie nie jest więc gwarantowane. W przypadku produkcyjnego łącza plan powinien obejmować potwierdzoną zgodność portu, okno serwisowe i alternatywne połączenie z operatorem.

Przypadek ten pokazuje ważną różnicę: moduł może potencjalnie zestawić łącze, a mimo to nie stanowić przetestowanej i wspieranej kombinacji.