wir verwenden Unifi-Switche als Rückgrat unserer Netzwerkstruktur. Päd. Clients hängen an Ports mit dem VLAN „LMN7 - school“.
Da wir uns noch nicht genügend Unifi-Switche leisten konnten, haben wir an manchen Ports der Unifi-Switche mit VLAN „LMN7 - school“ noch unkonfigurierte andere Switche hängen und daran dann erst die päd. Clients.
Ich diesem Fall, den ich hier schildere, hängt ein alter 3com 4800G 3CRS48G-24S-91-ME mit Kupferkabel zwischen einem Unifi-Switch (Ubiquiti UniFi Switch 48 - US-48-500W) und dem Client (HP Elite 8300 CMT):
Das Aufnehmen des Clients mittels LINBO läuft problemlos, wenn er an dem alten 3com-Switch hängt (der am Unifi-Switch hängt). Hängt man den Client aber direkt an einen Unifi-Switch, dann läuft er regelmäßig in folgenden Fehler:
Press [1] to reboot oder [2] to shutdown
getestet mit mehreren Clients, Netzwerkdosen, Unifi-Switchen, Ports, Netzwerkkabeln
ich kann mir zwei Sachen vorstellen:
a) kernel-optionen funktionieren nicht
b) eine Fehlkonfiguration der VLANs/Routing/o.ä. liegt vor
Ich würde mal ein Betriebssystem vom Stick booten, und prüfen ob ich wie erwartet eine IP-bekomme - und wie lange das geht.
Abhängig davon, würde ich mal prüfen, ob die Kerneloption korrekt in der start.conf steht - und die MAC-Adresse auch entsprechend passt.
P.S.: in Einzelfällen kann auch ein Firmwareupdate des Switches helfen. Manchmal bringt auch ein Blick in die Unifi-Logs Aufschluss.
Hey,
wir haben auch UniFi-Switche und hatten das selbe Problem. Ein Deaktivieren von STP auf den entsprechenden Ports hat geholfen.
Ich hatte es bemerkt, dass der PxE-Boot noch eine IP-Adresse bekommen hat, Linbo danach aber nicht mehr. Und im UniFi-Controller wurde zeitgleich eine STP-Warnung auf dem Port angezeigt.
Keine Ahnung, warum der Switch da STP erkannt hat, evtl wegen den zwei identischem DHCP-Anfragen hintereinander?
Interessant war, dass sobald ein „dummer“ Switch dazwischen war, es keine Probleme mehr gab, nur wenn die PCs/Laptops direkt am UniFi hingen…
Hm… abschließend beantworten kann ich es nicht. Haben ein paar Schulen mit Unifi-Switchen, eine hatte auch solche Probleme, alle anderen aber nicht…
Vielleicht ist irgendetwas anders konfiguriert - oder bei der einen lag es an der „Wortmann“-hardware (no front but front :-))
Die Lenovo T430-Laptops konnte ich zuerst nicht aufnehmen, da sie zwar beim Booten eine IP bekamen, dann aber stoppte LINBO mit:
FATAL cannot read network infos…
[1] Reboot oder [2] Shutdown
Die Ursache des Problems konnte ich damals nicht klar eingrenzen - es ging dann wohl, als ich die T430 nicht direkt an einem Unifi-Switch angeschlossen hatte.
Mit DHCP hat das nichts zu tun. Switches mit Management-Funktion haben meistens Spanning Tree Protocol (STP) voreingestellt aktiv. Dann wird versucht 30sc lang zu ermitteln, ob eine Netzwerkschleife vorliegt und erst dann geht der Port nutzbar in Betrieb. Wem das zulange dauert, der sollte schauen, ob er das Rapid Spanning Tree Protocol (RSTP) aktivieren kann (bevorzugt) oder STP ausschalten (Nachteil: der „Schülerstreich“ mal ein TP-Kabel in die RJ45-Doppeldose zu stecken, wird nicht mehr abgefangen).
Wenn man einen „dummen“ Switch dazwischen hat, dann macht er diese Erkennung mittels (R)STP nicht und Pakete werden sofort weitergeleitet. Der Uplink vom „dummen“ Switch zum Switch mit Management-Funktion ist dann ja in der Regel dauerhaft aktiv. Da fällt dann auch nicht auf, dass evtl. nur nach einem Switchreboot mal 30sec lang noch keine Verbindung da ist.
Versuch: Neuaufnahme von PC - STP an Unifi-Switch
Beobachtung: Das Problem „Press [1] to reboot oder [2] to shutdown“ taucht auf, wenn RSTP eingeschaltet ist (was bei uns systemweite Grundeinstellung ist).
Schalte ich für den Port STP aus, so funktioniert LINBO prima.
Deutung: ???
Was heißt das jetzt für LINBO, für mein System, für… ?
Lieber Stefan,
wenn ich das richtig verstanden habe, hat das doch Buster ziemlich nice in seinem vorangehenden Beitrag erklärt - oder bleiben da Fragen offen? STP oder auch RSTP „bremsen“ den dhcp-Verkehr.
Wenn Du Dir einigermaßen sicher sein kannst, dass keine „Steckspiele“ an Switches oder Patch-Panels stattfinden (und Du nicht, wie ich einmal) eine Loop über das ver-meshte Wlan erzeugst, kann man das STP auch komplett ausschalten.
Gilt übrigens auch für die virtuellen Switches (Proxmox).
danke für den Hinweis! Leider habe ich schon öfters gesteckte Loops entfernen müssen und da wäre mir RSTP schon sehr recht.
Ich hätte gerne ein System, dass RSTP und ein funktionierendes LINBO hat.
Sehe ich es richtig, dass, wenn LINBO sich mehr Zeit nehmen würde, dass man dann nicht in den Fehler laufen würde? Kann man da vielleicht für die Rechneraufnahme den Zeitraum bis zum Abbruch irgendwo einstellen?
ich nehme die Rechner anders auf: Ich trage deren MAC in die meist schon bestehende start.conf.irgendwas ein und nutze bei dieser start.conf den sowieso hohen dcpretry-Wert. Das geht viel g’schwind’r, finde ich. Die MAC finde ich entweder am Rechner oder sie steht im BIOS oder ich boote halt in Gottes Namen einmal ein LinuxMint vom Stick, dann ifconfig oder ip a.
Danke für die Beschreibung Deiner Arbeitsweise - so habe ich das früher auch gemacht. Jetzt arbeite ich viel mit Lernenden bei der Rechneraufnahme, weil ich eine Arbeitsgemeinschaft habe und die AG sich v.a. um die Geräte in der Schule kümmert.
Da nehmen mir die Lernenden einiges ab - z.B. die MACs in eine Textdatei schreiben.
Und dafür wäre es schon gut, wenn ich das Standardverfahren von LINBO nutzen könnte, wo die MAC ja ohne Benutzerinteraktion angezeigt wird.
Das Problem trat bei uns aber auch bei RTSP auf. Und das DHCP beim PXE funktioniert ja. Erst das zweite mal DHCP wenn Limbo startet funktioniert dann nicht mehr.
ah, das macht natürlich Sinn, danke für die Erklärung
