Trockenübung Netzwerk
Hallo zusammen,
ich habe hier ein nettes Projekt vor der Nase, an dem ich u.a. auch einiges lernen möchte.
Unsere Netzwerkinfrastruktur bedarf einer Rundumerneuerung, die gewachsene Struktur
habe ich vorn ein paar Jahren übernommen und ich möchte den Wildwuchs an Switches
gern auflösen.
Dazu habe ich mich für die Netgear M4300 Serie entschieden und dort bedarfsgerecht ausgearbeitet was ich brauche.
Da für Ende der Woche nun die letzten Switches angekündigt sind (52G-PoE war nicht so leicht zu bekommen),
habe ich mich dazu entschlossen die Geräte erstmal "trocken" in Betrieb zu nehmen und mich mit der Konfiguration zu befassen:
Um mal die Verbindungen und die Bereiche zu skizzieren:
Kurz meine Gedanken dazu:
Fragen, speziell hinsichtlich der Kopplung via EthernetConnect & Richtfunk (Fallback):
Grüße
ToWa
ich habe hier ein nettes Projekt vor der Nase, an dem ich u.a. auch einiges lernen möchte.
Unsere Netzwerkinfrastruktur bedarf einer Rundumerneuerung, die gewachsene Struktur
habe ich vorn ein paar Jahren übernommen und ich möchte den Wildwuchs an Switches
gern auflösen.
Dazu habe ich mich für die Netgear M4300 Serie entschieden und dort bedarfsgerecht ausgearbeitet was ich brauche.
Da für Ende der Woche nun die letzten Switches angekündigt sind (52G-PoE war nicht so leicht zu bekommen),
habe ich mich dazu entschlossen die Geräte erstmal "trocken" in Betrieb zu nehmen und mich mit der Konfiguration zu befassen:
Um mal die Verbindungen und die Bereiche zu skizzieren:
Kurz meine Gedanken dazu:
- Netzwerktopologie "Spinnennetz":
- 2x 12X12F als Coreswitches, hier läuft alles zusammen, alle anderen sind UV an Clients
- Uplinks zu den Switches an Standort 1 erfolgen per LWL
- Standort 2 ist nur die UV per LWL angebunden
- Standort 2 besitzt aktuell keine nennenswerte Infrastruktur an Serversystemen (sollte sich das ändern, würde auch hier ein "Coreswitch" einziehen
Fragen, speziell hinsichtlich der Kopplung via EthernetConnect & Richtfunk (Fallback):
- Nur die 2x 12X12F Switches stacken, oder alle Switches?
- Wenn alle Switches, wie wäre das dann mit den Switches an Standort 2?
- Würdet ihr für die OOB-Schnittstellen (über diese greife ich aktuell auf die Systeme zu), ein separates VLAN empfehlen?
Grüße
ToWa
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1976997151
Url: https://administrator.de/forum/trockenuebung-netzwerk-1976997151.html
Ausgedruckt am: 01.04.2025 um 04:04 Uhr
15 Kommentare
Neuester Kommentar

- Nur die Cores pro Standort stacken. Standortübergreifend besteht bei einer nicht von dir gemanagten WAN Verbindung immer die Gefahr eines Split Brain bei Ausfall der Stack Links. Abgesehen davon reicht 1Gig niemals als Stack Link aus bei horizontal Stacking !
- OOBs ist abhängig welche Sicherheits Policy du hast. Ohne die zu kennen ist eine Antwort Raterei.

Denn die 52G Switches wären parallel 1x per LWL mit einem 12X12F (links) und 1x per LWL mit 12X12F (rechts)
Diese Links legst du zur Redundanz natürlich immer als LACP LAGs aus auf die Core Switches !Aber auch ohne LACP LAG wäre deine Annahme falsch oder du machst zumindestens dann einen Design Denkfehler ! Spanning Tree sorgt doch auch in dem Falle immer dafür das auch 2 einzelne Core Links redundant wären ! Spanning Tree (RSTP), IGMP Snooping und Jumbo Framing sind 3 klassische Standardfeatures die immer in einem Netz wie deinem aktiviert sein sollten !
Eine Sicherheits-Policy gibt es keine
Ooops...bei einer Erneuerung der Infrastruktur ignoriert man so etwas Fundamentales wie Netzwerk Security ?!? Na dann...Dann kannst du das machen wie du lustig bist und wie es für dich am einfachsten oder schönsten ist. In dem Falle gibts dann natürlich keine Regeln.

denn in wie weit EthernetConnect und Richtfunk im Switch parallel aktivieren aber unterschiedlich priorisieren kann ist mir noch ein Rätsel.
Layer 2 oder Layer 3 ??- Layer 2 = STP Link Priorisierung
- Layer 3 = Routing Costs
Schön wäre ja, wenn beides genutzt würde
Macht auch am meisten Sinn und ist auch der richtige Weg wie man sowas in der Praxis immer löst !Layer 3 ist in jedem Falle besser weil damit ein dynamisches Balancing möglich ist. Mit Layer 2 über Spanning Tree geht das immer nur wenn du eine VLAN Segmentierung hast und rein statisch über die Priority. Wenig flexibel also.
Idealerweise machst du das mit IP Routing (L3) und dann dynamisch z.B. mit OSPF ECMP (Equal Cost Multipathing) oder auch statisch was dann Session basiert balanced wenn beide Links gleiche Costs haben.
L3 ist also erheblich besser, da flexibler und dynamisch.
2 Links die das ansatzweise veranschaulichen.
Netzwerktopologie - mehrere Werke
Backup Problem mit Lancom 1721 VPN

Da braucht daher eigentlich nichts geroutet zu werden. Hm...
Leider damit dann ein recht laien- und frickelhaftes IP Design. Oder besser: Gar kein IP Design ! Kein verantwortungsbewusster Admin würde so etwas machen. Bedeutet ja im Endeffekt auch das dein EtherConnect ein simples Bridging machen muss und dann mit dem Broad- und Multicast Traffic beider Netze diese teure Leitung unnötig belastet und Performance nimmt.Ziemlich tiefes IT Neandertal was wenig praxistauglich ist aber nundenn...wenn man damit leben muss und will...?!
Damit fallen dann aber 90% aller gängigen und sinnvollen Balancing Mechanismen weg diese beiden Leitungen sinnvoll parallel zu nutzen wie es eigentlich Sinn machen würde.
Dir bleibt dann nur ein primitives Spanning Tree Failover auf Layer 2.

Nicht vergessen deinen Thread hier dann auch zu schliessen wenn keine Fragen mehr sind!!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?

als LAG miteinander vernetzt.
Das kann eigentlich so nicht sein. Zumindestens nicht wenn die Switches als Full Stacks konfiguriert sind. Aber auch beim billigen Clustering geht es so nicht zumindestens dann nicht wenn 802.3ad LAGs verwendet wurden.Mal ganz abgesehen das es eine Verletzung des IEEE Standards ist, denn LACP LAGs supporten keine Links mit unterschiedlichen Speeds. Das liegt daran das der LAG Standard 802.3ad keinerlei Paket Recovery Mechanismen mitbringt. Unterschiedliche Speeds sind also tödlich, nicht Standard konform und werden immer zu Problemen führen.
Stacking Ports nutzt generell KEINE LAG Mechanismen und sind eigene proprietäre Verfahren je nachdem welche Chipsätze verwendet werden.
Aber auch hier gilt ganz strikt: keine unterschiedlichen Speeds in den Stacking Links!
Das ist ein absolutes NoGo weil auch die Recovery Mechanismen fehlen und wegen der dann unterschiedlichen Signallaufzeiten kein Paket Recovery möglich ist. Folge sind Paketverluste und massive Retransmissions usw. auf solchen Links bei höherer Belastung.
Deine Beschreibung widerspricht sich nicht nur technisch sondern ist generell nicht supportet!
Gerade Funk Schnittstellen sind wegen der massiv schwankenden Bandbreite völlig ungeeignet für Stack Links zw. Switches.
Möglich aber das du das oben auch nur falsch oder missverständlich ausgedrückt hast.