Site icon bintorosoft.com

Underlay/Overlay Design: EVPN/VXLAN, SR-MPLS und SRv6 richtig einordnen

Globe icon with laptops around it, isolated on white background

Underlay/Overlay Design ist heute ein Kernbaustein moderner Netzwerkarchitekturen, weil es Skalierung, Mandantentrennung und Automatisierung deutlich erleichtert. Statt große Layer-2-Domänen „auszudehnen“ oder komplexe klassische MPLS-Designs in jede Ecke zu tragen, wird die Infrastruktur in zwei Schichten gedacht: Das Underlay stellt robuste IP-Konnektivität bereit (Routing, ECMP, Konvergenz, Telemetrie), während das Overlay logische Netzwerke, Segmente und Services abstrahiert (VNI/VRF, MAC/IP-Learning, Policy, Service-Chaining). In der Praxis stehen Architektenteams häufig vor der Frage, wie EVPN/VXLAN, SR-MPLS und SRv6 richtig einzuordnen sind: Welche Technologie löst welches Problem, welche Abhängigkeiten entstehen, wie hoch ist die operative Komplexität, und wo liegt der echte Mehrwert gegenüber einer „klassischen“ Lösung? Dieser Artikel ordnet Underlay/Overlay Design systematisch ein, erklärt EVPN/VXLAN als dominantes Data-Center-Overlay, zeigt SR-MPLS als effiziente Segment-Routing-Weiterentwicklung für MPLS-Backbones und erläutert SRv6 als IP-nativen Ansatz für Segment Routing und Servicefunktionen. Ziel ist eine belastbare Orientierung, mit der Sie Technologieentscheidungen nicht nach Trend, sondern nach Anforderungen, Risiko und Betriebsfähigkeit treffen.

Underlay vs. Overlay: Das Grundprinzip in professionellen Designs

Ein Underlay/Overlay-Ansatz trennt Zuständigkeiten, reduziert Kopplung und verbessert Wiederverwendbarkeit. Das Underlay ist die „Transportebene“: IP-Routing, stabile Konvergenz, ECMP, Failure Domains und Kapazitätsreserven. Das Overlay bildet darüber die „logische Ebene“: Mandanten, Segmente, virtuelle Netze, Policies und – je nach Technologie – auch Servicefunktionen.

Ein häufiges Missverständnis ist, dass das Overlay „die Komplexität verschwinden lässt“. In Wahrheit verlagert sich Komplexität in Control-Plane- und Operational-Modelle. Deshalb ist die richtige Einordnung entscheidend: Welche Schicht ist wofür verantwortlich, und wie wird die Fehlerdomäne begrenzt?

EVPN/VXLAN richtig einordnen: Der De-facto-Standard im Data Center

EVPN/VXLAN ist in vielen Data-Center-Architekturen das Standard-Overlay, weil es eine skalierbare Alternative zu klassischen L2-Erweiterungen bietet und Multi-Tenancy sauber abbildet. VXLAN ist dabei das Data-Plane-Encapsulation-Format (VNI als Segment-ID), während EVPN (BGP EVPN) als Control Plane MAC- und IP-Reachability verteilt und Mechanismen für Multihoming, ARP/ND-Suppression und optimiertes Learning bereitstellt.

Was VXLAN liefert

Technische Details zu VXLAN finden sich in RFC 7348 (VXLAN).

Was EVPN ergänzt

EVPN-Grundlagen sind in RFC 7432 (BGP MPLS-Based EVPN) beschrieben; EVPN wird in der Praxis auch mit VXLAN als Data Plane kombiniert.

Wann EVPN/VXLAN besonders sinnvoll ist

Typische Fallstricke bei EVPN/VXLAN

SR-MPLS einordnen: Segment Routing als Evolution des MPLS-Backbones

SR-MPLS (Segment Routing over MPLS) ist vor allem im WAN- und Backbone-Kontext relevant, in dem MPLS bereits etabliert ist oder in dem eine labelbasierte Data Plane mit klarer Traffic-Engineering-Fähigkeit benötigt wird. Segment Routing ersetzt dabei viele klassische MPLS-TE-Konstrukte durch das Konzept von Segmenten (z. B. Node-SIDs, Adjacency-SIDs), die als „Anweisung“ für den Pfad dienen. Die Steuerung kann über IGP-Erweiterungen oder über zentrale Controller erfolgen, während die Forwarding-Mechanik MPLS-Labels nutzt.

Was SR-MPLS gut kann

Die Architektur von Segment Routing wird in RFC 8402 (Segment Routing Architecture) beschrieben; die SR-MPLS Data Plane ist in RFC 8660 (SR-MPLS Data Plane) festgehalten.

Wann SR-MPLS besonders sinnvoll ist

Typische Fallstricke bei SR-MPLS

SRv6 einordnen: IP-nativ, flexibel – aber mit klaren Voraussetzungen

SRv6 (Segment Routing over IPv6) verfolgt das Ziel, Segment Routing vollständig in IPv6 zu integrieren. Statt MPLS-Labels werden IPv6-basierte Segment Identifiers (SIDs) verwendet, die sowohl Pfadsteuerung als auch Servicefunktionen (Network Programming) abbilden können. SRv6 ist damit konzeptionell sehr mächtig: Pfade, Policies und bestimmte Service-Mechanismen lassen sich als „Programmierkette“ ausdrücken.

Was SRv6 besonders macht

Grundlagen zu SRv6 und Network Programming finden sich in RFC 8986 (SRv6 Network Programming).

Wann SRv6 sinnvoll ist

Typische Fallstricke bei SRv6

EVPN/VXLAN vs. SR-MPLS vs. SRv6: Welche Schicht adressiert welches Problem?

Eine belastbare Einordnung gelingt, wenn Sie Technologie nicht nach Namen, sondern nach Einsatzdomäne und Funktionsziel sortieren. EVPN/VXLAN dominiert typischerweise als Data-Center-Overlay für Multi-Tenancy und L2/L3-Services über IP-Underlays. SR-MPLS und SRv6 adressieren häufiger Backbone/WAN-Themen: Pfadsteuerung, TE, deterministische Routing-Policies und – im Fall SRv6 – IP-native Integration und Network Programming.

Underlay-Design: Die Regeln, die unabhängig vom Overlay gelten

Viele Architekturprobleme werden fälschlich dem Overlay zugeschrieben, obwohl das Underlay der Engpass ist. Deshalb sollte Underlay-Design als eigenes Produkt verstanden werden: klarer Standard, wiederverwendbare Patterns und messbare Konvergenz.

Control Plane und Betriebsmodell: Der eigentliche Unterschied in der Praxis

Technologieentscheidungen scheitern selten an der Data Plane, sondern an Control Plane, Betrieb und Governance. Deshalb sollten Sie früh klären, wie Reachability verteilt wird, wie Policies ausgerollt werden und wie Troubleshooting abläuft.

EVPN-Operabilität

SR-MPLS/SRv6-Operabilität

Security- und Segmentierungsaspekte: Was sich ändert und was nicht

Underlay/Overlay-Design ersetzt keine Security-Architektur, kann sie aber besser strukturieren. Mandantentrennung (VRFs/VNIs) und klar definierte Zonen sind gut mit Overlays kombinierbar. Entscheidend bleibt: Wo wird enforced, wie werden Policies dokumentiert, und wie wird Logging vollständig umgesetzt?

Performance und Overhead: MTU, Encapsulation und Messbarkeit

Ein häufig unterschätzter Punkt ist der Encapsulation-Overhead. VXLAN und SRv6 erhöhen den Header-Anteil; bei SR-MPLS kann ein Label-Stack relevant werden. Das ist nicht „schlecht“, muss aber in MTU, Path-MTU-Discovery, QoS und Monitoring berücksichtigt werden.

Entscheidungsmatrix: Welche Fragen die Technologieauswahl lenken

Statt „EVPN/VXLAN oder SR?“ ist die bessere Frage: Welche Anforderungen und Randbedingungen sind gegeben? Die folgenden Kriterien helfen, EVPN/VXLAN, SR-MPLS und SRv6 korrekt zu gewichten.

Migration und Koexistenz: So vermeiden Sie „Big Bang“-Risiken

Die meisten Organisationen migrieren nicht von heute auf morgen. Deshalb sollte Underlay/Overlay Design immer Koexistenz und Übergangsarchitekturen berücksichtigen. Professionelle Migrationsplanung definiert Wellen, klare Exit-Kriterien und testbare Abnahmen.

Operational Checkliste: Underlay/Overlay-Design betriebssicher machen

Mit dieser Einordnung wird klar: EVPN/VXLAN, SR-MPLS und SRv6 sind keine konkurrierenden „Trendbegriffe“, sondern Werkzeuge für unterschiedliche Domänen und Reifegrade. Ein belastbares Underlay/Overlay Design entsteht, wenn Underlay-Stabilität, Control-Plane-Standards, Observability und Wartbarkeit von Anfang an als gleichwertige Designinputs behandelt werden.

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