Hi, mich würde interessieren, in welchen Bereichen sich Ethernet-Switches (managed, Layer2) diverser Hersteller von einander unterscheiden. Dabei geht es mir nicht um die Anzahl der Ports oder ähnlichem; sondern um die berühmtberüchtigten Kleinigkeiten, die einem nicht so schnell auffallen beim Durchlesen der Spezifikationen. Oder auch um Features, die ihr zum Beispiel bei euren Layer2 Switches vermisst. Kriterien, die ich bereits erarbeitet habe: - mit / oder ohne Lüfter - Expansion-Port - Kabeltest-Funktion Gruß Lars
Stromaufnahme. Nicht unwichtig bei Betrieb zu Hause, denn so ein Switch gehört naturgemäß zu den Dauerverbrauchern. Implizit daraus ergibt sich das Kühlungsthema; der 8-Port-GBe-Switch, der bei mir zu Hause hängt, hat natürlich kein Kühlgebläse und braucht deutlich unter 10 Watt.
Hier noch ein paar Dinge: http://www.juniper.net/us/en/products-services/switching/ex-series/#features-benefits
Rufus Τ. Firefly schrieb: > Stromaufnahme stimmt, die spielt auf jeden Fall eine tragende Rolle. Hab noch festgestellt, dass manche Switches noch ein Synchronization-protokoll wie das 1588 oder Sync-E aufweisen.
Angesichts der Unmengen an Features, die sich bei solchen Switches teilweise ansammeln, ist das viel verlangt. Insbesondere, wenn man nicht weiss, in welchem Umfeld du sie einzusetzen gedenkst. Vergleichsweise simple Sachen wie Spanning-Tree sind nicht bei allen gemanagten L2-Switches zu finden, beispielsweise nicht bei den einfacheren Typen von HP. Wichtig ist für mich die Möglichkeit, die Konfiguration sichern und wiederherstellen zu können. Vorzugsweise per Textfile statt binär um ggf. Anpassung vornehmen zu können. Selbst wenn es das gibt, dann gibt es dennoch manchmal Probleme beim Einlesen dieser Konfigurationsfiles, die sind mal leicht unvollständig (HP) oder liefern Fehler aufgrund von falscher Reihenfolge (Enterasys). In einer grösseren Umgebung kann dann auch eine automatische Sicherung der Konfiguration via Netz nützlich sein (bei Cisco machen das die Switches ggf. selbst). In komplexer Umgebung hilfreich: Debugging-Möglichkeiten im Switch.
Auf Wikipedia finden sich auch noch einige Kenngrössen: http://de.wikipedia.org/w/index.php?title=Switch_(Computertechnik)§ion=9#Kenngr.C3.B6.C3.9Fen
A. K. schrieb: > Angesichts der Unmengen an Features, die sich bei solchen Switches > teilweise ansammeln, ist das viel verlangt. Insbesondere, wenn man nicht > weiss, in welchem Umfeld du sie einzusetzen gedenkst. Die Einsatzgebiete können durchaus sehr unterschiedlich sein. Angefangen von einem kleinen einfachen Netzwerk - bestehend aus ein paar Netzwerk-teilnehmern -, welches sich auf einen Raum beschränkt, möchte ich auch größere Netzwerke einbeziehen, bei denen z. B. einzelne Neztwerkteilnehmer (Switches) per Glasfaser (ein paar Kilometer) verbunden sind. Jedoch sind alle Netzwerke lokal und nicht mit dem Internet verbunden. Maximal das ein VLAN für das Internet gesponsert wird. Spanning Tree ist ein sehr wichtiges Feature und gehört bei mir zur Grundausstattung. Ebenso die Möglichkeit, dass man die Konfiguration des Switches speichern / laden kann. Aber genau darum geht es mir, zu finden welche Features andere User (in anderen Einsatzgebieten) noch als wichtig erachten; da man selbst häufig das ein oder andere Detail vergisst und vielleicht auch gar nicht kennt. Gerade auch die Software-Features der unterschiedlichen Switches, da man in diesem Punkt als Hersteller doch noch einiges reißen kann, oder?
A. K. schrieb: > In einer grösseren Umgebung kann dann > auch eine automatische Sicherung der Konfiguration via Netz nützlich > sein (bei Cisco machen das die Switches ggf. selbst). das klingt widerum sehr interessant. Die Konfig-Files von einem Server zu beziehen. A. K. schrieb: > In komplexer Umgebung hilfreich: Debugging-Möglichkeiten im Switch. Welche Debug-Möglichkeiten sprichst du hier genau an? Bzw. in welcher Situation / bei welchem Problem hat sie dir schon einmal weitergeholfen? Und in welcher Form kann auf die Debug-Informationen zugegriffen werden - nur über den RS232 Port oder im Webinterface integriert? Gibt es hier auch die Möglichkeit auf die angezeigten Debug-Infos Einfluss zu nehmen - z. B. was alles angezeigt werden soll oder kann?
Lars schrieb: > das klingt widerum sehr interessant. Die Konfig-Files von einem Server > zu beziehen. Ich meinte das eher andersrum, d.h. die Switches schreiben das Konfigurationsfile automatisch ohne mnuelles Zutun auf einen Server (z.B. FTP). Bei Ersatz kann man das File dann auf gleichem Weg nach Minimalkonfiguration um ins Netz zu kommen wieder einspielen. Das geht beispielsweise bei Ciscos mit IOS. Ob die andere Richtung auch geht, also Konfiguration per DHCP/BOOTP/TFTP&Co, habe ich nicht untersucht, > Welche Debug-Möglichkeiten sprichst du hier genau an? Je mehr Features ein Switch hat, desto mehr fragt man sich, warum eine doch scheinbar völlig saubere Konfiguration nicht tut. Da kann es sinnvoll sein, sich die Sicht des Switches per Trace anzeigen zu lassen. Das ist seit jeher eine der Stärken der Cisco-Devices mit IOS. > Situation / bei welchem Problem hat sie dir schon einmal weitergeholfen? Noch nicht bei LAN-Switches, weil die Fälle, bei denen ich es gebraucht hätten, kein Debugging boten. Im Bereich von Routing und WAN-Switches freilich schon öfter. > Und in welcher Form kann auf die Debug-Informationen zugegriffen werden > - nur über den RS232 Port oder im Webinterface integriert? Konsole auch, aber ebenso Konsole per Telnet/SSH. > Gibt es hier > auch die Möglichkeit auf die angezeigten Debug-Infos Einfluss zu nehmen > - z. B. was alles angezeigt werden soll oder kann? Natürlich muss das detailliert ausgewählt werden. Man kriegt nur endlich viel über solche Text-Traces rüber.
Eine Feature, die ich bei den besseren Switches von HP recht angenehm finde: Die Einstiegsseite vom Webinterface liefert direkt eine heuristische Fehlerananalyse. Man bekommt damit sofort nach dem Login auf die Seiten angezeigt, dass etwas mit dem Port XY evtl. nicht stimmt, auch ohne dass man umständlich die Error-Counter abgrasen muss.
Lars schrieb: > Welche Debug-Möglichkeiten sprichst du hier genau an? Ein Beispiel für einen Fall, wo Debugging um Switch hilfreich sein kann: Dein Spanning-Tree ist verkorkst und du kapierst nicht weshalb. Wenn der Switch seine betreffenden BPDU/Port-Aktivitäten gut lesbar protokolliert, dann kann das ziemlich helfen.
Lars schrieb: > - mit / oder ohne Lüfter > - Expansion-Port > - Kabeltest-Funktion - (Rapid) Spanning Tree - VLANs - IGMP V2 - IGMP V3 - SNMP - Serielle Konsole - Portstatisken (Fehlerrate etc.) - Spiegelports
VLAN, Trunking, jumbo frames (wichtiges thema!), möglichkeit für LWL Einschübe, GBIC, Statistik über VLANs oder den gesamten Verkehr, Fehlerdiagnose, Breitbandbeschränkung (insb. in größeren Netzten) Lüfter, eventuell redulantes Netzteil Konfig. speichern, alte Konfig wiederherstellen usw
Es kommt immer darauf an, wo der Switch eingesetzt wird. Muss ich z.B an einem Officearbeitsplatz mehr Anschlüsse zu Verfügung stellen als die Gebäudeseitige Verkabelung zulässt, ist das Killerkriterium die passive Kühlung, allenfalls Stromversorgung des Switch selbst über PoE. In grösseren Netzwerken sind dann im Edge Bereich eher Sachen wie 802.1x Portauthentifizierung, VLAN, Spanningtree, Etherchannel, PoE, DHCP Spoofing, ARP Spoofing, Ports pro HE, etc gefragt. Im Core Bereich eher Layer 3, mindestens starisches Routing, VRRP, redundante Netzteile, Spanningtree, VLAN, einfache ACLs IP und Pritokollbasiert, Modularität für verschiedene Medientypen, Switch Stacking, non blocking Backplane etc. Im Storage Bereich sind FlowControl, Jumbo Frames, VLAN unverzichtbare Features. Du Siehst, DEN Switch gibt es nicht. Kommt immer auf den Einsatzbereich und die zusätzlich benötigten Features an. So ist es beinahe unmöglich, eine sinnvolle Produkteempfehlung abzugeben. So SchikiMiki Dinger wie Webinterface brauche ich nicht. Das einzige Interface welches ich nutze ist die Console über SSH :-) Ich muss zugeben, dass zwischen "meinen" Netzwerken und den HomeNetzwerken mit ein Paar PCs und dem ganzen Multimediagedöns Welten liegen - auch Preislich.
Vielen Dank für eure Antworten. Das bei den meisten Switches ein Console-Port existiert, welcher als RJ45 Buchse ausgeführt ist, ist nur der Tatsache geschuldet, dass dieser Port weniger Platz wegnimmt als ne RS232 Buchse? Weil was mich prinzipiell daran stört ist, dass man im Normalfall kein solches Kabel (RJ45 auf RS232) mit dabei hat...
Lars schrieb: > prinzipiell daran stört ist, dass man im Normalfall kein solches Kabel > (RJ45 auf RS232) mit dabei hat... Gehst du mit Switches auf Wanderschaft? Es gibt sowohl Geräte mit RJ45 als auch welche mit 9-Pol Konsole. Und nicht alle sind so knauserig wie Cisco, sondern liefern zu jedem Gerät ein Kabel mit.
Arduino schrieb: > So SchikiMiki Dinger wie Webinterface brauche ich nicht. Das einzige > Interface welches ich nutze ist die Console über SSH :-) Verwendet ihr auch das SNMP Protokoll?
Lars schrieb: >> So SchikiMiki Dinger wie Webinterface brauche ich nicht. Das einzige >> Interface welches ich nutze ist die Console über SSH :-) > > Verwendet ihr auch das SNMP Protokoll? Klar, aber für Konfiguration ist das eher unpraktisch.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.