Zusammenfassung

In den Netzwerk-Einstellungen muss bridging ("Netzwerkbrückung") immer aktiviert sein, egal ob ipvlan oder macvlan verwendet wird.

Wenn bridging deaktiviert ist, verbreitet Unraid ansonsten pro Netzwerkbuchse zwei MAC-Adressen, wodurch Netzwerkprobleme resultieren können (Ladeprobleme in WebGUI, PING-Verluste, SMB Transfers extrem gestört, etc.).

Technischer Hintergrund

Unraid erzeugt bei inaktivem bridging ein zusätzliches virtuelles Netzwerk-Gerät pro LAN-Buchse. Z.B. eth0 hat dann zusätzlich noch virt0@eth0. Dieses zweite Gerät ist für Docker gedacht und besitzt eine andere MAC-Adresse. D.h. wenn ihr Daten von einem Docker Container erhaltet, kommen diese - obwohl gleiche IP wie Unraid - von einer anderen MAC-Adresse.

Was rein technisch erstmal in Ordnung ist, kollidiert aber mit ARP. Denn bei IPv4 ist es Standard, dass Clients in das Netzwerk reinrufen (broadcast) und fragen, welche MAC-Adresse eine IP-Adresse hat (= ARP). Siehe auch:

https://de.wikipedia.org/wiki/Address_Resolution_Protocol

Der Unraid Server beantwortet diese Anfrage, weil er die MAC-Adresse zu der IP kennt. Allerdings versendet er zwei Antworten, weil ihm eben zwei MAC-Adressen zu der IP bekannt sind.

Der Client speichert dann per Zufall eine dieser beiden MAC-Adressen in seiner ARP Tabelle.

Sollte sich der Client nun die MAC-Adresse von Docker gemerkt haben, kann dieser nicht mehr die Unraid WebGUI, Netzwerk-Freigaben, usw. erreichen.

Sobald der Client dann wieder die MAC-Adresse von Unraid selbst in seiner ARP Tabelle gespeichert hat, läuft es wieder.

Allerdings wechselt das ständig hin und her und das fühlt sich dann effektiv wie zufällige Netzwerkstörungen an.

Fritz!Box

Manche User berichten, dass das ein Problem sei, dass "nur" bei billiger Consumer Hardware auftritt. Beispielsweise trete das bei OpenSense nicht auf. Ich bleibe allerdings dabei, dass das Problem bei Unraid verursacht wird und OpenSense vermutlich einfach nur selbst auf die ARP-Anfragen als Proxy antwortet oder sonst wie verhindert, dass die doppelten ARP-Antworten von Unraid bis zum Client durchkommen.

TL;DR

Ich bin in den letzten Wochen echt wahnsinnig geworden, weil ich phasenweise je nach Last und Verbindungsdauer massive Performance-Probleme zu beklagen hatte:

• sehr langsame SMB Transfers

• 10% PING Verluste

• langsame GUI (stark verzögerte Aktualisierung)

• langsame Übernahme von Terminal-Eingaben

Nun weiß ich aber endlich warum.

Und zwar hatte ich folgendes eingestellt:

• Enable bonding: No

• Enable bridging: No

Denn ich dachte "wozu". Ich habe ja keine Container auf br0. Was ich nun nicht wusste: Dadurch wechselt der Docker-Dienst AUTOMATISCH auf macvlan. Das war mir aber erst mal nicht bewusst.

Ich fand irgendwann heraus, dass arp auf meinem Client für meinen Server eine falsche MAC-Adresse anzeigte:

PS C:\Users\Marc> arp -a

Schnittstelle: 192.168.178.84 --- 0xd
  Internetadresse       Physische Adresse     Typ
  192.168.178.8         02-ee-e8-83-8a-5e     dynamisch

Dann machte ich mich beim Server auf die Suche gemacht und fand dort auch die MAC-Adresse:

root@thoth:~# ip a | grep -B2 5e
9: vhost0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
qdisc fq state UP group default qlen 500
 link/ether 02:ee:e8:83:8a:5e brd ff:ff:ff:ff:ff:ff

Doch woher kam die? Ich dachte erst an den VM-Dienst, aber der war nicht aktiv. bridging und bonding war ja wie gesagt auch aus und dann sah ich eben, dass docker auf macvlan lief und sich nicht mehr ändern ließ:

Hier fand ich dann die Info, dass man bridging aktivieren MUSS, damit man ipvlan nutzen kann:

https://www.reddit.com/r/unRAID/comments/1905g2v/in_unraid_6126_and_all_612x_versions_i_cant/

Daraufhin konnte ich dann zurück zu ipvlan und SOFORT war die "falsche" MAC-Adresse aus der arp Liste des Clients verschwunden und damit auch ALLE Netzwerkprobleme:

Schnittstelle: 192.168.178.84 --- 0xd
  Internetadresse       Physische Adresse     Typ
  192.168.178.8         88-c9-b3-b5-0e-ee     dynamisch

Laut KI (ich bin kein Netzwerker) ist es wohl so, dass bei aktivem macvlan der Docker Dienst hingeht und einen vhost0@eth0 Eintrag mit einer virtuellen MAC-Adresse erzeugt. Wenn Clients dann ARP Anfragen versenden, ist es Zufall, welche MAC-Adresse vom Server zurückkommt und wenn man Pech hat, ist es die vom Docker Dienst. Der Client sendet dann seinen Traffic nicht mehr an Unraid, sondern Docker. Der weiß wiederum nichts von SMB, WebGUI, Terminal, usw. und schmeißt ihn einfach weg = Netzwerkprobleme.

Für mich fühlt sich das wie ein Bug in Unraid an. Aber das müsste @limetech bewerten. Meiner Ansicht nach sollte Unraid die vhost0@ethX Netzwerk-Geräte NUR dann erzeugen, wenn sie eine von Unraid ABWEICHENDE IP-Adresse besitzen. Also zB dann, wenn man einen Container mit einer anderen IP-Adresse startet.

Das ist deren macvtap work around für die macvlan call traces, die ja seit glaube ich 6.12.11 gefixt sind.

Das man eth0 nicht mehr "nackt" benutzen kann ist echt schade. Hab deswegen briding an um das vhost interface loszuwerden

Edited October 17, 2025Oct 17 by Mainfrezzer

Nun, dann darf es dem User nicht mehr möglich sein das bridging zu deaktivieren, solange dieser Workaound notwendig ist.

Ist ja nicht mehr notwendig, schon lange nicht mehr, da es ein paar Kernelversionen vor dem 6.12.11 (Unraid Version) Kernel gefixt wurde. Aber so ist es nun mal mit temporären Hilfsmittel, die bleiben permanent.

Glaube der einzige positive Grund der da erwähnenswert ist, fürs beibehalten, hat was mit VMs zu tun und deren Anbindung. Die hätten schon damals, als dieser "fix" kam, die Option zum deaktivieren des macvtap/vhost hinzufügen sollen. Die Option sind da zurzeit limitiert ohne groß da selbst mit den Systemdateien rumzufummeln.


Ich hab mich schon damals geärgert deswegen
[6.12.6] Macvtap causes consistent package loss - Stable Releases

Edited October 17, 2025Oct 17 by Mainfrezzer

Wie ist denn nun "the way to go"? Das wird mir hieraus nicht klar.

Ich habe bspw. bei Unifi regelmäßig, dass die IP des Servers (192.168.1.100) "mehrfach" verwendet wird - und ich habe schon die allermeisten Docker im VLAN "192.168.10.0/24".

2 hours ago, k3vbert said:

Ich habe bspw. bei Unifi regelmäßig, dass die IP des Servers (192.168.1.100) "mehrfach" verwendet wird -

Ich habe oben eine Zusammenfassung ergänzt.

Das wird aber vermutlich dein Problem nicht beheben, da bei macvlan ja meine ich jeder docker eine eigene MAC-Adresse bekommt oder nicht? Habe ich jedenfalls nicht getestet. Check einfach mal den Output von ip a und suche nach den IP/MACs, die du doppelt siehst.

Die KI schlägt dieses command vor:

for c in $(docker ps -q); do
  name=$(docker inspect -f '{{.Name}}' "$c" | sed 's#^/##')
  mac=$(docker inspect -f '{{range $k,$v := .NetworkSettings.Networks}}{{$v.MacAddress}}{{end}}' "$c")

  if [ -z "$mac" ]; then
    echo "--- $name ---"
    echo "  (no MAC / host network mode)"
    continue
  fi

  echo "--- $name ---"
  host_if=$(ip -o link | awk -v mac="$mac" '$0 ~ mac {print $2}' | sed 's/://')
  if [ -n "$host_if" ]; then
    echo "  MAC: $mac  ->  Host IF: $host_if"
  else
    echo "  MAC: $mac  ->  (no host device, likely ipvlan)"
  fi
done

Ich erhalte das, weil bei ipvlan nach außen keine MAC-Adressen publiziert werden:

--- nextcloud-mariadb ---
  MAC: 02:42:ac:11:00:04  ->  (no host device, likely ipvlan)
--- nextcloud ---
  MAC: 02:42:ac:11:00:05  ->  (no host device, likely ipvlan)
--- home-assistant ---
  (no MAC / host network mode)
--- npm ---
  (no MAC / host network mode)

Danke, habe es mal geprüft:

Output von ip a spuckt das hier aus:

3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 1000

    link/ether 10:7c:61:b8:33:c4 brd ff:ff:ff:ff:ff:ff

    inet 192.168.1.100/24 metric 1 scope global eth0

       valid_lft forever preferred_lft forever

5: vhost0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 500

    link/ether 02:4f:e0:d1:f2:97 brd ff:ff:ff:ff:ff:ff

    inet 192.168.1.100/24 scope global vhost0

       valid_lft forever preferred_lft forever

Also scheint eth0 und vhost0 die gleiche IP zu nutzen - wie auch immer ich das ändern kann.

6 minutes ago, mgutt said:

jeder docker eine eigene MAC-Adresse bekommt

Korrekt, ich sehe auch in Unifi jeden gestarteten Container mit seiner MAC & IP.

Wenn ich das von dir vorgeschlagene Skript (KI) verwende bekomme ich jeden Container und seine MAC aufgelistet mit dem Hinweis "no host device, likely ipvlan".

1 hour ago, k3vbert said:

wie auch immer ich das ändern kann.

Nur durch Aktivierung von bridging, aber das "verbietet" Unraid wegen dem Kernel Bug:

https://docs.unraid.net/unraid-os/release-notes/6.12.4/

The root of the problem is that macvlan used for custom Docker networks is unreliable when the parent interface is a bridge (like br0), it works best on a physical interface (like eth0) or a bond (like bond0). We believe this to be a longstanding kernel issue and have posted a bug report.

Dh macvlan + bridging = Crash Gefahr

Hast du host to custom network aktiviert? Laut dem Text hilft das:

However, some users have reported issues with port forwarding from certain routers (Fritzbox) and reduced functionality with advanced network management tools (Ubiquity) when in ipvlan mode.

For those users, we have a new method that reworks networking to avoid issues with macvlan. Tweak a few settings and your Docker containers, VMs, and WireGuard tunnels should automatically adjust to use them:

• Settings > Network Settings > eth0 > Enable Bonding = Yes or No, either work with this solution

• Settings > Network Settings > eth0 > Enable Bridging = No (this will automatically enable macvlan)

• Settings > Docker > Host access to custom networks = Enabled

Moin,

Das Thema interessiert mich auch da mir auch schon aufgefallen ist das die Perfomance nicht so dolle ist, ob System selbst oder wie die angesprochene SMB Transfers.
Ich hab das mal Docker auf IPvlan gestellt fahren die Container mit Netzwerktyp: br0 nicht mehr hoch.

Hier mal meine Aktuelle Docker Settings und Netzwerksetting aktuell hab ich es wieder macvlan da sonst nichts läuft.
Welche bridging Einstellung ist gemeint eigentlich Docker oder Netzwerkeinstellung?

8 minutes ago, SvensenDE said:

Ich hab das mal Docker auf IPvlan gestellt fahren die Container mit Netzwerktyp: br0 nicht mehr hoch.

Wenn du container mit eigenen IP-Adressen brauchst, musst du macvlan verwenden. Das geht nicht anders.

Und bridging meint die Netzwerk Einstellungen (also "Netzwerkbrückung"). Die "bridge" in Docker ist was anderes.

Ist bei dir aber eh aktiv, daher ist es bei dir wenn ein anderes Thema (hier geht es wie gesagt um PING Verluste, also deutliche Netzwerkprobleme).

52 minutes ago, mgutt said:

Wenn du container mit eigenen IP-Adressen brauchst, musst du macvlan verwenden. Das geht nicht anders.

ah okay hab ich das falsch verstanden dacht du hast das auch mit festen IPadressen für docker

21 minutes ago, mgutt said:

wegen dem Kernel Bug

Der ist aber laut Bugzilla geschlossen und gefixt. "Closing as resolved. Thanks Florian & Pablo!"

8 hours ago, mgutt said:

Hast du host to custom network aktiviert?

Ja, hatte ich bereits aktiv. Habe jetzt testweise auf IPVLAN mit Bridging gestellt und beobachte es jetzt.

Dann verstehe ich nicht wozu das virt0 device aud eth0 noch erzeugt wird 🤔

Ich erst recht nicht 😀 Aber ich kann vermelden, dass bisher alles läuft und ich die Meldung der doppelten IP-Vergabe im UCG-Fiber nicht mehr bekommen habe 🙌

On 10/17/2025 at 11:29 AM, Mainfrezzer said:

Ich hab mich schon damals geärgert deswegen
[6.12.6] Macvtap causes consistent package loss - Stable Releases

Also du auf OpenSense umgestellt hast, hast du da dann das Netzwerk Setup geändert oder alles so gelassen?

Also zb auf VLAN umgestellt?

Ich frage mich, was OpenSense anders macht. Die einzige Idee, die ich hier habe, ist dass wenn der Client die ARP-Broadcast-Anfrage versendet, dass OpenSense im Gegensatz zur Fritz!Box eine der beiden ARP-Antworten von Unraid verwirft. zb weil es erstmal intern abgleicht, welche MAC-Adresse ihm selbst bekannt sind. Oder aber die ARP-Anfragen gehen gar nicht erst zu Unraid durch, weil OpenSense die direkt selbst beantwortet?!

1 hour ago, k3vbert said:

Ich erst recht nicht 😀

Ach, jemand anderes hatte geantwortet 🫣😅

Ok, cool. Auf den Fiber wollte ich bei Glasfaser auch wechseln.

Aber grundsätzlich kann ich mir einfach nicht vorstellen, dass Unraid hier korrekt agiert. Sowie ich das verstanden habe, sind zwar mehrere MAC-Adressen pro IP erlaubt, aber nur sinnvoll, wenn man zb ein HA-Cluster hat, wo es Load Balancing oder Failover gibt.

2 hours ago, mgutt said:

Auf den Fiber wollte ich bei Glasfaser auch wechseln

Ich nutze es derzeit noch mit VDSL, aber nach dem Umzug steht zusätzlich noch Glasfaser zur Verfügung. Damit habe ich dann mit VDSL einen Fallback/Loadbalancer. Das Fiber läuft echt gut, hatte aber vorher auch schon den Dream Router 7.

Für mich macht es nur Sinn eine MAC & eine IP pro Container zu generieren. Aber ich glaube nicht, dass das ein Unraid-Thema ist, sondern eher Docker/Kernel. Ich bin aber auch auf der aktuellsten BETA 🫣 Wer weiß ob/was hier jetzt was geändert oder korrigiert wurde.

BTW und Hard-Offtopic: Mein Bruder sah zufällig unsere Konversation hier und kennt dich noch aus dem Civic-Forum 😃 So klein ist die Welt...

Edited October 21, 2025Oct 21 by k3vbert

On 10/21/2025 at 10:53 AM, mgutt said:

Also du auf OpenSense umgestellt hast, hast du da dann das Netzwerk Setup geändert oder alles so gelassen?

Also zb auf VLAN umgestellt?

Ich frage mich, was OpenSense anders macht. Die einzige Idee, die ich hier habe, ist dass wenn der Client die ARP-Broadcast-Anfrage versendet, dass OpenSense im Gegensatz zur Fritz!Box eine der beiden ARP-Antworten von Unraid verwirft. zb weil es erstmal intern abgleicht, welche MAC-Adresse ihm selbst bekannt sind. Oder aber die ARP-Anfragen gehen gar nicht erst zu Unraid durch, weil OpenSense die direkt selbst beantwortet?!

Ich war nicht derjenige der auf Opensense umgestellt hat, ich hab immer noch die Fritzbox am laufen. Hab damals einfach 6.11.5 weiterbenutzt, bis das behoben war und hab dann wieder die bridge angeworfen

Moin zusammen,

ich habe ein ähnliches Problem, aber doch anders.

Das mit den MACs habe ich auch:

Schnittstelle: 192.168.178.31 --- 0xe
  Internetadresse       Physische Adresse     Typ
  192.168.178.2         00-d8-61-a6-dd-3f     dynamisch --> Korrekt
PS C:\Users\smueh> arp -a 192.168.178.2

Schnittstelle: 192.168.178.31 --- 0xe
  Internetadresse       Physische Adresse     Typ
  192.168.178.2         46-39-87-75-23-da     dynamisch

Nur das ich bridging aktiv habe bei macvlan.

Sobald ich alle Container Stoppe, bleibt die MAC-Adresse vom UnRaid gleich, nur wenn die Container laufen fängt es an zu Spinnen.

Keine der MAC Adressen ist von einem Container oder einer VM.

Ich bin echt ratlos, weil es einfach ohne Änderung angefangen hat.

Edited November 7, 2025Nov 7 by MVLP

Ich bin Eli auf den Sack gegangen und er hat netterweise den Bugreport auf der neuen Plattform wiedereröffnet.

https://product.unraid.net/p/6-12-6-macvtap-causes-consistent-package-loss

Gibt doch noch Hoffnung, diese vhost/macvtap loszuwerden um wieder den "nackten" Netzwerkadapter zu benutzen.

Bei mir läuft macvtap (bridging aus) am Besten. Sobald ich auf bridging mit Macvlan oder Ipvlan umstelle bekomme ich alle paar Sekunden Network Drops auf eth0.

Das ist seit der Umstellung auf Unifi Switche und ein Unifi UCG Fiber so.

Vorher hatte ich eine Fritzbox und einfache Netgear Switche im Einsatz, da war es genau umgekehrt. Network Drops alle paar Sekunden mit deaktiviert bridging, sobald Bridging an war wieder alles gut.

Interessant ist wenn ich einen einfachen Switch zwischen den Unifi Switch und Unraid hänge, gibt es wieder Drops bei macvtap (bridging aus).

Konnte bis jetzt noch nicht rausfinden an was das liegt. Würde eigentlich gerne das Bridging aktivieren um die Fehlermeldung in UCG Fiber wegzubekommen.

Edited March 28Mar 28 by mgl