Netzwerken mit Comfort-Features / clockwork braucht neues Spielzeug

TL;DR: TP-Links Cluster-Switch-Feature und GVRP-Implementation sind ein schlechter Witz.

Wenn man eine heterogene Landschaft an Netzwerk-Hardware betreuen darf, verlässt einen schnell die Lust.
Jedes Gerät will anders angesprochen und verwaltet werden:
Hier mal per telnet, da per ssh, woanders per Webfrontend, dieses per serieller Konsole oder am Ende gar per binärblob Windohv-Proprietär-Software (*schauder*).

Natürlich gibt es oft die Möglichkeit auch per SNMP Anpassungen durchzuführen, aber auch hier braut jeder Vendor wieder sein eigenes Süppchen.

Die Über-Super-eierlegende-Wollmilchsau-Ich-Konfiguriere-Dir-Alles-unter-einem-Hut-Lösung gibt es nicht und auch wenn es schmerzt legt es doch eine  mögliche Lösung nahe: Binde dich an einen Vendor, welcher die gewünschten Features mitbringt.

Wer einmal Ciscos VTP- und Stack-/Cluster-Features benutzt, viele VLANs und Switchports zu betreuen hat möchte diese und andere nicht mehr missen.
Mir und anderen befragten Admins zumindest geht es so.

Auch bei anderen vergleichbaren Herstellern findet man tolle Features zur zentralen Verwaltung, doch eines haben sie leider alle gemein:
Billig sind sie nicht… 🙁

Was also machen?

Nachdem mir ein Freund davon erzählt hat, dass TP-Link Switches mit dem „Cluster“-Feature komplett zentral per Webfrontend verwaltbar sein sollen, habe ich mir mal für meinen kleinen „Backbone“ daheim jeweils einen sog. „Commander“- (der Name hat ja schonmal was) und einen „Member“-Switch zugelegt.
Dabei habe ich erfreut festgestellt, dass ein TP-Link-Switch, welchen ich schon im Einsatz habe auch als „Member“-Switch fungieren kann.

Also Test-Aufbau mit folgenden Geräten:
TL-SG5428 als Commander
TL-SG3216 als Member
TL-SG3210 als Member

Die initiale Konfiguration des Commanders läuft wie gewohnt. IP-Adresse, VLANs, LLDP, GVRP, bliblablubb. Interessant sind dann die Cluster-Settings:
Hier bedarf es eines eigenen Subnetzes für die Switches im Cluster. Der Commander verteilt dann IPs aus diesem Netz an die Member-Switches.
Gefällt mir zwar nicht wirklich, dass der Commander hier pseudo DHCP spielt, aber sei es drum.

Nachdem dieser jetzt konfiguriert ist, mag man auf die tolle Idee kommen, dass es ja eventuell klappen könnte (sinnvoll^tm wäre), dass wenn man jetzt einen jungfräulichen Switch verbindet und bootet, dieser automagisch eine Pool-IP bekommt und ootb konfiguriert wird/werden kann.
Ein Blick in die Anleitung und der trotzdem hoffnungsvoll ausgeführte Versuch lassen einen aber gleich wieder stutzig werden.
Auch die Member-Switches müssen erst per Hand angefasst und komplett eingerichtet werden m(
Erst nachdem dies geschehen ist, kann man diese verbinden und das wirklich einzige, was anschließend von selbst funktioniert ist das hinzufügen zum „Cluster“.

Jetzt kann man <ironie>ganz toll</ironie> auf einer Übersicht betrachten, wie der „Cluster“ hierarchisch zusammenhängt, sich einige Infos anzeigen lassen und die Switches „managen“. Dahinter verbirgt sich allerdings nur, dass der Commander das Webfrontend der anderen Switches über sich selbst weiterproxiet… m(
Das heißt: Wenn ich bei einem Switch auf „manage“ klicke, komme ich über einen lokalen Port auf der Commander-Switch-IP auf dem Webfrontend des Switches heraus. Dolle Wurst! Hier also einfach mal garnichts von zentraler Verwaltung…

Jetzt aber zu dem Feature, welches ich am wirklich brauche: GVRP, die offene Quasi-Alternative zu Ciscos VTP.
Zugegebenermaßen übertreibe ich es gerne mit Netz-Segregierung und dem entsprechend mit der Anzahl von VLANs. Das ganze hat einfach den Grund, dass ich beim Firewalling etwas paranoid bin und so einfach zentral die Zugriffe steuern und die Netz-Broadcast-Stürme eindämmen kann.
Und jetzt auf jedem Switch immer wieder jedes VLAN und jeden Port lokal zu verwalten ist einfach nur nervig.

Nachdem nun also alle Switches auch für GVRP konfiguriert sind, verteilen/lernen diese auch lustig die auf dem Commander zentral erstellten VLANs.
Sehr gut!
Doch dann das böse Erwachen: Zum einen werden hier nur die verteilten VLAN-IDs und nicht die zugehören Bezeichnungen der VLANs verteilt.
Hm… so weit, so unschön. Zum anderen, und jetzt kommt die wirkliche Facialpalmierung: Die Switches leiten zwar brav die VLANs weiter, um aber einen Port einem der per GVRP verteilten VLANs zuzuweisen muss man, haltet euch fest… das VLAN auch auf dem Switch selbst erstellen!
D.h. die Switches leiten auf den Uplink-Trunks zwar die VLANs und deren Traffic weiter, können aber selbst, wenn das VLAN nicht LOKAL angelegt wurde keine eigenen Access-Ports darauf mappen! Welch grandioses Feature! Zentrale Verwaltung der VLANs und Ports… NOT!
Lustigerweise kommt erschwerend hinzu, dass man dann um dieses VLAN auf Ports (egal ob ACCESS, TRUNK oder GENERAL) mappen zu können erst einmal das GVRP abschalten darf, da sonst beim Konfigurationsversuch ein Fehler geworfen wird… Also GVRP aus, VLAN lokal erstellen, alle gewünschten Ports mappen und GVRP wieder an. Was bei mir bei allein nur drei Switches dazu geführt hat, das ganze gleich deaktiviert zu lassen. Da ich keine Switches in Daisy-Chain geschalten habe, müssen auch keine auf dem Access-Switch nicht verwendeten VLANs durchgeschleift werden. Dolle Wurst Nr. 2!
Zugegebenermaßen ist GVRP selbst auch für nichts weiter gedacht, als die IDs zu lernen und auf die Trunks zu packen. Dennoch würde ich mir eine bessere Konfigurationsmöglichkeit im Frontend v.a. bei einem „Cluster“ erwarten. Einfach so wie: „Hey! Dieses VLAN möchte ich hier auf diesen Port legen!“ *klick* fertig. VLAN wird automatisch lokal angelegt und die Ports können gemappt werden. Wär doch immerhin mal etwas.
Würde mich ja echt mal interessieren, ob Cisco auf Funktionsweise und -prinzip von VTP Patente hat. Anders kann ich es mir langsam echt nicht mehr erklären, dass es dazu so gar keine nutzbare Alternative gibt.

Also alles in allem wird hier mit Features geworben, welche sich im Nachhinein als nichts besonderes herausstellen. Nicht mal die Features und Ports aller sich im Cluster befindlichen Switches kann man zentral verwalten.

Trotzdem kann man beim Preis-/Leistungsverhältnis nicht meckern, muss aber eben auch wissen, worauf man sich hier einlässt.
Dafür, dass man letztendlich dann doch alles händisch auf jedem einzelnen Switch konfigurieren darf, hättens auch die kleineren Varianten der Switches getan. Dann eben ohne gefaketen „Cluster“ und graphische Übersicht, aber das gibts ja notfalls mit anderen Mitteln umsonst 😉

Dafür habe ich jetzt halt einen „Commander“…