Zahlreiche Unternehmensnetze sind das, was sich beschönigend "historisch gewachsen" nennt. Diese diplomatische Formulierung verschleiert eine ganze Reihe von Missständen, die an der Hochverfügbarkeit nagen: Das Netzwerk stammt aus grauer IT-Vorzeit und ist somit auf die Anforderungen moderner Echtzeitapplikationen ebenso wenig ausgelegt wie auf die Bedürfnisse einer verteilt arbeitenden Belegschaft. Es ist komplex aufgebaut, dadurch aufwendig und fehleranfällig im Unterhalt. Management, Monitoring und Analyse von LAN, WAN und WLAN sind über mehrere Applikationen verteilt, die das Netzwerkteam bei Störungen alle im Blick behalten muss. Und trotz mühsam implementierter Mechanismen und Protokolle für schnelles Failover liegen die Umschaltzeiten im Störungsfall oft doch nicht im Millisekunden-, sondern eher im Minutenbereich.

Die Folge sind dann Geschäftsanwendungen, die ihre Verbindung zur Datenbank verlieren, unterbrochene VoIP-Telefonate und Videokonferenzen sowie frustrierte Endanwender, die – in diesem Fall sogar zurecht – dem Netzwerk die Schuld an der unfreiwilligen Kaffeepause geben. Im Worst Case steht sogar das Fließband eines Industrieunternehmens still oder ein Betreiber kritischer Infrastruktur muss einen Aussetzer überbrücken, um Versorgungslücken zu vermeiden.

Das kaffeepausenfreundliche Netzwerk historisch gewachsener Prägung hat jedoch – eine gute Nachricht für alle außer den ernsthaft koffeinabhängigen Kollegen – einen hochverfügbaren Nachfolger: Fabric Connect beziehungsweise die Fabric. Als virtuelles End-to-End-Overlay über ein physisches Netzwerk mit Autosensing- und Autokonfigurationsfunktionen ermöglicht eine Fabric, richtlinienbasiert und dynamisch Punkt-zu-Punkt-Verbindungen auf- und wieder abzubauen, ohne dass der Administrator eingreifen muss: Automatisierte Prozesse eliminieren den manuellen Aufwand und schließen damit Fehlkonfigurationen ebenso aus wie Unterbrechungen der Netzwerkverbindung, die einen reizbaren Endanwender oder eine latenzempfindliche Applikation irritieren könnten.

Dazu macht das Netzwerkteam lediglich Vorgaben, wer mit wem oder was kommunizieren darf und das Netzwerk setzt diese Vorgaben dann automatisch um. Damit bietet eine solche Fabric eine einheitliche und effiziente Umgebung vom Datacenter über den Campus und das WAN bis zu den Zweigstellen.

Ein Blick unter die Haube offenbart das Geheimnis dieser Hochverfügbarkeitsmaschine: Sie basiert auf "Shortest Path Bridging" (SPB, IEEE 802.1aq) und dem bewährten Routing-Protokoll IS-IS. Diese Kombination ersetzt das klassische Spanning-Tree-basierte Layer-2-Switching durch ein Routing mit redundanter Wegeführung – und dies ohne zentralen Controller, denn die Intelligenz sitzt auf jeder aktiven Komponente am Edge und im Core. Der Core ist dabei reduziert auf eine mächtige, aber einfache Durchleitungsinfrastuktur, die keine Konfigurationsarbeit mehr erfordert. Redundanz und verteilte Intelligenz sorgen so in Kombination für Ausfallsicherheit.

Wie effektiv das Duo aus SPB und IS-IS ist, zeigt sich an der langen Liste von Standardprotokollen, die es überflüssig macht: STP, MSTP und RSTP ebenso wie RIPv1, RIPv2, OSPF, EIGRP, ECMP, PIM-SM, PIM-SSM, DVMRP, LSP oder das ebenfalls in die Jahre gekommene MPLS. Als sicheren Übertragungsmechanismus setzt eine moderne Fabric mittels SPB auf eine MAC-in-MAC-Kapselung. In Kombination mit NAC (Network Access Control) lässt sich auch der Netzwerkzugang neuer Geräte automatisieren: Sind diese einmal erfasst, erhalten sie, sobald sie sich mit dem Netzwerk verbinden, automatisch Zugriff auf die hinterlegten Applikationen und Services. Und wenn sie sich wieder aus dem Netz entfernen, baut die Fabric den Tunnel ebenso automatisch wieder ab.

In der Praxis vereinfacht dies zahllose Abläufe. Im Krankenhaus zum Beispiel wandert viel Medizintechnik auf Rollwägen hin und her, von Behandlungszimmer zu Behandlungszimmer oder vom OP zurück auf Station. Die Fabric erkennt das Gerät, sobald es sich mit dem Netzwerk verbindet. Das Device erhält einen sogenannten ISID (Individual Service Identifier) und wird automatisch zum passenden Server geleitet, beispielsweise zum Fileserver, auf dem die Klinik die Untersuchungsergebnisse speichert. Beim Abziehen des Steckers baut sich der Tunnel wieder ab – und beim nächsten Einsatz beginnt der Ablauf wieder von vorn, ohne dass je ein Administrator eingreifen muss. Die Zeitersparnis durch selbstkonfigurierendes Netzwerk könnte im Krankenhaus letztlich sogar Leben retten – im Alltag verschafft die No-Touch-Konfiguration dem IT-Team zumindest Entlastung und dem Klinikpersonal mehr Zeit für die Pflege.

Eine Fabric bietet diverse weitere Vorteile: Da das Netzwerk Segmente und Tunnel selbsttätig auf- und abbaut, läuft die Provisionierung schneller ab, während die Zahl der Konfigurationsfehler sinkt. Eine Umfrage [1] unter Fabric-Anwendern ergab, dass sich neue Services elf Mal so schnell (also in neun Prozent der Zeit) provisionieren ließen, während die Zeiten für Konfiguration und Troubleshooting auf 15 Prozent des vorherigen Bedarfs sanken. Ein interessantes Detail: 41 Prozent der Befragten konnten zu Troubleshooting-Zeiten keine belastbaren Angaben machen – schlicht deshalb, weil eine Fehlersuche seit Fabric-Einführung noch gar nicht notwendig war.

Zudem entfallen manuelle Fehler, da bei einer etablierten Fabric keine Konfigurationen im Core oder der Distribution erforderlich sind. Und durch Automatisierung werden Layer-8-Fehler eliminiert. Die Failover-Zeiten sanken bei den befragten IT-Teams von über 13 Minuten auf 0,32 Sekunden – eine Verzögerung, die eine Business-Applikation gar nicht merkt, ein Endanwender erst recht nicht. Ausfallzeiten aufgrund menschlicher Fehler wiederum entfielen praktisch vollständig. Und da die Automation rein auf Intelligenz am Edge beruht, muss das IT-Team den Netzwerk-Backbone gar nicht anfassen – ein Schritt, den Administratoren bekanntlich nur ungern gehen.

Zum ausfallsicheren Netz gehört zwingend hohe Netzwerksicherheit, könnten doch Manipulationen durch Angreifer Netzwerkausfälle verursachen. Die automatisch etablierten Ende-zu-Ende-Verbindungen einer Fabric gehen deshalb ebenso selbsttätig Hand in Hand mit einer Hypersegmentierung: Statt maximal 4096 VLANs sind über 16 Millionen Segmente möglich, die Weiterleitung erfolgt mittels Tunneling anhand der erwähnten ISIDFlags statt IP-Adressen. Durch dieses unsichtbare Stealth-Tunneling ist der Netzwerkverkehr für die IP-Scan-Tools von Angreifern nicht erkennbar. Selbst Multicasting ist mit solchen Tunneln möglich. Und da das selbstkonfigurierende Netzwerk Redundanzen vorsieht, weist es keinen dedizierten Ausfallpunkt (Single-Point-of-Failure) auf.

Hilfreich ist dies zum Beispiel für Industrieunternehmen mit verschiedenen Produktionsstandorten. Hier müssen manche Beschäftigte immer wieder mal am einen, mal am anderen Standort arbeiten. Deren Netzwerkanbindung lässt sich per Fabric mit einem Höchstmaß an Sicherheit automatisieren: Die Fabric erkennt den Mitarbeiter und sein Endgerät, sobald sie sich an einem Standort mit dem LAN oder WLAN verbinden. Das Gerät bekommt automatisch sein Regelwerk zugewiesen, und der reisende Techniker oder Manager kann sofort arbeiten, wie er es von seinem Office- oder Home-Office-Arbeitsplatz her kennt. Kurz: Der Endanwender kommt nicht mehr zum Netzwerk, sondern das Netzwerk kommt zum Endanwender – und das ebenso sicher.

Für möglichst hohe Verfügbarkeit sollte dabei das NAC-System, etwa ein RADIUS-Server, physisch und logisch redundant aufgebaut sein. Idealerweise weist die Fabric für solche Einsatzfälle eine integrierte SD-WAN-Funktionalität (Software-defined WAN) auf. Diese ermöglicht dem Benutzer eine ebenso performante wie sichere Anbindung über diverse WAN-Verbindungen mit applikationsbezogenem Traffic-Management. Dies erlaubt ununterbrochenes Arbeiten, selbst wenn ein Carrier gerade zu wenig Bandbreite bereitstellt.

Ebenso ausfallsicher wie das Netzwerk selbst muss auch dessen Verwaltung und Kontrolle sein. State of the Art ist hier ein cloudbasiertes, intuitiv bedienbares Full-Stack-Netzwerkmanagement. Beim Stichwort Cloud zuckt manch Administrator spontan zusammen und muss sich vor Schreck erst mal einen Kaffee holen, aber keine Sorge: Hier ist nicht die Rede von der Data- oder der Control-Plane des Netzwerks, sondern lediglich von der Management-Plane. Dadurch, dass der Datenverkehr des Unternehmens lokal bleibt, ist weder eine Kompromittierung der Datensicherheit oder der Compliance zu befürchten, noch drohen Datenverluste, wenn einmal eine WAN-Verbindung ausfällt.

Vieles spricht dafür, die Managementebene eines Netzwerks in der Cloud anzusiedeln, nicht zuletzt die Resilienz der globalen Hyperscaler-Infrastrukturen, denn gegen alltägliche Störungen und Serviceausfälle sind die Hyperscaler durch ihre ausgefeilten Failover-Konzepte gewappnet. Oder können Sie sich noch erinnern, wann die Google-Suche zuletzt nicht zu erreichen war? Für das hochverfügbare, cloudbasierte Netzwerkmanagement mit einem SLA von 99,9 Prozent Verfügbarkeit (in der Praxis deutlich mehr) sorgen die zugrunde liegenden Microservices ebenso wie automatisierte Backups der Konfigurationen. Eine Multi-Tenant-Architektur garantiert die verlässliche Trennung der Mandanten.

Bei der Implementierung einer solchen Lösung sollten IT-Teams auf Single-Signon und Multifaktor-Authentifizierung beim Adminstratorenzugriff achten – und selbstverständlich muss der Management- Datenverkehr nach dem Stand der Technik verschlüsselt sein. Ein Hosting der Software im europäischen Rechtsraum vermeidet DSGVO-Konflikte, und das Rechenzentrum des Providers – im Idealfall auch alle eingesetzten Lösungen – sollte ISO-27017/27018-zertifiziert sein, um dem Stand der Technik zu entsprechen.

Ein cloudbasiertes Full-Stack-Management verschafft dem IT-Team idealerweise den Überblick über das gesamte Netzwerk: vom Core bis zum Edge und vom verkabelten Netz bis zum WLAN. Denn eine Aufteilung in Silos ist längst nicht mehr zeitgemäß und stellt nur eine Fehlerquelle dar. Last but not least muss das Interface eine klare, intuitive Benutzerführung bieten.

Schließlich lässt sich so manch ein Netzwerkausfall auf Konfigurationsfehler zurückführen – ein Risiko, das der akute Mangel an Fachpersonal in der IT-Branche noch verschärft. Kurz: Das Netzwerk sollte sich wo immer möglich automatisch konfigurieren und aktualisieren. Sobald manuelle Eingriffe notwendig sind, sollte der Administrator möglichst schnell und einfach erkennen können, was zu tun ist – und dies über die gesamte Netzwerkumgebung hinweg.

Das WLAN ist aus den allermeisten Unternehmensnetzwerken nicht mehr wegzudenken – und dies dürfte trotz des Hypes um 5G-Mobilfunk auch so bleiben. Schließlich kann Wi-Fi 6E (und zukünftig Wi-Fi 7) der neuen Mobilfunkgeneration in vielerlei Hinsicht Paroli bieten, und die IT-Teams sind, anders als bei 5G, mit den Anforderungen und Managementtools seit geraumer Zeit vertraut.

In puncto Ausfallsicherheit bildet das WLAN einen Sonderfall. Natürlich ließen sich, dem klassischen Failover-Gedanken folgend, auch WLAN-Access-Points (APs) redundant anbinden. In der Tat gibt es immer wieder Ausschreibungen, insbesondere im KRITIS-Sektor, die eine redundante AP-Integration vorsehen. Diese erfordert aber prinzipbedingt eine doppelte Kabelführung zu jedem einzelnen AP, weshalb die Auftraggeber das Konzept aus Kostengründen dann doch meist nicht weiterverfolgen.

Denn der einfachere und kostengünstigere Weg zu Redundanz im WLAN führt schlicht über eine gründlich geplante Ausleuchtung: IT-Verantwortliche definieren vorab, wofür die Access Points gedacht sind (Daten, Sprache, Streaming, Multicasting et cetera), kalkulieren die Leistungsparameter und positionieren die APs dann so, dass von einem Endgerät aus immer mehr als einer erreichbar ist. Beim Ausfall eines AP führt automatisches Roaming den Client dann sofort zum nächsten WLAN-Zugang.

Unternehmen sollten zudem auf den Einsatz von 802.11ax-APs achten. Denn der aktuelle WLAN-Standard ist auf optimiertes Performancemanagement ausgelegt und kann somit Schwächen bei der Ausleuchtung besser ausgleichen, insbesondere bei der Übertragung zahlreicher kleiner Frames. Beherrschen die APs "SmartRF", gleichen sie Versorgungslücken automatisch aus, indem sie ihre Leistung dynamisch erhöhen. Redundanz ist im WLAN somit weniger eine Frage doppelter AP-Verkabelung als vielmehr aktueller AP-Technik und durchdachter Funkabdeckung.

So erfordern zum Beispiel die Handheld-Scanner im Hochregallager eines Logistikunternehmens eine sehr gute WLAN-Ausleuchtung. Denn die tragbaren Geräte sind laufend an immer neuen Punkten im Einsatz, und je nach Art und Größe der Ware kann schnell mal eine Palette mit Material die Verbindung zu einem AP stören. Entsprechend gründlich sollte hier also die AP-Abdeckung geplant sein.

Eine auf Hochverfügbarkeit getrimmte Fabric minimiert störungsbedingte Zwangskaffeepausen und eröffnet dadurch die Möglichkeit, öfter mal freiwillig und in Ruhe einen Espresso zu trinken – da sollte die Kaffeeversorgung nicht daran scheitern, dass die Bohnen im Lager des Spediteurs liegenbleiben. Denn letztlich ist Hochverfügbarkeit auch immer eine Frage der Lieferkette und verlässlicher Partner.