Unraid wechselt manchmal auf die falsche Netzwerkkarte

[MAM59]

Moin 🙂

Bei meinem setup treten leider manchmal spontane LAN Störungen auf. Die Ursache ist, dass Unraid aus unerfindlichen Gründen manchmal eth0 mit eth1 verwechselt und den Traffic über die falsche Karte abwickeln will. Die Partner im LAN erkennen den Wechsel anhand der MAC Adresse, und schalten ihren ARP Cache entsprechend um. Wenn UNRAID dann ein paar Sekunden später den Fehler erkennt und zurückschaltet, gibts erstmal heftige Pausen, bis die Caches neu befüllt werden.

Mein Setup:

Unraid Server mit 2*10Gbe zu demselben Switch (aber nicht gedoppelt oder so, die eine Karte macht nur statisch IPV4, die andere statisch nur IPV6) und noch eine 1Gbe Karte zu einem separierten Management LAN (hier gibts auch keine Probleme)

 

Da die eine Karte nur V4 macht und die andere nur V6, dürften sie sich niemals in die Quere kommen. Tun sie leider doch, wie die Protokolle der anderen Maschinen zeigen. ARP gibts ja nur auf V4, es erscheinen aber Einträge, dass die V6 Karte (MAC) mit der V4 Adresse der anderen Karte aktiv war.

 

Hat einer ne Idee, wie man UNRAID diesen Fehler abgewöhnen kann???

 

[Ford Prefect]

...hast Du in unraid eine, keine oder mehrere Bridges definiert in den Netzwerk-Settings?

Die Nummerierung der ethX selbst kannst Du dort festlegen.

 

Was genau ist das Phänomen?

Das unraid die Karten wirklich anders nummeriert?

Oder das der Traffik falsch fliesst?

Was hast Du denn für einen Router und Switches am Start/angebunden und sind nur Clients ausserhalb von unraid betroffen?

 

[MAM59]

2 hours ago, Ford Prefect said:

...hast Du in unraid eine, keine oder mehrere Bridges definiert in den Netzwerk-Settings?

Die Nummerierung der ethX selbst kannst Du dort festlegen.

 

Was genau ist das Phänomen?

Das unraid die Karten wirklich anders nummeriert?

Oder das der Traffik falsch fliesst?

Was hast Du denn für einen Router und Switches am Start/angebunden und sind nur Clients ausserhalb von unraid betroffen?

 

Die Reihenfolge IST genau festgelegt.

Das Phänomen ist, dass einige andere Maschinen im LAN  feststellen, dass die V4 Adresse von Unraid auf einmal unter einer anderen MAC Adresse erscheint (und kurz danach wieder zurückwechselt)

Wie die Karten nummeriert sind, ist mir im Prinzip egal, aber wenn der Traffik zwischen den Karten wechselt, entsteht bei allen Rechnern im LAN erstmal eine Irritation und somit eine komplette Pause. Laufende Verbindungen werden abgebrochen und mit der "neuen" Karte neu aufgebaut. Das geht zwar sehr schnell, aber es sorgt halt dafür, dass nicht der maximale Durchsatz erzielt wird.

(Leider ist auch nicht vorhersehbar, OB und WANN es passiert, die letzten 2 Tage z.B. war gar nix. Aber es passiert mal hin und wieder)

 

Es geht nur um Rechner im LAN (hab gar keine Verbindung zum Internet eingerichtet). Switche sind MicroTik CRS 309 und Buffalo BS 2008 (Unraid hängt aber nur am Buffalo). LAN Karten sind Intel Convergent X550-T2 (Dual Port). Eine Bridge gibts nur für Karte 1 für ne VM (ich würd lieber ohne Bridge arbeiten und den VMs ne eigene 10Gbe Karte geben).

Karte 1 ist nur für IP V4 statisch programmiert, Karte 2 nur IP V6, auch statisch, eingerichtet.

 

ich häng mal die simple Config für die V6 Karte an. Wobei man natürlich auch nicht vergessen zu erwähnen darf, dass UNRAID auf V6 ausgesprochen mager bestückt ist 😞 Wenn man schon "statisch" anwählt, so fehlen dann noch die Felder für DNS Server. Auch darf man das Routerfeld nicht ausfüllen, da UNRAID vergisst, nach Routerankündigungen zu suchen und hier automatisch einträgt, was es glaubt, erkannt zu haben. Das hat alles wenig mit "statisch" zu tun. Sollte mal dringend korrigiert werden.

Unter dieser MAC Adresse tauchen ab und an ARP Pakete auf, die aber nur auf IP V4 existieren dürften.

 

[mgutt]

Hat eth1 wirklich keine IPv4 mehr? Check mal bitte über das Terminal mit dem Kommando ifconfig.

 

Auch mal darüber IPv4 manuell killen:

https://serverfault.com/questions/388501/disable-ipv4-what-exactly-does-ifconfig-eth0-0-do/388504#388504

 

 

[Ford Prefect]

57 minutes ago, Michael Meiszl said:

(Leider ist auch nicht vorhersehbar, OB und WANN es passiert, die letzten 2 Tage z.B. war gar nix. Aber es passiert mal hin und wieder)

....schalten Switche a dran mal ab und wiedre an...port-flapping beobachtet?

Am Switch...STP/RSTP oder MRSTP aktiviert?

 

57 minutes ago, Michael Meiszl said:

 

Es geht nur um Rechner im LAN (hab gar keine Verbindung zum Internet eingerichtet).

...die Frage war, ob es auch bei Dockern / VMs auf unraid passiert?

 

57 minutes ago, Michael Meiszl said:

Switche sind MicroTik CRS 309 und Buffalo BS 2008 (Unraid hängt aber nur am Buffalo). LAN Karten sind Intel Convergent X550-T2 (Dual Port). Eine Bridge gibts nur für Karte 1 für ne VM (ich würd lieber ohne Bridge arbeiten und den VMs ne eigene 10Gbe Karte geben).

Karte 1 ist nur für IP V4 statisch programmiert, Karte 2 nur IP V6, auch statisch, eingerichtet.

Du hast drei Karten...ist die 3te (1G) in dieser Bridge?

In welchen v4 Netz ist die...gleiches Netz wie die 10G-v4?

 

Ich halte eine Bridge für robuster...jedesmal, wenn eine VM oder ein Docker gestartet/gestoppt/ge-cycled wird, gibt es da eine Phase, wo die Karte neu initialisiert wird.

Bei ner Bridge geht das ohne Probleme, bei einer HW-Karte weiss ich es nicht.

 

57 minutes ago, Michael Meiszl said:

ich häng mal die simple Config für die V6 Karte an.

OK, die hat keine Brdige....mal probiert eine eigene zu erstellen, br1 dann.

 

57 minutes ago, Michael Meiszl said:

Unter dieser MAC Adresse tauchen ab und an ARP Pakete auf, die aber nur auf IP V4 existieren dürften.

...ich würde diese Multi-Home "Kacke" auf dem unraid Host nicht machen, sondern mal VLANs aktivieren.

Wenn Du es auf unRaid nicht machen willst, dann als Access-Port mit eigener VID/PID am Switch.

Wie sieht denn die Routing Tabelle aus für v4?

 

[MAM59]

40 minutes ago, mgutt said:

Hat eth1 wirklich keine IPv4 mehr? Check mal bitte über das Terminal mit dem Kommando ifconfig.

 

 

ja, wirklich nicht

br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.4  netmask 255.255.255.0  broadcast 0.0.0.0
        ether a0:36:9f:20:30:00  txqueuelen 1000  (Ethernet)
        RX packets 1430439804  bytes 277884272571 (258.7 GiB)
        RX errors 0  dropped 1318083  overruns 0  frame 0
        TX packets 1069940341  bytes 955614905869 (889.9 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500
        ether a0:36:9f:20:30:00  txqueuelen 1000  (Ethernet)
        RX packets 3134083958  bytes 2414306070394 (2.1 TiB)
        RX errors 0  dropped 2  overruns 0  frame 0
        TX packets 3191576415  bytes 2938673473836 (2.6 TiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 2001:YYYY:XXXX  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::a236:9fff:fe20:3002  prefixlen 64  scopeid 0x20<link>
        ether a0:36:9f:20:30:02  txqueuelen 1000  (Ethernet)
        RX packets 1375459440  bytes 1839269836585 (1.6 TiB)
        RX errors 0  dropped 1480486  overruns 0  frame 0
        TX packets 1504367052  bytes 1963840590300 (1.7 TiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.4.4  netmask 255.255.255.0  broadcast 0.0.0.0
        ether 00:13:3b:12:e4:3f  txqueuelen 1000  (Ethernet)
        RX packets 91889480  bytes 138958411947 (129.4 GiB)
        RX errors 0  dropped 9  overruns 0  frame 0
        TX packets 5599961  bytes 345351255 (329.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 

Was mich etwas wundert sind die Tonnen von Droppeds auf eth1 und br0. Aber das können natürlich V4 und V6 Pakete sein, die auf dem jeweiligen Interface nix zu suchen haben und deshalb sofort in den Orkus wandern (hmm, üblicherweise "frisst" die Karte die sofort, sollten es gar nicht bis zum OS schaffen)

 

[mgutt]

Ergänze mal das in deiner /etc/sysctl.conf:

 

net.ipv6.conf.br0.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1
net.ipv4.conf.eth1.disable_ipv4 = 1

 

Und dann das ausführen um die Änderungen anzuwenden:

 

sysctl -p

 

 

[MAM59]

10 minutes ago, Ford Prefect said:

...ich würde diese Multi-Home "Kacke" auf dem unraid Host nicht machen, sondern mal VLANs aktivieren.

Wenn Du es auf unRaid nicht machen willst, dann als Access-Port mit eigener VID/PID am Switch.

Wie sieht denn die Routing Tabelle aus für v4?

 

>....schalten Switche a dran mal ab und wiedre an...port-flapping beobachtet?

>Am Switch...STP/RSTP oder MRSTP aktiviert?

Hier flappt nix, da würden sofort die Alarmglocken läuten und ich intergalatisch werden. Der letzt "Flap" war, als der lüfterlose Microtik meinte, er bräuchte n Lüfter, weil die Kupferleitung zu lang ist und er zu heiß wird auf dem Port. Seit da ein 120mm PC Lüfter vor dem Switch steht, ist alles im Grünen Bereich (Port 78°, Switch 32°)

Hab im Winter keine Lust, die Wände aufzureissen, nächstes Jahr werden die langen Strecken gegen LWL getauscht.

 

>...die Frage war, ob es auch bei Dockern / VMs auf unraid passiert?

Docker gibts hier nicht, ist Hexenwerk bzw. reiner Pfusch. die VM läuft über BR0 ohne Probleme Aber eigentlich soll UNRAID nur ein Fileserver sein, die VM ist Kür und kann auch wieder weg.

 

>Du hast drei Karten...ist die 3te (1G) in dieser Bridge?

Nein (Netzbelegung siehe vorigen Post, ich hab nur die globale V6 Adresse aus-ge-X-t, da sie wirklich global und statisch ist. UNRAID ist aber darüber nicht von aussen erreichbar, Firewall sei Dank)

>In welchen v4 Netz ist die...gleiches Netz wie die 10G-v4?

Nein, die 1G Karte ist in einem physikalisch getrennten "Video LAN". Dort tummeln sich nur SAT-IP Geräte vebunden über separate Switche. Sie benutzen UNRAID als Fileserver für Aufnahmen.

Für das vorliegende Problem ist die 1G Karte also völlig unerheblich.

 

>Ich halte eine Bridge für robuster...jedesmal, wenn eine VM oder ein Docker gestartet/gestoppt/ge-cycled wird, gibt es da eine Phase, wo die Karte neu initialisiert wird.

>Bei ner Bridge geht das ohne Probleme, bei einer HW-Karte weiss ich es nicht.

DAS IST EINE IDEE! Du meinst also, wenn ich die VM mal stoppe, sollte das Problem auftreten? kann ich gleich mal probieren...

VM gestoppt und gestartet: NO EFFECT 😞

Schade eigentlich, klang plausibel

 

>OK, die hat keine Brdige....mal probiert eine eigene zu erstellen, br1 dann.

Nein, Bridges braucht kein Mensch, ich wäre froh, wenn ich br0 auch loswerden könnte. Kostet nur Zeit, bringt gar nix (solange nur eine Karte dran teilnimmt)

 

>...ich würde diese Multi-Home "Kacke" auf dem unraid Host nicht machen, sondern mal VLANs aktivieren.

Das ist keine Multi-Home "Kacke", sondern saubere Netztrennung. V4 und V6 kriegen so jeder volle 10Gbit/s und das ohne Fakes wie Trunks usw.

(ausserdem sind das eh alles Doppel-Karten, soll ich die eine in der Luft hängen lassen ???)

 

Vielleicht sollte ich betonen, dass ich ein SCHNELLES LAN haben will, keine künstlichen Bremsen oder "von hinten durch die Brust ins Auge".

 

in UNRAID stecken einige 2 und 4 TB NVME "Platten", die wollen schnell zugestellt werden.

 

>Wie sieht denn die Routing Tabelle aus für v4?

Gut :-)))

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.0.253   0.0.0.0         UG        0 0          0 br0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 br0
192.168.4.0     0.0.0.0         255.255.255.0   U         0 0          0 eth2

 

ist doch übersichtlich

 

[MAM59]

13 minutes ago, mgutt said:

Ergänze mal das in deiner /etc/sysctl.conf:

 

net.ipv6.conf.br0.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1
net.ipv4.conf.eth1.disable_ipv4 = 1

 

Done, aber mit mässigem Erfolg:

root@F:~# sysctl -p
fs.inotify.max_user_watches = 524288
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.ip_forward = 1
net.netfilter.nf_conntrack_max = 131072
net.ipv6.conf.br0.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1
sysctl: cannot stat /proc/sys/net/ipv4/conf/eth1/disable_ipv4: No such file or directory

 

ist ja auch eingentlich klar eth1 hat noch nie ipv4 gesehen, da kann man es auch nicht abschalten.

 

Allerdings wundert mich warum er bei eth0 nicht auch meckert, wenn es um das Abschalten von V6 geht...

Oh! könnte das die VM betreffen? mussich mal gucken...

interessanterweise hat die VM immer noch V6 und es funktioniert dort auch! Die Einstellungen scheinen also keinen Effekt zu haben, oder ich muss neu booten? (DAS steht im Moment NICHT zur Debatte!)

 

[mgutt]

33 minutes ago, Michael Meiszl said:

oder ich muss neu booten?

Dann wären die Einstellungen weg. unRAID installiert immer alles neu beim Booten.

 

Aber warum hat die VM IPv6?!

 

Hast du die fehlerhafte Zeile rausgenommen und noch mal den Befehl abgesetzt?

 

Du kannst die Einstellungen auch manuell sofort aktivieren:

echo 1 > /proc/sys/net/ipv6/conf/eth0/disable_ipv6

 

Die restlichen Kommandos dann wie du benötigst.

 

[Ford Prefect]

1 hour ago, Michael Meiszl said:

>....schalten Switche a dran mal ab und wiedre an...port-flapping beobachtet?

>Am Switch...STP/RSTP oder MRSTP aktiviert?

Hier flappt nix, da würden sofort die Alarmglocken läuten und ich intergalatisch werden. Der letzt "Flap" war, als der lüfterlose Microtik meinte, er bräuchte n Lüfter, weil die Kupferleitung zu lang ist und er zu heiß wird auf dem Port. Seit da ein 120mm PC Lüfter vor dem Switch steht, ist alles im Grünen Bereich (Port 78°, Switch 32°)

Hab im Winter keine Lust, die Wände aufzureissen, nächstes Jahr werden die langen Strecken gegen LWL getauscht.

...Du hast ne etwas flapsige Art, wenn ich das mal so sagen darf.

Wenn ein port runtergeht kann das viele Ursachen haben und solche Effekte wie Du sie erlebst verursachen...

Offensichtlich hast Du ja alles im Griff, was Deine Infrastruktur angeht und weisst Bescheid.

Ich tippe mal, wenn es nicht einfach kaputte Kabel sind, auf den Treiber der Intel - da gab es hier schon ein paar mit Beschwerden oder eine Fehl-Konfig in einem der Switche.

Dein Setup ist...um es mal einfach auszudrücken, ungewöhnlich ... 

 

...helfen kann man Dir so aber nur schwer.

[MAM59]

37 minutes ago, Ford Prefect said:

Ich tippe mal, wenn es nicht einfach kaputte Kabel sind, auf den Treiber der Intel - da gab es hier schon ein paar mit Beschwerden oder eine Fehl-Konfig in einem der Switche.

Nee, kaputte Kabel können wir ausschließen. Habe fast 6 Monate lang Kabel ausprobiert, bis endlich stabile Verbindungen da waren. Cat.7 behaupten sie alle, aber die Stecker sind meist unzureichend und wackeln gerne. Aber habe inzwischen wirklich gute gefunden, komischerweise sogar recht billige. Und wir reden hier von 1m und 2m Längen, da geht auch Twisted Pair noch stressfrei. Schwierig wirds so ab 30m, da wird viel Strom verbraten und einige Switches/Karten kommen an ihre Leistungsgrenze.

41 minutes ago, Ford Prefect said:

Dein Setup ist...um es mal einfach auszudrücken, ungewöhnlich ... 

Was bitte ist daran ungewöhnlich? Alles eigentlich sauber getrennt. Fehlersuche recht einfach. Dich stört vielleicht das separate 1Gbe LAN, aber das exisitiert schon seit Urzeiten und sorgt nur dafür, dass QoS nicht von anderen gestört werden kann und die etwas anfälligen IP-SAT Pakete nicht gebremst werden. Es reicht ja schon ein Gerät im LAN, dass dem nicht Folge leistet und schon hast Du Störungen und Fehlpakete in den Videos.

(Und hier gibts REICHLICH Geräte im LAN, aus historischen Gründen sogar noch eine Kiste, die nur 10Mbit/s Ethernet hat und noch 20Jahre weiterlaufen muss)

 

Ich werd mal das Ganze im Auge behalten, Vieleicht krieg ich ja raus, WANN der Zustand auftritt

 

[MAM59]

2 hours ago, mgutt said:

Dann wären die Einstellungen weg. unRAID installiert immer alles neu beim Booten.

Jep, ich vergaß :-)))

 

2 hours ago, mgutt said:

Aber warum hat die VM IPv6?!

Warum sollte sie nicht? über die Bridge kommen doch die RTA Pakete durch, also kriegt jede VM automatisch eine Adresszuweisung (hier gibts kein SLAAC, sondern DHCP6).

Da müsste sich der CLient in der VM schon aktiv gegen wehren (ist Windows, nix Linux), tut sie aber nicht.

 

Aber insofern habt ihr recht, so ganz sauber ist das nicht. Auf ETH0 soll nur V4 erlaubt sein, über die Bridge kommt aber V6 mit rein. Zumindest für die VMs. Da kann ich eigentlich gleich beide Protokolle auf ETH0 packen und ETH1 rausziehen...

War wohl ein Denkfehler meinerseits...

 

 

[Ford Prefect]

15 minutes ago, Michael Meiszl said:

Nee, kaputte Kabel können wir ausschließen. Habe fast 6 Monate lang Kabel ausprobiert, bis endlich stabile Verbindungen da waren.

...ich mache hier 10G über cat5e ... 18m problemlos.

Deine Schilderung lässt vermuten, dass das bei Dir immer noch "wackelig" sein kann....woher kommen Deine Drops?

 

15 minutes ago, Michael Meiszl said:

Was bitte ist daran ungewöhnlich? Alles eigentlich sauber getrennt.

ipv4 ind ipv6 sind getrennte stacks....sollte sogar auf einer Karte simultan funktionieren.

Das Du es auf zwei Karten aufteils macht die Trennung nicht sauberer. Die sind immer noch am gleichen L2 Netzwerk.

Daher auch meine Anmerkung, wenn Du es sauber trennen willst, es über VLANs zu machen.

 

15 minutes ago, Michael Meiszl said:

Fehlersuche recht einfach. Dich stört vielleicht das separate 1Gbe LAN,

nein.

Wenn es einfach ist, mach es...lass ein wireshark mitlaufen...kannst Du ja über einen Switch auskoppeln.

15 minutes ago, Michael Meiszl said:

Ich werd mal das Ganze im Auge behalten, Vieleicht krieg ich ja raus, WANN der Zustand auftritt

s.o....wireshark

[MAM59]

1 minute ago, Ford Prefect said:

s.o....wireshark

zu selten für den Kabelhai. Solange ich nicht genau weiß, wie man das reproduzieren kann, ist Messen recht sinnfrei und folgt der alten Ingenieursweisheit "wer misst, misst Mist".

 

3 minutes ago, Ford Prefect said:

Deine Schilderung lässt vermuten, dass das bei Dir immer noch "wackelig" sein kann....woher kommen Deine Drops?

es sind keine Paketverluste, sondern vielmehr "du bist nicht für mich, ich schmeiss dich weg". Der Switch weißt keinerlei Fehler auf, 1*TX Pause zum Router, 31*TX Pause zur Garage (also da wo UNRAID ist). Das sind aber nur Flow Control Pakete und 31 bei einer Gesamtzahl von über 3 Millionen ist doch recht vernachlässigbar.

 

Was Du im Sinn hast sind Link Verluste durch wacklige Kabel, die gibts hier nicht. garantiert nicht. Die würden auch überall automatisch mitprotokolliert.

 

(und ja, 18m ist noch im grünen Bereich, die kritische Länge fängt bei 30m an. Ab 80 ist dann Glauben angesagt auf Kupfer. Ich hab hier eine Strecke mit 34, das gab Probleme anfangs. Aber die sind nun erstmal ausgeräumt und wie gesagt, nächstes Jahr LWL, da ist dann selbst das billigste Modul für 300m gut)

 

 

[MAM59]

Also ich hab ja nun eth1 abgeschaltet, da "passiert" dann nix mehr.

 

Aber vorher gabs nochmal einen solcher Anfälle:

 

Quote

l3router.XXXXl.de kernel log messages: +arp: 192.168.0.4 moved from a0:36:9f:20:30:00 to a0:36:9f:20:30:02 on ix1

 

Das passiert wohl immer dann, wenn das Array gestoppt ist und man in den Netzwerkeinstellungen irgendwas ändert.

 

Wie oben schon vermutet, werden danach die Karten neu initialisiert und dabei tritt der "Fehler" auf.

Ist also wohl harmlos. Allerdings ist es schon merkwürdig, dass er die falsche V4 Adresse auf ein V6-only Interface initialisiert um es danach sofort wieder zu löschen...

 

Nun könnte ich den Kabelhai entsprechend triggern und mir genauer angucken, was da abgeht. Aber der Aufwand lohnt wohl nicht, deshalb können wir diesen Thread hier wohl schließen.

 

[Ford Prefect]

Das "Problem" könnte eben sein, dass die ja auf L2 in einem Netz sind, aber Du auf L3 unterschiedliche Netze (zwar v4 und v6 in getrennten Stscks) nutzt.

Evtl. ist da der Treiber auch nicht ganz OK oder eben auf Ebene unRaid die Bridge nicht ganz "dicht", wenn das passiert.

Ein ARP-Request ist eben L2....daher denke ich, mit VLANs am Start, im Switch und unRaid würde das dann nicht mehr passieren. Bei mir laufen die L" der VLANs sauber (habe aber nur v4 am Start).