CARP Status verschwindet nach failover

[mimugmail]

Bei einem funktionierenden Sync sollte bei Anlage von Carp Interface die Skew auf dem Backup automatisch erhöht werden. Das ist dann auch grau hinterlegt wenn ich mich richtig erinnere.

[linuxmail]

hi,

ich klinke mich mal hier ein, da es danach aussieht, als wenn das Problem exakt dem entspricht, was wir hier haben: https://forum.opnsense.org/index.php?topic=8915.0

Ich versuche jetzt die Onboard Netzwerkkarte durch USB zu ersetzen (keine freien Slots/Ports mehr) und dann schauen wir, ob das Problem besteht. Ich vermute es wird funktionieren.

[mimugmail]

Wenn es funktioniert würde deine Theorie mit pfSense nicht ganz Sinn machen? Halt uns da mal auf dem Laufenden. Hast du auf GitHub in core schon nen issue dazu?

[tt-ah]

Abweichung bei mir wäre, dass der Promiscious Mode tatsächlich deaktiviert wird und nicht nach UP des Interfaces aktiviert wird.

(s. Log in früherem Post)

[clystron]

Der ifconfig-Fehler beim Durchlaufen von rc.newwanip killt den CARP-status, es gibt hier scheinbar einen Bug im BSD-Source.

Siehe https://github.com/opnsense/core/issues/2486 bzw. https://redmine.pfsense.org/issues/6892

[tt-ah]

Danke für die Info clystron!

Den Bug #6892 hatte ich auch gefunden, aber abgehakt, da er als resolved markiert war. Das neue Topic im Github ist aber sehr interessant! Also dann doch warten bis 18.7 

[clystron]

Ich hab mir testweise einen Workaround gebastelt der das ifconfig Kommando einfach wiederholt wenn es fehlschlägt. Ideal ist das natürlich nicht aber es scheint zu wirken.

[franco]

Mit clystrons Hilfe haben wir den Fix aus FreeBSD erfolgreich getestet und in die kommende Version 18.7 übernommen.

> Den Bug #6892 hatte ich auch gefunden, aber abgehakt, da er als resolved markiert war.

Ein Bug der 1 Jahr alt ist wobei wir schon vor 3 Jahren geforkt haben sollte skeptisch beäugt werden.


Grüsse
Franco

[tt-ah]

Stimmt, da war ja was 

Cool, dass ihr es fixen konntet. Freue mich aufs Update 

[franco]

Oder gleich testen:

# opnsense-update -kr 18.1.9-next -n "snapshots\/dummy"
# /usr/local/etc/rc.reboot


Grüsse
Franco

[tt-ah]

Patch habe ich getestet, das Problem mit dem CARP-Interface tritt nicht mehr auf. 

Jedoch ist es nun wieder so, dass beim Ausfall eines Interfaces nur das eine Interface an den Slave abgegeben wird. Das zweite Interface bleibt beim Master :/

Das hatte vor dem Patch noch funktioniert. Das Tunable net.inet.carp.preempt "1" ist gesetzt...

Hat da jemand eine Idee?


Jun 28 14:58:05   kernel: carp: 1@igb0: BACKUP -> MASTER (preempting a slower master)
Jun 28 14:58:04   opnsense: /usr/local/etc/rc.carpmaster: Starting OpenVPN server instance on xxx.xxx.xxx.xxx - WAN_CARP because of transition to CARP master.
Jun 28 14:58:04   opnsense: /usr/local/etc/rc.carpmaster: Carp cluster member "xxx.xxx.xxx.xxx - WAN_CARP (2@igb1)" has resumed the state "MASTER" for vhid 2
Jun 28 14:58:04   kernel: carp: 2@igb1: BACKUP -> MASTER (preempting a slower master)
Jun 28 14:58:04   kernel: carp: demoted by -240 to 0 (pfsync bulk fail)
Jun 28 14:57:04   opnsense: /usr/local/etc/rc.carpbackup: Carp cluster member "192.168.123.1 - LAN_CARP (1@igb0)" has resumed the state "BACKUP" for vhid 1
Jun 28 14:57:04   opnsense: /usr/local/etc/rc.carpbackup: Carp cluster member "xxx.xxx.xxx.xxx - WAN_CARP (2@igb1)" has resumed the state "BACKUP" for vhid 2
Jun 28 14:56:58   kernel: carp: 1@igb0: MASTER -> BACKUP (more frequent advertisement received)
Jun 28 14:56:58   kernel: carp: demoted by 240 to 240 (pfsync bulk start)
Jun 28 14:56:58   kernel: carp: 2@igb1: INIT -> BACKUP (initialization complete)
Jun 28 14:56:01   opnsense: /usr/local/etc/rc.carpmaster: Carp cluster member "192.168.123.1 - LAN_CARP (1@igb0)" has resumed the state "MASTER" for vhid 1
Jun 28 14:56:00   kernel: carp: 1@igb0: BACKUP -> MASTER (preempting a slower master)
Jun 28 14:56:00   opnsense: /usr/local/etc/rc.carpbackup: Carp cluster member "192.168.123.1 - LAN_CARP (1@igb0)" has resumed the state "BACKUP" for vhid 1
Jun 28 14:56:00   kernel: carp: demoted by -240 to 0 (vhid removed)
Jun 28 14:55:59   kernel: carp: 1@igb0: MASTER -> BACKUP (more frequent advertisement received)
Jun 28 14:55:59   kernel: carp: demoted by 240 to 240 (interface down)
Jun 28 14:55:59   kernel: carp: 2@igb1: MASTER -> INIT (hardware interface down)

[mimugmail]

Preempt aber bitte nur auf dem Slave oder?

[tt-ah]

Hatte es auf beiden Systemen. Aber auch wenn es nur auf dem Slave eingerichtet ist, der Master wird ja trotz inaktivem Interface wieder auf 0 promoted:

Jun 28 14:56:00   kernel: carp: demoted by -240 to 0 (vhid removed)
Jun 28 14:55:59   kernel: carp: 1@igb0: MASTER -> BACKUP (more frequent advertisement received)
Jun 28 14:55:59   kernel: carp: demoted by 240 to 240 (interface down)

Dann wird der Slave das ja auch nicht übernehmen.

[clystron]

Also bei mir hat der Patch nichts in der Richtung geändert, mein Testsetup besteht aus zwei Firewalls mit LAN/WAN/DMZ und alle Interfaces wandern zum Slave wenn ich am Master eins abziehe.

Preempt ist bei mir auf beiden Hosts gesetzt, laut FreeBSD CARP-Manpage sollte das so sein ("Enable it on   both hosts A and B")

Edit: was mich stutzig macht ist die "vhid removed" message die dann wieder zur Rückkehr auf 0 führt, die hab ich nicht und die sollte doch auch nicht sein würd ich sagen

Wolfgang

[mimugmail]

Preempt ist bei mir auf beiden Hosts gesetzt, laut FreeBSD CARP-Manpage sollte das so sein ("Enable it on   both hosts A and B")

Das ist Geschmacksache .. ich mag die Primärfirewall immer Master haben wenn die auch i.O. ist.