L2 Access + L3 Core: Wo die Grenze im Provider-Netz sinnvoll ist

Die Architektur „L2 Access + L3 Core“ ist in Provider-Netzen ein bewährtes Grundmuster, weil sie Skalierung, Betrieb und Fehlertoleranz häufig besser in Balance bringt als ein durchgängiges L2- oder ein „alles L3“-Design. Trotzdem ist die entscheidende Frage selten ob L2 oder L3, sondern wo die Grenze sinnvoll liegt: Welche Teile des Netzes dürfen Broadcast- und MAC-State sehen? Wo endet die L2-Failure-Domain? Wo beginnt die L3-Hierarchie mit Summarization, klaren Routingdomänen und stabilen Konvergenzmechanismen? Eine falsch gesetzte Grenze führt zu typischen Problemen: zu große Broadcast-Domänen, ARP/ND-Stürme, MAC-Table-Pressure und schwer erklärbare Loops auf der einen Seite – oder auf der anderen Seite unnötige Komplexität durch zu frühes Routing, zu viele VRFs, aufwendige Provisioning-Workflows und schwierige Service-Abbildungen. In modernen Telco-Umgebungen kommen weitere Faktoren hinzu: EVPN als skalierbares L2/L3-Control-Plane-Modell, Segment Routing, strengere Timing-/QoS-Anforderungen (z. B. im Mobile Transport) sowie Security Domains, die Management, Retail, Wholesale und Enterprise trennen müssen. Dieser Artikel erklärt, wie Sie die L2/L3-Grenze im Provider-Netz topologisch sauber setzen, welche Designpatterns sich in Access, Metro und Core bewährt haben und wie Sie Wachstum ermöglichen, ohne Routing-Chaos oder Komplexitäts-Explosion.

Warum die L2/L3-Grenze im Provider-Netz so wichtig ist

Layer 2 und Layer 3 haben unterschiedliche „Kosten“ im Betrieb. L2 ist in vielen Access-Szenarien praktisch, weil es einfache Übergaben ermöglicht (VLAN, QinQ, E-Line/E-LAN), aber es bringt State (MAC, ARP/ND) und Broadcast/Unknown-Unicast mit. L3 reduziert diese Flächen, bringt dafür aber Routingdomänen, IP-Planung, Summarization und häufig mehr Policy-Aufwand. Die Grenze definiert, wo diese Kosten anfallen – und wie groß die Failure Domain ist, wenn etwas schiefgeht.

• L2 Vorteile: einfache Übergabe, transparent für viele Kunden/Protokolle, oft gute Passung zu Access-Technologien.
• L2 Risiken: Broadcast-Domänen, MAC/IP-State, Loop-Risiken, Troubleshooting-Komplexität bei großen Flächen.
• L3 Vorteile: klare Domänengrenzen, Summarization, bessere Churn-Lokalisierung, stabilere Skalierung.
• L3 Risiken: mehr IP-Planung, mehr Protokoll-/Policy-Disziplin, mögliche Produktkomplexität bei L2-Services.

Leitprinzip: L2 dort, wo es Nutzen stiftet – L3 dort, wo es Stabilität bringt

Carrier-Grade Designs setzen L2 gezielt im Access ein und ziehen L3 so früh wie nötig, aber so spät wie sinnvoll. Die optimale Grenze liegt oft dort, wo Sie natürliche Aggregationspunkte und Failure Domains haben (Metro-Hubs/PoPs).

Typische Provider-Rollen: Access, Aggregation/Metro, Core, Edge

Die L2/L3-Grenze ist eng mit Rollenmodellen verknüpft. Provider-Netze sind hierarchisch: Access sammelt viele Endpunkte, Metro aggregiert und strukturiert, der Core transportiert, und Edges terminieren Services. Wenn Sie die Grenze passend zu Rollen setzen, werden Betrieb und Skalierung deutlich einfacher.

• Access: viele Anschlüsse, häufig L2-nahe Technologien (FTTH/OLT, HFC, Mobile Sites), hohe Portdichte.
• Metro/Aggregation: natürliche Kante für Domänenschnitt; hier können L2-Flächen beendet und L3-Hierarchie gestartet werden.
• Core: stabiler Transport, möglichst „langweilig“, wenig kundenspezifischer State.
• Service Edge: BNG/BRAS, PE, Internet Edge, Security Edge; hier werden Policies und Services terminiert.

Ein bewährtes Zielbild

Access kann L2 sein, Metro wird zum Übergabepunkt (L2->L3), und der Core bleibt L3 mit klarer Summarization. Services werden an Edges terminiert, nicht im Core.

L2 Access: Welche Gründe im Provider-Alltag wirklich zählen

L2 im Access hat reale Vorteile: Es passt zu vielen Zugangstechnologien, vereinfacht Wholesale-Übergaben (Bitstream, L2-Handover), und ermöglicht L2VPN-Produkte wie E-Line/E-LAN. Außerdem ist L2 für bestimmte Betriebsmodelle im Feld praktikabel, weil weniger IP-Planung auf jedem Access-Knoten nötig ist. Allerdings muss L2 im Access bewusst begrenzt werden: kleine Domänen, klare Schutzmechanismen, saubere Tagging-Standards.

• Produktfit: L2VPN, Wholesale Handover, transparente Übergaben für Enterprise.
• Access-Technik: OLT/DSLAM/Cell-Site Aggregation arbeitet oft VLAN-/QinQ-basiert.
• Provisioning: VLAN/QinQ-Modelle sind oft gut automatisierbar und in OSS/BSS etabliert.
• Risiko: L2-Domänen dürfen nicht unkontrolliert wachsen; sonst steigen Broadcast/ARP/ND und Loop-Risiken.

Blueprint-Regel: L2-Domänengröße ist eine harte Zahl

Definieren Sie maximale Domänengrößen (z. B. pro OLT-Cluster, pro Metro-Ring, pro EVPN-Instance). Ohne diese Grenze wächst L2 historisch – und wird zum Incident-Treiber.

L3 Core: Warum Provider den Kern „state-arm“ halten wollen

Ein L3-Core skaliert gut, weil er weniger broadcastlastigen State transportiert und weil Routing hierarchisch organisiert werden kann. Außerdem erlaubt L3 Core eine klare Trennung zwischen Transport und Service: Der Core kennt Pfade und Kapazität, aber nicht jedes Kundendetail. Das schützt die Control Plane, reduziert Routen-/MAC-Churn im Kern und verbessert die Planbarkeit von Konvergenzmechanismen (FRR/TI-LFA, BFD).

• Summarization: Aggregation von Präfixen reduziert RIB/FIB-Größe und Update-Last.
• Churn-Lokalisierung: Access-Events bleiben in Access/Metro, statt Core-weit sichtbar zu werden.
• Konvergenz: IGP/Segment Routing plus FRR/TI-LFA ist im L3-Core gut beherrschbar.
• Security Domains: L3 erleichtert Segmentierung (VRFs, Policies) und kontrollierte Leaks.

Designregel: Der Core soll keinen Kundenschatten tragen

Wenn der Core jedes VLAN, jede MAC und jedes kleine Access-Subnetz kennt, wird er zum Skalierungsproblem. Ein guter Core sieht nur aggregierte Routen und transportrelevante Informationen.

Wo die Grenze sinnvoll ist: Access->Metro als natürliche L2/L3-Kante

In vielen Provider-Netzen ist die optimale Grenze nicht am „allerletzten“ Access-Gerät und auch nicht erst im zentralen Core, sondern in der Metro-Aggregation: Dort gibt es ohnehin Knoten mit höherer Qualität (Strom, Klima, Monitoring), mehr Kapazität und bessere Redundanz. Diese Knoten sind prädestiniert, um L2-Flächen zu terminieren und in L3 zu überführen.

• Natürliche Aggregationspunkte: Metro-Hubs bündeln mehrere Access-Ringe/OLT-Cluster/Sites.
• Bessere Failure Domain Kontrolle: Ein Metro-Cluster ist eine sinnvolle Domäne für L2-Scopes.
• Betriebsfähigkeit: Hubs sind leichter zu überwachen und zu warten als Feldstandorte.
• Service-Integration: Von hier aus sind BNG/PE/Edges sinnvoll erreichbar, ohne Hairpinning zu erzwingen.

Ein praktisches Pattern

L2 im Access (VLAN/QinQ) → L2-Termination/EVPN oder klassisches Bridging im Metro-Hub → L3-Weiterleitung in den Core. So bleibt L2 lokal, und L3 übernimmt Skalierung.

EVPN als „Grenztechnologie“: L2/L3 sauber kombinieren

EVPN hat die klassische L2/L3-Debatte verändert, weil es L2-Services über ein BGP-Control-Plane-Modell transportiert und damit viele L2-Probleme (Flooding, unkontrolliertes Learning) reduziert. EVPN ist besonders stark, wenn Sie L2 im Access brauchen, aber den Core „L3-like“ betreiben möchten. EVPN kann somit als kontrollierte L2-Schicht fungieren, die an definierten Kanten in L3 (VRF/IRB) übergeht.

• Kontrolliertes Learning: MAC/IP werden via BGP verteilt statt rein datengetrieben zu fluten.
• Anycast Gateway: L3-Gateway nahe am Edge/Leaf reduziert L2-Stretch-Bedarf.
• Multi-Tenant: VRFs plus EVPN ermöglichen saubere Isolation und kontrollierte Leaks.
• Scope-Regeln: EVPN-Domänen müssen trotzdem begrenzt werden; L2 bleibt stateful.

Designregel: EVPN ist kein Freifahrtschein für globale L2-Flächen

EVPN macht L2 besser kontrollierbar, aber nicht „kostenlos“. Große Domänen erzeugen MAC/IP-State und erhöhen Komplexität. Setzen Sie EVPN als kontrollierte Brücke zwischen Access-L2 und Core-L3 ein, nicht als globales Stretch-Tool.

Entscheidungskriterien: Was die Grenze in der Praxis verschiebt

Ob die L2/L3-Grenze eher näher am Access oder näher am Core liegt, hängt von wenigen stabilen Kriterien ab. Diese Kriterien sollten Sie vor dem Design klar priorisieren, statt später mit Ausnahmen zu kämpfen.

• Produktportfolio: Viele L2-Produkte/Wholesale-Handovers sprechen für mehr L2 am Rand, aber mit klaren Scopes.
• Netzgröße und Wachstum: Je größer das Netz, desto stärker profitiert es von frühem L3-Schnitt und Summarization.
• OPEX und Automatisierung: Wenn Automatisierung stark ist, kann L3 früher sinnvoll sein; wenn nicht, ist L2 im Feld oft pragmatischer.
• Timing/QoS-Anforderungen: Mobile Transport und Echtzeitprofile können kurze, stabile Pfade bevorzugen; Grenzsetzung muss Störfallpfade berücksichtigen.
• Security Domains: Management, Retail, Wholesale, Enterprise benötigen klare Grenzen; L3/VRF hilft, L2 muss strikt segmentiert bleiben.

Eine nützliche Faustregel

$\mathrm{Komplexität}\approx \mathrm{L2\_Scope}+\mathrm{Policy\_Varianten}+\mathrm{Standortanzahl}$

Wenn Standortanzahl und Policy-Varianten wachsen, sollten Sie L2-Scope reduzieren und die L3-Grenzen klarer ziehen.

Provisioning und Betrieb: VLAN/QinQ vs. IP/VRF als Betriebsmodell

Die L2/L3-Grenze beeinflusst direkt, wie Sie Services provisionieren. L2-basierte Modelle nutzen häufig VLAN/QinQ, während L3-basierte Modelle stärker VRFs, IP-Pools und Routingpolicies einsetzen. Beide können automatisiert werden, aber sie erfordern unterschiedliche Tooling- und Governance-Reife.

• L2-Provisioning: VLAN- und QinQ-Templates, einfache Handover-Logik, dafür Risiko von VLAN-Sprawl.
• L3-Provisioning: VRF-/IPAM-Templates, Summarization, Route-Policies, dafür oft mehr initiale Planungsarbeit.
• Change-Risiko: L2-Änderungen können großflächige Broadcast-Effekte haben; L3-Änderungen können Routing/Policy beeinflussen.
• Troubleshooting: L3 ist oft deterministischer, L2 kann in großen Domänen schwerer zu entstören sein.

Blueprint-Regel: Provisioning folgt der Grenze

Wenn Sie L3 früh ziehen, brauchen Sie IPAM- und Policy-as-Code-Reife. Wenn Sie L2 länger ziehen, brauchen Sie strikte VLAN/QinQ-Standards und Scope-Limits. Chaos entsteht, wenn weder das eine noch das andere konsequent umgesetzt ist.

Störfallverhalten: N-1, Umwege, MTU und Blackhole Prevention

Die Grenze muss auch im Failover funktionieren. Ringe, Meshes und Metro-Hubs erzeugen im Störfall andere Pfade. Wenn L2- und L3-Profile auf Ersatzpfaden inkonsistent sind (MTU, Tagging, Policies), entstehen Blackholes und scheinbar „mystische“ Drops. Besonders bei QinQ, PPPoE und Overlays ist MTU end-to-end kritisch.

• N-1 Kapazität: Wenn L2 im Ring-Failover die gesamte Last über einen Pfad drückt, entsteht Congestion.
• MTU-Profile: Tagging/Encapsulation muss auch im Ersatzpfad passen; sonst droppen große Pakete.
• PMTUD/ICMP: Kontrolliert ermöglichen, um Blackholes zu verhindern.
• Konvergenz: FRR/TI-LFA und stabile Timer reduzieren Impact bei L3-Schnittstellen.

Ein häufiger Fehler: Grenze nur im Normalbetrieb validiert

Viele Designs sehen sauber aus, bis ein Link ausfällt. Deshalb müssen Failover-Tests Bestandteil des L2/L3-Grenzdesigns sein: Pfadwechsel, MTU, QoS, ARP/ND-Verhalten und Session-Stabilität messen.

Security Domains: Warum L3-Grenzen Segmentierung vereinfachen

Provider müssen häufig Retail, Wholesale, Enterprise und Management sauber trennen. L3/VRF-Grenzen sind dafür sehr geeignet, weil sie klare Policies und kontrollierte Leaks erlauben. L2 kann ebenfalls segmentiert werden, aber große L2-Flächen erhöhen das Risiko unbeabsichtigter Sichtbarkeit und erschweren Audit. Deshalb ist ein häufiges Ziel: L2 im Access für Übergabe/Produkte, L3/VRF ab Metro/Edge für konsequente Domain-Trennung.

• Management Isolation: Management-VRF/OOB, Jump-Zones, keine Adminpfade in Service-VLANs.
• Wholesale Handover: Definierte Policy Points, strikte Filter und Limits.
• Retail Edge: CGNAT/DDoS/Security Chains in eigener Domain, klarer Steering-Pfad.
• Enterprise VRFs: Hub-and-Spoke für Shared Services statt VRF-Mesh; kontrollierte Leaks.

Designregel: Domains sind wichtiger als Technologie

Ob L2 oder L3: Entscheidend ist, dass Domains klar sind, Leaks kontrolliert sind und Betriebspfade auditierbar sind. L3 erleichtert das meistens, L2 erfordert strengere Disziplin.

Observability: Wo die Grenze liegt, bestimmt auch die Messbarkeit

Die L2/L3-Grenze beeinflusst, wie gut Sie Probleme lokalisieren können. L3 liefert oft klarere Metriken (Routen, Pfade, Latenz per Hop), während L2-Probleme sich in MAC-/ARP-/ND-State und Broadcastverhalten zeigen. Ein professionelles Design definiert daher Mindest-Telemetry für beide Seiten der Grenze.

• L2-KPIs: MAC-Table-Auslastung, ARP/ND-Raten, Unknown-Unicast/Broadcast-Stats, Loop-Guard-Events.
• L3-KPIs: IGP/BGP-Events, SPF/Convergence, FRR-Aktivierungen, Pfad-Latenz/Loss.
• QoS-KPIs: Queue-Drops pro Klasse an Engpässen, LAG-Member-Hotspots.
• Change-Korrelation: Wartungen und Rollouts mit KPIs korrelieren, um Drift früh zu erkennen.

Evidence-by-Design: Die Grenze muss „beweisbar“ funktionieren

Wenn Sie zeigen können, dass ARP/ND-Last lokal bleibt, dass der Core nur Summaries sieht und dass Failoverpfade MTU/QoS-konform sind, wird die Grenzentscheidung operational belastbar.

Praktische Leitlinien: Wo die Grenze im Provider-Netz sinnvoll ist

• L2 im Access begrenzen: Kleine Domänen, klare VLAN/QinQ-Standards, Loop- und Storm-Guards, Scope-Limits.
• L3 am Metro-Hub starten: Metro/Aggregation als natürliche L2/L3-Kante, mit klaren Failure Domains und Summarization.
• Core L3 und „langweilig“: Transport ohne kundenspezifischen State, FRR/TI-LFA, konservatives Convergence Engineering.
• EVPN gezielt einsetzen: Als kontrollierte L2/L3-Brücke, Anycast Gateway nutzen, L2-Stretch nur als Ausnahme.
• Provisioning standardisieren: Wenige Blueprints, Policy-as-Code, Ausnahmen streng steuern.
• Störfallfähigkeit testen: N-1 Kapazität, MTU/PMTUD, QoS und Pfadwechsel regelmäßig validieren.
• Security Domains konsequent: VRFs für Retail/Wholesale/Enterprise/Management, kontrollierte Leaks über Hubs.
• Observability verpflichtend: L2- und L3-KPIs, Queue-/Member-Telemetry, Change-Korrelation und Trendanalyse.