Switch, Firewall und AP jenseits des Datenblatts bewerten

Die meisten Unternehmensnetzwerkprojekte beginnen am gleichen Punkt: der Produktauswahl. Und die meisten scheitern am gleichen Punkt: Produkte arbeiten nicht zusammen. Denn was wir ein “Core-Netzwerk” nennen, sind nicht nur drei Boxen nebeneinander; es geht darum, dass diese drei Komponenten gemeinsam Identität tragen, gemeinsam segmentieren, gemeinsam Policies durchsetzen und vor allem gemeinsam den Betrieb aufrechterhalten.

Was ich über die Jahre beobachte: Ein Unternehmen kämpft nicht, weil sein Netzwerk “schlecht” ist, sondern weil der Entscheidungsmechanismus des Netzwerks fragmentiert ist. Die teuersten Geräte, die besten Lizenzen, der höchste Durchsatz — alles vorhanden. Aber wenn ein Incident eintritt, weiß niemand, welches Gerät mit welchem Kontext entscheidet, wo Traffic divergiert oder wo er kontrolliert wird. Das Ergebnis: Es gibt ein “Netzwerk,” aber kein “Netzwerkverhalten.”

In diesem Artikel teile ich ein praxiserprobtes Framework zur Bewertung von Core-Network-Produkten über drei Säulen: Firewall, Switching und Access (Wi-Fi). Aber vorab: Zwei Faktoren sind genauso entscheidend wie “technische Spezifikationen” — und die meisten Teams erkennen das zu spät: Reports/Validierung und Support/Lifecycle.

Für die architektonische Philosophie hinter diesem Auswahlprozess: IT-Infrastruktur ist keine Produktsammlung

Schritt 1: Reports, Tests und Marketing-Rauschen filtern

Eine der ersten Referenzen bei der Produktauswahl sind, ja, Gartner-Reports. Sie geben eine Vorstellung von der Marktposition eines Produkts: Wer ist Leader, wer Visionär, wer spielt in einer Nische. Das ist besonders nützlich, um Entscheidungsträger zu überzeugen.

Aber es gibt eine kritische Falle: Gartner sagt Ihnen nicht, welches Produkt für Ihr spezifisches Szenario richtig ist. Gartner ist eine Marktkarte; Ihre Aufgabe ist es, die Architekturkarte zu zeichnen. Nutzen Sie Gartner als ersten Filter — er grenzt Optionen ein, trifft aber keine endgültige Entscheidung.

Zusätzlich zu Gartner müssen Performance- und Sicherheitstests von Herstellern oder unabhängigen Laboren, Vergleichsberichte und Real-World-Benchmarks berücksichtigt werden. Der Durchsatz auf einem Datenblatt ist nicht derselbe wie der Durchsatz in Produktion, wenn IPS aktiv ist, SSL-Entschlüsselung läuft und App-Control eingeschaltet ist.

Schritt 2: Support und Lifecycle — Die unsichtbaren Säulen

Die technischen Fähigkeiten eines Produkts sind nur die halbe Geschichte. Das Supportmodell und der Lifecycle sind ebenso kritisch. Netzwerkdesign endet nicht am Installationstag. Die eigentliche Frage ist: Was passiert 3 Jahre später?

• Wie lauten die EoL / EoS-Daten?
• Wie schnell kommen Patches, Bugfixes und Security-Updates?
• Ist TAC/Support wirklich zugänglich?
• Was ist die Realität der RMA-Prozesse?
• Wird das Lizenzmodell nach Jahr eins Überraschungen bringen?
• Passt die Vendor-Roadmap zu Ihrer strategischen Richtung?

Das häufigste Problem im Feld: Das Team wählt ein technisch solides Produkt, aber weil Support/Lifecycle deprioritisiert wurde, wird der Betrieb 12 Monate später zum Alptraum. Das Gerät bekommt die Schuld — aber das eigentliche Problem war nie das Gerät.

Schritt 3: Die Firewall-Schicht bewerten

Die Firewall hat längst aufgehört, nur ein “Sicherheitsgerät am Netzwerkrand” zu sein. Richtig positioniert ist sie das Policy-Gehirn der Architektur. Falsch positioniert wird sie zum Bottleneck.

UTM vs. NGFW — eine notwendige Unterscheidung:

Der UTM-Ansatz folgt der “alles in einer Box”-Philosophie: Firewall + IPS + Web-Filter + AV + Gateway-Funktionen. In kleineren Umgebungen wegen Verwaltungseinfachheit und gebündelter Lizenzierung bevorzugt.

NGFW ist um Anwendungsbewusstsein, Benutzer/Identitätskontext und tiefere Policy-Kontrolle herum positioniert. In modernen Enterprise-Umgebungen reicht die Sicherheit nur auf Port/Protokoll-Basis nicht mehr aus.

Warum zwei oder drei Firewalls in derselben Organisation normal ist:

• Perimeter/Internet Edge Firewall: Internet-Egress, VPN, NAT, Inbound/Outbound-Policy
• Internal Segmentation Firewall (ISFW): East-West-Kontrolle, interne Segmentierung
• Datacenter / High-Performance FW: DC-Traffic, hohe Session-Zahlen, hohe PPS, geringe Latenz

Für einen tieferen Blick auf Firewall-Architektur im breiteren Netzwerkdesign: Switch, Firewall, AP — Warum die richtige Produktwahl allein nicht ausreicht

Schritt 4: Firewall-Kapazitätsplanung — Durchsatz kann lügen

Der gefährlichste Fehler bei der Firewall-Auswahl ist, sich nur auf die Gbps-Zahl zu konzentrieren. In der Praxis scheitern Firewalls selten am Durchsatz — sie scheitern an:

• PPS (Packets per Second)
• Anzahl gleichzeitiger Sessions
• New-Session-Rate
• NAT-Tabellen und State-Handling
• Performance mit aktivem IPS/AV/App-ID
• SSL/TLS-Entschlüsselungslast
• Log-Generierung und SIEM-Transport

Die richtige Frage ist immer:

“Mit den Sicherheitsfunktionen, die ich aktivieren werde, und meinem spezifischen Traffic-Profil — wie viel Last kann diese Firewall tatsächlich tragen?”

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

Schritt 5: Switch-Bewertung — Rolle und Last statt Portanzahl

Die Switch-Auswahl beginnt oft mit Portanzahlen. Diese sind wichtig — aber aus Core-Network-Perspektive nicht ausreichend. Ein Switch ist nicht nur eine Steckdose; er ist ein Entscheidungspunkt, der bestimmt, wo Traffic sich konzentriert, divergiert und nach oben getragen wird.

Der häufigste Access-Layer-Fehler: nur für den heutigen Bedarf planen. Der Access-Layer ist die sich am schnellsten verändernde Schicht. Multi-Gig-Ports (2,5G/5G), PoE-Nachhaltigkeit pro Port und echte Uplink-Kapazität werden kritisch.

Uplinks werden konsequent unterschätzt. “2×10G Uplinks reichen” hört man oft — ohne das Traffic-Profil zu analysieren. Backplane-Kapazität und Oversubscription-Ratios sind genauso wichtig wie die Uplink-Geschwindigkeit.

Beim Entwurf des Core-Netzwerks muss die Frage “Wo steht dieser Switch und welchen Traffic trägt er?” vor “Wie viele Ports hat er?” kommen.

Schritt 6: Wireless — Uplink und Controller-Architektur

Bei WLAN verschiebt sich der Fokus meist auf Wi-Fi-Standards: Wi-Fi 6, 6E, 7. In der Praxis wird die Wireless-Performance oft nicht durch das Radio, sondern durch das Kabel begrenzt. Viele Enterprise-APs können ihr volles Potenzial auf einem 1-Gbps-Uplink nicht ausschöpfen.

2,5G und 5G Kupfer-Uplink-Unterstützung ist in High-Density-Umgebungen kein Luxus — es ist eine Designanforderung. Und kritisch: Wenn der AP 2,5G unterstützt, aber der Switch-Port nicht, ist die gesamte Investition verschwendet. AP- und Switch-Auswahl müssen zusammen erfolgen.

Controller-Architektur ist ebenso kritisch. Kapazität muss über CPU, Speicher, Session-Handling und Policy-Enforcement bewertet werden — nicht nur nach Lizenzanzahl.

Schritt 7: Herstellerbewertung — Feldrealitäten

Cisco bleibt einer der stärksten Akteure in Switching und Routing. Wireless ist seit Jahren ausgereift. Im Firewall-Bereich nach Akquisitionen wie Sourcefire deutlich wettbewerbsfähiger. Vorbehalt: Eine vollständige Cisco-Umgebung ist leistungsfähig, aber selten einfach.

HPE Aruba ist durch Akquisitionen inklusive Juniper erheblich gewachsen. Switching weit verbreitet. Wireless nach meiner persönlichen Einschätzung einer der stärksten in der Branche. Das Fehlen einer starken nativen Firewall-Familie bleibt eine Lücke.

Fortinet bietet eines der breitesten Portfolios unter einem Dach. Firewall-Kompetenz ist stark. Switching reifte später, ist aber zunehmend im Feld präsent. Größter operativer Vorteil: relative Einfachheit der Integration und Verwaltung.

Palo Alto Networks ist klarer Marktführer bei Firewalls — betritt bewusst nicht Switching oder Wireless. Anwendungssichtbarkeit, Policy-Tiefe und SASE-Führerschaft sind die stärksten Differenzierungsmerkmale.

Abschließender Punkt: API-Unterstützung ist kein Bonus mehr — es ist ein Auswahlkriterium. Die Frage “Wie werde ich diese Architektur automatisiert verwalten?” sollte vor der Wahl von Switch, Firewall oder AP kommen.

Serverraum und Verkabelung: Was niemand besprechen will, aber jeder bezahlt

In Netzwerkprojekten dominieren die “glänzenden” Themen. Aber ein erheblicher Teil der Feldprobleme beginnt an einem viel grundlegenderen Ort: Serverraum-Design und Verkabelungsinfrastruktur.

Egal wie gut die Produkte oder wie korrekt die Architektur — wenn Serverraum und Verkabelung schwach sind, wird das Netzwerk irgendwann Probleme produzieren. Diese Probleme erscheinen als “Netzwerkausfälle,” aber die Grundursache ist fast nie wirklich das Netzwerk.

Wärme, Strom, Luftströmung, Zugänglichkeit und Ordnung müssen zusammen berücksichtigt werden. Redundante Netzteile werden gekauft, ohne zu prüfen, ob sie tatsächlich an separate Stromleitungen angeschlossen sind. Es heißt, es gibt eine USV, aber keine Kapazitätsberechnung wird durchgeführt.

Verkabelung ist die langlebigste Komponente des Netzwerks. Switches, Firewalls und APs ändern sich — Kabel bleiben. Eine 1G-Infrastruktur stößt schnell an ihre Grenzen, wenn 2,5G/5G-APs ankommen.

In meiner Sicht sind Serverraum und Verkabelung nicht die “unterste Schicht” der Architektur — sie sind das Fundament. Ein gut funktionierendes Netzwerk ist unsichtbar, weil das Fundament solide ist. Niemand bemerkt es. Und das ist meiner Meinung nach das größte Lob, das ein Infrastrukturdesign erhalten kann.

Hinweis

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

👉 Lesen Sie den Artikel auf Substack: Hier klicken

Verwandte Artikel

Architektur & Strategie

• 📐 IT-Infrastruktur ist keine Produktsammlung — Der Grundlagenartikel dieser Serie
• 🏗️ Switch, Firewall, AP — Warum die richtige Produktwahl allein nicht ausreicht — Architektur-zuerst Core-Network-Design
• 🛡️ Zero Trust Mindset: Sicherheit als Architektur — Sicherheit als Architektur

Technisches Engineering

• 📊 Der Monitoring-Mindset: Nicht nur sehen, sondern verstehen — Operative Sichtbarkeit
• 🛠️ Die Hintertür des Netzwerks: Next-Gen Console Server Architektur — Out-of-Band-Zugang
• 🛡️ Network Packet Broker (NPB) Masterclass — Traffic-Sichtbarkeit und Sicherheitsstrategie

Architektur, Kapazitätsplanung und die Vendor-Realität, über die niemand spricht

Die meisten Unternehmensnetzwerkprojekte beginnen am gleichen Punkt: der Produktauswahl. Und die meisten scheitern ebenfalls dort: an Produkten, die nicht sauber miteinander arbeiten. Denn das, was wir ein „Core-Netzwerk" nennen, besteht nicht aus drei Geräten (Switch, Firewall, Access Point), die nebeneinander stehen; es sind diese drei Komponenten, die gemeinsam Identität tragen, gemeinsam segmentieren, gemeinsam Policies durchsetzen und vor allem gemeinsam den Betrieb aufrechterhalten.

Was ich seit Jahren beobachte, ist Folgendes: Unternehmen leiden nicht daran, dass ihr Netzwerk schlecht ist, sondern daran, dass der Entscheidungsmechanismus des Netzwerks fragmentiert ist. Die teuersten Geräte, die besten Lizenzen, der höchste Durchsatz – alles ist vorhanden. Doch sobald ein Incident auftritt, weiß niemand genau, welches Gerät auf welcher Basis entscheidet, wo Traffic getrennt wird, wo er kontrolliert wird. Das Ergebnis: Es gibt „ein Netzwerk", aber kein definiertes „Netzwerkverhalten".

In diesem Artikel betrachte ich das Core-Netzwerk anhand von drei Säulen: Firewall, Switching und Access (Wi-Fi). Bevor ich darauf eingehe, möchte ich jedoch eines klar festhalten: Im Auswahlprozess gibt es zwei Faktoren, die mindestens genauso entscheidend sind wie „technische Spezifikationen", die jedoch von vielen Teams erst zu spät erkannt werden: Reports/Validierung und Support/Lifecycle.

Reports filtern, Tests einordnen und Marketingrauschen ausblenden

Eine der Referenzen bei der Produktauswahl sind – ja – Gartner-Reports. Denn Berichte wie die von Gartner geben eine Vorstellung von der Marktposition eines Produkts: Wer ist Leader, wer Visionär, wer bewegt sich in einer Nische. Gerade gegenüber Entscheidern ist das hilfreich, weil es eine strukturierte Antwort auf die Frage „Warum diese Marke?" liefert.

Doch hier liegt eine kritische Falle: Gartner sagt dir nicht, welches Produkt für dein konkretes Szenario richtig ist. Gartner liefert eine Marktkarte; deine Aufgabe ist es, eine Architekturkarte zu zeichnen. Deshalb ist es sinnvoll, Gartner als ersten Filter zu nutzen: Er reduziert Optionen, trifft aber keine finale Entscheidung.

Zusätzlich zu Gartner müssen Performance- und Security-Tests von Herstellern oder unabhängigen Laboren, Vergleichsberichte und reale Benchmarks berücksichtigt werden. Denn der Durchsatz auf dem Datenblatt ist nicht identisch mit dem Durchsatz im Echtbetrieb, wenn IPS aktiv ist, SSL-Entschlüsselung läuft und Application Control eingeschaltet ist. Reports dienen hier als zweiter Filter: Sie helfen, eine nicht-marketinggetriebene Antwort auf die Frage zu finden: „Was leistet diese Box unter genau dieser Last?"

Support und Lifecycle: die unsichtbare Säule der Architektur

Genauso wichtig wie technische Fähigkeiten sind Supportmodell und Lifecycle eines Produkts. Denn Netzwerkdesign endet nicht am Installationstag. Die eigentliche Frage lautet: Was passiert drei Jahre später?

• Wie lauten die EoL- / EoS-Daten?
• Wie schnell kommen Patches, Bugfixes und Security-Updates?
• Wie erreichbar ist der Support wirklich, und wie funktionieren Eskalationen?
• Wie realistisch sind RMA-Prozesse und Ersatzteilverfügbarkeit?
• Gibt es Lizenzüberraschungen nach einem Jahr?
• Passt die Roadmap des Herstellers zur eigenen strategischen Richtung?

Ich betone diesen Punkt bewusst, weil ich im Feld immer wieder dasselbe sehe: Teams wählen ein technisch fast passendes Produkt, doch wegen Support- oder Lifecycle-Problemen wird der Betrieb nach zwölf Monaten zur Belastung. Die Schuld wird dann dem Gerät gegeben, obwohl das eigentliche Problem die mangelnde Gewichtung des Supports in der Entscheidungsphase war.

Firewall: UTM, NGFW oder mehrere Rollen?

Eine Firewall ist längst nicht mehr nur ein „Security-Gerät am Netzrand". Richtig positioniert wird sie zum Policy-Gehirn; falsch positioniert wird sie zum Bottleneck, auf dem alles kollabiert.

Begrifflich lohnt sich eine klare Trennung: UTM und NGFW werden in vielen Umgebungen vermischt.

Der UTM-Ansatz folgt meist der Idee „alles in einer Box": klassische Firewall, IPS, Webfilter, AV und einige Gateway-Funktionen. Gerade in kleinen und mittleren Umgebungen wird dies wegen einfacher Verwaltung und gebündelter Lizenzen bevorzugt.

NGFW hingegen ist auf Applikationssichtbarkeit, Benutzer- und Identitätskontext sowie tiefere Policy-Kontrolle ausgelegt. In modernen Enterprise-Umgebungen reicht es oft nicht mehr, Security nur anhand von Port und Protokoll zu betreiben – hier kommt NGFW ins Spiel.

Der entscheidende Punkt ist jedoch: Die Anforderungen eines Unternehmens lassen sich oft nicht mit einem einzigen „Firewall-Typ" abdecken. Eine Firewall übernimmt je nach Layer und Zweck unterschiedliche Rollen.

Warum zwei (oder sogar drei) Firewalls im selben Unternehmen sinnvoll sind

In vielen Organisationen sind folgende Szenarien völlig legitim:

• Perimeter- / Internet-Edge-Firewall: Internetzugang, VPN, NAT, Inbound/Outbound-Policy.
• Interne Segmentierungs-Firewall (ISFW): interne Netzsegmentierung, East-West-Kontrolle, Schutz kritischer Zonen.
• Datacenter- / High-Performance-Firewall: DC-Traffic, hohe Session-Zahlen, hohe PPS, geringe Latenz.
• In manchen Architekturen zusätzliche Komponenten wie WAF oder Cloud-Firewalls.

Das bedeutet nicht „zwei Firewalls kaufen", sondern „zwei unterschiedliche Aufgaben mit passenden Werkzeugen abdecken". Wenn alles in eine Box gepackt wird, leidet entweder Performance, Manageability oder Security – meist mindestens eines davon.

Für ein tieferes Verständnis der Sicherheitsphilosophie hinter dieser Architektur empfehle ich: Zero Trust Mindset: Sicherheit als Architektur, nicht als Produkt

Und damit sind wir direkt bei der Kapazitätsplanung.

Firewall-Kapazitätsplanung: Durchsatz allein ist trügerisch

Der gefährlichste Fehler bei der Firewall-Auswahl ist der Fokus auf die reine Gbps-Zahl. In der Praxis scheitern Firewalls selten am Durchsatz, sondern an:

• PPS (Packets per Second)
• Anzahl gleichzeitiger Sessions
• New-Session-Rate
• NAT-Tabellen und State-Handling
• Performance mit aktivem IPS/AV/App-ID
• SSL/TLS-Entschlüsselung
• Log-Erzeugung und Log-Transport (z. B. SIEM)

Ein reales Beispiel: Die Aussage „wir haben eine 10-Gbps-Firewall gekauft" ist isoliert wertlos. Diese 10 Gbps gelten meist nur unter Idealbedingungen. Sobald IPS, URL-Filter, Application Control und Decryption aktiv sind, sieht die Realität völlig anders aus. Die richtige Frage lautet daher: „Wie viel Last kann diese Firewall mit genau den Security-Features und genau meinem Traffic-Profil tragen?"

Gibt es darauf keine belastbare Antwort, ist die Auswahl riskant.

Switching: Rolle und Last sind wichtiger als Portanzahl

Switch-Auswahl beginnt häufig mit der Portanzahl: wie viele Kupferports, wie viele Glasfaserports, PoE ja oder nein. Das ist wichtig, aber aus Core-Netzwerk-Sicht nicht ausreichend. Ein Switch ist kein Verlängerungskabel; er ist ein Entscheidungspunkt für Traffic-Konzentration, -Trennung und Weiterleitung.

Ein häufiger Fehler im Access-Bereich ist die Planung nur für den Ist-Zustand. Dabei ist die Access-Schicht die dynamischste Ebene im Netzwerk. Heute reichen 1G-Kupferports, morgen hängen dort High-Density-APs oder andere Edge-Geräte. Deshalb werden Multi-Gig-Ports (2.5G/5G), PoE-Budgets pro Port und die tatsächliche Uplink-Kapazität entscheidend.

Uplinks werden oft unterschätzt. Aussagen wie „2×10G reichen" hört man häufig, ohne das Traffic-Profil zu analysieren. Mit steigender Userzahl, mehr East-West-Traffic und veränderter Broadcast-Dynamik sind diese Links schneller gesättigt als erwartet. Hier zählen nicht nur die Uplink-Geschwindigkeit, sondern auch Backplane-Kapazität und Oversubscription-Ratios des Switches.

Auch die Abgrenzung zwischen Edge- und Datacenter-Switches ist oft unscharf. Edge-Switches sind auf Portdichte und PoE optimiert, Datacenter-Switches auf hohen Durchsatz, niedrige Latenz und hohe PPS. Beides von einem Gerät zu erwarten, führt meist zu unnötigen Kosten oder zu Performanceproblemen. Die Frage „Wo steht dieser Switch und welchen Traffic trägt er?" muss vor der Frage „Wie viele Ports?" kommen.

Inter-VLAN-Routing ist ebenfalls ein Architekturaspekt. Wenn Routing auf dem Switch erfolgen soll, reichen Layer-3-Fähigkeiten allein nicht aus. Route-Scale, TCAM-Kapazität, Policy-Integration und das Zusammenspiel mit der Firewall sind entscheidend. Andernfalls entsteht aus einer vermeintlichen Performance-Optimierung später eine komplexe, schwer wartbare Struktur.

Access / Wi-Fi: Uplink und Control Plane sind Teil der Architektur

Bei WLAN wird oft über Standards gesprochen: Wi-Fi 6, 6E, 7. In der Praxis limitiert jedoch häufig nicht der Funk, sondern das Kabel. Ein leistungsfähiger Access Point ist wertlos, wenn der dahinterliegende Uplink den Traffic nicht tragen kann.

Viele Enterprise-APs können ihr Potenzial mit 1-Gbps-Uplinks nicht ausschöpfen. Deshalb sind 2.5G- und 5G-Uplinks in High-Density-Umgebungen kein Luxus, sondern Designanforderung. Doch auch hier gilt: Die Kette ist nur so stark wie ihr schwächstes Glied. Ein 2.5G-fähiger AP an einem 1G-Switchport ist eine Fehlinvestition. AP- und Switch-Auswahl müssen gemeinsam erfolgen.

Ein weiterer kritischer Punkt ist die Controller-Architektur. Anzahl unterstützter APs, gleichzeitige Clients und Roaming-Verhalten bestimmen die reale Stabilität. Ein Controller, der „500 APs" unterstützt, kann in High-Density-Umgebungen deutlich früher an Grenzen stoßen. Entscheidend sind nicht nur Lizenzen, sondern CPU, Memory, Session-Handling und Policy-Durchsetzung.

WLAN gilt oft als Edge-Thema, belastet aber das Core-Netzwerk besonders stark: mobile Clients, häufige Reauthentifizierung, intensive Policy-Zyklen. Kleine Designfehler im Access-Bereich erzeugen unerwartete Lasten im Core. AP-Auswahl ist daher keine reine Coverage-Frage, sondern eine Core-Architekturentscheidung.

Abschluss: Vendor-Auswahl, architektonische Reife und Realität

Die folgenden Einschätzungen basieren ausschließlich auf meinen eigenen Felderfahrungen. Ziel ist weder Lob noch Kritik, sondern eine nüchterne Einordnung von Stärken und Schwächen.

Cisco ist im Switching und Routing weiterhin extrem stark, insbesondere in großen Campus- und Datacenter-Umgebungen. Wireless ist seit Jahren ausgereift. Im Firewall-Bereich hat Cisco durch Akquisitionen deutlich aufgeholt. Gleichzeitig gilt: Eine durchgängige Cisco-Landschaft ist leistungsfähig, aber selten einfach. Integration ist möglich, erfordert jedoch Erfahrung und Aufwand.

HPE Aruba habe ich über Jahre intensiv begleitet. Das Portfolio ist durch europäische Akquisitionen und zuletzt Juniper stark gewachsen. Aruba ist im Switching breit akzeptiert, im WLAN meiner Ansicht nach branchenführend. Historisch gab es Lücken im Routing, die sich mit Juniper weitgehend schließen dürften. Eine starke eigenständige Firewall-Familie fehlt jedoch weiterhin.

Fortinet bietet ein sehr breites Portfolio aus einer Hand. Besonders die Firewall-Kompetenz ist stark. Switching und Wireless sind später gereift, werden aber zunehmend eingesetzt. Ein großer Vorteil ist die vergleichsweise einfache Integration und Bedienbarkeit – ein Pluspunkt für kleinere IT-Teams.

Palo Alto Networks ist im Firewall-Bereich klar führend. Switching und Wireless gehören bewusst nicht zum Fokus. Viele Organisationen setzen Palo Alto ausschließlich für Firewalls ein – aus guten Gründen. Besonders bei Application Visibility, Policy-Tiefe und SASE sehe ich Palo Alto klar an der Spitze.

In der Praxis existieren alle Mischformen: Single-Vendor-Ansätze, Dual-Vendor-Strategien oder Best-of-Breed-Architekturen. Diese Entscheidungen sind ebenso organisatorisch wie technisch geprägt.

Meine persönliche Haltung: Wo Teams reif genug sind, profitieren Architekturen oft von spezialisierten Herstellern pro Layer. Wo Einfachheit, Klarheit und ein zentraler Supportkanal wichtiger sind, ist ein Single-Vendor-Ansatz völlig legitim.

Ein letzter Punkt ist mir besonders wichtig: Automatisierung. API-Fähigkeit ist heute kein Bonus mehr, sondern ein Auswahlkriterium. Produkte sollten nicht zuerst nach Hardware, sondern nach Automatisierbarkeit bewertet werden.

Einen praktischen Rahmen für den Aufbau von Infrastruktur-Sichtbarkeit finden Sie hier: Der Monitoring-Mindset: Nicht nur sehen, sondern verstehen und proaktiv handeln

Serverraum und Verkabelung: Die Realität, über die niemand spricht – aber jeder bezahlt

In Netzwerkprojekten stehen meist die „glänzenden" Themen im Vordergrund. Doch viele Probleme entstehen viel tiefer: im Serverraum und in der Verkabelung.

Meine Erfahrung ist eindeutig: Schlechte Serverraum- oder Kabelinfrastruktur macht jede noch so gute Architektur angreifbar. Die Symptome heißen „Netzwerkausfall", die Ursache liegt fast nie im Netzwerkdesign.

Serverräume werden oft wie Abstellräume behandelt. Racks wachsen, Kabel häufen sich, Provisorien werden dauerhaft. Irgendwann entsteht ein Raum, den niemand anfassen will – aber jeder braucht. Genau hier beginnt das Risiko.

Ein Serverraum ist das Herz des Netzwerks. Kühlung, Strom, Luftführung, Zugänglichkeit und Ordnung sind keine Nebensachen. Dauerhafte Hitze verkürzt Lebensdauer und erzeugt instabile Effekte. Auch Stromkonzepte werden unterschätzt: Redundante Netzteile ohne getrennte Stromkreise, USVs ohne Kapazitätsplanung – im Ernstfall wertlos.

Verkabelung ist die langlebigste Komponente der Infrastruktur. Geräte wechseln, Kabel bleiben. Deshalb ist Planung nur für den Ist-Zustand ein Fehler. 1G-Designs stoßen mit Multi-Gig-APs schnell an Grenzen.

Kupfer oder Glasfaser ist keine Glaubensfrage, sondern Architektur. Patchpanel-Struktur, Beschriftung und Kabelmanagement sind operative Notwendigkeiten, keine Ästhetik.

Unklare Verkabelung macht jede Änderung riskant. Falscher Port, falsches Kabel – und ein anderer Service fällt aus. Dann heißt es wieder: „Das Netzwerk war schuld."

Physische Zugriffskontrolle wird ebenfalls oft ignoriert. Ohne klare Regeln verliert jede logische Security an Bedeutung.

Aus meiner Sicht sind Serverraum und Verkabelung nicht die „unterste Schicht" der Architektur, sondern das Fundament. Eine stabile Infrastruktur wird nicht gelobt – sie fällt nicht auf. Und genau das ist ihr größter Erfolg.

Hinweis

Dieser Artikel erschien ursprünglich in kürzerer, erzählerischer Form auf Substack. Diese Version erweitert die architektonische Grundlage der Serie.

👉 Lesen Sie den Artikel auf Substack: Hier klicken

Verwandte Artikel

Wenn Ihnen dieser Artikel gefallen hat, könnten auch diese Beiträge interessant sein:

Architektur & Sicherheitsdesign

• 📐 IT-Infrastruktur ist keine Produktsammlung — Der Grundlagenartikel dieser Serie
• 🛡️ Zero Trust Mindset: Sicherheit als Architektur, nicht als Produkt — Warum Zero Trust eine Philosophie und kein Produkt ist
• 📊 Der Monitoring-Mindset: Nicht nur sehen, sondern verstehen — Echte Transparenz in der Infrastruktur aufbauen

Technisches Engineering

• 🛠️ Die Hintertür des Netzwerks: Next-Gen Console Server Architektur — Out-of-Band-Zugang wenn alles andere versagt
• 🛡️ Network Packet Broker (NPB) Masterclass — Erweiterte Traffic-Sichtbarkeit und Sicherheitsstrategie
• 🔐 802.1X Projekte erfolgreich umsetzen: Praxiseinblicke — Identitätsbasierter Zugang in Unternehmensnetzwerken
• ⚙️ Nexus Software Upgrade Guide — NX-OS Upgrade ohne Ausfallzeit