Konfiguracja i testowanie LAG z LACP w Sophos Firewall

Link Aggregation Group (LAG) łączy od dwóch do czterech portów fizycznych w jeden interfejs logiczny. Active-Backup zapewnia redundancję z jednym aktywnym łączem. 802.3ad (LACP) korzysta równolegle z wielu łączy i zwiększa łączną przepustowość dla wielu połączeń.

Pojedyncze połączenie TCP lub UDP zwykle nie staje się szybsze dzięki LACP: algorytm hash utrzymuje jeden przepływ na jednym łączu członkowskim. Dodatkowa przepustowość pojawia się dopiero przy wielu połączeniach, które trafiają do różnych wyników hashowania.

Przygotowanie trybu i migracji

Active-Backup czy 802.3ad

Active-Backup to prosty tryb redundancji. Tylko jeden port członkowski przesyła ruch, a po jego awarii zadanie przejmuje inny. Switch nie wymaga w tym przypadku port-channel z LACP. Oba porty switcha muszą jednak używać tych samych VLAN-ów lub tej samej konfiguracji access, należeć do tej samej sieci warstwy 2 i akceptować zmianę adresu MAC podczas failover.

802.3ad (LACP) wykorzystuje wszystkie aktywne łącza do rozkładania obciążenia i failover. Obowiązują następujące wymagania:

• LACP jest aktywne na firewallu i switchu.
• Wszystkie porty członkowskie mają ten sam typ interfejsu, tę samą prędkość i Full-Duplex.
• Porty switcha należą do tego samego logicznego peera LACP i port-channel.
• Dwa fizyczne switche działają tylko wtedy, gdy stack, MLAG/MC-LAG lub porównywalna technologia przedstawia je jako wspólny system LACP.
• Konfiguracja VLAN/trunk oraz MTU są spójne na wszystkich portach członkowskich.

Dla samej redundancji Active-Backup jest zwykle prostszy. LACP jest odpowiedni, gdy wiele równoległych połączeń rzeczywiście potrzebuje większej łącznej przepustowości.

Sprawdzenie portów członkowskich i przygotowanie planu wycofania

Sophos Firewall zezwala na użycie od dwóch do czterech niepowiązanych interfejsów fizycznych ze statycznym przypisaniem adresu IP jako członków LAG. Interfejsy PPPoE, Cellular-WAN i WLAN są wykluczone.

Istniejące porty uplink nie są automatycznie migrowane podczas tworzenia LAG. VLAN-y, Zone Binding, DNS, gatewaye, SD-WAN, Interface Hosts, Dynamic DNS, NAT i routing mogą zależeć od starego interfejsu. Przed migracją należy:

1. W Object usage użyć opcji Refresh, aby zaktualizować i udokumentować zależności.
2. Przygotować backup, okno serwisowe i konkretny plan wycofania.
3. Przetestować niezależny dostęp administracyjny.
4. Zaplanować VLAN-y, trunki switcha, interfejsy NAT, routing i gatewaye dla nowego LAG.
5. Dopiero potem w kontrolowany sposób usunąć dotychczasowe powiązania przyszłych portów członkowskich.

Planowanie stref i interfejsów Sophos Firewall wyjaśnia, jaką strefę powinien otrzymać LAG. Spójny przykład używany w tym artykule to:

PortF2 + PortF4 → LAG0 → VLAN 10 Clients i VLAN 20 Server

Tworzenie LAG w WebAdmin

LAG w SFOS 22 tworzy się w następujący sposób:

1. Otworzyć Network > Interfaces.
2. Wybrać Add interface > Add LAG.
3. W polu Name wpisać czytelną nazwę wyświetlaną o długości do 58 znaków, na przykład LAG_Core_Uplink.
4. Ustawić Hardware name o długości do 10 znaków, używając A-Z, a-z, 0-9 i podkreślenia, na przykład lag_core. Nazwy tej nie można później zmienić i nie może ona zawierać zarezerwowanych nazw, takich jak all, gre, eth lub WLAN.
5. W polu Member interface dodać od dwóch do czterech przygotowanych portów, w tym przykładzie PortF2 i PortF4.
6. Jako Bonding mode wybrać Active-Backup lub 802.3ad.
7. Przypisać odpowiednią Zone.
8. Skonfigurować IP assignment dla IPv4, a w razie potrzeby także IPv6.
9. W sekcji Advanced settings > Port settings sprawdzić Link mode, Auto-negotiation for media type oraz zależne od modelu Forward Error Correction (FEC). Wybranie Show recommended settings, a następnie Load recommended configuration, stosuje wartości obsługiwane przez port.
10. W sekcji Advanced settings > Interface settings sprawdzić MTU oraz w razie potrzeby Override MSS. Przy 802.3ad ustawić również Xmit hash policy.
11. Użyć domyślnego adresu MAC pierwszego portu członkowskiego albo nadpisać go tylko wtedy, gdy wymaga tego konkretny projekt. Przywrócenie ustawień fabrycznych zmienia nadpisany adres z powrotem na domyślny adres MAC, dlatego nie może on być jedyną podstawą zewnętrznych reguł port security ani autoryzacji.
12. Wybrać Save.

Następnie interfejs logiczny, na przykład lag0, pojawi się w Network > Interfaces. VLAN-y tworzy się później z LAG jako interfejsem nadrzędnym. Proces konfiguracji VLAN ID, Zone, gatewaya, DHCP i testu odbiorczego opisuje artykuł Konfiguracja i testowanie VLAN w Sophos Firewall.

⚠️ Opis problemu sprawdzony dla tej procedury przypisuje NC-94073 do SFOS 19.0.0 GA-Build317 (19.0.0.317) [Tupai]; w chwili weryfikacji nie wskazywał wersji zawierającej poprawkę. Jako dotknięty problemem wymienia wyłącznie XGS Appliance z interfejsem 10G. Nie dowodzi to, że problem dotyczy SFOS 22. Nie należy więc zmieniać ustawienia zapobiegawczo. Jeśli port lub LAG XGS Appliance 10G z SFOS 22 wykazuje ten sam błąd przy Auto-negotiation, najpierw zapisać build SFOS, poprzednie wartości Link mode i Auto-negotiation oraz konfigurację peera, a także zapewnić niezależny dostęp. W oknie serwisowym można przetestować w WebAdmin workaround Sophos 10000 Mbps – Full-Duplex; peer musi być zgodny. Zmiana może przerwać łącze. Następnie sprawdzić status łącza, osiągalność i liczniki błędów. Jeśli to nie pomoże, przywrócić zapisane wartości po obu stronach i przekazać dane do Sophos Support. Workaround nie został tutaj przetestowany laboratoryjnie na XGS Appliance 10G.

Device Console nie jest gotową receptą zmian

SFOS 22 udostępnia zmienne opcje lag-interface dotyczące LACP rate, static mode, Xmit Hash Policy i link monitoring. Po zalogowaniu dokładny kontekst to Main Menu > 4. Device Console. Dozwolone zakresy wynoszą od 0 do 10000 milisekund dla down-delay, monitor-interval i up-delay oraz od 0 do 255 dla garp-count; nie są to zalecenia.

Publiczna dokumentacja nie podaje jednak pełnego polecenia tylko do odczytu bieżących wartości LAG, ich wartości domyślnych ani udokumentowanego resetu. Ponadto w składni występuje monitor-interval, a w opisie monitor-interface. Dlatego artykuł celowo nie zawiera gotowego do skopiowania polecenia set network lag-interface: bez wiarygodnej wartości poprzedniej i jednoznacznej ścieżki powrotu zmiana uplinku produkcyjnego nie byłaby bezpiecznie powtarzalna.

Jeśli Sophos Support zaleci taką zmianę dla konkretnego buildu SFOS 22, najpierw zabezpieczyć backup i niezależną ścieżkę zarządzania, a następnie zapisać stan LAG i switcha, utratę pakietów oraz wszystkie poprzednie wartości potwierdzone przez support. W Device Console użyć Tab i ?, aby sprawdzić składnię danego buildu, zmienić tylko zatwierdzone wartości, po czym przetestować stan łącza i LACP, logi switcha, GARP/MAC Move, utratę pakietów oraz awarię i powrót każdego portu członkowskiego. Wycofanie polega na jawnym ustawieniu zapisanych wartości; jeśli ich brakuje, należy zatrzymać się przed zmianą CLI.

Właściwy wybór Xmit Hash Policy

Xmit Hash Policy określa przy 802.3ad, przez który port członkowski Sophos Firewall wysyła ruch wychodzący. Ruch przychodzący do firewalla rozdziela switch przy użyciu własnej polityki hash. Algorytmy nie muszą być więc identyczne; każda strona podejmuje decyzję niezależnie dla własnego kierunku wysyłania.

• Layer2: wykorzystuje źródłowy i docelowy adres MAC. Przy niewielkiej liczbie par MAC jeden port członkowski może być znacznie bardziej obciążony.
• Layer2+3: uwzględnia dodatkowo źródłowe i docelowe adresy IP i często jest rozsądnym punktem wyjścia dla mieszanego ruchu sieciowego.
• Layer3+4: wykorzystuje dodatkowo informacje warstwy transportowej. Pozwala to lepiej rozdzielić wiele połączeń między tymi samymi hostami. W przypadku ruchu fragmentowanego informacje o portach mogą jednak nie być dostępne; fragmenty mogą zostać inaczej zahashowane i spowodować Packet Reordering.

Żadna z tych polityk nie rozdziela pojedynczego przepływu na wszystkie łącza. Właściwy wybór sprawdza się więc przy użyciu rzeczywistego ruchu oraz liczników portów członkowskich w obu kierunkach, a nie na podstawie identycznej nazwy algorytmu hash na switchu.

Konfiguracja switcha

Przy Active-Backup portów nie łączy się w statyczny ani LACP port-channel. Oba porty otrzymują tę samą konfigurację VLAN/trunk i prowadzą do tej samej sieci warstwy 2. Należy dodatkowo sprawdzić, czy Spanning Tree, Port Security lub ustawienia MAC Move nie opóźniają ani nie blokują przełączenia.

Przy 802.3ad porty switcha muszą:

• należeć do tego samego LACP port-channel,
• aktywnie używać LACP,
• odpowiadać stronie firewalla pod względem prędkości, duplexu, VLAN-ów i MTU,
• w przypadku dwóch switchy należeć do wspólnego logicznego systemu LACP.

Samo utworzenie LAG na firewallu nie wystarcza. Jeśli switch nadal traktuje porty niezależnie lub używa statycznego bondingu zamiast LACP, mogą wystąpić utrata pakietów, asymetryczne zachowanie albo tylko częściowo aktywny LAG.

Testowanie LAG i failover

Przed pierwszym testem awarii należy udokumentować stan początkowy, status portów członkowskich, status LACP i liczniki interfejsów na firewallu oraz switchu. Następnie:

1. Normalna praca: przetestować gateway, cele wewnętrzne i wymagane usługi w obu kierunkach.
2. Odłączyć kolejno każdy port członkowski: zmierzyć osiągalność, utratę pakietów, istniejące sesje i czas przełączenia. Failover nie zawsze jest całkowicie bezprzerwowy.
3. Ponownie podłączyć port: sprawdzić na firewallu i switchu, czy został znów aktywnie przyjęty i czy liczniki błędów pozostają stabilne.
4. Przetestować LACP z wieloma przepływami: wygenerować kilka połączeń z różnymi kombinacjami źródła i celu w obu kierunkach oraz porównać liczniki portów członkowskich.
5. Sprawdzić VLAN-y: w tym przykładzie osobno przetestować VLAN 10 i VLAN 20 pod kątem gatewaya, dozwolonych celów, blokowanych celów, DHCP i DNS.

Dla Layer3+4 można na kliencie testowym poza firewallem użyć na przykład iPerf3 z czterema równoległymi przepływami zamiast jednego połączenia, ponieważ różnią się one portami:

iperf3 -c 10.20.20.50 -P 4 -t 30
iperf3 -c 10.20.20.50 -P 4 -t 30 -R

Adres 10.20.20.50 należy zastąpić adresem serwera testowego iPerf3. Przy Layer2 lub Layer2+3 potrzebnych jest kilka par hostów źródłowych i docelowych albo różne adresy MAC lub IP. Test celowo generuje obciążenie i powinien zostać wykonany w odpowiednim oknie czasowym. Opcja -R sprawdza kierunek przeciwny. Pełną konfigurację urządzeń końcowych opisuje artykuł Testowanie wydajności Sophos Firewall za pomocą iPerf3.

Typowe błędy

• Port członkowski nie pojawia się: port jest nadal powiązany, nie ma konfiguracji statycznej lub należy do wykluczonego typu interfejsu.
• LACP nie staje się aktywne: porównać port-channel switcha, tryb LACP, przypisanie portów członkowskich, Speed/Duplex, VLAN-y i MTU.
• Dwa switche bez wspólnego peera LACP: brakuje stacku lub MLAG/MC-LAG. Ograniczyć LACP do jednego logicznego peera albo odpowiednio zaplanować Active-Backup.
• Łącze XGS Appliance 10G pozostaje down przy Auto-negotiation: sprawdzić powyższą, zależną od wersji uwagę o NC-94073, zapisać wcześniejsze wartości i testować workaround tylko w kontrolowanym oknie serwisowym.
• Prawie całe obciążenie przypada na jeden port członkowski: przy niewielkiej liczbie przepływów może to być prawidłowe. Przetestować kilka odpowiednich połączeń i porównać liczniki obu kierunków wysyłania; polityka hash switcha nie musi mieć tej samej nazwy.
• VLAN lub internet przestaje działać po migracji: sprawdzić interfejs nadrzędny VLAN, Zone, obiekty sieciowe, NAT Inbound/Outbound Interfaces, routing i gatewaye. Zwykłe reguły firewalla dopasowują strefy i sieci, a nie fizyczny port członkowski.
• Failover powoduje utratę pakietów lub sesji: zmierzyć czas przełączenia i sprawdzić ustawienia switcha dotyczące MAC Move, Spanning Tree oraz Port Security.
• Hardware name jest błędna: nazwy technicznej nie można później zmienić; jeśli zmiana nazwy jest konieczna, LAG trzeba utworzyć ponownie.

Checklista operacyjna

• Wybrano Active-Backup lub 802.3ad zgodnie z celem dotyczącym redundancji i przepustowości
• Przygotowano od dwóch do czterech niepowiązanych, statycznych fizycznych portów członkowskich
• Sprawdzono Object Usage, backup, plan wycofania i niezależny dostęp administracyjny
• Skonfigurowano porty switcha odpowiednio dla Active-Backup lub LACP
• Sprawdzono Link mode, Auto-negotiation, FEC, MTU i MSS
• Poprawnie przypisano Xmit Hash Policy tylko do kierunku wysyłania firewalla
• Przetestowano awarię każdego portu członkowskiego i jego ponowne dołączenie
• Przetestowano LACP z wieloma przepływami w obu kierunkach i porównano liczniki portów członkowskich
• Po migracji zweryfikowano interfejsy nadrzędne VLAN, Zone, NAT, routing i gatewaye

FAQ