Konfigurera och testa LAG med LACP i Sophos Firewall

En Link Aggregation Group (LAG) samlar två till fyra fysiska portar i ett logiskt gränssnitt. Active-Backup ger redundans med en aktiv länk. 802.3ad (LACP) använder flera länkar parallellt och ökar den sammanlagda bandbredden över flera anslutningar.

En enskild TCP- eller UDP-anslutning blir normalt inte snabbare med LACP: hashningen håller ett flöde på en medlemslänk. Ytterligare kapacitet uppstår först genom flera anslutningar som får olika hashvärden.

Förbered läge och migrering

Active-Backup eller 802.3ad

Active-Backup är det enkla redundansläget. Endast en medlem överför trafik och en annan tar över vid ett avbrott. Switchen behöver ingen LACP-port-channel för detta. Båda switchportarna måste dock använda samma VLAN eller samma accesskonfiguration, ligga i samma lager 2-nät och tillåta MAC-byte vid failover.

802.3ad (LACP) använder alla aktiva länkar för lastfördelning och failover. Följande gäller:

• LACP är aktiverat på brandväggen och switchen.
• Alla medlemmar har samma gränssnittstyp, samma hastighet och Full-Duplex.
• Switchportarna tillhör samma logiska LACP-peer och port-channel.
• Två fysiska switchar fungerar bara om en stack, MLAG/MC-LAG eller motsvarande teknik presenterar dem som ett gemensamt LACP-system.
• VLAN-/trunkkonfiguration och MTU är konsekventa på alla medlemmar.

För enbart redundans är Active-Backup oftast enklare. LACP passar när flera parallella anslutningar faktiskt behöver högre total bandbredd.

Kontrollera medlemmar och förbered återställning

Sophos Firewall tillåter två till fyra obundna fysiska gränssnitt med statisk IP-tilldelning som LAG-medlemmar. PPPoE-, Cellular-WAN- och WLAN-gränssnitt är undantagna.

Befintliga uplink-portar migreras inte automatiskt när en LAG skapas. VLAN, Zone Binding, DNS, gateways, SD-WAN, Interface Hosts, Dynamic DNS, NAT och routing kan vara beroende av det gamla gränssnittet. Före migreringen:

1. Använd Refresh under Object usage för att uppdatera och dokumentera beroendena.
2. Förbered backup, underhållsfönster och en konkret återställningsplan.
3. Testa en oberoende administratörsåtkomst.
4. Planera VLAN, switchtrunkar, NAT-gränssnitt, routing och gateways för den nya LAG:en.
5. Ta först därefter bort de framtida medlemmarna från deras befintliga bindningar på ett kontrollerat sätt.

Planera zoner och gränssnitt i Sophos Firewall förklarar vilken zon LAG:en bör få. Ett genomgående exempel i den här artikeln är:

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

Skapa LAG i WebAdmin

Skapa LAG i SFOS 22 så här:

1. Öppna Network > Interfaces.
2. Välj Add interface > Add LAG.
3. Ange ett tydligt visningsnamn med högst 58 tecken under Name, till exempel LAG_Core_Uplink.
4. Ange ett Hardware name med högst 10 tecken från A-Z, a-z, 0-9 och understreck, till exempel lag_core. Det kan inte ändras senare och får inte innehålla reserverade namn som all, gre, eth eller WLAN.
5. Lägg till två till fyra förberedda portar under Member interface, i exemplet PortF2 och PortF4.
6. Välj Active-Backup eller 802.3ad som Bonding mode.
7. Tilldela rätt Zone.
8. Konfigurera IP assignment för IPv4 och vid behov IPv6.
9. Kontrollera Link mode, Auto-negotiation for media type och modellberoende Forward Error Correction (FEC) under Advanced settings > Port settings. Show recommended settings följt av Load recommended configuration använder de värden som porten stöder.
10. Kontrollera MTU och vid behov Override MSS under Advanced settings > Interface settings. Ange även Xmit hash policy för 802.3ad.
11. Använd standard-MAC-adressen från den första medlemmen eller åsidosätt den endast om det finns ett tydligt designkrav. En fabriksåterställning återställer en åsidosatt adress till standard-MAC-adressen, så den får inte vara den enda grunden för extern port-security- eller behörighetslogik.
12. Välj Save.

Därefter visas det logiska gränssnittet, till exempel lag0, under Network > Interfaces. VLAN skapas sedan med LAG som överordnat gränssnitt. Konfigurera och testa VLAN i Sophos Firewall beskriver VLAN ID, Zone, gateway, DHCP och validering.

⚠️ Problembeskrivningen som granskades för den här proceduren kopplar NC-94073 till SFOS 19.0.0 GA-Build317 (19.0.0.317) [Tupai]; vid granskningen angavs ingen korrigerad version. Endast XGS Appliance med ett 10G-gränssnitt anges som påverkad. Detta visar inte att SFOS 22 är påverkat. Ändra därför inte inställningen i förebyggande syfte. Om en XGS Appliance 10G-port eller LAG med SFOS 22 visar samma fel med Auto-negotiation, dokumentera först SFOS-build, tidigare Link mode, Auto-negotiation och peer-konfiguration och säkerställ oberoende åtkomst. I ett underhållsfönster kan Sophos workaround 10000 Mbps – Full-Duplex testas i WebAdmin; peer-sidan måste matcha. Ändringen kan bryta länken. Kontrollera sedan länkstatus, nåbarhet och felräknare. Om det inte hjälper, återställ dokumenterade värden i båda ändar och lämna uppgifterna till Sophos Support. Denna workaround har inte labbtestats här på XGS Appliance 10G.

Använd inte Device Console som ändringsrecept

SFOS 22 erbjuder ändringsbara lag-interface-alternativ för LACP rate, static mode, Xmit Hash Policy och link monitoring. Efter inloggning är den exakta kontexten Main Menu > 4. Device Console. De tillåtna intervallen är 0 till 10000 millisekunder för down-delay, monitor-interval och up-delay samt 0 till 255 för garp-count; de är inte rekommendationer.

Den offentliga referensen visar dock varken ett fullständigt skrivskyddat kommando för aktuella LAG-värden, standardvärden eller en dokumenterad återställning. Dessutom står monitor-interval i syntaxen men monitor-interface i alternativtexten. Artikeln innehåller därför medvetet inget kopieringsklart set network lag-interface-kommando: utan ett tillförlitligt tidigare värde och en uttrycklig återställningsväg kan en ändring av produktionsuplink inte reproduceras säkert.

Om Sophos Support föreskriver en sådan ändring för en viss SFOS 22-build ska backup och oberoende managementväg först säkras. Dokumentera sedan LAG- och switchstatus, paketförlust och alla tidigare värden som Support bekräftar. Använd Tab och ? i Device Console för att kontrollera buildens syntax, ändra endast godkända värden och testa därefter länk- och LACP-status, switchloggar, GARP/MAC Move, paketförlust samt avbrott och återhämtning för varje medlem. Återställ genom att uttryckligen sätta de dokumenterade tidigare värdena; om de saknas ska man stoppa före CLI-ändringen.

Välj rätt Xmit Hash Policy

Xmit Hash Policy avgör vid 802.3ad över vilken medlem Sophos Firewall skickar utgående trafik. Inkommande trafik till brandväggen fördelas av switchen med dess egen hashpolicy. Algoritmerna behöver därför inte vara identiska; varje sida fattar ett oberoende beslut för sin sändningsriktning.

• Layer2: använder källans och målets MAC-adresser. Med få MAC-par kan en medlem belastas betydligt mer än de andra.
• Layer2+3: tar även hänsyn till källans och målets IP-adresser och är ofta en lämplig utgångspunkt för blandad nätverkstrafik.
• Layer3+4: använder dessutom information från transportlagret. Flera anslutningar mellan samma värdar kan därmed fördelas bättre. För fragmenterad trafik kan portinformation däremot saknas; fragment kan få olika hashvärden och orsaka Packet Reordering.

Ingen policy fördelar ett enskilt flöde över alla länkar. Rätt val kontrolleras därför med verklig trafik och medlemsräknare i båda riktningarna, inte genom att använda samma namn på hashningen i switchen.

Konfigurera switchen

Vid Active-Backup grupperas portarna inte i en statisk port-channel eller LACP-port-channel. Båda portarna får samma VLAN-/trunkkonfiguration och leder till samma lager 2-nät. Kontrollera dessutom om Spanning Tree, Port Security eller MAC Move-inställningar fördröjer eller blockerar växlingen.

Vid 802.3ad måste switchportarna:

• ligga i samma LACP-port-channel,
• använda LACP aktivt,
• matcha brandväggen avseende hastighet, duplex, VLAN och MTU,
• tillhöra ett gemensamt logiskt LACP-system om två switchar används.

Det räcker inte att bara skapa en LAG på brandväggen. Om switchen fortsätter att hantera portarna oberoende eller använder statisk bonding i stället för LACP kan resultatet bli paketförlust, asymmetriskt beteende eller en LAG som bara är delvis aktiv.

Validera LAG och failover

Dokumentera utgångsläge, medlemsstatus, LACP-status och gränssnittsräknare på brandvägg och switch före det första avbrottstestet. Därefter:

1. Normal drift: testa gateway, interna mål och nödvändiga tjänster i båda riktningarna.
2. Koppla från varje medlem separat: mät nåbarhet, paketförlust, befintliga sessioner och omkopplingstid. Failover är inte automatiskt helt avbrottsfri.
3. Anslut medlemmen igen: kontrollera på brandvägg och switch att den åter blir aktiv och att felräknarna förblir stabila.
4. Testa LACP med flera flöden: skapa flera anslutningar med olika käll-/målkombinationer i båda riktningarna och jämför medlemsräknarna.
5. Kontrollera VLAN: testa i exemplet VLAN 10 och VLAN 20 separat avseende gateway, tillåtna mål, blockerade mål, DHCP och DNS.

För Layer3+4 kan man på en testklient utanför brandväggen exempelvis använda iPerf3 med fyra parallella flöden i stället för en enskild anslutning, eftersom deras portar skiljer sig:

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

Ersätt 10.20.20.50 med adressen till iPerf3-testservern. För Layer2 eller Layer2+3 krävs flera käll-/målvärdspar eller olika MAC- eller IP-adresser. Testet skapar avsiktligt belastning och ska genomföras i ett lämpligt tidsfönster. -R testar motsatt riktning. Testa Sophos Firewall-prestanda med iPerf3 beskriver hela konfigurationen av ändpunkterna.

Vanliga fel

• Medlemmen visas inte: porten är fortfarande bunden, inte statiskt konfigurerad eller tillhör en undantagen gränssnittstyp.
• LACP blir inte aktivt: jämför switchens port-channel, LACP-läge, medlemstilldelning, Speed/Duplex, VLAN och MTU.
• Två switchar men ingen gemensam LACP-peer: stack eller MLAG/MC-LAG saknas. Begränsa LACP till en logisk peer eller planera Active-Backup på rätt sätt.
• XGS Appliance 10G-länken förblir down med Auto-negotiation: kontrollera den versionsspecifika informationen om NC-94073 ovan, dokumentera tidigare värden och testa workaround endast i ett kontrollerat underhållsfönster.
• Nästan all belastning ligger på en medlem: med få flöden kan detta vara korrekt. Testa flera lämpliga anslutningar och jämför räknarna för båda sändningsriktningarna; switchens hashpolicy behöver inte ha samma namn.
• VLAN eller internet slutar fungera efter migreringen: kontrollera VLAN:s överordnade gränssnitt, Zone, nätverksobjekt, NAT Inbound/Outbound Interfaces, routing och gateways. Vanliga brandväggsregler matchar zoner och nät, inte en fysisk medlemsport.
• Failover förlorar paket eller sessioner: mät omkopplingstiden och kontrollera switchinställningarna för MAC Move, Spanning Tree och Port Security.
• Hardware name är fel: det tekniska namnet kan inte ändras i efterhand; om ett namnbyte krävs måste LAG:en skapas på nytt.

Driftchecklista

• Active-Backup eller 802.3ad valt utifrån målet för redundans och bandbredd
• två till fyra obundna, statiska fysiska medlemmar förberedda
• Object Usage, backup, återställningsväg och oberoende administratörsåtkomst kontrollerade
• switchportar konfigurerade för Active-Backup eller LACP
• Link mode, Auto-negotiation, FEC, MTU och MSS kontrollerade
• Xmit Hash Policy korrekt klassificerad som endast brandväggens sändningsriktning
• avbrott och återanslutning testade för varje medlem
• LACP testat med flera flöden i båda riktningarna och medlemsräknare
• VLAN:s överordnade gränssnitt, Zone, NAT, routing och gateways verifierade efter migreringen

FAQ