CARP / HA kurzer PING Timeout nach Reboot der Backup Maschine
-
Hi,
vielleicht versteh ich auch was falsch, aber folgendes ist mir aufgefallen.
Ich setze die Backup Maschine in "persistent carp maintenance mode" und reboote die Maschine.
Nach dem die Backup Maschine wieder hochgefahren ist habe ich auf allen IP's kurz Timeouts (3-4), was aber schon einige Anwendungen raus schmeisst.
Die Sync Interface sind direkt per Kabel (kein Switch dazwischen) angebunden.
VIP 192.168.62.1
CARP 1: 192.168.62.2
CARP 2: 192.168.62.3
Kann in den Logs nichts auffälliges finden.
Hat jemand eine Idee wo ich angreifen kann?
Danke!
Erik
-
@richie1985
Hallo,das Rebooten der Backup pfSense sollte überhaupt keine Auswirkung auf Verbindungen durch die Firewall haben. Der ganze Traffic läuft ja über die Master Box.
Dazu muss sie nicht mal in den Persistent Maintenance Mode gesetzt werden.Ich kenne übrigens gar keinen vernünftigen Grund, die Backup jemals in den Persistent CARP Maintenance Mode zu setzen. So lange sie nicht Master ist, kannst du auf der basteln, was du willst, es sollte keinen Einfluss auf die Verbindungen haben.
Du pingst hier die Interface IPs des CARP-Systems selbst. Es macht wohl mehr Sinn, die Verbindungen durch die Firewall zu prüfen.
Das Outbound NAT hast du auf die CARP-IP gesetzt?
Siehst du irgendeine Unterbrechung der Gateways im Log am Master? -
@viragomann
carp ip natürlich im outbound nat gesetzt.
letzte logs im gateway monitoring irgendwann von september ^^was meinst du mit "Es macht wohl mehr Sinn, die Verbindungen durch die Firewall zu prüfen"?
-
@richie1985
Na ja, Ziel der Sache ist es ja nicht, dass die beiden redundanten Firewalls über einen Failover hinweg unterbrechungsfrei erreichbar sind, sondern Hosts im Internet von internen Geräten und eventuell umgekehrt.Aber dennoch, normal ist es nicht. Die Master sollte immer erreichbar sein, unter beide IPs.
Ich könnte mir nur denken, dass die Regeln neu geladen werden, aber das würde sich auch im Log finden. -
@viragomann said in CARP / HA kurzer PING Timeout nach Reboot der Backup Maschine:
Ich kenne übrigens gar keinen vernünftigen Grund, die Backup jemals in den Persistent CARP Maintenance Mode zu setzen. So lange sie nicht Master ist, kannst du auf der basteln, was du willst, es sollte keinen Einfluss auf die Verbindungen haben.
Da mag ich einhaken: es macht durchaus Sinn es vorsichtshalber zu setzen. Bei Fehlern/Störungen im Netzwerk oder auf dem Switch hat man sonst die Situation, dass sich die Geräte gegenseitig sonst nicht sehen oder gestört sind und beide dann auf master wechseln. Und master/master SplitBrain will man eigentlich immer vermeiden. Gerade in größeren Umgebungen wo nicht nur einer sondern ggf. mehrere Switche dazwischenhängen, kommt das gern mal vor, dass dann doch auf einem Access oder dem Core Switch ein VLAN vergessen wird und dann plötzlich die eine Hälft des Netzes auf der einen und die andere auf der anderen Firewall hängen. Unschön :)
Dann besser die 2. gar nicht erst Master werden lassen können.Ansonsten aber richtig, wenn der Standby Node mit persistent mode hochgefahren wird, darf der zu keiner Zeit mal kurz Master werden und den Betrieb stören. Das "kurz Master werden" würde sich aber im Syslog zeigen, dass der CARP State kurz auf Master und dann wieder auf Backup gewechselt hat. Darf aber wie gesagt nicht sein. Da sollte man die Config vom Cluster mal abklopfen und sich beide Nodes genau anschauen ob sich nicht irgendwo ein Fehler eingeschlichen hat.
-
Hi,
das ist das was pfsense 1 (also die die nicht neugestartet wird) im logs ausspuckt:
ist da irgendwas "nicht" okay?
-
@richie1985 Nö das sieht OK aus. Das igb0/Sync wird wohl direkt verkabelt sein, daher der Hotplug Event mit dem UpDown-Girl ;) Ansonsten sieht man da leider bezogen auf CARP nicht viel.
