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.
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.
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.
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.
