[gelöst] CARP auf vSphere Distributed Switch Backup - Backup

[NilsS]

Moin,

ich hab mein erstes CARP Cluster aufgesetzt und hab ein Problem mit dam VIP.

Ich hatte zuerst auf beiden OPNs beim CARP im Dashboard MASTER stehen (CARP IP erreichbar - keine DUPs)
Dann habe ich im Distributed Switch den Promiscous Mode/Mac change/Forge transmits erlaubt
Danach wechselte die Anzeige bei beiden OPN auf BACKUP (CARP IP weiter erreichbar - keine DUPs)

Im NetFate Forum hatte ich dann was von "Net.ReversePathFwdCheckPromisc" gefunden, dass habe ich dann auch auf allen ESX Hosts auf 1 gesetzt und Promiscous wie dort beschrieben aus und wieder an gemacht - hat aber auch nix gebracht.

Es scheint jetzt aber (laut Logfile) im 3 Sekunden Takt zwischen Master und Backup zu wechseln.

Was kann ich machen um das Problem zu finden.

Switche zwischen den ESX Hosts sind FS.COM S8050 mit je 4 x 40Gbit an jedem ESX Host

EDIT: wenn ich auf einem OPN das CARP deaktiviere scheint sich der andere Trotzdem nicht vom Backup zu lösen.

[mimugmail]

4x40 als LACP?

[NilsS]

nö nur als Failover
2 Karten mit je 2 Ports auf 2 Switche
Der Preis für 40GBe war nicht groß anders als für 10GBe

[NilsS]

Code: [Select]

2020-07-11T23:15:44 opnsense: /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface 2xx.1xx.2xx.x - WAN 2xx.1xx.2xx.x CARP.
2020-07-11T23:15:44 opnsense: /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "2xx.1xx.2xx.x - WAN 2xx.1xx.2xx.x CARP (1@vmx0_vlan76)" has resumed the state "BACKUP" for vhid 1
2020-07-11T23:15:44 opnsense: /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface 2xx.1xx.2xx.x - WAN 2xx.1xx.2xx.x CARP.
2020-07-11T23:15:44 opnsense: /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "2xx.1xx.2xx.x - WAN 2xx.1xx.2xx.x CARP (1@vmx0_vlan76)" has resumed the state "MASTER" for vhid 1
2020-07-11T23:15:44 kernel: ifa_maintain_loopback_route: deletion failed for interface vmx0_vlan76: 3
2020-07-11T23:15:44 kernel: carp: 1@vmx0_vlan76: MASTER -> BACKUP (more frequent advertisement received)
2020-07-11T23:15:44 kernel: carp: 1@vmx0_vlan76: BACKUP -> MASTER (master timed out)
2020-07-11T23:15:41 opnsense: /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface 2xx.1xx.2xx.x - WAN 2xx.1xx.2xx.x CARP.
2020-07-11T23:15:41 opnsense: /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "2xx.1xx.2xx.x - WAN 2xx.1xx.2xx.x CARP (1@vmx0_vlan76)" has resumed the state "BACKUP" for vhid 1
2020-07-11T23:15:41 opnsense: /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface 2xx.1xx.2xx.x - WAN 2xx.1xx.2xx.x CARP.
2020-07-11T23:15:41 opnsense: /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "2xx.1xx.2xx.x - WAN 2xx.1xx.2xx.x CARP (1@vmx0_vlan76)" has resumed the state "MASTER" for vhid 1
2020-07-11T23:15:41 kernel: ifa_maintain_loopback_route: deletion failed for interface vmx0_vlan76: 3

Das da 20-openvpn dran steht hat nix zu sagen oder?

Ich hab zwar openvpn konfiguriert, aber nur auf loopback.

[mimugmail]

Das wird immer ausgeführt, egal ob die instance aktiv ist.

Steck mal alle 40G Kabel bis auf EINES ab .. dann kannst du schon mal keinen Loop bauen.
Wenn das geht, weiter einstecken. Ich würde gefühlt 2xLACP ESX1 und 2xLACP ESX2 machen .. alles andere ist zu anfällig für Loops, gerade bei Failover .. das macht das der Hypervisor ohne Rücksicht auf Spanning Tree

[NilsS]

Danke, werde ich morgen vor Ort mal testen. Ports per shutdown remote zu deaktivieren und auf dem verbleibendem dann Firewall Tests zu machen hört sich nicht nach nem guten Sonntagsplan an ;-)

Bzgl. LACP habe mich mich gegen entschieden weil das ISCSI des ESX auch mit über den distributed Switch geht und dort MPIO empfohlen wird. Außerdem muss ja ja beide Switche einbinden. Die switche können zwar MLAG aber das war mir dann doch zu komplex da ich eh nicht mit Auslastung von einem 40GBE rechne.

Der Anschluss mit 2 Karten/2 Ports je überkreuzt an 2 Switche ist ja denke ich immer noch das von VMware empfohlene Best Practice.

Wenn ich Loops im spanning tree hätte hätte doch aber der Switch dahinter den Loop erkennen müssen und den Port auf Blocked gestellt.

Die beiden OPN sind nicht am gleichen Switch.

Wir haben 3 esx an Standort A und 1 esx an Standort B. Die OPN befinden sich je an einem Standort. Die Standorte sind mit einem 40GBE-LR4 verbunden.

Aber du hast recht das es vermutlich schon im ESX zum Loop kommen könnte. Da ja jede OPN für sich alleine schon meint es gäbe bereits einen Master.

[mimugmail]

Wenn du kein LACP machst, kein MLAG, und redundant auf 2 Switche verkabelst .. was soll da stabiles raus kommen?

[NilsS]

Jo du hast Recht, es hat gelooped.

Die Portgruppen beim Distributed Switch bieten beim erstellen NUR wenn man erweitert wählt die Möglichkeit beim Teaming Failover auszuwählen.

Da wie gesagt zwei Switche genutzt werden sollen und mir die Konfiguration von MLAG und LACP auf den Switchen zu Aufwendig für einfache Ausfallsicherheit sind, habe ich jetzt unter der Portgruppe unter Teaming nur eine Netzwerkkarte aktiv und eine im Failover auf dem anderen Switch.

Die 40GBe werden bei ca 40 Arbeitsplätzen dahinter eh NIE an ihre Grenzen kommen.

Problem ist gelöst. Danke

Es viel vorher nicht auf weil als Loadbalance Algo By Source MAC eingestellt ist.