CARP Split Brain mit VMs

[Dunuin]

Ich habe da ein ähnliches Problem.

Eine OPNsense läuft als VM auf einem Proxmox Server, eine andere OPNsense als VM auf einem FreeNAS Server.
Beide OPNsenses sind ständig Master.
Ich habe jetzt auf beiden Servern mal mit tcpdump die Pakete untersucht ob die CARP Pakete irgendwo verloren gehen.

Netzwerk ist bei mir so:

OPNsense VM -> vmbr2 (bridge) -> bond0.2 (vlan) -> bond0 (failover) -> zwei NICs -> Switch <- zwei NICs <- lagg0 (failover) <- vlan2 <- bridge2 <- OPNsense2 VM

Wenn ich an vmbr2 mithorche sehe ich CARP Pakete von beiden VMs.
Wenn ich an vlan2 mithorche sehe ich nur CARP Pakete von der OPNsense2 VM.
Wenn ich an lagg0 mithorche sehe ich CARP Pakete von beiden VMs.

Also irgendwie schaffen es die CARP Pakete von der OPNsense2 VM komplett rüber zur OPNsense VM, aber die CARP Pakete von der OPNsense VM bleiben irgendwo zwischen lagg0 und vlan2 stecken.

Hat jemand eine Ahnung warum die Pakete da stecken bleiben?

[Dunuin]

Tcpdump vlan2:

Code Select Expand

tcpdump -B 16000 -i vlan2 -s0 -vv -n | grep VRRPv2
tcpdump: listening on vlan2, link-type EN10MB (Ethernet), capture size 262144 bytes
    192.168.0.3 > 224.0.0.18: vrrp 192.168.0.3 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 36, addrs(7): 204.26.121.131,113.231.163.36,111.27.69.51,139.52.213.104,103.208.241.213,47.0.182.224,252.5.96.64
    192.168.0.3 > 224.0.0.18: vrrp 192.168.0.3 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 36, addrs(7): 41.158.64.171,149.16.125.193,4.191.90.167,232.125.20.154,100.184.50.211,12.127.42.235,115.221.179.11
    192.168.0.3 > 224.0.0.18: vrrp 192.168.0.3 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 36, addrs(7): 56.238.168.180,162.56.17.240,137.1.45.56,91.38.150.2,7.134.32.57,88.104.65.61,66.78.169.91

Tcpdump lagg0:

Code Select Expand

tcpdump -B 16000 -i lagg0 -s0 -vv -n | grep VRRPv2
tcpdump: listening on lagg0, link-type EN10MB (Ethernet), capture size 262144 bytes
    192.168.0.3 > 224.0.0.18: vrrp 192.168.0.3 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 36, addrs(7): 111.100.125.40,62.223.145.20,142.113.126.246,185.154.196.161,103.0.53.151,212.222.211.243,85.170.90.42
    192.168.43.3 > 224.0.0.18: vrrp 192.168.43.3 > 224.0.0.18: VRRPv2, Advertisement, vrid 3, prio 100, authtype none, intvl 1s, length 36, addrs(7): 96.66.4.97,132.211.112.69,212.103.17.121,143.149.122.238,4.30.250.155,65.48.107.187,65.63.152.79
    192.168.42.3 > 224.0.0.18: vrrp 192.168.42.3 > 224.0.0.18: VRRPv2, Advertisement, vrid 5, prio 100, authtype none, intvl 1s, length 36, addrs(7): 32.109.10.203,100.5.167.83,103.19.183.233,178.227.26.106,226.114.149.25,181.206.12.219,83.59.18.64
    192.168.0.3 > 224.0.0.18: vrrp 192.168.0.3 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 36, addrs(7): 111.100.125.40,62.223.145.20,142.113.126.246,185.154.196.161,103.0.53.151,212.222.211.243,85.170.90.42
    192.168.43.3 > 224.0.0.18: vrrp 192.168.43.3 > 224.0.0.18: VRRPv2, Advertisement, vrid 3, prio 100, authtype none, intvl 1s, length 36, addrs(7): 96.66.4.97,132.211.112.69,212.103.17.121,143.149.122.238,4.30.250.155,65.48.107.187,65.63.152.79
    192.168.42.3 > 224.0.0.18: vrrp 192.168.42.3 > 224.0.0.18: VRRPv2, Advertisement, vrid 5, prio 100, authtype none, intvl 1s, length 36, addrs(7): 32.109.10.203,100.5.167.83,103.19.183.233,178.227.26.106,226.114.149.25,181.206.12.219,83.59.18.64
    192.168.0.2 > 224.0.0.18: vrrp 192.168.0.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 0, authtype none, intvl 1s, length 36, addrs(7): 111.100.125.40,62.223.145.21,135.66.16.237,211.4.211.42,117.193.93.14,212.76.235.95,104.10.216.75


Tcpdump vmbr2:

Code Select Expand

tcpdump -B 16000 -i vmbr2 -s0 -vv -n | grep VRRPv2
tcpdump: listening on vmbr2, link-type EN10MB (Ethernet), capture size 262144 bytes
    192.168.0.3 > 224.0.0.18: vrrp 192.168.0.3 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 36, addrs(7): 121.117.48.10,56.7.253.87,70.65.213.181,67.105.250.170,222.9.115.236,50.252.143.196,169.224.5.94
    192.168.0.2 > 224.0.0.18: vrrp 192.168.0.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 0, authtype none, intvl 1s, length 36, addrs(7): 121.117.48.10,56.7.253.88,58.219.37.12,15.210.142.91,192.209.83.22,41.242.4.18,137.13.56.178
    192.168.0.2 > 224.0.0.18: vrrp 192.168.0.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 0, authtype none, intvl 1s, length 36, addrs(7): 121.117.48.10,56.7.253.89,16.104.17.98,215.206.131.78,42.128.191.9,19.252.151.219,186.215.188.18
    192.168.0.3 > 224.0.0.18: vrrp 192.168.0.3 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 36, addrs(7): 75.106.105.61,145.109.17.99,48.110.165.149,172.62.82.112,114.186.137.221,186.29.255.226,22.90.25.111
    192.168.0.2 > 224.0.0.18: vrrp 192.168.0.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 0, authtype none, intvl 1s, length 36, addrs(7): 75.106.105.61,145.109.17.100,86.107.71.132,149.44.192.90,221.144.124.56,111.128.79.123,117.35.199.20
    192.168.0.3 > 224.0.0.18: vrrp 192.168.0.3 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 36, addrs(7): 35.220.254.150,215.66.139.39,133.190.110.130,88.215.243.94,211.204.175.144,249.115.200.64,153.255.214.192
    192.168.0.2 > 224.0.0.18: vrrp 192.168.0.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 0, authtype none, intvl 1s, length 36, addrs(7): 35.220.254.150,215.66.139.40,151.189.205.255,16.22.81.156,215.5.36.88,254.222.251.113,140.137.102.211


[mimugmail]

Die Multicast Pakete kommen nicht direkt zur Maschine an, das liegt dann an einem der Hypervisor.

[Dunuin]

Ja, gehen in einer Richtung halt komplett durch und in der anderen Richtung scheitert es zwischen lagg0 und vlan2.
Ich habe mir auch noch einmal mit Wireshark den Header angeguckt, da haben die CARP Pakete auf lagg0 (tagged vlan interface) mitgeschnitten noch korrekt vlan 2 gesetzt. Mein Interface "vlan2" was dann alles aus vlan 2 als untagged Traffic über die Bridge an die VM leiten sollten hat dann aber keine CARP Pakete mehr.

Da hat niemand einen Tipp woran das liegen könnte?

[Patrick M. Hausen]

Auf welchem der beiden Hypervisor läuft denn die VM, die die Pakete verschluckt?
Wenn das Proxmox ist, muss der evtl. den promiscuous mode für den Gast ausdrücklich erlauben so wie ESXi auch?
Wenn es bhyve ist mit lagg -> vlan -> bridge -> tap, hast Du alles hardware offloading auf den phys. ports deaktiviert?

[Dunuin]

Auf dem Proxmox-Host läuft alles. Das Problem ist der FreeNAS-Host.
Bis zum bhyve-Gast schaffen es die Pakete ja garnicht erst.

Also das geht wunderbar:
lagg <- vlan <- bridge <- tap <- bhyve Gast (OPNSense2)

OPNsense im bhyve kann CARP schicken, die gehen dann durch das tap, durch die bridge, werden vom vlan als vlan 2 getaggt, gehen dann getaggt über das lagg zum Switch und dann zum Proxmox-Host und bei dem auch einmal komplett durch.

Was nicht geht ist die andere Richtung. Da kommen die CARP Pakete vom Proxmox-Host zwar als tagged traffic mit vlan 2 bei den NICs an, gehen dann auch korrekt über das lagg (immer noch mit vlan 2 tag im Header) aber dann ist Schluss. Auf vlan + bridge + tap ist von den CARP Paketen des Proxmox-Hosts nichts mehr zu finden. Das einzige was da noch rumfliegt sind die ausgehenden CARP Pakete vom bhyve Gast.

Kann das vielleicht irgendwie damit zusammen hängen, dass da bei mir OPNsense per MAC Spoofing beiden physischen IPs die selbe MAC verpasst und dann FreeBSD irgendwie durcheinander kommt und die Pakete am vlan interface verwirft, wo die dann von Tagged Traffic zu Untagged Traffic übersetzt werden?

Oder ist es normal, dass da die beiden OPNsense VMs die normale MAC vom Interface für die virtual IPs verwenden und dann für die "physischen" IPs zwei identische MACs generiert werden? Ich hätte gedacht das müsste anders herum sein.

So sieht das bei mir aus:
192.168.0.1 ist meine Fritzbox vom ISP
192.168.0.2 ist die physische WAN IP der OPNsense auf dem Proxmox-Server.
192.168.0.3 ist die physische WAN IP der OPNsense auf dem FreeNAS-Server
192.168.0.4 ist als virtuelle IP bei beiden VMs eingestellt.

Meine Interfaces in den VMs sehen dann so aus:

OPNsense VM auf Proxmox-Server:

Code Select Expand

ifconfig vtnet1
vtnet1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=800a8<VLAN_MTU,JUMBO_MTU,VLAN_HWCSUM,LINKSTATE>
        ether fe:41:dc:03:e2:67
        inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255
        inet 192.168.0.4 netmask 0xffffff00 broadcast 192.168.0.255 vhid 1
        inet6 xxx%vtnet1 prefixlen 64 scopeid 0x2
        carp: MASTER vhid 1 advbase 1 advskew 0
        media: Ethernet 10Gbase-T <full-duplex>
        status: active
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>


OPNsense VM auf FreeNAS-Server:

Code Select Expand

ifconfig vtnet1
vtnet1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=80028<VLAN_MTU,JUMBO_MTU,LINKSTATE>
        ether 00:a0:98:6f:54:71
        inet 192.168.0.3 netmask 0xffffff00 broadcast 192.168.0.255
        inet 192.168.0.4 netmask 0xffffff00 broadcast 192.168.0.255 vhid 1
        inet6 xxx%vtnet1 prefixlen 64 scopeid 0x2
        carp: MASTER vhid 1 advbase 1 advskew 100
        media: Ethernet 10Gbase-T <full-duplex>
        status: active
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

Wenn ich bei der Fritzbox gucke, was da bei mir im Netz hängt, dann sehe ich aber folgendes:

OPNsense VM am Proxmox an, OPNsense VM am FreeNAS aus:
FE:41:DC:03:E2:67 192.168.0.4
00:00:5E:00:01:01 192.168.0.2

OPNsense VM am Proxmox aus, OPNsense VM am FreeNAS an:
00:A0:98:6F:54:71 192.168.0.4
00:00:5E:00:01:01 192.168.0.3

OPNsense VM am Proxmox an, OPNsense VM am FreeNAS an:
FE:41:DC:03:E2:67 192.168.0.4
00:A0:98:6F:54:71 192.168.0.4
00:00:5E:00:01:01 192.168.0.2 oder 192.168.0.3 bei nie gleichzeitig, weil es wohl einen Konflikt wegen identischer MAC gibt.

[Patrick M. Hausen]

Hast Du auf dem FreeNAS "Disable Hardware Offloading" für die phys. Interfaces aktiviert? Wenn nicht, tu das bitte mal.

[Dunuin]

Auch wenn auf FreeNAS für alle Interfaces the "disable Hardware Offload" Checkbox aktiviere und reboote habe ich das gleiche Problem. Werder immer noch von lagg0 nach vlan2 verschluckt.

Was ich über vlan2 reinbekomme sind ziemlich viele Pakete wie dieses hier:

Code Select Expand

14:44:00.330231 e8:df:70:2c:73:05 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x8912), length 60:
        0x0000:  0170 a000 0000 1f84 74a3 97a2 5553 bef1  .p......t...US..
        0x0010:  fcf9 796b 5214 13e9 e200 0000 0000 0000  ..ykR...........
        0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............
14:52:38.522921 e8:df:70:2c:73:05 > 00:b0:52:00:00:01, ethertype Unknown (0x88e1), length 60:
        0x0000:  0068 a000 b052 1874 ed7f 0000 0000 0000  .h...R.t........
        0x0010:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............

Kann es sein, dass das mal die CARP Pakete waren und die irgendwie von lagg0 nach vlan2 kaputt gehen?

Edit:
Das sind wohl Pakete von der Fritzbox.

[JeGr]

Ich trenne das ab, das macht hier im alten Thread (https://forum.opnsense.org/index.php?topic=18278) IMHO keinerlei Sinn und irritiert eher, aber ein phys. Cluster mit 2 VMs auf noch dazu unterschiedlichen HVs ist nichtmal im Ansatz "das gleiche Problem".

[Patrick M. Hausen]

Auch wenn auf FreeNAS für alle Interfaces the "disable Hardware Offload" Checkbox aktiviere und reboote habe ich das gleiche Problem. Werder immer noch von lagg0 nach vlan2 verschluckt.

Dann gehen mir die Ideen aus. Allerdings sieht Dein tcpdump danach aus als ob die Pakete auf dem lagg0 ungetaggt reinkommen. Oder vertue ich mich da? Guck Dir doch mal normalen Unicast-Traffic auf dem Interface an. Weiß Dein Switch, dass das ein Trunkport ist und dass VLAN 2 getaggt transportiert werden soll?

[Dunuin]

Bis auf die CARP Pakete läuft da alles. Über das lagg0 laufen 8 verschiedene VLANs die alle wunderbar funktionieren. Die OPNsense-VM läuft auch. Die kommt auch ins Internet und so (über das gleiche vlan interface wo die CARP Pakete stecken bleiben) und kann auch zwischen DMZ, LAN und WAN routen. DMZ, LAN und WAN laufen alle über das lagg0, haben dann je ein eigenes Vlan interface, eine eigene Bridge und eigene Virtio NIC.

Also mit Unicast scheint es da keine Probleme zu geben.

[Patrick M. Hausen]

Probier doch mal, die OPNsense direkt auf das lagg zu bridgen und die OPNsense die VLAN tags machen zu lassen ...

[Dunuin]

Das klappt leider nicht, wenn ich das im FreeNAS Forum richtig verstanden habe.

Laut den Infos dort können die Bridges von FreeNAS kein VLAN. Und die VM muss ich ja über eine Bridge irgendwie an die physische NIC kommen, da über die gleiche NIC auch alle Dienste wie SMB und Co vom Host selbst laufen. Dort wurde mir gesagt die einzige Möglichkeit wäre vor die Bridge ein Vlan Interface zu hängen, dass da der Tagged Traffic vom Lagg zu normalen Untagged Traffic umgewandelt wird, damit die Bridge nur Untagged Traffic leiten muss.

Und zu mindestens für alles außer CARP klappt das ja auch gut.

Edit:
Hab nochmal ein Bild von dem Setup angehängt.
Rote Linie ist da, wo die CARP Pakete von lagg0 nach vlan2, vlan42 und vlan43 verschollen gehen. Andere Richtung klappt. Alle CARP Pakete kommen von der oberen VM durch bis zu unteren VM.
Und alles was kein CARP ist geht auch wunderbar komplett in beide Richtungen durch von VM zu VM.

[JeGr]

Darf ich trotzdem mal zwischendurch fragen welchen effektiven Sinn man da verfolgt hat, sich selbst - relativ masochistisch ;) - das Leben schwer zu machen indem man versucht CARP mit zwei verschiedenen VMs in verschiedenen HVs zu basteln, die so gar nicht ähnlich sind und bei denen selbst das BaseOS noch unterschiedlich ist (was heißt selbst die NICs heißen nicht mal gleich)? Neugier und Spielfreude? :)

Denn gerade solche Punkte sind ja schon der Grund, warum es nicht umsonst empfohlen wird zwei gleiche HW oder Setups zu nutzen wenn man CARP Systeme baut.

[Dunuin]

Naja, Ich habe hier daheim halt nur 2 Server die ständig laufen und ein dritter ist auch nicht drin, weil die beiden jetzt schon 50€ im Monat an Strom fressen und damit den Großteil meiner Stromrechnung ausmachen.

Einfach nur eine OPNsense als VM mag ich aber auch nicht, weil mein Netzwerk hier zu komplex ist, als dass ich da mal eben einen normalen OpenWRT Router als Ersatz anschließen könnte, wenn mal der Server mit der OPNsense-VM kaputt gehen sollte.
Und wenn dann OPNsense mein Haupt-Router ist, dann würde hier daheim garnichts mehr laufen...nicht mal mehr das Internet. Und wenn ich dann ein paar Wochen brauche um den Fehler am Server zu finden oder defekte Hardware auszutauschen, dann wäre das schon echt übel.
Wenn OPNsense auf beiden Servern läuft und sich synchronisiert, dann habe ich das Risiko ja nicht mehr.
Auch kommt dann noch hinzu, dass da meine automatischen Backups ziemlich lange dauern können (aktuell so 2 Stunden) und sich in der Zeit dann auch die VMs runterfahren. Wenn ich auch die OPNsense VM sichern möchte, dann wäre auch das Internet und Co für etliche Minuten tot. Das Problem würde ein HA Setup dann ja auch beheben.

Und die Server sind halt leider nur einmal Proxmox als Hypervisor und einmal FreeNAS als NAS. Wollte ich halt das beste draus machen.

Einzeln laufen die beiden OPNsense-VMs übrigens bestens. Routen beide wie sie es sollen. Aber HA geht halt nicht, weil beide dann immer Master sind und sich in die Quere kommen. Syncen der Konfig von einem zum anderen klappt übrigens auch.

Wenn es garnicht klappen sollte würde ich sonst immer nur eine OPNsense-VM zur Zeit laufen lassen und nur gelegendlich mal die zweite hochfahren, damit die Konfig gesynt werden können. Dann wäre da ja wenigstens eine zweite identische OPNsense da, die ich zur Not aktivieren könnte.
Aber HA wäre halt schon netter, gerade wegen den Backups wenn die OPNsense-VM selbst runterfahren muss.
Wenn OPNsense schon so ein tolles HA Feature hat, dann würde ich das natürlich auch gerne nutzen.