Der D-Link DGS-1210 ist ein lüfterloser Switch (zumindest in der 24-Port Ausführung) und daher geeignet, direkt im Klassenraum aufgestellt zu werden. Ob die Performance dieses Switches ausreichend ist, sollte jeder selbst feststellen …
Als kleine Entscheidungshilfe sei folgender Screenshot hilfreich (Ping auf den Switch; Client hängt direkt über ein 2 Meter langes Kabel am Switch; keine weiteren Clients hängen daran; Pingzeiten bei allen hier vorhandenen 8 Switches ähnlich; aktuellste Firmware eingespielt…)
kurz: Lüfterlos ist er wenigstens… (wie gesagt: nur in der 24-Port-Ausführung)
Bei der Verwendung in gerouteten Netzwerken mit VLANs verhält er sich leider eher bockig, wobei dies noch untertrieben ist.
Sobald Rapid Spanning Tree aktiviert wird,reagiert der Switch erst nach 15 Sekunden (default Wert, der sich nur auf lediglich 4 Sekunden verkürzen lässt) erstmalig auf ein Ping-Paket, antwortet aber auch danach nicht regelmäßig.
Dies führt dazu, dass ein Boot über PXE nicht möglich ist, da das Timout des DHCP-Servers vor der Aktivierung des Uplinks des Switches erfolgt.
Spanning Tree in Klassenräumen zu dekativieren, um einen Switch ans Netz zu bringen, ist kategorisch abzulehnen!!!
Es gibt dennoch eine Lösung:
Die Konfiguration des Switches erlaubt es, auf Ports, an denen ein anderer Switch (= Layer3-Switch) hängt, Rapid Spanning Tree zu deaktivieren
Der entsprechende Screenshot sähe so aus:
Mit diesen Einstellungen reagiert der Switch nun sauber und flott – die Pingzeiten verändern sich allerdings nicht, was aber unerheblich ist, da ein Ping durch den Switch auf den Gateway akzeptable Werte liefert:
Zusammenfassung:
auf den Uplinks RSTP deaktivieren, und das Teil ist ganz passabel (und leise!), womit sich bei der Verkabelung von Notebookklassen viel Geld sparen lässt, da nur 1 Kabel vom Serverraum in den Klassenraum reicht!
Sowas wie *portfast* gibts auf den D-Links nicht?
–alfred
Hallo Alfred!
Auf den DGS-1210 gibt es meines Wissens nach “Portfast” leider nicht – und auch das Manual teilt nichts Diesbezügliches mit.
Der vollständigkeit Halber:
“EDGE” erscheint mir am ähnlichsten zu “BPDU Guard” und Portfast.
Das Manual von D-Link meint hier
“Edge ports cannot create loops. However, an edge port can lose edge port status if a topology change creates a potential for a loop. An edge port normally should not receive BPDU packets. If a BPDU packet is received, it automatically loses edge port status.”
Falls Du diese Informationen verstehst, wäre ich Dir für eine Erklärung dankbar. Mir verschließt sich der Sinn dieser Konfiguration, da der Port lediglich seinen Status ändert, aber nicht deaktiviert wird…
Das von mir beschriebene Problem hat die Ursache allerdings darin, dass der D-Link “zu langsam” mit dem nächstgelegenen Switch/Router kommuniziert, wenn STP aktiviert ist…
Die von mir getesteten Betriebssysteme sind hier toleranter, ein Boot via PXE wird aber rascher abgehandelt und daher kommt es hier zu einem Timeout, bevor der D-Link mit seinen “Nachbarn” die Verhandlungen zu Ende geführt hat
In Ermangelung von “Portfast” bleibt imho also nur, diese “UPLINKS” um STP zu erleichtern. Da auf die Verkabelung zwischen den Switches / Routern die Endbenutzer keinen Zugriff haben, erscheint mir dies ein kalkulierbares Risiko.
Auf Ports, an denen Clients hängen, MUSS STP natürlich aktiviert bleiben…
In diesem Sinne
Danke für Deinen Hinweis
lg
Edi
Es gibt eine bessere Konfigurationsmöglichkeit.
Aber zuerst einmal zu der Frage nach den EDGE-ports von Edi:
Das Spanning-Tree-Protocol ist eigentlich für die Verbindungen zwischen den Switchen gedacht, insbesondere für solche Netze, die sich nur selten ändern. Jedesmal, wenn ein neues Gerät eingebunden wird, kommunizieren alle angeschlosenen Geräte miteinander, um festzustellen, wer ab jetzt die Root-Bridge ist, die den Spanning-Tree steuert. Dies dauert je nach Netzgröße zwischen wenigen Sekunden und ein paar Minuten.
(Meine Erfahrung mit 25 D-link DGS1210-24 und 5 Cisco-Switchen ist ca 40-50 Sekunden, bis ein Port, an den ein neues Gerät angeschlossen ist, freigegeben wird.)
Diese Zeit kann man Verkürzen, wenn man dem STP mitteilt, dass ein angeschlossenes Gerät kein weiterer Verteiler, sondern ein Endgerät ist. Ein solcher Port wird dann EDGE-Port genannt.
Dieser Port wird dann nicht mehr benutzt, um Informationen zum Aufbau des Sapanning-Tree zu übertragen. Die Einstellmöglichkeiten hier sind TRUE, FALSE und AUTO.
TRUE bedeutet dieser Port ist ein EDGE-Port, hier kann kein Loop entstehen, also wird er vom STP ausgenommen.
FALSE bedeutet, dieser Port ist mit einem anderen Switch verbunden, es könnte evtl ein Loop entstehen, also wird er im STP berücksichtigt.
AUTO bedeutet, der Port wird solange als EDGE-Port angesehen, bis über diesen Port ein BPDU-Paket reinkommt. Ein BPDU-Paket bedeutet in diesem Fall, dass dort ein anderer Switch angeschlossen ist. Sobald also ein BPDU-Paket erkannt wird, verliert der Port seinen EDGE-Status und wird wieder im STP berücksichtigt.
Das Problem, was hier auftaucht ist, dass an einem EDGE-Port sehr wohl ein Loop entstehen könnte, dies aber vom Switch nicht erkannt wird… von Schülern dagegen schon
Die Lösung nennt sich Loopback-Detection (Beim DGS-1210-24 Rev. A1 zwei Punkte oberhalb vom STP, bei Rev. D1 der dritte Punkt unter L2 Functions).
Nach meiner Erfahrung funktioniert ein Intervall von 2-5 Sekunden und eine Recovery-Time von 60-120 Sekunden sehr gut. Längere Intervalle haben bei unseren Core-Switchen die Sturmkontrolle ausgelöst, so dass diese ihre Ports abgeschaltet haben.
Ist die Loopback-Detection aktiviert, benötigt man das STP an den EDGE-Ports nicht mehr, man kann (und sollte) es dort deaktivieren. Damit sind neue Geräte ohne Wartezeiten im Netz, PXE-Boot funktioniert wieder und Loops werden trotzdem zuverlässig erkannt und unterbunden.
Viele Grüße,
Carsten