CARP Master zurück wechseln schlägt fehl

[xee]

Moin,

ich teste aktuell OPNsense auf zwei Identischen Servern als HA Firewall.

Das Setup sieht momentan so aus:

10GBit Nic (ix0) darauf VLANs für WAN(61) und für LAN(21)
1GBit Nic (igb0) für sync

Auf WAN habe ich eine Gemeinsame IP eingerichtet nach Anleitung.

Auf der zweiten Maschine habe ich Skew auf 100 gesetzt damit der Master wenn möglich immer auf der ersten läuft.

Trenne ich Server1 ix0 vom Switch wird Server2 Master.
Verbinde ich Server1 ix0 wieder zum Switch bleibt Server2 Master, Server eins gibt eine Fehlermeldung aus und bleibt Backup:

CARP has detected a problem and this unit has been demoted to BACKUP status.
Check link status on all interfaces with configured CARP VIPs.

Energiesparoptionen habe ich per tunables auf allen Karten deaktiviert.

Ich bin nach einigem hin und her Testen inclusive frischer Installation ein wenig ratlos und bin schon fast versucht nach einer alternativen Firewall zu schauen, dabei bin ich mit einer Einzelnen OPNsense ohne HA seit Monaten sehr zufrieden.

Vielleicht kann mir ja Jemand den entscheidenden Hinweis geben woran es hakt.

Viele Grüße

[mimugmail]

Du hast beim Einrichten was falsch gemacht. Der Fehler erscheint wenn was mit den Interfaces nicht passt. Such Mal nach Carp Vlan und Beiträgen von Wayne Train. Da hab ich n kurzes Howto mit Tunable geschrieben wie das funktioniert.

[xee]

Danke für die schnelle Antwort.

Du meinst diesen Thread? https://forum.opnsense.org/index.php?topic=5412.15

Die "Disable preempt" Checkbox hatte ich ohnehin nicht angewählt. Die "net.inet.carp.senderr_demotion_factor=0" tunable habe ich auf beiden Geräten gesetzt und jeweils gerebooted.

Geändert hat sich leider nichts.

[mimugmail]

Dann ist da grob was falsch. Kannst du bitte Carp ohne Vlan testen ob das klappt?

[Wayne Train]

Hi,

bei mir lag das Problem nicht an der Konfiguration, sondern an dem verwendeten Release. Zwei Updates später ging das wieder. Zu war es zumindest bei mir. Dennoch hat Mimugmail nicht unbedingt unrecht. Bei der verwendung von VLANs und CARP kann man schnell einen Fehler machen. Ich hatte auf einem anderen System mal das Problem, dass ich die Interfaces auf den beiden Nodes nicht exakt in der gleichen Reihenfolge erstellt habe. Wenn die VIPs dann hinterher sprechen wollen, führt das zu Chaos.

Was du mal testweise machen kannst um sowas auszuschliessen: Die Konfig des Backups sichern, die des Masters exportieren, modifizieren (also IPs anpassen, Hostnamen, Skew, und das disablen von Sync-to usw.) und dann auf dem Slave wieder einspielen. Dann hast du definitiv die gleiche Interface-Reihenfolge und (fast) gleiche Konfig.

Nutz du VLAN Interfaces über LAGGs ? Darin lag mein Problem. Bei mir hat CARP im Zusammenhang mit LAGGs und VLANs beim Entfernen eines Kabels aus einem LAG-Port (LAN-Seite) zu einem Failover geführt, der sich allerdings auch nur lan-seitig ausgewirkt hat. Sprich ich hatte einen Split-Brain, der sich auch ohne ein paar mal zwischen Maintenance Mode hin und herzuschalten auch nicht mehr lösen ließ. Konsolenseitig hat sich das Ganze dadurch bemerkbar gemacht, dass die carp-demotion auf beiden Büchsen amok gelaufen ist.

Kann mich zwar nicht mehr an alles erinner (das Thema war ein einziger Brainfuck), aber falls du Fragen hast, melde dich. Ich versuch's dann mal.

LG
Wayne

[JeGr]

Genau, was Wayne sagt. Unbedingt überprüfen, dass bspw. die VLAN Interfaces genau in der gleichen Reihenfolge zugewiesen wurden und intern die gleiche OPTx ID haben. Fatal wäre es, wenn auf dem einen Node bspw. WAN Opt1 und auf dem anderen Opt2 wäre, dann bekommst du ruck-zuck einen SplitBrain.

Ich würde sicherheitshalber auch erstmal direkt auf dem Interface ohne VLAN testen. Auch den Zustand vor dem Failover prüfen (sauberer CARP Status Master/Backup). Und dann nochmals mit WAN als VLAN, durchtesten und dann erst das zweite VLAN für LAN anlegen und nochmals testen. Wichtig auch wie bei Wayne: CARP Failover muss für alle Interfaces bei Ausfall von einer VIP durchgeführt werden - nicht nur für dieses Interface - sonst ist der Clusterfuck komplett

[Perun]

wieso macht man es eigentlich so? wäre es nicht viel eleganter/flexibler auf die description des interfaces zu matchen? Dann könnte man dadrunter haben was man will... ich habe z.B. 2 ungleiche router (apu2c4 und ne xen vm) wo es schwierig ist ohne zu tricksen die interfaces identisch gleich einzurichten...

Greetz

[JeGr]

Genau WEIL OPT eine interne Bezeichnung ist, macht man es ja wie du sagst. OPT1/2/3 ist eine willkürlich gewählte interne Bezeichnung der Sensen und hat KEINEN Bezug zum physischen Interface. Deshalb kannst du überhaupt ein CARP Interface einrichten auf 2x opt1 bspw. und es ist einmal bspw. igb2 und auf der anderen Seite ein re5. Dass das absolut unschön und praktisch komplett vermieden werden sollte überhaupt zwei so unterschiedliche Systeme zu nutzen steht auf einem anderen Blatt. Aber machbar ist es - wenngleich eben mit der Einschränkung, dass man aufpassen muss was man tut.

[Perun]

ok verstanden, dann sollte aber eine einfache Möglichkeit geschaffen werden die Namen (opt etc) anzupassen/ändern...

Greetz

[JeGr]

Man muss immer auch technische Umsetzung/Umsetzbarkeit und Komfort gegenüber Features abwägen. Ja ich habe noch 1000 andere Funktionen, die ich mit PF und CARP bspw. machen _könnte_ - aber das sinnvoll und relativ einfach und fehlerunanfällig für eine breite Masse verfügbar zu machen ist nicht wirklich einfach. Und irgendwelche Interface Aliase o.ä. einfach wild zuzuweisen kann im Fall der Fälle mehr kaputt als ganz machen. Dass das dann nicht frei wählbar ist, finde ich nicht so unverständlich auch wenn es an der Stelle zu umständlicherem Verhalten führt.