Sophos Firewall LAG mit LACP einrichten und testen

Eine Link Aggregation Group (LAG) bündelt zwei bis vier physische Ports zu einem logischen Interface. Active-Backup bietet Redundanz mit einem aktiven Link. 802.3ad (LACP) nutzt mehrere Links parallel und erhöht die Gesamtbandbreite über mehrere Verbindungen.

Eine einzelne TCP- oder UDP-Verbindung wird durch LACP normalerweise nicht schneller: Der Hash hält einen Flow auf einem Member-Link. Zusätzliche Kapazität entsteht erst durch mehrere unterschiedlich gehashte Verbindungen.

Modus und Umbau vorbereiten

Active-Backup oder 802.3ad

Active-Backup ist der einfache Redundanzmodus. Nur ein Member überträgt Traffic; bei einem Ausfall übernimmt ein anderer. Der Switch benötigt dafür keinen LACP-Port-Channel. Beide Switch-Ports müssen aber dieselben VLANs beziehungsweise dieselbe Access-Konfiguration verwenden, im gleichen Layer-2-Netz liegen und den MAC-Wechsel beim Failover akzeptieren.

802.3ad (LACP) verwendet alle aktiven Links für Lastverteilung und Failover. Dafür gelten:

• LACP ist auf Firewall und Switch aktiviert.
• Alle Member haben denselben Interfacetyp, dieselbe Geschwindigkeit und Full-Duplex.
• Die Switch-Ports gehören zum selben logischen LACP-Peer und Port-Channel.
• Zwei physische Switches funktionieren nur, wenn Stack, MLAG/MC-LAG oder eine vergleichbare Technik sie als gemeinsames LACP-System präsentiert.
• VLAN-/Trunk-Konfiguration und MTU sind auf allen Membern konsistent.

Für reine Redundanz ist Active-Backup meist einfacher. LACP passt, wenn mehrere parallele Verbindungen tatsächlich mehr Gesamtbandbreite benötigen.

Member und Rollback vorbereiten

Sophos Firewall erlaubt zwei bis vier ungebundene physische Interfaces mit statischer IP-Zuweisung als LAG-Member. PPPoE-, Cellular-WAN- und WLAN-Interfaces sind ausgeschlossen.

Bestehende Uplink-Ports werden beim Anlegen nicht automatisch migriert. VLANs, Zone Binding, DNS, Gateways, SD-WAN, Interface Hosts, Dynamic DNS, NAT und Routing können vom alten Interface abhängen. Vor dem Umbau:

1. Unter Object usage mit Refresh die Abhängigkeiten aktualisieren und dokumentieren.
2. Backup, Wartungsfenster und einen konkreten Rollback-Plan vorbereiten.
3. Einen unabhängigen Admin-Zugang testen.
4. VLANs, Switch-Trunks, NAT-Interfaces, Routing und Gateways für den neuen LAG planen.
5. Künftige Member erst danach kontrolliert aus ihren bisherigen Bindungen lösen.

Sophos Firewall Zonen und Interfaces planen erklärt, welche Zone der LAG erhalten sollte. Ein durchgängiges Beispiel für diesen Artikel ist:

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

LAG im WebAdmin anlegen

So wird der LAG in SFOS 22 angelegt:

1. Network > Interfaces öffnen.
2. Add interface > Add LAG wählen.
3. Unter Name einen sprechenden Anzeigenamen mit maximal 58 Zeichen eintragen, beispielsweise LAG_Core_Uplink.
4. Einen Hardware name mit maximal 10 Zeichen aus A-Z, a-z, 0-9 und Unterstrich setzen, beispielsweise lag_core. Er kann später nicht geändert werden und darf keine reservierten Namen wie all, gre, eth oder WLAN enthalten.
5. Unter Member interface zwei bis vier vorbereitete Ports hinzufügen, im Beispiel PortF2 und PortF4.
6. Als Bonding mode Active-Backup oder 802.3ad wählen.
7. Die passende Zone zuweisen.
8. IP assignment für IPv4 und bei Bedarf IPv6 konfigurieren.
9. Unter Advanced settings > Port settings Link mode, Auto-negotiation for media type und modellabhängig Forward Error Correction (FEC) prüfen. Mit Show recommended settings und anschliessend Load recommended configuration werden die vom Port unterstützten Werte übernommen.
10. Unter Advanced settings > Interface settings MTU und bei Bedarf Override MSS prüfen. Bei 802.3ad zusätzlich die Xmit hash policy festlegen.
11. Die Standard-MAC-Adresse des ersten Members verwenden oder nur bei einer klaren Designanforderung überschreiben. Ein Factory Reset setzt eine überschriebene Adresse wieder auf die Standard-MAC-Adresse zurück; sie darf deshalb nicht die einzige Grundlage für eine externe Port-Security- oder Freischaltlogik sein.
12. Save wählen.

Danach erscheint das logische Interface, beispielsweise lag0, unter Network > Interfaces. VLANs werden anschliessend mit dem LAG als Parent angelegt. Den Ablauf für VLAN ID, Zone, Gateway, DHCP und Abnahme beschreibt Sophos Firewall VLAN einrichten und testen.

⚠️ Die für diesen Ablauf geprüfte Problembeschreibung ordnet NC-94073 SFOS 19.0.0 GA-Build317 (19.0.0.317) [Tupai] zu; zum Prüfzeitpunkt war keine Fix-Version angegeben. Als betroffen nennt sie ausschliesslich XGS Appliance mit einem 10G-Interface. Daraus folgt nicht, dass SFOS 22 betroffen ist. Die Einstellung deshalb nicht vorsorglich ändern. Zeigt ein XGS Appliance-10G-Port oder -LAG unter SFOS 22 dasselbe Fehlerbild mit Auto-negotiation, zuerst SFOS-Build, bisherigen Link mode, Auto-negotiation und Gegenstellenkonfiguration dokumentieren und einen unabhängigen Zugang sicherstellen. Im Wartungsfenster kann man den von Sophos genannten Workaround 10000 Mbps – Full-Duplex im WebAdmin testen; die Gegenstelle muss dazu passen. Die Änderung kann den Link unterbrechen. Danach Linkstatus, Erreichbarkeit und Fehlerzähler prüfen. Hilft sie nicht, die dokumentierten Vorwerte auf beiden Seiten wiederherstellen und den Fall mit diesen Daten an Sophos Support geben. Dieser Workaround wurde hier nicht in einem Labor mit XGS Appliance 10G getestet.

Device Console nicht als Änderungsrezept verwenden

SFOS 22 führt konfigurierbare lag-interface-Optionen für LACP-Rate, statischen Modus, Xmit Hash Policy und Link-Monitoring. Der exakte Konsolenkontext ist nach der Anmeldung Main Menu > 4. Device Console. Die zulässigen Bereiche sind 0 bis 10000 Millisekunden für down-delay, monitor-interval und up-delay sowie 0 bis 255 für garp-count; sie sind keine Empfehlungen.

Die öffentliche Referenz zeigt jedoch weder einen vollständigen lesenden Befehl für die aktuellen LAG-Werte noch deren Defaults oder einen dokumentierten Reset. Zudem steht in der Syntax monitor-interval, im Optionstext aber monitor-interface. Deshalb enthält dieser Artikel bewusst keinen kopierbaren set network lag-interface-Befehl: Ohne belastbaren Vorwert und eindeutigen Rückweg wäre die Änderung an einem produktiven Uplink nicht sicher reproduzierbar.

Wenn Sophos Support für einen konkreten SFOS-22-Build eine solche Änderung vorgibt, vorab ein Backup und einen unabhängigen Managementpfad bereitstellen. Ausserdem LAG- und Switch-Status, Paketverlust und alle von Support bestätigten Vorwerte dokumentieren. In Device Console mit Tab und ? die build-spezifische Syntax kontrollieren, nur die freigegebenen Werte ändern und danach Linkstatus, LACP-Status, Switch-Logs, GARP/MAC Move, Paketverlust sowie Ausfall und Wiederaufnahme jedes Members testen. Für den Rollback werden ausdrücklich die dokumentierten Vorwerte gesetzt; fehlen sie, endet der Ablauf vor der CLI-Änderung.

Xmit Hash Policy richtig wählen

Die Xmit Hash Policy bestimmt bei 802.3ad, über welchen Member die Sophos Firewall ausgehenden Traffic sendet. Eingehenden Traffic zur Firewall verteilt der Switch mit seiner eigenen Hash-Policy. Die Algorithmen müssen deshalb nicht identisch sein; jede Seite entscheidet unabhängig für ihre Senderichtung.

• Layer2: verwendet Quell- und Ziel-MAC-Adresse. Bei wenigen MAC-Paaren kann ein Member deutlich stärker belastet sein.
• Layer2+3: berücksichtigt zusätzlich Quell- und Ziel-IP-Adressen und ist oft ein sinnvoller Ausgangspunkt für gemischten Netzwerktraffic.
• Layer3+4: verwendet zusätzlich Informationen der Transportschicht. Mehrere Verbindungen zwischen denselben Hosts können dadurch besser verteilt werden. Bei fragmentiertem Traffic fehlen jedoch möglicherweise Portinformationen; Fragmente können anders gehasht werden und Packet Reordering verursachen.

Keine Policy verteilt einen einzelnen Flow über alle Links. Die passende Wahl wird deshalb mit realem Traffic und den Member-Zählern in beiden Richtungen geprüft, nicht durch einen identischen Hash-Namen auf dem Switch.

Switch-Seite konfigurieren

Bei Active-Backup werden die Ports nicht zu einem statischen oder LACP-Port-Channel zusammengefasst. Beide Ports erhalten dieselbe VLAN-/Trunk-Konfiguration und führen zum gleichen Layer-2-Netz. Zusätzlich sollte geprüft werden, ob Spanning Tree, Port Security oder MAC-Move-Einstellungen den Wechsel unnötig verzögern oder blockieren.

Bei 802.3ad müssen die Switch-Ports:

• im selben LACP-Port-Channel liegen,
• LACP aktiv verwenden,
• mit Geschwindigkeit, Duplex, VLANs und MTU zur Firewall passen,
• bei zwei Switches zu einem gemeinsamen logischen LACP-System gehören.

Ein LAG nur auf der Firewall reicht nicht. Wenn der Switch die Ports weiterhin unabhängig betreibt oder statisches Bonding statt LACP verwendet, können Paketverlust, asymmetrisches Verhalten oder ein nur teilweise aktiver LAG entstehen.

LAG und Failover abnehmen

Vor dem ersten Ausfalltest Ausgangszustand, Member-Status, LACP-Status und Interface-Zähler auf Firewall und Switch dokumentieren. Danach:

1. Normalbetrieb: Gateway, interne Ziele und benötigte Dienste in beiden Richtungen testen.
2. Jeden Member einzeln trennen: Erreichbarkeit, Paketverlust, bestehende Sessions und Umschaltdauer messen. Ein Failover ist nicht automatisch vollständig unterbrechungsfrei.
3. Member wieder verbinden: Auf Firewall und Switch prüfen, ob er wieder aktiv aufgenommen wird und die Fehlerzähler stabil bleiben.
4. LACP mit mehreren Flows testen: Mehrere Verbindungen mit unterschiedlichen Quell-/Zielkombinationen in beide Richtungen erzeugen und Member-Zähler vergleichen.
5. VLANs prüfen: Im Beispiel VLAN 10 und VLAN 20 einzeln auf Gateway, erlaubte Ziele, blockierte Ziele, DHCP und DNS testen.

Für Layer3+4 kann auf einem Testclient ausserhalb der Firewall statt einer einzelnen Verbindung beispielsweise iPerf3 mit vier parallelen Flows verwendet werden, weil sich deren Ports unterscheiden:

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

10.20.20.50 ist durch die Adresse des iPerf3-Testservers zu ersetzen. Bei Layer2 oder Layer2+3 sind mehrere Quell-/Zielhost-Paare beziehungsweise unterschiedliche MAC- oder IP-Adressen erforderlich. Der Test erzeugt bewusst Last und gehört in ein geeignetes Zeitfenster. -R prüft die Gegenrichtung. Die vollständige Einrichtung der Endpunkte erklärt Sophos Firewall Performance mit iPerf3 testen.

Typische Fehler

• Member erscheint nicht: Der Port ist noch gebunden, nicht statisch konfiguriert oder gehört zu einem ausgeschlossenen Interfacetyp.
• LACP wird nicht aktiv: Switch-Port-Channel, LACP-Modus, Member-Zuordnung, Speed/Duplex, VLANs und MTU vergleichen.
• Zwei Switches, aber kein gemeinsamer LACP-Peer: Stack oder MLAG/MC-LAG fehlt. LACP auf einen logischen Peer begrenzen oder Active-Backup passend planen.
• XGS Appliance-10G-Link bleibt mit Auto-negotiation down: Den versionsbezogenen Hinweis zu NC-94073 oben prüfen, Vorwerte sichern und den Workaround nur kontrolliert im Wartungsfenster testen.
• Last liegt fast vollständig auf einem Member: Bei wenigen Flows kann das korrekt sein. Mehrere geeignete Verbindungen testen und Zähler beider Senderichtungen vergleichen; die Switch-Hash-Policy muss nicht denselben Namen haben.
• VLAN oder Internet fällt nach der Migration aus: VLAN-Parent, Zone, Netzwerkobjekte, NAT-Inbound-/Outbound-Interfaces, Routing und Gateways prüfen. Normale Firewall-Regeln matchen Zonen und Netze, nicht einen physischen Member-Port.
• Failover verliert Pakete oder Sessions: Umschaltdauer messen und Switch-Einstellungen für MAC Move, Spanning Tree und Port Security prüfen.
• Hardware name ist falsch: Der technische Name kann nicht nachträglich geändert werden; der LAG muss bei einem notwendigen Namenswechsel neu erstellt werden.

Betriebscheckliste

• Active-Backup oder 802.3ad anhand von Redundanz- und Bandbreitenziel gewählt
• zwei bis vier ungebundene, statische physische Member vorbereitet
• Object Usage, Backup, Rückweg und unabhängiger Admin-Zugang geprüft
• Switch-Ports passend zu Active-Backup oder LACP konfiguriert
• Link mode, Auto-negotiation, FEC, MTU und MSS kontrolliert
• Xmit Hash Policy nur für die Senderichtung der Firewall eingeordnet
• jeden Member-Ausfall und die Wiederaufnahme getestet
• LACP mit mehreren Flows in beiden Richtungen und Member-Zählern geprüft
• VLAN-Parents, Zone, NAT, Routing und Gateways nach der Migration validiert

FAQ