Migration von VLAN zu EVPN/VXLAN: Adressierung und Mapping planen

Die Migration von VLAN zu EVPN/VXLAN ist im Telco- und Provider-Umfeld ein typischer Schritt, wenn klassische Layer-2-Domänen an Grenzen stoßen: zu große Broadcast-Domänen, schwieriges VLAN-Scaling (4094 VLANs sind schneller „voll“ als man denkt), komplexe STP-Topologien, unklare Trunk-Scopes und hohe Betriebskosten durch L2-Fehlersuche. EVPN/VXLAN verspricht hier echte Vorteile: skalierbare Layer-2- und Layer-3-Segmente über ein routbares Underlay, saubere Multi-Tenant-Isolation, Anycast Gateways, kontrolliertes MAC-Learning via Control Plane und bessere Automatisierbarkeit. Gleichzeitig ist die Umstellung kein reines „Feature-Upgrade“. Sie ist eine Design- und Migrationsaufgabe, bei der Adressierung und Mapping über Erfolg oder Chaos entscheiden: VTEP-IPs müssen stabil und aggregierbar sein, Underlay-Links müssen konsistent adressiert werden, VLANs müssen auf VNIs gemappt werden (und zwar nach einem Schema), VRFs benötigen strukturierte Route-Targets, Anycast-Gateway-IPs müssen sauber geplant und dokumentiert werden, und der Übergang zwischen Legacy-VLAN-Welt und EVPN/VXLAN-Welt braucht klare Interop-Muster (Bridging, IRB, L2/L3-Gateways). Wer ohne Blueprint migriert, baut ein zweites Chaos – nur moderner verpackt. Dieser Artikel zeigt praxisnah, wie Sie die Migration so planen, dass sie wiederholbar und betriebssicher ist: Welche Adressräume Sie brauchen, wie Sie VLAN-to-VNI und VLAN-to-VRF Mapping systematisieren, wie Sie Cutover in Wellen durchführen und welche typischen Fehlerbilder Sie vorab vermeiden.

Warum EVPN/VXLAN statt klassischem VLAN-Trunking?

Im Kern ersetzt EVPN/VXLAN nicht „VLAN“, sondern die Art, wie VLANs transportiert und skaliert werden. VLAN bleibt häufig als lokale Segment-ID im Access bestehen, während VXLAN die Overlays über das Underlay trägt. EVPN ist dabei die Control Plane, die MAC/IP-Informationen verteilt und Multi-Homing sauber macht.

• Skalierung: VXLAN VNIs sind 24 Bit (deutlich mehr als VLAN-IDs), wodurch Segmentanzahl und Mandantenfähigkeit steigen.
• Stabilität: weniger STP-Abhängigkeit, klarere Failure Domains, kontrolliertes Learning.
• Segmentierung: VRFs + VNIs ermöglichen saubere Tenant-Isolation und Policy-Strukturen.
• Automation: Templates und Source-of-Truth lassen sich besser durchziehen (VNI/RT/RD/Prefix-Container).

Grundbausteine im EVPN/VXLAN-Design: Underlay, Overlay, VTEPs, VNIs

Für die IP-Planung ist wichtig, die Ebenen zu trennen. Viele Migrationsprobleme entstehen, wenn Underlay- und Overlay-Adressierung vermischt werden oder wenn VTEP-IPs „irgendwo“ herkommen.

• Underlay: routbares IP-Netz zwischen Leafs/Spines (oder P/PE) – typischerweise mit IGP (IS-IS/OSPF) und P2P-Netzen.
• Overlay: VXLAN-Tunnel zwischen VTEPs; VNIs repräsentieren L2- oder L3-Segmente.
• VTEP: VxLAN Tunnel Endpoint, meist eine Loopback-IP auf Leaf/PE.
• EVPN Control Plane: meist BGP EVPN; verteilt MAC/IP/Route-Informationen und Multi-Homing State.

Adressierung im Underlay: Standards, die Migrationen stabil machen

Im Underlay gelten klassische Provider-Best-Practices: kleine, konsistente P2P-Netze, stabile Loopbacks, klare Summaries. EVPN/VXLAN funktioniert nur so gut wie das Underlay.

• P2P IPv4: /31 als Default, /30 nur als Ausnahme (Gerätekompatibilität) – konsistent über alle Links.
• P2P IPv6: /127 als Default, wenn Dual Stack im Underlay genutzt wird.
• Loopbacks: /32 (IPv4) und /128 (IPv6) rollenbasiert (Leaf/VTEP, Spine, RR).
• IGP-Scope: nur Underlay- und Loopback-Prefixe im IGP, keine Tenant- oder Service-Netze.

VTEP-IP-Plan: Stabil, aggregierbar, rollenbasiert

Die VTEP-IP ist die Identität Ihres VXLAN-Endpunkts. Sie sollte aus einem dedizierten Rollenblock stammen und so strukturiert sein, dass Sie pro Pod/PoP/Region aggregieren können. VTEP-IPs sollten nicht aus „Management-Netzen“ oder „irgendeinem freien Pool“ kommen.

• Dedizierter VTEP-Container: eigener Prefix-Container pro Region/PoP/Pod.
• Rollenbasierung: VTEP-Loopbacks getrennt von Router-ID-Loopbacks (wenn Ihr Design das trennt) oder klar dokumentiert, wenn es zusammenfällt.
• Redundanz sichtbar: VTEPs pro Leaf; bei Multi-Homing/MLAG/ESI müssen Identitäten sauber nachvollziehbar sein.
• Monitoring: VTEP-IPs sind ideale Source-IPs für Telemetry und Overlay-Debugging.

VLAN-to-VNI Mapping: Der Kern der Migrationsplanung

Die größte operative Herausforderung ist nicht „VXLAN aktivieren“, sondern ein Mapping zu finden, das langfristig konsistent bleibt. Ohne Schema entstehen Kollisionsrisiken, unklare Dokumentation und schwer skalierbare Automatisierung. Ein gutes Mapping ist deterministisch: Aus VLAN (plus Scope/Tenant) lässt sich VNI ableiten.

• L2VNI: VNI für ein Layer-2-Segment (entspricht funktional einem VLAN im Overlay).
• L3VNI: VNI für eine VRF (Layer-3-Overlay), über das Inter-Subnet-Routing in der VRF läuft.
• Mapping-Strategie: entweder VNI = VLAN-ID (einfach, aber begrenzt) oder VNI nach Schema (skalierbar).
• Scope-Faktor: Tenant/VRF und Standort müssen berücksichtigt werden, um Überschneidungen zu vermeiden.

Bewährte Mapping-Modelle

• Einfaches Modell: L2VNI = 10000 + VLAN (z. B. VLAN 120 → VNI 10120). Vorteil: leicht zu merken; Nachteil: begrenzte Ausdruckskraft.
• Tenant-basiertes Modell: VNI = TenantID * 10000 + VLAN. Vorteil: starke Isolation; Nachteil: TenantID-Governance nötig.
• Service-basiertes Modell: VNI-Bereiche pro Serviceklasse (SVC, CUST, MGMT, OAM) plus Offset. Vorteil: Policies werden einfacher.

Wichtig ist nicht, welches Modell Sie wählen, sondern dass es dokumentiert, versioniert und automatisierbar ist.

VLAN-to-VRF Mapping: Wann L2 reicht und wann L3 sauberer ist

In vielen Bestandsnetzen wird Segmentierung ausschließlich über VLANs gemacht. In EVPN/VXLAN-Designs ist VRF die natürliche Isolationseinheit, insbesondere für Multi-Tenant, Overlaps und saubere Policy-Modelle. Die Frage lautet: Welche VLANs gehören zusammen in eine VRF, und welche müssen strikt getrennt werden?

• Eine VRF pro Tenant: ideal bei Kunden-/Mandantenisolation, Overlaps, SLA- oder Security-Anforderungen.
• Eine VRF pro Serviceklasse: z. B. MGMT, OAM, SVC, CUST-RES, CUST-BIZ.
• L3VNI pro VRF: jede VRF bekommt einen L3VNI; das Routing innerhalb der VRF läuft darüber.
• Interop zu Legacy: VRF-Grenzen vereinfachen Übergänge über Firewalls/Policy-Gateways.

IRB und Anycast Gateway: IP-Adressierung für Default Gateways

Ein großer Vorteil von EVPN/VXLAN ist das Anycast Gateway: Mehrere Leafs können denselben Gateway-IP/MAC anbieten, was Failover verbessert und Ost-West-Verkehr lokal hält. Für die IP-Planung bedeutet das: Gateway-IPs sind nicht mehr „pro Switch“, sondern „pro Segment“. Das muss sauber standardisiert werden.

• Gateway-IP pro Subnetz: bleibt stabil, auch wenn Workloads zwischen Leafs wandern.
• Anycast-MAC: konsistent pro Fabric/Pod; muss dokumentiert sein, weil Troubleshooting daran hängt.
• IP-Plan-Disziplin: Subnetze pro VLAN/Segment klar, keine „kreativen“ Gateways pro Leaf.
• Reserved IPs: definieren, welche IPs im Subnetz für Gateway, VIPs, Infrastruktur reserviert sind.

Route Targets, Route Distinguishers und Naming: Policy-Fähigkeit von Anfang an

EVPN basiert oft auf BGP. Damit kommen Identifikatoren wie RD/RT ins Spiel. Wenn diese Werte wild vergeben werden, wird das Netz schwer zu auditieren. Ein telco-taugliches Design nutzt ein Schema, das Scope (Region/PoP), VRF/Tenant und Serviceklasse abbildet.

• RD-Strategie: deterministisch (z. B. aus Router-ID + VRF-ID) oder zentral aus SoT vergeben.
• RT-Strategie: pro VRF (L3) und pro L2VNI (L2) klare RTs; keine unkontrollierten Leaks.
• Naming: VRF-Namen, VNI-Labels und VLAN-Namen enthalten Scope und Rolle (z. B. MET-BER-SVC-APP1).
• Governance: ein zentraler Katalog verhindert RT-Kollisionen, besonders bei Multi-Pod/Region.

Migrationstaktik: Koexistenz statt Big Bang

Die meisten Netze migrieren nicht alles auf einmal. Sie betreiben Legacy VLAN-Transport und EVPN/VXLAN eine Zeit parallel. Dafür brauchen Sie klare Interop-Muster, sonst entstehen Loops oder inkonsistente Forwarding-Domänen.

• Wellen nach Scope: pro PoP/Pod/Metro-Ring migrieren, nicht querbeet.
• Wellen nach Serviceklasse: erst interne Services, dann weniger kritische Customer-Segmente, dann hochkritische Bereiche.
• Parallelbetrieb: definierte Übergangspunkte (Gateway/Border Leaf) statt „VLAN überall doppelt“.
• Rollback: für jede Welle ein klarer Rückweg, der technisch getestet ist.

Interop-Muster: Legacy VLANs in EVPN/VXLAN-Welt abbilden

• VLAN-Aware Bundles: mehrere VLANs werden im EVPN als getrennte L2VNIs geführt; eignet sich für strukturierte Migration.
• VLAN-Based Service: ein VLAN wird als eigene EVPN-Instanz migriert; einfach, aber bei vielen VLANs aufwändig.
• Border Leaf Bridging: ein Border Leaf bridged zwischen Legacy VLAN und VXLAN L2VNI – sinnvoll als Übergangspunkt, aber Scope strikt begrenzen.
• L3 Cutover: statt L2 Bridging wird am Rand auf L3 umgestellt (VRF/IRB); reduziert L2-Ausdehnung, verlangt aber IP-/Gateway-Planung.

IP-Plan-Fallen bei der Migration: Was typischerweise schiefgeht

• VTEP-IPs ohne Struktur: erschwert Summaries, Monitoring und Fehlersuche.
• VNI-Kollisionen: entstehen, wenn kein Mapping-Schema existiert oder Tenant/Scope nicht berücksichtigt wird.
• Gateway-Inkonsistenz: unterschiedliche Gateway-IPs/MACs pro Leaf führen zu ARP/ND-Churn und instabilem Traffic.
• RT/RD Wildwuchs: unerwartete Route-Leaks zwischen VRFs oder zwischen Pods/Regionen.
• MTU unterschätzt: VXLAN-Overhead; große Pakete blackholen, wenn Underlay nicht angepasst ist.
• Trunk-Altlasten: Legacy „allow all“ Trunks transportieren plötzlich mehr als gedacht; Loops und Broadcast-Stürme werden wahrscheinlicher.

MTU, QoS und Monitoring: Begleitdesign, das im IP-Plan auftauchen muss

EVPN/VXLAN-Migration ist nicht nur Adressierung. Drei Themen müssen im Plan und in Templates enthalten sein, sonst entstehen „mystische“ Störungen.

• MTU-Profile: Underlay-MTU so planen, dass VXLAN inklusive Overhead zuverlässig passt; PMTUD nicht kaputtfiltern.
• QoS-Mapping: CoS/802.1p und DSCP-Mappings definieren; besonders, wenn Legacy VLANs QoS nutzen.
• Observability: OAM-Netze/VRFs sauber trennen; VTEP-Loopbacks als stabile Source-IPs nutzen.

Dokumentation und Source of Truth: Mapping und Adressierung als Datenmodell

Eine erfolgreiche Migration hat eine starke Datenbasis. Mindestens folgende Objekte sollten in Ihrem SoT/IPAM gepflegt werden, bevor die erste Welle live geht.

• VLAN: ID, Name, Scope, Role, Legacy-Status, Owner.
• L2VNI: VNI, VLAN-Zuordnung, RTs, Site/Pod, Status.
• VRF/L3VNI: VRF-Name, L3VNI, RTs/RD, erlaubte Leaks, Owner.
• Subnetz/Gateway: Prefix, Anycast Gateway IP/MAC, Reserved IPs, DHCP/ND-Policies.
• VTEP: VTEP-IP, Device, Pod/PoP, Loopback-Container, Monitoring-Profile.
• Interop-Punkte: Border Leafs, Bridging-Scopes, Cutover-Wellen, Rollback-Plan.

Praxis-Checkliste: Adressierung und Mapping für die EVPN/VXLAN-Migration planen

• Underlay standardisieren: P2P /31 (IPv4) und /127 (IPv6), Loopbacks /32-/128, IGP-Scope sauber.
• VTEP-Container definieren: dedizierte VTEP-Loopback-Prefixe pro Region/Pod, aggregierbar und dokumentiert.
• VLAN-to-VNI Schema festlegen: deterministische Ableitung (Offset, TenantID, Serviceklasse), Kollisionen ausgeschlossen.
• VLAN-to-VRF Modell bauen: VRFs nach Tenant/Serviceklasse, L3VNI pro VRF, Leak-Allow-Lists.
• Anycast Gateway planen: Gateway-IP/MAC pro Subnetz, Reserved-IP-Regeln, konsistente IRB-Policies.
• RT/RD Governance: zentraler Katalog, standardisierte Naming/Tagging-Regeln für VRFs und VNIs.
• Migration in Wellen: Scope-basiert (PoP/Pod/Metro) und servicebasiert, mit getesteten Rollbacks.
• Interop sauber begrenzen: Border Leaf Patterns, kein „doppeltes VLAN überall“, Trunk-Scopes reduzieren.
• MTU/QoS/OAM mitnehmen: MTU-Profil, QoS-Mappings, OAM-VRF/Netze als Pflicht in Templates.
• SoT/IPAM nutzen: VLAN/VNI/VRF/Gateway/VTEP als Datenmodell, versioniert und drift-sicher.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.