Stell dir vor, es ist Montagmorgen um drei Uhr. Du stehst in einem eiskalten Rechenzentrum oder sitzt per Remote-Konsole vor einem leeren Bildschirm, der seit zwei Stunden nur einen blinkenden Cursor zeigt. Der Plan war simpel: Zweihundert neue Server vollautomatisch aufsetzen. Stattdessen hängen die ersten zehn Maschinen in einer Endlosschleife fest, weil die Kombination aus PXE Boot and FTP Clients nicht so funktioniert, wie es im Lehrbuch steht. Ich habe dieses Szenario oft erlebt. Meistens liegt es daran, dass jemand dachte, ein alter FTP-Server auf einer ausrangierten Workstation würde für den Rollout ausreichen. Das Ergebnis? Ein korruptes Image nach dem anderen, Timeouts im BIOS und ein Team, das Überstunden schiebt, um den Schaden zu begrenzen. Ein solcher Fehler kostet ein mittelständisches Unternehmen schnell mehrere tausend Euro an Arbeitszeit und entgangener Produktivität, nur weil die Grundlagen der Netzwerkübertragung falsch eingeschätzt wurden.
Die Illusion der Einfachheit bei PXE Boot and FTP Clients
Der größte Fehler, den ich immer wieder sehe, ist der Glaube, dass FTP das ideale Protokoll für das Booten im Netzwerk sei. Viele Administratoren greifen dazu, weil sie FTP kennen und schätzen. Sie vergessen dabei, dass der Preboot Execution Environment Standard ursprünglich auf TFTP ausgelegt war. Wenn du versuchst, moderne PXE Boot and FTP Clients in eine Umgebung zu pressen, die nicht für die Eigenheiten von FTP-Verbindungen im frühen Bootstadium optimiert ist, handelst du dir Ärger ein. FTP benötigt zwei Ports — einen für Befehle und einen für Daten. In einer Phase, in der der Netzwerkstack des Rechners nur rudimentär vorhanden ist, führt das oft zu Timeouts.
Ich habe Projekte gesehen, bei denen Techniker Tage damit verbracht haben, Firewall-Regeln anzupassen, nur um festzustellen, dass der FTP-Client im Bootloader überhaupt kein passives FTP unterstützt. Wer hier ohne Testphase in die Vollen geht, riskiert, dass die gesamte Bereitstellungskette reißt. Es ist kein theoretisches Problem; es ist ein handfester technischer Konflikt zwischen einem Protokoll aus den 70ern und moderner Hardware-Initialisierung.
Das Problem mit der MTU und die vergebliche Fehlersuche
Ein weiterer Punkt, der regelmäßig für graue Haare sorgt, ist die Maximum Transmission Unit. In einer Standard-Ethernet-Umgebung liegt diese bei 1500 Bytes. Sobald du aber über VLANs, VPNs oder komplexe Switch-Strukturen bootest, schrumpft der nutzbare Platz für Datenpakete. Wenn dieser Prozess nicht exakt abgestimmt ist, bricht die FTP-Übertragung mittendrin ab. Der Rechner meldet einen kryptischen Fehlercode, und du suchst den Fehler stundenlang in der Konfiguration des FTP-Servers, während das Problem eigentlich auf Layer 2 deines Netzwerks liegt.
In meiner Laufbahn war es oft so, dass die Pakete schlicht zu groß für die Zwischenstationen waren. Ein FTP-Client im PXE-Stadium ist nicht so intelligent wie ein modernes Betriebssystem. Er kann Pakete nicht einfach fragmentieren und wieder zusammensetzen, wenn die Hardwareunterstützung fehlt. Wenn du also versuchst, ein 4 GB großes Image über eine Leitung zu schieben, die irgendwo ein Nadelöhr hat, wird der Bootvorgang scheitern. Das ist kein „Vielleicht“, das ist eine Gewissheit.
Warum statische IP-Adressen im Boot-Prozess Gift sind
Oft versuchen Leute, Fehler zu umgehen, indem sie den PXE-Clients statische IP-Adressen verpassen wollen. Das klingt logisch: „Dann wissen wir wenigstens, wer wer ist.“ In der Realität ist das der direkte Weg ins Chaos. PXE basiert fundamental auf DHCP. Wer versucht, diesen Mechanismus zu verbiegen, um FTP-Verbindungen stabiler zu machen, baut sich eine Wartungsfalle.
Ich erinnere mich an einen Fall, bei dem ein Admin für jedes der 500 Geräte eine Reservierung im FTP-Server manuell hinterlegt hat. Als der Switch getauscht wurde und sich die Latenzen minimal änderten, griffen die Timeouts der Clients, bevor die Authentifizierung am FTP abgeschlossen war. Die Lösung ist niemals mehr manuelle Konfiguration, sondern ein sauberer DHCP-Handshake, der dem Client alle nötigen Optionen direkt mitgibt. Wer hier pfuscht, verliert später Wochen bei der Fehlersuche, wenn nur ein kleiner Teil der Infrastruktur aktualisiert wird.
Die Falle der anonymen Logins
Ein technisches Detail, das oft unterschätzt wird, ist die Sicherheit. Viele setzen auf anonyme FTP-Zugänge, damit die PXE-Clients keine Zugangsdaten benötigen. Das ist zwar bequem, führt aber in Firmennetzen oft dazu, dass Sicherheitssoftware die Verbindung kappt oder der FTP-Server bei zu vielen gleichzeitigen anonymen Zugriffen dichtmacht. Wer denkt, dass 50 gleichzeitige Boot-Vorgänge „schon irgendwie klappen“, wird von den Standardlimits der meisten FTP-Dienste eines Besseren belehrt. Es geht hier nicht nur um Sicherheit, sondern um die schiere Verfügbarkeit des Dienstes unter Last.
Vorher und Nachher: Ein Rollout-Szenario aus der Praxis
Schauen wir uns an, wie sich ein falscher Ansatz im Vergleich zu einer durchdachten Strategie auswirkt. Nehmen wir an, ein Unternehmen möchte 100 Workstations in einer neuen Niederlassung ausrollen.
Im schlechten Szenario hat der verantwortliche Techniker einen Standard-PC als FTP-Server aufgesetzt. Er verwendet das Standard-PXE-Menü und hat keine Anpassungen an den Blockgrößen vorgenommen. Am Tag des Rollouts starten alle 100 Rechner gleichzeitig. Der FTP-Server ist sofort überlastet, da er für jeden Client einen eigenen Prozess startet. Die Festplatte des Servers kommt mit den gleichzeitigen Lesezugriffen nicht hinterher. Nach 20 Minuten haben nur drei Rechner das Image geladen, bei 40 ist der Bootvorgang mit einem Timeout abgebrochen, und der Rest hängt in einer Warteschleife. Der Techniker muss nun jeden Rechner einzeln neu starten und hoffen, dass er einen Slot erwischt. Das dauert insgesamt 14 Stunden.
Im guten Szenario wurde die Umgebung vorher getestet. Der Techniker weiß, dass FTP für große Mengen an gleichzeitigen Zugriffen ohne Optimierung ungeeignet ist. Er hat den FTP-Server so konfiguriert, dass die Anzahl der Verbindungen pro IP limitiert ist und der Datendurchsatz gedrosselt wird, damit die Festplatten nicht kapitulieren. Zudem wurden die Boot-Images so verkleinert, dass nur das Nötigste über das Netzwerk geht. Die 100 Rechner werden in Wellen zu je 20 Stück gestartet. Nach drei Stunden sind alle Maschinen einsatzbereit. Der Unterschied liegt nicht in der Hardware, sondern im Verständnis dafür, wie PXE Boot and FTP Clients unter Last reagieren.
Die Wahl der richtigen Server-Software entscheidet alles
Es ist ein Irrglaube, dass jeder FTP-Server gleich gut für PXE geeignet ist. Viele Open-Source-Lösungen sind für den Dateiaustausch zwischen Menschen optimiert, nicht für die automatisierte Abfrage durch minimale Clients. In meiner Praxis hat sich gezeigt, dass Server, die keine vernünftige Logging-Funktion für fehlgeschlagene Logins auf Paketebene haben, wertlos sind. Wenn der PXE-Client die Verbindung abbricht, musst du im Server-Log sehen können, ob das Paket gesendet wurde oder ob der Client gar nicht erst gefragt hat.
Viele kommerzielle Lösungen bieten zwar „PXE-Module“ an, diese sind aber oft nur aufgeblasene TFTP-Server mit einer hübschen Oberfläche. Wer wirklich professionell arbeiten will, schaut sich die RFCs der verwendeten Protokolle an und gleicht sie mit den Fähigkeiten der Netzwerkkarte des Zielsystems ab. Es bringt nichts, einen High-End-FTP-Server zu haben, wenn die On-Board-NIC des Servers nur einen veralteten PXE-Stack von 2015 besitzt.
Hardware-Inkompatibilitäten und die bittere Wahrheit
Ein Punkt, der in keinem Handbuch steht: Manche Netzwerkkarten mögen FTP einfach nicht. Ich habe es erlebt, dass bestimmte Chipsätze bei der Initialisierung des FTP-Handshakes reproduzierbar abstürzen. Da hilft kein Update und keine Konfigurationsänderung. In solchen Fällen ist der Versuch, PXE über FTP zu erzwingen, reine Zeitverschwendung.
Wenn du merkst, dass eine bestimmte Hardware-Revision immer wieder aussteigt, hör auf zu suchen. Nutze HTTP oder bleib bei TFTP für die erste Stufe und lade das große Image später nach, wenn ein echtes Betriebssystem mit echten Treibern läuft. Sturheit bei der Protokollwahl ist einer der teuersten Fehler in der IT-Infrastruktur. Es geht darum, das System zum Laufen zu bringen, nicht darum, eine bestimmte Technologie zu beweisen.
Realitätscheck
Machen wir uns nichts vor: Ein perfekt funktionierendes System für das Booten über das Netzwerk aufzubauen, ist kein Wochenendprojekt. Es ist mühsame Kleinarbeit. Wenn du glaubst, du kannst eine Anleitung aus einem Forum kopieren und damit eine produktive Umgebung steuern, wirst du scheitern. Die Realität in modernen Netzwerken mit Micro-Segmentierung, komplexen Firewalls und verschiedenen Hardware-Generationen ist grausam zu jedem, der nicht bereit ist, jedes Paket einzeln zu analysieren.
Es braucht Geduld, ein ordentliches Oszilloskop für den Netzwerkverkehr (wie Wireshark) und die Bereitschaft, das eigene Konzept dreimal umzuwerfen, bevor es stabil läuft. Wenn du nicht bereit bist, dich mit den Details von TCP-Fenstern, DHCP-Optionen und Boot-Latenzen auseinanderzusetzen, solltest du die Finger davon lassen. Ein unzuverlässiges PXE-System ist schlimmer als gar keines, weil es eine Sicherheit suggeriert, die beim ersten echten Lasttest in sich zusammenbricht. Wer Erfolg haben will, muss die Theorie hinter sich lassen und lernen, wie die Hardware unter Stress wirklich reagiert. Es gibt keine Abkürzung, nur Erfahrung und eine Menge kaputter Boot-Vorgänge, aus denen man lernt.
