Overlays in der Analyse – Teil 1: EVPN vs. SPBM

Kommentieren Drucken

Die gesamte Rechenzentrumsinfrastruktur befindet sich derzeit im Umbau: weg von den klassischen Einzelboxen, die als Server, Switch, Firewall etc. individuell für einzelne Anwendungen konzipiert wurden, hin zu einer integrierten Gesamtstruktur, die gemeinhin als Cloud Computing bezeichnet wird. Die Gründe für diesen Wandel sind im Wesentlichen bekannt, im Vordergrund stehen die Bereitstellung und der Betrieb von Anwendungen. Anwendungen müssen schnell und flexibel nutzbar zur Verfügung stehen, um auf Kundenanforderungen unmittelbar und zielgerichtet reagieren zu können und um notwendige Änderungen bei den Geschäftsprozessen in kürzester Zeit umsetzen und neue Funktionen adäquat unterstützen zu können. Der Druck aus dem Markt ist in jeder Branche enorm.

Im folgenden Artikel werden zunächst die grundlegenden Konzepte und Bausteine von Overlay-Technologien und deren diversen Ausprägungen analysiert. Im zweiten Teil stellen wir dann mit SPBM und EVPN zwei verbreitete Overlay-Lösungen gegeneinander, die gleichzeitig für die beiden Basistechnologien in Unternehmensnetzen stehen: Layer 2 (Ethernet) und Layer 3 (IP).

Jede Entwicklung im und um das Rechenzentrum wird derzeit getrieben von dem Anspruch, zumindest große Teile der Konfiguration von Lösungen und bereitgestellter Ressourcen automatisieren zu können. Dies gilt auch und gerade in virtualisierten Umgebungen. Zero-Touch- oder One-Stop-Provisioning lauten hier die Schlagworte.

Die Kernanforderungen lauten also: automatisierte Bereitstellung, flexible Konfiguration, geringer Administrationsaufwand, effizienter Betrieb, Fokussierung auf die Anwendungen.

Für den Netzwerkbereich haben sich hierzu zwei Technologiebereiche entwickelt: Switch-Fabrics und Overlays. Overlays trennen das Netzwerk in ein physisches Transportnetz und verschiedene logische Anwendungsnetze – oder je nach Sichtweise in ein (physisches) Providernetz und virtuelle Kundennetze (VPNs – Virtual Private Networks). Overlays adressieren also eher die Punkte Flexibilität und Effizienz bei der Bereitstellung und dem Betrieb von Anwendungen, während bei Fabrics das Underlay, das physische Transportnetz, im Vordergrund steht, verbunden mit der Fähigkeit hohen Durchsatz bei möglichst geringem Delay zur Verfügung zu stellen.

Im Folgenden werden zunächst die grundlegenden Konzepte und Bausteine von Overlay-Technologien betrachtet:

  • Was bedeutet der Begriff „Overlay“, aus welchen Bausteinen setzt sich eine Lösung zusammen?
  • Wieso setzen moderne Netzdesigns auf Overlay-Strukturen?
  • Was leisten Overlays in Enterprise-Umgebungen?
  • Wie werden die beiden Netzbereiche Overlay und Underlay gesteuert?

Konzepte und Bausteine

Der Begriff Overlay bezeichnet eine Netzwerkschicht, die über eine Abstraktionsebene von der darunterliegenden Schicht (die dann mitunter als Underlay bezeichnet wird) getrennt ist. „Overlays“ sind also eng mit „Virtualisierung“ verbunden, beide Begriff beschreiben vergleichbar Konzepte. Die technische Realisierung des Transports von Overlay-Strukturen durch das Netzwerk erfolgt dann durch Tunnelprotokolle.

Daher werden je nach Sichtweise und Standpunkt die Begriffe Overlay, Netzwerkvirtualisierung, VPN (Virtual Private Network) und Tunnelprotokoll gerne gleichbedeutend für dieselbe Technologie verwendet. Trotzdem sollte man dies alles nicht unreflektiert in einen Topf werfen.

Overlays im obigen Sinn sind jetzt wirklich Neues. Es gibt wenigstens zwei weitverbreitete Overlay-Technologien, die den meisten Lesern bekannt sein werden:

  1. MPLS (Multiprotocol Label Switching):
    MPLS wird genutzt, um räumlich getrennte, meist IP- oder Ethernet-basierende Netzbereiche über große, internationale Transportnetze miteinander zu verbinden.
  2. VLANs (Virtual LANs):
    VLANs werden genutzt, um Layer-2-Domänen in kleinere, voneinander unabhängige Netze zu segmentieren.

Schon anhand dieser beiden Beispiele können zwei wesentliche Funktionsmerkmale von Overlay-Lösungen festgehalten werden:

  1. Angebundene Netzsegmente, die zusammengehören, werden transparent miteinander verbunden.
  2. Netzsegmente, die zu verschiedenen Kunden oder Sicherheitszonen etc. gehören, müssen jedoch sicher voneinander getrennt werden, ohne dass Kunde A Verkehrsströme von Kunde B sehen oder beeinflussen kann. (siehe Bilder 1 und 2)

Eine technische Gesamtlösung, die Overlays zur Verfügung stellt, besteht also mindestens aus folgenden Bausteinen:

  • einem physischen Transportnetz und
  • mehreren daran angebundenen Kundensegmente (das können Einzelsysteme oder Teilnetze sein), die zu einem oder mehreren Kunden (Benutzergruppen, Services, Sicherheitszonen etc.) gehören,
  • einem Tunnelprotokoll und
  • Steuerungsebenen (Control Layer) für Overlay und Underlay.

Darüber hinaus ist gerade in Unternehmensrechenzentren in der Regel auch eine Virtualisierungsplattform mit Hypervisor und Management-Software integriert bzw. involviert.

Diese Bausteine und ihre Funktionsweisen werden im Weiteren genauer dargestellt.

Wie und warum werden Overlays überhaupt eingesetzt?

Für Unternehmensnetze können wir von folgender allgemeiner Situation ausgehen:

  1. Es besteht ein verbreiteter Bedarf das Gesamtnetz in unabhängige Teilnetze zu unterteilen, in der Regel geschieht dies durch VLANs. Die Gründe hierfür sind vielfältig und reichen von der Notwendigkeit, die Broadcast-Last und der Größe von Fehlerdomänen zu beschränken, bis zu dem Wunsch, Benutzergruppen, Dienste, Anwendungen, Sicherheitsbereiche etc. unabhängig voneinander administrieren und steuern zu können.
  2. Um trotzdem Kommunikationsbeziehungen auch zwischen diesen Teilnetzen zulassen zu können, werden hierauf Layer-3-Strukturen abgebildet und diese IP-Subnetze über Routing-Instanzen wieder miteinander verbunden.
  3. Im Rechenzentrum sind Virtualisierungslösungen insbesondere für Compute- und Storage-Ressourcen im Einsatz. Der effektive Betrieb dieser Lösungen erfordert es, dass speziell virtuelle Server flexibel und dynamisch auf Virtualisierungshosts platziert und bei Bedarf verschoben werden können – letzteres auch während des aktiven Betriebs. Soll dies unterbrechungsfrei aus Sicht der Anwendung geschehen, darf sich bei den meisten der derzeit genutzten Anwendungen die IP-Adresse nicht ändern.
  4. Im Rechenzentrum werden IP-Subnetze meist nach räumlichen Kriterien verteilt, also pro Rack oder pro Rackzeile ein Subnetz. Das ist natürlich für eine flexible Verteilung virtueller Maschinen und die dynamische Bereitstellung von Anwendungen äußerst ungünstig.
  5. Georedundante Rechenzentren werden im WAN in der Regel über unterschiedliche IP-Adressbereiche erreicht. Wie eben erwähnt, widerspricht dies der flexiblen Verteilung virtueller Maschinen und ihrer Anwendungen, aber auch einer schnellen Bereitstellung zustätzlicher Ressourcen.

Damit ergeben sich typische Einsatzszenarien für Overlay-Lösungen:

A) Virtuelle Anwendungsnetze:
In oder direkt hinter den Virtualisierungshosts (zum Beispiel im Top-of-Rack-Switch) werden Overlay-Netze aufgesetzt, die die virtuellen Maschinen, die gerade auf diesem Host oder diesem Rack platziert sind, mit ihren jeweiligen Layer-2-Domänen transparent verbinden. Damit können virtuelle Maschinen und Anwendungen unabhängig von einem speziellen Virtualisierungshost oder Server-Rack irgendwo im Rechenzentrum platziert und verschoben werden. Letzteres wird auch gerne mit dem Begriff „MAC Mobility“ bezeichnet. (siehe Bild 3)

B) RZ-Kopplung:
Georedundante Rechenzentren werden über Providernetze miteinander verbunden. Hierbei stellt in der Regel der Provider die Overlay-Technologie (nach wie vor meist MPLS). Für den Kunden ist es nur wichtig zu entscheiden, ob (aus seiner Sichtweise, also innerhalb der Tunnel) die Rechenzentren über Layer 2 oder Layer 3 verbunden werden sollen. Der erste Fall ist sicherlich einfacher und flexibler gerade für RZ-interne Kommunikationsbeziehungen, im zweiten Fall erscheint das gesamte Providernetz wie ein einziger Router, der die beiden Rechenzentren über IP verbindet.

C) Overlays zur Nutzung flexibler Netzwerkdesigns:
Das entscheidende Hemmnis zur Nutzung flexibler Designs wie Maschen, Ringe, Spine-Leaf und gegebenenfalls von Lastausgleich über parallele Wege (Equal Cost Multipathing – ECMP) ist der Spanning Tree bzw. die Unfähigkeit von Ethernet Schleifen zu verhindern. Klassischerweise wird dieses Manko durch ein Layer-3-Design und die Nutzung von Routingprotokollen wie OSPF (die ECMP unterstützen) überwunden. Solche Lösungen sind ohne zusätzlichen Automatisierungslayer jedoch administrativ sehr aufwändig und daher nur für kleine Netzbereiche (z. B. Übergang Core – Backbone) sinnvoll.

Wie oben erwähnt, haben Overlays aber nicht nur die Fähigkeit zu verbinden, sondern auch zu trennen. Daher werden einige Lösungen wie beispielsweise SPB auch dazu genutzt, um die Funktionalität klassischer VLANs einfach nur zu erweitern und Beschränkungen, die Layer-2-Netze mit sich bringen, aus dem Weg zu räumen. Hierzu gehören:

  • die gegebenenfalls zu geringe Anzahl von maximal gut 4.000 VLANs,
  • die Notwendigkeit, für jedes VLAN ein eigenes virtuelles Interface anlegen zu müssen,
  • die Beschränkung auf eine einzige Baumstruktur (Spanning Tree).

Kommen wir zu den Bausteinen einer Gesamtlösung.

Transport-Edge (Provider-Edge)

Die für das Gesamtkonzept wichtigsten und auch technisch aufwändigsten Komponenten sind offensichtlich die Systeme, die den Rand des Transportnetzwerks bilden:

  • Sie sind mit zwei Welten verbunden sind, dem Transportnetz und den angebundenen Anwendungs- bzw. Kundennetzen (siehe Bild 4), die sich unter Umstanden sogar in der Zugangstechnologie voneinander unterscheiden.
  • Sie müssen die Topologien und Netzwerktechnologien auf beiden Seiten unterstützen, das heißt sie müssen auf beiden Seiten Frames empfangen und senden können.
  • Hier werden die Tunnel bzw. die Overlays aufgesetzt, um die auf der Kundenseite empfangenen Frames durch das Transportnetz zu leiten.
  • Hier werden die Tunnel auch terminiert und die ausgepackten Inhalte an die richtigen Empfänger weitergeleitet.
  • Hier stoßen Underlay und Overlay aufeinander! Das heißt, sollen Informationen aus dem Overlay (wie beispielsweise QoS-Tags) auf das Underlay übertragen werden, dann hier.

Bild 4 zeigt den generischen Aufbau eines Edge-Systems.

Die Verbindung zwischen Kundennetz und Transportnetz erfolgt über eine Ab-straktions- und Steuerungsschicht sowie ein Overlay-Modul. Letzteres bildet den Tunnelendpunkt und ist für das Einpacken und Entpacken der Verkehrsflüsse in ein geeignetes Tunnelprotokoll zuständig, während auf der Abstraktions- und Steuerungsschicht (gerne auch als Virtualisierungsschicht bezeichnet) alle Funktionen implementiert sind, die einerseits unterschiedliche Kundennetze voneinander trennen und andererseits räumlich getrennte Netzsegmente, die zum selben Overlay gehören, miteinander verbinden. Hierzu gehören insbesondere die Wegewahl und Informationen über die Erreichbarkeit entfernter Endgeräte.

Diese Edge-Systeme werden im Allgemeinen als „Provider Edge“ gezeichnet, weil gerade bei Provider-Produkten die gesamte Technologie des Transportnetzes inklusive der Tunnelendpunkte meist im Netzwerk des Providers installiert ist. Das muss aber nicht zwingend so sein. Gerade bei Layer-2-VPNs zum Beispiel mit VXLAN kann es günstiger sein, die IP-Tunnel auf der Kundenseite aufzubauen und beim Provider ein einfacheres Layer-3-Produkt einzukaufen.

Wir bleiben daher im Folgenden bei der neutralen Bezeichnung Edge. Die zusätzliche Betrachtung eines „Customer Edge“ als letztes reguläres System im Kundennetz macht aus konzeptioneller Sicht eh keinen Sinn.

Ein solches Edge-System kann sowohl als Teil eines virtuellen Switches innerhalb eines Hypervisors als auch innerhalb eines physischen Switchs oder Routers oder auch in einer separaten Netzwerk-Appliance (Tunnel-Gateway) implementiert sein.

Servicetypen

Typischerweise können über eine Overlay-Struktur zwei Arten von Netzwerkservices transportiert werden: Layer-2-Services und Layer-3-Services.

Ein Layer-2-Service verbindet Ethernet-basierende Netzsegmente entweder auf einer Punkt-zu-Multipunkt- oder Multipunkt-zu-Multipunkt-Topologie. Typische Beispiele für Layer-2-Services sind MPLS L2VPN, SPB (Shortest Path Bridging nach 802.1aq), VXLAN oder EVPN (Ethernet VPN). Das Overlay stellt dabei also ein kundenspezifisches Layer-2-Switching zwischen den angebundenen Segmenten zur Verfügung. Als Transporttechnologien kommen sowohl Ethernet, IP als auch MPLS zum Einsatz.

Ein Layer-3-Service stellt dagegen kundenspezifisch eine IP-Routing-Funktionalität zwischen den angebundenen IP-Subnetzen zur Verfügung. Das hat zur Folge, dass zwischen diesen Subnetzen Routing-Informationen ausgetauscht werden müssen, die auch auf den Edge-Devices (Tunnelendpunkten) zur Verfügung stehen müssen. Mit anderen Worten, die Edge-Devices sind in das übergreifende Routing der Kundennetze eingebunden. Insbesondere wenn die Edge-Device zum Providernetz gehören, ist das nicht immer gewünscht.

Im Underlay kommen hierbei bevorzugt Layer-3-Technologien wie MPLS oder IP zum Einsatz.

Tunnelprotokolle

Der Frame-Aufbau von Tunnelprotokollen folgt im Wesentlich folgendem Schema (siehe Bild 5):

  • Vor den zu transportierenden Protokoll-Frame wird ein verfahrensspezifischer Tunnelheader gesetzt – mitunter wird auch das gesamte innere Protokoll in einen Tunnelrahmen eingebettet.
  • Das so neu verpackte Paket wird dann um die standardmäßigen Header des jeweiligen Transportnetzes erweitert und entsprechend transportiert.

Als Tunnelprotokolle kommen sowohl spezifische Protokolle, die dediziert auf ein inneres Protokoll zugeschnittenen sind, als auch generische Protokolle, die unterschiedliche Kommunikationsprotokolle transportieren können, zum Einsatz.

Es gibt also jeweils einen äußeren Header, der für den Transport durch das Transportnetz zuständig ist, gefolgt von einem Tunnelheader und den inneren Header des transportierten Pakets. Tunnelprotokolle gibt es wie Sand am Meer, einige populäre Beispiele sehen Sie in Bild 6.

Für Overlay-Lösungen kommen natürlich nur Protokolle infrage, die Layer-2- oder Layer-3-Frames transportieren. Die beiden Storage-Protokolle sind lediglich mit aufgeführt, um das grundlegende Prinzip zu verdeutlichen.

Wesentliches Merkmal solcher Protokolle ist, dass sie Endgeräte oder Netzbereiche transparent miteinander über das jeweilige Transportnetzwerk verbinden. Transparent bedeutet hierbei, dass aus Sicht der angebundenen remote Systeme das Transportnetz als solches gar nicht existiert. Die angebundenen Netze, Systeme oder Dienste „wissen“ nicht, dass sie sich durch einen Tunnel bewegen / bewegt haben, das Transportnetz verhält sich wie ein großer Switch oder Router.

Dieser Punkt beschreibt das generelle Virtualisierungskonzept:

Die in der virtuellen Welt bereitgestellten Ressourcen und Dienste funktionieren genauso wie in der physischen Welt. Dienste und Anwendungen müssen nicht an die konkrete Ausgestaltung des Transportnetzes oder des Tunnelprotokolls angepasst werden.

Die damit einhergehende logische Trennung in Overlay und Underlay hat zwei wichtige Konsequenzen:

  1. Struktur und Aufbau der virtuellen Overlay-Netze sind unabhängig von der Hardware und der Technologie des Underlays.

    Dies ist ein äußerst wichtiger Aspekt für den Aufbau flexibler Netzinfrastrukturen, für die schnelle, automatisierte Bereitstellung von Anwendungen – und natürlich für die nahtlose Integration von Cloud-Infrastrukturen, wo mir als Kunde die Technologie des Betreibers ja gegebenenfalls überhaupt nicht bekannt ist. Denn nur dank der durchgehenden Abstrahierung von allen physischen Ressourcen können virtuelle Overlays, inklusive deren virtuellen Workloads und Netzwerkdiensten in die Cloud verschoben und auch wieder zurückgeholt werden! Entscheidend hierfür ist die Virtualisierungsplattform, aber eben nicht die Hardware.

  2. Umgekehrt ist aber auch das Underlays befreit von allen Spezialitäten der angebundenen Kunden- und Anwendungsnetze.
    Die Weiterleitung innerhalb des Transportnetzes erfolgt ausschließlich anhand einfach auszuwertender Felder, die direkt im äußeren Transportheader stehen (wie MAC-Adresse, VLAN-ID, MPLS-Label). Aufwändige Lookups in tiefere Schichten des Pakets, insbesondere in den getunnelten kundenspezifischen Frame entfallen. Das macht die Weiterleitung schnell und den Betrieb einfach.

    Darüber hinaus sind auch die Weiterleitungstabellen in den Geräten deutlich kleiner und damit schneller zu bearbeiten, da nur die Netzwerkadressen aus dem Transportnetz bekannt sind. Die gegebenenfalls deutlich umfangreichere Zahl an MAC- und IP-Adressen sowie VLAN-Tags ist für den Kern des Transportsnetzes transparent.

    Umgangssprachlich heißt das, auch das Underlay muss nicht „wissen“, dass es Kundennetze in Tunnelprotokollen transportiert. Wiewohl dies nicht für die Tunnelendpunkte zutrifft, sondern nur für die Switche im Kern des Transportnetzes – und auch diese könnten, wenn es das Verfahren erfordert, durch einen tieferen Lookup die Tunnel natürlich sehen.

  3. Für Provider ist es sicherlich noch interessant, dass hiermit MAC-Adressen, IP-Adressen und VLAN-IDs kundenspezifisch bleiben und es bei Überschneidungen zu keinen Kollisionen kommt. In Unternehmensnetzen spielt dies eine eher untergeordnete Rolle, allenfalls die Möglichkeit, VLAN-IDs wiederzuverwenden, ist eine Option.

Der zwischen Transportheader und Header des transportierten Pakets eingeschobene Tunnelheader ist wesentlich dafür zuständig, dass in mandantenfähigen Designs Tunnel für unterschiedliche Kunden oder Services über dieselbe Infrastruktur transportiert und trotzdem sauber voneinander getrennt werden können. Hierfür muss im Tunnelheader der jeweilige Sicherheitskontext kodiert werden, damit am Tunnelende der entpackte Frame auch dem richtigen Kunden bzw. Netzsegment zugeordnet werden kann.

Zu diesem Zweck wird in der Regel eine netzwerkweit eindeutige Tunnel- oder Service-ID im Tunnelheader genutzt. Die Größe dieses Felds entscheidet darüber, wie viele Kontexte im Netz unterschieden werden können. Nachdem sich die 12 Bit große VLAN-ID schon in mittleren Umgebungen als zu klein herausgestellt hat, ist in den meisten neueren Tunnelprotokollen ein doppelt so großes ID-Feld vorgesehen. Damit können fast 17 Millionen virtuelle Netze unterschieden werden.

Bild 7 zeigt das Frameformat von PBB (Provider Backbone Bridges), dem Format, das von Shortest Path Bridging – MAC-Mode (SPBM) genutzt wird. Die Tunnel-ID heißt hier Service-Identifier (im Bild das Feld I-SID) und ist 24 Bit lang.

Steuerungsebene/Control Plane

Die wichtigsten Aufgaben der in Abbildung 4 dargestellten Control Plane betreffen die korrekte Zustellung von durchgeleiteten Frames. Hierzu muss jedes Edge-System Regeln verwalten, welche Kundensegmente zusammengehören, welche getrennt werden müssen, wie sie unterschieden werden, welche Endsysteme über lokal angebundene Segmente erreicht werden und wie entfernte Endsysteme erreicht werden können.

Die Zuordnung von ankommenden Frames zu „ihrem“ virtuellen Overlay und umgekehrt erfolgt über Regeln, die meist administrativ verwaltet oder von einem übergeordneten Managementsystem übermittelt werden. Typische Kriterien für solche Zuordnungen sind neben dem Eingangsport des Frames die üblichen Netzwerkadressen von Layer 2 bis Layer 4 inklusive der VLAN-ID des Frames.

Die Weiterleitung der Frames selbst erfolgt dann anhand von Weiterleitungstabellen der Form:

  • Netzwerkadressen des Endsystems
  • zugehörige Tunnel-ID
  • Erreichbarkeit (Das ist entweder der lokale Switch-Port oder der entfernte Tunnelendpunkt, hinter dem das Endsystem zu erreichen ist.)

Bei der Frage nach der konkreten Weiterleitung des Tunnel-Frames kommen wir zu einem sehr grundlegenden Punkt der jeweiligen Lösung:

Wie sehr sind die Control Layer von Overlay und Underlay miteinander verquickt? Und natürlich hängt diese Frage eng mit der geforderten Hardware-Unabhängigkeit der Lösung zusammen.

Hypervisor-basierende Lösungen wie NSX verwalten zu entfernten Endsystemen ausschließlich die Netzwerkadresse des entfernten Tunnelendpunkts und halten sich damit aus der Wegewahl durch das Transportnetz komplett raus.

Befindet sich dagegen der Tunnelendpunkt auf einer aktiven Netzwerkkomponente, die ihrerseits bereits Teil des Underlays und gegebenenfalls eines Routingprozesses im Underlay ist, dann entscheidet dieses Edge-System nicht nur zu welchem entfernten Tunnelendpunkt der verpackte Frame geschickt wird, sondern eben auch auf welchem Weg durch das Underlay dies geschieht. Vergleichen Sie hierzu Bild 8 mit Bild 3.

Dies bringt zusätzliche Komplexität in das Edge-Device und verquickt die Weiterleitungsentscheidungen im Overlay mit denen im Underlay.

Der Aufbau dieser Tabellen kann ganz klassisch durch Lernen von eingehenden Frames auf der Data Plane erfolgen (Data Plane Learning). Dieses „Lernen“ von Netzwerkadressen hat aber einen großen Nachteil: Unbekannte Zieladressen müssen im virtuellen Overlay geflutet, das heißt, an alle potentiellen Endpunkte, die zum gleichen Overlay gehören, ausgeliefert werden. Im Overlay geschieht dies wie gewohnt durch Broadcasts oder Anycasts, was schon aufwändig genug ist. Im Underlay bedeutet das aber unter Umständen die Unterstützung von Multicasts mit allen unangenehmen Begleitumständen wie Multicast-Routing etc.

Um dies zu vermeiden, setzen moderne Overlay-Lösungen auf eine übergeordnete Control Plane, die Netzwerkadressen und Erreichbarkeitsinformationen unter allen beteiligten Systemen austauscht. Dieses „Control Plane Learning“ hat außerdem den Vorteil, dass man besser kontrollieren kann, wer welche Adressen lernt, und den Prozess über geeignete Policies steuern kann, was gerade in mandantenfähigen Umgebungen wichtig ist.

Falls die Lösung zu angebundenen Endgeräten sowohl MAC- als auch IP-Adressen verwaltet, können darüber hinaus die Edge-Devices ARP-Anfragen zu entfernten System lokal beantworten (Proxy-ARP).

Am Edge-Port selbst werden die angebundenen Netze und deren Adresse natürlich weiterhin ganz klassisch gelernt:

  • über eingehende Frame (Data Plane),
  • über IEEE 802.1X („Port Based Network Access Control“),
  • via LLDP (Link Layer Discovery Protocol),
  • über manuell konfigurierte Einträge (Management Plane),
  • sonstige Protokolle.

Diese übergeordnete Control Plane kann entweder als zentraler SDN-Controller oder als verteilte Steuerebene (Distributed Control Plane) umgesetzt werden. Im ersten Fall werden wie bei dem Overflow-Modell alle relevanten Informationen an einer zentralen Instanz zusammengezogen und entweder proaktiv oder auf Anfrage den Tunnelendpunkten mitgeteilt. Beispiele für diesen zentralen Ansatz sind VMware NSX und Cisco ACI, aber auch MPLS-Netze nutzen in der Regel zentrale Instanzen, um Pfaddefinitionen zu verteilen.

Im zweiten Fall wird ein Control-Protokoll genutzt, um die Informationen an alle Endpunkte zu verteilen. Hierbei ist es wichtig sicherzustellen, dass alle Weiterleitungssysteme denselben Informationsstand haben. Typischerweise wird hierbei auf eines der etablierten Routing-Protokolle gesetzt, deren Aufgabe es ja klassischerweise ist, Routing-Informationen in einer Routing-Domäne zu verteilen und für eine gemeinsame Datenbasis zu sorgen.

Da die Steuerungsschicht in Overlay-Lösungen, die Layer-2-VPNs zur Verfügung stellen (was ja gerade in Unternehmens- bzw. Rechenzentrumsnetzen notwendig und gewünscht ist), aber mehr Informationen braucht als „einfache“ Layer-3-Routing-Informationen (z. B. die MAC-Adressen von Endsystemen), sind diese Routing-Protokolle verfahrensspezifisch erweitert. Wir werden weiter unten auf zwei Beispiele genauer eingehen.

Weitere Funktionen, die je nach Verfahren von der Steuerungsschicht der Edge-Devices wahrgenommen werden, sind:

  • lokales Bridging,
  • lokales Routing,
  • Integration des Underlay zur Wegewahl durch das Transportnetz

Im Folgenden werden zwei Beispiele von verbreiteten Overlay-Lösungen und deren Control Plane im Überblick vorgestellt: BGP-EVPN und SPB.

EVPN

EVPN (Ethernet VPN) wurde standardisiert von der mittlerweile geschlossenen IETF Working Group L2VPN (Layer 2 Virtual Private Networks). Ziel dieser Arbeitsgruppe war die Entwicklung von Lösungen, die Layer-2-Verbindungen über Providernetze ermöglichen. Untergeordnet wurde auch untersucht, welche Anforderungen Cloud-Lösungen und große Rechenzentren an diese Protokolle haben.

Dabei stand von Anfang an die klare Trennung zwischen Overlay und Underlay fest. L2VPN-Lösungen sollten keine Kontrolle über das Underlay haben, falls nötig, sollen existieren QoS-Mechanismen oder Funktionen zur Wegewahl des Underlay genutzt werden.

EVPN selbst ist im RFC 7432 „BGP MPLS-Based Ethernet VPN“ definiert, Ziel ist alle Servicetypen wie E-LAN, E-LINE, E-TREE, L3-VPN und RZ- und Cloud-Kopplungen durch eine einheitliche Technologie betreiben zu können. (siehe Bild 9)

In dem Dokument wird ein Verfahren beschrieben, um Ethernet-basierende Services über MPLS zu verbinden – also eine Alternative zu den „klassischen“ MPLS L2VPNs wie VPLS (Virtual Private LAN Service). Adressiert werden insbesondere:

  • Multihoming und Redundanz (und zwar sowohl active-passive Anbindungen als auch active-active),
  • Optimierungen für Multicasts,
  • einfache Provisionierung (Auto-Discovery),
  • flowbasierendes Load-Balancing und
  • Multipathing.

Die beschriebenen Mechanismen beziehen sich jedoch ausnahmslos auf die Control Plane in den Edge-Devices. Das Dokument betont daher auch explizit, dass EVPN nicht auf MPLS-Transportnetze beschränkt ist, sondern auch mit IP-basierenden Transportprotokollen umgesetzt werden kann – also beispielsweise mit VXLAN (VXLAN BGP EVPN). Solche Implementierungen gibt es von einer ganzen Reihe von Herstellern (Cisco, Juniper, Brocade u. a.).

Darüber hinaus gibt es auch Implementierungen, die PBB als Encapsulation-Protokoll und darüber MPLS als Transportprotokoll nutzen („MPLS PBB-EVPN“). Hierbei werden im Edge die Funktionen einer PBB-Edge-Bridge und eines EVPN-Edge-Devices kombiniert: Angebundenen Segmenten wird eine Service-ID (I-SID) für PBB zugeordnet (Cisco nennt das auch „PBB Bridge Domain“) und jeweils einer oder mehreren dieser Bridge Domains wird eine EVPN-ID zugeordnet, die ihrerseits mit einem MPLS-Label verbunden ist, um die so verpackten Frames über das MPLS-Netz zu transportieren. Der Vorteil dieser vorgeschalteten PBB-Encapsulation ist im Wesentlichen die weitere Reduzierung der Größe der MAC-Tabellen.

Kernpunkte von EVPN sind:

  • Es werden virtuelle Ethernet-Services über Layer 3 (MPLS oder IP) bereitgestellt. Das heißt, die Edge-Devices verbinden Layer-2-Segmente über Layer-3-Tunnel transparent miteinander.
  • Das Verfahren ist mandantenfähig, das heißt, das genutzte Tunnelprotokoll muss eine Tunnel-, Service- oder Kunden-ID transportieren.
  • BGP wird als Control-Protokoll zum Austausch von Netzwerkadressen und Erreichbarkeitsinformationen genutzt.
  • MAC-Learning von entfernten Segmenten erfolgt nicht über die Data Plane, sondern über die Control Plane, also BGP.

Damit diese Anforderungen von BGP unterstützt werden können, sind einige Erweiterungen zur ursprünglichen Standardisierung nötig. Die wichtigste ist MP-BGP (Multiprotocol Border Gateway Protocol, standardisiert in RFC 4760 „Multiprotocol Extensions for BGP-4“), da BGP klassischerweise nur für IPv4 definiert ist. Mit Multiprotocol-BGP werden sogenannte „Address Family Identifier“ eingeführt, um unterschiedliche Netzwerkadresstypen wie IPv4, IPv6, MAC, Frame Relay, L2VPN, MPLS etc. pp kennzeichnen zu können. Somit können mit MP-BGP Netzwerk-Routen für völlig unterschiedliche Adresstypen verteilt werden.

Gleichwohl braucht weiterhin jeder BGP-Router, genauer jedes System, das BGP spricht, eine IPv4-Adresse! (siehe Bild 10)

Für EVPN wurde eine neue, eigene „Address Family“ definiert, mit der fünf verschiedene Routen kodiert werden können:

  • Ethernet Auto-Discovery (A-D) route um schnellere Konvergenz im Fehlerfall und Load Balancing zu unterstützen
  • MAC/IP Advertisement route für Unicast MAC-Adressen und Zuordnung der Tunnel-ID (oder MPLS-Label) optional können zusätzlich eine oder mehrere IP-Adressen des Endgeräts übermittelt werden, womit am lokalen Edge ARP-Requests beantwortet werden können (Proxy ARP)
  • Inclusive Multicast Ethernet Tag route für Multicast-Unterstützung, inklusive Broadcast und Unknown Unicasts
  • Ethernet Segment route zur Unterstützung von Multihoming und Auto-Discovery von mehrfach angebundenen Ethernet-Segmenten, sowie zur Wahl des Designated Forwarders
  • IP Prefix route zur Integration von Layer-3-Routing

Das hierauf aufbauende Verfahren zur Weiterleitung von Frames ist dem von IP-VPNs (wie im RFC 4364 „BGP/MPLS IP Virtual Private Networks (VPNs)“) sehr ähnlich:

  • Jedem Kundensegment wird eine eigene Weiterleitungstabelle, jetzt jedoch für Layer-2-Adressen, (MAC-VRF – Virtual Routing and Forwarding Table for MAC Addresses) zugeordnet.
  • Routen zu diesen Segmenten werden über einen „Route Distinguisher“ eindeutig gemacht. Somit erreicht man einerseits, dass gleiche IP-Adressen in verschiedenen VPNs genutzt werden können, und andererseits können unterschiedliche Routen zum selben physischen Segment (oder Endgerät) unterstützt werden (Multihoming).
  • Edge-Devices, die an dasselbe zusammenhängende Ethernet-Segment angebunden sind, wählen einen „Designated Forwarder“, der für Broadcasts, Multicasts und Unknown Unicasts zuständig ist.
    Ergänzend zu diesem standardmäßigen „intra-subnet forwarding“ auf Layer 2, behandelt EVPN auch „inter-subnet forwarding“, also die Weiterleitung von Frames über Subnetzgrenzen hinweg und wo infolge dessen IP-Routing erfolgen muss.

Traditionell wird hierfür der Verkehr über ein zentrales Layer-3-Gateway (Default Gateway) geführt. Das bedeutet aber eben, dass die Kommunikation zwischen zwei virtuellen Maschinen, die beispielsweise auf demselben Host laufen, erst den Host verlassen muss, gegebenenfalls quer durch das Rechenzentrum zum Gateway geführt, dort geroutet und dann zum Host zurückgeführt wird. Gerade in großen Umgebungen ist das sehr ineffektiv.

Um dieses „hair pinning“ zu vermeiden, soll daher das Routing zwischen Systemen, die hinter demselben Tunnelendpunkt liegen, lokal erfolgen, also ohne dass der Verkehr verpackt wird und den Tunnel überhaupt erreicht. Das heißt, jedes Edge-System wird zum Default-Gateway für die angebundenen Subnetze und hat eine Schnittstelle in alle anderen angebundenen Subnetze. Diese Schnittstellen spielen dann ihrerseits Default Gateway für jede Netze.

Da die IP-Adressen von Default-Gateways innerhalb eines Subnetzes eindeutig sind, müssen diese IP-Adressen als IP-Anycast-Adressen allen Edge-Systemen zugewiesen werden, wo ein entsprechendes Segment angebunden ist. Ob zusätzlich auch einheitlich MAC-Anycast-Adressen genutzt werden, ist je nach Implementation unterschiedlich. Einheitliche MAC-Anycasts haben jedenfalls den Vorteil, dass im Netz keine Routen zu den MAC-Adressen der Default Gateways verteilt werden müssen – die Edge-Systeme agieren an dieser Stelle völlig autark voneinander.

Der IETF Entwurf „Integrated Routing and Bridging in EVPN“ (draft-ietf-bess-evpn-inter-subnet-forwarding – letzte Version 3 vom 8.2.17) schlägt ergänzend vor, optional auf allen Edges Schnittstellen für alle möglichen EVPN-Overlays bereitzustellen (siehe Bild 3). In diesem Szenario würde dann jeglicher subnetzübergreifende Verkehr direkt am Ingress-Edge in das Zielnetz geroutet und dann erst über die Tunnel zum jeweiligen Tunnelendpunkt geleitet.(siehe Bild 11)

Das Konzept sieht es dabei durchaus vor, dass beide Verfahren, zentrales Gateway und verteiltes Gateway, nebeneinander genutzt werden können. Beispielsweise könnte Verkehr, der zum selben Kunden oder zur selben Sicherheitszone gehört, lokal geroutet werden, während Verkehr, der die Grenzen von Kundennetzen oder Sicherheitszonen überquert, extern über eine dedizierte Firewall geführt wird.

Shortest Path Bridging

Shortest Path Bridging (SPB) ist von der IEEE in der Erweiterung 802.1aq zum VLAN-Standard 802.1Q standardisiert. Die Ziele dieses Standards sind:

  • Berechnung kostengünstiger Wege für Unicasts und Multicasts,
  • Überwindung der Beschränkung auf nur einen einzigen Spanning Tree pro VLAN,
  • Steigerung der Bandbreite und Senkung der Laufzeiten im Netzwerk,
  • bessere Ausnutzung aller Netzwerk-Ressourcen und Ermöglichung von Lastausgleich über kostengleiche Wege.

Basis des Verfahrens ist IS-IS. IS-IS steht für „Intermediate System to Intermediate System Protocol” und ist von der ISO als Routingprotokoll für OSI-Systeme standardisiert (ISO 10589). IS-IS wurde ausgewählt, weil das Protokoll einige interessante Eigenschaften mit sich bringt:

  • IS-IS ist als OSI-Protokoll unabhängig von einem speziellen Adressformat. Es werden also beispielsweise keine IP-Adressen benötigt wie etwa bei OSPF, sondern es läuft auch direkt auf Layer 2.
  • IS-IS ist ein „Link State“-Protokoll (wie auch OSPF). Link-State-Protokolle konvergieren üblicherweise sehr schnell, sie sind weniger anfällig gegen Routing-Loops und unterstützen größere Netze.
  • IS-IS kann ohne Konfiguration (sogenannte „Zero Configuration“) betrieben werden.
  • IS-IS verwendet eine TLV-Kodierung (Type, Length, Value); dies vereinfacht die Definition und den Transport von neuen Arten von Daten.

Letzteres wurde dann auch von der IEEE genutzt, um einige neue, SPB-spezifische TLVs zu definieren.

Auf dieser Control Plane setzen zwei verschiedene Tunnelverfahren auf:

  • SPBV: Shortest Path Bridging VID (VLAN-ID) Mode und
  • SPBM: Shortest Path Bridging MAC Mode.

SPBV nutzt das in IEEE 802.1ad spezifizierte Q-in-Q-Verfahren „Provider Bridges“, während SPBM das in IEEE 802.1ah spezifizierte MAC-in-MAC-Verfahren „Provider Backbone Bridges (PBB)“ einsetzt (Frameformat siehe Bild 6).

SPBV hat praktisch keine Marktrelevanz, einzig SPBM ist in einer Implementierung der Firma Avaya (mittlerweile/demnächst Extreme) in nennenswerten Umfang installiert.

Vergleich EVPN und SPBM

Mit beiden Verfahren werden moderne Overlay-Lösungen gesteuert, die Layer-2-Services zur Verfügung stellen, und damit gibt es auf den ersten Blick eine ganze Reihe von Gemeinsamkeiten:

  • Die IP- und MAC-Adressräume unterschiedlicher Kunden bzw. Services werden vollständig voneinander und vom Transportnetz getrennt. Damit werden überlappende Adressräume zwischen Kunden unterstützt.
  • Es gibt nur ein sehr reduziertes MAC-Learning auf der Data Plane, nämlich beim Lernen von Adressen aus lokal angebundenen Layer-2-Segmenten. Alle MAC-Adressen aus entfernten Segmenten und alle MAC-Adressen der Tunnelendpunkte werden über die Control Plane gelernt. (Bei SPB außerdem die Adressen aller anderen Transportswitches ebenfalls.)
  • Neue Endpunkte von Servicenetzen werden automatisch erkannt und über die Control Plane verteilt.
  • Shortpathing und Multipathing werden von beiden Verfahren unterstützt.

Nichtsdestotrotz unterscheiden sich die Verfahren gewaltig, der wesentlichste Unterschied ist, dass SPBM im Gegensatz zu EVPN auf ein Layer-2-basierendes Underlay setzt. Hieraus leiten sich insbesondere für die Administration und das Operating solcher Netze wichtige Funktionsunterschiede ab:

1. Adressvergabe
Layer 2 ist per se selbstkonfigurierend, da keine Layer-2-Adressen manuell oder automatisiert vergeben werden müssen.

Für ein Layer-3-Design, wie es EVPN BGP erwartet, müssen dagegen an alle Tunnel-
endpunkte und alle Routingschnittstellen einzeln IP-Adressen vergeben werden. Dies wird in der Regel manuell erfolgen und ist mit entsprechendem Aufwand verbunden. Eine automatisierte Vergabe erfordert zusätzliche Tools und Schnittstellen, die zum einen die Komplexität der Lösung erhöhen und zum anderen ebenfalls konfiguriert werden müssen.

So oder so müssen außerdem im Vorfeld geeignete IP-Adresspläne entwickelt werden.

Hierzu ein kurzes Rechenbeispiel:

In einem mittleren Spine-Leaf-Design mit 2 Spines mit 30 Leafs benötigt man:

  • 32 IP-Adressen für die Systeme selbst (Loopback Interfaces)
  • 30 IP-Adressen für die Tunnelendpunkte auf den Leaf-Switches
  • 2 Spines * 30 Leafs = 60 Punkt-zu-Punkt-Verbindungen * 2 für /31-Netze ergibt 120 IP-Adressen
  • In Summe also 182 IP-Adressen, sinnvollerweise verteilt auf drei Adressgruppen.

2. Netzwerkerweiterung
SPB ist vom Konzept her eine Erweiterung des STP (Spanning Tree Protocol) und nutzt daher ebenfalls MAC-Multicasts (so genannte BPDUs – Bridge Protocol Data Units) zur Kommunikation mit den direkten Nachbarn. Das bedeutet, dass sich SPBM-Switches automatisch finden und eine SPBM-Fabric ohne Konfiguration erweitert werden kann. Einziger Nachteil: Eine SPB-Area muss immer zusammenhängend aufgebaut werden, jeder Switch, der kein SPB unterstützt, begrenzt der Area.

Die Nachbarschaftsbeziehungen von BGP laufen dagegen prinzipiell immer über TCP und müssen daher konfiguriert werden, bevor irgendeine BGP-Kommunikation beginnen kann. Es gibt einige erste Produkte (z. B. von Extreme), bei denen sich direkt benachbarte Layer-3-Switches über LLDP (Link Layer Discovery Protocol) finden und so auch für BGP-basierende Designs eine Art Auto-Discovery realisieren.

3. Netzwerktopologie
Eines der wichtigsten Ziele bei der Entwicklung von SPB war es, die Einschränkungen des Spanning Trees zu überwinden. Daher ist SPB vom Design her dazu prädestiniert, beliebige Topologien vom Ring bis zur Vollvermaschung zu unterstützen. SPB-Fabrics können ohne Rücksichtnahme auf irgendwelche Designvorschriften nach Bedarf aufgebaut und erweitert werden.

BGP setzt per Design auf Punkt-zu-Punkt-Verbindungen, wobei iBGP eine Vollvermaschung aller Router eines autonomen Systems voraussetzt, was in der Regel durch den Einsatz von Route Reflectors umgangen wird. Die Topologie einer hoch performanten BGP-Fabric mit redundanter Mehrwege-Ausbreitung ist somit alles andere als trivial, Spine-Leaf-Topologien sind hierfür noch am besten geeignet. Von den meisten Herstellern gibt es daher sehr detaillierte Leitfäden zum Aufbau von EVPN-basierenden Fabrics mit sehr wenig Spielraum für individuelle Sonderwünsche.

4. Skalierbarkeit
Das Underlay einer SPB-Lösung ist ein flaches Layer-2-Netz. Auch wenn in dieser gemeinsamen Broadcast-Area praktisch keine Broadcasts verwendet werden, beschränkt dies natürlich die Skalierbarkeit von SPBM deutlich. Hinzukommt, dass auch das Control-Protokoll IS-IS in einer einzigen Area läuft, was bedeutet, dass alle Switches die gleiche Topologie-Datenbank verwalten. Den Aufbau einer hierarchischen Lösung lässt SPB nicht zu. Damit ist eine SPB-Area realistischer Weise auf wenige Hundert Switches beschränkt.

Wie erwähnt, setzen die meisten EVPN-Designs auf eine Spine-Leaf-Topologie. Spine-Leaf wird gerne als Wundermittel für hoch skalierbare Netze verkauft, aber gerade eine reinrassige Spine-Leaf-Topologie hat klare Skalierungsgrenzen dort, wo alle Ports an den Spines belegt sind. Der entscheidende Vorteil von EVPN liegt darin, mit BGP klassische hierarchische Clos-Architekturen aufbauen zu können.

Zusammenfassung
Braucht ein Unternehmensnetz zwingend Overlays?

Kurz gesagt: Ja. Overlays sind das Mittel der Wahl, um skalierbare Netze zu bauen. Das ist nicht neu, mit VLANs machen wir das schon seit Jahrzehnten, aber VLANs und daraus aufbauende Netze unterliegen einer Reihe von Einschränkungen, die in modernen Netzen nicht länger tolerierbar sind:

  • Gut 4.000 VLAN-IDs sind in vielen Umgebungen zu wenig.
  • Die Virtualisierung und Automatisierung im RZ erfordert das Verschieben virtueller Maschinen über Layer-3-Grenzen hinweg (MAC Mobility).
  • Der Spanning Tree als Mittel zur Schleifenunterdrückung ist indiskutabel.

Gleichzeitig kommen gerade im Rechenzentrum weitere Anforderungen nach Flexibilität und Automatisierung hinzu. Damit kommt insbesondere der Control Plane einer Overlay-Lösung große Bedeutung zu.

Wir haben in diesem Artikel zwei Overlay-Lösungen verglichen, deren Control Plane noch ganz klassisch im Netzwerk, verteilt auf alle teilnehmenden Netzwerkkomponenten liegt und die gleichzeitig stellvertretend für die beiden Basistechnologien Ethernet und IP im physischen Underlay sind.

Die Unterschiede sind erwartungsgemäß so groß, dass eine Entscheidung zwischen beiden Modellen nicht schwerfällt:

SPBM basiert auf Layer 2 und konfiguriert sich damit praktisch von alleine. Es werden beliebige Topologien unterstützt, solange die Fabric zusammenhängend bleibt, was die Lösung insbesondere auch für den Campus und die Access-Bereich interessant macht. Multicast-Support ist quasi eingebaut. Einzig die Zuordnung zu den virtuellen Netzen am Edge muss konfiguriert werden.

Der Wermuttropfen von SPBM liegt in der Skalierbarkeit, für wirklich große Netze ist die Lösung nicht geeignet.

Und genau hier liegt die Stärke von BGP-EVPN: Durch die Möglichkeit hierarchische Netzstrukturen zu bauen und einer Vielzahl weiterer Konfigurationsparameter kann man sehr präzise steuern, wer wie viele Routen verwaltet muss, und erreicht so deutlich größere Netze bis hin zu Hyperscalern wie Facebook, Microsoft und Co.

Von einem Zero-Touch-Provisioning oder One-Stop-Provisioning sind wir hierbei jedoch meilenweit entfernt. EVPN ist letztlich eben doch Provider-Technologie. Oder wie sehen Sie das? Ich freue mich auf Ihre Rückmeldungen.

Im nächsten Teil werden wir uns mit der Frage beschäftigen, welche Auswirkungen die Wahl eines bestimmten Overlay-Protokolls (wie beispielsweise VXLAN) oder einer bestimmten Control Plane (wie beispielsweise EVPN) eigentlich auf das Underlay hat.

zugeordnete Kategorien: Archiv, Klassiker
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.