[SOLVED] IP "Änderung" erst nach Reboot wirksam


mgutt

Recommended Posts

Ich habe bei mir eine Situation, die ich immer wieder nachstellen kann:

 

1.) Ich lösche /boot/config/network.cfg und /boot/config/network-rules.cfg und starte den Server neu. Das führt zum Reset the Netzwerkeinstellungen. Der Server holt sich also per DHCP eine IP.

2.) Ich ändere die Reihenfolge meiner Netzwerkkarten so, dass meine 10G Karte eth0 erhält (Settings > Network > Interface Rules) und starte den Server neu.

3.) Ich ändere die IP von DHCP auf statisch und behalte die IP aber bei (Settings > Network > Interface eth0).

 

Und das war es dann. Der Server ist nicht mehr erreichbar. Ich kann ihn von meinem Client auch nicht mehr anpingen. Erst wenn ihn noch mal neu starte, gilt die eingestellte statische IP.

 

Da ich den Server produktiv einsetze, kann ich das nicht genauer untersuchen. Ich wollte mal fragen ob das andere auch schon erlebt haben bzw ob das eher an meiner 10G Karte liegen könnte? So rein vom Gefühl her ist das ein Bug in Unraid.

Link to comment
2 hours ago, mgutt said:

Und das war es dann. Der Server ist nicht mehr erreichbar. Ich kann ihn von meinem Client auch nicht mehr anpingen.

Für das gibt's genau den GUI mode, nur weil du in einem anderen Thread mal danach gefragt hast. :)

 

Spaß ohne... Ist auch für mich ein komisches Verhalten, tritt dieses Verhalten bei jedem reboot ein oder nur wenn du die oben aufgeführten Schritte durchführst? Hast du einen Monitor an deinem Server dran da würdest sehen was er für eine IP bezieht bzw. auch woran das Problem liegt...

 

2 hours ago, mgutt said:

Ich wollte mal fragen ob das andere auch schon erlebt haben bzw ob das eher an meiner 10G Karte liegen könnte?

Welche Karte hast du denn genau?

Link to comment
2 hours ago, mgutt said:

1.) Ich lösche /boot/config/network.cfg und /boot/config/network-rules.cfg und starte den Server neu. Das führt zum Reset the Netzwerkeinstellungen. Der Server holt sich also per DHCP eine IP.

2.) Ich ändere die Reihenfolge meiner Netzwerkkarten so, dass meine 10G Karte eth0 erhält (Settings > Network > Interface Rules) und starte den Server neu.

3.) Ich ändere die IP von DHCP auf statisch und behalte die IP aber bei (Settings > Network > Interface eth0).

Du kannst nicht einfach die IP allein im unRaid auf statischn ändern, sondern musst das auch im DHCP-Server machen.

Da Du die Netzwerkkarte geändert hast, gibt es eine neue MAC für die gleiche IP.

Dein DHCP-Server hat aber noch das alte Lease gespeichert und die erste MAC noch in der Lease- und ARP-Tabelle oder aber die gleiche IP bereits wieder an einen anderen Client via DHCP vergeben.

Ebenso andere Server/Clients, die Du kurz vorher noch mit der anderen MAC im gleichen Netz angesprochen hast.

 

Dann ist es durchaus normal, dass dieses Phänomen auftritt, würde ich sagen.

Ein reboot sendet einen refresh...zumindest bis die gleiche IP nicht an einen anderen client vergeben wird, bleibt es dann OK.

Also auf jeden Fall, die IP aus dem Pool des DHCP-Servers entfernen.

Edited by Ford Prefect
Link to comment
1 hour ago, Ford Prefect said:

Da Du die Netzwerkkarte geändert hast, gibt es eine neue MAC für die gleiche IP.

Mein DHCP Bereich startet bei .30 und der Server hat die .9

 

Nun lösche ich die Network Config und obwohl dadurch DHCP aktiv wird, behält der Server die .9

 

Dann ändere ich auf .9 statisch und der Server ist nicht mehr erreichbar. 

 

Beim letzten Mal als die erste 1G LAN Buchse noch nicht per vfio cfg ignorieren ließ, bekam der Server sogar mal die .66, aber als ich die 10G Karte auf eth0 stellte, erhielt der Server nach dem nächsten Neustart wieder die .9 (immer noch DHCP aktiv).

 

Ich vermute die Fritz!Box gönnt der statischen IP auch eine lease time, wenn die MAC Adresse nun plötzlich den DHCP Server anfragt.

 

Wenn ich das richtig sehe, muss ich das noch mal reproduzieren und beim nächsten Versuch ändere ich die IP auf .10 um die Fritz!Box als Ursache auszuschließen. Korrekt?

Link to comment
1 hour ago, ich777 said:

 nur wenn du die oben aufgeführten Schritte durchführst?

Ja, nur dann. Danach gibt es nie mehr Probleme.

 

1 hour ago, ich777 said:

Hast du einen Monitor an deinem Server dran da würdest sehen was er für eine IP bezieht

Ist dran und wenn ich die IP auf statisch .9 ändere, dann kann ich über das Terminal auch nicht mehr den Router anpingen.

 

1 hour ago, ich777 said:

Welche Karte hast du denn genau?

QNAP QXG-10G1T

 

 

Link to comment
6 minutes ago, mgutt said:

Mein DHCP Bereich startet bei .30 und der Server hat die .9

So wie Du es oben mit 1,2,3 beschrieben hattest, sollte also die erste IP aus dem Pool, also >=.30 sein und nicht 9.

6 minutes ago, mgutt said:

Nun lösche ich die Network Config und obwohl dadurch DHCP aktiv wird, behält der Server die .9

...config löschen, dann den Server rebooten...so hast Du es auch oben unter (1) beschrieben.

Das ist nicht normal...auch nicht bei einer Fritz als DHCP-Server, es sei denn Du hast irgendwann mal in der Fritz das Häcken bei "diesem Computer immer die gleiche IP zuweisen" (oder so) gesetzt.

 

Hast Du in unRaid eine Bridge oder Bond gesetzt? Bleibt diese MAC bei Wechsel der Config und Reihenfolge gleich?

Es sollte meiner Erfahrung nach immer die MAC der eth0 sein.

 

6 minutes ago, mgutt said:

Dann ändere ich auf .9 statisch und der Server ist nicht mehr erreichbar. 

 

Beim letzten Mal als die erste 1G LAN Buchse noch nicht per vfio cfg ignorieren ließ, bekam der Server sogar mal die .66, aber als ich die 10G Karte auf eth0 stellte, erhielt der Server nach dem nächsten Neustart wieder die .9 (immer noch DHCP aktiv).

Wenn der DHCP-Pool Bereich erst mit .30 beginnt, ist das nicht OK.

Schau in der Fritz nach, welche Computer bekannt sind und ob da für einen, mit Deiner ETH0-Mac das Häckchen für die "statische-IP" gesetzt ist.

Ansonsten bleibt nur die Frage ob Du noch nen Switch oder PiHole hast o.ä., wo evtl. auch noch ein DHCP-Server läuft.

 

6 minutes ago, mgutt said:

Ich vermute die Fritz!Box gönnt der statischen IP auch eine lease time, wenn die MAC Adresse nun plötzlich den DHCP Server anfragt.

Ja natürlich...aber wenn der Server die alte, ihm zuvor bekannte anfragt bekommt er diese nur, wenn die innerhalb des DHCP-Bereichs ist.

6 minutes ago, mgutt said:

Wenn ich das richtig sehe, muss ich das noch mal reproduzieren und beim nächsten Versuch ändere ich die IP auf .10 um die Fritz!Box als Ursache auszuschließen. Korrekt?

Ja, aber nur, wenn die .10 noch nicht vergeben ist ;-)

Link to comment
1 hour ago, Ford Prefect said:

So wie Du es oben mit 1,2,3 beschrieben hattest, sollte also die erste IP aus dem Pool, also >=.30 sein und nicht 9.

Ich starte ja mit einer funktionierenden Config, also mit der statischen .9

 

1 hour ago, Ford Prefect said:

Du hast irgendwann mal in der Fritz das Häcken bei "diesem Computer immer die gleiche IP zuweisen" (oder so) gesetzt.

Gerade geschaut. Stimmt. Ist jetzt raus. Hat das aber überhaupt einen Einfluss auf den Fehler?

 

1 hour ago, Ford Prefect said:

Hast Du in unRaid eine Bridge oder Bond gesetzt?

Wenn man die Config löscht, dann ist das ja die Grundeinstellung. Nach der Änderung der eth0 auf die 10G Karte und dem Neustart, entferne ich das Bonding mit eth1 (was aber eh keine Verbindung hat). Bridging bleibt für Docker/VM an.

Link to comment
32 minutes ago, mgutt said:

Ich starte ja mit einer funktionierenden Config, also mit der statischen .9

Verzeih wenn ich da pedantisch bin, aber Du hast in Deinem ersten Post geschrieben:

5 hours ago, mgutt said:

Ich habe bei mir eine Situation, die ich immer wieder nachstellen kann:

 

1.) Ich lösche /boot/config/network.cfg und /boot/config/network-rules.cfg und starte den Server neu. Das führt zum Reset the Netzwerkeinstellungen. Der Server holt sich also per DHCP eine IP.

...wenn diese IP nach einer leeren Config via DHCP kommt, sollte es eine aus dem DHCP-Bereich der Fritz, also >=.30 sein.

Quote

Gerade geschaut. Stimmt. Ist jetzt raus. Hat das aber überhaupt einen Einfluss auf den Fehler?

Tja, die Wege der Fritte sind unergründlich.

Ich habe zwar 3 davon im Einsatz, aber nutze die für den shice nicht.

Kann sein, da die MAC und IP nun in der Fritz bekannt sind, dass der DHCP-Server auch diese IP ausserhalb des Range zurückgibt.

Was passiert nun, da das Häcken raus ist? Kommt bei neuer Config eine IP aus dem "echten" Pool?

 

Quote

Wenn man die Config löscht, dann ist das ja die Grundeinstellung. Nach der Änderung der eth0 auf die 10G Karte und dem Neustart, entferne ich das Bonding mit eth1 (was aber eh keine Verbindung hat). Bridging bleibt für Docker/VM an.

Das Entscheidende ist die MAC, welche den DHCP-request auslöst und die IP bei der Fritz anfordert.

Die MAC sollte die von eth0 sein...wenn Du die Reihenfolge änderst, wird/sollte sich die MAC ändern und Du für DHCP eine andere/neue IP bekommen.

Andersrum wäre es doof, wenn die gleiche IP im "Netz" noch teilweise für mehr als eine MAC bekannt ist.

Innerhalb des gleichen IP-Netzes/-Maske läuft die Ethernet-Kommunikation über ARP, nicht über die IP, da eben nicht gerootet werden muss.

Beide Seiten der Session müssen die Gegenstelle kennen (die IP gegen die MAC auflösen, via ARP). Wenn da ein Schiefstand vorliegt, laufen die Pakete ins leere.

 

Edit: um das Problem zu "durchbrechen", sobald Du die Karte Deiner Wahl als eth0 ausgewählt hast, solltest Du eine IP-statisch vergeben welche Deine Fritz noch nicht kennt. Heisst, eine IP die noch nicht im Heimnetz der Fritz angezeigt wird.

Wenn Du also die .9 willst, solltest Du diese aus der Fritz löschen.

Dafür sollte ein reboot der Fritz reichen (am besten während in unRaid eine andere IP aktiv ist, zb die .10)

Edited by Ford Prefect
Link to comment
39 minutes ago, Ford Prefect said:

Was passiert nun, da das Häcken raus ist? Kommt bei neuer Config eine IP aus dem "echten" Pool?

Kann ich nicht mal eben testen. Wie gesagt mein produktiver Server. Wenn Mal keine Aktivität ist, werde ich das noch mal testen. Einmal die .9 und dann auch mal die .10.

 

Was könnte ich denn auf dem Server vor und nach der Änderung ausführen, damit ich debuggen kann, was hier eigentlich in die Hose geht? Also wenn es überhaupt an Unraid liegt.

Link to comment

...in den logs sollte zu finden sein, wie die IP "bezogen" wird. Wenn es DHCP ist, auch ob eine IP vorangefragt wird und was der DHCP-Server antwortet.

 

Ich denke es liegt am Wechsel der Karte, da diese ja die MAC trägt und etwas mit den ARP-Tabellen der Geräte im Netz durcheinanderkommt.

 

Das eigentliche Problem ist also ausserhalb des Servers (die - nicht funktionierenden - Verbindungen).

Daher kann man nur da reingucken, was aber knifflig ist und Aufwand bedeutet.

Also zB im Switch den Port vom Server auf einem anderen Port einen "mirror" aktivieren und mit einem Client am geclonten Port mittels wireshark mitschneiden, was passiert....wo die Anfragen hingehen, was zurückkommt.

Das gleiche an dem Port an dem das andere System hängt das mit dem Server kommuniziert und schauen was ankommt bzw wohin die Antworten gehen.

Am besten nur 1:1 LAN-Kabel Verbindungen der Geräte nehmen, keine Ports wo noch ein WLAN durchgeht.

Was besseres fällt mir nicht wirklich ein.

 

Wenn die Fritz ein Problem ist, evtl einen anderen "Server" als DHCP-Server nehmen und den in der Fritz ausschalten.

Ein Linux ist a viel geschwätziger und konfigurierbarer als die Fritz...kann auch ein rPi mit PiHole sein.

 

Edit: Man könnte auch zum Debug auf die statische IP verzichten und DHCP nehmen...evtl. sogar die Range in der Fritz ausweiten.

Wenn es mikttels DHCP immer funktioniert, auch beim Wechsel der Karte, dann ist es der Umstieg auf statische IP.

Wenn dabei ein MAC Wechsel stattfindet müsste es in der Fritz zu sehen sein (welche PCs werden mit welcher MAC im Heimnetz gelistet).

...wenn man so nix findet ist es doch im unRaid, aber da bin ich raus ;-)

Edited by Ford Prefect
Link to comment

Ok, was Neues herausgefunden. Die Erreichbarkeit ist schon nicht mehr gewährleistet, wenn ich nur das Bonding deaktiviere.

 

Hier die Schritte in Bildern:

 

Nach Löschen der Network Config sah es so aus:

1180985632_2020-12-1008_59_07.png.437c2f5bc2da2171251ba7e79d2dd784.png

 

2023411811_2020-12-1008_59_16.png.d2455e3fd270d8f568b2cee87441520e.png

 

Die MAC-Adresse wurde auch von der Fritz!Box übernommen (wohlgemerkt steckt kein Kabel in B4:2E:99.A8:C7:2A):

2066251305_2020-12-1008_59_50.png.f4970fd3f10ae92b9340511d308ae196.png

 

Dann habe ich die Geräte umsortiert:

917713223_2020-12-1009_00_20.png.24c28328951238a7f67f8aea1662f118.png

 

Nach dem Neustart erhielt ich nun erstmals eine DHCP Adresse, dh den Haken rausnehmmen bei "immer die gleiche IPv4" auf der Fritz!Box hat das Verhalten nun geändert:

559452634_2020-12-1009_04_02.thumb.png.f51311c93f11494e3b7dff1dc776a166.png

 

Und als nächstes habe ich bonding auf "no" gestellt und "Apply" gedrückt. Danach war der Server nicht mehr erreichbar.

 

Das klingt nun eher nach einer Inkompatibilität zum 10G Treiber. Was meint ihr?

 

Ich teste nachher noch ob ich das Bonding drin lassen kann und nur die IP auf statisch setzen kann.

 

EDIT: Also der Server wird auch dann unerreichbar, wenn ich das Bonding aktiv lasse und nur die IP auf statisch ändere. Scheinbar ist jede Einstellungsänderung ein Problem. Kann ich irgendwo nachschauen wie Unraid die Einstellungen aktualisiert? Also dass ich die Kommandos mal selbst testen kann?

 

EDIT2: Und wieder was Interessantes. Nachdem ich nun die IP auf statisch geändert hatte, musste ich ja neu starten. Dann habe ich das Bonding deaktiviert und das hat nun anstandslos geklappt?!

 

Also noch mal zusammengefasst:

- Bonding deaktivieren und IP auf statisch ändern = offline

- Bonding deaktivieren = offline

- IP auf statisch ändern = offline

- Bonding deaktivieren, wenn bereits eine statische IP existiert = bleibt online

 

 

 

Link to comment

Ok, ich habe den Quelltext gefunden. Es werden mehrere Dateien bei einer Änderung des Netzwerks ausgeführt, wobei die update.php nur dafür sorgt, dass die /include/update.ethernet.php included und die /scripts/netconfig ausgeführt wird:

<form markdown="1" name="eth0_settings" method="POST" action="/update.php" target="progressFrame" onchange="exitCode(this,false)" onsubmit="return prepareSettings(this)">
<input type="hidden" name="#file" value="<?=$ini?>">
<input type="hidden" name="#include" value="/webGui/include/update.ethernet.php">
<input type="hidden" name="#section" value="eth0">
<input type="hidden" name="#command" value="/webGui/scripts/netconfig">

 

Und in der /scripts/netconfig gibt es nur wenige Terminal-Kommandos. Am Anfang stoppt er zB das Interface:

$set = $ifname = $argv[1];
$run = $set != 'none';
...
exec("/etc/rc.d/rc.inet1 ".escapeshellarg("{$ifname}_stop")." >/dev/null");

Und am Ende des Quelltextes startet er das Interface dann wie folgt wieder und lädt das Shell Script create_network_ini:

// start interface with updated (new) configuration
// don't execute when only interface description has changed
if ($run) {
  exec("/etc/rc.d/rc.inet1 ".escapeshellarg("{$ifname}_start")." >/dev/null");
  exec("/usr/local/sbin/create_network_ini >/dev/null");
}

 

Diese Kommandos könnte ich dann selbst mal testen und evtl Fehlermeldungen prüfen.

 

In der create_network_ini passiert dann auch nicht mehr viel. Die generiert einfach eine neue /var/local/emhttp/network.ini und zum Schluss gibt es noch eine Zeile betreffend NGINX, die aber nur ausgeführt wird, wenn man DHCP aktiviert (weil $data sonst leer ist):

  IFACE=${IFNAME[$i]:-eth$i}
  ETH=${IFACE/#bond/eth}
  ETH=${ETH/#br/eth}
...
if [[ ${USE_DHCP[$i]} == yes ]]; then
    NET=($(ip -4 addr show $IFACE|awk '/inet /{sub("/"," ",$2);print $2;exit}'))
    GW=$(ip -4 route show default dev $IFACE|awk '{print $3;exit}')
...
    data="${data}${ETH}_I_IPADDR:0=${NET[0]} ${ETH}_S_NETMASK:0=$(mask ${NET[1]}) ${ETH}_I_GATEWAY:0=$GW "
...
# send update information
[[ -n $interface && -n $data && -e /var/run/nginx.socket ]] && curl -sfd "$data" --unix-socket /var/run/nginx.socket http://localhost/pub/dhcp?buffer_length=0 >/dev/null 2>&1

 

 

 

Das würde heißen, dass schon das simple Stoppen des Interface das Problem verursacht. Mehr dazu, wenn ich weiter testen kann....

Link to comment

Interessant.

Ja, durch den Wechsel der ETH-Reihenfolge ändert sich die MAC und es gibt brav eine neue, eigene IP via DHCP...so sollte es sein.

Die MAC aussen ist mit bonding dann immer die von eth0, egal wo das Kabel drin ist.

Die IP ist aber am Interface bond0, br0, nicht eth0...wenn Du das bond0/br0 entfernst hat eth0 im ersten Fall kein Kabel mehr, aber die IP bleibt an die alte MAC gebunden.

Warum es im zweiten Fall nicht läuft, ist mir ein Rätsel. kann wirklich etwas mit dem Treiber zu tun haben, wenn bonding/bridging aufgelöst wird.

Nach einem Reboot wird er neu initialisiert und läuft dann.

 

Was macht ein manuelles if-ip/if-down für den NIC, der das Kabel hat?

 

 

Link to comment

Vielleicht kann ich auch noch kurz meinen Senf dazu geben.

Ich selbst habe eine Asus XG-C100C. Diese müsste den gleichen Chipsatz wie deine Qnap haben.

In meinem Unraid Server hatte ich auch immer Probleme damit. Server plötzlich nicht mehr erreichbar und dergleichen.

Habe dann im Server eine Intel 550 T1 10gbit Nic eingebaut. Mit dieser hatte ich noch nie Probleme.

Die Asus verrrichtet nun in meinem Hackintosh ihren Dienst.

Ich gehe von Problemen mit dem Atlantic Chipsatz und Unraid aus.

Grüße

Link to comment
  • ich777 changed the title to [SOLVED] IP "Änderung" erst nach Reboot wirksam

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.