6
Neues Netzwerk, Segmentierung KMU
Hallo an alle,
seit langem lese ich schon im Forum aus Interesse mit, jedoch hatte ich noch nie die Gelegenheit aktiv an der Community teil zu nehmen. Ich hoffe das ändert sich hiermit.
Wir haben aktuell ein Projekt das mir übertragen wurde, welches eine Netzwerksegmentierung voraussetzt. Wir sind ein mittelständiges Unternehmen mit einer schwankenden Mitarbeiter Zahl, jedoch liegt diese immer im Rahmen von 180 – 200 Mitarbeiter. Da unser Netzwerk jedoch in die Jahre gekommen ist und das aktuelle Budget vorhanden ist sowie auslaufende Wartungsverträge anstehen, muss ein neues Netzwerk her, das stabil und performant läuft.
Anbei eine kleine Auflistung des derzeitigen Netzwerks:
1. Wir haben etwa 150 Clients die über Gbit angeschlossen sind
2. Wir haben ungefähr 10 virtuelle Server die in der DMZ stehen und mit Gbit angeschlossen sind. Dieses muss auf 10Gbit hochgestuft werden.
3. Wir haben mehrere virtuelle Server in Betrieb, jedoch sind alle über Gbit angeschlossen, außer der Fileserver, der auf 10Gbit läuft. (Dieser könnte jedoch 20Gbit voll ausreitzen, Datenträgerseitig)
4. Unser Backupsystem ist über 10Gbit angeschlossen und soll auch auf 20Gbit gehen (Dieser könnte auch 20Gbit voll ausreitzen)
5. Zu guterletzt, wollen wir noch ein Verwaltungssystem anschaffen, wo Drucker, WLAN, Monitoring und Logging usw läuft, damit alles schön separiert wird.
Zurzeit ist es so, das alle System kreuz und quer in zwei Subnetzen verteilt ist, das heisst, Client Server und Backup liegen im gleichen Netz und können aufeinander zugreifen (danke an meinen Vorgänger).
Anbei ist ein Diagramm, das das neue Netzwerk erklären soll.
1. Alle Client sollen sich in einem seperaten Netzwerk befinden ( zB. 10.0.1.0/24 ) und alle 4 Switche, die jeweils 48 Ports haben, sollen per 10Gbit an einen Core Switch angeschlossen werden, der insgesamt 20Gbit an die Firewall weitergibt. Die derzeitige Auslastung ist nicht relevant genug um die 40Gbit vom Core Switch an die Firewall weiter zu geben.
2. Die DMZ ( zB. 10.0.3.0/24 ) und die Verwaltung ( zB. 10.0.4.0/24 ) sollen sich einen Switch teilen, diese werden per Portisolierung voneinander getrennt, sodass jede Instanz ( DMZ und Verwaltung ) einen separaten Uplink zum CoreSwitch bekommt. Der Switch wird in Richtung 24 Port RJ45 und 4x SFP+ gehen.
3. Auch die Serverumgebung ( zB. 10.0.2.0/24 ) soll direkt an den Core angeschlossen werden, das heisst 20Gbit für den Fileserver und jeweils 10Gbit pro Hypervisior, jedoch wird die Serverumgebung mit 20Gbit angebunden und die Backupumgebung ( zB. 10.0.5.0/24 ) soll per QSFP auf 40Gbit laufen. (Die jeweiligen Server haben keine große Auslastung, deswegen der „Flaschenhals“ mit 20Gbit im ganzen Serverbereich)
4. Der Core Switch gibt somit 20Gbit der Client an die Firewall weiter, 10GBbit der DMZ, 10Gbit der Verwaltung, 20Gbit der Server und 40Gbit der Backupumgebung.
Das ist gemessen, an dem was wir jetzt haben, ein gewaltiger Sprung in Richtung Performance, Sicherheit und Erweiterbarkeit.
Hier meine Fragen:
1. Was haltet ihr von diesem Konzept und was würdet ihr verbessern?
2. Switche habe ich schon rausgesucht (HPE Aruba 2540 48G JL355A), Core Switche zu finden, die das abdecken und nicht überdimensioniert sind, sind schwer zu finden. Könnt ihr was empfehlen?
Danke schon mal für eure Unterstützung, ich bin sehr gespannt auf Feedback 😊
seit langem lese ich schon im Forum aus Interesse mit, jedoch hatte ich noch nie die Gelegenheit aktiv an der Community teil zu nehmen. Ich hoffe das ändert sich hiermit.
Wir haben aktuell ein Projekt das mir übertragen wurde, welches eine Netzwerksegmentierung voraussetzt. Wir sind ein mittelständiges Unternehmen mit einer schwankenden Mitarbeiter Zahl, jedoch liegt diese immer im Rahmen von 180 – 200 Mitarbeiter. Da unser Netzwerk jedoch in die Jahre gekommen ist und das aktuelle Budget vorhanden ist sowie auslaufende Wartungsverträge anstehen, muss ein neues Netzwerk her, das stabil und performant läuft.
Anbei eine kleine Auflistung des derzeitigen Netzwerks:
1. Wir haben etwa 150 Clients die über Gbit angeschlossen sind
2. Wir haben ungefähr 10 virtuelle Server die in der DMZ stehen und mit Gbit angeschlossen sind. Dieses muss auf 10Gbit hochgestuft werden.
3. Wir haben mehrere virtuelle Server in Betrieb, jedoch sind alle über Gbit angeschlossen, außer der Fileserver, der auf 10Gbit läuft. (Dieser könnte jedoch 20Gbit voll ausreitzen, Datenträgerseitig)
4. Unser Backupsystem ist über 10Gbit angeschlossen und soll auch auf 20Gbit gehen (Dieser könnte auch 20Gbit voll ausreitzen)
5. Zu guterletzt, wollen wir noch ein Verwaltungssystem anschaffen, wo Drucker, WLAN, Monitoring und Logging usw läuft, damit alles schön separiert wird.
Zurzeit ist es so, das alle System kreuz und quer in zwei Subnetzen verteilt ist, das heisst, Client Server und Backup liegen im gleichen Netz und können aufeinander zugreifen (danke an meinen Vorgänger).
Anbei ist ein Diagramm, das das neue Netzwerk erklären soll.
1. Alle Client sollen sich in einem seperaten Netzwerk befinden ( zB. 10.0.1.0/24 ) und alle 4 Switche, die jeweils 48 Ports haben, sollen per 10Gbit an einen Core Switch angeschlossen werden, der insgesamt 20Gbit an die Firewall weitergibt. Die derzeitige Auslastung ist nicht relevant genug um die 40Gbit vom Core Switch an die Firewall weiter zu geben.
2. Die DMZ ( zB. 10.0.3.0/24 ) und die Verwaltung ( zB. 10.0.4.0/24 ) sollen sich einen Switch teilen, diese werden per Portisolierung voneinander getrennt, sodass jede Instanz ( DMZ und Verwaltung ) einen separaten Uplink zum CoreSwitch bekommt. Der Switch wird in Richtung 24 Port RJ45 und 4x SFP+ gehen.
3. Auch die Serverumgebung ( zB. 10.0.2.0/24 ) soll direkt an den Core angeschlossen werden, das heisst 20Gbit für den Fileserver und jeweils 10Gbit pro Hypervisior, jedoch wird die Serverumgebung mit 20Gbit angebunden und die Backupumgebung ( zB. 10.0.5.0/24 ) soll per QSFP auf 40Gbit laufen. (Die jeweiligen Server haben keine große Auslastung, deswegen der „Flaschenhals“ mit 20Gbit im ganzen Serverbereich)
4. Der Core Switch gibt somit 20Gbit der Client an die Firewall weiter, 10GBbit der DMZ, 10Gbit der Verwaltung, 20Gbit der Server und 40Gbit der Backupumgebung.
Das ist gemessen, an dem was wir jetzt haben, ein gewaltiger Sprung in Richtung Performance, Sicherheit und Erweiterbarkeit.
Hier meine Fragen:
1. Was haltet ihr von diesem Konzept und was würdet ihr verbessern?
2. Switche habe ich schon rausgesucht (HPE Aruba 2540 48G JL355A), Core Switche zu finden, die das abdecken und nicht überdimensioniert sind, sind schwer zu finden. Könnt ihr was empfehlen?
Danke schon mal für eure Unterstützung, ich bin sehr gespannt auf Feedback 😊
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 643472
Url: https://administrator.de/forum/neues-netzwerk-segmentierung-kmu-643472.html
Ausgedruckt am: 21.12.2024 um 18:12 Uhr
6 Kommentare
Neuester Kommentar
Moin,
ob ihr die Bandbreiten tatsächlich benötigt, kann ich von hier aus nicht beurteilen.
Da du aber massig mit 10GBit und 40Gbit "um dich schmeisst":
Als Edge-Switch: Ruckus ICX 7150 oder 7250. Gehen dir die sehr knapp bemessenen Ports zur Neige, hängst du einfach einen weiteren Switch darunter, stackst den und hast physisch zwei Switche, managen sich aber wie einer.
Im Zentrum dann zwei ICX7650-24F oder -48F, auch wieder im Stack
Der hat 24x bzw. 48x SFP+ und kann zusätzliche QSFP-Module aufnehmen/ hat er die an der Rückseite.
Dann kannst du Access-Switche über zwei Switche am Core-Switch verteilen: fällt einer aus, ist immer noch ein Bein online.
Denk bei der Anzahl der Ports zwischen Edge und Core-Switchen nur dran, jeweils eine LAG mit >=2 Ports vorzusehen.
Die Hypervisor würde ich ebenfalls mindestens mit 2x10GBit anbinden - wenn dein Hypervisor VMware ist, schreit der sogar danach.
Chassis-basierte Switche sind zwar ebenfalls Modular, aber wenn das Gehäuse ausfällt, steht auch hier alles. Folglich wäre ein zweites Chassis auch hier von Nöten.
Neben den o.g. RUCKUS-Kisten gehen auch welche von Cisco, Juniper, Huaweii (und wehe es kommt mit einer mit der Chinaböller Ware oder "da mischt die Regierung mit". Das kann für Cisco & Co. auch gelten. Juckt nur keinen, da aus dem Westen stammend).
Du musst halt nur im Enterprise-Segment suchen.
Hinweis zu deinen ARUBAs:
Ich weiß nicht, ob HPE das immer noch so macht, aber wenn du ein Stack hast, musst du dich zu jedem Stack-Member separat verbinden, um den zu konfigurieren. Die haben sich - zumindest früher - nicht als eine Einheit "angefühlt".
Grundsätzlich: Suche dir zudem nur einen Hersteller heraus: das vereinfacht die Kompatibilität und Komplexität. Du musst dich nur in eine Syntax und Terminologie einarbeiten.
P.S.
Da braucht es nicht für jedes Segment einen eigenen Switch. Zudem kannst du so Personalwesen und Produktion trennen, selbst wenn die im selben Raum sitzen würden und dadurch am selben Switch hingen.
Gruß
em-pie
ob ihr die Bandbreiten tatsächlich benötigt, kann ich von hier aus nicht beurteilen.
Da du aber massig mit 10GBit und 40Gbit "um dich schmeisst":
Als Edge-Switch: Ruckus ICX 7150 oder 7250. Gehen dir die sehr knapp bemessenen Ports zur Neige, hängst du einfach einen weiteren Switch darunter, stackst den und hast physisch zwei Switche, managen sich aber wie einer.
Im Zentrum dann zwei ICX7650-24F oder -48F, auch wieder im Stack
Der hat 24x bzw. 48x SFP+ und kann zusätzliche QSFP-Module aufnehmen/ hat er die an der Rückseite.
Dann kannst du Access-Switche über zwei Switche am Core-Switch verteilen: fällt einer aus, ist immer noch ein Bein online.
Denk bei der Anzahl der Ports zwischen Edge und Core-Switchen nur dran, jeweils eine LAG mit >=2 Ports vorzusehen.
Die Hypervisor würde ich ebenfalls mindestens mit 2x10GBit anbinden - wenn dein Hypervisor VMware ist, schreit der sogar danach.
Chassis-basierte Switche sind zwar ebenfalls Modular, aber wenn das Gehäuse ausfällt, steht auch hier alles. Folglich wäre ein zweites Chassis auch hier von Nöten.
Neben den o.g. RUCKUS-Kisten gehen auch welche von Cisco, Juniper, Huaweii (und wehe es kommt mit einer mit der Chinaböller Ware oder "da mischt die Regierung mit". Das kann für Cisco & Co. auch gelten. Juckt nur keinen, da aus dem Westen stammend).
Du musst halt nur im Enterprise-Segment suchen.
Hinweis zu deinen ARUBAs:
Ich weiß nicht, ob HPE das immer noch so macht, aber wenn du ein Stack hast, musst du dich zu jedem Stack-Member separat verbinden, um den zu konfigurieren. Die haben sich - zumindest früher - nicht als eine Einheit "angefühlt".
Grundsätzlich: Suche dir zudem nur einen Hersteller heraus: das vereinfacht die Kompatibilität und Komplexität. Du musst dich nur in eine Syntax und Terminologie einarbeiten.
P.S.
2. Die DMZ ( zB. 10.0.3.0/24 ) und die Verwaltung ( zB. 10.0.4.0/24 ) sollen sich einen Switch teilen, diese werden per Portisolierung voneinander getrennt, sodass jede Instanz ( DMZ und Verwaltung ) einen separaten Uplink zum CoreSwitch bekommt. Der Switch wird in Richtung 24 Port RJ45 und 4x SFP+ gehen.
Das, was du vor hast, nennt sich VLAN und wäre in jedem Fall einzusetzen.Da braucht es nicht für jedes Segment einen eigenen Switch. Zudem kannst du so Personalwesen und Produktion trennen, selbst wenn die im selben Raum sitzen würden und dadurch am selben Switch hingen.
Gruß
em-pie
Moin,
erst mal sollte dir klar sein - für gewöhnlich meint 4x 10GB (oder auch 2x 10GBit) eben nicht 40 (bzw. 20) Gbit, sondern eben wirklich 4x 10GBit (z.B. LACP). Das macht schon mal einige Rechnungen anders.
Dann solltest du dir überlegen die VLANs auch kleiner zu wählen. Bei 150 Clients würde ich z.B. gucken das ich das auf Abteilungen aufteile und VLANs mache so das ich am Ende da ggf. 20-30 Clients in nem VLAN habe. Das reduziert die Broadcasts erheblich und steigert damit die Performance.
Ausserdem kommt natürlich viel darauf an was ihr macht. Sind es 99% Office-Plätze die mal ne Word-File speichern sind die Anforderungen anders als ne Grafik-/Video-Abteilung die GByte-Grosse Dateien aufm Server bearbeiten.
Was mir auf deiner Zeichung auffällt (ggf. aber nur ein Darstellungsproblem): Ich würde ALLE Switches redundant anbinden - und je nach Modell sogar nen virtuellen Stack bauen so das die Distri's eben auch wieder einen Ring untereinander bilden. Wenn also der Uplink von einem Switch zum Core ausfällt - was solls, geht der übern "virtuellen" Stack-Ring mit..
Das wichtigste an der ganzen Sache jedoch: Du musst es am Ende verwalten können!
erst mal sollte dir klar sein - für gewöhnlich meint 4x 10GB (oder auch 2x 10GBit) eben nicht 40 (bzw. 20) Gbit, sondern eben wirklich 4x 10GBit (z.B. LACP). Das macht schon mal einige Rechnungen anders.
Dann solltest du dir überlegen die VLANs auch kleiner zu wählen. Bei 150 Clients würde ich z.B. gucken das ich das auf Abteilungen aufteile und VLANs mache so das ich am Ende da ggf. 20-30 Clients in nem VLAN habe. Das reduziert die Broadcasts erheblich und steigert damit die Performance.
Ausserdem kommt natürlich viel darauf an was ihr macht. Sind es 99% Office-Plätze die mal ne Word-File speichern sind die Anforderungen anders als ne Grafik-/Video-Abteilung die GByte-Grosse Dateien aufm Server bearbeiten.
Was mir auf deiner Zeichung auffällt (ggf. aber nur ein Darstellungsproblem): Ich würde ALLE Switches redundant anbinden - und je nach Modell sogar nen virtuellen Stack bauen so das die Distri's eben auch wieder einen Ring untereinander bilden. Wenn also der Uplink von einem Switch zum Core ausfällt - was solls, geht der übern "virtuellen" Stack-Ring mit..
Das wichtigste an der ganzen Sache jedoch: Du musst es am Ende verwalten können!
Hallo,
Nur eine Kleinigkeit am Rande:
Drucker, WLAN sind eher unsichere Netzwerkteilnehmer, Monitoring und Logging sicherheitskritische Systeme. Die würde ich separieren. Logging braucht je nach Umfang passenden Storage. Wenn ihr sowieso neu plant, schaut da nochmal drüber.
Grüße
lcer
Nur eine Kleinigkeit am Rande:
Zitat von @surreal1:
5. Zu guterletzt, wollen wir noch ein Verwaltungssystem anschaffen, wo Drucker, WLAN, Monitoring und Logging usw läuft, damit alles schön separiert wird.
5. Zu guterletzt, wollen wir noch ein Verwaltungssystem anschaffen, wo Drucker, WLAN, Monitoring und Logging usw läuft, damit alles schön separiert wird.
Drucker, WLAN sind eher unsichere Netzwerkteilnehmer, Monitoring und Logging sicherheitskritische Systeme. Die würde ich separieren. Logging braucht je nach Umfang passenden Storage. Wenn ihr sowieso neu plant, schaut da nochmal drüber.
Grüße
lcer
Könnt ihr was empfehlen?
Ja, in jedem Falle kein HP !Idealerweise realisierst du den RZ Layer 3 Core mit einem Full Stack also Stacking fähigen Switches. Die Anbindung der Access Switches dann wie immer redundant an den Core mit LACP LAGs.
Ein absolut klassisches Standard Netzdesign was dann im Endeffekt immer so aussieht:
Mit Ruckus ICX Switches bist du hier in der Tat am besten bedient denn im Stacking Bereich gehören die im Moment zu den Anbietern mit dem besten Preis Leistung Verhältnis und Performance. Wartung und Service inklusive. Chassis Switches sind mittlerweile völlig überholt.
Bei deiner Größenordnung wäre aber Ruckus ICX immer die erste Wahl wegen der Port und Stack Skalierbarkeit ! Die Kollegen oben haben es ja schon gesagt !
Von den intern überbuchten HP Gurken die noch nicht einmal von HP selber entwickelt sind sondern nur billige OEM Massenprodukte nur mit draufgebäppeltem HP Logo solltest du in deinem Projekt besser die Finger lassen !
Hey em-pie,
danke für Empfehlung. Ich habe mir die Ruckus Switche angesehen und das Preis Leistung Niveau ist definitiv in Ordnung. Viel ließt man jedoch nicht über die Marke, genau so wenig, wie einfach oder umständlich es ist diese zu konfigurieren. Vom Funktionsumfang und der Performance sollen die definitiv besser sein als Cisco und der ganze andere Kram, da du weniger an Lizenzkosten zahlst und viel mehr für dein Geld bekommst. Kannst du mir noch sagen wie es sich mit den Geräten verhällt, wenn man nicht allzu viel Erfahrung im Konfigurieren der Switche per CLI hat? Lernfähig sind wir ja alle
Hey Maretz,
das mit dem trennen der jeweiligen Clients habe ich auch schon in der Planung berücksichtigt. Ich werde jedoch pro Access Switch ein eigenes VLAN verteilen, das sollte ausreichen, wenn ich knapp 40 Clients pro Switch rechne. Auch werden die Access Switche redundant an die Cores verteilt und ein Zusatzgerät bestellt, sodass ein Ausfall eines Access Switch unter einer Stunde liegt.
Hey Icer00,
guter Hinweis. Ich habe das Netzwerk nur sehr grob geplant, die Feinheiten kommen noch, trotzdem ist das ein sehr guter Hinweis den ich berücksichtigen werden.
Hey Aqui,
okay, ich bin weg vom Thema HP. Die Zeichnung ist eine gute Referenz und wird genauso bei uns umgesetzt, das heißt 2 Cores Switche und die Access Switche redundant verteilt. Chassis sind definitiv keine Option für uns, da wie du schon erwähnt hast, ein Ausfall vom Gesamtsystem nicht tolerierbar ist. Auch an dich die Frage, wie gut man die Ruckus Switche verwalten kann. Zwar sind wir nicht unbedingt an die GUI gewöhnt, jedoch ist die im Zweifel bei unbekannt Geräten einfacher Hand zu haben als eine CLI, an die man sich erstmal rantasten muss.
Danke euch allen für das Feedback!
danke für Empfehlung. Ich habe mir die Ruckus Switche angesehen und das Preis Leistung Niveau ist definitiv in Ordnung. Viel ließt man jedoch nicht über die Marke, genau so wenig, wie einfach oder umständlich es ist diese zu konfigurieren. Vom Funktionsumfang und der Performance sollen die definitiv besser sein als Cisco und der ganze andere Kram, da du weniger an Lizenzkosten zahlst und viel mehr für dein Geld bekommst. Kannst du mir noch sagen wie es sich mit den Geräten verhällt, wenn man nicht allzu viel Erfahrung im Konfigurieren der Switche per CLI hat? Lernfähig sind wir ja alle
Hey Maretz,
das mit dem trennen der jeweiligen Clients habe ich auch schon in der Planung berücksichtigt. Ich werde jedoch pro Access Switch ein eigenes VLAN verteilen, das sollte ausreichen, wenn ich knapp 40 Clients pro Switch rechne. Auch werden die Access Switche redundant an die Cores verteilt und ein Zusatzgerät bestellt, sodass ein Ausfall eines Access Switch unter einer Stunde liegt.
Hey Icer00,
guter Hinweis. Ich habe das Netzwerk nur sehr grob geplant, die Feinheiten kommen noch, trotzdem ist das ein sehr guter Hinweis den ich berücksichtigen werden.
Hey Aqui,
okay, ich bin weg vom Thema HP. Die Zeichnung ist eine gute Referenz und wird genauso bei uns umgesetzt, das heißt 2 Cores Switche und die Access Switche redundant verteilt. Chassis sind definitiv keine Option für uns, da wie du schon erwähnt hast, ein Ausfall vom Gesamtsystem nicht tolerierbar ist. Auch an dich die Frage, wie gut man die Ruckus Switche verwalten kann. Zwar sind wir nicht unbedingt an die GUI gewöhnt, jedoch ist die im Zweifel bei unbekannt Geräten einfacher Hand zu haben als eine CLI, an die man sich erstmal rantasten muss.
Danke euch allen für das Feedback!
Viel ließt man jedoch nicht über die Marke, genau so wenig, wie einfach oder umständlich es ist diese zu konfigurieren.
Das sind ex Brocade Switches. (Der Cisco im SAN Bereich) Mit dem Übergang von Brocade in Broadcom sind die Switches an Ruckus übergegangen. Kein Niche Player also.Sie besitzen ein Cisco CLI was die HP Gurken ja mehr oder weniger auch haben. Die Kommando Syntax ist da ja zu 98% identisch. Mit anderen Worten jeder der Cisco und HP kann, kann auch Ruckus.
Für die etwas einfacher gestrickte Klicki Bunti Fraktion haben sie aber selbstredend auch ein vollständiges GUI zum Mamagement an Bord.
Nutzt man von Ruckus auch die WLAN Lösung kann man die Switches zusätzlich sowohl über die Controller lose "Unleashed" Lösung über das onboard AP Management grafisch verwalten und managen als auch über einen separaten WLAN Controller. LAN und WLAN sind also Management seitig integriert.
Zudem haben sie natürlich auch alle Schnittstellen für freie Management Systeme wie Observium, Nagios und Co.
Mit anderen Worten: Du machst damit nichts falsch.
