Interface Anpassungen am CARP Master -> wird zu Slave - normales Verhalten?

[c-mu]

Hallo Community,
ich muss zur Zeit einige Anpassungen an den IP's am Master und Slave machen.
Mir ist dabei aufgefallen, dass sobald ich eine Änderung am Master vornehme, in dem ich z.B. eine IPv6 Adresse auf ein Interface lege, dass der Master seinen Status aufgibt und zum Backup Server wird. Der Slave übernimmt dann die Master Rolle.

Ich muss dann hinterher manuell die Masterrolle wieder zurecht rücken. Das er nicht automatisch wieder Master wird, habe ich deaktiviert, damit im beispielsweise Problemfall eines Flapping State nicht immer hin und her getauscht wird.

Ist dieses Verhalten denn normal, oder deutet dies auf eine Fehlkonfiguration hin?

Danke!

[c-mu]

Ich habe diese Frage im HA- Forum erneut gestellt, da scheint es besser aufgehoben zu sein:
https://forum.opnsense.org/index.php?topic=24004.0

[JeGr]

Die Frage ist, wie packst du die IP6 da rauf? Hast du auf beiden Nodes die IP6 konfiguriert und draufgepackt? Auch eine VIP für v6? Was sagen die Logs dazu?

[c-mu]

Hi,
sorry für die späte Antwort:

Auf beiden Interfaces, also Master und Slave sind die IPv6 Adressen eingerichtet und anschließend habe ich erst via IP Alias auf eine vorhandene CARP VHID gelegt. Das funktioniert ja auch an sich.

Ich habe noch kein 100%iges Vertrauen, daher mache ich erst nach Feierabend IP Änderungen, aber ich habe einen Workaround:

Wenn ich auf dem SLAVE CARP temporär deaktiviere, dann kann ich in der Regel alle Änderungen ohne Probleme durchführen.

Das Logfile geht mir gerade nicht weit genug zurück, aber es stand meines Wissens nur ein Einzeiler im Log, der "sagte das da ein Event stattfand". Ggf. finde ich das noch wieder.

[JeGr]

> Auf beiden Interfaces, also Master und Slave sind die IPv6 Adressen eingerichtet und anschließend habe ich erst via IP Alias auf eine vorhandene CARP VHID gelegt. Das funktioniert ja auch an sich.

OK halt, kannst du das ggf als Screenshot zeigen bzw. an Hand von Beispiel Adressen erklären? Wenn du IP6 auf einem Interface konfigurierst (sowohl auf Primary als auch Secondary Node), dann legst du im Normalfall ja erst nochmal eine neue CARP style VIP an mit IPv6. Hast du das oder hast die direkt die erste VIP mit v6 schon auf eine ANDERE VIP gelegt? Das würde dann erklären warum es nicht klappt.

Im Prinzip hat man auf jedem VLAN/Interface: eine VIP mit VHID bspw. 4 für IPv4 und eine mit VHID bspw. 6 für IPv6. Jede weitere VIP kann man dann - je nach v4 oder v6 - auf die entsprechend schon vorhandene VIP als Alias draufsetzen. Aber eine v6 auf bpsw. eine v4 huckepack als Alias zu definieren - das geht IMHO eher schief.

CHeers

[c-mu]

Also ich habe dutzende VLAN's.
Jedes VLAN/Interface hat seine static IPv4 + IPv6 konfiguriert.
Ich habe in jedem VLAN jeweils eine CARP IPv4.

Da ich in jedem VLAN schon eine IPv4 CARP Adresse habe, und die Systeme sich darüber gegenseitig erkennen und merken das der Master/Slave ggf. weg ist, habe ich mir gedacht, das ich nicht noch mehr Broadcast Traffic erzeugen muss als unbedingt nötig und habe deshalb in jedem VLAN die IPv6, die ich normalerweise als CARP IP anlegen würde, eben als IP Alias erzeugt. Die ist auch immer bei der jeweiligen Firewall ansprechbar, die die Masterrolle inne hat.

Der IP Alias ist natürlich immer auf die ensprechende VHID gemappt, bei dem das Interface die entsprechende IPv4+6 Adresse auch konfiguriert ist.

Ich konnte heute Abend eine Anpassung machen, in dem ich auf dem Slave zu erst CARP deaktiviere, dann auf dem Master die Anpassungen mache, Synce und anschließend wieder CARP aktiviere. So scheint es reibungslos zu laufen.

[JeGr]

Das muss ggf. jemand anders beantworten, ob das per se funktionieren soll, ich kenne es so, dass das pro Protokoll - und IPv6 ist ein anderes Protokoll als IPv4 - eine CARP VIP sein muss und damit gab es auch noch nie ein Problem. Ich würde daher erst einmal die erste IPv6 als CARP IP definieren und ggf. weitere wenn vorhanden dann als Alias IPs auf dieser CARP VIP.

Es ist auf jeden Fall kein Normalfall, dass man ERST irgendwas abschalten muss bevor es sauber gesynct wird etc. Das ist ja kein HA mehr bzw. kein ordentlicher Sync mehr wenn ich ständig in den Prozess eingreifen muss.

[mimugmail]

Ja, ich würde je Protokoll eine VHID, also WAN VHID v4 = 14 und WAN VHID v6 = 16 .. also immer 4 und 6.
Einfach zu merken

[mimugmail]

P.S.: Da glänze ich aber auch nur mit Halbwissen. Bin grade dabei so einen Cluster live zu setzen, ist aber eher für September angepeilt.

[JeGr]

Ich bau für den Test von sowas gerade unser Lab aus, damit wir auch nen virtuellen Cluster haben um sowas zu testen, aber das haut immer nur hin wenn Zeit über ist und daran krankt es gerade Daher kann ichs auch nicht direkt nachbauen, würde aber meinen da unterschiedliches Base Protocol auch Unterschiede bei der Multicast Anfrage und Antwort und daher würde ich meinen klemmt es dann auch beim Schwenk - aber gerade auch nur Vermutung + Halbwissen