Neue IT-Infrastruktur als Leaf Spine mit Netgear?

[Maphi]

Hallo an alle ich bin neu hier im Forum und komme gleich mal zum Thema:

Wir strukturieren unser Netzwerk in eine Spine-Leaf Architektur um - als Spine wollen wir 2 Core Switche redundant verwenden und als Leaf 13 Access Switche. Geplant ist, die Core Switche über VRRP redundant zu verbinden. Weil unser Budget begrenz ist, mussten wir in die Netgear Serien gehen, wir haben geplant als:

Core: 2 Netgear M4300-24X24F
Access: 13 Netgear M4300-28g PoE+ ODER 13 Netgear GS728TXP

Die Access Switche sind auf 10 Racks aufgeteilt. Die Verbindung der Access zu den Core-Switchen soll über SFP+ Module (10 GBit) erfolgen, also je eine LWL Strecke zu einem Core Switch. Die Server stehen in einem separatem Raum und sind getrennt von den Core Switchen. Generell haben wir ca. 50 Clients, diverse Endgeräte wie Drucker usw, ca 50 VoIP Telefone, 12 virtuelle Server und 4 Storage. Im Prinzip läuft wenig "harter Traffic" durch die Leitung, sodass wir keine High End Geräte brauchen, die höchstmögliche Switching Kapazitäten haben.

Geplant sind diverse vLANs z. B. getrennt nach Etagen, VoIP, Gast-vLAN, Server-vLAN (ca. 5 vLANs werden es wohl werden).

Bei der Planung bin ich mir nun nicht sicher, ob mir der Layer 3 M4300-24X24F als Core genügt, da dieser ja das gesamte Routing übernehmen soll. Durch eine Redundanz über VRRP ist der zweite ja nur im Standby und routet oder switcht so nicht aktiv. Genügen mir dann im Access Bereich Layer 2 Switche, weil der Core das Routing übernimmt oder ist es Sinnvoll im Rack wo Server+Storage stehen auf Layer 3 zu gehen und nur wo "dumme Endgeräte" stehen Layer 2 einzusetzen?

Wenn ich Infos vergessen habe, bitte kurz kurz Bescheid geben.

Hier ein Leaf Spine Beispiel - so wird es bei uns umgesetzt, nur eben mit 2 Cores.

Viele Grüße

Maphi

[pcpeasant]

Ich glaube du verrennst dich gerade in eine Topologie von der Du zu wenig Ahnung hast. Es bringt nichts so eine Architektur zu bauen ohne den Gedanken dahinter zu verstehen. So wie du es schilderst (mit VRRP) generiert es nicht den Vorteil den es sollte.

Leaf Spine Netzwerke sollten statt auf STP auf ein ECMP Protokoll wie TRILL oder SPB setzen, um die volle Bandbreite und Redundanz nutzen zu können. Ich schätze einfach Mal, das die netgears das nicht können.

Ist so als würdest du den Bauplan von einem Ferrari nehmen und diesen mit Alufolie nachbauen wollen und dann sagen "ja, ich brauche eh nicht viel PS im Alltag".

Aus meiner subjektiven Sicht (die sich aus den begrenzen Daten ergibt die du lieferst) ist euer Plan falsch. Ich wähle hier explizit den Begriff "falsch" und nicht nur "unpassend".

Ein Buttermesser ist ein unpassendes Besteck zum Schneiden eines Steak. Eine Kuchengabel ist definitiv das falsche Besteck zum Schneiden von so ziemlich allem (außer Kuchen)

Gesendet von meinem SM-N910F mit Tapatalk

[Crash2001]

Ich verstehe ehrlich gesagt nicht ganz den Sinn dahinter bei der Größe des Netzwerkes auf Leaf & Spine zu gehen.

Bei großen Netzwerken macht Leaf & Spine Sinn, um die Anzahl der Hops zu reduzieren, die zwischen zwei Stellen gemacht werden müssen. In deinem Fall ist aber doch die maximale Hop-Anzahl eh nur 2. Eine Reduzierung auf 1 macht also nicht sooo viel Sinn, da es keinen großartigen Performancegewinn mit sich bringt im Vergleich zum klassischen Ebenen Modell (in deinem Fall mit Collapsed Core und Access Layer). Vor allem nicht, wenn der Core sowieso nicht großartig ausgelastet ist mit dem Traffic. Die Trafficmenge ist ja anscheinend auch nicht wirklich hoch, so dass die Anbindung an den Core auch nicht der Flaschenhals ist.

Würde man hier also entweder einen Stack als Core einsetzen, oder aber z.B. ein VSS-System, hätte man selbst die Anzahl der Hops auf 1 reduziert, die doppelte Anbindungsgeschwindigkeit und somit in meinen Augen keinerlei Vorteil mehr für ein Leaf & Spine Netzwerk gegenüber dem klassischen Aufbau.

 

Ob im Serverrack Layer 3 Switche Sinn machen, kann man so generalisiert nicht sagen. Das hängt auch unter anderem davon ab, ob im Datacenter mehrere vlans zur Anwendung kommen, zwischen denen geroutet werden muss, oder ob alles über das selbe vlan läuft, oder aber erst zum User hin dann geroutet werden muss.
Schaut man sich den Aufbau an, dann geht es ja so oder so über den Core-Switch. Somit hätte man also nur bei direktem Routing zwischen zwei Server-Netzen einen Vorteil. Solange das nicht so häufig vorkommt, würde ich auch dort nur L2-Switche einsetzen. Wenn L3-Switche, dann mit der Performance der Core-Switche, da es sonst keinen Sinn macht.

Bearbeitet 31. Januar 2017 von Crash2001

[Maphi]

vor 14 Stunden schrieb V1RTU4L:

Ich glaube du verrennst dich gerade in eine Topologie von der Du zu wenig Ahnung hast. Es bringt nichts so eine Architektur zu bauen ohne den Gedanken dahinter zu verstehen. So wie du es schilderst (mit VRRP) generiert es nicht den Vorteil den es sollte.

Leaf Spine Netzwerke sollten statt auf STP auf ein ECMP Protokoll wie TRILL oder SPB setzen, um die volle Bandbreite und Redundanz nutzen zu können. Ich schätze einfach Mal, das die netgears das nicht können.
 

Von Spine-Leaf habe ich tatsächlich nicht so viel Ahnung - nur angelesen. Ich habe auch schon überlegt, bei Schränken, wo 2 Switche verbaut sind diese zu stacken und dann mit je einer Leitung zu einem Core Switch zu gehen. Die Core Switche sollen aber trotzdem via VRRP redundant werden. Ggf. werden es statt den 10 schränken auch nur 5 - je nach Aufteilung der Kabel.

Genügen mir dann als Access Switche Layer 2 Geräte - das Routing zwischen den vLANs (es sollen ca. 5 werden) übernehmen dann ja die Core Switche oder macht es dann Sinn auch auf Layer 3 zu gehen?

Die Netgear unterstützen Ring Stacking, sodass die Access Switche gestackt werden können und dann mit nur 1/2 Leitungen zu den Core Switchen.

[Crash2001]

Nicht jede neue Technik / Trend macht Sinn für jedes Netzwerk.

Wieso willst du VRRP unbedingt nutzen, wieso nicht z.B. HSRP? Kennst du die Unterschiede?

Ist die Konvergenzzeit in dem Netzwerk so ausschlaggebend, dass nicht ein Stack ausreicht für die grundlegende Redundanz?

Beim Stack gibt es ja den Master und fällt dieser aus, übernimmt der Switch mit der nächsthöheren Priorität die Rolle des Masters. Die Konvergenzzeit ist natürlich hierbei höher, da die Konvergenzzeit in etwa der Zeit entspricht, die der Switch zum starten braucht. Das können also schon mal 5-10 Minuten sein. Eine grundlegende Redundanz bietet das aber auch schon.

Besser wären natürlich 2 separate Switche / Stacks, die mittels HSRP oder VRRP sich eine gemeinsame IP-Adresse pro Segment teilen, die als Gateway für das jeweilige Segment genutzt wird, um die Konvergenzzeit zu minimieren. Standard-Konvergenzzeiten bei HSRP und VRRP liegen meist bei zwischen 10 und 60 Sekunden (je nach Timer-Einstellung halt), was natürlich einiges niedriger liegt als die Konvergenzzeit beim Stack.

Baust du ein Standard-Design mit Collapsed Core und Access Layer auf, dann wird L3 sinnvollerweise nur im Core/Distri (da Collapsed Core, gibt es keinen Distri, sondern nur den Core) genutzt. Für den Access Layer reicht dann L2 vollkommen aus, was das Ganze auch vom Preis her reduziert.

vor 15 Stunden schrieb Maphi:

[...]Die Netgear unterstützen Ring Stacking, sodass die Access Switche gestackt werden können und dann mit nur 1/2 Leitungen zu den Core Switchen.

Gestackte Switche haben zwar Vorteile, haben jedoch auch durchaus Nachteile.
 

Vorteile:

• Weniger Aufwand beim Management / Verwaltung
• grundlegende Redundanz vorhanden
• Man benötigt weniger Anbindungen an den Core oder Distri Switch und kann somit Switchports, Patchpanelports, Kabel und SFPs einsparen

Nachteile:

• Es gibt Bugs in den Betriebssystemen, die nur bei Stack-Betrieb auftreten
• Austausch von Switchen ist aufwändiger und kann einen kompletten Neustart des ganzen Stacks notwendig machen (wenn der Master-Switch ausfällt und ein anderer Switch übernimmt, wenn man den neuen Switch wieder als Master Switch haben möchte)
• Stacking-Switche sind meist etwas teurer als Switche ohne diese Funktionalität.
• Auch Stacking-Kabel können kaputt gehen.
• Die Redundanz bezieht sich nicht auf die User-Ports, sondern nur auf die Anbindung zum Core. Fällt einer der gestackten Access-Switche aus, können die dort angeschlossenen User genausowenig mehr arbeiten, wie wenn ein nicht gestackter Switch ausfällt.

Als Core macht ein Stack Sinn, wenn die Uplink-Ports der angeschlossenen Switche auf die gestackten Switche verteilt werden.

Als Access-Switch macht ein Stack in meinen Augen jedoch nicht wirklich viel Sinn, wenn man genügend Uplink-Möglichkeiten zum Core (Patchpanel oder Direktverkabelung) und freie Ports auf dem Core hat.

[Maphi]

vor 9 Stunden schrieb Crash2001:

Wieso willst du VRRP unbedingt nutzen, wieso nicht z.B. HSRP? Kennst du die Unterschiede?

Was spricht gegen VRRP mit OSPF?

Welchen Grundlegenden Aufbau schlägst du uns vor? Wenn die Einrichtung von VRRP mit OSPF in Verbindung mit VLANs zu aufwendig sein sollte, was gibt es für Alternativen? Die Netgear Switche lassen sich ja stacken und eine Redundanz sollte darüber möglich sein. Eine Downtime von bis zu 5 Minuten wäre noch OK.

Generell sollen bis zu 5 vLANs eingerichtet werden. Datentraffic herrscht nicht extrem viel. Die Clients und VoIP Telefone halten sich mit ca. 60 Stück je Arbeitsplatz in Grenzen. Wir können bei Netgear alle Switche mit der NMS300 Software verwalten. Die Switche werden - wie oben geschrieben - auf mehrere Schränke aufgeteilt. 2-3 Switche stacken wir und gehen mit je einer LWL Leitung zu einem Core (also gehen von einem Stack 2 LWL Leitungen, zur Ausfallsicherheit eines Cores) weg.

Als Core Switche nutzen wir die im 1. Post erwähnten. Als Access Switche nutzen wir nur Netgear Layer 2. Die Uplink Ports setzen wir als tagged und sind dann somit die Trunk-Leitungen zum Core.

[Crash2001]

Es spricht nichts gegen VRRP in Kombination mit OSPF - die Frage ist eher, wieso du dich so auf VRRP versteifst, statt auch offen zu sein für HSRP oder GLBP. Hier mal ein Vergleich der 3 Protokolle. GLBP kann man jedoch nur mit Cisco-HArdware verwenden.

Die selbe Frage stellt sich mir halt auch bei OSPF. Wieso willst du gerade OSPF nutzen, bzw. wieso willst du überhaupt ein Routingprotokoll nutzen bei der kleinen Umgebung? Hast du die Routingprotokolle miteinander verglichen und bist zum Schluß gekommen, dass OSPF das beste Routingprotokoll für eure Zwecke ist? Was würde z.B. gegen RIPv2 sprechen? Was würde gegen statische Routen sprechen? OSPF ist um EINIGES komplexer und somit auch schwieriger optimiert einzurichten, bietet aber natürlich auch einige Möglichkeiten mehr. Die Frage ist nur, welchen Mehrwert OSPF in eurer Umgebung hätte. Bei der simplen Umgebung sehe ich ehrlich gesagt keine wirklichen Vorteile.

Ich möchte dir nicht von einem davon abraten, aber du solltest halt überlegen, weshalb du etwas einsetzen willst und nicht nur, weil es grad in ist. Jedes Protokoll hat seine Vorteile und seine Nachteile und je nach eingesetzter Umgebung ist mal das eine besser geeignet oder das andere.

Solltest du dich zu wenig damit auskennen, solltest du vielleicht überlegen, das Ganze an ein Systemhaus auszulagern. Kostet zwar mehr, aber dafür hat man auch einen Ansprechpartner bei Problemen.

Ich kenne die genannten Netgear-Switche nicht und weiß somit nicht, wie lange diese zum Starten brauchen. Somit keine Ahnung, ob sie als Stack als Core in Frage kommen für euch, oder ob ein HSRP- oder VRRP-Cluster sinnvoller ist.

Ich würde ein klassisches Design eines Collapsed Core vorschlagen. Im Core also somit L3 und im Access Layer nur L2. Routing findet somit nur im Core statt.

[Maphi]

@Crash2001

Nach Rücksrpache mit dem Netgear Support soll das Stacking in unter 2 Minuten den Standby Core aktivieren. Somit wäre dann VRRP / HRSP für uns tatsächlich nutzlos und steht im Vergleich zum hohen Einrichtungsaufwand in keinem Verhältnis. Durch das Stacking benötigen wir dann wahrscheinlich auch kein Protokoll wie STP/OSPF, da der zweite Core ja im Standby ist.

Waren meine Gedanken zu vLANs korrekt?

Wir verbinden Layer 2 Access Switche in Schränken, in denen 2-3 Stück sitzen und gehen mit einer LWL Leitung zum Core. Die Stacking Leitungen und der Uplink zum Core sind VLAN tagged. Die Ports an den Switchen teilen wir in VLANs auf. Somit übernimmt der Core das Routing und wir haben als Access günstigere Layer 2.
Bei Ausfall eines Core bootet der zweite, gestackte und übernimmt die Aufgaben des ersten (eine zweite LWL Leitung geht natürlich zum zweiten Core).
Durch statische Routen am Core Switch kann ich ja dann die Netze miteinander verbinden, die auch verbunden werden sollen.

Was ist denn der grundlegende Unterschied zwischen Collapsed Core und Spine-Leaf Topologie?

Bearbeitet 2. Februar 2017 von Maphi

[Maphi]

Das verwendete Netz ist zur Zeit überdimensional groß (Klasse B Netz mit Subnet Mask 255.255.0.0). Die Geräte sind Gerate nach Abteilungen aufgeteilt z. B. 172.16.3.0 Marketing 172.16.4.0 Vertrieb usw. Ich finde das Netz zu überdimensioniert und bin der Meinung dass ein VLAN Konzept sinnvoll wäre. Es sollte eigentlich kein Zugriff von Vertrieb auf Marketing oder Produktion möglich sein. Durch VLANs lassen sich ja die Netze voneinander abschotten und so hat nur Jeder auf den Server Zugriff, aber kein Netz kann auf das andere aktiv zugreifen.

Was hätte ich sonst noch für Vor-/Nachteile wenn wir das bestehende Netz in VLANs unterteilen? Ich würde das Netz in einzelne VLANs unterteilen z. B. Server 172.16.0.0 mit 255.255.255.0, Marketing 172.16.3.0 mit 255.255.255.0.
Wäre das sinnvoll?

[Crash2001]

vor 17 Stunden schrieb Maphi:

@Crash2001

[...]Durch das Stacking benötigen wir dann wahrscheinlich auch kein Protokoll wie STP/OSPF, da der zweite Core ja im Standby ist.

Meinst du SPT (Spanning Tree) mit STP?
Ein Routingprotokoll wie OSPF wäre für die Umgebung meiner Meinung nach überdimensioniert. Wenn schon, dann kann man auch RIPv2 nutzen, falls man das Routing nicht statisch konfigurieren will.

vor 17 Stunden schrieb Maphi:

Waren meine Gedanken zu vLANs korrekt?[...]

Welche Gedanken?

vor 17 Stunden schrieb Maphi:

[...]Wir verbinden Layer 2 Access Switche in Schränken, in denen 2-3 Stück sitzen und gehen mit einer LWL Leitung zum Core.

Hier sollte man zumindest zwei Leitungen nehmen, wenn man einen Stack als Core hat. Eine Leitung zum Master und eine Leitung zum Slave-Switch, damit beim Ausfall des Cores die Verbindungen noch bestehen. Sonst bringt dir der Stack ja nichts.

vor 17 Stunden schrieb Maphi:

Die Stacking Leitungen und der Uplink zum Core sind VLAN tagged. [...]

ICh weiß nicht, wie das Stacking bei Netgear umgesetzt ist, aber bei Cisco Switchen sind das keine normalen Ports, sondern hinten am Switch hat man 2 Stacking Ports, über die mit speziellen Kabeln die anderen Switche dann angebunden werden. Da konfiguriert man kein vlan tagging o.ä. drauf, sondern das ist afaik eine Verbindung der Backplane.

vor 17 Stunden schrieb Maphi:

[...]Was ist denn der grundlegende Unterschied zwischen Collapsed Core und Spine-Leaf Topologie?

Das sind zwei unterschiedliche Ansätze.
Der Hauptunterschied ist wohl, dass beim klassischen Layer-Design (Access - Distribution - Core) bzw. Collapsed Core (Access - Distribution und Core in einem Layer) standardmässig Spanning Tree eingesetzt wird, was redundante Wege blockiert, um Loops zu verhindern.
Bei Spine Leaf werden andere Protokolle (Trill oder so) statt Spanning Tree eingesetzt, die keine Verbindungen blockieren, sondern mehrere mögliche Wege ermöglichen, um die Anzahl der Hops zwischen zwei Geräten zu minimieren. Loops im klassischen Sinne gibt es hier nicht. Aus dem Grunde werden auch alle Access-Switche mit möglichst vielen Switchen im Layer darüber verbunden, um die Anzahl der Hops zu minimieren. So muss ein PAket z.B. nicht mehr vom Access- zum Distri- zum Access-Switch zurück gehen, sondern geht direkt über einen Switch, der Direkatanbindung zu beiden Geräten hat.
Produktiv habe ich Spine Leaf aber auch noch nicht wirklich gesehen.

vor 14 Stunden schrieb Maphi:

Das verwendete Netz ist zur Zeit überdimensional groß (Klasse B Netz mit Subnet Mask 255.255.0.0). Die Geräte sind Gerate nach Abteilungen aufgeteilt z. B. 172.16.3.0 Marketing 172.16.4.0 Vertrieb usw. Ich finde das Netz zu überdimensioniert und bin der Meinung dass ein VLAN Konzept sinnvoll wäre. [...]

Das eine hat aber nicht direkt etwas mit dem anderen zu tun. Den gleichen Effekt könntest du auch schon durch die Nutzung kleinerer Netze haben - dafür braucht man keine vlans. Dann müsste aber die MAC-ADresse jedes PCs auf dem DHCP-Server eingetragen sein, um ihn dem entsprechenden Netz zuzuweisen.
Vlans sind halt nur sinnvoll, um Ports auf einem Switch in unterschiedliche Netze legen zu können, als ob man mehrere physikalische Switche hätte. Woher sollte der PC ansonsten wissen, welchen Netzbereich er hat.

vor 14 Stunden schrieb Maphi:

Es sollte eigentlich kein Zugriff von Vertrieb auf Marketing oder Produktion möglich sein. Durch VLANs lassen sich ja die Netze voneinander abschotten und so hat nur Jeder auf den Server Zugriff, aber kein Netz kann auf das andere aktiv zugreifen.[...]

Das regelt man am einfachsten mit Access-Listen, oder aber auf einer internen Firewall.

vor 14 Stunden schrieb Maphi:

Was hätte ich sonst noch für Vor-/Nachteile wenn wir das bestehende Netz in VLANs unterteilen? Ich würde das Netz in einzelne VLANs unterteilen z. B. Server 172.16.0.0 mit 255.255.255.0, Marketing 172.16.3.0 mit 255.255.255.0.
Wäre das sinnvoll?

siehe oben.
Mehrere verschiedene Netze an einem Switch möglich, Separierung der Netze, Umzüge von PCs in andere Abteilungen sind problemlos mal eben möglich ohne Umverkabelung (Unabhängigkeit von physikalischer Topologie), man kann QoS sinnvoller umsetzen, Verkleinerung der Kollisionsdomain (wobei das eher durch das Subnetting als durch die Nutzung von vlans),  ...

[pcpeasant]

Die weiteren Ausführungen über Subnetze und VLANs lassen mir die Haare zu Berge stehen. Das ist wirklich nicht böse gemeint, aber falls ihr jemanden habt der ein wenig Ahnung von Netzwerken habt, dann lass doch bitte diese Person das übernehmen. Es hört sich stark danach an, als hätte jemand das Netzwerk entworfen für den selbst ComputerBILD noch zu hoch ist und deine Kenntnisse sind meiner Meinung nach nicht gut genug das Projekt ohne Kollateralschäden durchzuführen.


Gesendet von meinem SM-N910F mit Tapatalk

[Maphi]

Am 5.2.2017 um 13:54 schrieb V1RTU4L:

Die weiteren Ausführungen über Subnetze und VLANs lassen mir die Haare zu Berge stehen. Das ist wirklich nicht böse gemeint, aber falls ihr jemanden habt der ein wenig Ahnung von Netzwerken habt, dann lass doch bitte diese Person das übernehmen. Es hört sich stark danach an, als hätte jemand das Netzwerk entworfen für den selbst ComputerBILD noch zu hoch ist und deine Kenntnisse sind meiner Meinung nach nicht gut genug das Projekt ohne Kollateralschäden durchzuführen.


Gesendet von meinem SM-N910F mit Tapatalk
 

Danke für deinen Kommentar aber ich bin der Meinung dass man einfach mal etwas versuchen muss - wie lernt man es sonst? Wenn ich es nur theoretisch weiß, muss ich es trotzdem einmal in der Praxis umsetzen und da ist es dann auch einmal das erste mal...Als ich den Thread eröffnet habe war ich wirklich noch sehr beschränkt im Wissen um VLANs und was alles dahinter steckt....

An den letzten Tage und auch das ganze Wochenende habe ich mich in das Thema VLAN mit allen zu konfigurierenden Bereichen wie DHCP Relay, allgemeine Struktur, Routing usw. sehr tief rein gearbeitet. Ich habe mir jetzt Zeichnungen vom Netzwerk erstellt, alle DV Schränke mit allen Haupt- und Unterverteilern, habe alle Switche, alle gestackten Verbindungen und Verbindungsstrecken vom Edge zum Core eingezeichnet und mit einem Systemhaus durchgesprochen - die meinten das wäre so OK und gängige Vorgehensweise.

Eine Testeinrichtung mit den beiden Cores und 2 Access-Switchen im Bereich VLAN hat funktioniert - der Zugriff untereinander von VLAN zu VLAN hat funktioniert und lies sich auch mit ACLs sperren. Die Geräte haben sich im selben VLAN auf allen Switchen erreicht. Die Vergabe von IP Adressen über DHCP hat mit DHCP Relay am L3 Core funktioniert und der Internetzugriff über die Default Route klappte auch. Ich gehe davon aus, dass ich es dann auch schaffen werden, alle Switche über alle Verteiler zu verbinden. Die alte Infrastruktur läuft ja noch und falls es zu Schwierigkeiten kommen sollte, kann ich jederzeit zurück springen oder die 24/7 Hotline von Netgear um Hilfe bitten :-)

Die Netgear Switche sind sogar Full Stacking fähig, erscheinen nach außen mit einer IP Adresse und die Master Rolle verschiebt sich bei Ausfall des Core Master auf den Slave mit ca 3-4 Pings Unterbrechung (heißt NonStopFailover bei Netgear)- auch das hat funktioniert. Somit sind dann VRRP/HRSP mit RSTP oder OSPF hinfällig. Die Access Switche lassen sich ebenso stacken (aber ohne NSF, was ja im Edge Bereich nicht benötigt wird).

Somit bin ich dem Bereich VLAN ein großes Stück näher und kann den Thread hier schließen. Ich danke für alle Antworten.

Bearbeitet 7. Februar 2017 von Maphi

[Crash2001]

vor 16 Stunden schrieb Maphi:

Danke für deinen Kommentar aber ich bin der Meinung dass man einfach mal etwas versuchen muss - wie lernt man es sonst? Wenn ich es nur theoretisch weiß, muss ich es trotzdem einmal in der Praxis umsetzen und da ist es dann auch einmal das erste mal[...]

Solange du problemlos zurück zur alten Infrastruktur gehen kannst und dein Chef hinter dir steht, sehe ich nicht so das Problem.

Die Frage wäre halt noch, was für sicherheitsrelevante Protokolle du alle einsetzen willst, bzw. was vom Netgear Switch unterstützt wird.

hier mal ein paar Stichworte für dich:
Storm Control
(Rapid) Spanning Tree und wo die Root-Bridge sitzen sollte
LAG / LACP
allowed vlans auf trunks
native vlan
port security
Telnet verbieten, Webfrontend falls möglich per https
...