OPNsense Forum
International Forums => German - Deutsch => Topic started by: Chrigu on April 04, 2017, 05:32:40 pm
-
Hallo liebe Mitstreiter
ich habe schon die Sufu bemüht, aber keinen passenden Beitrag gefunden weshalb ich diesen hier eröffne.
Wir bekommen vom ISP redundanten Feed, und diese Redundanz möchte ich bilderbuchmässig von vorne bis hinten (FW's, Switche mit Spanning Tree, Hyper-V's mit NIC Teaming) durchgeben.
Deshalb habe ich vor, 2 Firewalls mit LAGG/CARP sowohl WAN-seitig als auch LAN-seitig einzurichten.
Jede Firewall hat 2 Interfaces für WAN und 2 Interfaces für LAN, welche ich gern LAGGen möchte. Am Schluss sollen die LAGG Interfaces dann noch ein CARP zwischen beiden FW's bekommen.
FW01 LAGG0 --> VIP(WAN) <-- FW02 LAGG0
FW01 LAGG1 --> VIP(LAN) <--- FW02 LAGG1
FW01 IGB4-----> SYNC <--- FW02 IGB4
PFsync geht über ein separates Interface.
Beim Test des Aufbaus gab es jedoch Probleme. FW01 ist MASTER beider CARP's, deaktiviere ich temporär das CARP auf FW01 (simuliere einen Ausfall), übernimmt FW02 den MASTER für beide CARP's. Aktiviere ich CARP auf FW01 wieder, sollte nach einiger Zeit (240 Sekunden?) FW01 wieder zum MASTER werden, jedoch passiert das nicht.
Im Log fand ich dazu: "carp: demoted (pfsync bulk fail)"
Habe nach einiger Recherche ein paar pfSense Threads dazu gefunden, aber so richtig glücklich bin ich damit nicht geworden. Ich möchte ungern ausserhalb des WebGUI mit sysctl irgenwelche zusätzlichen Tunables erstellen.
Jetzt zu meiner Frage: Gibt es dazu eine einfachere Lösung per GUI? Oder vielleicht sogar einen ganz anderen Lösungsansatz?
Ich danke Euch schonmal im Voraus für Eure Hilfe!
LG Chrigu
-
> sollte nach einiger Zeit (240 Sekunden?)
Nein, das sollte quasi sofort wiederhergestellt werden.
> Im Log fand ich dazu: "carp: demoted (pfsync bulk fail)"
pfSync nicht auf extra Interface konfiguriert? Es wird empfohlen, Sync wie eigenem Crossover Interface zwischen den beiden Geräten zu realisieren. Man kann es auch auf LAN laufen lassen, sollte es aber lieber über ein dediziertes Interface abbilden.
> Ich möchte ungern ausserhalb des WebGUI mit sysctl irgenwelche zusätzlichen Tunables erstellen.
Das gehört aber zur Arbeit mit der Hardware und dem OS dazu. Es werden eben für einige Hardware Settings Tunables benötigt.
> Oder vielleicht sogar einen ganz anderen Lösungsansatz?
Erstmal müsste man dein Problem konkretisieren, dann gibt es vielleicht auch einen (anderen) Lösungsansatz.
Zudem hast du uns leider nicht erhellt, welche Version du bspw. einsetzt etc.
-
Hallo JeGr
danke für deine Antwort.
Das mit dem separaten SYNC Interface hatte ich geschrieben:
-> FW01 IGB4-----> SYNC <--- FW02 IGB4
-> PFsync geht über ein separates Interface.
Die Version ist die neueste, also 17.1.4.
Ich führe das Vorhaben mal genauer aus.
Wir haben 2 verschiedene Zuleitungen (nenne sie mal A und B) vom ISP, jeweils 1Gbit.
Bei FW01 soll Zuleitung A auf WAN1 und Zuleitung B auf WAN2 ankommen. WAN1 und WAN2 sollten dann in ein LAGG0. So hätten wir Loadbalance oder Failover für die Zuleitungen vom ISP.
Dasselbe soll auch mit FW02 passieren. Wieder Zuleitung A und B auf WAN1 und WAN2
Dann haben wir auf FW01 ein LAGG0 und auf FW02 ein LAGG0. Wenn wir dann die beiden LAGG's carpen könnten, hätten wir eine zentrale VIP.
LAN-seitig soll dann dasselbe passieren, also LAN1 und LAN2 auf jeder FW in ein LAGG (LAGG1), und danach carpen.
Weiter geht es dann zu 2 Switchen, also von FW01 und FW02 jeweils ein Kabel auf Switch1 und Switch2.
Auch die Switche sind miteinander verbunden (Spanning Tree).
An den Switchen hängen dann die Hyper-V's, jeder Hyper-V bekommt ein Kabel von Switch1 und ein Kabel von Switch2. Die 2 definierten Interfaces auf den Hyper-V's sind im NIC Teaming.
So wäre eine absolute Hochverfügbarkeit gegeben. :)
Im Anhang mal ein schnelles Visio, vielleicht hilfts ja.
Ich hänge aber wie gesagt noch bei den gecarpten LAGG Interfaces fest, geht der Master - sagen wir mal FW01 - down, wird FW02 Master. Kommt FW01 wieder up, bleibt FW02 Master. Hatte leider vergessen zu testen was passiert, wenn kurz darauf FW02 auch mal down geht. Vielleicht fühlt sich FW01 ja dann wieder verpflichtet Master zu werden?
LG Chrigu
-
Hi,
ich habe gerade ein ähnliches Problem. Wird bei dir der Master nach einem "behobenen" Failover wieder zum richtigen Master, oder spielt der BACKUP weiter den Master ?
LG Wayne
-
Ich hatte das hier mit 2 Testkisten und 17.1.6 auch mal, aber nach Update lies sich das nicht mehr reproduzieren (aber ohne LAGG)
-
Ich mache zum Beispiel gerade auf dem neuesten Release die Erfahrung, dass wenn ich ein Patch Kabel aus dem LAGG ziehe ein Failover ausgelöst wird, der in einem Split-Brain resultiert. Zur Verdeutlichung: igb0 und igb1 bilden LAGG0. Das ist auf beiden FWs so. Ziehe ich nun z.B. auf dem master das LAN-Kabel von igb1 ab, so wird ein Failover ausgelöst. Stecke ich es wieder rein, habe ich einen <ironie>herrlichen </ironie> Splitbrain, sodass ein Teil der VLANs auf dem Master und dem Backup aktiv sind. Der Master fängt dann natürlich irgendwann richtig an zu laggen. Teilweise kachelt mir dabei dann auch noch die SSH-Session weg.
Irgendjemand Erfahrungen damit oder 'ne Idee woran das liegen könnte ?
Viele Grüße
Wayne
-
Machst du LACP?
-
Ja mache ich. Ist das das Problem ?
-
Nö, grad wenn man kein LACP macht gibts Probleme. Also Switch und OPN machen beide LACP, korrekt?
-
@chrigu: Hat damals für mich keinen Sinn ergeben, macht es jetzt auch nicht ;) Das Setup mit 2x2 Leitungen und das via LAGG auf CARP ist einfach seltsam. Ich habe 2 Kisten, damit die einspringen können, also lasse ich sie auch einspringen.
Für mich macht es keinen wirklichen Sinn, Zuleitung A und B als LAGG auf die gleiche Kiste zu bringen, wenn vom Anbieter A und B eh ein Failover ist (sollte es das nicht sein, weil verschiedene so betont wird, dann mea culpa). Aber die wenigstens Anbieter geben einem hier 2GBit als einzelne Adern, sondern haben eher eine Ausfallsichere Leitung die da draufsteckt. Darum die Frage.
Grüße
-
Hi,
der eine oder andere wird durch meine Posts schon mitbekommen haben, dass ich gerade auf einem neueren Cluster ziemlich mit CARP am kämpfen bin. Ich habe dauernd Splitbrains, obwohl ich sowohl switchseitig als auch von der Config selbst her, ein zu ca. 90% ig identisches Setup fahre. WAN seitige Failover funktionieren, aber sobald ich ein Kabel vom LAGG des Masters abziehe auf dem die VLANs liegen, die dann wiederum die jeweiligen V-IPs inne haben, kommt es zum Splitbrain. Auf dem Produktivsystem konnte ich das noch nicht testen, hoffe aber, dass ich dort nicht das gleiche Problem habe, da wir nachdem wir die VLANs eingezogen haben den Failover nur WAN-seitig geprüft haben. Produktiv ist momemtan noch auf 17.1.1 während der neue HA-Cluster auf 17.1.8 läuft. Wenn also jemand 'ne Idee hat woran das liegen könnte, oder mir noch ein paar Tipps zur Fehlersuche geben könnte wäre das top.
Anhand des Verhaltens, dass WAN seitige Failover sauber zu funktionieren scheinen und ich in den Dokus zu Pfsense und OPNsense immer auch in den Testbeispielen immer nur was zu WAN-Failover, aber niemals was zur LAN-Seite gelesen habe, frage ich mich gerade zudem noch, ob LAN seitige Failover von CARP überhaupt sauber gehandelt werden können, oder ob sich das immer nur aufs WAN bezieht. Das wäre dann nochmal richtig strange...
MFG
Wayne
-
Ich würde erst mal LAGG deaktivieren um den Fehler eingrenzen zu können.
P.S.: Es reicht auch wenn du nur in einem Post dein CARP/LAGG Problem beschreibst ;)
-
Ich hab das Problem gelöst indem ich auf BEIDEN FWs den Haken bei "Disable preempt" NICHT gesetzt habe.
Zusätzlich auf beiden Systemen ein Tunable:
net.inet.carp.senderr_demotion_factor=0
Nach einem Reboot von beiden Kisten war das Phänomen wie von dir beschrieben bei mir nicht mehr vorhanden.
Probiers mal ...
EDIT: Sorry, der reply gilt "Wayne Train"
-
Hi,
danke, das ist ein guter Tipp. Das muss ich direkt nach dem Urlaub mal testen.
Hattest du genau das gleiche Problem wie ich ?
Gruß
Wayne
-
Mein Testsetup:
WAN physikalisches IF
LAN1 und LAN2 auf LAGG
Also 3 CARPs.
Wenn ich WAN abstecke war Unit2 Master für WAN und Backup für LANs. Und dann war beim Reboot von Unit2 immer die Unit2 auf einmal für alle Master.
Beim Abstecken von einem LAGG Member ist nix passiert (vorher und nachher).
War das bei dir auch so? Schon oder?
-
Hi Mimugmail,
ich verstehe deinen Post nicht ganz. Du hast ein LAGG aus LAN 1 und LAN 2 gebaut. Dann hast du eine CARP-VIP auf dem WAN und eine CARP-VIP auf dem LAN oder ? Woher kommt deine 3. CARP-VIP?
Wenn ich WAN abstecke war Unit2 Master für WAN und Backup für LANs.
Ja, das war bei mir auch so. Auflösen konnte ich das immer nur, wenn ich Unit 1 in den "Persisten Maintenance Mode" gesetzt habe. Dann ist auch die LAN-Seite auf Unit 2 Master geworden. Wenn ich dann auf Unit 1 den Mainentance-Mode verlassen habe, sind nur ein Teil der LAN-seitigen VLANs auf Unit 1 Master geworden, während Unit 2 weitehin Master für WAN und einige VLANs auf der LAN-Seite war.
Und dann war beim Reboot von Unit2 immer die Unit2 auf einmal für alle Master.
So ähnlich...Wenn ich zum Beispiel Unit 2 rebootet habe, wurde kurz Unit 1 Master für alles, danach hat sich Unit 2 als sie wieder komplett da war einige der LAN-seitigen VLANs gezogen während ein Teil auf Unit 1 verblieb. WAN seitig blieb Unit 1 meistens Master. Das ist auch nicht bei jedem Reboot aufgetreten, sondern nur ab und an. Ohne das ich ein bestimmtes Muster darin erkennen konnte.
Wenn ich z. B. Unit 1 dann nochmal rebootet habe, war und blieb Unit 2 auch oftmals Master für alles. Wollte ich hingegen, dass Unit 1 wieder der eigentliche Master ist und auch bleibt, musste ich oftmals wie folgt vorgehen:
Unit 2 in den Maintenance Mode setzen: Alles wandert zu Unit 1 die nun Master ist. Dann noch Unit 1 rebooten, sobald sie wieder oben ist, auch Unit 2 rebooten und nach ner Weile den Maintenance Mode auf Unit 2 wieder verlassen. Diese Methode funktioniert meistens, hat aber das Problem, dass halt das Netz mal für ne Weile weg ist und das Ganze am Thema Hochverfügbarkeit vorbeischiesst....
Viele Grüße
Wayne
-
Sorry, wenn du statt LAN1 und LAN2 -> VLAN1 und VLAN2 machst ergibt alles Sinn :)
Jo, dann hatten wir das Gleiche ... probiers einfach mal mit dem tunable
-
Ja,
denke auch, dass das ein Versuch Wert ist. Ich habe mittlerweile auch in einem anderen Post gelesen, dass es sowohl mit LAGGs, als auch mit CARP unter BSD wohl Probleme gibt. Bleibt ja zu hoffen, dass es da in Zukunft einen Fix für geben wird. Unter PFsense gab es damit um 2016 rum auch erhebliche Probleme. Habe mir da vor kurzem noch einen Forumsaccount angelegt, da dort die Userbase ein wenig größer ist....
Funktioniert denn nach deinem Tuning der Failover genauso wie man ihn erwarten würde, also ein Interface, LAN oder WAN-seitig macht die Biege und die Büchse schaltet auf den Failover-Node um ?
MFG
Wayne
-
Ja funktioniert wunderbar. Wobei nicht geswitcht wird wenn nur ein LAGG Member gezogen wird, aber das ist ja OK