Von der Fabric im Kern bis zur durchgängigen Architektur über alle Standorte. Welche Designvariante zu Ihrem Netz passt und wo die Grenzen liegen.

Beim Netzwerkdesign mit Extreme Networks stellt sich früh die Frage, wie viel Fabric ein Netz wirklich braucht. Extreme Fabric basiert auf Shortest Path Bridging (SPB, IEEE 802.1aq) und ersetzt Spanning Tree, OSPF und PIM weitgehend durch eine einzige Steuerungsebene auf Basis von IS-IS. Dienste wie VLANs, VRFs oder Multicast werden nur noch am Rand des Netzes konfiguriert.

Wie weit Sie diese Architektur ins Netz tragen, bleibt Ihre Entscheidung. Im Folgenden geht es um vier gängige Ansätze, den Vergleich mit EVPN-VXLAN und den Weg dorthin ohne Big Bang.

Das Wichtigste in Kürze

  • Extreme Fabric virtualisiert Layer 2, Layer 3 und Multicast über ein einziges Protokoll. Neue Dienste werden nur an den Randknoten eingerichtet.
  • Vier Designansätze sind üblich: Fabric im Kern mit Fabric Attach, durchgängige Fabric bis zum Access, Standortanbindung per Fabric Extend und Fabric-Funktionen im Rechenzentrum.
  • SPB ist im Campus oft einfacher zu betreiben als EVPN-VXLAN. EVPN bietet dafür mehr Herstellervielfalt und ist im Rechenzentrum verbreiteter.
  • Skalierung, I-SID-Schema und Werkzeuge wie L2 Ping und Fabric RSPAN gehören früh ins Design.
  • Die Migration erfolgt parallel zum Bestandsnetz in vier Schritten, von neuem Core bis zum Rückbau.

Warum klassische Netzwerkdesigns an Grenzen stoßen

Viele Unternehmensnetze folgen noch dem Dreischichtmodell aus Access, Distribution und Core. Im Access laufen VLANs mit Spanning Tree, in der Distribution sorgen VRRP und OSPF für Redundanz und Routing. Für Multicast oder Mandantentrennung kommen PIM, VRFs und gegebenenfalls MPLS hinzu.

Das funktioniert, kostet aber Aufwand. Jede Dienstschicht bringt ein eigenes Protokoll mit, mit eigenem Konvergenzverhalten, eigener Fehlersuche und Konfiguration auf vielen Geräten.

Spürbar wird das bei alltäglichen Anforderungen: ein gebäudeübergreifendes Segment für die Gebäudetechnik, sauber getrennte IoT-Geräte oder ein Außenstandort mit denselben Diensten wie die Zentrale. Im klassischen Design bedeutet jede dieser Änderungen Eingriffe in Access, Distribution und Core, also Wartungsfenster und Fehlerrisiko.

Was Extreme Fabric technisch ausmacht

Ein Protokoll statt eines Protokollstapels

Kern der Architektur ist Fabric Connect, die Extreme-Implementierung von SPBM (Shortest Path Bridging MAC-in-MAC) nach IEEE 802.1aq und RFC 6329. Alle Fabric-Knoten sprechen IS-IS und kennen damit die komplette Topologie. Datenverkehr wird per MAC-in-MAC-Kapselung nach IEEE 802.1ah transportiert.

Dabei gibt es zwei Rollen. Backbone Edge Bridges (BEB) sind Randknoten, an denen Dienste beginnen und enden. Backbone Core Bridges (BCB) leiten nur anhand des äußeren Headers weiter und kennen die transportierten Dienste nicht. Der Kern muss bei neuen Diensten deshalb nicht angefasst werden.

Jeder virtuelle Dienst erhält eine Service Instance ID (I-SID). Mit 24 Bit stehen rund 16 Millionen Kennungen zur Verfügung statt 4.094 nutzbarer VLAN-IDs.

Dienste statt VLAN-Strecken

Extreme Fabric kennt mehrere Diensttypen, die sich frei kombinieren lassen:
L2VSN
verbindet ein VLAN über eine I-SID mit beliebigen anderen Punkten der Fabric, gebäude- oder standortübergreifend.
L3VSN
bildet eine VRF auf eine I-SID ab und ersetzt klassische MPLS-IP-VPNs für Mandanten- oder Sicherheitstrennung.
IP Shortcuts
routen IPv4 und IPv6 der globalen Routingtabelle direkt über IS-IS, ohne separates OSPF im Kern.
IP-Multicast
wird innerhalb der Fabric ohne PIM-Konfiguration im Kern geroutet, relevant etwa für Videoverteilung, Gebäudeleittechnik oder Alarmierung.

„Kürzeste Wege, alle Links aktiv“

Jeder Fabric-Knoten berechnet aus der IS-IS-Datenbank die kürzesten Wege zu allen anderen Knoten. Hin- und Rückweg zwischen zwei Knoten sind dabei identisch. Die Linkkosten orientieren sich an der Bandbreite, neuere Fabric-Engine-Releases setzen sie auf Wunsch automatisch. Über mehrere Backbone-VLANs verteilt die Fabric Dienste auf gleichwertige Pfade, sodass redundante Verbindungen nicht brachliegen.

Fällt ein Link aus, rechnen die Knoten die Pfade neu, ohne dass ein Protokoll wie Spanning Tree Ports erst wieder freischalten muss. Da Unicast, Multicast und virtualisierte Dienste dieselbe Steuerungsebene nutzen, konvergieren sie gemeinsam statt nacheinander.

Automatisierung an der Kante

Mit Fabric Engine, dem Betriebssystem der aktuellen Universal-Switches, sind Auto-sense-Ports im Auslieferungszustand aktiv. Ein Port erkennt selbstständig, was angeschlossen wird: ein Fabric-Switch, ein Fabric-Attach-Gerät, ein IP-Telefon, ein Endgerät mit 802.1X oder eine SD-WAN-Appliance.

Je nach Erkennung richtet der Port einen Fabric-Link, einen FA-Link, einen Voice-Port oder, bei konfiguriertem RADIUS, einen NAC-geschützten Zugang ein. Zusammen mit der automatischen Vergabe von Knotenkennungen lassen sich neue Switches weitgehend ohne manuelle Vorplanung in die Fabric integrieren.

Dier vier Designansätze im Überblick

Ansatz 1: Fabric im Kern, Fabric Attach im Access

Core und Distribution bilden die SPB-Fabric, im Access laufen einfachere Switches weiter. Fabric Attach nach IEEE 802.1Qcj verbindet beide Welten: Ein Access-Switch als FA-Proxy oder ein Access Point als FA-Client signalisiert per LLDP, welches VLAN zu welcher I-SID gehört. Der Fabric-Switch als FA-Server richtet die Zuordnung automatisch ein.

Das schont das Budget. Etagenverteiler müssen nicht sofort getauscht werden, neue Access Points erhalten ihre Segmente automatisch, auf Wunsch auch gesteuert über NAC.

Fabric Attach hat aber Grenzen. Es automatisiert nur Layer-2-Zuordnungen, L3VSNs müssen am FA-Server vorbereitet sein. Außerdem ist die Zahl signalisierbarer VLAN/I-SID-Paare pro Proxy begrenzt. Die vielen Kombinationen aus Plattformen, Management-VLANs und NAC-Varianten verlangen eine sorgfältige Planung.

Ansatz 2: Durchgängige Fabric bis zum Etagenverteiler

Laufen auch die Access-Switches mit Fabric Engine, wird jeder Etagenverteiler selbst zur BEB. Dienste enden direkt dort, wo Nutzer und Geräte angeschlossen sind. Zwischen den Switches ist kein Spanning Tree mehr nötig, beide Uplinks bleiben aktiv. Layer-3-Konfiguration im Access entfällt trotzdem.

Am meisten bringt dieser Ansatz bei der Netzwerksegmentierung. In Kombination mit NAC wird ein Endgerät nach der Authentifizierung automatisch dem passenden Dienst zugewiesen. Wird es abgesteckt, verschwindet die Zuordnung wieder. In Krankenhäusern, Hochschulen oder Produktionsstandorten mit vielen IoT- und OT-Geräten spart das viel Handarbeit.

Ansatz 3: Standorte anbinden mit Fabric Extend und SD-WAN

Fabric Extend trägt die Fabric über IP-Netze hinweg. Die IS-IS-Nachbarschaften werden über VXLAN-Tunnel aufgebaut, sodass jeder Fabric-Dienst an jedem Standort verfügbar ist, vom L2VSN bis zum Multicast.

Beim Design ist vor allem die MTU zu beachten. Die Kapselung erfordert im WAN eine MTU von mindestens 1.600 Byte, was in MPLS-Netzen meist unkritisch ist. Über das Internet mit einer MTU von 1.500 Byte sind IPsec und Fragmentierung nötig. Das übernimmt das Fabric IPsec Gateway als virtuelle Maschine auf geeigneten Switches oder eine SD-WAN-Appliance.

Bei der Integration mit ExtremeCloud SD-WAN lernen die Fabric-Switches die Tunnelparameter direkt von der Appliance. Die SD-WAN-Seite liefert applikationsbasierte Wegewahl und Priorisierung. Fällt eine Leitung aus, signalisiert die Appliance den Tunnelverlust und die Fabric routet schnell um.

Ansatz 4: Rechenzentrum und Serverräume

Im Rechenzentrum stehen drei Bausteine im Mittelpunkt. Switch-Cluster mit virtuellem Inter-Switch-Trunk (vIST) terminieren Link-Aggregation von Servern auf zwei Switches, die nicht direkt verbunden sein müssen. Distributed Virtual Routing (DVR) verteilt das Default Gateway auf die Top-of-Rack-Switches, sodass Ost-West-Verkehr dort geroutet wird, wo der Server angeschlossen ist.

Dritter Baustein ist das Anycast Gateway für IPv4. Dafür müssen alle Fabric-Knoten einen passenden Softwarestand haben, ein typischer Stolperstein bei gemischten Release-Ständen. Ob die SPB-Fabric im Rechenzentrum die richtige Wahl ist, hängt stark vom Umfeld ab.

SPB oder EVPN-VXLAN: wann was passt

EVPN-VXLAN hat sich als Standard für IP-Fabrics im Rechenzentrum etabliert und wird zunehmend auch im Campus angeboten. Es trennt ein geroutetes IP-Underlay von einem BGP-EVPN-Overlay. Extreme unterstützt EVPN-VXLAN ebenfalls, etwa auf Switches mit Switch Engine.

Für SPB spricht die Einfachheit. Ein einziges IS-IS steuert Unicast, Multicast, L2- und L3-Virtualisierung, und alle Dienste nutzen dieselbe Topologiedatenbank. EVPN-VXLAN kombiniert typischerweise ein IGP oder BGP im Underlay, BGP EVPN im Overlay und je nach Design PIM oder Ingress Replication. Das ist leistungsfähig, verlangt aber mehr Protokoll-Know-how im Betrieb.

Für EVPN-VXLAN sprechen Herstellervielfalt, breite Unterstützung in RZ-Ökosystemen und ein großer Pool an Fachkräften. Den Punkt Herstellerbindung sollten Sie offen bewerten: SPB ist standardisiert und auch bei anderen Herstellern zu finden. Die Kombination mit Fabric Attach, Fabric Extend und DVR ist in dieser Tiefe jedoch Extreme-spezifisch, gemischte SPB-Fabrics mehrerer Hersteller sind in der Praxis selten.

Im Campus mit vielen Segmenten, Multicast-Anforderungen und kleinem Betriebsteam hat SPB klare Vorteile. In großen, heterogenen Rechenzentren mit Automatisierung rund um EVPN kann eine IP-Fabric die bessere Wahl sein. Beide Welten lassen sich an definierten Übergabepunkten koppeln.

Langer, moderner Serverraum mit mehreren Racks, die mit blau leuchtenden Netzwerk- und Datacenter-Komponenten bestückt sind, reflektiert in einer Glaswand, symbolisiert IT Solutions, Managed Services und Cloud Services der dierckgroup.
Mehrere blaue Netzwerkkabel sind an die Rückseite eines Servers angeschlossen, der in einem Rechenzentrum steht. Die Kabel sind mit Etiketten versehen und verbinden den Server mit einem Server-Hub, was typische Netzwerklösungen und IT-Infrastruktur symbolisiert. Das Bild steht im Kontext von IT Solutions, Managed Services, Cloud Services und IT-Support der dierckgroup.

Sicherheit und Segmentierung als Designprinzip

Virtuelle Dienste wie L2VSN und L3VSN werden per MAC-in-MAC transportiert. Der Kern und diese Dienste sind dadurch für IP-basierte Scans nicht sichtbar, der Hersteller spricht vom Stealth-Modus. Für Verkehr, der per IP Shortcuts in der globalen Routingtabelle läuft, gilt das nicht.

IS-IS-Nachbarschaften lassen sich per HMAC-SHA256-Authentifizierung absichern, Links per MACsec verschlüsseln. Auto-sense-Ports können so konfiguriert werden, dass sie keine Fabric-Nachbarschaft zulassen.

Richtig wirksam wird das zusammen mit NAC. Makro-Segmentierung über L3VSNs trennt etwa Verwaltung, Medizintechnik und Gebäudeleittechnik, Mikro-Segmentierung über Policies regelt die Kommunikation innerhalb eines Segments. Mit Blick auf NIS-2, die angemessene technische Maßnahmen zum Risikomanagement fordert, wird eine wirksame Netzwerktrennung für viele Organisationen zu einem zentralen Baustein.

Skalierung und Fabric-Grenzen im Design

Wie groß ein Fabric-Bereich werden kann, begrenzt die leistungsschwächste Plattform darin. Core-Switches verkraften deutlich mehr Fabric-Knoten, VRFs und Nachbarschaften als kompakte Access-Modelle. Laut Herstellerunterlagen liegen die Werte pro IS-IS-Bereich je nach Plattform bei mehreren hundert Knoten.

Für größere Netze gibt es IS-IS Multi-Area. Ausgewählte Plattformen arbeiten dabei als Grenzknoten zwischen zwei Bereichen, sodass sich etwa ein großer Campus und seine Außenstellen getrennt skalieren lassen, ohne die gemeinsame Dienstlogik aufzugeben.

Zwei Dinge gehören deshalb vor die Migration: ein I-SID-Schema, das Diensttypen, Standorte und Mandanten logisch abbildet, und ein Abgleich der geplanten Dienste gegen die Skalierungswerte der Access-Plattformen. Beides lässt sich später nur mit Aufwand korrigieren.

Migration: schrittweise statt Big Bang

Eine Fabric lässt sich parallel zum Bestandsnetz aufbauen. Bewährt hat sich ein Vorgehen in vier Schritten:

  • Neuen Fabric-Core neben dem bestehenden OSPF-Kern aufbauen und VLANs sowie Subnetze dorthin erweitern.
  • Neue Aggregationsebene mit Fabric-Links zum neuen Core ergänzen.
  • Etagenverteiler schrittweise auf die neuen Aggregationsknoten umschwenken.
  • Verbleibende Leitungen migrieren und Altgeräte zurückbauen.

Für die Übergangsphase gibt es Brückenfunktionen. Routen lassen sich zwischen OSPF und IS-IS mit Route-Tags austauschen, ein PIM-Gateway koppelt Multicast-Welten, und MSTP-Domänen können redundant angebunden werden.

Die Fabric im Betrieb: Transparenz und Fehlersuche

Overlays gelten als schwer zu durchschauen. Extreme Fabric nutzt dafür Werkzeuge aus der Ethernet-Welt. Nach IEEE 802.1ag (Connectivity Fault Management) stehen L2 Ping und L2 Traceroute direkt auf Ebene der Fabric zur Verfügung, ergänzt um Varianten für Multicast-Bäume.

Mit Fabric RSPAN lässt sich Verkehr an beliebigen Fabric-Knoten spiegeln und über eine eigene I-SID zu einem zentralen Analysesystem transportieren, ohne dafür Kabel oder separate Monitoring-Netze zu ziehen. Fabric QoS übernimmt je nach QoS-Modell die Markierungen aus dem Access in die Kapselung, sodass Sprache und Video über den gesamten Pfad bevorzugt behandelt werden.

Weil Pfade symmetrisch berechnet und Dienste fest einem Backbone-VLAN zugeordnet werden, lässt sich nachvollziehen, welchen Weg ein Dienst nimmt. Das vereinfacht Kapazitätsplanung und Fehlersuche gegenüber Designs, in denen Spanning Tree über aktive und blockierte Wege entscheidet.

Voraussetzungen in Kürze

Extreme Fabric läuft auf Switches mit Fabric Engine, auf älteren VSP-Plattformen unter dem früheren Namen VOSS. Die aktuellen Universal-Switches unterstützen wahlweise Fabric Engine oder Switch Engine, die Architekturentscheidung bleibt damit auch nach dem Kauf offen. Einige Funktionen wie DVR-Controller oder das Fabric IPsec Gateway setzen laut Herstellerunterlagen eine Premier-Lizenz voraus. Verwaltet wird die Fabric zentral, etwa über Extreme Platform ONE mit Zero-Touch-Provisioning und Erkennung von Konfigurationsabweichungen. Eine Prüfung gegen die aktuellen Release Notes gehört in jede Architekturplanung.

Fazit

Beim Netzwerkdesign mit Extreme Networks geht es vor allem darum, Komplexität aus dem Netz zu nehmen. Eine Fabric ersetzt mehrere Protokolle durch eines und verschiebt die Konfiguration an den Rand. Segmentierung ist dann keine Zusatzaufgabe mehr, sondern Teil der Architektur.

Welcher Ansatz passt, hängt von Bestand, Standorten, Rechenzentrum und Betriebsteam ab. In den meisten Projekten lohnt sich ein klares Zielbild, das in wirtschaftlich sinnvollen Schritten erreicht wird.

Häufige Fragen zu Extreme Fabric

Was ist Extreme Fabric?

Extreme Fabric ist die Netzwerkarchitektur von Extreme Networks auf Basis von Shortest Path Bridging (IEEE 802.1aq). Sie virtualisiert Layer-2-, Layer-3- und Multicast-Dienste über eine einzige IS-IS-Steuerungsebene und automatisiert die Bereitstellung an den Randknoten.

Was ist der Unterschied zwischen Fabric Connect und Fabric Attach?

Fabric Connect ist die eigentliche SPB-Fabric zwischen Fabric-fähigen Switches. Fabric Attach bindet Geräte ohne SPB-Unterstützung, etwa Access-Switches oder Access Points, automatisch an Fabric-Dienste an, indem VLAN-zu-I-SID-Zuordnungen per LLDP signalisiert werden.

Kann ich bestehende Switches weiter nutzen?

Ja, in vielen Fällen. Fabric-Attach-fähige Switches, in der Regel Extreme-Geräte, werden automatisch an Fabric-Dienste angebunden. Switches anderer Hersteller lassen sich klassisch über getaggte Uplinks integrieren. Die Migration kann parallel zum laufenden Netz erfolgen.

Funktioniert Extreme Fabric auch über das WAN?

Ja. Fabric Extend überträgt die Fabric per VXLAN über IP- oder MPLS-Netze, über das Internet zusätzlich per IPsec. Eine Integration mit ExtremeCloud SD-WAN automatisiert die Tunnelkonfiguration.

Ist SPB besser als EVPN-VXLAN?

Nicht grundsätzlich. SPB ist im Campus meist einfacher zu betreiben, EVPN-VXLAN bietet mehr Herstellervielfalt und ist im Rechenzentrum verbreiteter. Die Entscheidung hängt von Umgebung, Skalierung und Betriebskompetenz ab.