Site icon bintorosoft.com

EVPN-MPLS vs. EVPN-VXLAN: Wann welche Wahl in Provider/DC sinnvoll ist

Red Snapper

Das Hauptkeyword „EVPN-MPLS vs. EVPN-VXLAN“ beschreibt eine Designentscheidung, die heute sowohl Provider-Netze als auch moderne Data-Center-Fabrics prägt: Welches Datenebenen-Transportverfahren soll die EVPN-Control-Plane (BGP) bedienen? EVPN (Ethernet VPN) bringt als „L2/L3 Control Plane“ Ordnung in die Welt der Multi-Tenant-Layer-2-Domänen, indem MACs und IPs kontrolliert über BGP verteilt werden, statt sie über Flooding und klassische Spanning-Tree-Mechaniken zu „erraten“. Die Frage ist jedoch, ob die Pakete im Transport über MPLS-Labels oder über VXLAN (UDP-basierte Encapsulation) laufen sollen. Beide Varianten können technisch dasselbe EVPN-Semantikmodell abbilden, unterscheiden sich aber deutlich in Betriebsmodell, Hardware-Anforderungen, MTU-Planung, OAM-Fähigkeiten und in der Art, wie Sie Fehlersuche und Change-Management strukturieren. In der Praxis entscheidet nicht „besser oder schlechter“, sondern „passender für Underlay, Organisation, Telemetrie und Serviceportfolio“. Dieser Artikel ordnet EVPN-MPLS und EVPN-VXLAN entlang typischer Provider/DC-Anforderungen ein, zeigt reale Auswahlkriterien und liefert ein praxistaugliches Entscheidungsraster, das in Produktion belastbar ist.

EVPN als gemeinsames Fundament: Control Plane bleibt gleich, Data Plane nicht

EVPN basiert auf BGP und definiert, wie MAC-Adressen, IP-Informationen und Service-Instanzen (z. B. VLAN/VNI, EVI) zwischen Provider Edges oder Data-Center-Leafs ausgetauscht werden. Kernidee: Statt unkontrolliertem Flooding lernen Endpunkte über signalisierte Routen. Das reduziert BUM-Last (Broadcast, Unknown Unicast, Multicast), verbessert Skalierbarkeit und macht Fehlerbilder deterministischer. Für die Grundlagen ist RFC 7432 (BGP MPLS-Based Ethernet VPN) die zentrale Referenz.

Wichtig ist: EVPN beschreibt primär die Control Plane und den Serviceaufbau. Die Datenebene – also wie Nutzdatenpakete zwischen VTEPs/PEs transportiert werden – kann unterschiedlich sein. Typisch sind zwei große Welten:

EVPN-MPLS: Stärken im Provider-Backbone und in Multi-Domain-Szenarien

EVPN-MPLS spielt seine Vorteile dort aus, wo MPLS ohnehin „natürlicher“ Bestandteil des Netzes ist: in ISP/Telco-Backbones, in Metro-Netzen, in Wholesale-Transport und überall, wo Label-Switching, Traffic Engineering oder bestehende MPLS-OAM-Prozesse gesetzt sind. MPLS als Architektur ist in RFC 3031 beschrieben, das Label-Stack-Encoding in RFC 3032.

Operative Passform: Wenn MPLS bereits das „Betriebssystem“ des Netzes ist

Skalierung und Failure Domains

Provider-Netze sind häufig hierarchisch: Access/Metro/Core, verschiedene Admin-Domänen, verschiedene Vendor-Inseln. EVPN-MPLS kann hier Vorteile bieten, weil MPLS bereits Mechaniken für Skalierung, Segmentierung und kontrollierte Failure Domains mitbringt (z. B. FRR-Strategien, SRLG-Planung, Label-Distribution, Core-Isolation). Das reduziert die Wahrscheinlichkeit, dass ein lokaler Fehler im Access als großflächiges Flooding-Problem im gesamten Netz sichtbar wird.

EVPN-VXLAN: Stärken in modernen Data-Center-Fabrics und Cloud-nahen Designs

EVPN-VXLAN ist heute der De-facto-Standard für L2/L3-Overlay-Fabrics in Data Centern: Leaf-Spine-Topologien, IP-Underlay, viele Tenants, schnelle Skalierung und standardisierte Automatisierung. VXLAN selbst ist in RFC 7348 beschrieben; die Einordnung von EVPN als Control Plane für VXLAN findet sich u. a. in RFC 8365.

Operative Passform: Wenn das Underlay bereits „IP first“ ist

Skalierung in vielen kleinen Segmenten

VXLAN nutzt VNIs statt VLANs und skaliert damit deutlich über klassische L2-Domänen hinaus. In der Praxis ist nicht „VNI-Anzahl“ die harte Grenze, sondern Hardware-Tabellen (MAC/IP, ARP/ND, Route-Scale), Telemetrie- und Policy-Design. EVPN hilft, diese Skalierung kontrollierbarer zu machen, weil MAC/IP-Learning signalisierungsbasiert erfolgt.

Der Kernunterschied in der Datenebene: MPLS-Labels vs. VXLAN-Encapsulation

Die technische Semantik von EVPN ist ähnlich, aber die Kapselung und damit die Auswirkungen auf MTU, Hashing, QoS und Troubleshooting unterscheiden sich deutlich.

MTU und Overhead: VXLAN braucht konsequente Planung

VXLAN kapselt Ethernet über UDP/IP. Dadurch steigt die Paketgröße, was ohne angehobene MTU zu Fragmentierung oder Drops führt. MPLS hat ebenfalls Overhead (Label Stack), ist aber in vielen Provider-Backbones bereits in der MTU-Planung berücksichtigt. Ein vereinfachtes Overhead-Modell kann so dargestellt werden:

MTU_underlay ≥ MTU_payload + Overhead

Für VXLAN ist der Overhead typischerweise „Ethernet + IP + UDP + VXLAN“. Für MPLS ist es „Label Stack“. In der Praxis ist die genaue Zahl weniger wichtig als die Disziplin: VXLAN-Fabrics sollten Underlay-MTU konsequent auf „Jumbo“ setzen (netzweit, nicht nur punktuell), sonst entstehen schwer zu diagnostizierende „Hidden Outages“ (z. B. nur bestimmte Flows oder nur bestimmte VM-Typen betroffen).

ECMP und Hashing

Wenn Ihr Netz stark auf ECMP-Lastverteilung angewiesen ist (typisch im DC), ist VXLAN oft operativ „einfacher“. Wenn Ihr Provider-Netz hingegen deterministische Pfade (TE/SR-Policies) bevorzugt, kann MPLS die bessere Integrationsfläche sein.

OAM und Troubleshooting: Was ist in Produktion schneller nachweisbar?

In Produktionsnetzen zählt nicht nur „es funktioniert“, sondern „ich kann es in Minuten beweisen“. Hier trennen sich die Philosophien oft entlang bestehender Toolchains.

EVPN-MPLS: MPLS-OAM ist häufig etabliert

EVPN-VXLAN: Overlay-Troubleshooting erfordert gute Fabricsicht

In beiden Welten gilt: Ohne standardisierte Telemetrie pro Layer wird EVPN-Fehlersuche schnell „religionsartig“. Mit sauberer Observability (Interface/Queue, BGP EVPN Route Types, MAC/IP-Table Health, Underlay-IGP/BGP Health) wird sie hingegen sehr deterministisch.

Control Plane im Detail: Route Types, MAC/IP Distribution und BUM-Handling

EVPN arbeitet mit definierten Route Types (z. B. MAC/IP Advertisement, Inclusive Multicast Ethernet Tag). Die Control Plane ist in EVPN-MPLS und EVPN-VXLAN konzeptionell ähnlich, die Datenebene für BUM-Traffic (Broadcast/Unknown Unicast/Multicast) unterscheidet sich aber in der Umsetzung.

Replication vs. Multicast: BUM sauber entscheiden

In Data Centern wird häufig Ingress Replication bevorzugt, weil „Multicast im Underlay“ zusätzliche Komplexität bringt. Provider können hingegen Multicast-basiertes BUM-Handling attraktiver finden, wenn sie ohnehin Multicast-Expertise und Tooling besitzen.

QoS, SLA und Performance: Welche Datenebene passt zu welchen Kundenanforderungen?

Provider-Designs werden oft von SLAs getrieben: definierte Latenz, definierter Jitter, definierte Wiederherstellungszeiten und klare Fault Domains. Data Center Designs sind häufig throughput- und scale-getrieben, mit anderen Failure- und Traffic-Profilen.

Wenn TE und deterministische Pfade wichtig sind

EVPN-MPLS ist oft die naheliegende Wahl, wenn Sie Traffic Engineering, SR-Policies oder streng definierte Pfade pro Service nutzen möchten. Das gilt besonders für Wholesale-Backbones, Metro-Transport und Netze, in denen ein Overlay nicht nur „LAN-Erweiterung“, sondern ein SLA-Produkt ist.

Wenn East-West-Scale und ECMP-Effizienz dominieren

EVPN-VXLAN passt hervorragend zu Leaf-Spine-Fabrics, bei denen ECMP, große Parallelität und schnelle Skalierung im Vordergrund stehen. Hier ist das Ziel meist nicht „Pfad fixieren“, sondern „viele Pfade effizient nutzen“.

Hardware- und Feature-Matrix: Was Sie vor der Entscheidung realistisch prüfen müssen

Viele Projekte scheitern nicht am Konzept, sondern an impliziten Annahmen: „Das kann unsere Plattform bestimmt.“ In der Praxis sollten Sie vor einer Entscheidung eine klare Feature-Matrix erstellen.

Checkliste für EVPN-MPLS

Checkliste für EVPN-VXLAN

Typische Einsatzmuster: Wann EVPN-MPLS sinnvoller ist

Typische Einsatzmuster: Wann EVPN-VXLAN sinnvoller ist

Hybrid-Realität: EVPN-MPLS und EVPN-VXLAN in einem End-to-End-Service

Viele Organisationen betreiben nicht „entweder oder“, sondern „beides“: EVPN-VXLAN im Data Center, EVPN-MPLS im Provider-Transport oder Metro-Backbone. Das ist oft sinnvoll, weil es jeweils die Stärken der Domäne nutzt. Entscheidend ist dann das Interworking an Border-Elementen:

In solchen Designs ist es besonders wichtig, ein gemeinsames Monitoring- und Ticketing-Schema zu etablieren, das Underlay/Overlay sauber trennt und dennoch schnell korrelierbar macht.

Entscheidungsraster für Produktion: Die drei Fragen, die wirklich zählen

Damit die Wahl nicht an Einzelmeinungen hängt, hilft ein strukturiertes Raster. Drei Fragen sind in der Praxis besonders belastbar:

Wenn Sie diese Fragen ehrlich beantworten, ergibt sich die Wahl häufig klarer als über Feature-Listen. Besonders wichtig ist die Messbarkeit: Ein Design, das sich nicht schnell verifizieren lässt, ist in großen Netzen langfristig teurer als ein Design, das „theoretisch eleganter“ wirkt.

Outbound-Links für Standards und vertiefende Informationsquellen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Lieferumfang:

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.

 

Exit mobile version