Carrier-of-Carriers / CSC: Provider-Szenario im Enterprise-Kontext erklärt

Carrier-of-Carriers (CoC) bzw. Carrier Supporting Carrier (CSC) ist ein MPLS-Provider-Design, bei dem ein „Backbone-Provider“ (P-Provider) einem „Kunden-Provider“ (C-Provider) Transport bereitstellt, sodass der C-Provider eigene L3VPN-Services über die Infrastruktur des P-Providers anbieten kann. Im Gegensatz zu einem normalen Enterprise-L3VPN ist der „Kunde“ hier selbst ein Provider mit eigenen VRFs, eigenen Route Targets und oft eigenen Kunden (Endkunden). Für Enterprise-Kontexte ist CSC relevant, wenn du ein unternehmensinternes Backbone wie einen Provider betreibst (z. B. globale Konzerne, Multi-Tenant-IT, Shared Services) oder wenn du als Managed Service Provider Enterprise-Kunden weiterverkettete Provider-Services anbietest. Dieser Artikel erklärt die Konzepte, die typischen Betriebsmodi und die wichtigsten Design-Fallstricke.

Begriffe und Rollen: P-Provider, C-Provider, PE, CE

In CSC gibt es zwei „Provider-Ebenen“. Der P-Provider stellt MPLS-Transport bereit. Der C-Provider nutzt diesen Transport, um eigene VPNs (für seine Kunden) zu bauen. Dadurch entsteht eine Provider-Kette.

• P-Provider: Backbone, bietet MPLS-Transport (sieht C-Provider als „Kunde“)
• C-Provider: „Kunde“ des P-Providers, aber selbst Provider für Endkunden
• PE (P-Provider): Provider Edge im Backbone
• CE (C-Provider): Sicht des P-Providers, aber im C-Provider oft ein PE für Endkunden

Warum CSC? Das Kernproblem ohne CSC

Wenn ein Provider seine Services über einen anderen Provider transportieren will, braucht er Mandantentrennung und End-to-End Transport, ohne dass der P-Provider alle Endkunden-Routen kennen oder kontrollieren muss. CSC trennt Verantwortlichkeiten: P-Provider transportiert, C-Provider steuert Services.

• C-Provider behält Kontrolle über eigene VPN-Policy (RD/RT, VRFs)
• P-Provider muss keine Endkunden-VPNv4 Routen des C-Providers tragen
• Skalierung: weniger State und weniger Trust-Anforderungen im P-Core

Enterprise-Kontext: Wann CSC „wie ein Enterprise-Problem“ aussieht

Auch ohne echtes Telco-Provider-Business kann CSC-Denke in Enterprises sinnvoll sein, wenn du organisatorisch getrennte „Netzdomänen“ hast: z. B. Corporate IT als Backbone-Provider für Business Units, oder ein Konzern betreibt eine interne WAN-Plattform für Tochtergesellschaften.

• Globale Konzerne: interne WAN-Plattform als „Provider“
• Shared Services: zentrale IT stellt Transport und Standards bereit
• Managed Services: MSP betreibt Underlay, Kunde betreibt Overlay-VPNs

CSC Betriebsmodelle: Die zwei gängigen Varianten

In der Praxis unterscheidet man vor allem, ob der P-Provider die VPN-Routen (VPNv4/v6) des C-Providers sieht oder ob er nur Transport liefert. Je weniger der P-Provider sieht, desto stärker ist die Trennung – und desto mehr „Overlay“ liegt beim C-Provider.

• Modell A: P-Provider liefert nur Transport (C-Provider kapselt/steuert selbst)
• Modell B: P-Provider unterstützt bestimmte VPN-Funktionalität (mehr Integration)

Technischer Kern: Was wird zwischen P- und C-Provider ausgetauscht?

Das zentrale Design-Element ist die PE-CE Schnittstelle zwischen P- und C-Provider. Dort werden entweder nur „Transport-Labels“ ausgetauscht (klassischer Transport-Fokus) oder zusätzlich BGP-basierte Informationen (je nach CSC-Variante). In vielen Designs wird dafür BGP (und ggf. BGP-LU) genutzt.

• IGP bleibt im P-Core (C-Provider wird nicht Teil des P-IGP)
• BGP kann als Interconnect dienen (IPv4/IPv6, labeled-unicast)
• MPLS im P-Core transportiert Traffic zwischen Interconnect-Punkten

Policy und Sicherheit: Trust Boundary ist der eigentliche Mehrwert

CSC ist nicht nur Skalierung, sondern auch Trust Boundary: Der P-Provider soll nicht beliebige Kundensignale „durchreichen“, und der C-Provider soll nicht den P-Core destabilisieren. Deshalb sind Filter, Limits und klare Schnittstellenregeln Pflicht.

• Max-Prefix und strikte Prefix-Filter auf Interconnect-BGP
• Keine unkontrollierte Redistribution zwischen Domänen
• CoPP/Control Plane Schutz auf P-Provider PEs
• RT-Governance bleibt beim C-Provider, P-Provider behandelt es als „payload“

Typische Use-Cases: Wo CSC in der Praxis auftaucht

CSC sieht man klassisch in Providerketten, ist aber auch in „Plattform-IT“ Konstrukten wiederzufinden. Es passt immer dann, wenn ein Betreiber Transport als Service anbietet und ein anderer Betreiber darauf eigene VPN-Services liefert.

• Wholesale/Backhaul: Carrier A nutzt Backbone von Carrier B
• MSP/Enterprise: MSP liefert MPLS-Transport, Kunde betreibt eigene VPNs
• Multi-Tenant Konzern: zentrale WAN-Plattform, dezentrale VRF-/Policy-Verantwortung

Operational Pitfalls: Was in CSC-Designs häufig schiefgeht

Die Fehler sind meist Governance- und Schnittstellenprobleme: zu viel Vertrauen an der Grenze, unklare Ownership und fehlende Limits. Das kann zu Route Leaks, Update Storms oder schwer debuggbaren Path-Asymmetrien führen.

• Fehlende Outbound Whitelist → Route Leaks zwischen Providern
• Kein Max-Prefix → Prefix-Explosion reißt Sessions/Control Plane
• Unklare MTU/Label-Stack Planung → Drops im Transport
• Unklare Verantwortung: wer debuggt was (P oder C)?

Debugging-Ansatz: Layering strikt einhalten

CSC debuggt man erfolgreich nur mit strikter Ebenentrennung: erst P-Provider Transport (IGP/MPLS), dann Interconnect (BGP), dann C-Provider Overlay (VPN/VRF). Wer Ebenen mischt, verliert Zeit.

• P-Layer: IGP Reachability, MPLS Forwarding, LDP/SR Health
• Interconnect: BGP State, Prefix-Counts, Policies, Max-Prefix
• C-Layer: VRFs, RD/RT, VPNv4/v6, Customer Policies

Command Pack (P-Layer)

show ip route <remote-pe-loopback>
show mpls interfaces
show mpls forwarding-table
traceroute mpls ipv4 <remote-pe-loopback>

Command Pack (Interconnect)

show ip bgp summary
show ip bgp neighbors <peer>
show ip bgp neighbors <peer> advertised-routes
show logging | include BGP|MAXPFX

Mini-Template: Interconnect-BGP mit Guardrails (Pattern)

Dieses Pattern zeigt die Grundidee für eine harte Interconnect-Grenze: Session schützen, Prefixes begrenzen, Policies erzwingen. Die konkreten Prefixes/ASNs hängen vom Vertrag zwischen P und C ab.

ip prefix-list PL_IC_ALLOWED seq 10 permit 10.255.0.0/16 le 32
ip prefix-list PL_ANY seq 5 permit 0.0.0.0/0 le 32
route-map RM_IC_OUT permit 10

match ip address prefix-list PL_IC_ALLOWED

route-map RM_IC_OUT deny 100

match ip address prefix-list PL_ANY
router bgp 65000

neighbor 203.0.113.1 remote-as 65100

neighbor 203.0.113.1 maximum-prefix 5000 90 restart 5

neighbor 203.0.113.1 route-map RM_IC_OUT out

Wann CSC die falsche Wahl ist

Wenn du nur „ein normales Enterprise-WAN“ mit VRFs brauchst und keine zweite Provider-Ebene wirklich existiert (keine getrennte Ownership, keine Service-Provider-Anforderungen), ist CSC oft Overkill. Dann ist klassisches L3VPN (oder SD-WAN Overlay) betrieblich einfacher.

• Keine echte Provider-/Tenant-Trennung → L3VPN reicht
• Keine Notwendigkeit für „Provider-Kette“ → CSC erhöht Komplexität
• Fehlende Betriebsmannschaft/Tooling → CSC ist riskant

Quick-Runbook: CSC Incident Isolation

Diese Sequenz trennt Transport, Interconnect und Overlay schnell – der wichtigste Schritt, um CSC-Störungen effizient zu lösen.

! P-Provider Transport
show ip route <remote-pe-loopback>
show mpls forwarding-table
! Interconnect

show ip bgp summary

show ip bgp neighbors  | include Prefix|Last reset|state
! C-Provider Overlay (Beispiel)

show ip bgp vpnv4 all summary

show running-config | section vrf definition

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.