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

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.

• Underlay: L3-IP-Fabric (z. B. Leaf-Spine), IGP (z. B. IS-IS/OSPF) oder BGP-Underlay, ECMP, BFD, Telemetrie, NTP.
• Overlay: Tunneling oder Label/Segment-basierte Identität für logische Netze (VXLAN VNI, MPLS Labels, SR Segments, SRv6 SIDs), Control Plane für Reachability (BGP EVPN, BGP-LU, SR Control).
• Designziel: Das Underlay bleibt möglichst simpel und stabil, das Overlay liefert Flexibilität, Mandantentrennung und Automatisierbarkeit.

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

• Overlay-Segmente: VNIs ersetzen „globale VLAN-Ausdehnung“ und erlauben viele logische Segmente.
• Transport über IP: Underlay bleibt IP-basiert; VXLAN kapselt L2/L3 darüber.
• Skalierung: Mehr Segmente und größere Fabrics sind möglich als mit klassischen VLAN-/STP-Modellen.

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

Was EVPN ergänzt

• Control Plane statt Flood-and-Learn: MAC/IP-Informationen werden über BGP verteilt, Flooding wird reduziert.
• Multihoming: Redundante Anbindungen (z. B. Dual-Homing von Servern/ToR) mit definiertem Failover-Verhalten.
• Operative Stabilität: Mechanismen wie ARP/ND-Suppression senken Broadcast-/Unknown-Traffic.

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

• Leaf-Spine Fabrics: ECMP-optimierte Underlays mit klaren Failure Domains.
• Multi-Tenant-DCs: VRFs/VNIs pro Mandant, klare Segmentierung, wiederverwendbare Patterns.
• Mobility/Workload-Verteilung: Wenn logische Netze unabhängig von physischer Topologie benötigt werden.
• Standardisierung: Wenn Teams ein konsistentes DC-Overlay über mehrere Pods/Standorte nutzen wollen.

Typische Fallstricke bei EVPN/VXLAN

• Underlay unterschätzt: Instabilität im Underlay (BFD/IGP/ECMP) wirkt direkt auf das Overlay.
• Fehlende Guardrails: Unklare VTEP-Standards, inkonsistente MTU, fehlende Telemetrie für Encapsulation.
• Komplexes Multihoming: Falsche Anycast-Gateway- oder Multihoming-Parameter führen zu schwer diagnostizierbaren Blackholes.
• Overlays ohne SLOs: Wenn Latenz/Jitter/Loss nicht gemessen werden, bleiben „schnelle“ Fabrics subjektiv.

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

• Traffic Engineering ohne komplexe RSVP-TE-Signalisierung: Pfadsteuerung über Segmente statt per-Flow Signaling.
• Skalierung und Vereinfachung: Weniger State im Netz, klarere Abhängigkeiten, oft bessere Automatisierbarkeit.
• Backbone-Modernisierung: Gute Option, wenn MPLS im Netz bereits operativ beherrscht wird.

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

• Provider- oder Enterprise-Backbones: Große Domänen mit Bedarf an deterministischen Pfaden und TE-Funktionen.
• Multi-Domain-Routing: Wenn Pfadsteuerung über Domänengrenzen hinweg wichtig ist (mit passender Control Plane).
• MPLS-Lifecycle-Weiterentwicklung: Wenn MPLS nicht „abgeschafft“, sondern modernisiert werden soll.

Typische Fallstricke bei SR-MPLS

• „SR ersetzt Design“: Ohne saubere Failure Domains, Kapazitätsplanung und Konvergenzdesign bringt SR keine Magie.
• Observability-Lücken: Segment-Pfade müssen messbar und nachvollziehbar sein (Label-Stacks, Counters, Telemetrie).
• Policy-Sprawl: Pfadsteuerung kann ausufern, wenn Standards für Segment-Policies fehlen.

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

• IP-native Data Plane: Kein MPLS-Label-Stack, sondern IPv6-basierte SIDs.
• Network Programming: SIDs können Funktionen kodieren (z. B. Service-Steering), abhängig von Plattform und Implementierung.
• Konvergenz und TE-Potenzial: SR-Konzepte bleiben erhalten, aber in IPv6-Form.

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

Wann SRv6 sinnvoll ist

• IPv6-first Strategien: Wenn IPv6 im Backbone/Underlay bereits stabil etabliert ist.
• Langfristige Vereinheitlichung: Wenn MPLS- und IPv6-Strategie konsolidiert werden sollen.
• Service-Steering Bedarf: Wenn SRv6-Funktionen bewusst als Architekturwerkzeug eingesetzt werden (nicht als „Feature-Checkliste“).

Typische Fallstricke bei SRv6

• MTU und Overhead: SRv6-Header erhöhen Overhead; Underlay-MTU und Pfad-MTU müssen sauber designt und getestet werden.
• Plattform-Reife: Feature- und Telemetrie-Abdeckung kann stark variieren; operativer Reifegrad ist entscheidend.
• Troubleshooting-Komplexität: Ohne klare Standards für SID-Plan, Logging und Pfadbeobachtung wird Fehleranalyse schwierig.

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.

• Data Center Fabric: EVPN/VXLAN ist meist die naheliegende Wahl für Overlay-Segmente und Mandantentrennung.
• Backbone/WAN: SR-MPLS modernisiert MPLS-Umgebungen; SRv6 kann eine IPv6-native Alternative sein.
• Underlay bleibt kritisch: Unabhängig vom Overlay entscheidet Underlay-Stabilität über Verfügbarkeit und Performance.

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.

• Topologie: Leaf-Spine oder klare Core/Distribution-Modelle mit begrenzten Failure Domains.
• ECMP und Headroom: ECMP-Design muss Hotspots, Elephant Flows und Failover-Last berücksichtigen.
• Konvergenz: BFD, IGP-Tuning mit Guardrails, definierte Konvergenzzeiten pro Domäne.
• MTU-Design: Overlay-Encapsulation erfordert saubere MTU-Planung (VXLAN, SRv6-Header, ggf. MPLS-Stacks).
• Observability: Telemetrie, Logs, Flow-Daten, synthetische Probes, konsistente Zeitbasis (NTP).

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

• BGP als zentrale Control Plane: Standards für Route Targets, VNIs/VRFs, Multihoming-Modelle.
• Fehlerbilder: MAC/IP-Learning, ARP/ND-Suppression, Anycast Gateway, DF-Election (je nach Design).
• Change-Mechanik: Segment-/VNI-Rollouts in Wellen, klare Abnahmekriterien pro Mandant/Segment.

SR-MPLS/SRv6-Operabilität

• Segment-Plan: Node-SIDs/Adjacency-SIDs oder SRv6-SIDs brauchen konsistente Planung und Dokumentation.
• Pfadsteuerung: Standards für Policies, Schutzmechanismen gegen „Policy-Sprawl“ und messbare Validierung.
• Nachweisbarkeit: Pfade müssen beobachtbar sein (Telemetry, Counters, Logs), sonst wird SR zum Blackbox-Risiko.

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?

• Mandantentrennung: VRFs/VNIs oder SR-Policies schaffen logische Grenzen, ersetzen aber keine Policy-Governance.
• Enforcement Points: Firewalls/Proxies/Service-Chains müssen so platziert sein, dass sie nicht zum globalen Single Point of Failure werden.
• Kommunikationsmatrix: Quelle/Ziel/Service/Begründung/Owner/Review-Intervall als zentrales Artefakt für auditierbare Regeln.
• Logging/Telemetry: Overlay und Underlay müssen gemeinsam betrachtet werden, damit Flows nachvollziehbar bleiben.

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.

• MTU-Baseline: Underlay muss genügend MTU bieten, damit Overlays keine Fragmentierung oder Drops verursachen.
• QoS durchgängig: Markierungen und Queue-Profile müssen auch durch Encapsulation korrekt behandelt werden.
• Messpunkte definieren: Latenz/Jitter/Loss pro Domäne und kritischem Pfad, nicht nur „Device up“.

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.

• Einsatzdomäne: Data Center Fabric (typisch EVPN/VXLAN) vs. Backbone/WAN (typisch SR-MPLS/SRv6).
• IPv6-Reifegrad: Wenn IPv6 stabil und breit etabliert ist, wird SRv6 realistischer.
• MPLS-Bestand: Wenn MPLS vorhanden und operativ beherrscht ist, kann SR-MPLS eine evolutionäre Modernisierung sein.
• Operative Reife: Standards, Automatisierung, Telemetrie und Testkatalog bestimmen, wie viel Komplexität tragbar ist.
• Observability-Anforderungen: Können Pfade, Segmente und Policies zuverlässig gemessen und erklärt werden?
• Wartungsmodell: Wie werden Rollouts, Upgrades und Rollbacks durchgeführt, ohne große Blast Radii zu erzeugen?

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.

• Schrittweise Einführung: Zuerst Underlay stabilisieren (Konvergenz, MTU, Telemetrie), dann Overlay in begrenztem Scope pilotieren.
• Wellenplanung: Pods/Standorte/Segmente in sinnvollen Einheiten migrieren, nicht „alles gleichzeitig“.
• Interoperabilität: Definieren, wie Alt und Neu miteinander sprechen (Routing-Grenzen, Redistribution-Guardrails, Policy-Übergänge).
• Testkatalog: Failover-, Degradation- und Maintenance-Tests pro Welle, inkl. Messung von Service-Impact.

Operational Checkliste: Underlay/Overlay-Design betriebssicher machen

• Underlay stabil: ECMP-Design ohne Hotspots, definierte Konvergenzziele, BFD/IGP-Guardrails, ausreichender Headroom.
• MTU validiert: Encapsulation-Overhead berücksichtigt, Path-MTU getestet, keine stillen Drops.
• Overlay-Standards: VNI/VRF-Plan oder SID-Plan, Naming, Templates, Versions- und Deprecation-Regeln.
• Control-Plane-Transparenz: BGP/EVPN-States, SR-Policies, RR/Controller-Architektur dokumentiert und überwacht.
• Security und Logging: Enforcements klar, Kommunikationsmatrix gepflegt, Logs/Flows vollständig, Zeitbasis konsistent.
• Tests verpflichtend: Failover, Flap, Degradation, Upgrade/rollback und Pfadvalidierung wiederholbar.
• Runbooks vorhanden: Standardverfahren für Blackholes, Hash-Hotspots, MTU-Probleme, BGP/EVPN/SR-Anomalien.

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:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

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.