Braucht das Campus-Netz nun eine Fabric?

Ob die sprichwörtliche Behauptung, dass „neue Besen gut kehren“, von einem Besenverkäufer ins Leben gerufen wurde, weiß ich zugegebenermaßen nicht. Denkbar wäre das durchaus. Zumindest kann man diesen Eindruck bezüglich neuer Netztechnologien bekommen, wenn man sieht, wie neue technologische Ansätze von Netzherstellern angepriesen und vermarktet werden. Natürlich haben neue Besen mit ihren meist noch schönen und geraden Borsten tatsächlich einige Vorteile beim Fegen. Auch alte Besen haben ihren Charme und Nutzen. Inwieweit sich dies beim Netzdesign ebenso verhält, ist abzuwarten. Klar ist, dass in beiden Fällen Vor- und Nachteile ersichtlich sind. Der Nutzer (oder Netzbetreiber) muss natürlich die für sich und seine Umgebung passende Lösung finden.

Im Bereich der Netztechnik finden sich tatsächlich seit einigen Jahren recht häufig moderne Lösungen, bei denen die Steuerung und das Management des Netzes durch zahlreiche neue Features angereichert werden. Meist besteht die eingesetzte Technologie im Netz hierbei aus einer sogenannten Fabric-, SDN- oder Overlay-Lösung. Ob diese Lösung mit ihrer angepriesenen Flexibilität jedem Kunden einen Nutzen bringt, ist nicht direkt klar. Es bietet sich also an, dieses Thema genauer anzuschauen und einige der Hintergründe der verschiedenen Lösungen zu diskutieren.

Anforderungen an die moderne Netzarchitektur

Als erstes sollte man sich klar werden, warum eine Anpassung bestehender Netzarchitekturen überhaupt Sinn ergeben kann. Ein Startpunkt ist die Betrachtung der Anforderungen an das Netz. Diese erhöhen sich zunehmend durch die immer weiter steigende Anzahl an Endgeräten und neuen Anwendungen.

Moderne Netzarchitekturen müssen also neue Anforderungen abbilden können, flexibel aufgebaut sein und den betrieblichen Bedingungen entsprechen. Bei verschiedenen Kunden sehen wir immer häufiger den Bedarf, verschiedene Gewerke (Medientechnik, Büro-IT, Gebäudetechnik etc.) in ein Netz zu integrieren. Dies erhöht die Komplexität des Netzbetriebs, welcher durch die technische Lösung entsprechend unterstützt werden soll.

Die Anbindung verschiedener Gewerke und damit von Endgeräten oder Netzbereichen in der Verantwortung verschiedener Abteilungen stellt insbesondere Anforderungen an die unterstützten Technologien, die Bereitstellung von Anschlüssen und logischen Netzen und die Sicherheit und Netztrennung.

Diese Funktionen müssen durch das lokale Campus-Netz bereitgestellt werden. Im selben Zuge wird die Automatisierung zur Abbildung der Dynamik in Bezug auf die Endgeräteanbindung im Netz immer wichtiger. Der Anschluss neuer Endgeräte, die Bereitstellung logischer Netze und Anpassungen sollen möglichst automatisch erfolgen. Die Konfiguration neuer Komponenten soll mit einem entsprechenden Zero Touch Provisioning umgesetzt werden. Insgesamt geht es also um eine betriebliche Vereinfachung im Netz.

Im modernen Netzbetrieb wird die Überwachung des Netzes neben der eigentlichen Kommunikationsfunktion immer wichtiger. Entsprechende Anforderungen beinhalten neben einfachen Statistiken sogar die Möglichkeit zur Darstellung der Kommunikationspfade einzelner Anwendungen.

Was ist eine Fabric?

Zunächst muss klargestellt werden, was mit einer Fabric- oder Overlay-Lösung gemeint ist. Es gibt keine einheitliche Definition, und jeder Hersteller hat einen etwas anderen Blickwinkel auf das Thema. Für uns bzw. in Kundenprojekten sind zwei grundlegende Elemente wichtig: die Netzarchitektur und das zugehörige Management. Insbesondere ersteres ist dabei für die technischen Aspekte eines Overlay ausschlaggebend.

Wenn wir uns als ersten Schritt mit der Netzarchitektur befassen, müssen wir hierbei einige grundlegende Begriffe betrachten. Zentral sind die Control Plane (Steuerungsebene) und die Data Plane (Nutzdatenebene).

Bei der Control Plane handelt es sich um Funktionen und Protokolle zur Steuerung, wie Daten im Netz geleitet werden sollen. In einem klassischen Netz kann dies beispielsweise durch Routing-Protokolle oder manuell konfigurierte statische Routen abgebildet werden. Die Formate, die für die Datenweiterleitung genutzt werden, bilden die Data Plane. In der ISO/OSI-Hierarchie gibt es sowohl Steuerungsprotokolle als auch Datenformate auf verschiedenen Schichten. Beispiel Ethernet: Die Data Plane nutzt das Ethernet-Frame-Format, die Control Plane Protokolle für Medienzugriffsverfahren. Und Beispiel IP: Auf der Data Plane hat sich das Format des IP-Datagramms mit definiertem Header etabliert, auf der Control Plane die Arbeitsteilung zwischen Endgeräten und Routern bzw. Routing-Protokollen.

In Fabrics kann die entsprechende Funktion der Control und Data Plane durchaus sehr unterschiedlich umgesetzt werden. Für letztere werden im Prinzip zusätzliche Schichten in das ISO/OSI-Modell eingeführt, welche die geforderte Flexibilität ermöglichen. Es werden neue Protokolle etabliert, um die bereits existierenden Netzfunktionen zu ergänzen. Die von der Fabric-Lösung bereitgestellten Schichten liegen dabei als weitere überlagernde Ebene oberhalb der bisherigen Data Plane des klassischen Netzes. Daher ergibt sich der Begriff Overlay. Overlays bezeichnen somit verschiedene logische Netze, die das gemeinsame physische Netz nutzen.

Analog wird der Begriff Underlay für die Ebenen von der Verkabelung bis zu der im physischen Netz verwendeten IP-Kommunikation genutzt.

Das Overlay agiert in der Fabric regelmäßig wie eine einheitliche Instanz. In der Endgerätekommunikation kann es als „verteilter Router“ abstrahiert werden, wie in Abbildung 1 skizziert.

In Abbildung 2 ist einerseits die Sicht des Endgeräts auf das Netz dargestellt und andererseits die Zuständigkeit der Control Plane. Durch die Fabric wird dem Endgerät damit ein Layer-2- bzw. Layer-3-Netz zur Verfügung gestellt. Diese bereitgestellten Schichten sind als Overlay vom darunterliegenden Underlay getrennt.
Für das Endgerät muss die Trennung zwischen Underlay und Overlay völlig transparent sein. Es sieht die in der Abbildung blau dargestellten Schichten als die genutzte Netzhierarchie. Die weiteren Schichten der Data Plane und des Underlay (grün) sind für das Endgerät nicht sichtbar.

Die Control Plane steuert den Datenfluss bzw. die dazu notwendige Konfiguration der Komponenten. Dazu werden meist zusätzliche Protokolle benötigt. Der grundsätzliche Aufbau kann lösungsabhängig von Protokollen ähnlich dem klassischen Routing bis hin zu zentralisierten Ansätzen mit sogenannten Controllern variieren. Bspw. können die Komponenten Routing-Tabellen untereinander austauschen, oder eine zentrale Instanz übernimmt diese Koordination und stellt die notwendigen Informationen bereit. Letzteres ist in Teilen vergleichbar mit dem Management der WLAN-Access-Points durch einen WLAN-Controller.

Eine weitere zentrale Funktion ist bei vielen Lösungen der Control Plane das Zero Touch Provisioning (ZTP). Hierbei ist die grundsätzliche Idee, dass sich neue Komponenten selbstständig mit dem Netz verbinden, indem sie ihre Control Plane bzw. ihren Controller finden und dort ihre Konfiguration erhalten. Dies soll die Inbetriebnahme deutlich vereinfachen. Insgesamt profitiert das ZTP davon, dass die eigentliche Intelligenz in der Control Plane liegt und somit die meisten Komponenten mit einer entsprechend einheitlichen Grundkonfiguration funktionieren können, während die Control Plane die Detail-Organisation übernimmt.

Als weiterer zentraler Punkt des zugehörigen Netzmanagements ist das Monitoring des Netzes zu sehen. Die angebotenen Gesamtlösungen und das Marketing der Hersteller legen einen besonderen Fokus auf diesen Aspekt. Unabhängig von der eigentlichen Fabric-Lösung bieten Hersteller ein ganzes Set von Funktionen an, um Kommunikationspfade einzelner Anwendungen zu analysieren und so die Fehlersuche zu vereinfachen. Fehlerzustände lassen sich damit in Bezug auf die EAP/RADIUS-Authentisierung klarer nachvollziehen. Auch wenn die eigentliche Überwachungsfunktion losgelöst von der Technologie der Fabric ist, hat sie bei den meisten Anbietern doch einen bedeutenden Anteil an der Gesamtlösung und damit am Nutzen für den Kunden. Insbesondere diese Sicht auf oder in das Netz wird daher stark beworben. Dennoch wollen wir uns in diesem Artikel auf die Kommunikationsebenen der Fabric konzentrieren.

Wie sehen die Ebenen nun im Detail aus?

Um die Funktionsweise des Overlay genauer zu verstehen, muss man sich von der oben beschriebenen abstrakten Sichtweise lösen und in konkrete Protokoll-Beispiele der Produkte schauen. Die verschiedenen Varianten lassen sich nicht auf eine einzelne einfache Beschreibung herunterbrechen. Die folgenden Erläuterungen können daher nur als Beispiele verstanden werden und haben keinen Anspruch auf Vollständigkeit. Der interessierte Leser sei auf entsprechende weiterführende Informationen am Ende des Artikels verwiesen.
Prinzipiell gelten für alle Lösungen, dass sie Kombinationen und herstellerspezifische Abwandlungen der üblichen Standards nutzen. Selbst wenn der Hersteller sich auf einen offenen Standard beruft, heißt das noch lange nicht, dass hierbei Produkte verschiedener Anbieter zueinander kompatibel sind. Wer sich für eine Fabric oder ein Overlay entscheidet, bindet sich damit auch für die Zukunft immer an eine herstellerspezifische Lösung.

Ein Beispiel für eine solche Lösung ist Cisco Software-Defined Access (Cisco SDA). In unseren Kundenprojekten wird deutlich, dass Cisco in der Lage ist, durch geeignetes Marketing Interesse an dem Produkt zu wecken. SDA basiert auf dem Protokoll LISP (Location/Identifier Separation Protocol) und dem Tunnelformat VXLAN (Virtual Extensible LAN).
Einer der zentralen Aspekte von Cisco SDA ist die Steuerung des Netzes mithilfe zentraler Control Plane Nodes. Hinsichtlich der Datenweiterleitung bieten diese eine Adress- oder Service-Datenbank, welche für die Kommunikation abgefragt wird. Bei Anschluss eines Endgeräts wird mittels NAC (Network Access Control) das Endgerät der passenden Gruppe zugeordnet. Im Management definierte Regeln geben vor, welche Geräte miteinander kommunizieren dürfen.

Access Switches (sogenannte Edge Nodes) registrieren die angeschlossenen Subnetze oder Endgeräte-Adressen an zentraler Stelle. Bei entsprechendem Kommunikationsbedarf können andere Edge Nodes diese Informationen abfragen, um Daten entsprechend zustellen zu können.

Eine IP-Adresse im Overlay (Endgeräte-IP-Adresse) wird so auf die IP-Adresse des Edge Node im Underlay abgebildet, über welchen das Endgerät erreichbar ist. Die Kommunikation und vor allem die Netzstruktur des Overlay, in dem sich die Endgeräte befinden, können somit losgelöst von dem eigentlichen Netzdesign des Underlay sein. Dies ist in Abbildung 3 skizziert.

Die eigentlichen Nutzdaten werden gemäß VXLAN enkapsuliert und so durch das Underlay zum zuständigen Edge Node transportiert. Hier ist also der Edge Node das Ziel des VXLAN-Pakets. Dieser kann die Daten wiederum auspacken und dem Endgerät zustellen. Für das Endgerät arbeitet die Fabric damit transparent. Das bedeutet, dass die Zwischenschritte durch die Fabric (im VXLAN-Paket) für das Endgerät nicht ersichtlich sind. Das ursprüngliche IP-Paket oder der ursprüngliche MAC-Frame werden auf diesen Zwischenschritten nicht verändert.

SDA stellt zwar nur ein Beispiel dar. Es zeigt aber schon recht gut, wie Fabrics als solche funktionieren. Grundsätzliche Funktionen, wie die Gruppenbildung mithilfe von NAC-Systemen und die transparente Weiterleitung von Daten, sind in den meisten Fabrics ähnlich (aber nicht gleich) gelöst.

Dennoch ist dies nicht die einzige Fabric-Lösung, welche am Markt zu finden ist. Als weiteres Beispiel mit einem etwas anderen Design betrachten wir die SPBm-Lösung von Extreme Networks. Hierbei liegt der Fokus weniger auf einer zentralen Infrastruktur. Konkret setzt diese Lösung darauf, dass, nach einer NAC-basierten Authentisierung, Endgeräte einem Service (Layer-2-Netz) zugeordnet werden. Für die darauffolgende Kommunikation wird auf eine zentrale Datenbank verzichtet. Stattdessen werden die benötigten Informationen mittels IS-IS (Intermediate System to Intermediate System) als Routing-Protokoll zwischen den beteiligten Switches verteilt. Alle Access Switches, welche den gleichen Service bereitstellen, kennen sich und somit ihre Subnetze. Eine Weiterleitung der Daten wird daher ermöglicht.

Nutzdaten werden mittels SPBm (Shortest Path Bridging MAC) enkapsuliert und als MAC-in-MAC-Kommunikation auf Layer-2-Ebene transportiert.

Aus dem Design einer verteilten Control Plane resultiert, dass man die benötigten Protokolle ohne Managementsystem manuell konfigurieren könnte. Dies mag für den Normalfall keinen besonderen Vorteil bieten. Im Notfall kann das durchaus ein Weg zur Fehlerbereinigung sein, den ich andernfalls nicht hätte. Im Regelfall wird dennoch ein Management als zentrale Komponente vorgesehen.

Durch manuelle Konfiguration kann natürlich eine Alternative zu den Varianten der Hersteller implementiert werden. Wenn man bereit ist, auf Annehmlichkeiten des zentralen Managements und der Integration der Fabric-Protokolle zu verzichten, besteht so die Möglichkeit, entsprechende Protokolle unabhängig von einem Teil der Herstellerbindung zu nutzen.

Eine Möglichkeit ist die Konfiguration von EVPN/VXLAN. Hierbei fungiert EVPN (Ethernet VPN) bzw. MP-BGP (Multi-Protocol Border Gateway Protocol) als Control Plane. Layer-2- und Layer-3-Routing-Informationen können so im Netz zwischen VTEPs (Virtual Tunnel End Point – z.B. Access Switches) ausgetauscht werden. Als Data Plane wird wiederum VXLAN eingesetzt. Es gibt Hersteller, die im Bereich Campus-Fabric auf diese Protokolle setzten. Ein Beispiel dafür ist Juniper.

Eine mögliche EVPN/VXLAN-Architektur kann in Abbildung 5 nachvollzogen werden. Abbildung 6 skizziert hierzu, wie Daten in einer solchen Fabric sowohl als Layer-2-Netze (blaue Verbindung) als auch als Layer-3-Routing (grüne und rote Layer-2-Verbindung) weitergeleitet werden können.

Neben diesen Architekturmodellen gibt es weitere Alternativen, wie z.B. Tunnel-basierte Verfahren, die wir hier nicht im Detail beschreiben wollen. Tabelle 1 soll einen Eindruck vermitteln, welche Verfahren bei den unterschiedlichen Herstellern zum Einsatz kommen.

Sind klassische Netze eine Alternative?

Die wichtigste Frage an dieser Stelle ist, ob man Fabrics in seinem Netz überhaupt benötigt. Ein klassisches Netz ist möglicherweise weiterhin eine passende Alternative.

Viele der Funktionen, welche die Hersteller anpreisen, sind auch mit etablierten, bekannten Technologien umsetzbar. So kommen zur Automatisierung NAC und Skripte in Frage. Die Netztrennung kann mittels klassischer VLANs, VRFen oder auch MPLS erfolgen, und Firewalls sind ohnehin ein essentieller Bestandteil der Infrastruktur, welcher auch durch die Fabric nicht wegfällt.

Eine Automatisierung im Netzbetrieb und beim Zero Touch Deployment ist im klassischen Netz eingeschränkt möglich. Bei Bedarf ist man hier auf den Zugriff auf API-Schnittstellen, Python-Programmierung und Vergleichbares angewiesen. Es ist daher entsprechendes Know-how notwendig.

Ein erster Schritt ist zu erfassen, welche Anforderungen (insbesondere aus betrieblicher Perspektive) bestehen und ob diese für den Einsatz einer Fabric sprechen. Dies kann je nach Umgebung durchaus recht unterschiedlich ausfallen.

Wesentlich hierbei ist aber, dass die Bestandteile einer integrierten Lösung eines Herstellers, inklusive des entsprechenden Managementsystems, natürlich aufeinander abgestimmt sind. Bei einer klassischen Lösung ist der Administrator selbst für diese Orchestrierung zuständig.

Wenn die Anforderungsanalyse allerdings keinen besonderen Bedarf hinsichtlich der Automatismen der Fabric ergeben hat, ist das klassische Netz häufig eine gute Wahl.

Erfahrungen aus Kundenprojekten

Tatsächlich sehen wir in unseren Kundenprojekten oftmals die Tendenz zu einem klassischen Netz. Die Faszination der neuen Lösungen besteht sicherlich. Somit wird das Thema in fast jedem aktuellen Netzdesign-Projekt angesprochen und diskutiert. Eine Umsetzung in der Praxis ist trotzdem rar.

Kunden mit einer etablierten Betriebsmannschaft stehen meist vor der Tatsache, dass die konkreten Anforderungen durch das Personal erfüllbar sind. Der Aufwand zur Konfiguration oder zur Betreuung des Netzes muss dem Versprechen der Hersteller von einer Aufwandsreduzierung und dem Know-how-Aufbau, welcher bei Umstieg auf eine neue Lösung notwendig wird, gegenübergestellt werden.

Wo entsprechende Lösungen vom Kunden konkret in Betracht gezogen wurden, bestanden meist auch besondere Anforderungen an die Technologie und vor allem an die Flexibilität des Netzes. Daher spielte die Automatisierung eine besondere Rolle.

Ein konkretes Beispiel ist ein Flughafen-Terminal, bei dem die notwendige Flexibilität unter anderem durch die Netzbereitstellung am Gate für wechselnde Fluggesellschaften erforderlich wurde. Mit ähnlichen Anforderungen hatten wir auch im Rahmen einer Netzerneuerung an einem großen Klinikum zu tun. Hierbei resultierte der Bedarf daher, dass besonders teure Medizingeräte ortsunabhängig und vor allem sicher angebunden werden sollten.

Ebenso wurde das Thema für ein großes Messegelände diskutiert, um die Ausstelleranbindung möglichst flexibel zu gestalten. Man kann sich in diesem Beispiel vorstellen, den Aufwand bei häufig wechselnden Messen zu reduzieren. Eine klassische VLAN/VRF-Konfiguration mit NAC bietet die notwendigen Funktionen mit einem entsprechenden Betrieb aber ebenfalls.

Im Endeffekt muss man sich immer mit den speziellen Eigenheiten der herstellerabhängigen Lösung befassen. Je nach eingesetzter Architektur können technische Anforderungen eine Fabric-Lösung erschweren oder dieser entgegenstehen. Gibt es beispielsweise einen großen Bedarf an Multicast-Kommunikation, so kann es der Fall sein, dass diese im Underlay als Unicasts mit höherer Datenlast übertragen werden. Ebenso nicht zu vernachlässigen sind eventuelle Abhängigkeiten zentralisierter Ansätze mit einem Lookup in einer Datenbank und einer Erhöhung der Latenz.

Zu guter Letzt sind die Anbindung und die Abhängigkeiten mit Blick auf andere bestehende Netze eine zu betrachtende Problemstellung. Es kann erforderlich sein, IP-Konzepte anzupassen und entsprechende Anbindungen neu zu konfigurieren. Häufig findet eine Verwaltung der IP-Adressen durch die Management-Lösung statt. Dies kann so weit gehen, dass Router-Interfaces ihre Adresse ändern. Statische Routen von externen Netzen erfordern daher ggf. eine Anpassung, wie wir in einem Kundenprojekt erlebt haben.
Ein ebenso wichtiger Punkt ist für die meisten Kunden die Migration zu solch einem Netz hin. Auf der grünen Wiese erscheint dies recht simpel. Die meisten Kunden arbeiten allerdings mit bestehenden Netzen.

Typischerweise wird in Teilen ein Parallelaufbau von bestehender und neuer Infrastruktur notwendig, wenn größere Ausfälle verhindert werden sollen. Das rührt daher, dass es einen klaren Übergang zwischen dem bestehenden Netz und der Fabric geben muss, da ersteres aus Sicht der Fabric-Lösung als externes Netz verstanden wird. Dieser Übergang findet meist an zentraler Stelle statt. Eventuelle Distribution- und Access-Ebenen können dann Zug um Zug migriert werden. Eine schrittweise Migration erfordert auf den darüberliegenden Ebenen einen Parallelbetrieb bis zur Schnittstelle zwischen altem und neuem Netz. Kurzum, die Einführung einer Fabric ist eine „Komplett-Migration“ des Netzes und vergleichbar mit einem Herstellerwechsel. Der notwendige Know-how-Aufbau kann ebenfalls dem Bedarf bei einem Wechsel des Herstellers ähneln.

Zusammenfassung

Zusammenfassend lässt sich somit sagen, dass eine Fabric-Lösung sicherlich mit Ihren angepriesenen Vorteilen Flexibilität, Sicherheit, Automatisierung und Management sehr attraktiv ist. Bei entsprechenden Anforderungen kann ein Einsatz in Betracht gezogen werden. Wir sehen jedoch immer wieder, dass hier eine genaue Prüfung notwendig ist.

Wir empfehlen, eine solche Umsetzung mit einem Proof of Concept zu begleiten, um unerwartete Überraschungen zu vermeiden. Darüber hinaus muss klar sein, dass die Entscheidung für eine Fabric-Lösung immer eine Entscheidung für eine herstellerspezifische Lösung ist. Die Unterschiede in der Umsetzung sind zu groß, um herstellerunabhängig betrachtet zu werden.

Abhängig von den Anforderungen und dem bisherigen Betrieb kann man einen Großteil der Funktionen ebenso gut in einem klassischen Netz abbilden. Daher bildet dies für viele Kunden den Startpunkt der Evaluierung.

Man kann also festhalten, dass neue Besen vielleicht gut kehren, alte Besen aber auch. Ob der Bedarf für einen neuen Besen ausreicht und ob der Betreiber das eine oder das andere bevorzugt, ist tatsächlich individuell und projektspezifisch.

Weiterführende Literatur

[1] Florian Hojnacki, SD-Lösungen für Campusnetze, https://www.comconsult.com/sd-loesungen-campusnetze/
[2] IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging, https://tools.ietf.org/html/rfc6329
[3] Juniper Networks, EVPN-VXLAN CAMPUS FABRICS, Solution Brief, https://www.juniper.net/assets/us/en/local/pdf/solutionbriefs/3510643-en.pdf
[4] Controlware / Extreme Networks, Matthias Neumann, Netz Microsegmentierung zur automatisierten Absicherung von Produktionsnetzen am Beispiel der Extreme Networks Fabric-Connect Lösung, https://www.controlware.de/fileadmin/dateien/termine/vortraege/2019-06_WSKassel_03_Secure_Automated_Campus.pdf
[5] Sara Perrott, Fabric Networking for dummies – Extreme Networks Special Edition, https://kapost-files-prod.s3.amazonaws.com/