Komisches IP-Address Problem

[rocketworm]

Moin moin Zusammen,

ich habe ein abgefahrenes IP/DHCP Problem.

Ich habe gerade frisch eine Debian 11 VM auf einem VMware ESXi 8.0 installiert.

Nach dem ersten Boot hat die VM in einem /24 Netz die .203 bekommen. Soweit alles normal.
Ich habe anschließend auf meinem Windows Server 2019 einen statischen Eintrag für die MAC der VM mit der .130 angelegt.
Wenn ich die Debian VM neustarte, kommt diese aber wieder mit der .203 hoch.

Ich habe dann auf der Debian VM mittels "dhclient -r" die IP zurückgegeben und mitttels "dhclient" eine neue vom DHCP geholt.
Die VM hat jetzt so wie sie soll, die .130 und der DHCP Server sagt auch, dass die .203 nicht mehr reserviert ist.

Wenn ich nun die VM wieder Reboote, hat diese wieder die .203 und laut DHCP Server ist diese auch nicht vergeben. Die Debian VM scheint die IP echt gern zu haben.
Das WWW hat mir dazu leider weiter geholfen. Ich hoffe ihr habt einen Tipp für mich. Bin langsam am verzweifeln.

Viele Grüße

[bluestar]

Kann es sein, dass deine VM bei jedem Neustart eine neue zufällig MAC Adresse vom ESXi 8.0 zugewiesen bekommt?

[rocketworm]

Nein, die MAC bleibt gleich.
Es taucht auf dem DHCP-Server auch keine neue Reservierung für die .203 auf. Die Zaubert die Debian VM scheinbar selbst aus den Hut.

[reox]

Klingt nach unterschiedlichen Client Identifiern. Ist der vllt bei dem statischen Eintrag mitgespeichert?

[rocketworm]

Klingt nach unterschiedlichen Client Identifiern. Ist der vllt bei dem statischen Eintrag mitgespeichert?

Nee, der DHCP Münzt nur auf die MAC.

Ich habe gerade nen Raspberry mit Raspbian 11 lite aufgesetzt. Der ändert brav seine IP nach einem Reboot wenn ich nen statischen Eintrag auf dem DHCP anlege.

Ich werde jetzt parallel zwei Dinge testen:
- Ich lösche die Debian 11 VM und lege Sie nochmal neu an und installiere neu. Mal schauen wie es sich dann verhält.
- Ich setze eine Ubuntu VMmit identischen Eigenschaften auf und wiederhole das Prozedere und schaue was da passiert

[rocketworm]

Unbuntu Server 22.04 die selbe Grütze
Warum funktioniert es aber dann mit dem Raspberry und allen anderen Maschinen und auch älteren Debian und Ubuntu VM's auf dem selben ESXi?

[mat6937]

Wenn ich nun die VM wieder Reboote, hat diese wieder die .203 und laut DHCP Server ist diese auch nicht vergeben. Die Debian VM scheint die IP echt gern zu haben.

Wie ist die Ausgabe von:

Code: Alles auswählen

networkctl status <Interface>

?
Schau mal nach, ob es auf der Debian VM, lease-Dateien mit der IP .203 gibt und wenn ja, dann lösche diese lease-Datei(en).

[rocketworm]

Das hat den Fix gebracht. Warum auch immer kommt die VM mit einer 36 Stelligen MAC beim DHCP an.
https://community.spiceworks.com/topic/ ... ive-leases

Bei einem ip a hat er nur die 12 stellige Mac ausgespuckt. Warum auch immer Debian jetzt meint eine 36 stellige MAC an den DHCP senden zu müssen.

[reox]

Das hat den Fix gebracht. Warum auch immer kommt die VM mit einer 36 Stelligen MAC beim DHCP an.
https://community.spiceworks.com/topic/ ... ive-leases

Bei einem ip a hat er nur die 12 stellige Mac ausgespuckt. Warum auch immer Debian jetzt meint eine 36 stellige MAC an den DHCP senden zu müssen.

Ja dann wohl doch client identifier

[rocketworm]

Ja dann wohl doch client identifier

Es funktioniert ja generell auch mit der langen Variante im DHCP.
ip a und ifconfig spucken nur die "reale MAC" aus. Gibts eine Chance direkt von der Maschine die lange Variante ausgeben zu lassen?

[mat6937]

[Gibts eine Chance direkt von der Maschine die lange Variante ausgeben zu lassen?

Vielleicht mit:

Code: Alles auswählen

hostnamectl status
networkctl status <Interface>
cat /etc/machine-id
cat /proc/sys/kernel/random/boot_id

?

[reox]

Ich vermute du hast einen systemd-networkd oder so am laufen der sich die .203 schnappt und der dhclient nimmt eine andere client id und holt sich die .130
Du kannst zB konfigurieren, dass der networkd nur die mac nimmt und nicht die duid: https://manpages.debian.org/bullseye-ba ... ON_OPTIONS

ClientIdentifier=
The DHCPv4 client identifier to use. Takes one of mac, duid or duid-only. If set to mac, the MAC address of the link is used. If set to duid, an RFC4361-compliant Client ID, which is the combination of IAID and DUID (see below), is used. If set to duid-only, only DUID is used, this may not be RFC compliant, but some setups may require to use this. Defaults to duid.

[mat6937]

Ich vermute du hast einen systemd-networkd ...

Dann müsste der TE eine *.network-Datei angelegt haben ... und das ist ja schnell geprüft, mit z. B.:

Code: Alles auswählen

systemctl status systemd-networkd --full --no-pager
ls -la /etc/systemd/network

[JTH]

Dann müsste der TE eine *.network-Datei angelegt haben ... und das ist ja schnell geprüft, mit z. B.:

Es gibt ein paar mitgelieferte .network in /lib/systemd/network.

Vom Namen her klingt /lib/systemd/network/80-vm-vt.network so, als ob es, zusammen mit dem von reox zitierten Standardwert duid für systemd-networkds ClientIdentifier, unerwartetes Verhalten bewirken könnte (hab gerade keinen Blick in die 80-vm-vt.network reinwerfen können).

[reox]

Vom Namen her klingt /lib/systemd/network/80-vm-vt.network so,

Kann man sich auch ansehen welche verwendet wird.
Zuerst mit

Code: Alles auswählen

networkctl

schauen welche interfaces konfiguriert sind und dann

Code: Alles auswählen

networkctl status $interface

dort steht dann unter "Network file" wo die konfiguration her kommt.
Außerdem steht ganz unten die "DHCP4 Client ID"

Bin mir nicht 100% sicher ob networkd unter debian 11 schon standard ist und ob es eine automatische konfiguration mitbringt, aber das könnte schon sein.

[cosinus]

Ich habe anschließend auf meinem Windows Server 2019 einen statischen Eintrag für die MAC der VM mit der .130 angelegt.

In der DHCP-Server-Konsole vom Windows Server müsstest du doch sehen, mit welcher ID jeder Client da ankommt. Zieh mal mit der Debian-VM die IP-Adresse neu, schau nach welche das ist und dann auf dem Server den entsprechenden Eintrag raussuchen. Welche Client-ID steht dort?