🚀 go-pugleaf

Am 26.04.2024 16:49 Uhr schrieb Jürgen Jänicke:

> Hallo, habe neuerdings einen LAN-Switch dem PC vorgeschalten aber der 
> ist i.d.R. aus, also ohne Stromversorgung. Wird nur bei Bedarf 
> aktiviert. 90% Netzwerkzeit läuft per WLAN.
> Aber in dem Zustand, Switch ohne Strom, dauert das Booten wesentlich 
> länger. PC bleibt lange im BIOS, bzw. EFI, bevor es dann das
> eigentliche OS bootet. LAN steht an 3. Stelle nach HDD und USB.
> Ist der Switch bestromt oder das LAN-Kabel abgesteckt dann geht alles 
> wie gewohnt schnell voran.

Schalte mal PXE (Netzwerkboot) ganz aus und teste dann.

> Nun zwei Fragen:
> 1. Kann es durch einen anderen, aktuelleren Switch besser werden? Der 
> jetzige ist wahrscheinlich fast 20 Jahre alt, aber funktioniert eben 
> prinzipiell noch.
> 2. Oder ist das so normal und funktionsbedingt und ich muss damit
> leben?

Nein, aber die Ursache ist bisher unklar.

-- 
Gruß
Marco

Spam und Werbung bitte an
1714142999ichwillgesperrtwerden@nirvana.admins.ws

Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
> Das würde ich exakt andersrum vermuten.
>
> Switch aus => Link down => PXE boot klar unmöglich => kann schnell von
> der Platte booten.

Ich kenne auch BIOS oder UEFI, bei denen ein LAN-Kabel ohne Signal
trotzdem Abwarten eines längeren Timeouts bewirkt.

Wenn bei eingeschaltetem Switch ein sinnvolles Nnetzwerk anliegt, dann
würde es das beschriebene Verhalten erklären.

/ralph

Marco Moock <mm+solani@dorfdsl.de> wrote:
>Am 26.04.2024 16:49 Uhr schrieb Jürgen Jänicke:
>> Hallo, habe neuerdings einen LAN-Switch dem PC vorgeschalten aber der
>> ist i.d.R. aus, also ohne Stromversorgung. Wird nur bei Bedarf
>> aktiviert. 90% Netzwerkzeit läuft per WLAN.
>> Aber in dem Zustand, Switch ohne Strom, dauert das Booten wesentlich
>> länger. PC bleibt lange im BIOS, bzw. EFI, bevor es dann das
>> eigentliche OS bootet. LAN steht an 3. Stelle nach HDD und USB.
>> Ist der Switch bestromt oder das LAN-Kabel abgesteckt dann geht alles
>> wie gewohnt schnell voran.
>
>Schalte mal PXE (Netzwerkboot) ganz aus und teste dann.

Das würde ich exakt andersrum vermuten.

Switch aus => Link down => PXE boot klar unmöglich => kann schnell von
der Platte booten.

Switch an => Link Up => Mindestens DHCP-Timeout muss abgewartet werden
=> dauert

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Am 26.04.24 um 18:55 schrieb Marc Haber:
> Marco Moock <mm+solani@dorfdsl.de> wrote:
>> Am 26.04.2024 16:49 Uhr schrieb Jürgen Jänicke:

>>> aktiviert. 90% Netzwerkzeit läuft per WLAN.
>>> Aber in dem Zustand, Switch ohne Strom, dauert das Booten wesentlich
>>> länger. PC bleibt lange im BIOS, bzw. EFI, bevor es dann das
>>> eigentliche OS bootet. LAN steht an 3. Stelle nach HDD und USB.
>>> Ist der Switch bestromt oder das LAN-Kabel abgesteckt dann geht alles
>>> wie gewohnt schnell voran.

Warum steht LAN dann überhaupt in der Bootorder? Statt an 3. Stelle
sollte es überhaupt nicht auftreten - wenn man es nie braucht.

>> Schalte mal PXE (Netzwerkboot) ganz aus und teste dann.
>
> Das würde ich exakt andersrum vermuten.

O-Yoda-J: "Unterschätze nie die Dummheiten eines BIOS/UEFI junger
Padawan" :-) SCNR.

> Switch aus => Link down => PXE boot klar unmöglich => kann schnell von
> der Platte booten.

Denkbar wäre doch das es trotz link Down auf einen Timeout wartet weil
es ja möglich ist das jemand noch in dem Zeitfenster ein Kabel
einsteckt. Dann ist der Link da und... (s.u.)

> Switch an => Link Up => Mindestens DHCP-Timeout muss abgewartet werden
> => dauert

Wie PXE mit DHCP interagiert weiß ich nicht. Die Klassische Methode
(TFTP) fragt den dhcpd nach einem bootfile. Dazu braucht dieser eine
entsprechende Einstellung sonst wird er das vermutlich sofort NAK'en und
dann kann der nächste Eintrag der Bootorder greifen.

BTW. Manche Boards haben ja ein eigenes NIC Rom/Setup (Alt-A o.ä.?) oft
ein Intel Bootagent. Mein Eindruck bei denen die mir begegneten war das
die recht unabhängig sind von BIOS/UEFI Einstellungen. Wenn man es dort
deaktiviert heißt das noch nicht das der Bootagent lahm gelegt ist und
es nicht weiterhin versucht. Und mindestens einen hatte ich der sich
garnicht komplett deaktivieren ließ.

Bye/
   /Kay

--
nix

Kay Martinen <usenet@martinen.de> wrote:
>Am 26.04.24 um 18:55 schrieb Marc Haber:
>> Das würde ich exakt andersrum vermuten.
>
>O-Yoda-J: "Unterschätze nie die Dummheiten eines BIOS/UEFI junger
>Padawan" :-) SCNR.

Genau.

>> Switch aus => Link down => PXE boot klar unmöglich => kann schnell von
>> der Platte booten.
>
>Denkbar wäre doch das es trotz link Down auf einen Timeout wartet weil
>es ja möglich ist das jemand noch in dem Zeitfenster ein Kabel
>einsteckt. Dann ist der Link da und... (s.u.)

Das würde mich überraschen. Aber gut, so viel Erfahrung mit
verschiedener Hardware habe ich da nicht.

>> Switch an => Link Up => Mindestens DHCP-Timeout muss abgewartet werden
>> => dauert
>
>Wie PXE mit DHCP interagiert weiß ich nicht. Die Klassische Methode
>(TFTP) fragt den dhcpd nach einem bootfile. Dazu braucht dieser eine
>entsprechende Einstellung sonst wird er das vermutlich sofort NAK'en und
>dann kann der nächste Eintrag der Bootorder greifen.

Das ist ein so interressantes Thema dass ich das gerne etwas näher
beleuchten würde. Vermutlich kennst Du das schon alles, aber es gibt
ja auch noch andere Leser.

Ich habe das selbst noch nie mit IPv6 gemacht, daher beschränke ich
mich im Weiteren auf IPv4.

Ein Startup eines Rechners per PXE beginnt mit einem DHCPDISCOVER. Das
ist ein Broadcast, kommt also bei allen DHCP-Servern und DHCP-Relays
im lokalen Netz an. Ja, das können mehrere sein.

Jeder DHCP-Server (auch diejenigen, an die die DHCP-Relays das
DHCPDISCOVER weitergeleiter haben), der sich zu einer Antwort berufen
führt, antwortet auf das DHCPDISCOVER. Der Client bekommt also im
zweifel mehrere DHCPOFFER-Pakete, die sich auch durchaus widersprechen
können oder unterschiedliche Informationen beinhalten.

Manche Softwaredistributionssysteme greifen an dieser Stelle ein und
senden, wenn für konkret diesen Client eine Installation hinterlegt
ist, ein eigenes DHCPOFFER, in dem Boot-Informationen (z.B. Boot File,
Next Server etc) enthalten sind. Ist keine Installation hinterlegt,
ignorieren diese Systeme das DHCPDISCOVER und überlassen die Arbeit
dem "eigentlichen" DHCP-Server.¹

Derselbe Mechanismus wird gerne von IP-Telefonanlagen genutzt, hierbei
sendet dann die Telefonanlage ein eigenes DHCPOFFER mit den speziellen
Optionen die das Telefon erwartet.

Der Client darf sich dann aus den empfangenen DHCPOFFERs dasjenige
aussuchen, das ihm am besten in den Kram passt. Ein gerade auf PXE
Boot wartender Client wird das OFFER nehmen, in dem Boot-Informationen
entalten sind und alle anderen ignorieren; ein IP-Telefon wird das
DHCPOFFER wählen, das die Optionen enthält, auf die es wartet.

Ein bereits gebootetes Betriebssystem wird im Zweifel alles nehmen was
daherkommt, daher ist es so wichtig dass in den beiden oberen
Sonderbeispielen weder das Softwaredistributionssystem noch die
Telefonanlage überhaupt ein DHCPOFFER versenden. Das
Distributionssystem wird schweigen wenn für einen Client keine
Installation hinterlegt ist; die Telefonanlage kennt typischerweise
den MAC-Adress-Range aus dem "ihre" Telefone ihre MAC-Adressen
zugewiesen bekommen haben und wird nur diesen antworten. Auf diese
Weise ist auch gleich der Einsatz "fremder" Telefone schwieriger, was
im Interesse des Anlagenherstellers liegt.

Nachdem der Client sich für ein DHCPOFFER entschieden hat, sendet er
an den Server, von dem das OFFER gekommen ist, ein DHCPREQUEST² um ihm
zu bestätigen, dass er der "auserwählte" ist, und mit einer weiteren
Bestätigung seitens des Servers ist die Lease nun komplett.

Im PXE-Fall ist es übrigens nicht unüblich, dass die nachgeladene
Komponente wieder "von vorne" mit DHCP anfängt, damit die Beteiligen
dieses Bootstrap-Prozesses nicht miteinander reden müssen. Dumme
Server vergeben an dieser Stelle eine ganz neue IP-Adresse, was
zusammen mit langen Leasezeiten durchaus lästig sein kann (weil ein
PXE-Boot potenziell mehrere Leases belegen kann, und so ein /24 ist
schon ziemlich schnell voll).

Wegen dieses stufenweisen Boots ist es nicht selten notwendig, dass
der Server "intelligente" Entscheidungen trifft. Zum Beispiel ist
dann, wenn die weit verbreitete Software iPXE³ zum Einsatz kommt
üblich, dass im Server Logik wie diese hier hinterlegt ist:

|if exists user-class and option user-class = "iPXE" {
|filename "http://bootserver.example/pxe/default.ipxe";
|} else {
|filename "undionly.kpxe";
|}

Im Klartext bedeutet das "schaue in die vom Client übermittelte
DHCP-Option User-Class und wenn Du daran erkennst, dass auf dem Client
bereits ein iPXE läuft¼ schicke ihm den URL zum Weiterbooten. Sonst
schicke sage ihm er möge iPXE aus dem Netz laden und ausführen."

Grüße
Marc

¹ Diese Systeme haben entweder einen eigenen IP-Adress-Range
hinterlegt und reserviert oder holen sich "hintenrum" eine Adressse
vom "eigentlichen" DHCP-Server per DHCP.
² Das ist dann übrigens kein Broadcast-Paket mehr, sondern ein
Unicast, das im Zweifel, wenn der Server nicht im gleichen Netz steht
wie der Client, ganz normal geroutet wird ohne dass das DHCP-Relay
nochmal eingreifen muss.
³ iPXE hat den großen Vorteil, dass es http spricht und den Großteil
des zu bootenden Betriebssystem so nachladen kann. Das ist erheblich
schneller als das hier traditionell eingesetzte tftp. Außerdem kann
iPXE ein Menü anbieten und auch anderweitig mit dem Benutzer
interagieren. In meinem Labornetz bekommt jeder PXE-Client so ein Menü
zugeworfen, wo der Benutzer auswählen kann, von seiner lokalen Platte
weiterzubooten (was nach 5 Sekunden Wartezeit automatisch geschieht)
oder ob er ein grml oder einen Debian-Installer zugeworfen bekommen
möchte
¼ manche VMs benutzen direkt iPXE als ersten Schritt des PXE-Boots,
andere Systeme (wie z.b. die meisten "Bleche") wollen den ersten
Schritt klassisch per tftp.
--
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Am 26.04.24 um 16:49 schrieb Jürgen Jänicke:
> Hallo, habe neuerdings einen LAN-Switch dem PC vorgeschalten aber der
> ist i.d.R. aus, also ohne Stromversorgung. Wird nur bei Bedarf
> aktiviert. 90% Netzwerkzeit läuft per WLAN.
> Aber in dem Zustand, Switch ohne Strom, dauert das Booten wesentlich
> länger. PC bleibt lange im BIOS, bzw. EFI, bevor es dann das eigentliche
> OS bootet. LAN steht an 3. Stelle nach HDD und USB.
> Ist der Switch bestromt oder das LAN-Kabel abgesteckt dann geht alles
> wie gewohnt schnell voran.

Vmtl. erkennt das System, dass das LAN angeschlossen ist, bekommt aber
dann keine Verbindung.

Wenn er die Verbindung eigentlich gar nicht braucht aber trotzdem
wartet, ist es ein BIOS Bug.

> Nun zwei Fragen:
> 1. Kann es durch einen anderen, aktuelleren Switch besser werden?

Abwegig. Wie soll ein anderer /ausgeschalteter/ Switch etwas besser
machen. Du müsstest schon das Mainboard tauschen.


Marcel

Am 26.04.2024 Fr. um 19:48 schrieb Kay Martinen:
>
>
> Am 26.04.24 um 18:55 schrieb Marc Haber:
>> Marco Moock <mm+solani@dorfdsl.de> wrote:
>>> Am 26.04.2024 16:49 Uhr schrieb Jürgen Jänicke:
>
>>>> aktiviert. 90% Netzwerkzeit läuft per WLAN.
>>>> Aber in dem Zustand, Switch ohne Strom, dauert das Booten wesentlich
>>>> länger. PC bleibt lange im BIOS, bzw. EFI, bevor es dann das
>>>> eigentliche OS bootet. LAN steht an 3. Stelle nach HDD und USB.
>>>> Ist der Switch bestromt oder das LAN-Kabel abgesteckt dann geht alles
>>>> wie gewohnt schnell voran.
>
> Warum steht LAN dann überhaupt in der Bootorder? Statt an 3. Stelle
> sollte es überhaupt nicht auftreten - wenn man es nie braucht.
>
Ja, stimmt eigentlich. Habe jetzt LAN deaktiviert. Also steht jetzt da:
1. Bootgerät: ubuntu (wegen GRUB Bootmanger)
2. Bootgerät: Removable Device
3. Bootgerät: disabled
4. Bootgerät: disabled

Mehr braucht es ja nicht und damit funktioniert es wieder korrekt auch
mit deaktiven aber angestecktem Switch.

Danke des Denkanstoßes, ist ja eigentlich auch besser so. Dachte bislang
eben nur das LAN an 3. Stelle sich nicht auswirken sollte wenn vorher
was nutzbares vorhanden und gefunden wird.

Jürgen

Bernd Mayer <beam.bam.boom@knuut.de> wrote:
> Was zeigt das BIOS 15 Sekunden lang an?

Ich bin zwar nicht der angesprochene, aber gerade im Serverbereich ist
15 Sekunden Warten ohne Feedback quasi gar nix.

/ralph

Am 27.04.2024 09:19 Uhr schrieb Marc Haber:

> Ich habe das selbst noch nie mit IPv6 gemacht, daher beschränke ich
> mich im Weiteren auf IPv4.

Das geht ja mal gar nicht.
Interessant wird, wie der die eigentlichen Daten nachlädt. Bei Ubuntu
war das glaub NFS und da soll es wohl mit IPv6 noch Probleme geben.
Müsste ich ehrlich gesagt mal testen. Und heute ist Samstag, morgen
Sonntag, da wäre eigentlich Zeit dazu.

> Ein Startup eines Rechners per PXE beginnt mit einem DHCPDISCOVER. Das
> ist ein Broadcast, kommt also bei allen DHCP-Servern und DHCP-Relays
> im lokalen Netz an. Ja, das können mehrere sein.
> 
> Jeder DHCP-Server (auch diejenigen, an die die DHCP-Relays das
> DHCPDISCOVER weitergeleiter haben), der sich zu einer Antwort berufen
> führt, antwortet auf das DHCPDISCOVER. Der Client bekommt also im
> zweifel mehrere DHCPOFFER-Pakete, die sich auch durchaus widersprechen
> können oder unterschiedliche Informationen beinhalten.
> 
> Manche Softwaredistributionssysteme greifen an dieser Stelle ein und
> senden, wenn für konkret diesen Client eine Installation hinterlegt
> ist, ein eigenes DHCPOFFER, in dem Boot-Informationen (z.B. Boot File,
> Next Server etc) enthalten sind. Ist keine Installation hinterlegt,
> ignorieren diese Systeme das DHCPDISCOVER und überlassen die Arbeit
> dem "eigentlichen" DHCP-Server.¹

Ist das nicht Garant dafür, dass Allerlei passieren kann?
Eines der Systeme bevorzugt einfach den ersten DHCP oder so?

> Derselbe Mechanismus wird gerne von IP-Telefonanlagen genutzt, hierbei
> sendet dann die Telefonanlage ein eigenes DHCPOFFER mit den speziellen
> Optionen die das Telefon erwartet.
> 
> Der Client darf sich dann aus den empfangenen DHCPOFFERs dasjenige
> aussuchen, das ihm am besten in den Kram passt. Ein gerade auf PXE
> Boot wartender Client wird das OFFER nehmen, in dem Boot-Informationen
> entalten sind und alle anderen ignorieren; ein IP-Telefon wird das
> DHCPOFFER wählen, das die Optionen enthält, auf die es wartet.

Wird es das immer tun oder gibt es da schwarze Schafe?

> Im PXE-Fall ist es übrigens nicht unüblich, dass die nachgeladene
> Komponente wieder "von vorne" mit DHCP anfängt, damit die Beteiligen
> dieses Bootstrap-Prozesses nicht miteinander reden müssen. Dumme
> Server vergeben an dieser Stelle eine ganz neue IP-Adresse, was
> zusammen mit langen Leasezeiten durchaus lästig sein kann (weil ein
> PXE-Boot potenziell mehrere Leases belegen kann, und so ein /24 ist
> schon ziemlich schnell voll).

IPv4 halt. :-)

> ³ iPXE hat den großen Vorteil, dass es http spricht und den Großteil
> des zu bootenden Betriebssystem so nachladen kann. Das ist erheblich
> schneller als das hier traditionell eingesetzte tftp.

Warum ist tftp signifikant langsamer?

-- 
Gruß
Marco

Spam und Werbung bitte an
1714202346ichwillgesperrtwerden@nirvana.admins.ws

Am 27.04.2024 Sa. um 10:55 schrieb Jürgen Jänicke:
> Am 26.04.2024 Fr. um 19:48 schrieb Kay Martinen:
>>
>>
>> Am 26.04.24 um 18:55 schrieb Marc Haber:
>>> Marco Moock <mm+solani@dorfdsl.de> wrote:
>>>> Am 26.04.2024 16:49 Uhr schrieb Jürgen Jänicke:
>>
>> Warum steht LAN dann überhaupt in der Bootorder? Statt an 3. Stelle
>> sollte es überhaupt nicht auftreten - wenn man es nie braucht.
>>
> Ja, stimmt eigentlich. Habe jetzt LAN deaktiviert. Also steht jetzt da:
> 1. Bootgerät: ubuntu (wegen GRUB Bootmanger)
> 2. Bootgerät: Removable Device
> 3. Bootgerät: disabled
> 4. Bootgerät: disabled
>
> Mehr braucht es ja nicht und damit funktioniert es wieder korrekt auch
> mit deaktiven aber angestecktem Switch.
>
Ups, zu früh gefreut. Leider ist es nur bei einem Neustart (Warmstart)
ok. Bei einem richtigen Kaltstart wartet er wieder ca. 15 Sekunden im
BIOS trotz obiger Einstellung.

Jürgen

Jürgen Jänicke <post@j-jaenicke.de> wrote:
> Am 27.04.2024 Sa. um 13:39 schrieb Ralph Aichinger:
>> Bernd Mayer <beam.bam.boom@knuut.de> wrote:
>>> Was zeigt das BIOS 15 Sekunden lang an?
>>
>> Ich bin zwar nicht der angesprochene, aber gerade im Serverbereich ist
>> 15 Sekunden Warten ohne Feedback quasi gar nix.
>>
> Bei mir sind es aber im Normalfall genau 2,4 Sekunden.

Glaub ich dir sofort, ich hab aber auch schon Server gehabt, bei denen
ich mich ernsthaft gefragt habe "ist der jetzt kaputt", dann hab ich
noch mal 30 Sekunden gewartet, und dann hat sich irgendeine
RAID-Firmware gemeldet.

/ralph

Am 27.04.2024 12:10 Uhr schrieb Jürgen Jänicke:

> Ups, zu früh gefreut. Leider ist es nur bei einem Neustart
> (Warmstart) ok. Bei einem richtigen Kaltstart wartet er wieder ca. 15
> Sekunden im BIOS trotz obiger Einstellung.

Ist die LED am Netzwerkport dann aus?

-- 
Gruß
Marco

Spam und Werbung bitte an
1714212610ichwillgesperrtwerden@nirvana.admins.ws

Am 27.04.24 um 12:10 schrieb Jürgen Jänicke:
>>
> Ups, zu früh gefreut. Leider ist es nur bei einem Neustart (Warmstart)
> ok. Bei einem richtigen Kaltstart wartet er wieder ca. 15 Sekunden im
> BIOS trotz obiger Einstellung.

Hallo,

was für ein PC ist das denn?

Was zeigt das BIOS 15 Sekunden lang an?


Bernd Mayer

Am 27.04.2024 Sa. um 13:39 schrieb Ralph Aichinger:
> Bernd Mayer <beam.bam.boom@knuut.de> wrote:
>> Was zeigt das BIOS 15 Sekunden lang an?
>
> Ich bin zwar nicht der angesprochene, aber gerade im Serverbereich ist
> 15 Sekunden Warten ohne Feedback quasi gar nix.
>
Bei mir sind es aber im Normalfall genau 2,4 Sekunden.

Jürgen

Am 27.04.2024 Sa. um 12:22 schrieb Marco Moock:
> Am 27.04.2024 12:10 Uhr schrieb Jürgen Jänicke:
>
>> Ups, zu früh gefreut. Leider ist es nur bei einem Neustart
>> (Warmstart) ok. Bei einem richtigen Kaltstart wartet er wieder ca. 15
>> Sekunden im BIOS trotz obiger Einstellung.
>
> Ist die LED am Netzwerkport dann aus?
>
Ja. Ist aus wenn Switch auch aus ist.

Jürgen

Am 27.04.2024 Sa. um 12:23 schrieb Bernd Mayer:
> Am 27.04.24 um 12:10 schrieb Jürgen Jänicke:
>>>
>> Ups, zu früh gefreut. Leider ist es nur bei einem Neustart (Warmstart)
>> ok. Bei einem richtigen Kaltstart wartet er wieder ca. 15 Sekunden im
>> BIOS trotz obiger Einstellung.
>
> Hallo,
>
> was für ein PC ist das denn?
>
Ist ein Acer Aspire C24-1650 (ein all-in-one pc  -mit dem ich ansonsten
rundum zufrieden bin)

> Was zeigt das BIOS 15 Sekunden lang an?
>
Die übliche Meldung:
"Press <Del> to Enter BIOS Setup Menu, Press <F12> to Display Boot Menu"

Jürgen

Marco Moock <mm+solani@dorfdsl.de> wrote:
>Am 27.04.2024 09:19 Uhr schrieb Marc Haber:
>> Ich habe das selbst noch nie mit IPv6 gemacht, daher beschränke ich
>> mich im Weiteren auf IPv4.
>
>Das geht ja mal gar nicht.
>Interessant wird, wie der die eigentlichen Daten nachlädt. Bei Ubuntu
>war das glaub NFS und da soll es wohl mit IPv6 noch Probleme geben.

Das kommt darauf an was da gebootet wird. Der Debian-Installer ist ja
im Wesentlichen ein initramfs, der halt vom PXE-Bootloader per ftp
geladen oder von iPXE per http; grml lädt sein initramfs genauso. Wenn
man wirklich ein Betriebssystem aus dem Netz bootet, mit dem dann
später auch gearbeitet werden soll, möchte man natürlich ein
read/write fähiges Netzwerkfilesystem haben, aber bis das System so
weit ist ist der PXE-Boot längst gelaufen.

Mit IPv6 gehe ich davon aus dass das ganz ähnlich aussieht, DHCPv6 ist
halt subtil anders. Nur, welche Hardware hat einen IPv6-fähigen
PXE-Client in der Firmware?

>> Manche Softwaredistributionssysteme greifen an dieser Stelle ein und
>> senden, wenn für konkret diesen Client eine Installation hinterlegt
>> ist, ein eigenes DHCPOFFER, in dem Boot-Informationen (z.B. Boot File,
>> Next Server etc) enthalten sind. Ist keine Installation hinterlegt,
>> ignorieren diese Systeme das DHCPDISCOVER und überlassen die Arbeit
>> dem "eigentlichen" DHCP-Server.¹
>
>Ist das nicht Garant dafür, dass Allerlei passieren kann?
>Eines der Systeme bevorzugt einfach den ersten DHCP oder so?

Bei der Softwaredistribution will der Client ja booten. Im DHCPOFFER
vom ersten Server sind keine Bootoptionen drin, also wird der
bootwillige Client dieses für ihn unbrauchbare DHCPOFFER als fü rihn
unbrauchbar verwerfen.

>> Der Client darf sich dann aus den empfangenen DHCPOFFERs dasjenige
>> aussuchen, das ihm am besten in den Kram passt. Ein gerade auf PXE
>> Boot wartender Client wird das OFFER nehmen, in dem Boot-Informationen
>> entalten sind und alle anderen ignorieren; ein IP-Telefon wird das
>> DHCPOFFER wählen, das die Optionen enthält, auf die es wartet.
>
>Wird es das immer tun oder gibt es da schwarze Schafe?

Auch hier wird es für seine Funktion auf die zusätzlich übermittelte
Option angewiesen sein. Softwarefehler sind natürlich immer denkbar.

>> Im PXE-Fall ist es übrigens nicht unüblich, dass die nachgeladene
>> Komponente wieder "von vorne" mit DHCP anfängt, damit die Beteiligen
>> dieses Bootstrap-Prozesses nicht miteinander reden müssen. Dumme
>> Server vergeben an dieser Stelle eine ganz neue IP-Adresse, was
>> zusammen mit langen Leasezeiten durchaus lästig sein kann (weil ein
>> PXE-Boot potenziell mehrere Leases belegen kann, und so ein /24 ist
>> schon ziemlich schnell voll).
>
>IPv4 halt. :-)

Bei IPv6 kommt man sogar ganz ohne Leases aus.

>> ³ iPXE hat den großen Vorteil, dass es http spricht und den Großteil
>> des zu bootenden Betriebssystem so nachladen kann. Das ist erheblich
>> schneller als das hier traditionell eingesetzte tftp.
>
>Warum ist tftp signifikant langsamer?

Der Hauptgrund dürfte sein, dass tftp kein Receive Window unterstützt,
es wird also immer erst auf den Eingang der Quittung gewartet bevor
das nächste Datenpaket losgeschickt wird.

Da möchte man einfach etwas benutzen was auf TCP basiert und einen
vollständig implementierten TCP-Stack zur Verfügung hat.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Am 27.04.2024 13:54 Uhr schrieb Marc Haber:

> Mit IPv6 gehe ich davon aus dass das ganz ähnlich aussieht, DHCPv6 ist
> halt subtil anders. Nur, welche Hardware hat einen IPv6-fähigen
> PXE-Client in der Firmware?

Mein ZBook 15 G1 (2013) behauptet das zumindest.

> >> Im PXE-Fall ist es übrigens nicht unüblich, dass die nachgeladene
> >> Komponente wieder "von vorne" mit DHCP anfängt, damit die
> >> Beteiligen dieses Bootstrap-Prozesses nicht miteinander reden
> >> müssen. Dumme Server vergeben an dieser Stelle eine ganz neue
> >> IP-Adresse, was zusammen mit langen Leasezeiten durchaus lästig
> >> sein kann (weil ein PXE-Boot potenziell mehrere Leases belegen
> >> kann, und so ein /24 ist schon ziemlich schnell voll).  
> >
> >IPv4 halt. :-)  
> 
> Bei IPv6 kommt man sogar ganz ohne Leases aus.
> 
> >> ³ iPXE hat den großen Vorteil, dass es http spricht und den
> >> Großteil des zu bootenden Betriebssystem so nachladen kann. Das
> >> ist erheblich schneller als das hier traditionell eingesetzte
> >> tftp.  
> >
> >Warum ist tftp signifikant langsamer?  
> 
> Der Hauptgrund dürfte sein, dass tftp kein Receive Window unterstützt,
> es wird also immer erst auf den Eingang der Quittung gewartet bevor
> das nächste Datenpaket losgeschickt wird.

Ist das bei den geringen Latenzen im internen Netz wirklich spürbar?
Ich habe per TFTP bisher nur Kram auf Geräte übertragen, die halt lahm
sind - Cisco-Router z.B.

-- 
Gruß
Marco

Spam und Werbung bitte an
1714218893ichwillgesperrtwerden@nirvana.admins.ws

Am 27.04.2024 13:46 Uhr schrieb Jürgen Jänicke:

> Am 27.04.2024 Sa. um 12:22 schrieb Marco Moock:
> > Am 27.04.2024 12:10 Uhr schrieb Jürgen Jänicke:
> >   
> >> Ups, zu früh gefreut. Leider ist es nur bei einem Neustart
> >> (Warmstart) ok. Bei einem richtigen Kaltstart wartet er wieder ca.
> >> 15 Sekunden im BIOS trotz obiger Einstellung.  
> > 
> > Ist die LED am Netzwerkport dann aus?
> >   
> Ja. Ist aus wenn Switch auch aus ist.

Das ist spannend. Teste mal mit eingestecktem Kabel am PC, aber
ausgesteckt am Switch.


-- 
Gruß
Marco

Spam und Werbung bitte an
1714218392ichwillgesperrtwerden@nirvana.admins.ws

Am 27.04.2024 Sa. um 14:17 schrieb Marco Moock:
> Am 27.04.2024 13:46 Uhr schrieb Jürgen Jänicke:
>
>> Am 27.04.2024 Sa. um 12:22 schrieb Marco Moock:
>>> Am 27.04.2024 12:10 Uhr schrieb Jürgen Jänicke:
>>>
>>>> Ups, zu früh gefreut. Leider ist es nur bei einem Neustart
>>>> (Warmstart) ok. Bei einem richtigen Kaltstart wartet er wieder ca.
>>>> 15 Sekunden im BIOS trotz obiger Einstellung.
>>>
>>> Ist die LED am Netzwerkport dann aus?
>>>
>> Ja. Ist aus wenn Switch auch aus ist.
>
> Das ist spannend. Teste mal mit eingestecktem Kabel am PC, aber
> ausgesteckt am Switch.
>
Genau so ist es immer gewesen. Habe immer nur den Stecker am Switch gezogen.

Jürgen

Am 27.04.2024 Sa. um 14:17 schrieb Marco Moock:
> Am 27.04.2024 13:46 Uhr schrieb Jürgen Jänicke:
>
>> Am 27.04.2024 Sa. um 12:22 schrieb Marco Moock:
>>> Am 27.04.2024 12:10 Uhr schrieb Jürgen Jänicke:
>>>
>>>> Ups, zu früh gefreut. Leider ist es nur bei einem Neustart
>>>> (Warmstart) ok. Bei einem richtigen Kaltstart wartet er wieder ca.
>>>> 15 Sekunden im BIOS trotz obiger Einstellung.
>>>
>>> Ist die LED am Netzwerkport dann aus?
>>>
>> Ja. Ist aus wenn Switch auch aus ist.
>
> Das ist spannend. Teste mal mit eingestecktem Kabel am PC, aber
> ausgesteckt am Switch.
>
>
Habe nun das Problem (erstmal) prakmatisch gelöst. Es geht hier ja nur
um 100Mbit/s und da trenne ich die Verbindung mit einem 4pol.
Kippschalter. Den kann ich halt etwas günstiger erreichbar
positionieren. . .

Jürgen

PS: Und ja, funktioniert trotz einigen Zentimetern nicht normgerechter
Leitungsführung.

Ralph Aichinger <ralph@pi.h5.or.at> wrote:
>Bernd Mayer <beam.bam.boom@knuut.de> wrote:
>> Was zeigt das BIOS 15 Sekunden lang an?
>
>Ich bin zwar nicht der angesprochene, aber gerade im Serverbereich ist
>15 Sekunden Warten ohne Feedback quasi gar nix.

Bei Arbeitsplatzrechnern ist "Zeit bis zum Windows-Desktop" eine
durchaus nicht unwichtige Metrik, auch in der Presse.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Jürgen Jänicke <post@j-jaenicke.de> wrote:
>Am 27.04.2024 Sa. um 12:23 schrieb Bernd Mayer:
>> Was zeigt das BIOS 15 Sekunden lang an?
>>
>Die übliche Meldung:
>"Press <Del> to Enter BIOS Setup Menu, Press <F12> to Display Boot Menu"

Bei besseren Firmwares kann man die Wartezeit an dieser Stelle im
Firmware-Setup konfigurieren.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Marco Moock <mm+solani@dorfdsl.de> wrote:
>Am 27.04.2024 13:54 Uhr schrieb Marc Haber:
>> >> ³ iPXE hat den großen Vorteil, dass es http spricht und den
>> >> Großteil des zu bootenden Betriebssystem so nachladen kann. Das
>> >> ist erheblich schneller als das hier traditionell eingesetzte
>> >> tftp.
>> >
>> >Warum ist tftp signifikant langsamer?
>>
>> Der Hauptgrund dürfte sein, dass tftp kein Receive Window unterstützt,
>> es wird also immer erst auf den Eingang der Quittung gewartet bevor
>> das nächste Datenpaket losgeschickt wird.
>
>Ist das bei den geringen Latenzen im internen Netz wirklich spürbar?

Größenordnungen..

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Jürgen Jänicke schrieb am 27/4/2024 12:10:

> Ups, zu früh gefreut. Leider ist es nur bei einem Neustart (Warmstart)
> ok. Bei einem richtigen Kaltstart wartet er wieder ca. 15 Sekunden im
> BIOS trotz obiger Einstellung.

Ist das BIOS/UEFI aktuell? Falls nein, Update machen.

--
Gerald

Am 27.04.24 um 18:53 schrieb Marc Haber:
> Ralph Aichinger <ralph@pi.h5.or.at> wrote:
>> Bernd Mayer <beam.bam.boom@knuut.de> wrote:
>>> Was zeigt das BIOS 15 Sekunden lang an?

Diese Frage ist IMO noch offen oder? War die Antwort "Nix"?

>> Ich bin zwar nicht der angesprochene, aber gerade im Serverbereich ist
>> 15 Sekunden Warten ohne Feedback quasi gar nix.
>
> Bei Arbeitsplatzrechnern ist "Zeit bis zum Windows-Desktop" eine
> durchaus nicht unwichtige Metrik, auch in der Presse.
Sehe ich auch so, und hier geht's ja m.W. auch um einen
Arbeitsplatz-rechner. Und ich halte diese o.g. "Metrik" für so mächtig
(= für ONU's Wichtig weil direkt meßbar) das sie ein Antrieb sein dürfte
für immer mehr... an CPU-Takt, Schnelleres RAM, SSDs und was es eben
sonst beschleunigen könnte. Und dann starten sie das ineffizienteste OS
von allen damit: Windows. ;-)

Und in den Minuten die (m)ein älterer Proliant (G5) hier braucht um
durch seine Startup-Procedere zu taumeln ist mein ebenfalls alter
Desktop (aber mit SSD) längst beim Grafischen Target "Login-Manager"
angekommen und ist am warten. Aber wenigstens wartet er "schnell" :-)


Bye/
   /Kay

--
nix

Am 27.04.24 um 12:10 schrieb Jürgen Jänicke:
> Am 27.04.2024 Sa. um 10:55 schrieb Jürgen Jänicke:
>> Am 26.04.2024 Fr. um 19:48 schrieb Kay Martinen:
>>>
>>>
>>> Am 26.04.24 um 18:55 schrieb Marc Haber:
>>>> Marco Moock <mm+solani@dorfdsl.de> wrote:
>>>>> Am 26.04.2024 16:49 Uhr schrieb Jürgen Jänicke:
>>>
>>> Warum steht LAN dann überhaupt in der Bootorder? Statt an 3. Stelle
>>> sollte es überhaupt nicht auftreten - wenn man es nie braucht.
>>>
>> Ja, stimmt eigentlich. Habe jetzt LAN deaktiviert. Also steht jetzt da:
>> 1. Bootgerät: ubuntu (wegen GRUB Bootmanger)

Hast du noch einen Booteintrag für die Platte, ist da nur "ubuntu" oder
mehr, z.b. "grub" oder "EFI-Boot" o.ä.?

>> 2. Bootgerät: Removable Device

Hast du einen SD-Kartenleser im Gerät oder ein CD/DVD Laufwerk?

>> 3. Bootgerät: disabled
>> 4. Bootgerät: disabled
>>
>> Mehr braucht es ja nicht und damit funktioniert es wieder korrekt auch
>> mit deaktiven aber angestecktem Switch.
>>
> Ups, zu früh gefreut. Leider ist es nur bei einem Neustart (Warmstart)
> ok. Bei einem richtigen Kaltstart wartet er wieder ca. 15 Sekunden im
> BIOS trotz obiger Einstellung.

Und du bist dir Sicher das der nicht evtl. 15 Sekunden auf ein (Nicht
vorhandenes oder reagierendes) Removable Device wartet - statt auf das LAN?

Du könntest den 2. Punkt auch mal raus werfen und das Testen. Da es
verschiedene Geräte betrifft kann sich das ggf. überlappen. Also das er
auf ein CD/DVD Laufwerk zugreifen will und im Hintergrund schon versucht
ob das LAN aktiv ist - um bei Timeout des 2. gleich mit dem 3. weiter zu
machen. Da du 3. nun raus geworfen hast träte 2. Zu tage.

BTW. Ich hatte mal einen HP All-In-One Drucker mit Multikarten-leser.
Eines Tages hatte ich die CF-Karte einer Digitalkamera darin vergessen.
Der PC hat beim Booten eine Ewigkeit gewartet weil er den; per USB
angeschlossenen; Kartenleser als Bootgerät erkannte. Nur leider war die
CF nicht bootbar was ihn nicht interessiert hat.

Lösung: CF entfernen und/oder Booten davon im Bios aus knipsen.


Bye/
   /Kay

--
nix

Am 27.04.2024 Sa. um 23:25 schrieb Kay Martinen:
>
>
> Am 27.04.24 um 12:10 schrieb Jürgen Jänicke:
>> Am 27.04.2024 Sa. um 10:55 schrieb Jürgen Jänicke:
>>> Am 26.04.2024 Fr. um 19:48 schrieb Kay Martinen:
>>>>
>>>>
>>>> Am 26.04.24 um 18:55 schrieb Marc Haber:
>>>>> Marco Moock <mm+solani@dorfdsl.de> wrote:
>>>>>> Am 26.04.2024 16:49 Uhr schrieb Jürgen Jänicke:
>>>>
>>>> Warum steht LAN dann überhaupt in der Bootorder? Statt an 3. Stelle
>>>> sollte es überhaupt nicht auftreten - wenn man es nie braucht.
>>>>
>>> Ja, stimmt eigentlich. Habe jetzt LAN deaktiviert. Also steht jetzt da:
>>> 1. Bootgerät: ubuntu (wegen GRUB Bootmanger)
>
> Hast du noch einen Booteintrag für die Platte, ist da nur "ubuntu" oder
> mehr, z.b. "grub" oder "EFI-Boot" o.ä.?
>
Nein

>>> 2. Bootgerät: Removable Device
>
> Hast du einen SD-Kartenleser im Gerät oder ein CD/DVD Laufwerk?
>
Nur SD-Kartenleser und der Slot ist leer.

>
> Und du bist dir Sicher das der nicht evtl. 15 Sekunden auf ein (Nicht
> vorhandenes oder reagierendes) Removable Device wartet - statt auf das LAN?
>
Und das nur bei ausgeschaltenen Switch?

> Du könntest den 2. Punkt auch mal raus werfen und das Testen.
>
Auch keine Änderung. Aber wie ich gestern 14:48 schrieb habe ich das
Problem nun anderweitig, rein elektro-mechanisch, gelöst.

Jürgen

Am 27.04.2024 Sa. um 22:12 schrieb Gerald E¡scher:
> Jürgen Jänicke schrieb am 27/4/2024 12:10:
>
>> Ups, zu früh gefreut. Leider ist es nur bei einem Neustart (Warmstart)
>> ok. Bei einem richtigen Kaltstart wartet er wieder ca. 15 Sekunden im
>> BIOS trotz obiger Einstellung.
>
> Ist das BIOS/UEFI aktuell? Falls nein, Update machen.
>
Ist laut Acer Website aktuell.

Jürgen

Kay Martinen <usenet@martinen.de> wrote:
>Am 27.04.24 um 18:53 schrieb Marc Haber:
>> Bei Arbeitsplatzrechnern ist "Zeit bis zum Windows-Desktop" eine
>> durchaus nicht unwichtige Metrik, auch in der Presse.
>Sehe ich auch so, und hier geht's ja m.W. auch um einen
>Arbeitsplatz-rechner. Und ich halte diese o.g. "Metrik" für so mächtig
>(= für ONU's Wichtig weil direkt meßbar) das sie ein Antrieb sein dürfte
>für immer mehr... an CPU-Takt, Schnelleres RAM, SSDs und was es eben
>sonst beschleunigen könnte.

Dabei ist der Selbttest und die Hardwareinitialisierung der Firmware
der bestimmende Faktor.

Das neue vom Kunden bereitgestellte Notebook braucht in dieser
Disziplon locker zehn Sekunden länger als sein Vorgänger. Die Zeit vom
Einschalten bis zur Abfrage der Bitlocker-PIN ist bei diesem Gerät
länger als die Zeit von der Bitlocker-PIN bis zum benutzbaren Windows.

Inzwischen habe ich mich auch daran gewöhnt, mein Getränk direkt nach
dem Einschalten zu holen. Muss mich beeilen, denn wenn man die PIN
nicht eingibt, geht der Rechner ziemlich schnell wieder aus.

Satt schneller als der alte am Windows-Desktop ist die neue Kiste
trotzdem.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Am 27.04.24 um 09:19 schrieb Marc Haber:
> Kay Martinen <usenet@martinen.de> wrote:
>> Am 26.04.24 um 18:55 schrieb Marc Haber:
>>> Das würde ich exakt andersrum vermuten.

>>> Switch aus => Link down => PXE boot klar unmöglich => kann schnell von
>>> der Platte booten.
>>
>> Denkbar wäre doch das es trotz link Down auf einen Timeout wartet weil
>> es ja möglich ist das jemand noch in dem Zeitfenster ein Kabel
>> einsteckt. Dann ist der Link da und... (s.u.)
>
> Das würde mich überraschen. Aber gut, so viel Erfahrung mit
> verschiedener Hardware habe ich da nicht.

Naja, einen Teil dieser Erfahrung verdanke ich meinem Unübersichtlichen
"Umfeld" und meiner gelegentlichen Schusseligkeit (Oh, vergessen das
Kabel zu stecken). ;)

>>> Switch an => Link Up => Mindestens DHCP-Timeout muss abgewartet werden
>>> => dauert
>>
>> Wie PXE mit DHCP interagiert weiß ich nicht. Die Klassische Methode
>> (TFTP) fragt den dhcpd nach einem bootfile. Dazu braucht dieser eine
>> entsprechende Einstellung sonst wird er das vermutlich sofort NAK'en und
>> dann kann der nächste Eintrag der Bootorder greifen.
>
> Das ist ein so interressantes Thema dass ich das gerne etwas näher
> beleuchten würde. Vermutlich kennst Du das schon alles, aber es gibt
> ja auch noch andere Leser.

Im Grunde auch nur die konfig des dhcpd und das grundlegende Prozedere
aus DHCP-Discover, -Offer und -Ack/Nak

> Ich habe das selbst noch nie mit IPv6 gemacht, daher beschränke ich
> mich im Weiteren auf IPv4.

Hier Dito weil ich IPv6 im LAN nicht wirklich brauche - und für Remote
Boot oversized hielte.

Aber hat nicht Ulli H. o.a. mal von einem Solchen (PXE, IPv6) Versuch
berichtet - und das er aus unbekannten gründen fehl schlug?

> Ein Startup eines Rechners per PXE beginnt mit einem DHCPDISCOVER. Das
> ist ein Broadcast, kommt also bei allen DHCP-Servern und DHCP-Relays
> im lokalen Netz an. Ja, das können mehrere sein.

Ja. Wobei allerdings immer geraten wird in einem Netz-Segment nur Einen
DHCPd laufen zu haben. Das zwei DHCPd (generisch gesprochen, nicht
ISC-spezifisch gemeint) sich absprechen können oder gemeinsam agieren
ist m.E. noch nicht so lange möglich.

Und wenn man solche nicht verwendet kommt es eben drauf an, wie du unten
ausführst.

> Jeder DHCP-Server (auch diejenigen, an die die DHCP-Relays das
> DHCPDISCOVER weitergeleiter haben), der sich zu einer Antwort berufen
> führt, antwortet auf das DHCPDISCOVER. Der Client bekommt also im
> zweifel mehrere DHCPOFFER-Pakete, die sich auch durchaus widersprechen
> können oder unterschiedliche Informationen beinhalten.

An diesem Punkt setzte aber früher auch das First-come-first-serve an -
jedenfalls wenn der Client keine besonderen Ansprüche stellte. Also wenn
er nur IP/Mask und GW haben will nähme er den ersten der antwortete.

Sollte sich das geändert haben oder beziehst du da spezielle
Anforderungen mit ein?

> Manche Softwaredistributionssysteme greifen an dieser Stelle ein und
> senden, wenn für konkret diesen Client eine Installation hinterlegt
> ist, ein eigenes DHCPOFFER, in dem Boot-Informationen (z.B. Boot File,
> Next Server etc) enthalten sind. Ist keine Installation hinterlegt,
> ignorieren diese Systeme das DHCPDISCOVER und überlassen die Arbeit
> dem "eigentlichen" DHCP-Server.¹

Es ist natürlich klar das ein Dhcp/Bootp-client nicht erfolgreich booten
kann wenn er ein Offer eines Servers annähme in dem kein bootfile
enthalten ist. Mit Softwaredistributionsystem meinst du jetzt andere als
nur den DHCPd, eher welche die ihn nur nutzen um neuen Clients ein ein
RIPL zu ermöglichen. Was man manuell ablegen kann das tun die halt
automagisiert.

> Derselbe Mechanismus wird gerne von IP-Telefonanlagen genutzt, hierbei
> sendet dann die Telefonanlage ein eigenes DHCPOFFER mit den speziellen
> Optionen die das Telefon erwartet.

(Nicht) im Eigenen Voice-VLAN?

> Der Client darf sich dann aus den empfangenen DHCPOFFERs dasjenige
> aussuchen, das ihm am besten in den Kram passt. Ein gerade auf PXE
> Boot wartender Client wird das OFFER nehmen, in dem Boot-Informationen
> entalten sind und alle anderen ignorieren; ein IP-Telefon wird das
> DHCPOFFER wählen, das die Optionen enthält, auf die es wartet.

Soweit klar. Works as expected! Wenn alle diese Systeme in einem
LAN-Segment zusammen stehen dann kann es ja nur so laufen das sich der
Client eines aussuchen muß. Ich bin nur nicht sicher ob das beim Client
ggf. interaktiv ausgewählt werden müßte oder ob der automagisch immer
das richtige zieht.

> Ein bereits gebootetes Betriebssystem wird im Zweifel alles nehmen was
> daherkommt, daher ist es so wichtig dass in den beiden oberen
> Sonderbeispielen weder das Softwaredistributionssystem noch die
> Telefonanlage überhaupt ein DHCPOFFER versenden. Das

Ich meine ein bereits gebootetes OS sendet mit dem Request auch den ggf.
gesetzten hostnamen mit. An dem kann der Server ihn dann z.b. auch
identifizieren falls er einen fixed-address eintrag hat.

Ein Client-gerät das erst booten will kann das m.E. nicht tun. Da bliebe
nur die HW-MAC und erweitert werden könnte das allenfalls wenn der
Client seine eigene MAC oder IP im dns abfragen würde um einen hostnamen
zu bekommen. Aber dann ist die DHCP-Sequenz m.E. schon abgelaufen.



> Distributionssystem wird schweigen wenn für einen Client keine
> Installation hinterlegt ist; die Telefonanlage kennt typischerweise
> den MAC-Adress-Range aus dem "ihre" Telefone ihre MAC-Adressen
> zugewiesen bekommen haben und wird nur diesen antworten. Auf diese
> Weise ist auch gleich der Einsatz "fremder" Telefone schwieriger, was
> im Interesse des Anlagenherstellers liegt.

Heißt: Die Vendor-ID der MAC wird von der IP-Telefonanlage verwendet um
andere Geräte aus zu sperren, sie nicht zu versorgen. Nice!

Drei Bytes entscheiden ob dein Telefon das richtige ist... ;)

> Nachdem der Client sich für ein DHCPOFFER entschieden hat, sendet er
> an den Server, von dem das OFFER gekommen ist, ein DHCPREQUEST² um ihm
> zu bestätigen, dass er der "auserwählte" ist, und mit einer weiteren
> Bestätigung seitens des Servers ist die Lease nun komplett.

Hmm. DHCPACK!

> Im PXE-Fall ist es übrigens nicht unüblich, dass die nachgeladene
> Komponente wieder "von vorne" mit DHCP anfängt, damit die Beteiligen
> dieses Bootstrap-Prozesses nicht miteinander reden müssen. Dumme
> Server vergeben an dieser Stelle eine ganz neue IP-Adresse, was
> zusammen mit langen Leasezeiten durchaus lästig sein kann (weil ein
> PXE-Boot potenziell mehrere Leases belegen kann, und so ein /24 ist
> schon ziemlich schnell voll).

Okay. Das hängt aber doch an den Lease-Zeiten die man IMO Pro Block
getrennt setzen kann.

Man sollte Remote Bootenden Clients generell keine Langen Lease-zeiten
geben es sei denn man könnte sicherstellen das der server den client
auch im gebooteten Zustand "wiedererkennt". Sonst zieht der sich eine
neue IP und landet ggf. im falschen Pool und man hat einen Client mit
zwei Leases. Das wäre aber dann ein Konfigurations-problem.

Bei PXE ändert sich doch die HW-MAC nicht nach dem remote Boot oder?
Man kann sie bei vielen Systemen ja per Software ändern aber warum
sollte man das generell tun?

> Wegen dieses stufenweisen Boots ist es nicht selten notwendig, dass
> der Server "intelligente" Entscheidungen trifft. Zum Beispiel ist
> dann, wenn die weit verbreitete Software iPXE³ zum Einsatz kommt
> üblich, dass im Server Logik wie diese hier hinterlegt ist:
>
> |if exists user-class and option user-class = "iPXE" {
> |filename "http://bootserver.example/pxe/default.ipxe";
> |} else {
> |filename "undionly.kpxe";
> |}
>
> Im Klartext bedeutet das "schaue in die vom Client übermittelte
> DHCP-Option User-Class und wenn Du daran erkennst, dass auf dem Client
> bereits ein iPXE läuft¼ schicke ihm den URL zum Weiterbooten. Sonst
> schicke sage ihm er möge iPXE aus dem Netz laden und ausführen."

bootserver.example ist hier sicher nur Beispielhaft für ein bootfile auf
einem Webserver im LAN denke ich. Mit PXE, iPXE habe ich bisher keine
notwendigen Berührungspunkte gehabt.

Mich gruselt aber dabei das ein Client der eine IP/Mask und GW bekam
dann ggf. schlicht über den Router raus ein beliebiges Bootfile aus dem
Internet abfischen könnte - mit unbekanntem Inhalt. Falsche URL oder
DNS-Fehlkonfig dürfte reichen.


> ³ iPXE hat den großen Vorteil, dass es http spricht und den Großteil
> des zu bootenden Betriebssystem so nachladen kann. Das ist erheblich
> schneller als das hier traditionell eingesetzte tftp. Außerdem kann

Öffnet aber auch die Möglichkeit beliebigen Schadcode aus dem Internet
zu ziehen - direkt beim Booten. Setzt nur Zugriff auf den
verantwortlichen DHCPd voraus. Tröstlich daran ist nur das ein bereits
Kompromittierter Router (DHCPd) das schlimmere Problem ist und Clients
normalerweise nicht so oft booten müssen.

Teufel vs. Beelzebub!

> iPXE ein Menü anbieten und auch anderweitig mit dem Benutzer
> interagieren. In meinem Labornetz bekommt jeder PXE-Client so ein Menü
> zugeworfen, wo der Benutzer auswählen kann, von seiner lokalen Platte
> weiterzubooten (was nach 5 Sekunden Wartezeit automatisch geschieht)
> oder ob er ein grml oder einen Debian-Installer zugeworfen bekommen
> möchte

Nice. Ich denke so was will ich auch irgendwann mal ausprobieren. Aber,
ich meine das (Auswahlmenü) ginge auch bereits mit PXE oder der Vorigen
Variante.

> ¼ manche VMs benutzen direkt iPXE als ersten Schritt des PXE-Boots,
> andere Systeme (wie z.b. die meisten "Bleche") wollen den ersten
> Schritt klassisch per tftp.

Ich habe hier auch noch echte ISA/PCI NICs mit Bootrom Sockel. :-)
IMHO habe ich in der ProxMox UI was von iPXE gelesen/gesehen. Habe es
aber noch nicht näher angesehen.

Bye/
   /Kay

--
nix

Kay Martinen <usenet@martinen.de> wrote:
>Am 27.04.24 um 09:19 schrieb Marc Haber:
>> Ein Startup eines Rechners per PXE beginnt mit einem DHCPDISCOVER. Das
>> ist ein Broadcast, kommt also bei allen DHCP-Servern und DHCP-Relays
>> im lokalen Netz an. Ja, das können mehrere sein.
>
>Ja. Wobei allerdings immer geraten wird in einem Netz-Segment nur Einen
>DHCPd laufen zu haben. Das zwei DHCPd (generisch gesprochen, nicht
>ISC-spezifisch gemeint) sich absprechen können oder gemeinsam agieren
>ist m.E. noch nicht so lange möglich.

Die müssen sich nicht absprechen, das funktioniert einfach so. Die
Pools dürfen sich halt nicht überschneiden. Die DHCP-Server müssen
sich nur untereinander "absprechen" wenn sie beid den selben Pool
bedienen sollen.

>> Jeder DHCP-Server (auch diejenigen, an die die DHCP-Relays das
>> DHCPDISCOVER weitergeleiter haben), der sich zu einer Antwort berufen
>> führt, antwortet auf das DHCPDISCOVER. Der Client bekommt also im
>> zweifel mehrere DHCPOFFER-Pakete, die sich auch durchaus widersprechen
>> können oder unterschiedliche Informationen beinhalten.
>
>An diesem Punkt setzte aber früher auch das First-come-first-serve an -
>jedenfalls wenn der Client keine besonderen Ansprüche stellte. Also wenn
>er nur IP/Mask und GW haben will nähme er den ersten der antwortete.

Genau. Streng genommen darf er sich aussuchen was er macht. Es ist
freilich logisch, den ersten Datensatz zu nehmen der alles beinhaltet
was der Client hören möchte.

>> Manche Softwaredistributionssysteme greifen an dieser Stelle ein und
>> senden, wenn für konkret diesen Client eine Installation hinterlegt
>> ist, ein eigenes DHCPOFFER, in dem Boot-Informationen (z.B. Boot File,
>> Next Server etc) enthalten sind. Ist keine Installation hinterlegt,
>> ignorieren diese Systeme das DHCPDISCOVER und überlassen die Arbeit
>> dem "eigentlichen" DHCP-Server.¹
>
>Es ist natürlich klar das ein Dhcp/Bootp-client nicht erfolgreich booten
>kann wenn er ein Offer eines Servers annähme in dem kein bootfile
>enthalten ist. Mit Softwaredistributionsystem meinst du jetzt andere als
>nur den DHCPd, eher welche die ihn nur nutzen um neuen Clients ein ein
>RIPL zu ermöglichen. Was man manuell ablegen kann das tun die halt
>automagisiert.

Ich meine jetzt Systeme die z.B. einen neuen Client komplett ohne
menschliche Interaktion mit dem Rechner mit Betriebssystem versorgen
("unattended install").

>> Derselbe Mechanismus wird gerne von IP-Telefonanlagen genutzt, hierbei
>> sendet dann die Telefonanlage ein eigenes DHCPOFFER mit den speziellen
>> Optionen die das Telefon erwartet.
>
>(Nicht) im Eigenen Voice-VLAN?

Nicht notwendigerweise, nein. Das geht auch wenn alles in einem VLAN
ist.

>> Der Client darf sich dann aus den empfangenen DHCPOFFERs dasjenige
>> aussuchen, das ihm am besten in den Kram passt. Ein gerade auf PXE
>> Boot wartender Client wird das OFFER nehmen, in dem Boot-Informationen
>> entalten sind und alle anderen ignorieren; ein IP-Telefon wird das
>> DHCPOFFER wählen, das die Optionen enthält, auf die es wartet.
>
>Soweit klar. Works as expected! Wenn alle diese Systeme in einem
>LAN-Segment zusammen stehen dann kann es ja nur so laufen das sich der
>Client eines aussuchen muß. Ich bin nur nicht sicher ob das beim Client
>ggf. interaktiv ausgewählt werden müßte oder ob der automagisch immer
>das richtige zieht.

Eine interaktive Möglichkeit habe ich noch nie erlebt. Möglich ist es
freilich.

>> Ein bereits gebootetes Betriebssystem wird im Zweifel alles nehmen was
>> daherkommt, daher ist es so wichtig dass in den beiden oberen
>> Sonderbeispielen weder das Softwaredistributionssystem noch die
>> Telefonanlage überhaupt ein DHCPOFFER versenden. Das
>
>Ich meine ein bereits gebootetes OS sendet mit dem Request auch den ggf.
>gesetzten hostnamen mit. An dem kann der Server ihn dann z.b. auch
>identifizieren falls er einen fixed-address eintrag hat.

Ja, könnte er. Gängig ist dass der DHCP-Server dann ein DNSUPDATE
macht.

>> Distributionssystem wird schweigen wenn für einen Client keine
>> Installation hinterlegt ist; die Telefonanlage kennt typischerweise
>> den MAC-Adress-Range aus dem "ihre" Telefone ihre MAC-Adressen
>> zugewiesen bekommen haben und wird nur diesen antworten. Auf diese
>> Weise ist auch gleich der Einsatz "fremder" Telefone schwieriger, was
>> im Interesse des Anlagenherstellers liegt.
>
>Heißt: Die Vendor-ID der MAC wird von der IP-Telefonanlage verwendet um
>andere Geräte aus zu sperren, sie nicht zu versorgen. Nice!

Genau.

>> Nachdem der Client sich für ein DHCPOFFER entschieden hat, sendet er
>> an den Server, von dem das OFFER gekommen ist, ein DHCPREQUEST² um ihm
>> zu bestätigen, dass er der "auserwählte" ist, und mit einer weiteren
>> Bestätigung seitens des Servers ist die Lease nun komplett.
>
>Hmm. DHCPACK!

Ich müsste jetzt wirklich in einen Packettrace oder in den Standard
gucken um zu wissen wie das heißt.

>> Im PXE-Fall ist es übrigens nicht unüblich, dass die nachgeladene
>> Komponente wieder "von vorne" mit DHCP anfängt, damit die Beteiligen
>> dieses Bootstrap-Prozesses nicht miteinander reden müssen. Dumme
>> Server vergeben an dieser Stelle eine ganz neue IP-Adresse, was
>> zusammen mit langen Leasezeiten durchaus lästig sein kann (weil ein
>> PXE-Boot potenziell mehrere Leases belegen kann, und so ein /24 ist
>> schon ziemlich schnell voll).
>
>Okay. Das hängt aber doch an den Lease-Zeiten die man IMO Pro Block
>getrennt setzen kann.
>
>Man sollte Remote Bootenden Clients generell keine Langen Lease-zeiten
>geben es sei denn man könnte sicherstellen das der server den client
>auch im gebooteten Zustand "wiedererkennt". Sonst zieht der sich eine
>neue IP und landet ggf. im falschen Pool und man hat einen Client mit
>zwei Leases. Das wäre aber dann ein Konfigurations-problem.

Das stört aber nicht, bis auf die unnötigt belegte Adresse.

Clients mit Betriebssystem merken sich üblicherweise beim
Herunterfahren ihre IP-Adresse und schicken beim nächsten Boot direkt
ein DHCPREQUEST für ihre alte Adresse an den Server, so dass der ganze
Zirkus nur ablaufen muss wenn der Server erstmal NACK sagt.

>Bei PXE ändert sich doch die HW-MAC nicht nach dem remote Boot oder?
>Man kann sie bei vielen Systemen ja per Software ändern aber warum
>sollte man das generell tun?

Das macht man meistens wenn man fertig gebootet hat damit einen das
Net nicht wiedererkennt. In so einem Unternehmensnetz ist man
natürlich daran interessiert, dass einen das Netz wiedererkennt.

>> Wegen dieses stufenweisen Boots ist es nicht selten notwendig, dass
>> der Server "intelligente" Entscheidungen trifft. Zum Beispiel ist
>> dann, wenn die weit verbreitete Software iPXE³ zum Einsatz kommt
>> üblich, dass im Server Logik wie diese hier hinterlegt ist:
>>
>> |if exists user-class and option user-class = "iPXE" {
>> |filename "http://bootserver.example/pxe/default.ipxe";
>> |} else {
>> |filename "undionly.kpxe";
>> |}
>>
>> Im Klartext bedeutet das "schaue in die vom Client übermittelte
>> DHCP-Option User-Class und wenn Du daran erkennst, dass auf dem Client
>> bereits ein iPXE läuft¼ schicke ihm den URL zum Weiterbooten. Sonst
>> schicke sage ihm er möge iPXE aus dem Netz laden und ausführen."
>
>bootserver.example ist hier sicher nur Beispielhaft für ein bootfile auf
>einem Webserver im LAN denke ich.

Das ist der Hostname des Webservers, der das default.ipxe ausliefert.

>Mich gruselt aber dabei das ein Client der eine IP/Mask und GW bekam
>dann ggf. schlicht über den Router raus ein beliebiges Bootfile aus dem
>Internet abfischen könnte - mit unbekanntem Inhalt. Falsche URL oder
>DNS-Fehlkonfig dürfte reichen.

Es muss natürlich auch der Server willig sein, das Bootfile
auszuliefern, aber ja, das kann dann von irgendwo kommen. Den
Installer von ftp.debian.org zu booten müsste man tatsächlich mal
ausprobieren.

>> ¼ manche VMs benutzen direkt iPXE als ersten Schritt des PXE-Boots,
>> andere Systeme (wie z.b. die meisten "Bleche") wollen den ersten
>> Schritt klassisch per tftp.
>
>Ich habe hier auch noch echte ISA/PCI NICs mit Bootrom Sockel. :-)

Ich zum Glück nicht mehr.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Am 27.04.2024 Sa. um 10:02 schrieb Marcel Mueller:
> Am 26.04.24 um 16:49 schrieb Jürgen Jänicke:
>> Hallo, habe neuerdings einen LAN-Switch dem PC vorgeschalten aber der
>> ist i.d.R. aus, also ohne Stromversorgung. Wird nur bei Bedarf
>> aktiviert. 90% Netzwerkzeit läuft per WLAN.
>> Aber in dem Zustand, Switch ohne Strom, dauert das Booten wesentlich
>> länger. PC bleibt lange im BIOS, bzw. EFI, bevor es dann das
>> eigentliche OS bootet. LAN steht an 3. Stelle nach HDD und USB.
>> Ist der Switch bestromt oder das LAN-Kabel abgesteckt dann geht alles
>> wie gewohnt schnell voran.
>
> Vmtl. erkennt das System, dass das LAN angeschlossen ist, bekommt aber
> dann keine Verbindung.
>
Das heißt u.U. das der Switch selbst als Gerät erkannt wird? Oder
umgekehrt - allein das gesteckte Kabel im stromlosen Switch führt zu
dieser langen Wartezeit? Also wird das vorhandene Gerät registriert aber
da es nicht aktiv ist wird gewartet? Ok, muss ich so wohl hinnehmen.

Jürgen

Jürgen Jänicke schrieb am 29/4/2024 09:15:

> Also wird das vorhandene Gerät registriert aber
> da es nicht aktiv ist wird gewartet? Ok, muss ich so wohl hinnehmen.

Musst du nicht hinnehmen. In jedem ordentlichen BIOS/UEFI gibt es die
Möglichkeit, booten über LAN (PXE) abzuschalten.

--
Gerald

Am 29.04.2024 Mo. um 14:35 schrieb Gerald E¡scher:
> Jürgen Jänicke schrieb am 29/4/2024 09:15:
>
>> Also wird das vorhandene Gerät registriert aber
>> da es nicht aktiv ist wird gewartet? Ok, muss ich so wohl hinnehmen.
>
> Musst du nicht hinnehmen. In jedem ordentlichen BIOS/UEFI gibt es die
> Möglichkeit, booten über LAN (PXE) abzuschalten.
>
Ich schrieb bereits am Samstag(unter anderen)
"
. . .  Habe jetzt LAN deaktiviert. Also steht jetzt da:
1. Bootgerät: ubuntu (wegen GRUB Bootmanger)
2. Bootgerät: Removable Device
3. Bootgerät: disabled
4. Bootgerät: disabled
"
Aktuell ist auch das 2. Bootgerät disabled. Wo noch kann ich LAN
deaktivieren?

Jürgen

Am 29.04.24 um 09:15 schrieb Jürgen Jänicke:
>> Vmtl. erkennt das System, dass das LAN angeschlossen ist, bekommt aber
>> dann keine Verbindung.
>>
> Das heißt u.U. das der Switch selbst als Gerät erkannt wird?

Nein, einen ausgeschalteten Switch kann man nicht erkennen. Aber man
kann entweder die Schleifenimpedanz messen - ein angestecktes Gerät
führt zu einer relativ niederohmigen Verbindung der Adernpaare. Oder man
kann den gesteckten Stecker mechanisch erkennen. Letzteres hat aber den
Nachteil, dass ein eingestecktes, loses Kabel auch erkannt würde.
Außerdem ist Mechanik immer teurer als Elektronik.

> Oder
> umgekehrt - allein das gesteckte Kabel im stromlosen Switch führt zu
> dieser langen Wartezeit?

Zu einer Wartezeit führt nichts von alle dem. Dazu kommt es erst, wenn
im BIOS irgendein Programmcode meint, unbedingt auf eine aktive
Netzwerkverbindung warten zu müssen.

> Also wird das vorhandene Gerät registriert aber
> da es nicht aktiv ist wird gewartet? Ok, muss ich so wohl hinnehmen.

Ich vermute das.
Du kannst das recht leicht testen, indem du das Kabel abziehst.


Marcel

Am 28.04.24 um 17:23 schrieb Marc Haber:
> Kay Martinen <usenet@martinen.de> wrote:
>> Am 27.04.24 um 09:19 schrieb Marc Haber:

>>> ist ein Broadcast, kommt also bei allen DHCP-Servern und
>>> DHCP-Relays im lokalen Netz an. Ja, das können mehrere sein.

>> 1 DHCPd laufen zu haben. Das zwei DHCPd (...) sich absprechen
>> können oder gemeinsam agieren ist m.E. noch nicht so lange
>> möglich.
>
> Die müssen sich nicht absprechen, das funktioniert einfach so. Die
> Pools dürfen sich halt nicht überschneiden. Die DHCP-Server müssen
> sich nur untereinander "absprechen" wenn sie beid den selben Pool
> bedienen sollen.

Genau das meinte ich. Entweder du hast auf jedem dhcpd einen pool der
unterschiedliche IPs belegt oder es sind mindestens zwei mit gleichem
pool die sich dann aber absprechen sollten. So kann man sich immerhin
gegen ausfall des dhcp absichern ohne das alle clients neue leases brauchen.

>>> Manche Softwaredistributionssysteme greifen an dieser Stelle ein
>>> und senden, wenn für konkret diesen Client eine Installation

>> bootfile enthalten ist. Mit Softwaredistributionsystem meinst du
>> jetzt andere als nur den DHCPd, eher welche die ihn nur nutzen um
>> neuen Clients ein ein RIPL zu ermöglichen. Was man manuell ablegen
>> kann das tun die halt automagisiert.
>
> Ich meine jetzt Systeme die z.B. einen neuen Client komplett ohne
> menschliche Interaktion mit dem Rechner mit Betriebssystem versorgen
> ("unattended install").

Das dürfte z.b. beim Univention Corporate Server (UCS) möglich sein. IMO
bietet der auch Classroom-Management oder Desktop-Installationsdienste
an. Und, wie ich nachlas, scheinen Windows Server da ähnliches zu bieten.

Was mich nicht verwundern sollte. RIPL ging schon bei OS/2 IMO beim LSA4
und das ist echt lang her.

>>> Ein bereits gebootetes Betriebssystem wird im Zweifel alles
>>> nehmen was daherkommt, daher ist es so wichtig dass in den beiden
>>> oberen Sonderbeispielen weder das Softwaredistributionssystem
>>> noch die Telefonanlage überhaupt ein DHCPOFFER versenden. Das
>>
>> Ich meine ein bereits gebootetes OS sendet mit dem Request auch den
>> ggf. gesetzten hostnamen mit. An dem kann der Server ihn dann z.b.
>> auch identifizieren falls er einen fixed-address eintrag hat.
>
> Ja, könnte er. Gängig ist dass der DHCP-Server dann ein DNSUPDATE
> macht.

Bei Windows-Clients ist das m.W. eh der Default. Ab Install ist das
Häkchen in den Netzwerk-einstellungen dafür gesetzt "Adresse in DNS
registrieren".

Bin mir jetzt aber nicht sicher was dabei genau der Unterschied ist. Ob
der Win-Client nur seinen Namen sendet oder ob er frech beim Bind
anklopft und sich selbst eintragen wollte - was eher nicht sinnvoll ist.

Aber zum DNS Update braucht der dhcpd die (rndc) verbindung zum bind.
Die muß m.W. nicht auf localhost liegen. Aber ein Win-Client sollte das
nicht tun können.


>>> und mit einer weiteren Bestätigung seitens des Servers ist die
>>> Lease nun komplett.
>>
>> Hmm. DHCPACK!
>
> Ich müsste jetzt wirklich in einen Packettrace oder in den Standard
> gucken um zu wissen wie das heißt.

Mußt nur in's log schauen. Da stehen bei mir jede menge drin. Anders
geschrieben: DHCP ACK!

>>> reden müssen. Dumme Server vergeben an dieser Stelle eine ganz
>>> neue IP-Adresse, was zusammen mit langen Leasezeiten durchaus
>>> lästig sein kann (weil ein PXE-Boot potenziell mehrere Leases
>>> belegen kann, und so ein /24 ist schon ziemlich schnell voll).

>> Man sollte Remote Bootenden Clients generell keine Langen
>> Lease-zeiten geben es sei denn man könnte sicherstellen das der
>> server den client auch im gebooteten Zustand "wiedererkennt".

> Das stört aber nicht, bis auf die unnötigt belegte Adresse.

Deswegen meinte ich das man die leasezeit dafür kurz wählen sollte. Dann
ist sie schneller wieder frei.

> Clients mit Betriebssystem merken sich üblicherweise beim
> Herunterfahren ihre IP-Adresse und schicken beim nächsten Boot
> direkt ein DHCPREQUEST für ihre alte Adresse an den Server, so dass
> der ganze Zirkus nur ablaufen muss wenn der Server erstmal NACK
> sagt.

Was bei Fixed-address anhand der MAC ja normal nicht vorkommt.

>> Bei PXE ändert sich doch die HW-MAC nicht nach dem remote Boot
>> oder? Man kann sie bei vielen Systemen ja per Software ändern aber
>> warum sollte man das generell tun?
>
> Das macht man meistens wenn man fertig gebootet hat damit einen das
> Net nicht wiedererkennt. In so einem Unternehmensnetz ist man
> natürlich daran interessiert, dass einen das Netz wiedererkennt.

Du meinst damit man mit der Fertig Installierten Maschine nicht gleich
wieder die gleiche Installation neu drauf gebügelt bekommt?
Okay, da kann das dann Sinn machen. Die alternative dürfte aufwändiger
sein, dem Client einen Supplicant geben damit der Switchport ihn erkennt
und in ein anderes VLAN schiebt.

Und man muß auf dem SDS nur die MACs eintragen von den maschinen die neu
installiert werden sollen. Wenn die danach automagisch ihre MAC ändern
zu <myvendor><muster> dann kann man sie auch auseinander halten. So
lange die NIC ihrer Gesetzte MAC nicht vergißt. Sollte aber in ihrem
EEPROM stecken denke ich.

>>> Im Klartext bedeutet das "schaue in die vom Client übermittelte
>>> DHCP-Option User-Class und wenn Du daran erkennst, dass auf dem
>>> Client bereits ein iPXE läuft¼ schicke ihm den URL zum
>>> Weiterbooten. Sonst schicke sage ihm er möge iPXE aus dem Netz
>>> laden und ausführen."
>>
>> bootserver.example ist hier sicher nur Beispielhaft für ein
>> bootfile auf einem Webserver im LAN denke ich.
>
> Das ist der Hostname des Webservers, der das default.ipxe
> ausliefert.

Ich wollte mich schon früher mal mit den dhcp-options mehr auseinander
setzen. Mit user-class u.a. habe ich nur wenig experimentiert und da
ging es mir eher um die Zuordnung des Pools nach dem Client-OS.

Hab ich dann aber mit einem Retro-VLAN erschlagen.

>> Mich gruselt aber dabei das ein Client der eine IP/Mask und GW
>> bekam dann ggf. schlicht über den Router raus ein beliebiges
>> Bootfile aus dem Internet abfischen könnte -

> Es muss natürlich auch der Server willig sein, das Bootfile
> auszuliefern, aber ja, das kann dann von irgendwo kommen. Den

Nun Auth via .htaccess kann man da wohl vergessen also bliebe nur die
Allow und Deny Direktiven nach dem Netz oder IP-Bereich um den Ein zu
hegen das nicht jeder jedes file ziehen könnte. Im LAN ist das nicht das
Ding. Aber...

> Installer von ftp.debian.org zu booten müsste man tatsächlich mal
> ausprobieren.

... DAS wäre in der Tat mal Lustig. IMO bietet der Installer auch
(uboot, debootstrap?) dienstmodule an für eine Installation aus der
Ferne. Geht das nicht sogar gescripted per Antwort-datei?

Man muß ihn halt nur erst mal gebootet bekommen und per script so weit
das er zumindest eine (remote)shell startet um weiter zu machen - IMO
sogar von einem dritt-host aus wenn ich mich richtig erinnere.

Klingt echt kompliziert aber vermutlich braucht es nur 2 Dateien. Das
image und ein antwort-file das dazu passt. Ist lange her das ich danach
bei debian.org suchte aber ich bin sicher es gibt dazu was.

Wen wunderts. ;-)

>> Ich habe hier auch noch echte ISA/PCI NICs mit Bootrom Sockel. :-)
>
> Ich zum Glück nicht mehr.

Und ich finde aktuell die NIC Kiste mit meinen 3com's nicht wieder,
bräuchte aber grad eine für einen Thin Client den ich zum LAN Router
umstricken will.

Bye/
   /Kay

--
nix

Am 29.04.2024 Mo. um 20:26 schrieb Marcel Mueller:
> Am 29.04.24 um 09:15 schrieb Jürgen Jänicke:
>>> . . . . <<<
>
>> Also wird das vorhandene Gerät registriert aber da es nicht aktiv ist
>> wird gewartet? Ok, muss ich so wohl hinnehmen.
>
> Ich vermute das.
> Du kannst das recht leicht testen, indem du das Kabel abziehst.
>
Mach ich ja nun auch so. Zuerst testweise über einen 4pol. Kippschalter,
jetzt trenne ich die 4 Leitungen (da es nur 100Mbit/s sind) aktuell per
Relais. Und Relais + Switch werden nun nur bei Bedarf zusammen
eingeschalten. Unter anderen auch von einem Raspi welcher aus der Ferne
erreichbar ist und mir dann eben wenn notwendig noch 2 weitere Geräte
startet, ans Netz bringt und auch wieder abhängt und runterfährt.

Jürgen

Kay Martinen <usenet@martinen.de> wrote:
>Am 28.04.24 um 17:23 schrieb Marc Haber:
>> Kay Martinen <usenet@martinen.de> wrote:
>>> Am 27.04.24 um 09:19 schrieb Marc Haber:
>
>>>> ist ein Broadcast, kommt also bei allen DHCP-Servern und
>>>> DHCP-Relays im lokalen Netz an. Ja, das können mehrere sein.
>
>>> 1 DHCPd laufen zu haben. Das zwei DHCPd (...) sich absprechen
>>> können oder gemeinsam agieren ist m.E. noch nicht so lange
>>> möglich.
>>
>> Die müssen sich nicht absprechen, das funktioniert einfach so. Die
>> Pools dürfen sich halt nicht überschneiden. Die DHCP-Server müssen
>> sich nur untereinander "absprechen" wenn sie beid den selben Pool
>> bedienen sollen.
>
>Genau das meinte ich. Entweder du hast auf jedem dhcpd einen pool der
>unterschiedliche IPs belegt oder es sind mindestens zwei mit gleichem
>pool die sich dann aber absprechen sollten. So kann man sich immerhin
>gegen ausfall des dhcp absichern ohne das alle clients neue leases brauchen.

Ein kurzfristiger Ausfall des DHCP-Servers tut nicht so weh wie man
denkt, die bestehenden Clients haben mindestens die Hälfte ihrer Lease
noch vor sich, weil sie schon ab der halben Lease diese zu erneuern
versuchen. Nur neue Clients gucken ohne IP-Adresse in die Röhre.

Bei redundant ausgeführtem DHCP¹-Servern sind die Leasezeiten
potenziell erheblich kürzer als in der Konfiguration steht, da muss
man mehr aufpassen.

Und in Netzen die nur ein Default Gateway haben, ist ein redundanter
DHCP-Server im Wesentlichen nur Spielerei.

>>>> Ein bereits gebootetes Betriebssystem wird im Zweifel alles
>>>> nehmen was daherkommt, daher ist es so wichtig dass in den beiden
>>>> oberen Sonderbeispielen weder das Softwaredistributionssystem
>>>> noch die Telefonanlage überhaupt ein DHCPOFFER versenden. Das
>>>
>>> Ich meine ein bereits gebootetes OS sendet mit dem Request auch den
>>> ggf. gesetzten hostnamen mit. An dem kann der Server ihn dann z.b.
>>> auch identifizieren falls er einen fixed-address eintrag hat.
>>
>> Ja, könnte er. Gängig ist dass der DHCP-Server dann ein DNSUPDATE
>> macht.
>
>Bei Windows-Clients ist das m.W. eh der Default. Ab Install ist das
>Häkchen in den Netzwerk-einstellungen dafür gesetzt "Adresse in DNS
>registrieren".

Windows-Clients in einem AD sind so gut mit kryptografischen
Zertifikaten, Schlüsseln etc versorgt, die dürfen sich selbst ins DNS
eintragen und brauchen dazu keine Hilfe vom DHCP-Server.

Windows-Clients ohne AD, wo dieser Haken gesetzt ist, sind eine
Landplage, das flutet den DNS-Server mit Anfragen die er nur ablehnen
kann, weil der Client nicht authentifiziert ist.

>> Ich müsste jetzt wirklich in einen Packettrace oder in den Standard
>> gucken um zu wissen wie das heißt.
>
>Mußt nur in's log schauen. Da stehen bei mir jede menge drin. Anders
>geschrieben: DHCP ACK!

Dass das genau so geloggt wird wie es im Standard steht halte ich
nicht für gewährleistet. Aber es stimmt, ich hab mir das in einem
Packet Trace mal angeschaut. Aktuelles tcpdump sagt nur "request" und
"reply", wenn man das genauer wissen will muss man tatsächlich
wireshark anschmeißen.

Danke für die Motivation, ich hab dabei noch andere Dinge gesehen die
für mich lehrreich waren.

>
>>>> reden müssen. Dumme Server vergeben an dieser Stelle eine ganz
>>>> neue IP-Adresse, was zusammen mit langen Leasezeiten durchaus
>>>> lästig sein kann (weil ein PXE-Boot potenziell mehrere Leases
>>>> belegen kann, und so ein /24 ist schon ziemlich schnell voll).
>
>>> Man sollte Remote Bootenden Clients generell keine Langen
>>> Lease-zeiten geben es sei denn man könnte sicherstellen das der
>>> server den client auch im gebooteten Zustand "wiedererkennt".
>
>> Das stört aber nicht, bis auf die unnötigt belegte Adresse.
>
>Deswegen meinte ich das man die leasezeit dafür kurz wählen sollte. Dann
>ist sie schneller wieder frei.

Aber dafür ist man anfälliger bei Störungen im DHCP-Server.

Was bin ich froh dass diese ganzen Überlegungen mit IPv6 nicht mehr
notwendig sind.

>> Clients mit Betriebssystem merken sich üblicherweise beim
>> Herunterfahren ihre IP-Adresse und schicken beim nächsten Boot
>> direkt ein DHCPREQUEST für ihre alte Adresse an den Server, so dass
>> der ganze Zirkus nur ablaufen muss wenn der Server erstmal NACK
>> sagt.
>
>Was bei Fixed-address anhand der MAC ja normal nicht vorkommt.

Das kommt im Wesentlichen vor wenn der Client in ein neues Netz
gewandert ist oder so lange aus war dass seine Lease expired ist UND
die Adresse inzwischen an einen anderen Client verleast wurde.

>>> Bei PXE ändert sich doch die HW-MAC nicht nach dem remote Boot
>>> oder? Man kann sie bei vielen Systemen ja per Software ändern aber
>>> warum sollte man das generell tun?
>>
>> Das macht man meistens wenn man fertig gebootet hat damit einen das
>> Net nicht wiedererkennt. In so einem Unternehmensnetz ist man
>> natürlich daran interessiert, dass einen das Netz wiedererkennt.
>
>Du meinst damit man mit der Fertig Installierten Maschine nicht gleich
>wieder die gleiche Installation neu drauf gebügelt bekommt?

Eher damit die Accesslisten greifen können. Bei der Installation ist
es üblich dass der installierte Client sich beim
Softwaredistributionssystem mit einer Erfolgsmeldung meldet und dieses
daraufhin den Listeneinetrag löscht.

>> Installer von ftp.debian.org zu booten müsste man tatsächlich mal
>> ausprobieren.
>
>... DAS wäre in der Tat mal Lustig. IMO bietet der Installer auch
>(uboot, debootstrap?) dienstmodule an für eine Installation aus der
>Ferne. Geht das nicht sogar gescripted per Antwort-datei?

Ja, natürlich geht das auch vollautomatisch.

Sowas wird aber irgendwie immer ätzend an dem Punkt wo die
Installation zuende ist. Meist möchte man dann ja noch lokal bestimmte
Dinge machen (wie z.B. ssh-Konfiguration, Puppet-Client o.ä.
installieren, hostkeys einmelden etc), und das führt sowohl bei Debian
als auch bei Red Hat zu Monster-Einzeilern.

>
>Man muß ihn halt nur erst mal gebootet bekommen und per script so weit
>das er zumindest eine (remote)shell startet um weiter zu machen - IMO
>sogar von einem dritt-host aus wenn ich mich richtig erinnere.
>
>Klingt echt kompliziert aber vermutlich braucht es nur 2 Dateien. Das
>image und ein antwort-file das dazu passt. Ist lange her das ich danach
>bei debian.org suchte aber ich bin sicher es gibt dazu was.

Lohnt sich so oder so nur wenn das hunderte von Malen pro Woche
durchgespielt wird.

Grüße
Marc

¹ das gilt nur für den als EOL bezeichneten ISC DHCP, mit dem neuen
Kea habe ich noch keine Erfahrungen
--
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402