15
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
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte 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: 21.04.2025 um 15: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.
Hey,
danke schon mal.
OK, also wenn du von Core-Switches sprichst, dann ist die Annahme korrekt, dass wir nur von den 2x 12X12F von Netgear sprechen und die Verteilerswitches für die Clientstruktur da nicht zugehören?
Wie wären denn die Ports dorthin zu konfigurieren (Trunk)?
Denn die 52G Switches wären parallel 1x per LWL mit einem 12X12F (links) und 1x per LWL mit 12X12F (rechts) - welche sich dann im Stack befinden - verbunden.
Dies ist m.E.n. sinnvoll, um einen Ausfall eines Coreswitches zu kompensieren?
Eine Sicherheits-Policy gibt es keine, aktuell gibt es nicht mal VLANs, das soll sich aber dringend ändern.
Also würde ich mir ein "Management"-VLAN aufbauen und dies nur von essentiellen Systemen aus zugänglich machen.
danke schon mal.
Zitat von @148523:
- 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 !
OK, also wenn du von Core-Switches sprichst, dann ist die Annahme korrekt, dass wir nur von den 2x 12X12F von Netgear sprechen und die Verteilerswitches für die Clientstruktur da nicht zugehören?
Wie wären denn die Ports dorthin zu konfigurieren (Trunk)?
Denn die 52G Switches wären parallel 1x per LWL mit einem 12X12F (links) und 1x per LWL mit 12X12F (rechts) - welche sich dann im Stack befinden - verbunden.
Dies ist m.E.n. sinnvoll, um einen Ausfall eines Coreswitches zu kompensieren?
* OOBs ist abhängig welche Sicherheits Policy du hast. Ohne die zu kennen ist eine Antwort Raterei.
Eine Sicherheits-Policy gibt es keine, aktuell gibt es nicht mal VLANs, das soll sich aber dringend ändern.
Also würde ich mir ein "Management"-VLAN aufbauen und dies nur von essentiellen Systemen aus zugänglich machen.
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.
Zitat von @148523:
Ooops...bei einer Erneuerung der Infrastruktur ignoriert man so etwas Fundamentales wie Netzwerk Security ?!? Na dann...
Ooops...bei einer Erneuerung der Infrastruktur ignoriert man so etwas Fundamentales wie Netzwerk Security ?!? Na dann...
Naja was heißt ignoriert?
Das heißt eher es soll eher rudimentär "sicher" sein, aber eben nicht sicher in Kombination mit unnötig kompliziert.
Es geht ja schon los mit: Wer kommt an die zentralen Verteilungen ran? - Jeder.
Ha, genau LAG war das was ich da gesucht hab.
Da muss ich aber noch mal ein wenig lesen, denn in wie weit EthernetConnect und Richtfunk im Switch parallel aktivieren aber unterschiedlich priorisieren kann ist mir noch ein Rätsel.
Zitat von @148523:
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 !Salut noch mal, also die LAGs lassen sich problemlos anlegen:
Im Handbuch der Switches gibt es dazu den Verweis auf die Ports, ich gehe daher davon aus, dass sich das dann auf die LAG Config überträgt:
Hallo noch mal,
hat jemand noch eine Idee wie ich den zweiten Standort ideal anbinde?
Ich habe die EthernetConnect mit 1G zur Verfügung und parallel eine Richtfunkstrecke die max. 300 Mbit bieten kann.
Schön wäre ja, wenn beides genutzt würde, die EthernetConnect natürlich primär.
Wenn das nicht geht würde ich die Richtfunk nur als Standby nutzen wollen, der sich dann automatisch aktiviert wenn ein Switch auf der Gegenseite nicht mehr erreichbar ist?
Grüße
ToWa
hat jemand noch eine Idee wie ich den zweiten Standort ideal anbinde?
Ich habe die EthernetConnect mit 1G zur Verfügung und parallel eine Richtfunkstrecke die max. 300 Mbit bieten kann.
Schön wäre ja, wenn beides genutzt würde, die EthernetConnect natürlich primär.
Wenn das nicht geht würde ich die Richtfunk nur als Standby nutzen wollen, der sich dann automatisch aktiviert wenn ein Switch auf der Gegenseite nicht mehr erreichbar ist?
Grüße
ToWa
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
Zitat von @148523:
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 ??Die Switches können Layer 3, also werde ich den Ansatz mal verfolgen.
Danke für die Links und die Begrifflichkeiten, hab ich wieder was zu verfolgen.
Allerdings... die Werke sind ein "großes Ganzes", also alles in einem IP Netz, da die Serversysteme nur an einem Standort stehen und an beiden Standorten identische Programme und Daten genutzt werden, sowie die Mitarbeiter flexibel zwischen den Werken wechseln.
Da braucht daher eigentlich nichts geroutet zu werden. Hm...
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.
Zitat von @148523:
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 !Naja das heißt ja nicht, dass man das nicht ändern kann.
Das war damals die einzig sinnvolle Lösung um überhaupt Performance zwischen die Werke zu bekommen.
Das geht allerdings zu tief in die Historie.
Nur am Rande, das läuft so seit 3 Jahren absolut praxistauglich ohne Probleme.
Aber ja, die EthCon ist aktuell eine einfache LAN Verbindung, in meinen Augen auch nicht schlimm,
denn das einzige was an Traffic rausgefiltert werden könnte wären 100 Mbit max. Internet.
Ansonsten läuft sowieso alles über die Leitung was die Clients kommunizieren müssen.
Nun denn, werde ich das mal als Input mitnehmen und überlegen ob ich dann doch in Richtung Layer3 gehe und ein Zwischennetz erstelle.
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?
Hallo zusammen,
ich krame das hier noch mal raus.
Das lange Pfingstwochenende wurde genutzt und die Umstellung der gesamten Netzwerkinfrastruktur ist durch.
Hat soweit auch alles super funktioniert, inkl. der LAG Uplinks und der Standortvernetzungen.
Ich hatte mich dazu vorab auch noch mit dem Netgear-Support ausgetauscht.
Nun ergibt sich mir noch eine Verständnisfrage:
Ich habe an beiden Standorten ein Stack aus 2 Coreswitches.
Diese Stacks sind mit zwei unabhängigen Netzwerkstrecken (1x 980 Mbit/s EthernetConnect LWL & 1x 850 Mbit/s Richtfunk 60 GHz - Kupfer) als LAG miteinander vernetzt.
Die EthernetConnect ist sowieso transparent, da kann nur die Telekom selbst Diagnosen durchführen, aber
sobald die Accesspoints zum LAG hinzugefügt werden kann ich deren IP-Adressen nicht mehr erreichen.
Die Ports sind am Switch wie folgt konfiguriert:
Die Konfiguration der Ports sollte egal sein, da die Konfiguration der LAG herangezogen wird, diese ist identisch.
Gibt es eine Möglichkeit die IPs dennoch zu erreichen?
Laut Funktionsweise des Installateurs der Richtfunkstrecke macht diese nichts anderes als von Antenne zu Antenne alle ankommenden Datenpakete in ein VLAN 100 zu verpacken und auf der anderen Seite wieder auszupacken.
Da die Switches aber vermutlich durch den "Trunk" etwas anstellen kann ich den "Client", also die Accesspoints, nicht mehr erreichen.
Grüße
ToWa
ich krame das hier noch mal raus.
Das lange Pfingstwochenende wurde genutzt und die Umstellung der gesamten Netzwerkinfrastruktur ist durch.
Hat soweit auch alles super funktioniert, inkl. der LAG Uplinks und der Standortvernetzungen.
Ich hatte mich dazu vorab auch noch mit dem Netgear-Support ausgetauscht.
Nun ergibt sich mir noch eine Verständnisfrage:
Ich habe an beiden Standorten ein Stack aus 2 Coreswitches.
Diese Stacks sind mit zwei unabhängigen Netzwerkstrecken (1x 980 Mbit/s EthernetConnect LWL & 1x 850 Mbit/s Richtfunk 60 GHz - Kupfer) als LAG miteinander vernetzt.
Die EthernetConnect ist sowieso transparent, da kann nur die Telekom selbst Diagnosen durchführen, aber
sobald die Accesspoints zum LAG hinzugefügt werden kann ich deren IP-Adressen nicht mehr erreichen.
Die Ports sind am Switch wie folgt konfiguriert:
- Switch port Mode = Trunk
- Access VLAN ID = 111
- Native VLAN ID = 111
- Trunk Allowed VLANs = 10 - 2000
Die Konfiguration der Ports sollte egal sein, da die Konfiguration der LAG herangezogen wird, diese ist identisch.
Gibt es eine Möglichkeit die IPs dennoch zu erreichen?
Laut Funktionsweise des Installateurs der Richtfunkstrecke macht diese nichts anderes als von Antenne zu Antenne alle ankommenden Datenpakete in ein VLAN 100 zu verpacken und auf der anderen Seite wieder auszupacken.
Da die Switches aber vermutlich durch den "Trunk" etwas anstellen kann ich den "Client", also die Accesspoints, nicht mehr erreichen.
Grüße
ToWa
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.
Langsam, die zwei Stacks sind nicht über Glas und Kupfer gestackt.
Sondern es gibt auf jeder Seite ein Switchpaar welches in sich gestackt ist.
Diese kommunizieren dann über LACP LAG mit zwei parallelen Uplinks miteinander.
Eber die genannte Richtfunk (für den Switch als 1G Kupfer) und die genannte EthernetConnect (für den Switch als 1G Glas) zu erkennen.
Diese Konstellation wurde mir auch genauso von der Netgeartechnik als funktionell vorgeschlagen und läuft auch problemlos.
Einzug, dass ich die APs nun eben nicht mehr erreichen kann stört mich ein wenig.
Sondern es gibt auf jeder Seite ein Switchpaar welches in sich gestackt ist.
Diese kommunizieren dann über LACP LAG mit zwei parallelen Uplinks miteinander.
Eber die genannte Richtfunk (für den Switch als 1G Kupfer) und die genannte EthernetConnect (für den Switch als 1G Glas) zu erkennen.
Diese Konstellation wurde mir auch genauso von der Netgeartechnik als funktionell vorgeschlagen und läuft auch problemlos.
Einzug, dass ich die APs nun eben nicht mehr erreichen kann stört mich ein wenig.
Zitat von @dertowa:
Einzug, dass ich die APs nun eben nicht mehr erreichen kann stört mich ein wenig.
Einzug, dass ich die APs nun eben nicht mehr erreichen kann stört mich ein wenig.
Wie ich vom Hersteller der Richtfunk-APs erfahren habe, besitzen diese zwei LAN-Ports.
Auf der einen Seite liegt ein weiteres Kabel am Mast, das haben die Herren aber nicht angeschlossen da die Muffen zur Durchführung standardmäßig nur einmal enthalten sind.
Entsprechend sind nun weitere Muffen bestellt und am zweiten Mast wird mal fix noch ein Kabel hochgezogen, damit bekomm ich dann wieder Zugriff auf die APs.
