[Problem] [V3.0 IP5.1] Portainer MAC Adresse doppelt vergeben

[Mibr85]

Hallo zusammen
ich bekomme seit einiger zeit 2 Warnungen angezeigt:




Woran kann das liegen und wie kann ich das Problem beheben?
Danke euch im Voraus

[Sensej]

Hi Micha,
einfach die Mac-Adresse von deinem MQTT-Container manuell ändern?

MfG Juri

[Hiele]

Würde ich auch so machen, einmal auf Edit gehen unten unter Netzwerk anpassen und Depoy...

VG Hiele

[gbglace]

Die aktuelle Software-Version im Betreff ergänzen.

Ohne sind solche Meldungen nicht sauber supportbar.
Und User in der Zukunft brauchen bei ähnlichen Symptomen gleich gar nicht auf die Idee kommen das die Lösungen / Probleme und was folgt eine größere Relevanz für sie hat.

Das Symptom ist aber nicht unbekannt und es gibt Lösungen dafür. Manuelles überschrieben sollte nur der absolut letzte Notnagel sein und ist nicht nachhaltig, da dies einen Recreate des Containers nicht überleben wird.

[blaubaerli]

Hallo Göran,

das mit dem manuellen Überschreiben klappt da nicht. Aber ohne Versionsangabe halt ich mich da zurück.

Ich habe zu dem Thema erst kürzlich noch eine Testreihe gefahren.

Beste Grüße
Jens

[Mibr85]

Bekomme übers Handy den Titel nicht geändert.
Bin bei V3 IP5.1

[blaubaerli]

Hallo Micha,

erst einmal danke für die Versionsangabe.

Zunächst mal ein paar Dinge vorab:

• Die von mir angesprochenen Tests sind mit einer Entwicklungsversion gelaufen "Developer Edition (build time: 17 Jan 2022 13:20:05)"
• Aktuell ist bei mir schon wieder eine neue Version drauf. In dieser ist die Portainer-Version 1.17.1 im Einsatz. Ich habe mir die Kombination der Portainer-Version in Verbindung mit den Timberwolf-Versions-Ständen nicht notiert. Aus diversen Kommentaren vermute ich aber, dass die 1.17.1 seit längerem bei uns zum Einsatz kommt. Daher sollten die Informationen hier grundsätzlich passen.
• Die eigentlichen Ursachen des Problems kenne ich nicht im Detail. Ich habe dazu aber m.E. hier ein dokumentiertes Portainer-Issue gefunden.
• Dann noch ein Zitat aus den bekannten Problemen der Hinweise zur IP 5.1:

  ###########################################################################################################
  
  Bekannte Probleme:
  ...
  Doppelte bzw. mehrfache MAC-Adressen: Mehrere Kunden haben von Problemen in der IP-Kommunikation aus Containern berichtet. Diese sind auf doppelte MAC-Adressen für die Container zurückzuführen. Die genaue Ursache ist nicht gefunden, dürfte in jedoch in Docker und / oder Portainer liegen und steht NICHT im Zusammenhang mit diesem Update selbst, sondern nur mit dem Neustart. Dies tritt auch bei sonstigen Neustarts auf, unabhängig ob ein Update zuvor installiert wurde oder nicht. Wir haben daher u.a. die Darstellung im Container Management ab Version 1.6 erheblich verbessert, doppelte MAC-Adressen werden gelb unterlegt dargestellt. Wir bitten alle Nutzer, die mehr als eine Container nutzen, die Vergabe der MAC-Adressen NACH JEDEM EINZELNEN NEUSTART zu prüfen und in Portainer ggfls. anzupassen, so dass diese eindeutig sind.
  
  Workaround: Timberwolf Server und alle Container auf MacVLAN umstellen.
  
  ###########################################################################################################

Gemäß der Infos unter dem o.g. Link existiert also ein Automatismus, der die IP-Adressen vergibt und daraus ergibt sich implizit dann auch rechnerisch jeweils die MAC-Adresse.

Da das Problem ja nicht bei jedem User auftritt, scheint das schon ein etwas spezielleres Thema. Ich habe den Eindruck, dass das sowohl von der Anzahl der individuell eingerichteten Container, also auch von deren Timingverhalten während des Starts abhängt.

Wenn ich meine manuell eingerichteten Container alle gestoppt habe und nur mit den über die APP-Konstruktion eingerichteten Containern gearbeitet habe, lief das stabil. Wenn ich dann nach gestartetem Wolf meine Container manuell zeitversetzt wieder gestartet habe, kam es da auch zu keinen Problemen

Das manuelle Eingreifen in die MAC-Adressen-Einträge der von mir händisch hinzugefügten Container hatte das Problem übrigens nie gelöst, sondern in der Historie aus dem Gefühl eher verschärft.

Da mir das dann kollosal auf den Wecker ging, bin ich Stefans Hinweis gefolgt und habe meinen Wolf und alle von mir manuell angelegten Container auf MacVLAN umgestellt. Da steckt der Teufel allerdings wirklich im Detail. Zur grundsätzlichen Einrichtung gibt es einen Eintrag in der Knoledge Base. Es sollte einem jedoch bewusst sein, dass die Umstellung der Netzwerk-Konfig von "Bridge" auf "MacVLAN" ein echter GameChanger für die sonstigen netzwerkspezifischen Konfigurationsparameter ist.

Hat man die einzelnen Container umgestellt, erhalten diese nach dem offensichtlich identischen Automatismus wieder eine IP-Adresse, allerdings aus dem IP-Adresskreis des Subnetzes, das mittels MacVLAN zugeordnet wurde. Basierend darauf gibt es dann auch wieder eine errechnete MAC-Adresse. Das führte bei mir dann allerdings im Basisnetz zu doppelten IP-Adressen. Meine Fritzbox vergibt die Adressen grundsätzlich via DHCP. Den Adresskreis habe ich da aber konfigurativ eingeschränkt ab (X.X.X.20) aufwärts. Die X.X.X.2 habe ich meinem Drucker statisch zugeordnet.

Ich hatte bei den MacVLAN-Containern dann zunächst keine IP-Adressen manuell zugeordnet und der Erste hat beim Start dann prompt die Doublette X.X.X.2 zum meinem Drucker erhalten. Also ein wichtiges Ergebnis: Den Containern wird keinesfalls durch Portainer und MacVLAN mittels DHCP aus dem MacVLAN-Subnetz eine IP-Adresse zugewiesen.

Ich habe jetzt aus dem bei mir reservierten Bereich unterhalb X.X.X.20 manuell alle MacVLAN-Container mit IP-Adressen versorgt.

Das funktioniert nun stabil und hat mehrere Reboots ohne doppelte MAC-Adressen überstanden.

Folgende Prüfpunkte nach Umstellung der Container auf MacVLAN sollte man jedoch auf dem Radar haben:

• Einstellungen im Reverseproxy mit Zieladressen und Ports
• Netzreferenzen aus dem Container auf Services des Wolfes sind zu korrigieren, weil diese unter der "172.17.0.1" nicht mehr erreichbar sind.
• Portmappings können ggf. aufgelöst werden
• Wenn z.B. der hermsi-alpine-sshd im Einsatz ist, wird der nun nicht mehr unter der Adresse des Wolfes, sondern unter seiner eigenen Adresse und dann unter Port 22 erreichbar.
• 99% der im Forum zu findenden Einträge und ggf. aufgezeigten Lösungsansätze berücksichten in der Regel die "Standard"-Einstellungen, aber nicht unbedingt die "MacVLAN"-Spezifika

Fazit: Wenn man weiß was man macht ist das ein hilfreicher Ansatz.

Beste Grüße
Jens

[Cepheus73]

Das steht auch irgendwo in der Docker Doku, dass Docker standardmäßig kein DHCP nutzt, sondern die IP-Adressen für das konfigurierte Subnetz selber vergibt.

Es empfiehlt sich also, für Docker ein eigenes Subnetz zu verwenden. Das funktioniert natürlich nur, wenn man im Router mehrere Subnetze und das Routing dazwischen konfigurieren kann.
Ob das bei der Fritzbox geht, weiß ich nicht, da ich einen Mikrotik-Router benutze.

Ich stimme zu, dass das dann schon "Advanced" ist, und dass man dann grundlegende IP-Netzwerk-Kenntnisse haben sollte.

[ms20de]

Hallo Micha und andere,

ich bin bis jetzt immer gut damit gefahren beim der Nutzung von MACVLAN eine lokal administrierte MAC-Adresse zu erzeugen und diese zusätzlich zur IP-Adresse im Portainer einzutragen. Ich verlinke ein Tool, theoretisch sollte man prüfen ob die generierte MAC Adresse im lokalen Netzwerk schon verwendet wird, praktisch habe ich aber noch nicht gesehen, dass es eine Überschneidung gab.

https://www.hellion.org.uk/cgi-bin/randmac.pl

Hier ein Beispiel-Container bei mir.


Viele Grüße,
Matthias