Multicast VPN (mVPN): Grundkonzepte und typische Use-Cases

Multicast VPN (mVPN) ermöglicht Multicast-Verteilung über ein MPLS L3VPN, ohne dass der Provider-Core selbst „kundenspezifisches Multicast“ wie ein großes gemeinsames LAN behandeln muss. Stattdessen werden Multicast-Flows zwischen PEs über definierte Provider-Tunnel (P-tunnels) transportiert und die kundenspezifische Multicast-Control-Plane bleibt in der jeweiligen VRF. Das ist entscheidend für skalierbare Unternehmens-Use-Cases wie IPTV/Video, Finanzdaten (Market Data), Standort-Replikation, Telemetrie…

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…

QoS in MPLS L3VPN: EXP/TC Mapping sauber designen

QoS in MPLS L3VPN scheitert in der Praxis selten an fehlenden Queues, sondern an inkonsistentem Marking: Ein CE setzt DSCP, der PE mappt falsch auf EXP/TC, der Core behandelt die Bits anders, und am Egress kommt „Best Effort“ an. Sauberes EXP/TC Mapping ist deshalb ein Designproblem: Du definierst wenige, klare Service-Klassen, legst fest, wo klassifiziert…

Troubleshooting MPLS Blackholes: LFIB, CEF und Label Imposition prüfen

MPLS Blackholes sind besonders unangenehm, weil sie oft selektiv auftreten: Routing wirkt „gesund“, BGP/OSPF Nachbarn sind up, aber bestimmte Prefixes sind nicht erreichbar oder nur in eine Richtung. Der Grund liegt fast immer in einer Inkonsistenz zwischen Control Plane (RIB/BGP/LDP/SR) und Data Plane (CEF/FIB/LFIB). Ein klassischer Fall: Die IP-Route existiert, aber die Label-Imposition (Push) fehlt…

NAT64/DNS64 auf Cisco Routern: IPv6-only Clients zu IPv4 Services

NAT64 und DNS64 sind Übergangstechniken, mit denen IPv6-only Clients IPv4-only Services erreichen können. NAT64 übernimmt die eigentliche Protokoll- und Adressübersetzung zwischen IPv6 und IPv4, während DNS64 dafür sorgt, dass IPv6-only Clients für IPv4-Hosts eine „synthetische“ AAAA-Antwort erhalten. In der Praxis ist das ein sehr bewährtes Muster für IPv6-only WLANs, neue Campus-Segmente oder Container/Cloud-Umgebungen, in denen…

NPTv6 in der Praxis: Präfix-Translation sauber einsetzen

NPTv6 (Network Prefix Translation) ist eine IPv6-spezifische Präfix-Translation, die nicht wie NAT44/NAT64 mit Ports arbeitet, sondern nur das IPv6-Präfix umschreibt. Damit bleibt die Interface Identifier (Host-Teil) erhalten, und es entsteht keine zustandsbehaftete Port-Translation. In der Praxis nutzt man NPTv6 vor allem für Provider-Wechsel, Multi-Homing oder „renumbering-freundliche“ Designs: Intern verwendest du ein stabiles ULA- oder Unternehmenspräfix,…

IPv6 Routing Expert Guide: RA, ND, Guarding & Troubleshooting

IPv6-Routing-Probleme entstehen im Enterprise selten durch „OSPFv3 kaputt“, sondern viel häufiger am Rand: Router Advertisements (RA), Neighbor Discovery (ND) und fehlende Guardrails. Wenn RA falsch gesetzt ist, bekommen Clients den falschen Default Router. Wenn ND gestört ist, brechen On-Link-Kommunikation, SLAAC und Gateway-Auflösung. Und wenn RA/ND ungeschützt sind, können Rogue RAs, ND-Floods oder falsche Neighbor-Caches ganze…

Dual-Stack Design Patterns: Was im Betrieb wirklich stabil läuft

Dual-Stack ist in Enterprise-Netzen oft die stabilste Übergangsstrategie: IPv4 bleibt verfügbar, während IPv6 parallel produktiv genutzt wird. Die Realität im Betrieb ist jedoch: Dual-Stack verdoppelt nicht nur Adressen, sondern auch Fehlerpfade. Stabil wird es nur mit klaren Design-Patterns, die konsequent durchgezogen werden: einheitliche Default-Gateway-Logik, saubere RA/DHCPv6-Strategie, identische Routing-Topologie für v4/v6, konsistente Security-Policies und saubere Observability.…

CGNAT auf Cisco: Skalierung, Logging, Port Allocation Strategien

CGNAT (Carrier-Grade NAT) ist NAT im großen Stil: Viele private IPv4-Clients teilen sich einen begrenzten Pool öffentlicher IPv4-Adressen. In der Praxis ist CGNAT weniger ein „NAT-Feature“ als ein Betriebsprodukt: Skalierung (Sessions/Ports), deterministische Port-Zuteilung, Logging/Compliance und ein Design, das unter Last stabil bleibt. Auf Cisco-Plattformen (typisch IOS XE mit leistungsfähiger Data Plane) sind die wichtigsten Erfolgsfaktoren:…

RPKI für BGP auf Cisco: Route Origin Validation in der Praxis

RPKI (Resource Public Key Infrastructure) ist heute einer der wichtigsten Sicherheitsbausteine für BGP: Mit Route Origin Validation (ROV) prüfst du kryptografisch, ob der AS, der ein Prefix announced, dafür autorisiert ist. Damit reduzierst du das Risiko von Route Leaks und Hijacks deutlich – ohne komplizierte Filterlisten. In der Praxis ist RPKI kein „Allheilmittel“, sondern ein…