NIC Failover

[phoniex]

Hallo zusammen,

Mein "Problem" ist jetzt (vermutlich) nicht für die neue Version 7.0 spezifisch, aber da es sich um ein komplett neues "Projekt" handelt, habe ich gleich die neue Version ESXi 7.0 installiert.

Leider habe ich etwas ein Verständnisproblem hinsichtlich des NIC-Failovers. Als Beispiel folgender Aufbau:

• 1x Server mit 2 NIC's
• 2x Firewall im Cluster active/passive (master/slave)

Anzumerken ist dass die "passive" (slave) Firewall an seinen interfaces immer einen "uplink" hat - sie ignoriert einfach alle Datenpakete.

NIC1 => direkt an Interface1 von FW1 (active/master) angeschlossen
NIC2 => direkt an Interface1 von FW2 (passive/slave) angeschlossen

D.h. der gesamte Datenverkehr läuft über FW1 + NIC1. Wenn FW1 ausfällt oder einen Reboot durchführt, dann übernimmt FW2 + NIC2 => zu Beachten ist eben, dass die jeweils passive Firewall (solange diese "up" ist) immer einen "uplink" am interface hat.

Für die Konfiguration am ESXi Host habe ich dafür folgende Anleitung gefunden (Hier wird ein Beispiel für die zwei physische NIC's angegeben):
Praxishandbuch VMware vSphere 6.7

Grundsätzlich funktioniert mein Setting auch nur, wenn ich wie im Buch beschrieben bei "vSwitch0" beide NIC's als Aktiv kennzeichne. Zusätzlich habe ich bei "Netzwerk-Failover-Ermittlung" auf "Nur Signal" eingestellt - weil ja die passive Firewall immer einen uplink hat.

Im Buch wird dann beschrieben, dass man beim Mangament-Network bei NIC's auf Aktiv stellt und beim VM-Network eine NIC auf Aktiv und die andere auf Passiv.

In meinem Versuch ist es völlig egal, ob ich bei der Portgruppe (egal welche) auf NIC1 + NIC2 = aktiv oder NIC1 = aktiv, NIC2 = passiv einstelle - funktionieren tut es immer in beiden Fällen richtig. Unten angehängt meine aktuelle Konfiguration.

Da ich nicht blind irgendwelche Einstellungen ohne jegliche Erklärung aus dem Buch übernehmen will (was dann eventuell später in gewissen Situationen Folgen haben könnte), hätte ich ein paar Fragen:

• Warum müssen bei vSwitch0 beide NIC Aktiv sein? (andernfalls funktioniert es bei mir ja auch nicht)
• Wieso sind laut Buch VM-Network und Managment-Network unterschiedlich zu konfigurieren?
• Mir ist auch nicht ganz klar warum es bei VM-Network/Managment-Network egal ist, ob ich Aktiv+Aktiv oder Aktiv+Passiv einstelle?
• Ich habe ja in Wirklichkeit eine Aktive und Passive physische NIC - müsste dann nicht irgendwo (vSwitch/Portgruppe) zwingend NIC als passiv markiert sein? Oder ist das egal weil die "Signalprüfung" die zweite NIC ohnehin inaktiv setzt?

LG phoniex

vswitch

Management-Network

[irix]

Moin,

1. Es muessen niemals beide NICs Active/Active sein
2. Was funktioniert denn nun nicht?

Aber erstmal einen Schritt zurueck.

Der ESXi macht Netzwerkredundanz seit 2003 und gefuehlt hat sich auch nicht sooooooo wirklich viel getan in der Ecke. Primaerer Zweck ist es den Ausfall des Anschlusses, hier dann Kabel, pSwitchport/Switch und pNIC abzufangen und das ganze transparent fuer die VM bzw. GuestOS. Gleichzeitig kommt ein durchaus akzeptables Loadbalacing heraus weil bei mehreren aktiven VMNICs der ESXi beim Start einer VM diese Roundrobin maessig der Reihe nach zuweist. Dazu hat man durch die 2 Abstraktionsebenen Portgruppe und vSwitch das Netzwerkthema aus der Sicht des GuestOS/VM und der phys. Karte entkoppelt und kann auf beiden Seiten aendern ohne das man die anderen aendern muss.

Das ganze hat nun nichts damit zu tun das du einen Anwendungscluster hast. Wir haben hier auch virtuelle Active/Standby Firewall welche sich ueberwachen. Aehnlich ist es auch mit den Exchange DAG Gruppen oder anderen Windows Clustergeschichten wo die meisen ja ein Heartbeat Netzwerk sich wuenschen.

1.Wieviele NICs deine VMs haben ist egal
2.Ob und wann bei dir Active/Standby NICs sinnvoll sind kann dir kein Buch sagen
3.Solange du virtuelle Netzwerkredundanz hast wird aus der Sicht deiner Anwendung kein Failovergrund zusehen sein
4.Deine Primaer FW VM kann nicht erkennen wenn die vNetzwerkredundanz komplett verloren ist


* Damals hatte man multiple 1Gb Karten. Dann hatte man einen aktiven 10G Port und nen 1G als Standby. Heute erschlaegt man alles mit 2x25G. Trotzdem hat der Admin die Moeglichkeit den Paketfluss zu leiten so das ein massen vMotion planmaessig nicht ueber die NIC laeuft wo der ESXi sein HA Heartbeat betreibt. Allerdings war das ganze halt wichtiger zu Zeiten von 100Mbit/1G als Heute.

Gruss
Joerg

[phoniex]

1. Es muessen niemals beide NICs Active/Active sein
2. Was funktioniert denn nun nicht?

Funktionieren tut es, aber ich verstehe nicht warum

Deine Primaer FW VM kann nicht erkennen wenn die vNetzwerkredundanz komplett verloren ist

Vielleicht war das zuwenig erklärt von mir - ich habe einen physischen Firewall-Cluster:

physische NIC1 => direkt 1:1 mit LAN-Kabel an Interface1 von physischer FW1 (active/master) angeschlossen
physische NIC2 => direkt 1:1 mit LAN-Kabel an Interface1 von physischer FW2 (passive/slave) angeschlossen

Wenn man mal den Hypervisor ignoriert, dann gibt es in diesem Szenario eine "aktive" physische NIC1 und eine "passive" physische NIC2.
(Bzw. umgekehrt, wenn master/slave am FW-Cluster tauschen). Es findet jedenfalls immer nur auf einer physischen NIC eine Kommunikation statt, die Zweite ist immer im Standby - hat aber trotzdem "uplink", vorrausgesetzt beide physischen FW's sind online (fällt die aktive NIC aus, steht die ganze Kiste ohne Anbindung da - ist mir bewusst )

Betrachtet man jetzt ESXi dann müsste sich - zumindestens nach meinem Verständnis - hier ja auch "aktive" und "standby" der physischen NIC's in irgendeiner Form wiederspiegeln.

Genau da sind wir an dem Punkt, wo mein Verständnisproblem liegt - mache ich die Konfiguration wie im Buch beschrieben: vSwitch0 beide physischen NIC = aktiv, Management-Network beide = aktiv => dann kann ich den HOST jederzeit erreichen (sprich FW1 = active / FW2 = passive und auch FW1 = passive / FW2 = active). Es spiegelt sich aber in keinster Weise die physische Situation (eine pyhsische NIC aktiv, die andere im Standby) wieder...

Es muessen niemals beide NICs Active/Active sein

Doch am vSwitch0 schon, weil sonst kann ich bei "FW2 = active / FW1 = passive" den HOST nicht mehr erreichen. vSwitch0 muss Active/Active haben sonst geht es eben nicht. Der Portgruppe wiederrum ist es völlig egal ob ich Active/Active oder Active/Passive machen...

Liegt das dann einfach deshalb an der "Nur Signal" Prüfung? Weil der ESXi hier automatisch eine NIC zur "aktiven" ernennt?

Ich kann es natürlich einfach so lassen und wenn mein ein Kollege fragt: Warum hast du das so gemacht? Kann ich nur sagen: "Es hat halt funktioniert, stand irgendwo in einem Buch, aber warum weiß ich auch nicht." Abgesehen davon kenne ich mich bei einer etwaigen Fehlersuche erst recht nicht aus und stelle dann halt solang herum bis es wieder irgendwie durch zufall geht

[~thc]

"Aktiv/passiv" der externen Anbindung und "active/standby" von vSwitch und Portgruppe sind verschiedene Konzepte der Redundanz.

Extern: Immer genau eine Verbindung ist "aktiv" (beide Links sind "up") und die angeschlossenen Server müssen damit irgendwie zurecht kommen.

ESXi-intern: Beliebig viele vmnics (alle aktiv und nutzbar) sind in einem Team und stellen den VMs redundante Verbindungen nach außen zur Verfügung, selbst wenn vmnics physisch ausfallen.

Das "Beacon"-Probing deines Setups ist zwar nachvollziehbar, funktioniert aber leider nicht:

Use beacon probing with three or more NICs in a team because ESXi can detect failures of a single adapter. If only two NICs are assigned and one of them loses connectivity, the switch cannot determine which NIC needs to be taken out of service because both do not receive beacons and as a result all packets sent to both uplinks. Using at least three NICs in such a team allows for n-2 failures where n is the number of NICs in the team before reaching an ambiguous situation.

Aus https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.networking.doc/GUID-4D97C749-1FFD-403D-B2AE-0CD0F1C70E2B.html

[phoniex]

Ich hab das mal getestet und "Bacon Probing" (bzw. nur "Signal") am vSwitch0 entfernt. Dann habe ich auf FW1 einen reboot durchgeführt => FW2 = master/active. Solange sich FW1 noch im reboot befindet (die Ports sind offline) kann ich den Host und die VM's ganz normal erreichen. Sobald FW1 wieder online ist (jetzt passive/slave) kann ich den HOST und VM's nicht mehr erreichen.

Wenn ich "Bacon Probing" wie im Screeshot zuvor aktiviert habe, funktioniert dieses Szenario...

Wie "Bacon Probing" funktioniert ist hier ganz gut beschrieben: https://www.elasticsky.de/2019/01/esx-physische-uplinks-gegen-pfadausfall-sichern-teil-2/. Dort gibt es auch ein Beispiel für die 2 uplinks und damit verbundene Problematik.

Seltsam ist halt dann nur dass es bei mir trotzdem wie gewünscht funktioniert. Vielleicht hat es ja auch nur den Anschein dass es funktioniert... Ich kann zumindest ohne jegleiche Probleme / Verzögerung eine RDP-Sitzung zur Windows-VM aufbauen und beim Ping sind keine zeitlichen Ausreiser zu bemerken, auch der Ping von der VM nach extern (z.B. Google konstant mit 9ms - identisch wie wenn von der Firewall aus gestartet) zeigt keine Ausreiser an.

Die Frage ist nun wie muss ich denn die Konfig für vSwitch / Portgruppen für mein Szenario richtig vornehmen?

[~thc]

Die Frage ist nun wie muss ich denn die Konfig für vSwitch / Portgruppen für mein Szenario richtig vornehmen?

Sorry - aber du machst doch entgegen der "Best practice" ein "Beacon probing" mit zwei vmnics, dass trotzdem irgendwie funktioniert. Die von dir zitierte Info aus dem Buch ("dass man beim Mangament-Network bei NIC's auf Aktiv stellt und beim VM-Network eine NIC auf Aktiv und die andere auf Passiv.") ist Schwachsinn. Was genau willst du denn jetzt hören?

[phoniex]

Ja das im Buch ist Quatsch, verstanden. Beacon Probing ist für 2 NIC‘s nicht geeignet - wurde deaktiviert.

Meine Frage ist wie es jetzt richtig gemacht wird, damit es für meine physische Hardware-Gegebenheit korrekt (oder wie gewünscht) funktioniert? So funktioniert es jetzt nicht... sobald die FW2 zum Master wird, kann ich Host und VM‘s nicht erreichen (Konfig aktuell so wie im Origianlpost, nur ohne Beacon Probing).

[irix]

Was ist denn der Ausloeser das die FW2 Master wird? Du schaltest die FW1 aus oder?

Gruss
Joerg

[Dayworker]

Zur Einstellung kann ich nichts sagen, aber in meinen Augen macht dein Konzept mit 2 FWs keinen Sinn oder wissen beide FWs von einander und sind für redundanten Betrieb ausgelegt?

[irix]

Doch das kann Sinn machen. Wir haben sowas hier weil wir es vor 10 Jahren nicht besser wussten bzw. fuer eine Gute Idee hielten. Wir haben V+V also auch V+P Setups.

VRRP? oder so. Muesste nun meinen Admin fragen.

Ja natuerlich wissen die beiden von einander.

Gruss
Joerg

[~thc]

Beacon Probing ist für 2 NIC‘s nicht geeignet - wurde deaktiviert.

Meine Frage ist wie es jetzt richtig gemacht wird, damit es für meine physische Hardware-Gegebenheit korrekt (oder wie gewünscht) funktioniert?

Nach meinem Wissen gar nicht. Du kannst einem ESXi nicht zwei vmnics vorsetzen, die extern und für den ESXi nicht erkennbar per Failover umgeschaltet werden.

[phoniex]

Was ist denn der Ausloeser das die FW2 Master wird? Du schaltest die FW1 aus oder?

Den Reboot mache ich nur um eine Wechsel zu provozieren. In der Realität wird die FW2 zum Master wenn FW1 abschmiert ( Hearbeat geht verloren) oder WAN1 an der FW1 verloren geht (Monitoring der FW selbst), beim Firmware-Update des Clusters kann es auch noch passieren.

Zur Einstellung kann ich nichts sagen, aber in meinen Augen macht dein Konzept mit 2 FWs keinen Sinn oder wissen beide FWs von einander und sind für redundanten Betrieb ausgelegt?

Ja die sind im Cluster und über 2x Hearbeat Interfaces verbunden, also ja die wissen voneinander.

Du kannst einem ESXi nicht zwei vmnics vorsetzen, die extern und für den ESXi nicht erkennbar per Failover umgeschaltet werden.

Grundsätzlich würde die FW2 wenn sie zum Master wird „ gratuitous arp“ aussenden. Ich nehme aber mal an dass der ESXi darauf nicht reagiert.

Aber vielleicht gibt es doch eine Möglichkeit, nämlich den „Fallback“ zu deaktivieren. Wenn eine Firewall Master war und zum Slave wird (zB wie oben beschrieben wenn WAN verloren geht) dann wird für kurze Zeit das Interface an der FW deaktiviert - sprich der ESXi sieht dass der Uplink an NIC1 weg ist. Wenn der Fallback deaktiviert ist, würde ESXi erst dann wieder NIC1 verwenden, wenn NIC2 seinen uplink verliert.

Damit wäre aber wieder die Frage welche Konfiguration (active/passiv Einstellungen) ich dafür am vSwitch / Portgruppe brauche.

[irix]

Failback ist hier an und es funktioniert auch von Anfang an. Die Timings haben wir etwas zurueckgedreht da sonst mal bei einem Snapshot (Datensicherung) der Failover stattfindet.

Gruss
Joerg

[phoniex]

Das verstehe ich jetzt ehrlich gesagt nicht, inwiefern hat der Snapshot auf die physischen NIC‘s Einfluss?

https://docs.vmware.com/en/VMware-vSphe ... 7EE76.html

From the Failback drop-down menu, select whether a physical adapter is returned to active status after recovering from a failure.
If failback is set to Yes, the default selection, the adapter is returned to active duty immediately upon recovery, displacing the standby adapter that took over its slot, if any.

If failback is set to No for a standard port, a failed adapter is left inactive after recovery until another currently active adapter fails and must be replaced.

[irix]

Das verstehe ich jetzt ehrlich gesagt nicht, inwiefern hat der Snapshot auf die physischen NIC‘s Einfluss?

Das hat mit der phys. NIC genau NULL zutun. Es bleibt da die VM beim loeschen des Snapshots ein sekuendlein angehalten oder sonstwie beschaeftigt wird und da der Heartbeat dann ausbleibt wird ein Failover gemacht. Aber das haben wir seit Jahren im Griff und All Flash hilft da auch.

Wir haben da fuer eine andere Cluster Geschichte eine VA welche einen Schiedsrichter stellt und da ist Snapshot eine Katastrophe.

Also du sagt das wenn FW1 heruntergefahren wird und FW2 uebernimmt dann hast du keinen Zugriff mehr auf den ESX und die VMs auf diesem? Wenn dann Beaconprobing an ist dann funktionierts?

Gruss
Joerg

[~thc]

Aber vielleicht gibt es doch eine Möglichkeit, nämlich den „Fallback“ zu deaktivieren. Wenn eine Firewall Master war und zum Slave wird (zB wie oben beschrieben wenn WAN verloren geht) dann wird für kurze Zeit das Interface an der FW deaktiviert - sprich der ESXi sieht dass der Uplink an NIC1 weg ist. Wenn der Fallback deaktiviert ist, würde ESXi erst dann wieder NIC1 verwenden, wenn NIC2 seinen uplink verliert.

Das wäre tatsächlich die Lösung, wenn

a) die Link-Downtime der Passivschaltung der FW1 ausreicht, um ein Failover des ESXi auszulösen
b) das deaktivierte Failback nicht dazu führt, dass bei einem späteren Passiv-Linkdown der FW2 nicht zurückgeschaltet wird

Probier es einfach aus.

[phoniex]

Das hat mit der phys. NIC genau NULL zutun. Es bleibt da die VM beim loeschen des Snapshots ein sekuendlein angehalten oder sonstwie beschaeftigt wird und da der Heartbeat dann ausbleibt wird ein Failover gemacht.

Aber du redest doch hier von deinem VM-Firewall-Cluster oder verstehe ich da was falsch? Das hat dann ja nichts damit zu tun wovon ich rede... ich rede ja davon das failback am vSwitch zu deaktivieren - die Firewall befindet sich ja physisch zwischen dem ISP und ESXi. Der Snapshot wirkt sich ja nur auf die VM selbst aus, aber nicht auf die NIC‘s oder die physische Firewall vor dem ESXi. In deinem Fall verliert die VM-Firewall den Heartbeat und dann macht deine zweite VM-Firewall den Failover. Das hat aber nichts mit meiner Situation zu tun...

Also du sagt das wenn FW1 heruntergefahren wird und FW2 uebernimmt dann hast du keinen Zugriff mehr auf den ESX und die VMs auf diesem? Wenn dann Beaconprobing an ist dann funktionierts?

Reboot, Verlust von WAN-Anschluss oder Firmware-Update verursachen einen Wechsel vom Master an der Firewall. Beim Reboot von FW1 übernimmt FW2. Solange FW1 den reboot macht, kann ESXi über physische FW2 (befindet sich vor dem ESXi) => physische NIC2 erreicht werden. Wenn FW1 wieder da ist, kommt sie als Slave dazu (FW2 = master). Der Uplink an FW1 (slave) => NIC1 ist aktiv, aber die FW1 ignoriert alle Datenpakete. Der ESXi bekommt davon ja nichts mit. Er sieht nur dass ein Uplink an beiden NIC‘s besteht und nimmt einfach die erste aktive NIC1 (an FW1 angeschlossen) her.

Gleiches würde bei einem Verlust von WAN an FW1 passieren => FW2 übernimmt, die FW1 setzt kurzzeitig seinen Uplink an den interfaces aus.

Bei Beacon Probing, wie von ~thc beschrieben/verlinkt, mit 2 NIC‘s kann der ESXi jetzt die NIC‘s nicht untereinander erreichen (eine Firewall passiv). Daher sendet der ESXi einfach auf beiden NIC‘s das gleiche aus, wodurch es halt so funktioniert - aber wohl nicht im Sinne des Erfinders ist.

Das wäre tatsächlich die Lösung, wenn

Ja die downtime sollte ausreichend sein. Ich werde es heute einfach mal testen.

Ich nehme an am vSwitch ist NIC1=aktiv und NIC2=passiv zu wählen, und bei den Portgruppen die Einstellung „Failover Reihenfolge außer Kraft setzen“ dann zu deaktivieren? Aber ich werd’s eh sehen wenn ich es ausprobiere.

[irix]

Das hat dann ja nichts damit zu tun wovon ich rede... ich rede ja davon das failback am vSwitch zu deaktivieren - die Firewall befindet sich ja physisch zwischen dem ISP und ESXi.

Das hat dann in der Tat nichts damit zutun. Ich war davon ausgegangen das zumind. eine deiner FW eine VM ist weil hier gehts ja nunmal primaer im VMs. Rein phys. FW Cluster gibts hier auch und trotzdem gibts hier scheinbar das Problem nicht. Ich sehe nun auch nicht wie der ESXi involviert sein soll

Kann es sein das du keinen pSwitch zwischen ESXi und deinen FWs hast? Ich will ja nun endlich mal verstehen warum du ein Problem hast.

Gruss
Joerg

[phoniex]

Ich war davon ausgegangen das zumind. eine deiner FW eine VM ist weil hier gehts ja nunmal primaer im VMs.

Deshalb habe ich es in meinem zweiten Post auch entsprechend klargestellt

Kann es sein das du keinen pSwitch zwischen ESXi und deinen FWs hast?

Würde auch in meinem zweiten Post stehen, also nein kein Switch. FW ist mit pNIC des pServer direkt verbunden. Bei einem pSwitch alleine würde die Redundanz verloren gehen. Ein zweiter pSwitch würde aber auch nicht helfen, weil dann steht man wieder vor dem gleichen Problem. Beacon Probing funktioniert dann ja auch nicht, weil das erst bei 3 NIC‘s sind macht => dann wären 3 pSwitch notwendig.

Ein Active/Active an der pFW geht seitens ISP nicht, weil der Cluster immer eine gemeinsame MAC-Adresse hat (alle pFW im Cluster haben die selben virtuelle Mac-Adresse) - sprich der Coreswitch am ISP würde zwei Geräte mit gleicher Mac-Adresse sehen, der ISP macht am Coreswitch aber keine Ausnahme dafür. Dementsprechend ist nur Aktiv/Passiv am pFW-Cluster möglich, weil nur so die virtuelle MAC-Adresse einmalig vorhanden.

Ich sehe nun auch nicht wie der ESXi involviert sein soll

Der ESXi steht vor dem Problem dass er 2 pNIC sieht, die beide einen Uplink haben - aber er nur auf einer pNIC kommunizieren kann, weil die zweite pNIC auf der passiven pFW hängt, die aber keine Kommunikation ermöglicht (Port hat dennoch Uplink).

[Dayworker]

Klarstellen würde in meinen Augen ein Bild deiner Config. Zumindest ich sehe inzwischen nicht mehr durch, was wie wo funktioniert bzw nicht oder auch unerwartet trotzdem funktioniert.

[irix]

Ich mein es verstanden zu haben.... sein Problem haette er nicht wenn man eine redundante Switch haette zwischen FWs und ESXi Host oder halt 3 FWs weil dann wuerde Beaconprobing zur Anwendung kommen koennen.

Gruss
Joerg

[phoniex]

Klarstellen würde in meinen Augen ein Bild deiner Config. Zumindest ich sehe inzwischen nicht mehr durch, was wie wo funktioniert bzw nicht oder auch unerwartet trotzdem funktioniert.

Die Erklärung warum es mit Beacon Probing dann doch funktioniert hat, hat ~thc geliefert. Beim Beacon Probing werden Broadcast-Frames auf allen NIC's gesendet und von den jeweils anderen NIC's empfangen. Damit weiß der ESXi das alle pNICs eine Verbindung haben. Bei 2 NIC's kann der ESXi aber nicht feststellen auf welcher NIC der Fehler auftritt (https://www.elasticsky.de/2019/01/esx-p ... rn-teil-2/) - der ESXi geht dann einfach davon aus dass irgendeine NIC funktioniert und dupliziert die Datenpakete auf beide NIC's. Da sich in meinem Fall die beiden pNICs untereinander über die FW nicht erreichen können, hat der ESXi einfach auf beiden pNIC ausgesendet und hat halt dadurch funktioniert. Wusste ich aber vorher eben auch nicht.

Im Nachhinein betrachtet: Ja ein Bild wäre wohl doch hilfreich gewesen. Da es aber nur 6 Elemente gibt (2x FW, 2x Lan-Kabel, 2xpNIC) dachte ich mir es ist verständlich - offenbar aber nur in meinem Kopf

sein Problem haette er nicht wenn man eine redundante Switch haette zwischen FWs und ESXi Host oder halt 3 FWs weil dann wuerde Beaconprobing zur Anwendung kommen koennen.

Die Variante mit 3x pFW, 3x pNIC, 3x pSwitch macht das Ganze, glaube ich, nur unnötig kompliziert. Ich glaube die grundsätzlich bessere Lösung wäre es mit 2 pSwitch mit Hilfe von Link Aggregation / LACP... dann würde mein Problem wahrscheinlich in dieser Form nicht mehr existieren. Kann ich jetzt aber mangels Switch natürlich so nicht testen - aber wird für zukünftiges jedenfalls berücksichtigt.

Trotzdem vielen Dank, auch wenn wir aneinander "vorbeigeschrieben" haben.

Probier es einfach aus.

Ja es funktioniert so mit dem Failback. Vielen Dank für deine Unterstützung.
Sollte das irgendwie doch noch Probleme machen, könnte man natürlich einfach das Beacon Probing "missbrauchen" - also die doppelte Aussendung auf beiden NICs zu Nutze machen. Die saubere Lösung wäre wahrscheinlich, wie zuvor beschrieben, über 2 pSwitch mit Link Aggregation / LACP.

Zusammengefasst ist die Lösung:

• Der physische FW-Cluster muss eine Funktion haben, damit beim Wechsel von Master => Slave der Uplink der physischen FW-Interfaces kurzzeitig down geht.
• vSwitch => Failback deaktivieren, pNIC1 = aktiv, pNIC2 = standby
• Porgruppen => Failover-Reihenfolge außer Kraft setzen = Nein