OPNsense Forum
International Forums => German - Deutsch => Topic started by: Dunuin on February 22, 2021, 01:26:01 am
-
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?
-
Tcpdump vlan2:
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:
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:
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
-
Die Multicast Pakete kommen nicht direkt zur Maschine an, das liegt dann an einem der Hypervisor.
-
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?
-
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?
-
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:
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:
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.
-
Hast Du auf dem FreeNAS "Disable Hardware Offloading" für die phys. Interfaces aktiviert? Wenn nicht, tu das bitte mal.
-
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:
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.
-
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".
-
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?
-
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.
-
Probier doch mal, die OPNsense direkt auf das lagg zu bridgen und die OPNsense die VLAN tags machen zu lassen ...
-
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.
-
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.
-
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.
-
Ich weiß, dass die FreeBSD Bridge definitiv mit Multicast klar kommt. Sowohl IPv6 als auch CARP. Wir haben das in Jails mit epair/bridge gebaut, das funktioniert. Also hängt es am lagg oder am vlan. Da wir auch phys -> vlan -> bridge -> epair produktiv im Einsatz haben, mit IPv6, und da ohne Multicast gar nichts funktionieren würde, nimm doch mal das lagg aus der Konstruktion raus ...
Dann weißt Du, was Du bugs.freebsd.org ins Ticket schreiben musst ;)
-
Ohne lagg kann ich mal versuchen. Das habe ich nur drin weil ich noch eine NIC frei hatte und hier Katzen rumlaufen die gerne Kabel rausziehen. Besonders diese FSP+ DAC Kabel, die entriegeln wenn man an der Plastikschlaufe zieht...da hatten die Entwickler wohl echt nur an Datacenter gedacht wo keine Katzen randalieren ;D
Ist nur immer etwas umständlich da was am lagg zu ändern, weil darüber auch die WebUI läuft, worüber ich das dann ändere.
-
Ok, habe jetzt auf beiden Servern den lagg/bond entfernt und die sind jetzt nur noch über die eine ConnectX-3 NIC verbunden.
Wenn ich jetzt nach den CARP Paketen horche sehe ich auf dem FreeNAS Server überhaupt keine mehr vom Proxmox Server. Auf dem Proxmox-Server kommen aber weiterhin die CARP Pakete vom FreeNAS Server an.
Ich vermute mal da sind die CARP Pakete dann nur am lagg0 angekommen, weil die passive NIC die empfangen konnte, aber wurden dann nicht weitergeleitet, weil die NIC ja passiv war?
In beiden Servern steckt die gleiche mcx311a-xcat. Komisch, dass da beim einen Server alle CARPs angekommen und beim anderen nicht. Ist dann die Frage warum die nicht wollen. In die eine Richtung scheint es ja zu gehen.
Edit:
Habe mal vlan 2 vom switch auf eine andere NIC am FreeNAS Server angeschlossen. Auf der anderen NIC kommen die CARP Pakete an. Die ConnectX3 auf dem Proxmox Server sendet und empfängt die CARP Pakete also richtig und der Switch leitet diese auch korrekt zwischen den 2 Servern weiter.
Problem ist also, dass da die ConnectX3 im FreeNAS Server die CARP Pakete zwar versendet aber keine entgegennehmen mag.
Weiß jemand woran das liegen könnte? Gibt es da bei FreeBSD irgendwelche speziellen Einstellungen die man setzen muss, damit die NIC Multicast-Pakete annimmt?
Wenn ich mir die beiden NICs über ifconfig angucke, dann haben beide ein "MULTICAST" flag.
em0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 9000
description: Bond 1G
options=88<VLAN_MTU,VLAN_HWCSUM>
ether f4:52:14:88:30:60
hwaddr 00:25:90:46:79:89
nd6 options=9<PERFORMNUD,IFDISABLED>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
mlxen0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 9000
description: Bond SFP+
options=8c00a8<VLAN_MTU,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,LINKSTATE>
ether f4:52:14:88:30:60
hwaddr f4:52:14:88:30:60
nd6 options=9<PERFORMNUD,IFDISABLED>
media: Ethernet autoselect (10Gbase-CX4 <full-duplex,rxpause,txpause>)
status: active
Kann das "VLAN_HWTSO" bei der ConnectX3 vielleicht Probleme machen? Das fehlt bei der anderen NIC nämlich. Ich habe aber im Manual von ifconfig auch keine Option gefunden, wie man VLAN_HWTSO deaktivieren könnte. Für die anderen HW Offloading Funktionen gab es da ja Optionen um das zu deaktivieren.
-
Da müsstest Du jetzt langsam wirklich einen Bug bei FreeBSD einkippen, wenn es mit einer Deiner Karten im FreeNAS funktioniert, aber mit der anderen nicht. Das ist ja dann offensichtlich ein Treiber-Bug.
2 verschiedene Karten in einem lagg einzusetzen ist jetzt aber auch nicht grad das empfohlene Setup ...
Du sprichst doch LACP mit Deinem Switch? Ja? Jetzt sag nicht, dass nicht. Dann lass das mit dem lagg ...
-
Da müsstest Du jetzt langsam wirklich einen Bug bei FreeBSD einkippen, wenn es mit einer Deiner Karten im FreeNAS funktioniert, aber mit der anderen nicht. Das ist ja dann offensichtlich ein Treiber-Bug.
Ja, 3 Ports am Switch identisch eingestellt mit gleichen tagged VLANs. Davon 1x SFP+ zum Proxmox, 1x SFP+ zum FreeNAS und 1x Gbit Ethernet zum FreeNAS. Beide SFP+ NICs in den Servern sind identische "mcx311a-xcat". Lasse ich die Intel Gbit NIC unverbunden und nur die beiden SFP+ NICs dran, dann sehe auf dem Proxmox Host CARP Pakete von beiden Servern aber auf dem FreeNAS nur die CARP Pakete von FreeNAS selbst.
Stecke ich zusätzlich das Kabel in die Intel Gbit NIC am FreeNAS Host und gucke was über die Intel NIC läuft, dann sehe ich auch CARP Pakete von beiden Servern.
Also über die Intel NIC scheinen die CARP Pakete in beide Richtungen zu wandern aber über die Mellanox NIC nur ausgehend. Ist halt komisch, weil die baugleiche NIC mit baugleichem DAC am Proxmox Server keine Probleme mit CARP macht.
2 verschiedene Karten in einem lagg einzusetzen ist jetzt aber auch nicht grad das empfohlene Setup ...
Du sprichst doch LACP mit Deinem Switch? Ja? Jetzt sag nicht, dass nicht. Dann lass das mit dem lagg ...
Ich weiß das LACP da Probleme macht mit verschiedenen NICs, besonders wenn eine 10G die andere 1G ist.
Daher hab ich active-passive bzw failover genommen ohne LACP, wo die ja dann nicht gebündelt mit Lastverteilung arbeiten sondern immer nur eine zur Zeit einzeln. Das hatte ja auch soweit gut funktioniert, konnte volle 10Gbit nutzen und wenn ich ein Kabel gezogen habe ist es halt auf 1Gbit umgesprungen und lief dann wenigstens noch mit 1Gbit.
Aber lagg schien hier ja auch nicht das Problem zu sein, wenn die ConnectX3 auch ohne lagg CARP Pakete nur in eine Richtung durchlässt.
-
Alles andere ausser LACP ist Quatsch und funktioniert nicht stabil mit CARP. Bitte auch am Switch igmp snooping deaktivieren, oder du machst Mal nen direkten Crosslink zwischen beiden
-
IGMP Snooping ist deaktiviert.
Habe nochmal beide ConnectX-3 NICs auf die neuste Firmware geflasht und die beiden NICs aus beiden Servern vertauscht. Keine Änderung. FreeNAS will auf der ConnectX-3 keine CARP Pakete annehmen.
Direktlink muss ich mal gucken, da ja alles über das tagged vlan läuft und ich mich dann selbst aus beiden Server aussperre.
Edit:
Auch wenn ich beide NICs direkt per DAC verbinde kommen über die ConnectX-3 am FreeNAS keine CARP Pakete an.
-
Kurz zum Verständnis: Wenn AM FreeNAS keine CARP Pakete ankommen, würde das dann nicht heißen, dass die vom Proxmox aus nicht ankommen? Ist vielleicht auf der Seite was noch unvollständig oder falsch konfiguriert?