MPLS L3VPN Adressierung: Customer- und Provider-IP sauber planen

Eine saubere MPLS L3VPN Adressierung entscheidet im Telco-Umfeld darüber, ob ein L3VPN-Produkt langfristig skalierbar bleibt oder ob Betrieb und Fehlersuche mit jedem neuen Kunden komplizierter werden. In einer MPLS-L3VPN-Architektur treffen zwei Welten aufeinander: der Provider-IP-Raum (Transport/Backbone, IGP, Loopbacks, P2P-Links, Route Reflectors, PE-Infra) und der Customer-IP-Raum (Kundennetze in VRFs, CE-PE-Übergaben, ggf. Overlapping Addressing). Beide müssen getrennt, aber sinnvoll aufeinander abgestimmt geplant werden. Typische Probleme entstehen, wenn Provider- und Customer-Adressen vermischt werden, wenn CE-PE-Übergaben ohne Standard aus beliebigen Pools bedient werden oder wenn Summarisierung und VRF-Prefix-Strategie nicht von Anfang an mitgedacht werden. Das Ergebnis sind unnötig große Routing-Tabellen, fragile Policies, versehentliches Route-Leaking, schwierige Migrationen und lange Entstörzeiten. Dieser Artikel zeigt praxisnah, wie Sie Customer- und Provider-IP in MPLS L3VPN sauber planen – mit Hierarchien nach Region/PoP, Best Practices für /31 und /127 auf P2P-Links, Loopback-Design, VRF-Prefix-Container, Umgang mit überlappenden Kundennetzen, sowie Dokumentations- und Governance-Regeln, die Wildwuchs verhindern.

Warum Adressplanung in MPLS L3VPN anders ist als „normales Routing“

In MPLS L3VPN sind PEs (Provider Edges) die Service-Termination: Hier liegen VRFs, hier werden Kundennetze via eBGP/OSPF/static von CEs gelernt, und hier werden sie per MP-BGP (VPNv4/VPNv6) über das Provider-Netz verteilt. Das Provider-Backbone selbst bleibt idealerweise „kundennetzfrei“: Der Core kennt nur Provider-Infrastrukturprefixe und Labels. Genau diese Trennung ist der Kern der Skalierbarkeit – und muss sich in der Adressplanung widerspiegeln.

• Provider-Raum: stabil, aggregierbar, wenige Changes, stark standardisiert.
• Customer-Raum: dynamischer, viele Mandanten, potenziell überlappende Prefixe, produktgetrieben.
• PE als Schnittstelle: saubere CE-PE-Übergaben, klare VRF-Prefix-Container, kontrolliertes Leaking.

Die drei Adressdomänen, die Sie trennen müssen

Für einen robusten L3VPN-Betrieb sollten Sie drei Adressdomänen explizit trennen. Viele Probleme entstehen genau dann, wenn diese Grenzen verwischen.

• Transport-/Backbone-Domäne: Core/Metro/PoP-Transport, IGP, P2P-Links, Loopbacks, ggf. TE/SR.
• Service-/PE-Infra-Domäne: PE-Loopbacks (Control Plane), RR-Loopbacks, Management/OAM, ggf. spezielle Service-Interfaces.
• Customer-/VRF-Domäne: Kundennetze, CE-PE-Linknetze, VRF-interne Services, Shared Services (kontrolliert).

Provider-IP sauber planen: Hierarchie Region → Metro → PoP → Funktion

Der Provider-IP-Raum ist Ihr Fundament. Er sollte so geplant sein, dass Summarisierung funktioniert und der Core wenige, stabile Prefixe sieht. Das erreicht man mit einem Container-Modell, das die Topologie abbildet. Innerhalb jedes Containers werden Funktionsblöcke getrennt geführt: Loopbacks, P2P, Management, Infrastruktur-Services.

• Region-Container: zusammenhängende Prefix-Blöcke pro Region, um regionale Summaries zu ermöglichen.
• Metro-/Cluster-Container: Unterblöcke pro Metro-Cluster oder Aggregationsbereich.
• PoP-Container: fester Block pro Standort/PoP, aus dem lokale Infrastruktur abgeleitet wird.
• Funktionale Blöcke: Loopbacks, P2P, Management, Services getrennt und dokumentiert.

Container-Regel: keine Quer-Vergaben

Wenn ein PoP „mal schnell“ Link-Subnetze aus einem fremden Container nutzt, bricht Aggregation. Das führt zu spezifischen Routen und langfristig zu Routing-Wildwuchs. In L3VPN-Backbones ist das besonders teuer, weil viele Knoten betroffen sind.

Loopbacks im Provider-Netz: stabile Identitäten für PE, P und RR

Loopbacks sind im MPLS L3VPN zentral, weil iBGP/MP-BGP-Sessions, MPLS/Transportmechanismen und Monitoring häufig darauf basieren. Best Practice ist, Loopbacks in dedizierten, filterbaren Bereichen zu halten und nach Rolle zu trennen.

• PE-Loopbacks: stabile Endpunkte für iBGP/MP-BGP, oft auch für SR/LDP-Identitäten.
• P-Router-Loopbacks: Core-Identitäten, sehr stabil und selten geändert.
• RR-Loopbacks: dedizierter Bereich, erleichtert Policies und Whitelists.
• IPv4: /32 als Standard; IPv6: /128 als Standard.

P2P-Links im Backbone: /31 und /127 als Default

Backbone-Links sind in Provider-Netzen fast immer Punkt-zu-Punkt. Deshalb sind /31 (IPv4) und /127 (IPv6) bewährte Standards. Sie sparen IPv4, reduzieren bei IPv6 die Neighbor-Domain und machen Link-Adressierung konsistent.

• IPv4 /31: zwei nutzbare Adressen für zwei Endpunkte, ideal für Core/Metro/PoP-Uplinks.
• IPv6 /127: klare P2P-Domäne, übersichtlicher Betrieb, weniger ND-Risiken.
• Separater P2P-Block: P2P-Netze nie mit Loopbacks oder Services mischen.

Rechenlogik zur Einordnung

IPv4-Subnetze haben vereinfacht $2^h–2$ nutzbare Hosts (mit h Hostbits). Ein /30 hat zwei nutzbare Hosts, aber zwei Adressen Overhead. Für P2P ist /31 das präzisere Modell: exakt zwei Adressen für exakt zwei Endpunkte.

Management und OAM: nicht „irgendwo“, sondern bewusst getrennt

In MPLS-Backbones ist Management-Zugriff kritisch. Best Practice ist eine eigene Management-Zone, idealerweise in einer Management-VRF, mit dedizierten Prefixen. Damit verhindern Sie, dass Management unbeabsichtigt aus Service- oder Kundendomänen erreichbar wird.

• Management-VRF: separate Routing-Tabelle, minimierte Exposition.
• Dedizierte Management-Prefixe: pro Region/PoP strukturiert.
• Jump-Hosts/Bastion: Zugriff auf PEs/RRs/Core nur über definierte Sprungpunkte.
• Auditierbarkeit: AAA, Syslog und Telemetrie als Teil des Betriebsmodells.

Customer-IP sauber planen: VRF-Prefix-Container statt „freier Pool“

Im Customer-Bereich liegen die meisten Changes. Deshalb braucht es dort besonders klare Standards. Ein bewährtes Modell ist, pro VRF (oder pro VRF-Klasse) einen eigenen Prefix-Container zu definieren und innerhalb dieses Containers Funktionsblöcke zu trennen: CE-PE-Links, Kunden-LANs, VRF-interne Services, ggf. Transit zu Shared Services.

• VRF-Container: definierter Prefix-Bereich, aus dem diese VRF bedient wird (insbesondere für providerseitige Netze).
• Customer Access: CE-PE-Übergaben und Kundensegmente in klaren, dokumentierten Blöcken.
• Service/Plattform: Firewall-Interfaces, SD-WAN-Hubs, Logging innerhalb der VRF getrennt.
• Transit/Shared Services: eigene Leak-Zonen, nicht „wildes“ VRF-zu-VRF Routing.

CE-PE-Linknetze: klein, standardisiert, konfliktarm

Die CE-PE-Übergabe ist die häufigste „Adressierungsstelle“ in L3VPN. Wenn diese Links ohne Standard gebaut werden, entstehen schnell Konflikte und unübersichtliche Dokumentation. Der Schlüssel ist, ein konsistentes Modell zu wählen und es pro Produktlinie zu standardisieren.

• P2P-Übergaben: häufig /31 (IPv4) oder /30 als dokumentierte Ausnahme; IPv6 häufig /127 oder /64, je nach CPE-Policy.
• Separater Übergabepool: CE-PE-Links aus einem eigenen Bereich, getrennt von Backbone-P2P und Kundennetzen.
• Kundenkompatibilität: manche CPEs oder Kundenvorgaben beeinflussen Präfixlängen – Ausnahmen sollten kontrolliert sein.
• Dokumentationspflicht: Service-ID, Standort, VRF, Interface, Präfix, Gegenstelle, Status.

Overlapping Customer Addressing: erlauben, aber beherrschen

Ein großer Vorteil von MPLS L3VPN ist, dass Kundennetze in unterschiedlichen VRFs überlappen dürfen (z. B. mehrere Kunden nutzen 10.0.0.0/8). Das ist technisch möglich, aber operativ nur dann sicher, wenn Provider- und Shared-Service-Prefixe sauber getrennt sind und Route-Leaking strikt kontrolliert erfolgt.

• Overlapping nur zwischen VRFs: innerhalb einer VRF dürfen Prefixe nicht kollidieren.
• Provider-Services nicht in Kundenräumen: Shared Services, Management und Plattformnetze sollten eigene, nicht überlappende Bereiche nutzen.
• Controlled Leaking: wenn Kunden auf Shared Services zugreifen, dann über definierte Leak-Zonen oder Firewalls.
• NAT/Proxy als Werkzeug: wenn Overlap den Zugriff auf gemeinsame Ziele verhindert, kann Übersetzung nötig sein.

Route Targets und Policy-Design: Adressräume als Vereinfacher

Route Targets und BGP-Policies sind der „VPN-Kleber“ in MPLS L3VPN. Sie werden deutlich einfacher, wenn Adressräume pro VRF strukturiert sind. Dann können Sie Prefix-Listen, Communities und Leak-Regeln auf wenige Container-Prefixe beziehen, statt auf tausende Einzelnetze.

• VRF-Container als Policy-Anker: Filter und Export/Import-Regeln werden nachvollziehbar.
• Shared-Services-VRF: definierte Route Targets für kontrolliertes Leaking.
• Segmentierung nach Produkt: Business, Wholesale, Internet Access – getrennte VRF-Klassen und Prefix-Strategien.

Summarisierung im L3VPN-Kontext: Core klein halten, VRFs beherrschbar machen

Auch wenn der MPLS-Core keine Kundennetze routen muss, wachsen PEs, RRs und Policy-Tabellen mit der Zahl der VRFs und Prefixe. Summarisierung bleibt deshalb relevant: weniger spezifische Prefixe in VRFs, bessere regionale/PoP-Strukturen für providerseitige Netze und kontrollierte Aggregate für kundenseitige Bereiche, wo sinnvoll.

• Provider-Summaries: Region/PoP-Container für Loopbacks, P2P und Management als stabile Summaries.
• Customer-Summaries: wo Kunden adressmäßig strukturiert sind, können Aggregates in VRFs helfen.
• Reserve bewusst planen: Summaries können Reservebereiche überdecken; Nullroutes helfen als Schutznetz.

Dokumentation und Governance: Ohne IPAM wird L3VPN teuer

MPLS L3VPN skaliert technisch sehr gut – organisatorisch nur dann, wenn Adressvergabe und VRF-Objekte sauber gemanagt werden. Ein IPAM/CMDB-gestütztes Modell mit Pflichtfeldern verhindert Doppelvergaben, Drift und vergessene Services.

• Pflichtfelder VRF: VRF-Name/ID, Owner (Team/Role), Produktklasse, Route Targets, Scope (Region/PoP), Lifecycle.
• Pflichtfelder Prefix: VRF, Funktion (Access/Service/Mgmt/Transit), Standort/PoP, Status, Reserve-Tag.
• Pflichtfelder CE-PE: Service-ID, CE/PE-Interfaces, Präfix, Adressen, CPE-Anforderungen, Tests.
• Compliance: Container-Verstöße, falsche Präfixlängen, ungenutzte/deprecated Prefixe regelmäßig prüfen.

Typische Fehlerbilder in der MPLS L3VPN Adressierung

• Provider und Customer vermischt: Shared Services im Kundenraum – führt zu Overlap-Problemen und Security-Risiken.
• CE-PE ohne Standard: wechselnde Präfixlängen und Pools – erhöht Fehlerquote und MTTR.
• Quer-Vergaben: Prefixe aus falschen Regionen/PoPs – bricht Aggregation und macht Policies komplex.
• Route-Leaking „wild“: direkte VRF-zu-VRF Leaks ohne zentrale Shared-Services-Strategie.
• IPv6 ohne Struktur: „genug Adressen“ führt zu Unordnung – IPv6 genauso hierarchisch planen.
• Lifecycle vergessen: alte VRFs/Prefixe bleiben aktiv – Decommission-Prozess fehlt.

Praxis-Checkliste: Customer- und Provider-IP in MPLS L3VPN sauber planen

• Drei Domänen trennen: Provider-Transport, PE-Infra/Management, Customer/VRF.
• Provider-Hierarchie: Region → Metro → PoP → Funktion, mit Container-Regel.
• Loopbacks standardisieren: IPv4 /32 und IPv6 /128 in dedizierten, rollenbasierten Bereichen.
• P2P standardisieren: IPv4 /31 und IPv6 /127 in separaten P2P-Blöcken.
• VRF-Prefix-Container: pro VRF oder VRF-Klasse definierte Bereiche mit Funktionsblöcken.
• CE-PE-Übergaben standardisieren: dedizierte Übergabepools, klare Präfixregeln, dokumentierte Ausnahmen.
• Overlap kontrollieren: Kundenoverlap zwischen VRFs zulassen, Provider-/Shared-Service-Räume getrennt halten.
• Shared Services zentralisieren: Shared-Services-VRF, kontrolliertes Leaking via Prefix-Listen und klare RTs.
• IPAM/CMDB verpflichtend: Pflichtfelder, Statusmodell, Audit-Trails, Compliance-Checks.

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.