CARP-Fehler

[almo]

Hallo Zusammen,

beim Cluster Reboot habe ich immer wieder mal aber ohne Muster folgende Fehlermeldung:

CARP hat ein Problem erkannt und diese Einheit wurde auf den BACKUP Status herabgestuft.
Überprüfen Sie den Link Status aller Schnittstellen mit CARP VIP Konfiguration.

Und dann ist ein Teil auf Backup und ein Teil auf Master. Wenn ich dann Carp deaktiviere und wieder aktivere sind alle Master und auf der anderen FW alle Backup.

Wo finde ich den in welchem Log mehr Informationen dazu um den Fehler zu finden.

[mimugmail]

Console beim Hochfahren, dmesg, system.log.
Ist der Port am Switch auf portfast?

[almo]

Console beim Hochfahren, dmesg, system.log.

Steht leider nichts drin, nur die Timeouts vom Carp als das Netz weg war. Aber leider nicht warum er als das Netz wieder da war nur einen teil Zurück holen konnte und den anderen nicht.

Ist der Port am Switch auf portfast?

Sind 10G LWL Verbindungen und Karten. Extern sind 10G und die internen Verbindungen sind 2x 10G als ein LACP.
Denke nicht das es da ein Portfast geben sollte ...

[mimugmail]

Spanning Tree hat doch nichts mit LWL oder Kupfer zu tun?

[mgoerke]

Spanning Tree hat doch nichts mit LWL oder Kupfer zu tun?

Portfast bedeutet, dass SpanningTree nicht abwartet, sondern die (Access-)Ports direkt ins Forwarding bringt. Dies sollte hier kein Problem sein, da früher oder später die Frames dann doch weitergeleitet werden.
Nein, SpanningTree hat nichts mit Kupfer oder LWL zu tun.

Die Frage ist, ob IGMP Snooping sich in die Mutlicast Pakete einmischt. Um das Auszuschließen, wäre eine testweise direkte Verkabelung statt über einen Switch hilfreich.

[mgoerke]

Fehlversuche:
Wenn du per tcpdump auf den Interfaces mitloggs, dann sollte es nur von einem Interface carp/vrrp Packet (Type 112) geben.
Senden beide Interfaces CARP-Pakete, so sehen sich die CARP-Member nicht, warum auch immer. Mit einer direkten Verkabelung kann der Switch ausgeschlossen werden.

Ebenso sollte Preemtion geprüft werden, es muß derart eingestellt sein, dass der geplante Master auch immer wieder sich zum Master priorisiert.

[JeGr]

Zudem hat der OP leider nichts dazu geschrieben über welches Interface Sync läuft und wie das verkabelt ist.

[almo]

Ich werde noch irgendwie wahnsinnig.

Plötzlich war das Problem weg, jetzt ist es wieder da.

Die beiden FWs sind direkt auf Kupfer 1G miteinander Verbunden zum Sync. Da ist kein Switch dazwischen da geht ein 80 Meter Kabel von Firewall Master zur Firewall B.

Jetzt ist mir auch aufgefallen das die IP Aliase nicht erreichbar sind. Sprich wenn die Master z.b rebootet wirft es alles auf die Standbye die wird aktiv und Master. Aber die NAT's und Freigaberegeln reagieren irgendwie nicht. Sprich Websiten laden und laden und laden und nichts passiert.

Wenn ich aber auf den CARP Status gehe sehe ich 14 pfSync-Knoten.

Ich habe auf jedem Interface unter Regeln folgendes drin stehen:
IPv4 CARP   *   *   *   *   *   *

Und bei meine Sync-Schnittstelle da Sie ja direkt gesteckt ist eine:

IPv4*   *   *   Diese Firewall

[mimugmail]

Das hört sich nach DNS an. Hast du auf 20.7.7 geupdated? Dann bitte noch mal Hotfix release einspielen.
Geh mal auf die CLI und mach "ping heise.de" ob er das auflöst.

[almo]

Ist    OPNsense 20.7.7_1-amd64.

Wenn ich in den Wartungsmouds gehe legt es die Carps sauber auf die Backup Firewall aber die IP-Alias Adressen auf der WAN Schnittstelle die dann auch NATs von WAN zu den internen Diensten haben sind wie tot oder gelähmt vom verhalten. Auch über das LTE Netz läde es ewig und drei tage.