CARP Failover - Nur eine virtuelle IP wechselt Cluster-Node

inzanez

Hallo

nach ein paar Versuchen im "englischen" Forum bezüglich CARP stell ich hier die Frage noch einmal. Zum Test habe ich einen virtuellen pfSense Cluster gebaut.

Node1:

WAN: 10.41.41.107
LAN: 192.168.1.1
SECURE: 192.168.2.1
PFSYNC: 192.168.3.1

Node2:

WAN: 10.41.41.108
LAN: 192.168.1.2
SECURE: 192.168.2.2
PFSYNC: 192.168.3.2

Auf dem PFSYNC Interface habe ich einfachheitshalber any any all ports als rule hinzugefügt, und dann HA-Synchronization über das PFSYNC interface aktiviert. Danach habe ich folgende virtuelle CARP IP Adressen erfasst:

WAN: 10.41.41.109, VHID 3, Passwort: "Test3"
LAN: 192.168.1.3, VHID 1, Passwort: "Test"
SECURE: 192.168.2.3, VHID 2, Passwort: "Test2"

Soweit so gut. Der erste Node ist auf allen drei Interfaces als Master angegeben:

Und auf dem zweiten Node alle in Backup state:

Testweise entferne ich jetzt das LAN Interface auf dem Node1, und das Ergebnis ist wie folgt, auf Node1:

und auf Node2:

Habe jetzt also einen Split, da nur das LAN Interface auf den Node2 gewechselt hat, der ganze Rest aber auf Node1 bleibt. Irgendetwas muss wohl falsch sein an meiner Configuration? Komme nicht drauf,…

viragomann

@inzanez:

Zum Test habe ich einen virtuellen pfSense Cluster gebaut.

Das klingt, als ob diese Test-Maschinen in einer virtuellen Umgebung laufen würden.

Falls so, schon die Troubleshooting-Empfehlung https://doc.pfsense.org/index.php/CARP_Configuration_Troubleshooting durchgenommen?

Falls nicht, könnte diese auch helfen. Jedenfalls sieht es aus, als ob die CARP-Interfaces nicht miteinander kommunizieren könnten.

voleatech

Hallo inzanez,

das Verhalten ist so wie du es beschreibst korrekt.
Carp wechselt nur die IP zum Secondary, wenn es physikalisch für das jeweilige Interface keine Verbindung zwischen den beiden Geräten gibt.
Nur weil ein Kabel fehlt, wechseln nicht alle CARP IPs den Master, sondern nur diejenige, wo die Geräte nicht mehr miteinander über das jeweilige Interface kommunizieren können.

Viele Grüße
Sven

Voleatech
pfSense Select Partner

grosser

Moin,

bin neu hier und auch mit der sense :D

Hätte zu diesem Thema eine ähnliche frage.
Habe alles nach Anleitung gemacht und auch die möglichen / bekannten fehler geprüft, laut tutorial.
Ich baue mir gerade eine HA in der Cloud (AZURE) auf und habe folgendes problem.

Bei mir werden beide pfSensen als Master angezeigt obwohl die sec einen anderen skew bekommen hat.
Sync funktioniert super, habe auch testweise ein regel auf wan und lan erstellt das carp zugelassen wird.

Arbeite mit 2.2.6. hier noch meine Einstellungen.

PF1

Wan 10.32.2.4/24
SYNC 10.32.3.4/24
LAN 10.32.4.4/24

PF2

+alles mit endung 5

viragomann

Die Funktion des Sync scheint hier oft missverstanden zu werden. Der Sync hat nichts mit der Funktion von CARP selbst zu tun, das Signal ist nur indirekt insofern beteiligt, als die States darüber synchronisiert werden, ebenso wie Firewall-Konfigurationen.
Das bedeutet, wenn der Sync funktioniert ist dies NICHT gleichbedeutend mit CARP funktioniert.

Damit CARP funktioniert muss es zum einen richtig konfiguriert sein und zum anderen, wie schon oben erwähnt, müssen die beiden an einer CARP beteiligten Interfaces miteinander kommunizieren können.
Dabei schickt der Master sog. advertisments für die jeweilige VHID ins Netz an eine Multicast-Adresss (die IP des Partners kennt er ja nicht). Kommen diese bei der Backup-Firewall nicht an, übernimmt diese den Master.

Also wenn CARP nicht ordentlich arbeiten, funktioniert meist die Kommunikation der Schnittstellen nicht. Die CARP advertisments kann man mit Packet Capture aus dem Diagnostic Menü überprüfen.
Das jeweilige Interface einstellen und das Protokoll auf "CARP" und das Capture starten. Hier muss am Master und Backup das gleiche zu sehen sein. Achte darauf, dass die Pakete von der IP des Masters kommen. Je nach Netzwerk könnte auch ein anderes Gerät dazwischenfunken, z.B. ein CARP der ISP.

In dem o.g. Troubleshooting sollte so ziemlich alles in Frage kommende genannt sein.

viragomann

@voleatech:

Nur weil ein Kabel fehlt, wechseln nicht alle CARP IPs den Master, sondern nur diejenige, wo die Geräte nicht mehr miteinander über das jeweilige Interface kommunizieren können.

Das kann ich so nicht bestätigen. Wenn ich ein Kabel auf dem Master abziehe, übernimmt die bisweilige Backup-FW den Master auf allen CARPs und am vormaligen Master werden alle CARPs als Backup angezeigt mit Ausnahme der des abgehängten Interfaces, die werden mit "Init" gekennzeichnet.

voleatech

Hi,

dann ist an deinem Setup irgendetwas nicht in Ordnung.
Carp funktioniert definitiv pro Interface, VLANs auf einem Interface sind natürlich auch betroffen beim Kabel rausziehen.

Wie oben ebenfalls gut beschrieben, passiert kein kompletter failover, wenn nur ein Interface down ist.

Viele Grüße
Sven

Voleatech
pfSense Select Partner

viragomann

Hi Sven,

es funktioniert aber so problemlos und ich kenne HA auch gar nicht anders, auch nicht von anderen Systemen als pfSense bzw. FreeBSD.
Ich habe so schon zig Failovers gemacht, keine Klagen.

Eher habe ich den Eindruck, dass hier im Forum andere Leute immer wieder Probleme mit dem Failover haben, bei denen nur ein Interface den Master wechselt, aber das kann und will ich gar nicht reproduzieren.

Grüße

JeGr

Hallo Sven,

ich würde das aber auch als hochgradig gefährlich sehen, wenn es genauso nicht passieren würde. Denn was bringt mir ein System, bei dem bspw. das LAN auf den Slave wechselt und das WAN immer noch auf dem ehem. Master liegt? Das würde jegliches sinnvolles Routing brechen, da eingehende Verbindungen auf Node #1 aufschlagen, alles abgehende aber von Node #2 aus rausgehen. Zudem wäre dann die Konfiguration völlig im Limbo -> denn wo konfiguriere ich in dem Fall dann einen Workaround? Dem alten Master? So darf CARP eigentlich nie funktionieren, es muss m.E. immer sinnvoll EIN definiertes Gerät der Master sein, und nicht zu einem Split kommen.

Hab ich bislang in all den Jahren pfSense auch noch nie so erlebt, dass bspw. ein WAN Ausfall auf einem Node nicht ein vollständiges Failover ausgelöst hätte. Und andere CARP Implementationen (bspw. auf Linux -> dort wird es ja ebenso von vielen Produkten/Projekten genutzt) lösen hier auch immer einen vollständigen Switch aus, damit ganz klar definiert ist, wer der WorkingNode ist und wer der FailedNode ist.

Ich bin da ganz der Meinung von virago. Es kann zwar sein, dass ich so ein Verhalten erreichen möchte (wenn ich sowas wie active-active bauen wollen würde), aber ansonsten kann ich mir nicht vorstellen inwieweit das gewollt ist.

Grüße

Edit:
In der ursprünglichen OpenBSD CARP Doku ist auch ganz klar aufgeführt, dass alle CARP Interfaces Mitglieder der CARP Gruppe sind und daher gemeinsam failovern sollen. Wenn nicht alle CARP Interfaces switchen sollen, müssten spezifisch andere Gruppen eingerichtet werden (Beispiel: https://www.openbsd.org/faq/pf/carp.html#forcefail) um bspw. sowas wie active/active oder loadbalancing via Carp zu fahren (was unter FreeBSD aber nicht wirklich mehr möglich ist, da andere Implementierung). Meinem Verständnis nach, ist somit der full-failover der gewünschte und default-Fall der auftreten soll.

Edit 2:
Das war auch schonmal Gegenstand eines Bugreports: https://redmine.pfsense.org/issues/1248
Getriggert wird das Verhalten durch den preempt Sysctl Schalter: net.inet.carp.preempt: 1
Der ist zumindest bei meinen Kisten in Default Installation immer an gewesen.

JeGr

@grosser: Bitte kein Thread-Hijacking, da du ein SplitBrain mit 2 Mastern hast, ist das eine ganz andere Problemstellung. Bitte mach dafür doch einen extra Thread auf - Danke :)

voleatech

Hi,

ja, ihr habt recht, sorry for that.
So lange net.inet.carp.preempt: 1 ist, sollte der Backup alle VIPs übernehmen.

Viele Grüße
Sven

Voleatech
pfSense Select Partner

viragomann

@JeGr:
Vielen Dank für den Link zu den OpenBSD FAQs. Danach hatte ich, von voleatech verunsichert, gesucht um die Sache zu untermauern, jedoch nichts gefunden. :)

JeGr

@virago: immer gern :)

Fein, dann sind wir ja alle wieder auf dem gleichen Nenner ;)

@inzanez: Wie sieht es denn sonst mit der Checkliste aus bei CARP Problemen? Interface Namen/Reihenfolge identisch, VIPs etc. soweit alle klar? CIDR Einstellungen der VIPs OK? Also mal die ganzen Troubleshooting Einstellungen durchgegangen? Und wie schaut es mit der Preempt Setting aus? Ist das bei dir brav auf 1 gesetzt? Nicht dass das bei Neuinstallationen rumbuggt?

Gruß

d4sId

Hallo JeGr

Ich habe aber auch hier die Problematik, dass wenn ich ein Interface auf der primären Firewall ausschalte, auf der sekundären Firewall nur dieses Interface auf Master wechselt, alle anderen Interfaces bleiben.

Gruss

![Iface aus auf primary.png](/public/imported_attachments/1/Iface aus auf primary.png)
![Iface aus auf primary.png_thumb](/public/imported_attachments/1/Iface aus auf primary.png_thumb)

secondary.png_thumb

JeGr

Alleine, dass da noch 2 Interfaces auf INIT stehen, ist ja schon nicht gesund. Ansonsten müsste hier wie gesagt mal die CARP Checkliste bei Troubleshootings durchgegangen werden. Sind die OPT Interfaces gleich, physikalische gleich, pingbar etc. gleiches VLAN usw.
Und dann natürlich die Variable mal checken: net.inet.carp.preempt ob das aus einem alten Setup/Konfig heraus mal anders eingestellt war.

blex

Hallo,

damit CARP einen ordentlichen Master / Slave erreicht, müssen sich die beiden Interfaces sehen können. Teilweise wird hier auch die Mac von Master / Slave zwischen den Interfaces hin und her getauscht. Das macht oft bei Virtuellen Umgebungen Probleme da hier immer nur die MAC Adresse der Virtuellen Netzwerkkarte erlaubt wird. Weiterhin meine ich im Kopf zu haben das hier auch teilweise Multicast genutzt wird. Dieses wird teilweise auch gefiltert.

Also bitte prüfen ob Multicast zugelassen ist und ob weitere MAC Adressen auf dem Port erlaubt sind oder ob die weg gefiltert werden.