CARP/HA Probleme

[bewue]

Moin Leute,

mir sind einige Dinge im Zusammenhang mit CARP und dem HA-Verbund aufgefallen.
Vielleicht könnt ihr mich ja aufklären
Version ist 18.1.6

1. CARP/XMLRPC: Falsche Zuordnung der Interfaces auf Backup-Maschine bei XMLRPC synchronisierung
  Den virtuellen IPs vom Typ CARP werden bei der synchronisierung unter Umständen die
  falschen Interfaces zugeordnet.

  Anscheinend müssen die initialen Interfacenamen also z.B. LAN und OPT1
  den gleichen System-Interfaces (xn0) wie auf der Backup-Maschine zugeordnet sein.
  Der Zuordung bei "Interfaces -> Assignments" kann nicht vertraut werden.
  Somit muss bei "Interfaces -> Overview" die initiale Zuordnung auf beiden Maschinen übereinstimmen.
  Das ist irgendwie versteckt bzw. verwirrend, oder?

2. Welche Firewallregeln müssen für CARP/PFSYNC/XMLRPC erstellt werden?
  Anscheinend kommen CARP und PFSYNC ohne Regeln durch, XMLRPC (TCP 443) benötigt aber eine?

3. CARP Authentication wird nicht angewandt, trotz angabe von Password im GUI?
  (Wegen der gleichen IP Protokollnummer (112) werden CARP pakete von tcpdump als VRRPv2
  Pakete geparsed, das scheint aber trotzdem aussagekräftig zu funktionieren!?)
  Jedenfalls zeigt mir tcpdump "authtype none" an. Des Weiteren sehe ich kein Feld
  welches den SHA1-HMAC enthalten könnte.

4. Der Prio-Wert in den CARP Advertisements hat maximal den Wert 240 (mit tcpdump überprüft)
  Der Prio-Wert ist ja anscheinend direkt der Skew-Wert den man in der GUI einstellen kann.
  Die Backup-Maschine bekommt dann über XMLRPC den Skew-Wert vom Master + 100.
  Wenn auf dem Master ein Wert >=240 eingetragen wird bekommt die Backup-Maschine den Wert 254.
  Ab einem Wert >=240 auf dem eigentlichen Master wird die Backup-Maschine zum neuen Master:
  Der Zustand ist dann z.B.:
  Eigentlicher Master: 250
  neuer Master: 254
  (Der neue Master sendet aber weiterhin nur CARP Advertisements mit dem Wert 240)
  Obwohl der Skew-Wert auf dem eigentlichen Master noch niedriger ist, ist die Backup-Maschine
  neuer Master geworden? (advbase war immer 1)
 
  Die magische Zahl 240 sowie der Wechsel des Masters sind mir hier unverständlich.
  Kann mich jemand erleuchten?

5. Die Option "Disable preempt" bei "System -> High Availibity -> Settings" befindet sich unter der Überschrift
  "State Synchronisation". So wie ich das sehe hat diese Option aber garnichts mit der State Synchronisation,
  also PFSYNC zu tun.

[JeGr]

1) Nein das ist dokumentiert und bekannt. Bei CARP müssen die Schnittstellen UND die intern vergebenen OPTx Bezeichnungen auf beiden Geräten identisch sein, sonst kommt es zu Problemen.

2) Nein kommen sie nicht. pfSync wird auf einem bestimmten Interface konfiguriert, normalerweise ein extra Interface nur dafür. Dort muss pfSync - oder wenn exklusiv nur als Sync Interface gedacht - besser einfach alles erlaubt werden, da hier nicht nur pfSync, sondern auch XMLRPC via WebUI Port zugreift, es sei denn dafür wäre eine andere IP konfiguriert.

3) CARP ist nichts anderes als VRRP. Es ist eine OpenSource und nicht lizenzpflichtige re-Implementierung von VRRP/HSRP etc. da der "ISO Standard" eigentlich Cisco gehört und man da nicht die Hand aufhalten lassen wollte.

4) Warum sollte man den Master und seinen Skew Wert überhaupt anpassen/anfassen? Es gab schon diverse kleinere Probleme mit Master Werten >100 somit sollte der Wert auf dem Master (0) eigentlich eh nicht angefasst werden und hat nur dann Relevanz, wenn man Daisy-Chaining mit einem dritten (und ggf. vierten) Knoten nutzen würde.

Gruß

[bewue]

schonmal vielen Dank für deine Antworten JeGr.
Ich hätte da noch folgende Rückfragen.

3) CARP ist nichts anderes als VRRP. Es ist eine OpenSource und nicht lizenzpflichtige re-Implementierung von VRRP/HSRP etc. da der "ISO Standard" eigentlich Cisco gehört und man da nicht die Hand aufhalten lassen wollte.

Also die Funktionsweise von CARP und das RFC von VRRP zeigen aber fundamentale Unterschiede...
(https://www.ietf.org/rfc/rfc3768.txt, Abschnitt "5.3.4. Priority" z.B.)

Zu CARP scheint es wenig konkretes zu geben.
Über den Aufbau des Protokoll-Headers für die Advertisements z.B. konnte ich im Internet nichts finden...

Und was ist mit der Authentication?
Bzw. für was ist das "Virtual IP Password" bei der virtuellen CARP IP?

4) Warum sollte man den Master und seinen Skew Wert überhaupt anpassen/anfassen? Es gab schon diverse kleinere Probleme mit Master Werten >100 somit sollte der Wert auf dem Master (0) eigentlich eh nicht angefasst werden und hat nur dann Relevanz, wenn man Daisy-Chaining mit einem dritten (und ggf. vierten) Knoten nutzen würde.

Das Verhalten von CARP an dieser Stelle ist für mich einfach undurchschaubar und ich würde es gerne verstehen.
Wenn das by design bei CARP so ist, sollte dazu doch etwas dokumentiert sein.
Ich konnte bisher in dem Internetz leider nichts dazu finden.

[JeGr]

Also ein bisschen Background zu CARP zu finden, ist nicht schwer...
-> https://de.wikipedia.org/wiki/Common_Address_Redundancy_Protocol
führt einen u.a. zu:
-> https://man.openbsd.org/carp
-> https://www.openbsd.org/faq/pf/carp.html

Wie gesagt ist CARP als freie Alternative zu VRRP und HSRP entwickelt worden. Ich habe damit nicht andeuten wollen, dass es eine vollständig identische Re-Implementierung ist - würde dank den tollen Cisco und Co Patenten wohl kaum funktionieren. Trotzdem bleibt der Sinn gleich und auch die bspw. verwendeten MAC Adressen für CARP VIPs sind Deckungsgleich mit den VRRP/HSRP Varianten. Daher ist beim Betrieb in der gleichen Broadcast Domain wie andere HA Switche/Geräte Vorsicht bei der VHID geboten.

> Bzw. für was ist das "Virtual IP Password" bei der virtuellen CARP IP?
Doku: "The authentication password to use when talking to other CARP-enabled hosts in this redundancy group. This must be the same on all members of the group."

> Ich konnte bisher in dem Internetz leider nichts dazu finden.
advskew: This optional parameter specifies how much to skew the  advbase when sending CARP advertisements. By manipulating advskew, the master CARP host can be chosen. The higher the number, the less preferred the host will be when choosing a master. The default is 0. Acceptable values are from 0 to 254.
...
To failover a particular CARP group, shut down the carp(4) interface on the master node. This will cause the master to advertise itself with an "infinite" advbase and advskew. The backup host(s) will see this and immediately take over the role of master.
...
An alternative is to increase the advskew to a value that's higher than the advskew on the backup host(s). This will cause a failover but still allow the master to participate in the CARP group.

Das ist CARP Basic. Die Sensen implementieren das wie sie ggf. wollen. In diesem Fall - steht in der Sense Doku - wird der Master auf Wert X (wie in der UI konfiguriert) gesetzt und der Slave bekommt via XMLRPC Sync die Daten mit +100 gepusht. Das stellt sicher, dass der Backup Node auch garantiert Backup IST (da höherer Wert). Es gibt/gab aber einige Rand-Abhängigkeiten der Sensen mit bspw. DHCP, der bei Skew Werten >100 dann aus dem Tritt kam. Theoretisch wäre ein Pärchen auch mit 100/200 ein Master/Slave, da beim DHCP aber bspw. 20 als Signalschwelle konfiguriert war, dass die Kiste Backup ist, hat keine von beiden mehr DHCP rausgegeben. Daher wurde das in *sense extra nochmal in den Text bei "Failover Peer IP" mit angegeben:

"Leave blank to disable. Enter the interface IP address of the other machine. Machines must be using CARP. Interface's advskew determines whether the DHCPd process is Primary or Secondary. Ensure one machine's advskew<20 (and the other is >20)."

Daher ist auch in der Doku die empfohlene Einstellung: Master Skew 0, Backup automatisch 100.

[bewue]

Die Probleme Nr. 3 und 4 in meinem ersten Post bleiben aber weiterhin unbeanwortet.
(oder habe ich etwas übersehen?)

@JeGr
Die Dokumente unter den von dir genanten URLs kannte ich schon und
bringen doch hierzu keine neuen Erkenntnisse!?

Bei einem "offenen" Netzwerk-Protokoll wie CARP hatte ich erwartet
z. B. Informationen zum Protokoll-Header im Internet zu finden, was
aber anscheinend nicht der Fall ist. Bei meiner Analyse mit tcpdump
konnte ich feststellen das der Advertisement-Header von CARP und der
von VRRP anscheinend gleich Strukturiert sind (gleiche längen der einzelnen Felder).
Aber die bedeutung einiger Felder unterscheidet sich.
Auch zu dem Problem Nr. 4 konnte ich nichts finden.

Ist dieser Sachverhalt irgendwo dokumentiert?

Ansonsten muss man doch erstmal von folgendem ausgehen:
3. ein Bug ist da keine Authentifizierung stattfindet obwohl ein Password angegeben wurde.
4. ein Bug ist da:
   a) Werte die eigentlich nur vom User bzw. XMLRPC gesetzt werden unter der Haube geändert werden.
   b) Das GUI Falsche Werte anzeigt. (Skew-Wert im GUI z.B. auf 251 gestellt,
       im Advertisement steht aber 240)
      (Vielleicht sollte man gleich im GUI nur Werte bis 240 erlauben!?)

[JeGr]

Hast du schonmal darüber nachgedacht, die Fragen anstatt an OPNsense zu richten, die lediglich eine CARP Implementation auf FreeBSD nutzen, die entweder direkt an die Mailingliste/Maintainer von CARP unter FreeBSD oder direkt an den Entwickler von CARP bei OpenBSD zu richten? Denn das hier zu diskutieren, wo dir auf solche Spezifika kaum jemand antworten können wird, dürfte eher weniger erfolgsversprechend sein.

4 a/b könnte man ggf. als Bug/Anfrage an das Team via Bugtracker/Github stellen, da es sich auf die UI/OPNSense bezieht, aber Tiefendetails über die CARP Implementation in FreeBSD oder CARP generell wären wohl besser bei den entsprechenden Upstream Stellen aufgehoben. Zumindest bei 3 kann ich dir nicht zu 100% folgen, denn in einem Szenario an das ich mich erinnere wurde das Passwort sehr wohl genutzt bzw wenn es manuell auf dem zweiten node geändert wurde, wurden keine advertisments mehr vom Master akzeptiert.

Trotzdem durchaus eine Frage an Upstream oder Entwickler wert.