Debian verliert default-route

Moin Paddel,

ich versuche gerade deine Fragen zu beantworten.

Leider bin ich in Linux nicht so der Held. Aber ich versuche mal trotzdem etwas zu beantworten.

mit journalctl /usr/lib/systemd/systemd habe ich das journal aufgerufen. Leider fehlen mir hier 4 Stunden. Da muss ich wohl nochmal 8 Stunden warten, bis der Fehler wieder auftritt.

Mit dem Energiesparmodi kann ich so nichts anfangen. Ich habe ihn zumindest nicht wissentlich aktiviert, da ich garnicht weiß, wie das funktioniert.
Mit der Frage zur Netzwerkkonfig bin ich auch gerade etwas überfragt. Ich habe diesen Debian nach der Installation eigentlich nicht weiter konfiguriert. Dieser Rechner holt sich seine IP-Konfig über einen DHCP-Server. Das ist ja standardmäßig bei debian so vorgesehen.

Das ist ein Debian 10, der ohne GUI installiert wurde. Auf dem DHCP-Server habe ich die mac-Adresse vom Debian eingetragen, damit dieser immer die IP bekommt. Das funktioniert auch so.

PS:
Ich sehe gerade, dass du deine Fragen aktualisiert hast.

Das Ganze ist virtuell auf ESXi 6.7 und die Version ist Debian 10.
Vielleicht noch einen Hinweis dazu:

Dieser Debian lief schon seit vielen Monaten auf einem ESXi 6.0 einwandfrei. Erst nach dem Umzug von einem ESXi-Server auf einen anderen ESXi-Server entstand das Problem.

Werde ich mal testen. Aber ich habe folgendes probiert:


Danach ist die Route wieder da. Ein "dhclient -r" alleine reicht nicht aus.

Was mich ja wundert, dass die beiden DNS-Einträge und auch die weitere Einträge alle vorhanden sind. Nur eben halt die Route fehlt. Hier mal ein Auszug aus der Datei "dhclient.ens192.leases":

lease {
interface "ens192";
fixed-address 192.168.1.10;
option subnet-mask 255.255.255.0;
option routers 192.168.1.1;
option dhcp-lease-time 28800;
option dhcp-message-type 5;
option domain-name-servers 192.168.1.4,192.168.1.5;
option dhcp-server-identifier 192.168.1.5;
option dhcp-renewal-time 14400;
option dhcp-rebinding-time 25200;
option domain-name "MEINE.FIRMA.DE";
renew 4 2022/10/06 06:10:10;
rebind 4 2022/10/06 09:25:55;
expire 4 2022/10/06 10:25:55;
}

Und diese Datei wird schön weiter fortgeschrieben. Hier ist auch zu erkennen, dass die Zeile mit dem Router auch dabei ist.

Nachtrag:

ip link set dev ens192 down
ip link set dev ens192 up

Das funktioniert nicht. Wundert mich eigentlich etwas. Dieser Befehl deaktiviert/aktivert doch die Netzwerkkarte?

Ah, das wusste ich nicht. Ich dachte das wäre so wie bei Windows. Nein, dabei gab es keine Fehlermeldung.

Jetzt bin ich gerade dabei den Datenverkehr aufzuzeichnen. Mal sehen, was dabei herauskommt.

Moin,

die Geschichte mit dem alternativen Netzwerkmanager habe ich mir mal notiert. Das werde ich aber erst später ausprobieren.

Ich möchte natürlich den Fehler finden, daher suche ich in dieser Richtung noch etwas weiter. Ich habe in der Zwischenzeit einen Mitschnitt gemacht. Weiterhin habe in der var/log/syslog mir die Logs angesehen. Desweiter habe ich auch intakte Server und mir das Ganze dort auch einmal angesehen. Dabei kam folgendes heraus:

Nach dem Neustart an dem defekten Rechner funktioniert ja erst einmal alles. Da sieht man auch im LOG, die DHCLIENT-Einträge. Wenn die Releasezeit abgelaufen ist, dann verliert dieser Rechner ja sein Gateway. Nach der Hälfte der Releasezeit möchte der Client seine Adresse erneuern. Das passiert schon mal nicht. Bei dem intakten Rechner sieht man das im LOG und im DUMP, immer wieder fortlaufend.
Ich hatte ja auf dem DHCP-Server die Zeit auf 2 Minuten verkürzt. Und nach Ablauf der Zeit macht der Rechner weiterhin nichts. Nichts im DUMP zu sehen und auch keine Einträge im LOG.

Vielleicht könntest du mir noch einen Tipp geben, warum der DHCLIENT nur nach dem Reboot scheinbar korrekt funktioniert, danach nicht mehr.

Auh! Das war das Stichwort! Ich habe beim Aufsetzen des ESXi verpennt, die Zeit per NTP zu einzustellen. Die Uhr ging zum Mond! Bei der Kontrolle der Logs ist mir auch die "Zukunftszeit" aufgefallen. Habe ich aber irgendwie ignoriert.

Ich habe das sofort geändert. Ich werde jetzt das Wochenende abwarten und das prüfen.

Zu dem Bugreport: Den hatte ich heute beim Surfen auch entdeckt. Werde ich mir auf jedenfall notieren.

Daher ergibt das Ganze jetzt auch einen Sinn. Denn vor dem Umzug lief alles tadellos. Das hätte ja auch nicht an den VMs liegen können.
Ich denke das wars.

Danke!

PS:
Gut, dass ich jetzt bemerkt habe. Ich wollte die Tage noch einen Domänencontroller dort draufschieben. Das hätte nach hinten losgehen können.