CARP, VLANs und LAGG - beide Firewalls sind Master

[Felix.]

Hmm, das kann ich so verkabeln, wäre kein Problem, da die Ausfallsicherheit ja nicht leidet.
Ob jetzt eine Firewall oder einer der Switche ausfällt wäre in dem Fall Wurst, da die 2. FW einspringen kann und der Rest durch die Verkabelung der Switche und Spanning Tree abgefedert wird.

Ich hab mal ein kleines Diagramm erstellt - das sollte doch so hinhauen, hm?

[mimugmail]

Korrekt, leider sinds halt Netgear Switche
FreeBSD hat das Problem dass der LAGG kurz flappt wenn ein Member down geht.
D.h. wenn du z.B. auf Switch1 ein Update einspielt flappen beide Firewalls, das ist natürlich ungünstig.

Dann lieber eine Firewall komplett auf einen Switch, dann kannst du bei Switch Update einfach die Master Funktion schieben 

[Felix.]

Korrekt, leider sinds halt Netgear Switche

So-called Budget-Lösung
Aber an und für sich benehmen sich die Teile sehr anständig - die M4300er haben in den letzten 5+ Jahren kaum Faxen gemacht. Wie gut die GC752er auf Dauer sind wird sich zeigen...

FreeBSD hat das Problem dass der LAGG kurz flappt wenn ein Member down geht.
D.h. wenn du z.B. auf Switch1 ein Update einspielt flappen beide Firewalls, das ist natürlich ungünstig.

Dann lieber eine Firewall komplett auf einen Switch, dann kannst du bei Switch Update einfach die Master Funktion schieben 

Uh, das ist wirklich gut zu wissen! 

Vielen lieben Dank erstmal für deine großartige Hilfe!! 
Ich verkabel das die nächsten Tage so und dann schreib ich wieder wies gelaufen ist... vermutlich gleich vor Ort, dann kann ich im Zweifelsfall noch reagieren.

Gibt ja in der Zwischenzeit noch genug andere Kleinigkeiten an dem Konstrukt die es zu lösen gilt... *hust* DHCP Failover, aber dazu mach ich einen separaten Thread auf. 

[Felix.]

Hi!
Leider konnte ich Freitag nicht direkt schreiben, da noch unerwartet weitere Arbeiten vor Ort angefallen sind.

Ich habe die Verkabelung wie besprochen angepasst und auch an den Switchen und FWs für die jeweiligen 2 Ports eine LAG konfiguriert und LACP aktiviert.

Ein paar kleine Tests lieferten gemischte Ergebnisse.
Zunächst mal, nachdem das Ganze verkabelt und konfiguriert war und auch in der Zwischenzeit, also während an FW1 die Kabel und Konfiguration geändert wurden, hat FW2 ganz brav und sofort die MASTER Rollen übernommen.
Das Failback zu FW1 lief ebenfalls gut.

Also nachdem die "Umbauten" fertig waren war erstmal alles gut. Sicherheitshalber haben auch beide Geräte einen Neustart gemacht.

Dann habe ich mal testweise einen der LAN Links gezogen, da ich hier schon Posts gelesen habe bzgl. LAGG und CARP und wie beschrieben kam es zum Failover, *obwohl* das LAGG Interface noch intakt hätte sein müssen.

FreeBSD hat das Problem dass der LAGG kurz flappt wenn ein Member down geht.

Ich dachte mir, dass das vielleicht der Auslöser für diesen Failover sein könnte.
Problem ist, weder der Failover geschweige denn der Failback funktionieren.
WAN machte einen sauberen Failover - alle auf den LAGGs liegenden VHIDs blieben dann auf *beiden* FWs im MASTER Zustand. Ich musste auf dem Master den Maintenance Mode aktivieren, damit die Backup Firewall komplett und korrekt übernahm.

Zurückswitchen konnte ich erst als das gezogene Kabel wieder steckte und ich am Master den Maintenance Mode deaktivierte.

Zwar laufen beide Firewalls so ganz anständig, aber ganz kugelsicher wirkt das Konstrukt noch nicht.
Ich könnte mir auch vorstellen auf das LAGG Interface zu verzichten - das war ja primär für die gekreuzte Verbindung zu den Switchen gedacht.

Durch das flappen der LAGG Interfaces wird ein Failover ja sowieso ausgelöst bzw. provoziert, ob nun ein oder beide Links ausfallen.
Und ich meine... naja, wofür hat man denn ein Failover-Peer? Dann hat man eben eine 0,0x% höhere Chance, dass die Backup-Firewall einspringen muss, aber was solls? Das soll sie ja.
Da lohnt sich der "Ärger" mit der Link Aggregation ja eigentlich gar nicht, da im Falle eines Falles ohnehin volle Redundanz besteht durch die Backup-Firewall.

Bin offen für Meinungen... 

[rainerle]

Hi Felix,

genau dem Pfad bin ich auch schon entlang gelaufen...

Meine Lösung sah dann so aus:
- 2 Huawei Switche gestackt
- 2 OPNsense mit je 4 interfaces active-passive
- Kein lagg und kein LACP

Siehe hier
https://forum.opnsense.org/index.php?topic=14130
und dann als Lösung hier
https://forum.opnsense.org/index.php?topic=14374

Gerade beim der Installation nervt das Aus-/Anschalten des LACP.
Weiterhin verwende ich das LAN (1G) interface als Admin Port - da gibt es dann auch Automatische Regeln, die das unabsichtliche Selberausperren verhindern.
Und das WAN (10G) als Uplink Port, dann hat man da auch automatische Regeln und das Outbound NAT schon mal fertig. Und Suricata mag eh kein VLAN auf dem Uplink port.
Bleiben noch zwei Interfaces übrig:
- Ein 1G für pfSync
- Ein 10G für alle anderen VLANs...

Wenn nun ein Switch ausfällt wegen Firmwarepatch oder so, dann gibt es halt einen failover auf den anderen Switch und eben auch die andere OPNsense.

Und bei mir gehen WAN Strecken immer erst in einen Switchport und da in ein VLAN rein. Und dann von da aus auf die Firewall. Dann kann man auch mal am Switch probieren, ob ein Netz geht und muss beim Ausfall einer WAN Strecke nicht gleich einen Failover der Firewall machen.

[JeGr]

Felix: dein letzter Nachsatz/Absatz ist der entscheidende.

HA zu haben ist gut und wichtig! Aber es muss Sinn machen. LAGG mit LACP kann(!) Sinn machen, gerade wenn man mehr Dampf als 1/10G braucht und dazu 2-4 Strecken bündelt und entsprechende Client Anzahlen hat. Gerade wenn dann auf dem LAGG mehrere VLANs liegen, macht sich 2x oder 4x LAGG bemerkbar (bei 1G). Bei 10G wirds schon nicht mehr so griffig, aber selbst da - kann Sinn machen.

Was keinen Sinn macht und ich aus der Praxis egal welcher Sense, BSD o.ä. sagen kann ist genau das was @mimugmail auch schon schreibt. Keine Kreuzverkabelung. Erstens MUSS das der Switch selbst unterstützen und Netgear ist da kein Freund von. Wir hatten es auf Juniper EX Kisten, das geht, weil die einzelnen Switche quasi als Backplanes eines einzigen Switches gesehen werden. ABER: Fällt Switch 1 aus, hast du vielleicht den Failover verhindert (ignorieren wir mal kurzes Chaos weil alle LAGGs flackern) aber nur noch die halbe Bandbreite! Das macht keinen Sinn. Man verkabelt ja dafür, dass man nicht nur Failover hat, sondern ggf. auch wegen Bandbreite. Wenn die aber keine Rolle spielt, dann erkauft man sich mit LACP kaum einen Zugewinn an Sicherheit, den man nicht eh schon durch CARP/Failover der Firewalls und 2 Switche hätte PLUS man bringt noch eine Kontrollschicht und Komplexität in die Architektur mit rein, bei der man am Fehlersuchen ist.

Ergo:

* wenn du die Bandbreite nicht brauchst - löse das LAGG auf und machs ganz ohne LACP. Viel entspannter und einfacher zu debuggen.
* wenns Bandbreite sein soll mach LACP über den gleichen Switch. FWL1 via SWT1 und FWL2 über SWT2.
Also eine H - keine Doppel-X Verkabelung.
* (nur zur Doku wenns jemand anders liest) LACP verdoppelt nicht einfach die Bandbreite. Das macht sich erst mit mehreren Quellen und Zielen bemerkbar!
* LACP über Kabel zu unterschiedlichen Switchen/Backplanes MUSS der Switch unterstützten, normal ist das nicht!

HTH
Grüße
\jens

[Felix.]

Hallo zusammen,

Sorry für die späte Antwort. 

Das HA-Konstrukt läuft jetzt seit knapp 4 Wochen und bislang bin ich ziemlich happy damit.
Die Firewalls hängen auch je an einem Switch dran, anstatt über Kreuz.
Demnächst lasse ich mal das 2. Update drüber laufen (20.7.2) - auch der Vorgang lief das 1. Mail vor Ort prima, da bin ich mal optimistisch.

Es gibt ein paar kleinere Wehwehchen sind mir noch aufgefallen, die ich auch zeitnah in weiteren Threads behandeln möchte. Aber nichts Tragisches.

Generell bin ich aber sehr glücklich mit dem jetzigen Setup.

LG
Felix

[mimugmail]

Fein, Danke für dein Feedback