Hallo Frithjof, "geht laaangsam weiter" kann ich bestätigen.
Die Einstellung ICMP-Snooping auf einem Switch, die dafür sorgt, dass diese Pakete nur an die Multicast-Zieladressen gehen, funktioniert lt. Dataport nur auf einem einzelnen Switch. Auf einem verbundenen Switch wird ein Broadcast daraus, und das ist schlecht für allen anderen Datenverkehr. Hierfür braucht man einen Multicast-Router. Das hat etwas mit einem Eintrag 224.*.*.* in der Routing-Tabelle zu tun, den man - habe ich gerade von Time for Kids zurückgemeldet bekommen habe - nicht auf dem Schulrouter (und nicht auf ipfire?) machen kann. Ich hatte mal so etwas auf unserem FOG-Server eingetragen, weil Multicast in dieser Umgebung zuerst gar nicht lief. Genaue Zeile "route add ..." z. B. in /etc/rc.local von linuxmuster liefere ich nach, wenn ich selbst getestet habe. Gruß Jürgen Am 09.11.2015 um 15:15 schrieb Frithjof Hammer: >> Wecke ich einen ganzen PC-Raum (30 PCs) per linbo-remote auf, dann >> bekommen die ersten ihre IP und starten durch. Die letzten (3-5 ?) >> bleiben in der grünen Linbo-Maske zunächst hängen. > Ich kenne dieses Phänomen auch. Der Grüne Linbo-Schirm besagt, dass > gerade der tftp-Dateitransfer im Gange ist. TFTP reagiert besonders > empfindlich auf steigende Latenz (Ping-Zeiten). Hier ein paar Beispiele > für Linbo-Bootzeiten via TFTP: > > geswitchtes, unbelastetes Lan: ~ 5s > hinter einer 5GHZ Wlan-Bridge, unbelastet: ~20-30s > openVPN-Tunnel via vdsl: 5-10 Minuten > > Ich vermute also, das die Latenz durch deinen vollen Switch ansteigt. > Der Transfer bleibt dabei nicht hängen, sondern geht stetig weiter - nur > eben sehr langsam. > > Gruß > Frithjof > _______________________________________________ > linuxmuster-user mailing list > [email protected] > https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user > _______________________________________________ linuxmuster-user mailing list [email protected] https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
