KOMPAKTER EINBLICK IN DIE VOR- UND NACHTEILE
EINER VxLAN LÖSUNG

Fabricpath, VxLAN, NVGRE, LISP, OTV, MPLS sind Begriffe, die aktuell in einem Atemzug genannt werden, wenn es um Datenkommunikation innerhalb oder zwischen Rechenzentren geht. Dabei kommt es mitunter zu einer inhaltlichen Vermischung der Technologien, die an sich Lösungen für verschiedene Anforderungen/Problemstellungen bieten.

Was die genannten Abkürzungen gemein haben: Es handelt sich um sogenannte Overlay Technologien.

Datacenter Overlay in einem Satz:
Die Übertragung von Daten auf Layer 2 Ebene über virtuelle Tunnel, die über ein darunter liegendes Layer 2 oder Layer 3 Netzwerk gespannt sind.“

Was sie im groben Sinn unterscheidet ist die Tatsache, dass die einen für eine optimierte Kommunikation innerhalb eines Rechenzentrums entwickelt wurden, die anderen für die komplexen Anforderungen in der Kommunikation zwischen Rechenzentren (DCI – Datacetner Interconnect genannt).

An der Geschichte von MPLS sieht man sehr schön, wie sehr sich die Einsatzgebiete dieser Overlay Technologien wandeln und erweitern können. Dies liegt nicht zuletzt an der hohen Flexibilität im Einsatz dieser hoch virtualisierten Netzwerk Technologien.

VxLAN unterliegt derzeit ähnlich zur MPLS Historie sehr interessanten Entwicklungen, die bereits heute für Einsatzgebiete weit jenseits der von Fabricpath sorgen. Dieser Artikel geht auf diese Entwicklungen und den sich daraus ergebenden Möglichkeiten, sowie Vor- und Nachteilen, die daraus entstehen können, ein.

 

ZU BEGINN EIN PAAR GRUNDLAGEN

Ein Overlay Netzwerk wie VxLAN lässt sich natürlich nicht in ein paar Worte fassen. Für einen Vergleich und die Erläuterung der essentiellen Unterschiede zu bekannten traditionellen Lösungen im Rechenzentrum sind ein paar grundlegende Begriffe und Funktionen jedoch ausreichend.

Bei VxLAN terminiert ein sogenannter VTEP (Virtual Tunnel Endpoint) Tunnel Verbindungen zu anderen gleichwertigen VTEP in einem Rechenzentrum. Jeder VTEP hat grundsätzlich 2 Interfaces, eines für die lokale Switching Funktion zu VLAN Segmenten (funktioniert nach traditionellen Gesichtspunkten), das andere Interface zur globalen Core VxLAN De- und Enkapsulation. VTEP unterstützen übrigens auch Virtual Port Channel Anbindungen in der aktuellen Version.

Das „Underlay“ Netzwerk, also das logisch darunter strukturierte Netzwerk zur Übertragung der Overlay Tunnel im Core, ist über ein Layer 3 Routed Netzwerk realisiert (prinzipiell mit beliebigem Routing Protokoll für den Austausch von VTEP Tunnel Endpunkt Adressen). Equal Cost Multipathing ist ebenfalls zentraler Bestandteil in diesem „Underlay“ Routing und sorgt für eine gleichmäßige Auslastung aller verfügbaren Links.

Grundsätzlich sind verschiedene Underlay Netzwerk Topologien umsetzbar, meist wird in Hinblick auf die Skalierung ein „Leaf/Spine“ Setup empfohlen.

Dabei sind alle einzelnen Links über IP Linknetze oder L3 Port-Channels realisiert, anstatt von VLAN Trunks und L2 Channels wie in traditionellen Layer 2 Netzwerken. Jeder Leaf Switch fungiert dabei als VTEP und terminiert über das darunter liegende Layer 3 Netzwerk die VxLAN Tunnel. Die VTEP leiten letztlich den „LAN seitig“ terminierten VLAN Traffic an ihre lokal terminierten VxLAN Tunnel weiter, um Ziele auf anderen VTEP erreichen zu können.

Ein VxLAN enkapsuliertes IP Paket enthält ein Protokoll Feld für einen s.g. VNI – VxLAN Network Identifier (24 bit). Dieser Identifier entspricht einem VxLAN Segment. Dieser VNI kann analog zu einem VLAN Segment für den VxLAN Core gesehen werden. Am VTEP passiert ebenfalls das VLAN zu VNI Mapping.

Das Routing zwischen VNI Segmenten (analog zum VLAN Routing) kann zentral oder über dezentrale Anycast Gateways passieren.

 

VORTEILE VON VXLAN IN STICHWORTEN

  • Offizieller IETF Standard (https://tools.ietf.org/html/rfc7348) von Cisco, vmware u.v.a. entwickelt
  • „On Demand“ Segmentierung mit sehr hoher Skalierung und Multi Tenancy
  • IP Routing als Grundlage, sehr stabil und skalierbar
  • Ermöglicht flexibles VM Deployment überall im Datacenter
  • Distributed Anycast Gateway sorgt für optimales Gateway Routing
  • VXLAN funktioniert über bestehendes Datacenter Equipment (Transport)
  • Brauchbar als Datacenter Interconnect? – Mehr dazu im letzten Kapitel …

 

WARUM VXLAN?

– MAC Address Tables im Rechenzentrum

Ein Hauptargument ist die Skalierung im Datacenter durch die steigenden Anforderungen der Server Virtualisierung. VxLAN segmentiert auf „Top Of The Rack“ Ebene und kann das MAC Learning auf ein Routing Protokoll (MP-BGP) „auslagern“. Tatsächlich steigen die verwendeten MAC Adressen pro Layer 2 Segment drastisch an, seit es VNICs in der Server Virtualisierung gibt. Hat ein physischer Server mit 2 Netzwerk Schnittstellen z.B. 2 MAC Adressen, so haben virtuelle Server mit 16 CPU Cores und > 100GB Memory bis zu 70 MAC Adressen durch die virtualisierten VNICs. Die Konsolidierte Hardware sorgt für inflationäre Verwendung von Server Resourcen und somit MAC Adressen.

Man kann sich vorstellen, dass sich dieser Trend beispielsweise durch „Containerisierung“ von Applikationen stark fortsetzen wird.

MAC in IP Enkapsulierung – Routing statt Spanning Tree

Bedeutender sind die Vorteile, die sich aus der IP Enkapsulierung des Protokolls ergeben. Hier zeigt sich auch das eindeutige Unterscheidungsmerkmal zu Fabricpath. Das setzt auf Layer 2 in Layer 2 (MAC in MAC), während VxLAN Layer 2 Frames in IP Pakete enkapsuliert. Dadurch kann das darunter liegende „Underlay“ Netzwerk als geroutetes Layer 3 Netzwerk aufgebaut werden, was maximale Segmentierung und damit höchste Stabilität und Flexibilität garantieren kann. Die Layer 3 Enkapsulierung ermöglicht außerdem das Forwarding von Datacenter Layer 2 Frames über Router Grenzen hinweg.

4000 VLANs reichen nicht aus?

Ein weiteres Argument ist das traditionelle VLAN Limit von 4000 Vlans und fehlendes „Multi Tenancy“ für ein Rechenzentrum. Für sehr große Netzwerke und Service Provider durchaus ein Thema, in Österreich treffen wir realistisch gesehen wohl eher selten an diese Limits. VxLAN unterstützt grundsätzlich bis zu 16 Millionen Layer 2 Segmente (24 bit VNI Adressierung im Protokoll), womit sich jedenfalls sehr flexible Möglichkeiten der Segmentierung von Services ergeben. Multi Tenancy ist primär für Service Provider interessant, aber vielleicht auch für Unternehmen, die Services im Rechenzentrum von einander isolieren wollen. Weniger bekannt ist, dass Nexus Switches auch ein internes VLAN Limit über alle verfügbaren Trunk Ports gerechnet haben. Jedoch auch diese Limits werden in Österreich aktuell wohl kaum erreicht.

 

Statisches Trunk Pruning vs. dynamischem VM Movement

In allen korrekt konfigurierten Rechenzentren wird in Richtung Server statisches Trunk VLAN Pruning betrieben. Alleine aus Gründen der Stabilität sollen auf einem Server Trunk Port nicht alle VLANs erlaubt sein. Diese Konfiguration ist aktuell statisch und damit fehleranfällig. Außerdem wird dadurch die VM Mobilität eingeschränkt oder ebenfalls Fehleranfällig. VxLAN schafft hier Abhilfe, da Multicast IGMP für ein automatisches Pruning eingesetzt werden kann.

 

Ist VxLAN „gut genug“ für eine Datacenter Interconnect Lösung?

Kurz gesagt „ja“, in aktueller Entwicklungsphase von VxLAN mit MP-BGP EVPN. Durch das nunmehr sehr stark reduziertes Flooding Verhalten über die VxLAN Control Plane zusammen mit dem Anycast Gateway Feature nähert man sich deutlich einer optimalen DCI Lösung an. Die Evolution beschreibt diese Annäherung in folgendem Kapitel.

DIE EVOLUTION VON VXLAN ZUR AKTUELLEN BGP-EVPN LÖSUNG

Der aktuell umgesetzte Entwicklungsstand von VxLAN entspricht einer eigenen Control Plane, basierend auf MP-BGP Routing, die für die dynamische Erfassung und Distribution von VTEPs und angeschlossenen Endsystem zuständig ist. Diese Erweiterung verringert Unicast Flooding innerhalb der Fabric signifikant und ist seit einiger Zeit auf der Cisco Nexus 9000 Platform in der Form verfügbar und in aktuellsten Versionen unter anderem auch auf Nexus 5600.

Folgend sie die einzelnen Entwicklungsphasen von VxLAN erläutert, um die Fortschritte der Lösung aufzuzeigen und einen Blick in die Zukunft geben zu können.

 

Phase 1 – „Multicast Transport Mode“

Zu beginn unterschied sich VxLAN von Fabricpath eigentlich nur von der Art des Overlays. VxLAN nutzt eine Layer 2 in Layer 3 Enkapsulierung, während Fabricpath Layer 2 in Layer 2 enkapsuliert. Fabricpath setzt generell auf das ISIS Routing Protokoll für eine Loop freie Auflösung von Pfaden. VxLAN nutzt hier ein prinzipiell frei wählbares Routing Protokoll vom Underlay Netzwerk (durch die IP Enkapsulierung).

VxLAN setzte in dieser frühen Phase auf ein reines Multicast „Flood and Learn“-Konzept ohne Control Plane. Damit werden Daten mit unbekannter MAC Adresse initial am VxLAN Netzwerk geflutet (ARP, Multicast, Unknown Unicast Traffic), bis die Zielsysteme die MAC Adressen lernen können. In dieser Phase können ob der fehlenden Control Plane auch keine anderen VTEP Switches in der VxLAN Fabric erkannt werden.

Es zeigt sich eine große Ähnlichkeit zu Fabricpath in dieser ersten Phase von VxLAN, denn beide basieren auf „Conversational MAC Learning“, die MAC Adresse wird wie bei einem traditionellem Layer 2 Netzwerk erst über empfangene Layer 2 Pakete selbst gelernt. Diese Art der Kommunikation sorgt letztlich für einen hohen Anteil von ungerichteten, gefluteten Paketen in einem Broadcast Segment.

 

Phase 2 – „Unicast Only Transport Mode“

In dieser Phase wurde die sogenannte Head End Replication (HER) in VxLAN eingeführt. Hierbei lernt jeder VTEP welche VNI (Virtual Network Identifier – oder VxLAN Segment ID) auf anderen VTEP zur Verfügung stehen. Diese Information wird von jedem VTEP über eine Control Plane (über iBGP/Route Reflectors) übertragen. Damit erhält jeder VTEP in der Fabric eine Liste aller anderen VTEP. Mit dieser Liste ist es nun möglich Broadcast (+ Multicast, Unknown Unicast) in Form von Unicast Paketen nur an die betreffenden VTEP mit entsprechenden VNI zu senden.

Der Name „Unicast Only Transport Mode“ ist trügerisch, denn auch hier ist wie in Phase 1 der „Flood and Learn“ Prozess für Multicast, Unknown Unicast und ARP Requests im Einsatz. Über die Control Plane wird ebenfalls keine End Host Informationen übertragen, sondern nur VTEP Tunnel Endpunkte pro VNI Segment.

 

Phase 3 – Dynamic Host Discovery und Distribution – MP-BGP EVPN

In der aktuellen Entwicklungsphase von VxLAN, wurden sehr wichtige Erweiterungen implementiert.

  • Host/Network Reachability Advertisement
  • VTEP Security und Authentication (via BGP Policies)
  • Distributed Anycast Gateway
  • ARP Supression
  • Dynamic Ingress Replication (Multicast, Unknown Unicast, …)

Zusätzlich zu der VTEP Information aus Phase 2 werden nun von jedem VTEP auch End Host Informationen aufgezeichnet und via Control Plane Protokoll (MP-BGP) an alle anderen VTEP weitergeleitet. Diese Endsystem Information beinhaltet neben VNI, VTEP Information und Layer 2 MAC Adresse auch Layer 3 IP Information, wie in dem entsprechenden IETF Draft beschrieben ist:

Jeder VTEP terminiert lokal seine konfigurierten VLAN Segmente und ist dafür zuständig, diesen VLAN Traffic einem VNI zuzuweisen und entsprechende Tunnel zu anderen VTEP zu terminieren. Eine weitere Aufgabe des VTEP ist das ARP Snooping. Der lokale VTEP antwortet anstelle des Zielsystems auf den ARP Request, mit der Information aus dem eigenen Endhost Table, der dynamisch über die Control Plane gelernt wurde.

Auch fürs Troubleshooting durchaus vorteilhaft, wie umfangreich die über BGP Control Plane übertragene Information in VxLAN ist …

Da nun jeder VTEP im Netzwerk die jeweils lokal erkannten Endsysteme anderer VTEP informiert wird, wird das klassische Flood and Learn Verhalten massiv reduziert. Das Unknown Unicast Flooding existiert nur mehr für „Silent Hosts“, also Systeme die nicht aktiv am Netzwerk kommunizieren (und non IP Protokoll Traffic).

DISTRIBUTED ANYCAST GATEWAY

Die Platzierung von Default Gateways im Rechenzentrum passiert bis heute im allgemeinen zentral auf Core Komponenten. Viele dieser Netzwerke haben diese Gateways bereits auf 4 Core Komponenten konfiguriert (auch über 2 Rechenzentren). Das ist keine optimale Lösung, denn es führt zu suboptimalen Pfaden und kann in bestimmten Situationen auch zu langen Umschaltzeiten führen. Über 2 Standorte verteilt, wird auf der passiven Seite jeglicher Traffic zum zweiten Rechenzentrum zum aktiven Gateway gesendet und eventuell auch wieder retour zum Zielsystem am ursprünglichen Standort.

VxLAN MP-BGP EVPN unterstützt ein Feature namens Anycast Gateway. In diesem Modus ist jeder Leaf Switch (VTEP) in der VxLAN Fabric nicht nur für die Layer 2 VLAN Terminierung zuständig, sondern fungiert auch als Layer 3 Gateway for alle VNI Segmente die an diesem VTEP anliegen.

Damit hat jeder VTEP die gleiche Gateway IP Adresse und kann somit auch lokal zwischen VNI/VLANs Routen. Im Detail stellt sich das System natürlich komplexer dar (z.B. Routing zwischen VNI auf verschiedenen VTEP, oder externes Routing), aber die Vorteile liegen auf der Hand. Durch das lokale Default Gateway am Leaf passiert auch das Routing immer am optimalen Pfad. Wendet man dies nun über eine VxLAN Fabric an, die über zwei Rechenzentren reicht … damit kommen wir zum nächsten Kapitel.

 

FABRICPATH UND VXLAN SIND KEINE DCI PROTOKOLLE …?

Die Einführung der erweiterten Control Plane in das VxLAN MP-BGP EVPN Konzept in Phase 3 wirft natürlich die Frage auf, ob und wie sich diese Entwicklung für DCI – Datacenter Interconnect Lösungen eignet.

Viele Rechenzentren in Österreich sind heute über zwei Standorte via Fabricpath angebunden. Andere über Nexus VPC „Back-to-Back“, also Etherchannel Anbindungen. In beiden Fällen werden Nachteile in Betrieb und Stabilität in Kauf genommen. Im Regelbetrieb, der hoffentlich dem dauerhaften Normalfall entspricht, sind diese Nachteile kaum bemerkbar. Was sind nun diese Nachteile und warum soll man sie unbedingt vermeiden?

  • Lokale Loops auf einzelnen Trunk Ports auf einem Switch erzeugen globale Broadcast Storms, diese legen immer beide Rechenzentren lahm
  • Unicast und Broadcast (ARP) Floods liegen in beiden Rechenzentren an, können somit beide Rechenzentren betreffen und zu globalen Ausfällen führen.
  • Spanning Tree Loops betreffen beide Standorte (im Falle von Fabricpath mit Backdoor Links ist die gesamte Fabric betroffen, da sie als Single Bridge fungiert)
  • Default Gateways sind meist in einem Rechenzentrum aktiv, erzeugt sub-optimales Routing und für lange Umschaltzeiten auf der passiven Seite

Man entfernt sich also deutlich vom eigentlichen Ziel, getrennte Rechenzentren sollen unabhängig voneinander funktionieren und sich möglichst nicht gegenseitig beeinflussen können.

Fabricpath verwendet zwar ein Routing Protokoll, um Loops in redundanten Netzwerken aufzulösen (anstelle von Spanning Tree). Das Layer 2 Learning und Flooding Verhalten ist jedoch gleich zu einem traditionellen Netzwerk basierend auf Spanning Tree.

Lassen wir die angesprochenen Erweiterungen zum Stand von VxLAN MP-BGP EVPN Revue passieren, kommen wir zum Schluss:

VxLAN ist im Gegensatz zu Fabricpath „gut genug“ für eine DCI Variante.

Unterstrichen wird diese Einschätzung durch vermutlich 95% aller DCI Lösungen, die derzeit in Österreich über zwei Standorte in Betrieb sind und dem traditionellen „Flood and Learn“ Verhalten ausgesetzt sind.

WAS FUNKTIONIERT MIT VXLAN MP-BGP EVPN BESSER?

  • Ein gemeinsames Underlay Netzwerk, IP geroutet sorgt für ein stabiles Grundgerüst
    • Primäres Ziel ist die Verteilung von VTEP Loopback Adressen
    • Routing Table Update Scope kann z.B. über Areas auf ein RZ beschränkt werden
  • Layer 2 Traffic (VLAN Segment) wird „Top Of The Rack“ am VTEP terminiert
    • Am Eintrittspunkt in die Fabric, sehr kleine Broadcast Domain
    • Durch ARP Supression ebenfalls direkt am VTEP terminiert (ARP snooping)
  • Overlay basiert auf MPLS Bullet Proof BGP Protokoll
    • BGP Route Reflectors können redundant und auf 2 RZ aufgeteilt werden
    • eBGP zwischen RZ möglich
    • Austausch aller Endsystem Informationen (VNI, VTEP, MAC, IP) auf alle VTEP
    • Unvergleichliche Einsicht in den Host Table über BGP show commands
  • BUM (Broadcast, Unknown Unicast, Multicast) Traffic ist um sehr hohen Faktor minimiert
    • Betrifft nur mehr spezielle Situationen wie Silent Hosts
  • Anycast Gateway sorgt für RZ und sogar VTEP lokales Routing direkt am Eintrittspunkt
    • Damit z.B. kein „Hair Pinning“ mehr von Gateway Traffic zwischen RZ, wie bei klassischen Core HSRP Implementationen

WAS WÜRDEN WIR UNS NOCH WÜNSCHEN?

WARUM GILT VXLAN TROTZDEM NOCH NICHT ALS VOLLSTÄNDIGE DCI LÖSUNG?

  • „Backdoor“ Layer2 Links (z.B. VLAN Trunks) über mehrere Devices zwischen Rechenzentren sind nicht möglich. Es gibt keine Loop Prevention über VNI Grenzen hinweg, damit ist dieser Fehlerfall nicht abgedeckt.
    • Als „Workaround“ kann BPDU Guard am Layer 2 Edge eingesetzt werden.
    • Eine integrierte Loop Prevention für Multi Homed Szenarios wäre wünschenswert.
  • Broadcast Storms (ARP Storms u.s.w.) sollten mit Rate Limiter Konfigurationen beeinflussbar sein.
    • Broadcasts können nie gänzlich verhindert werden.
    • Aktuelle VxLAN Phase reduziert Broadcasts „ganz gut“
    • Trotzdem sind Probleme durch Floods nicht zur gänze ausgeschlossen
  • VxLAN lässt sich aktuell über zwei Standorte betreiben
    • Kaum vorzustellen, dass es in absehbarer Zukunft über mehrere Standorte funktionieren können.
    • Einer der entscheidenden Vorteile, die für OTV sprechen.

Ein einfacheres Design für kleinere Rechenzentren könnte folgendermaßen aussehen:

Ja, OTV ist als DCI Technologie noch immer zu bevorzugen wenn es zur Wahl steht. Leider steht dies jedoch immer noch auf den sehr großen Cisco Platformen zur Verfügung. VxLAN startete mit den Serien Nexus 93xx und 95xx. Mittlerweile stehen die viele Features auch auf Nexus 56xx, 7xxx, 77xx, 31xxV zur Verfügung.

 

VXLAN MANAGEMENT

Damit kommen wir letztlich zum Nachteil einer VxLAN Lösung aus heutiger Sicht. Die Konfiguration über die Nexus Command Line ist umständlich, stark verschachtelt und somit behäbig. Administratoren von Rechenzentren sind in den meisten Fällen nicht die, die auch täglich MPLS Konfigurationen betreuen. Damit ergibt sich eine flache Lernkurve und nicht zuletzt höhere Fehleranfälligkeit in der Konfiguration. Letztlich ist vom Kunden selbst zu bewerten, ob sich die angesprochenen Vorteile in Stabilität und Betrieb mit den Nachteilen durch Konfigurationsaufwand und Fehleranfälligkeit gegenübergestellt letztlich lohnt.

Natürlich spielt auch das Thema Migration im Vergleich zu Neu- Installation eine zentrale Rolle. Die Empfehlung ist ein VxLAN Rechenzentrum mit neuen Komponenten aufzubauen und eine definierte Kopplung zu bestehenden Netzwerken durchzuführen. „Brown Field“ Migrationen auf bestehenden Komponenten sind sehr komplex und daher nicht zu empfehlen.

 

NFM – Nexus Fabric Manager

Es gibt auch grafische Management Lösungen, die speziell für VxLAN Netzwerke entwickelt werden. Der NFM ist die passende Lösung für VxLAN Dimensionen, wie sie in Österreich üblicherweise aufgebaut werden. Das User Interface wirkt sehr ausgereift und die meisten der komplexen VTEP Konfigurationen inklusive Anycast Gateway Funktionalität werden dabei automatisch vom NFM im Hintergrund durchgeführt. Das macht das Management einfach, hat allerdings den Nachteil, dass man mit der Software beim Stand Null beginnen muss. Es kann nicht in bestehende VxLAN Konfigurationen eingebunden werden.

Software Rollouts und Monitoring sind in dieser Software ebenfalls abgedeckt und eine API Schnittstelle zur Automatisierung zu anderen Systemen ist ebenfalls Bestandteil der Software.

 

VTS – Virtual Topology System

Hierbei handelt es sich um die „große Overlay“ Lösung. Dabei geht es um permanente Anbindungen über REST API an andere virtualisierungs Lösungen im Rechenzentrum wie Openstack oder vCenter. Die Architektur scheint ähnlich zu einem APIC-EM Controller zu funktionieren. Teilweise sind auch Konfigurationsmöglichkeiten via mitgeliefertem User Interface möglich wie zum Beispiel Topology Views und Anlegen von Tenants.

Für weiterführende Informationen und Fragen zum Thema VxLAN steht ihnen Herwig Gans gerne per Mail zur Verfügung!