Przejdz do tresci
Avanet

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:

  1. Ustalić model appliance i port sprzętowy: SFP, SFP+, QSFP albo Flexi Port.
  2. Sprawdzić obsługiwaną prędkość i zgodność transceivera dokładnie dla tego portu.
  3. Porównać transceiver, włókno lub DAC oraz moduł urządzenia po drugiej stronie.
  4. W Network > Interfaces sprawdzić Link mode, Auto-negotiation i FEC.
  5. Odczytać stan łącza i modułu za pomocą ethtool, bez wprowadzania zmian.
  6. Osobno podmienić włókno, moduł i port po drugiej stronie na znane, sprawne komponenty.
  7. 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.

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. Ten widok jest lepszy niż statyczna lista w artykule, ponieważ obsługiwane modele i moduły mogą być aktualizowane.

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.

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

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 modułach Flexi Port w modelach XGS 2100, 2300, 3100 i 3300 wszystkie porty SFP+ tego samego modułu muszą być skonfigurowane z tą samą prędkością. Ograniczenie to nie dotyczy ogólnie każdego stałego portu SFP+ ani każdego modelu XGS.

⚠️ Zmiana uplinku może natychmiast przerwać łącze, a tym samym dostęp do WebAdmin. W przypadku produkcyjnych połączeń WAN, core lub HA potrzebne są okno serwisowe, alternatywny dostęp administracyjny oraz zapis poprzednich wartości na potrzeby powrotu.

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

Aby użyć ethtool, należy przejść do Device Management > Advanced Shell. Konsole i dostęp SSH są opisane w artykule Zarządzanie Sophos Firewall przez 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 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.

Swisscom XGS-PON-GBIC w XGS Rev. 2

Aktualna Sophos Known Issues List zawiera pod identyfikatorem NC-168210 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.