Netzwerk & WAN
EVPN
EVPN (Ethernet VPN, RFC 7432) ist eine BGP-basierte Steuerebene für Layer-2- und Layer-3-Overlays; sie verteilt MAC- und IP-Adressen per Routing statt per Fluten.
- BGP-Steuerebene für Overlays
- Control-Plane statt Flood & Learn
- Aktiv/Aktiv-Multihoming
- RFC 7432 (Standards Track)
- VXLAN, MPLS oder SRv6
EVPN (Ethernet VPN) ist eine Steuerebene, die MAC- und IP-Adressen über das Border Gateway Protocol verteilt, statt sie wie klassisches VPLS per Fluten zu lernen. Damit weiß jeder Knoten im Netz, hinter welchem Tunnelendpunkt eine Adresse erreichbar ist, lange bevor das erste Datenpaket fließt.
Dieser Artikel erklärt die BGP-Adressfamilie hinter EVPN, die fünf Routentypen und ihre Aufgaben, das Multihoming über Ethernet Segments mit DF-Election und Split-Horizon, den Unterschied zwischen symmetrischem und asymmetrischem IRB, die MTU-Anforderung bei VXLAN sowie die Einordnung von EVPN-VXLAN im Rechenzentrum gegenüber EVPN-MPLS im Carrier-Netz.
1. Von Flood & Learn zur Control Plane
Klassische Layer-2-Verfahren lernen MAC-Adressen, indem sie unbekannten Verkehr in alle Richtungen fluten und aus den Antworten lernen. Das skaliert schlecht und erzeugt viel Broadcast-, Unknown-Unicast- und Multicast-Verkehr (BUM). EVPN dreht das um: Ein Tunnelendpunkt kündigt die hinter ihm sitzenden MAC- und IP-Adressen aktiv über BGP an. Andere Knoten kennen die Erreichbarkeit dadurch im Voraus, und der Großteil des Flutens entfällt.
Technisch nutzt EVPN dafür eine eigene Adressfamilie in Multiprotocol-BGP: AFI 25 (L2VPN) mit SAFI 70 (EVPN). Über dieselbe BGP-Sitzung, die ohnehin im Netz läuft, werden so strukturierte Informationen über MAC-Adressen, IP-Bindungen und Ethernet-Segmente transportiert.
2. Die fünf Routentypen
EVPN strukturiert seine Ankündigungen in Routentypen. Jeder hat eine klare Aufgabe:
| Typ | Name | Aufgabe |
|---|---|---|
| Type 1 | Ethernet Auto-Discovery | Mass Withdrawal, Aliasing und Split-Horizon für Multihoming |
| Type 2 | MAC/IP Advertisement | kündigt eine MAC, optional mit IP-Bindung an (Basis des Lernens) |
| Type 3 | Inclusive Multicast Ethernet Tag | baut die Replikationsliste für BUM-Verkehr je Segment auf |
| Type 4 | Ethernet Segment Route | ermöglicht die Designated-Forwarder-Wahl bei Multihoming |
| Type 5 | IP Prefix Route | kündigt IP-Präfixe ohne MAC-Bindung an (RFC 9136) |
3. Multihoming: ESI, DF-Election und Split-Horizon
Soll ein Server oder Standort an mehreren Tunnelendpunkten gleichzeitig hängen, identifiziert ein 10 Byte langer Ethernet Segment Identifier (ESI) das gemeinsame Segment. EVPN kennt zwei Betriebsarten: all-active, bei der alle beteiligten Endpunkte gleichzeitig weiterleiten, und single-active, bei der einer aktiv ist und die anderen als Reserve dienen.
Damit BUM-Verkehr nicht doppelt zugestellt wird und keine Schleifen entstehen, einigen sich die beteiligten Endpunkte per Type-4-Route auf einen Designated Forwarder je Segment. Split-Horizon-Filtering verhindert, dass ein Endpunkt ein BUM-Paket zurückbekommt, das er selbst gesendet hat. Fällt ein Uplink aus, beschleunigt Mass Withdrawal über Type-1-Routen das Invalidieren vieler MACs auf einmal.
4. ARP-Suppression statt Broadcast
Weil EVPN MAC- und IP-Bindungen über Type-2-Routen kennt, kann der lokale Tunnelendpunkt ARP- und Neighbor-Discovery-Anfragen direkt beantworten, statt sie ins ganze Segment zu fluten. Diese ARP/ND-Suppression senkt den Broadcast-Anteil in großen Layer-2-Domänen deutlich, ein wesentlicher Grund, warum EVPN-Fabrics weit über die Größe klassischer VLAN-Netze hinaus stabil bleiben.
5. Routing im Overlay: symmetrisches und asymmetrisches IRB
Sobald Verkehr zwischen Subnetzen geroutet werden soll, kommt Integrated Routing and Bridging (IRB, RFC 9135) ins Spiel. Es gibt zwei Modelle:
- Asymmetrisches IRB der eingehende Endpunkt routet bereits ins Zielsegment. Einfach in der Steuerebene, aber jeder Endpunkt muss ARP- und Bridge-Tabellen für alle Subnetze halten. Das skaliert bei vielen Subnetzen schlecht.
- Symmetrisches IRB beide Seiten routen über ein gemeinsames L3-VNI (eine VRF im Overlay). Jeder Endpunkt hält nur die Einträge seiner lokalen Hosts, was deutlich besser skaliert und heute die Standardempfehlung ist.
L2VNI und L3VNI
Die Begriffe L2VNI und L3VNI sind Industriejargon (Cisco, Arista, FRRouting). Gemeint ist die VNI für die Bridge-Domäne (L2) beziehungsweise für die übergreifende Routing-Instanz (L3); im MPLS-basierten EVPN entsprechen ihnen zwei MPLS-Labels statt VNIs.
6. MTU im Underlay: Jumbo Frames oder kleinere Tenant-MTU
Trägt EVPN ein VXLAN-Overlay, kapselt jeder Tunnel das Originalpaket in zusätzliche Header. Bei IPv4-Underlay sind das rund 50 Byte (äußeres Ethernet, IP, UDP und der VXLAN-Header), bei IPv6-Underlay rund 70 Byte. VXLAN fragmentiert nicht.
Reicht die Underlay-MTU nicht für Nutzlast plus Kapselung, entstehen stille Paketverluste, einer der häufigsten Fehler beim Fabric-Aufbau. Praxisüblich ist deshalb eine Underlay-MTU von 9216 Byte, sodass Hosts mit 9000-Byte-Frames ohne Fragmentierung bedient werden. Dieser Wert ist Hersteller-Praxis, kein RFC-Pflichtwert.
Ein einziges Gerät im Underlay ohne ausreichende MTU verursacht in einer VXLAN-EVPN-Fabric schwer auffindbare, sporadische Verluste. Jumbo-Frames gehören vor dem Rollout durchgängig verifiziert.
7. Steuerung über BGP: RD und Route-Targets
Wie bei MPLS-VPNs macht ein Route Distinguisher die EVPN-Ankündigungen netzweit eindeutig, sodass identische Adressen verschiedener Mandanten nebeneinander bestehen. Route-Targets steuern, welcher Endpunkt welche Routen importiert. In Umgebungen mit einheitlichem VNI-Schema lassen sich beide aus der VNI automatisch ableiten, was die Konfiguration spürbar vereinfacht.
8. Datacenter oder Carrier: VXLAN, MPLS und SRv6
EVPN ist von der Datenebene entkoppelt, dieselbe BGP-Steuerung trägt verschiedene Kapselungen:
| Profil | Datenebene | Typischer Einsatz |
|---|---|---|
| EVPN-VXLAN (RFC 8365) | VXLAN über UDP-Port 4789 | modernes Rechenzentrum, Spine-Leaf-Fabric |
| EVPN-MPLS (RFC 7432) | MPLS-Labels | Carrier- und Service-Provider-Backbone |
| EVPN-SRv6 (RFC 9252) | IPv6-Segment-IDs | neue Carrier- und 5G-Transportnetze |
Isolation ist keine Verschlüsselung
EVPN trennt Mandanten sauber über VNIs und VRFs, verschlüsselt den Verkehr im Underlay aber nicht. Wo physischer Zugriff aufs Underlay nicht ausgeschlossen ist, kommen MACsec auf den Strecken oder herstellerspezifische verschlüsselte Tunnel hinzu.
9. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| MAC-Verteilung per BGP statt Fluten, skaliert auf große Fabrics | Hohe konzeptionelle Komplexität (BGP, VRF, VNI, IRB) |
| Aktiv/Aktiv-Multihoming nativ im Standard (ESI, DF-Election) | Empfindlich gegen Underlay-MTU; ein Gerät genügt für stille Verluste |
| ARP/ND-Suppression senkt Broadcast-Last deutlich | Verschlüsselt nicht; Vertraulichkeit braucht MACsec/IPsec |
| Eine Steuerebene für VXLAN, MPLS und SRv6 | Herstellerdetails (ESI-Erkennung, Auto-RT) weichen ab |
| Herstellerneutral standardisiert (IETF), auch in FRRouting | Neuere Erweiterungen (z. B. RFC 9722/9746) noch nicht überall umgesetzt |
Häufige Fragen zu EVPN
VXLAN ist die Datenebene, also die Kapselung, die Layer-2-Frames über ein IP-Netz transportiert. EVPN ist die Steuerebene darüber, die per BGP verteilt, hinter welchem Tunnelendpunkt welche MAC- und IP-Adresse erreichbar ist. VXLAN ohne EVPN müsste MAC-Adressen weiterhin per Fluten lernen.
Die VXLAN-Kapselung fügt rund 50 Byte (IPv4-Underlay) hinzu und fragmentiert nicht. Ist die Underlay-MTU zu klein, werden gekapselte Pakete still verworfen. Üblich ist daher eine Underlay-MTU von 9216 Byte, durchgängig auf allen Geräten, damit auch Hosts mit 9000-Byte-Frames ohne Fragmentierung durchkommen.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
EVPN im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.