Produktauswahl in der Netzwerkinfrastruktur: Strategische Kriterien und Praxiserfahrungen

Die Realität von Switch – Firewall – AP Auswahl, Integration und Kapazität

Die meisten Netzwerkprojekte in Unternehmen beginnen am selben Punkt: der Produktauswahl. Und meistens scheitern sie am selben Punkt: Die Produkte arbeiten nicht zusammen. Denn das, was wir als „Core-Netzwerk“ bezeichnen, ist nicht einfach nur die Tatsache, dass drei Boxen (Switch, Firewall, Access Point) nebeneinander stehen; es geht darum, dass diese drei Komponenten gemeinsam eine Identität tragen, Segmente bilden, Richtlinien erzwingen und – was am wichtigsten ist – den operativen Betrieb gemeinsam aufrechterhalten.

Was ich über die Jahre beobachtet habe, ist Folgendes: Das Netzwerk eines Unternehmens ist oft nicht deshalb schlecht, weil die Hardware minderwertig ist, sondern weil der Entscheidungsmechanismus des Netzwerks fragmentiert ist. Man hat die teuersten Geräte, die besten Lizenzen, den höchsten Durchsatz… Alles ist vorhanden; aber im Ernstfall weiß niemand, welches Gerät auf Basis welchen Kontexts entscheidet, wo der Traffic getrennt wird, wo er kontrolliert wird – auf diese Fragen gibt es keine klaren Antworten. Das Ergebnis: Man hat zwar ein „Netzwerk“, aber kein „Netzwerkverhalten“.

In diesem Artikel werde ich das Core-Netzwerk anhand von drei Säulen behandeln: Firewall, Switching, Access (Wi-Fi). Aber bevor ich beginne, möchte ich eines klarstellen: Im Auswahlprozess gibt es zwei Faktoren, die ebenso entscheidend sind wie die „technischen Spezifikationen“, die viele Teams jedoch erst zu spät bemerken: Berichte/Validierung und Support/Lifecycle.

Berichte, Tests und das Filtern von „Marketing-Lärm“

Ein Anhaltspunkt bei der Produktauswahl sind natürlich die Gartner-Berichte. Denn Berichte wie die von Gartner geben Ihnen eine Vorstellung von der „Marktposition“ eines Produkts: Wer ist Marktführer, wer ist Visionär, wer besetzt eine Nische. Dies ist besonders nützlich, um die Entscheidungsträger zu überzeugen; es bietet einen Rahmen für die Frage „Warum diese Marke?“ am Budgettisch.

Aber hier gibt es eine kritische Falle: Gartner sagt Ihnen nicht, welches Produkt für Ihr spezielles Szenario das richtige ist. Gartner ist eine „Marktkarte“; Ihre Aufgabe ist es, eine „Architekturkarte“ zu zeichnen. Daher ist es besser, Gartner als ersten Filter zu verwenden: Es schränkt die Optionen ein, trifft aber nicht die endgültige Entscheidung.

Zusätzlich zu Gartner sollten Leistungs- und Sicherheitstests der Hersteller oder unabhängiger Labore, Vergleichsberichte und „Real-World“-Benchmarks einbezogen werden. Denn der Durchsatz in einem Datenblatt ist nicht derselbe wie der Durchsatz in der Realität, wenn IPS aktiviert ist, SSL-Entschlüsselung läuft und App-Control aktiv ist. Berichte dienen hier als zweiter Filter: Man sucht nach einer Antwort abseits des Marketings auf die Frage: „Was leistet diese Box unter dieser spezifischen Last wirklich?“

Support und Lifecycle: Die unsichtbare Säule, die das Projekt stützt

Ebenso kritisch wie die technischen Fähigkeiten eines Produkts sind dessen Support-Modell und Lebenszyklus. Denn ein Netzwerkdesign besteht nicht nur aus dem „Tag der Installation“. Die eigentliche Frage ist, was in 3 Jahren passieren wird:

• Was sind die EoL- / EoS-Daten (End of Life / End of Support) für dieses Produkt?
• Wie schnell werden Patches, Bugfixes und Sicherheitsupdates bereitgestellt?
• Ist der TAC/Support wirklich erreichbar, und wie funktioniert der Eskalationsprozess?
• Wie sehen die RMA-Prozesse und die Realität der Ersatzteilversorgung aus?
• Wird das Lizenzmodell nach einem Jahr Überraschungen bereithalten?
• Entspricht die Roadmap des Herstellers der Richtung, in die Sie gehen?

Ich möchte dies explizit in den Artikel aufnehmen, da dies das häufigste Problem ist, das ich in der Praxis sehe: Ein Team wählt ein Produkt aus, das technisch nahezu korrekt ist, aber aufgrund von Support/Lifecycle wird der Betrieb 12 Monate später zum Albtraum. Dann wird das Gerät beschuldigt; dabei liegt das Problem weniger am Gerät selbst als vielmehr daran, dass die „Support“-Seite bei der Auswahl nicht ernst genommen wurde.

Firewall: UTM, NGFW oder mehrere Rollen?

Die Firewall ist heute längst nicht mehr nur das „Sicherheitsgerät am Rand“ des Netzwerks. Richtig positioniert, ist sie das Gehirn der Richtlinien; falsch positioniert, wird sie zum Flaschenhals, weil alles auf sie abgeladen wird.

Hier ist es sinnvoll, die Terminologie von Anfang an zu klären: Die Konzepte UTM und NGFW werden in vielen Umgebungen vermischt.

Der UTM-Ansatz steht im Allgemeinen für das Denken „Alles in einer Box“: Basis-Firewall + IPS + Webfilter + AV + einige Gateway-Funktionen… Besonders in kleinen bis mittleren Strukturen wird er aufgrund der einfachen Verwaltung und des Paketansatzes bevorzugt.

NGFW hingegen positioniert sich durch Anwendungserkennung (Application Awareness), Benutzer-/Identitätserkennung, fortschrittlichere Sicherheitsdienste und Richtlinientiefe. Für die heutigen Anforderungen von Unternehmen reicht es oft nicht aus, die Sicherheit nur über „Port-Protokoll“ zu steuern; hier kommt die NGFW ins Spiel.

Aber der eigentliche kritische Punkt ist dieser: Der Bedarf eines Unternehmens endet möglicherweise nicht bei einem einzigen „Firewall-Typ“. Denn das, was wir als Firewall bezeichnen, kann tatsächlich unterschiedliche Rollen auf verschiedenen Ebenen für unterschiedliche Zwecke übernehmen.

Warum zwei (oder sogar drei) Firewalls in derselben Firma normal sind

In vielen Institutionen sind folgende Szenarien sehr sinnvoll:

• Perimeter/Internet Edge Firewall: Internetausgang, VPN, NAT, Inbound/Outbound-Richtlinien.
• Internal Segmentation Firewall (ISFW): Segmentierung im internen Netzwerk, East-West-Kontrolle, kritische Zonen.
• Data Center / High-performance FW: Rechenzentrum-Traffic, hohe Session-Zahlen, hoher PPS, niedrige Latenzanforderungen.
• In einigen Strukturen zusätzlich Komponenten wie WAF oder Cloud-Firewalls.

Dies bedeutet nicht „zwei Firewalls kaufen“; es bedeutet, „zwei verschiedene Aufgaben dem richtigen Werkzeug zu übertragen“. Wenn man alles in eine Box packt, verliert man entweder an Leistung, an Management-Übersicht oder an Sicherheit. In der Regel geht mindestens eines dieser drei Dinge verloren.

Und das führt uns direkt zur Kapazitätsplanung.

Firewall-Kapazitätsplanung: Durchsatz allein kann lügen

Der gefährlichste Fehler bei der Firewall-Auswahl ist, nur auf die Zahl „Gbps Throughput“ zu schauen. Denn in der Realität wird eine Firewall oft nicht durch den Durchsatz getötet, sondern durch:

• PPS (Packets per second)
• Anzahl gleichzeitiger Sessions (Concurrent Sessions)
• New Session Rate (Neue Sessions pro Sekunde)
• NAT-Tabelle und State-Management
• Leistung bei aktiviertem IPS/AV/App-ID
• Schwere Arbeitslasten wie SSL/TLS-Entschlüsselung
• Log-Erzeugung und Log-Transport (SIEM-Integration)

Ein Beispiel aus der Realität: Der Satz „Wir haben eine 10-Gbps-Firewall gekauft“ hat für sich allein keine Bedeutung. Denn diese 10 Gbps sind in den meisten Hersteller-Datenblättern eine Messung unter „idealen Bedingungen“. Wenn in Ihrer Umgebung IPS, URL-Filterung, App-Control und Entschlüsselung aktiv sind, ändert sich die tatsächliche Kapazität dramatisch. Daher sollte die richtige Frage lauten: „Wie viel Last bewältigt diese Firewall mit den von mir aktivierten Sicherheitsfunktionen unter meiner spezifischen Traffic-Charakteristik?“

Wenn es keine Antwort auf diese Frage gibt, ist die Auswahl riskant.

Switching: Die Last und Rolle sind wichtiger als die Port-Anzahl

Die Auswahl eines Switches beginnt oft mit der Anzahl der Ports: Wie viele Kupferports, wie viele Glasfaserports, wird PoE benötigt oder nicht… Diese sind natürlich wichtig, aber aus der Perspektive des Core-Netzwerks nicht ausreichend. Denn ein Switch ist nicht nur eine Steckdose, die Endpunkte verbindet; er ist ein Entscheidungspunkt, der bestimmt, wo sich der Traffic konzentriert, wo er getrennt und wo er nach oben transportiert wird.

Insbesondere auf der Seite der Access-Switches ist der häufigste Fehler, die Port-Planung basierend auf dem heutigen Bedarf vorzunehmen. Dabei ist der Access-Layer die Ebene im Netzwerk, die sich am schnellsten ändert. An einem Punkt, der heute für Kupferports ausreichend erscheint, könnte morgen ein AP mit hohem Bandbreitenbedarf, eine Kamera oder ein anderes Edge-Gerät stehen. Daher werden die Geschwindigkeitsfähigkeiten der Kupferports (1G, 2.5G/5G), die Nachhaltigkeit des PoE-Budgets pro Port (nicht nur die Gesamtwattzahl) und die tatsächliche Kapazität der Uplinks entscheidend.

Das Thema Uplink wird oft unterschätzt. Sätze wie „2×10G Uplink reichen aus“ hört man oft, aber über die Traffic-Charakteristik, die diese Uplinks tragen werden, wird selten gesprochen. Wenn die Benutzerzahl am Access-Layer steigt und sich der East-West-Traffic sowie das Broadcast-Verhalten ändern, können Uplinks viel schneller als erwartet gesättigt sein. An diesem Punkt sollte man nicht nur auf die Uplink-Geschwindigkeit schauen, sondern auf die Backplane-Kapazität des Switches und die Oversubscription-Raten. Denn ein Uplink kann 10G sein, aber wenn die interne Architektur des Switches dies nicht unterstützt, ist der Flaschenhals unvermeidlich.

Der Unterschied zwischen einem Edge-Switch und einem Datacenter-Switch wird in vielen Projekten ebenfalls nicht klar gezogen. Edge-Switches sind in der Regel für Benutzer- und Gerätedichte optimiert: viele Ports, PoE, zugriffsorientierte Funktionen. Datacenter-Switches hingegen kommen mit hohem Durchsatz, niedriger Latenz, hoher PPS-Leistung und einer Architektur, die East-West-Traffic bewältigt. Beides von demselben Gerät zu erwarten, erhöht entweder die Kosten unnötig oder senkt die Leistung unter das erwartete Niveau. Bei der Gestaltung eines Core-Netzwerks sollte die Frage „Wo wird dieser Switch stehen und was wird er tragen?“ vor der Frage „Wie viele Ports hat er?“ kommen.

Inter-VLAN-Routing-Entscheidungen stehen ebenfalls in direktem Zusammenhang mit der Switch-Auswahl. Wenn das Routing auf dem Switch durchgeführt werden soll, reicht es nicht aus, dass dieser Switch lediglich L3 unterstützt; Route-Scale, TCAM-Kapazität, die Anwendbarkeit von Richtlinien und die Integration dieser Entscheidungen in die Firewall müssen bedacht werden. Andernfalls kann ein Design, das anfangs wie ein Leistungsgewinn aussieht, später zu einem unkontrollierbaren Chaos führen.

Access / Wi-Fi: Der Uplink und die Kontrollebene sind ebenso Teil der Architektur wie der Funk

Wenn über drahtlose Netzwerke gesprochen wird, liegt der Fokus meist auf dem Wi-Fi-Standard: Wi-Fi 6, 6E, 7… Dabei wird die drahtlose Leistung in der Praxis oft nicht durch die Luft, sondern durch das Kabel begrenzt. Egal wie leistungsstark ein Access Point ist, wenn der Uplink dahinter dies nicht tragen kann, haben theoretische Geschwindigkeiten keine Bedeutung.

Heute können viele Enterprise-APs ihr Potenzial nicht annähernd ausschöpfen, wenn sie durch einen 1-Gbps-Uplink begrenzt sind. Daher ist die Unterstützung von 2.5G und 5G Kupfer-Uplinks, insbesondere in Umgebungen mit hoher Benutzerdichte, kein „Luxus“, sondern eine direkte Designanforderung. Aber auch hier darf die Kette nicht reißen: Der AP mag 2.5G unterstützen, aber wenn der Switch-Port, an dem er angeschlossen ist, dies nicht tut, ist die gesamte Investition umsonst. AP- und Switch-Auswahl sollten daher gemeinsam und nicht getrennt erfolgen.

Ein weiteres kritisches Thema auf der Wi-Fi-Seite ist die Controller-Architektur. Die Anzahl der vom Controller unterstützten APs, die gleichzeitige Client-Kapazität und das Roaming-Verhalten bestimmen die Stabilität des Netzwerks in der Realität. Ein Controller, auf dem auf dem Papier „unterstützt 500 APs“ steht, kann in einer Umgebung mit hoher Dichte und schnellem Roaming-Bedarf viel früher als erwartet an seine Grenzen stoßen. Die Controller-Kapazität sollte nicht nur nach der Anzahl der Lizenzen bewertet werden, sondern zusammen mit CPU, Speicher, Session-Handling und der Kapazität zur Richtliniendurchsetzung (Policy Enforcement).

Darüber hinaus werden drahtlose Netzwerke oft wie der „Edge“ betrachtet, aber in Wirklichkeit sind sie die Ebene, die das Core-Netzwerk am schnellsten belastet. Benutzer sind mobil, Verbindungen werden häufig getrennt und neu aufgebaut, der Zyklus von Authentifizierung und Richtlinienanwendung ist viel intensiver als im kabelgebundenen Bereich. Daher verursacht ein kleiner Designfehler auf der Access-Ebene unerwartete Lasten im Core-Netzwerk. Die AP-Auswahl ist nicht nur eine Berechnung der Abdeckungsfläche; es ist eine architektonische Entscheidung, die das Verhalten des Core-Netzwerks direkt beeinflusst.

Fazit: Herstellerwahl, architektonische Reife und Realitäten

An diesem Punkt möchte ich besonders betonen: Was ich unten erwähne, basiert vollständig auf meinen persönlichen Praxiserfahrungen und Beobachtungen. Meine Absicht ist es weniger, einen Hersteller zu loben oder zu kritisieren, sondern vielmehr offen zu sagen, wo sie stark sind und wo sie Schwierigkeiten haben. Denn Core-Netzwerk-Design wird nicht durch Markenfatalismus, sondern durch reale Bedürfnisse und operative Realitäten bestimmt.

Mit Cisco zu beginnen, ist natürlich. Im Bereich Switching und Routing sind sie immer noch einer der stärksten Akteure der Branche. Insbesondere in großen und komplexen Strukturen verfügen sie über eine enorme Reife im Bereich Campus- und Datacenter-Switching. Auch im Wireless-Bereich sind sie seit vielen Jahren stark; es gibt dort ein beträchtliches Ökosystem und einen großen Erfahrungsschatz. Auf der Firewall-Seite haben sie insbesondere nach dem asiatischen Markt und Akquisitionen wie Sourcefire eine ernsthafte Entwicklung gezeigt; im NGFW-Bereich befinden sie sich nun in einer wettbewerbsfähigeren Position. Man muss jedoch klar sagen: Wenn Sie alle Produkte von Cisco wählen, kann die Integration dieser Produkte untereinander für einen Administrator oft ermüdend und mühsam sein. Alles ist möglich, aber es ist oft nicht „einfach“; es erfordert ernsthaften Einsatz und Erfahrung auf der Integrationsseite.

Die HPE Aruba-Seite, deren Entwicklung ich seit etwa zehn Jahren eng verfolge, bietet eine andere Geschichte. Als ich zum ersten Mal in dieses Ökosystem eintrat, war die Produktpalette recht begrenzt. Im Laufe der Zeit wurde das Portfolio durch HPs Aruba-Akquisitionen erweitert; heute, mit der Hinzufügung der Juniper-Produktfamilie, wächst das Spektrum erheblich. Auf der Switching-Seite hat die Aruba-Familie eine sehr verbreitete und loyale Nutzerbasis. Auf der Wireless-Seite verfügen sie meiner persönlichen Meinung nach, auch beeinflusst durch die Aruba-Herkunft, über eine der stärksten Wi-Fi-Lösungen der Branche. Im Bereich Routing gab es in der Vergangenheit Lücken; ich denke jedoch, dass diese Lücke mit der Juniper-Produktfamilie weitgehend geschlossen wird. Im Gegensatz dazu führt das Fehlen einer eigenen starken Firewall-Produktfamilie dazu, dass sie in diesem Bereich ein Stück weit unvollständig bleiben.

Fortinet bietet eine sehr breite Produktpalette an. Die Möglichkeit, eine komplette Lösung für Firewall, Switching und Wireless „unter einem Dach“ anzubieten, ist für viele Institutionen ein ernsthafter Vorteil. Da Fortinets Wurzeln in der Sicherheit liegen, ist bekannt, dass sie auf der Firewall-Seite sehr stark sind. Die Switching-Produktfamilie begann erst relativ spät zu reifen; daher dauerte es Zeit, bis sie sich verbreitete, aber in den letzten Jahren sehen wir sie in der Praxis immer häufiger. Einer der größten Pluspunkte des Fortinet-Ökosystems ist meiner Meinung nach die Benutzerfreundlichkeit und die einfache Benutzeroberfläche. Die Integration der Produkte untereinander ist vergleichsweise schmerzlos, was die operative Last erheblich senken kann. Besonders in Unternehmen mit begrenzten IT-Teams ist dieser Unterschied sehr deutlich spürbar.

Wenn wir zur Seite von Palo Alto Networks kommen, wird das Bild klarer: Palo Alto ist im Bereich Firewalls sehr stark und unbestritten einer der führenden Hersteller in diesem Feld. Sie steigen jedoch bewusst nicht in Bereiche wie Switching oder Wireless ein; das ist ohnehin nicht ihr Fokus. Viele Unternehmen bevorzugen Palo Alto ausschließlich auf der Firewall-Seite, und dafür gibt es sehr logische Gründe. Ich denke, dass Palo Alto in Bereichen wie Application Visibility, Richtlinientiefe und insbesondere SASE einen ernsthaften Unterschied macht. Dass sie heute einer der weltweit größten Cybersicherheitshersteller sind, ist kein Zufall. Es ist ganz natürlich, dass sich viele Institutionen, die im Firewall-Bereich das „Beste“ suchen, Palo Alto zuwenden.

In der Realität können Unternehmen für diese drei grundlegenden Produktgruppen sehr unterschiedliche Entscheidungen treffen. Einige Institutionen bevorzugen es, mit einem einzigen Hersteller voranzugehen: Switch, Wireless und Firewall sollen von derselben Marke sein; Integration und Support sollen aus einer Hand kommen, damit bei Problemen der Ansprechpartner feststeht. Einige Institutionen verwenden einen Hersteller auf der Firewall-Seite und einen anderen für Switch und Wireless. In reiferen Strukturen ist es sogar üblich, jede Ebene von verschiedenen Herstellern zu wählen.

Diese Vorlieben sind oft ebenso organisatorisch wie technisch. Die Sicht des Unternehmens auf die IT, die Teamstruktur, die Gewohnheiten der Netzwerk-Mitarbeiter und frühere Erfahrungen beeinflussen diese Entscheidungen maßgeblich. Hier gibt es nicht die eine richtige Lösung. Meine persönliche Meinung ist: Es gibt Hersteller, die sich in jedem Bereich mehr bewiesen haben, und wenn das IT-Team reif genug ist, um diese Unterscheidung zu managen, kann die Wahl verschiedener Hersteller für verschiedene Ebenen technisch viel stärkere Ergebnisse liefern. Andererseits ziehen es einige Institutionen vor, sich nicht mit Integrationsproblemen, Installationskomplexität und Konfigurationsfehlern auseinanderzusetzen, und entscheiden sich daher für einen einzigen Hersteller, um alle Probleme über einen einzigen Supportkanal zu lösen. Auch dies ist ein völlig legitimer Ansatz.

Schließlich gibt es einen Punkt, den ich besonders unterstreichen möchte: Heutzutage investieren fast alle großen Hersteller massiv in den Bereich Automatisierung. An diesem Punkt ist die API-Unterstützung von Produkten kein „Extra“ mehr, sondern ein direktes Auswahlkriterium. Was über APIs gemacht werden kann, was automatisiert werden kann, wie offen die Integration ist; dies alles muss bei der Produktauswahl auf dem Tisch liegen.

Wie ich bereits in meinem ersten Artikel erwähnt habe, sollte die Produktauswahl meiner Meinung nach nicht als eine Schicht betrachtet werden, die erst nachträglich zu den Automatisierungsprozessen hinzugefügt wird. Im Gegenteil, Automatisierung und operative Prozesse sollten an der Spitze der Pyramide stehen; die Produkte sollten nach diesem Rahmen ausgewählt werden. Die Frage, welcher Switch, welche Firewall, welcher AP, sollte erst nach der Frage „Wie werde ich diese Architektur automatisch verwalten?“ kommen. Meiner Meinung nach beginnt genau hier ein korrektes Core-Netzwerk-Design.

Serverraum und Verkabelung: Die Realität, über die niemand sprechen will, für die aber jeder den Preis zahlt

In Netzwerkprojekten wird meist über die „glanzvollen“ Themen gesprochen: welcher Switch, welche Firewall, welche Wireless-Lösung… Aber ein erheblicher Teil der in der Praxis auftretenden Probleme beginnt an einem viel grundlegenderen Ort: dem Serverraum-Design und der Verkabelungsinfrastruktur.

Es gibt eine Realität, die ich über die Jahre hinweg immer wieder gesehen habe: Egal wie gute Produkte Sie wählen, egal wie korrekt Sie die Architektur aufbauen; wenn der Serverraum und die Verkabelungsinfrastruktur schwach sind, wird dieses Netzwerk früher oder später Probleme produzieren. Und diese Probleme erscheinen meist wie ein „Netzwerkfehler“, aber die Ursache ist niemals wirklich das Netzwerk selbst.

Der Serverraum wird in vielen Unternehmen immer noch wie ein „Abstellraum“ behandelt. Zuerst werden ein paar Racks in einem kleinen Bereich aufgestellt, mit der Zeit kommen neue Geräte hinzu, Kabel stapeln sich übereinander, temporäre Lösungen werden dauerhaft. Ab einem gewissen Punkt entsteht ein Bereich, den niemand mehr berühren möchte, von dem aber jeder abhängig ist. Genau hier beginnt das eigentliche Risiko.

Ein Serverraum ist nicht nur ein Ort, an dem Geräte stehen. Dieser Raum ist das Herz des Netzwerks. Wärme, Energie, Luftstrom, Zugänglichkeit und Ordnung; alles muss gemeinsam betrachtet werden. Zum Beispiel wird das Thema Kühlung oft zu spät bemerkt. Die Geräte scheinen zu laufen, aber der dauerhafte Betrieb bei hohen Temperaturen beeinträchtigt sowohl die Leistung als auch die Lebensdauer der Hardware erheblich. Plötzliche Reboots, unerwartete Freezes oder Fehler, die „von Zeit zu Zeit“ auftreten, haben oft eine unzureichende Kühlung als Ursache.

Auch die Energieseite wird ähnlich unterschätzt. Geräte mit redundanten Netzteilen werden gekauft, aber es wird nicht geprüft, ob diese Netzteile tatsächlich an unterschiedliche Stromkreise angeschlossen sind. Man sagt, es gäbe eine USV, aber eine Kapazitätsberechnung wird nicht durchgeführt. Es ist nicht klar, wie lange die Systeme bei einem Stromausfall online bleiben. Dies mögen auf dem Papier kleine Details sein, aber in einem Krisenmoment machen sie die gesamte Architektur bedeutungslos.

Die Verkabelungsinfrastruktur wird meist als etwas betrachtet, das man „einmal macht und dann vergisst“. Dabei ist die Verkabelung der langlebigste Teil des Netzwerks. Sie tauschen den Switch, die Firewall, den Access Point aus; aber das Kabel bleibt dort. Daher ist einer der größten Fehler, die Verkabelung nach dem heutigen Bedarf zu planen. Eine Infrastruktur, die heute für 1G als ausreichend geplant wurde, wird morgen mit APs, die 2.5G/5G-Uplinks benötigen, oder Edge-Geräten mit höherem Geschwindigkeitsbedarf an eine ernsthafte Grenze stoßen.

Wo und zu welchem Zweck Glasfaser- und Kupferkabel verwendet werden, ist ebenfalls eine architektonische Entscheidung. Nur weil „Glasfaser schneller ist“, überall Glasfaser zu ziehen, ist auch nicht richtig; es gibt immer noch viele Bereiche, in denen Kupfer vorteilhaft ist, etwa wenn PoE benötigt wird oder bei Kurzstreckenverbindungen. Das eigentliche Thema ist, die Verkabelung so zu gestalten, dass sie zukünftige Erweiterungen zulässt. Patchpanel-Ordnung, Kabelbeschriftung, Kabelmanagement im Rack und zwischen den Racks… Dies sind keine ästhetischen Fragen, sondern direkt operative Themen.

Jede Änderung in einer schlecht beschrifteten Verkabelungsinfrastruktur ist ein Risiko. Während Sie einen Port schließen, beeinträchtigen Sie versehentlich das falsche Gerät; während Sie ein Kabel abziehen, unterbrechen Sie einen anderen Dienst. Später heißt es dann wieder „das Netzwerk ist schon wieder weg“. Dabei ist das Problem nicht das Netzwerk, sondern die vor Jahren nachlässig durchgeführte Verkabelung.

Auch die Zugangssicherheit des Serverraums wird oft außer Acht gelassen. Wer diesen Raum betreten darf, wer zu welchen Zeiten Zugang hat, wie vorgenommene Änderungen dokumentiert werden; wenn dies nicht klar ist, verlieren selbst die besten Sicherheitsrichtlinien irgendwann ihren Sinn. In einer Umgebung, in der Sie den physischen Zugang nicht kontrollieren können, bleibt die Diskussion über logische Sicherheit meist theoretisch.

Aus meiner Sicht sind Serverraum und Verkabelung nicht die „untere Schicht“ des Core-Netzwerk-Designs; sie sind das Fundament. Egal wie anspruchsvolle Lösungen Sie darauf aufbauen, wenn das Fundament schwach ist, wird die Struktur wackeln. Daher sollte man beim Netzwerkdesign nicht nur auf die Diagramme schauen, sondern auch auf die physische Umgebung, in der diese Diagramme zum Leben erweckt werden. Rack-Ordnung, Kabelwege, Energie- und Kühlungsplanung; all dies ist Teil der Architektur.

Diese Themen sind meist nicht spannend, nehmen in Präsentationen nicht viel Platz ein und sind schwer in einen Lebenslauf zu schreiben. Aber die Realität ist, dass hinter einem gut funktionierenden Netzwerk meist ein gut gestalteter Serverraum und eine saubere Verkabelungsinfrastruktur stehen. Niemand bemerkt es; weil es eben keine Probleme gibt. Und meiner Meinung nach ist dies das größte Lob, das ein Infrastrukturdesign erhalten kann.

Notiz

Dieser Artikel wurde ursprünglich auf Substack in einer kürzeren, erzählerischen Form veröffentlicht. Diese Version erweitert die architektonischen Grundlagen der Serie.

👉 Artikel auf Substack lesen: Hier klicken