EVPN/VXLAN auf Cisco NX-OS: VNI Mapping, Anycast Gateway, IRB

EVPN/VXLAN auf Cisco NX-OS ist heute eines der etabliertesten Fabrik-Designs, um Layer-2- und Layer-3-Konnektivität in Datacentern skalierbar, deterministisch und betrieblich sauber umzusetzen. Statt große, flächige VLAN-Domänen durch das gesamte Rechenzentrum zu ziehen, kapselt VXLAN Layer-2-Segmente in IP/UDP und transportiert sie über ein robustes Layer-3-Underlay. EVPN liefert dazu die Control Plane: MAC-Adressen, IP-Bindings und Multicast-/Flooding-Informationen werden über MP-BGP verteilt, statt über reines Flood-and-Learn. In Cisco NX-OS bedeutet das konkret: Sie bauen eine Spine-Leaf-Fabric mit Anycast Gateway, nutzen VNI-Mapping für L2- und L3-Segmente und realisieren Inter-Subnet Routing per IRB (Integrated Routing and Bridging) direkt auf den Leafs. Genau in diesen drei Punkten entstehen jedoch die meisten Planungs- und Betriebsfehler: falsches VLAN-zu-VNI-Mapping (oder inkonsistente VNIs), ein Anycast Gateway ohne konsistente SVI-/MAC-/ARP-Regeln oder ein IRB-Design, das zwar „funktioniert“, aber bei Failovern, Host-Moves oder Policy-Änderungen schwer reproduzierbares Verhalten zeigt. Dieser Artikel erklärt EVPN/VXLAN auf Cisco NX-OS praxisnah und auf Enterprise-Niveau: wie VNI-Mapping sauber modelliert wird, wie Anycast Gateway richtig eingesetzt wird und wie IRB-Designs (symmetrisch) zuverlässig skalieren – inklusive typischer Fallstricke, Verifikationspunkte und Best Practices für Day-2-Betrieb.

Grundarchitektur: Underlay, Overlay und Rollen in der Fabric

EVPN/VXLAN trennt das Netzwerk in zwei Ebenen: das Underlay (klassisches IP-Routing) und das Overlay (VXLAN-Tunnel, EVPN-Control-Plane). Auf Cisco NX-OS ist das Ziel, dass das Underlay möglichst „langweilig“ und stabil ist, während das Overlay die Mandanten- und Segmentlogik trägt.

• Underlay: Layer-3 Spine-Leaf, typischerweise mit eBGP oder IS-IS/OSPF. Es transportiert ausschließlich IP zwischen VTEPs (VXLAN Tunnel Endpoints).
• Overlay: VXLAN kapselt L2 Frames in UDP; EVPN (BGP) verteilt MAC/IP-Informationen und steuert Flooding.
• Leaf: In der Regel der VTEP. Hier sitzen VLANs, SVIs, Anycast Gateway und IRB.
• Spine: Reines Underlay (meist ohne VXLAN-Termination), sorgt für ECMP und skalierbaren Transport.

Als Protokollhintergrund sind RFC 7348 (VXLAN) und RFC 7432 (EVPN) gute Referenzen; für einen EVPN-Überblick ist RFC 8365 (A Network Virtualization Overlay Solution using EVPN) sehr hilfreich.

VNI-Mapping verstehen: L2VNI, L3VNI und die saubere Trennung von Segment und VRF

Der häufigste Einstiegspunkt in EVPN/VXLAN ist das VNI-Mapping. Ein VNI (VXLAN Network Identifier) ist die Overlay-Entsprechung eines VLANs bzw. eines Segments – allerdings mit einem deutlich größeren Nummernraum (24 Bit). In NX-OS unterscheiden Sie in der Praxis zwei VNI-Typen:

• L2VNI: VXLAN-Segment für Layer-2 (Broadcast Domain). Häufig 1:1 zu einem VLAN gemappt.
• L3VNI: VXLAN-Segment für Layer-3 (VRF-Transport). Es repräsentiert die VRF im Overlay und ermöglicht Routing zwischen L2VNIs innerhalb der VRF über die Fabric.

Warum L3VNI ein eigenes Designobjekt ist

Ein häufiger Irrtum ist, L3VNI als „optional“ zu betrachten. In modernen, skalierenden Designs ist L3VNI der Schlüssel zu einem konsistenten, symmetrischen IRB: Jede VRF hat genau einen L3VNI. Inter-Subnet-Routing wird damit über die Fabric transportiert, ohne dass einzelne Leafs „Sonderrollen“ als zentrale Router übernehmen müssen.

Best Practices für VNI-Nummerierung

Damit VNI-Mapping auditierbar bleibt, sollten VNIs einem Schema folgen. Entscheidend ist nicht, ob Sie VNIs direkt aus VLAN-IDs ableiten, sondern dass das Schema konsistent, dokumentiert und langfristig stabil bleibt.

• Deterministisches Mapping: Beispiel: VLAN 101 ↔ L2VNI 10101 (präfixbasiert) oder VLAN 101 ↔ L2VNI 101 (direkt), sofern Nummernraum passt.
• Pro VRF ein L3VNI: L3VNI in einem separaten Bereich (z. B. 5xxxx), damit es nicht mit L2VNIs kollidiert.
• Reservieren: Freie Bereiche für Wachstum, Lab/PoC und Migrationen einplanen.

EVPN Route Types: Welche Informationen wirklich über BGP laufen

EVPN ist die Control Plane. Das bedeutet: MAC-Learnings und Host-Moves werden nicht primär über Flooding gelöst, sondern über BGP-Updates. Für den Betrieb ist es hilfreich, die wichtigsten EVPN Route Types zu kennen, weil Sie damit Fehlerbilder schneller einordnen können:

• Type 2: MAC/IP Advertisement (Host-Einträge). Zentral für ARP/ND-Optimierung und für saubere Host-Mobility.
• Type 3: Inclusive Multicast Ethernet Tag (IMET). Steuert BUM-Traffic (Broadcast/Unknown unicast/Multicast) und die Flooding-Domäne.
• Type 5: IP Prefix Routes. Relevant, wenn Sie EVPN als L3-Control-Plane für Prefixe nutzen (z. B. bestimmte Interconnect-Modelle).

Die Details sind in RFC 7432 beschrieben. In NX-OS ist im Day-2-Betrieb insbesondere Type 2/3 für klassische Datacenter-Fabrics entscheidend.

Anycast Gateway: Default Gateway ohne „Tromboning“

Anycast Gateway ist einer der größten praktischen Vorteile von EVPN/VXLAN auf Cisco NX-OS: Das Default Gateway (SVI) existiert auf jedem Leaf identisch (gleiche IP-Adresse und in der Regel gleiche Gateway-MAC). Hosts nutzen damit immer den lokal nächstgelegenen Leaf als Gateway. Das reduziert Latenz, vermeidet Hairpinning und macht Host-Mobility deutlich sauberer, weil ein Host nach einem Move sein Gateway nicht „verliert“.

Was Anycast Gateway technisch bedeutet

• Gleiche SVI-IP auf mehreren Leafs: Der Host sieht überall dieselbe Default-Gateway-IP.
• Gleiche Gateway-MAC: Der Host behält sein ARP-Binding stabil, auch wenn er den Leaf wechselt.
• Lokales Routing: Inter-Subnet-Traffic wird am Ingress-Leaf geroutet (bei symmetrischem IRB) und über L3VNI transportiert.

Fallstrick: Anycast ohne konsistente SVI-Standards

Anycast Gateway funktioniert nur dann „langweilig“, wenn SVIs und deren Parameter identisch und standardisiert sind. Typische Fehler sind inkonsistente Anycast-MAC-Konfiguration, abweichende SVI-MTU oder unterschiedliche ARP/ND-Sicherheitsfeatures pro Leaf. Das führt zu schwer reproduzierbaren Effekten, insbesondere bei Host-Moves oder bei asymmetrischen Trafficpfaden.

IRB in EVPN/VXLAN: Integrated Routing and Bridging sauber einsetzen

IRB beschreibt das Zusammenspiel von Bridging (L2VNI) und Routing (SVIs/VRFs) in der VXLAN-Fabric. In NX-OS ist das Ziel typischerweise ein symmetrisches IRB: Der Ingress-Leaf routet von VLAN A nach VLAN B innerhalb derselben VRF, kapselt dann in L3VNI (VRF-VNI) und am Egress-Leaf wird wieder in das Ziel-L2VNI decapsuliert und gebridged.

Warum symmetrisches IRB als Best Practice gilt

• Skalierung: Kein zentraler „Router Leaf“ nötig; Routing ist verteilt.
• Determinismus: Pfade sind nachvollziehbar: L2 innerhalb Segment, L3 zwischen Segmenten über VRF.
• Operationalisierung: Fehlerbilder lassen sich sauber in Underlay/Overlay/L2/L3 einsortieren.

Asymmetrisches IRB: Warum es betrieblich riskanter ist

Asymmetrische IRB-Modelle können in bestimmten Designs vorkommen, führen aber häufiger zu Debugging-Aufwand, insbesondere wenn Return Paths nicht konsistent sind oder wenn Policy-Enforcement nicht eindeutig ist. Für die meisten Enterprise- und DC-Standardfabrics ist symmetrisches IRB die stabilere Wahl.

VNI-Mapping in der Praxis: VLAN↔L2VNI und VRF↔L3VNI konsistent halten

Die häufigste Ursache für „EVPN ist up, aber Traffic geht nicht“ sind inkonsistente Mappings. Ein professionelles Betriebsmuster setzt deshalb auf Templates und harte Standards:

• VLAN-zu-L2VNI: Jede VLAN-ID hat exakt einen zugeordneten L2VNI. Dieser ist auf allen Leafs identisch, die dieses VLAN terminieren.
• VRF-zu-L3VNI: Jede VRF hat genau einen L3VNI. Dieser ist auf allen Leafs identisch, die diese VRF führen.
• SVI-Zuordnung: Jedes SVI gehört genau zu einer VRF, und das SVI existiert auf allen Leafs, auf denen Hosts dieses Segments ankommen können (für Anycast Gateway).

Ein nützlicher mentaler Check im Betrieb lautet: „Kann ich aus der Konfiguration allein deterministisch ableiten, in welchem VNI ein Frame landet?“ Wenn nicht, ist das Design zu driftanfällig.

Control Plane Design: BGP EVPN, Route Reflectors und Fabric-Rollen

In Cisco NX-OS Fabrics wird EVPN typischerweise über MP-BGP aufgebaut. In größeren Umgebungen kommen Route Reflectors (RR) zum Einsatz, um iBGP zu skalieren. Dabei gelten dieselben Grundregeln wie bei klassischen BGP-RR-Designs: Redundanz, klare Cluster-Struktur und konsistente Policies.

• RR-Redundanz: Mindestens zwei Route Reflectors, jeder Leaf peert zu beiden.
• Cluster IDs: Konsistent pro RR-Cluster, dokumentiert, keine unkontrollierten Überschneidungen.
• Policy-Disziplin: EVPN ist Control Plane; Filter und Community-Policies sollten standardisiert sein, damit keine „versteckten“ Reachability-Änderungen entstehen.

Für das RR-Grundmodell ist RFC 4456 (BGP Route Reflection) eine gute Referenz.

Flooding und BUM-Traffic: Multicast, Ingress Replication und Praxisentscheidungen

VXLAN muss BUM-Traffic transportieren: Broadcast, Unknown Unicast, Multicast. EVPN optimiert vieles (z. B. ARP/ND-Suppression über Type 2), aber BUM ist nie „null“. In NX-OS gibt es unterschiedliche Modelle, wie BUM im Underlay verteilt wird, je nach Design und Plattformfähigkeit.

• Multicast im Underlay: Klassisch, skaliert gut, erfordert aber PIM/Multicast-Komplexität im Underlay.
• Ingress Replication: Kein Underlay-Multicast nötig; der Ingress-VTEP repliziert BUM zu allen Remote-VTEPs. Betrieblich oft einfacher, aber bei sehr großen VTEP-Anzahlen weniger effizient.
• ARP/ND Suppression: Reduziert Broadcast-Anteil erheblich, wenn korrekt eingesetzt (Type-2 MAC/IP).

Best Practice ist, die BUM-Strategie nicht „aus Gewohnheit“ zu wählen, sondern anhand von Fabric-Größe, Hardwarefähigkeiten und Betriebskomplexität.

Anycast Gateway und ARP/ND: Stabilität durch Control-Plane-Optimierung

In EVPN/VXLAN-Fabrics ist ARP/ND-Handling ein operativer Schlüssel. Wenn ARP nicht kontrolliert ist, steigt Broadcast-Traffic, und Host-Moves erzeugen mehr Noise. EVPN kann IP/MAC-Bindings verteilen, damit ARP/ND lokal beantwortet werden kann (ARP suppression/ND proxy), was die Fabric deutlich beruhigt.

• Weniger Broadcast: ARP wird kontrollierter und oft lokal beantwortet.
• Host-Mobility: IP/MAC-Moves werden als EVPN-Updates verteilt, nicht durch „Learning Chaos“.
• Fehlersuche: IP/MAC-Binding lässt sich kontrolliert prüfen, statt nur auf Flooding zu hoffen.

Inter-VRF und Security: EVPN/VXLAN ist kein Ersatz für Policy

EVPN/VXLAN löst Segmentierung und Transport. Security-Policy bleibt ein eigenes Thema. Ein häufiger Fehler ist, IRB-Routing als „automatisch sicher“ zu interpretieren. Routing zwischen Subnetzen innerhalb einer VRF ist per Design möglich; wenn Sie Isolation benötigen, müssen Sie diese bewusst umsetzen (z. B. separate VRFs, Firewalls oder Microsegmentation).

• VRF als harte Grenze: Mandanten- oder Zonenisolation bevorzugt über VRFs statt über riesige ACL-Regelwerke.
• Shared Services: Bewusstes Route-Leaking oder Service-Chaining, nicht „alles in eine VRF“.
• Observability: Policies müssen messbar sein (Counters, Logs), sonst wird Debugging unzuverlässig.

Day-2 Betrieb: Verifikation, Monitoring und typische Fehlerbilder

Ein EVPN/VXLAN-Design ist dann produktionsreif, wenn Sie es systematisch verifizieren können. Statt „Ping geht nicht“ brauchen Sie eine Schichtlogik: Underlay, VTEP, BGP EVPN, VNI-Mapping, Anycast Gateway, IRB.

• Underlay-Checks: ECMP stabil, keine Link-Flaps, Routing-Neighbors stabil.
• VTEP-Reachability: Loopbacks/Source-Interfaces erreichbar, MTU ausreichend.
• BGP EVPN: Sessions up, Route Types vorhanden, keine Policy-Drift.
• VNI-Mapping: VLAN↔L2VNI und VRF↔L3VNI konsistent auf allen Leafs.
• Anycast Gateway: SVI überall vorhanden, MAC/IP identisch, ARP/ND stabil.
• IRB: Ingress-Routing und L3VNI-Transport nachvollziehbar, Return Path konsistent.

Typische Fehlerbilder und deren häufigste Ursachen

• Hosts im gleichen VLAN erreichen sich nicht: L2VNI-Mismatch, fehlende VTEP-Membership, BUM/Flooding-Problem.
• Inter-VLAN Routing funktioniert nicht: VRF/L3VNI inkonsistent, SVI fehlt auf einem Leaf, Anycast-Parameter abweichend.
• Nach Host-Move sporadische Probleme: ARP/ND-Binding inkonsistent, fehlende EVPN Type-2 Updates, MAC-Move Policy/Timers falsch bewertet.
• Hohe Broadcast-Last: ARP suppression fehlt oder ist inkonsistent, BUM-Design nicht passend, falsche Flooding-Domänen.
• „Alles ist up, aber nichts geht“: MTU/Overhead unterschätzt (VXLAN-Encapsulation), vTEP-Loopback nicht end-to-end erreichbar, oder falsche VRF-Zuordnung am Interface.

Best Practices als Blueprint: EVPN/VXLAN auf NX-OS konsistent standardisieren

• Stabiles Underlay: eBGP oder IS-IS/OSPF sauber, p2p-Links, klare Loopback-Standards, ECMP by design.
• VNI-Schema: Deterministische L2VNI/VLAN-Regel, separater L3VNI-Bereich pro VRF, dokumentiert und versioniert.
• Anycast Gateway standardisieren: Identische SVI-Templates, konsistente Gateway-MAC, einheitliche ARP/ND-Policies.
• Symmetrisches IRB: Distributed Routing via L3VNI, keine „Sonderrouter“ für Inter-Subnet-Traffic.
• RR-Redundanz: Zwei RRs, klare Cluster IDs, konsistente Policies.
• Operationalisierung: Monitoring für BGP EVPN, VTEP-Reachability, MAC/IP-Moves, BUM-Anteile und MTU-Drops.

Outbound-Referenzen

• Cisco Nexus 9000 NX-OS Configuration Guides für Cisco-spezifische EVPN/VXLAN-Konfiguration, Anycast Gateway und IRB-Modelle.
• RFC 7348 (VXLAN) für VXLAN-Kapselung und VNI-Grundlagen.
• RFC 7432 (EVPN) für EVPN Route Types und Control-Plane-Mechanik.
• RFC 8365 (EVPN Overlay Solution) für eine strukturierte EVPN-Overlay-Architekturübersicht.
• RFC 4456 (BGP Route Reflection) für RR-Designprinzipien, relevant für skalierbares EVPN in großen Fabrics.

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.