IP-Design für 5G Core: SBA, Interfaces und Naming/Adressierung

Ein sauberes IP-Design für 5G Core entscheidet darüber, ob Ihre Core-Plattform im Alltag stabil, sicher und skalierbar betrieben werden kann. Mit 5G wird der Core stärker softwaregetrieben: Die Service Based Architecture (SBA) setzt auf HTTP/2-basierte Service-Kommunikation, Service Discovery (z. B. über NRF), dynamische Skalierung (Cloud-native Deployments, häufig Kubernetes) und eine klare Trennung zwischen Control Plane und User Plane. Genau dadurch verschiebt sich der Schwerpunkt der Adressierung: Statt weniger „großer“ Schnittstellen mit statischen IPs haben Sie viele Network Functions (NFs), Services, Pods, Service-IPs, Load-Balancer-Endpunkte, Anycast- oder VIP-Adressen, DNS-Namen und Security-Zonen. Gleichzeitig bleiben klassische Telco-Anforderungen bestehen: deterministisches Routing, saubere Segmentierung (VRFs/VLANs), Filterbarkeit, Observability (OAM), Compliance-Logging und reproduzierbare Prozesse. Wer hier mit „ein paar Netzen im Rechenzentrum“ startet, landet schnell in Wildwuchs: unklare Prefix-Zuständigkeiten, überlappende RFC1918-Bereiche, unbeherrschbare ACLs, unsaubere MTUs, instabile Service-Erreichbarkeit oder Troubleshooting, das an fehlenden Naming-Standards scheitert. Dieser Beitrag zeigt praxisnah, wie Sie SBA, Interfaces sowie Naming/Adressierung im 5G Core so designen, dass neue Standorte, zusätzliche Slices, neue DNNs und wachsende UPF-Kapazitäten ohne Neuaufbau des Adressplans integriert werden können.

Service Based Architecture und ihre Auswirkungen auf IP-Adressierung

Die SBA bringt zwei Konsequenzen mit, die Ihr IP-Design direkt beeinflussen. Erstens: Viele Control-Plane-Kommunikationen laufen nicht mehr über „klassische“ Punkt-zu-Punkt-Interfaces, sondern über serviceorientierte HTTP(S)-Verbindungen zwischen NFs (z. B. AMF, SMF, PCF, UDM). Zweitens: Skalierung wird dynamischer, wodurch Endpunkte nicht zwingend als einzelne, statische IPs erscheinen, sondern als Services hinter Load Balancern oder Service-Mesh-Komponenten.

• NF-zu-NF Kommunikation: SBA-Services sind oft über DNS/FQDN und virtuelle Service-IPs erreichbar, nicht über einzelne Node-IPs.
• Service Discovery: NRF (Network Repository Function) und/oder SCP (Service Communication Proxy) beeinflussen, welche Endpunkte sichtbar sind und wie Traffic geroutet wird.
• Skalierung: horizontales Scaling erzeugt viele Ephemeral IPs (Pod-IPs), die nicht manuell verwaltet werden dürfen.
• Security und Segmentierung: die Anzahl der erlaubten Flows steigt; ohne Zonenmodell werden ACLs unwartbar.

Grundprinzipien für ein telco-taugliches 5G-Core-IP-Design

Ein robustes Design folgt wenigen, aber konsequent umgesetzten Leitplanken. Diese Leitplanken verbinden klassische Provider-Disziplin (hierarchische Prefixe, Aggregation, klare Rollen) mit Cloud-native Anforderungen (Service-IPs, Overlays, Automatisierung).

• Hierarchie: Region → DC/PoP → Core-Cluster → Rolle (MGMT/OAM/SBA/UP) als Prefix-Container.
• Trennung von Ebenen: Underlay (physisches Transportnetz), Overlay (Kubernetes/EVPN/VXLAN), Service-Endpunkte (VIP/Load Balancer) getrennt planen.
• Control vs. User Plane: SBA- und Signalisierungsnetze getrennt von User-Plane-/N3-/N6-Pfaden.
• Security-Zonen: klare Zonen für SBA intern, Exposures (NEF/SEPP), Management, OAM, User Plane und externe DNN/Internet.
• Dual Stack: IPv6 früh standardisieren; IPv4 gezielt und sparsam einsetzen, ohne späteres Refactoring.
• Source of Truth: IPAM als führendes System; dynamische Bereiche (Pod/Service CIDRs) werden als reservierte Container dokumentiert, nicht als Einzel-IP-Liste.

Interface-Landschaft im 5G Core und was das für Netze bedeutet

5G kennt eine Vielzahl an Schnittstellen. Für das IP-Design ist weniger die vollständige Normliste entscheidend, sondern die Gruppierung nach Funktion: Access/Radio-Anbindung, SBA/Control Plane intern, User Plane, externe Exposures und Management/OAM. Daraus leiten sich Subnetze, VRFs und Filterregeln ab.

• Access-/RAN-Anbindung: N2 (gNB → AMF, Control), N3 (gNB → UPF, User) und ggf. N9 (UPF → UPF).
• Core-Control-Plane intern: N10/N11/N12/N13/N14/N15/N16/N17 u. a. (NF-Interaktionen, oft SBA-basiert).
• Data Network/Internet: N6 (UPF → Data Network/DNN) und ggf. Enterprise/Partner-Interconnects.
• Security/Inter-PLMN: SEPP für N32 (Inter-PLMN/roaming-nahe Pfade) und zusätzliche Security-Gateways.
• OAM/MGMT: Managementzugriff, Logging, Telemetry, NMS, Backup/Registry.

Zonen- und VRF-Modell: Der wichtigste Schritt gegen Wildwuchs

Ein 5G Core ist praktisch nie ein „flaches Netz“. Ein VRF-/Zonenmodell macht den Core beherrschbar, weil es Trust Boundaries definiert und Overlaps kontrollierbar macht. Eine bewährte Grundstruktur ist, mindestens folgende VRFs/Zonen zu trennen:

• VRF-MGMT: Out-of-Band oder Management-VLANs/Netze für Gerätezugriff, BMC/iLO/iDRAC, Admin-Tools.
• VRF-OAM: Telemetry/Syslog/NetFlow/Tracing/Monitoring-Pfade, Collector-Netze, Jump/Tools.
• VRF-SBA: interne SBA-Kommunikation (NF zu NF), Service Mesh/SCP/NRF, interne APIs.
• VRF-RAN: N2/N3 Termination (oder logisch getrennt nach Control/User), je nach Transportdesign.
• VRF-UP: User Plane Transport (N3/N9) und Übergänge Richtung N6; oft mit sehr klaren MTU/QoS-Anforderungen.
• VRF-EXPOSURE: NEF/SEPP/DMZ-nahe Komponenten, die externe APIs oder Inter-PLMN-Verkehr abbilden.
• VRF-DNN: optional pro DNN/Enterprise (z. B. private APNs/DNNs), um Policies und Addressing sauber zu isolieren.

Ob Sie jede dieser VRFs tatsächlich separat implementieren, hängt von Ihrer Plattform und Ihrem Sicherheitsmodell ab. Entscheidend ist, dass das Adressdesign diese Rollen klar abbildet, damit Filter, uRPF, Prefix-Listen und Monitoring zuverlässig funktionieren.

Adressbereiche pro Core-Cluster: Container statt Einzelnetze

Ein Core-Cluster (z. B. pro Region oder pro Rechenzentrum) sollte einen klaren, aggregierbaren Adressblock erhalten, aus dem alle Teilbereiche abgeleitet werden. Das vereinfacht Summarisierung in IGP/BGP, reduziert Filterlisten und beschleunigt Rollouts neuer Sites.

• Cluster-Block IPv4: ein reservierter Block pro Core-Cluster (Größe abhängig von NF-Anzahl, LB/VIP-Bedarf und Reserven).
• Cluster-Block IPv6: ein hierarchischer IPv6-Block pro Cluster, mit Reserven für Locators/Services und Wachstum.
• Rollen-Slices: innerhalb des Cluster-Blocks feste Untercontainer für MGMT, OAM, SBA, UP, Exposures, DNNs.
• Reserve explizit: „Free Space“ nicht zufällig nutzen, sondern als Reserveblock markieren (Expansion ohne Renumbering).

Kubernetes und IP-Planung: Pod CIDR, Service CIDR, Load Balancer

Wenn Ihr 5G Core cloud-native ist, sind drei IP-Domänen zentral: Pod-Netze, Service-Netze und externe Endpunkte (Load Balancer/VIPs). Diese Bereiche müssen im IPAM dokumentiert und sauber von Underlay- und Transportnetzen getrennt sein. Die wichtigste Regel lautet: Pod-IPs sind dynamisch, aber die CIDRs sind planbar.

• Pod CIDR: pro Cluster definierter Bereich für Pod-IPs (keine Überschneidung mit DC-Underlay, RAN-Transport oder DNN-Netzen).
• Service CIDR: Bereich für ClusterIP/Service-IPs; stabiler als Pod-IPs, aber ebenfalls intern.
• Load Balancer/VIP Pool: dedizierter Pool für externe oder interne VIPs (z. B. für SBA-Exposures, NF-Endpunkte, APIs).
• Node/Host Subnetze: Underlay-IP pro Worker/Compute/Router getrennt vom Pod/Service-Bereich.

Naming und Adressierung für Network Functions: Einheitliche Konventionen

Im 5G Core ist Naming ein Betriebskostenhebel. Gute Namensstandards sorgen dafür, dass ein On-Call-Team aus einem Namen sofort Scope und Rolle erkennt. In cloud-nativen Umgebungen gilt das für DNS/FQDNs, Service-Namen, VRF-Namen, VLAN-Namen, Prefix-Container und auch für Load-Balancer-VIPs.

• Standort/Site-Code: kurze, eindeutige Kennung (Region/Metro/DC/PoP), konsistent in allen Namen.
• Cluster-ID: z. B. core-a, core-b oder k8s-01, um Redundanz und Rollouts zu steuern.
• NF-Rolle: amf, smf, upf, ausf, udm, pcf, nrf, scp, sepp, nef, udr, nssf.
• Zone/VRF: mgmt, oam, sba, up, exposure, dnn-xyz.
• Instanz: optional für Skalierung oder Redundanz (z. B. -01, -02) ohne semantische Überladung.

Beispielmuster für FQDNs und Labels

• NF-Service-FQDN: amf.core-a.ber.sba.example.net
• VIP/Endpoint: vip-scp.core-a.ber.sba.example.net
• UPF-Node: upf01.core-a.ber.up.example.net
• Management: mgmt-core-a-ber-switch01.example.net

Wichtig ist, dass Sie Namen nicht mit Interface-Bezeichnern oder kurzlebigen Details überladen. Rollen, Scope und Cluster reichen meist aus; technische Details gehören als Metadaten ins IPAM.

Adressierung der SBA: NRF, SCP und Service-Endpunkte

In SBA-Designs sind NRF und oft auch SCP zentrale Elemente. Daraus ergeben sich Anforderungen an stabile Endpunkte (VIPs), klare Zonierung (SBA intern vs. Exposure) und saubere DNS-Auflösung.

• NRF: benötigt hochverfügbare Erreichbarkeit (typisch über Service-IP/ClusterIP oder eine interne VIP) und klare Zugriffsregeln.
• SCP: wenn genutzt, wird SCP häufig zum zentralen Durchleitungspunkt; IP- und MTU-Design sowie Observability müssen hier besonders sauber sein.
• DNS als Pflicht: SBA setzt stark auf FQDNs; DNS-Design (Resolver, Split-Horizon, TTL-Strategie) ist Teil des IP-Designs.
• VIP-Strategie: getrennte VIP-Pools für interne SBA-Endpunkte und externe/DMZ-nahe Exposures.

User Plane (UPF) und Subnetting: N3, N9, N6 sauber trennen

Die UPF ist der Datenpfad. Hier gelten andere Anforderungen als bei SBA: hohe Bandbreite, klare MTU, deterministische Pfade, uRPF/Anti-Spoofing, DNN-spezifische Policies und oft spezielle QoS-Anforderungen. Subnetting und Segmentierung helfen, N3/N9/N6 klar zu trennen.

• N3 (RAN → UPF): eigener Transportbereich, häufig als VRF oder dedizierte VLANs, mit klarer MTU-Policy.
• N9 (UPF → UPF): eigener Inter-UPF-Bereich (bei Distributed UPF), um Skalierung und Troubleshooting zu erleichtern.
• N6 (UPF → DNN):
• Loopbacks für UPF: stabile Identitäten (Monitoring, BGP, TE), getrennte Rollencontainer.

MTU und Encapsulation: Warum IP-Design ohne MTU-Plan scheitert

5G Core Umgebungen nutzen häufig Overlays, Service Mesh, Container Networking, EVPN/VXLAN oder SR-Transport. Damit steigen Overheads, und MTU wird schnell zum versteckten Fehlerverursacher. Deshalb sollten MTU-Profile als Pflichtfeld pro Zone und Interface geführt werden.

• UPF-Pfad priorisieren: N3/N9/N6 müssen end-to-end konsistent sein, sonst entstehen Blackholes bei großen Paketen.
• PMTUD ermöglichen: ICMP/ICMPv6 funktional halten; pauschales Blocken erzeugt „mystische“ Störungen.
• Template-Ansatz: MTU nicht pro Device neu erfinden, sondern als Standardprofil pro Zone.

Prefix-Filter und Anti-Spoofing im 5G Core

Ein 5G Core hat viele Übergänge: RAN-Transport, interne SBA, externe Exposures, DNN-Interconnects. In jedem Übergang müssen Prefix-Filter und Anti-Spoofing (uRPF/ACLs) auf Basis Ihres Adressdesigns greifen, sonst entstehen Route Leaks oder Spoofing-Pfade.

• RAN-Eingang: erlaubte Source-Prefixe strikt definieren (nur erwartete gNB/Transport-Quellen, je nach Design).
• SBA-intern: nur SBA-Container innerhalb VRF-SBA; keine Vermischung mit MGMT/OAM.
• Exposure/DMZ: default-deny, nur definierte API-Endpunkte, klare VIP-Pools, Logging.
• DNN/Enterprise: pro DNN eigene Allow-Lists; Overlaps nur VRF-aware; keine „alles 10/8“-Regeln.

IPv6 im 5G Core: Präfixhierarchie und Filterbarkeit

IPv6 ist im 5G Core nicht nur „optional“. Viele Deployments profitieren von IPv6 in SBA und in DNNs, insbesondere wenn Skalierung und Multi-Tenant-Isolation relevant sind. Ein sauberer IPv6-Plan muss aggregierbar und filterbar sein.

• /64 pro Segment: Standard für L2/L3-Segmente, vermeidet Sonderfälle und Tool-Inkompatibilitäten.
• /127 für P2P: für Router-zu-Router Links, konsistent und dokumentiert.
• /128 für Loopbacks: stabile NF-Identitäten, gut für Monitoring und Policies.
• Prefix-Delegation in DNNs: falls relevant, Pools pro Cluster/Zone, klare Anti-Spoofing-Regeln.

Dokumentation und IPAM: Pflichtfelder für 5G-Core-Adressierung

5G Core skaliert nur, wenn die Adressdaten als System gepflegt werden. Neben den Prefixen selbst sind Metadaten entscheidend, damit Betrieb, Security und Automation dieselbe Wahrheit teilen.

• Scope: Region, DC/PoP, Core-Cluster, Zone/VRF.
• Rolle: MGMT/OAM/SBA/UP/EXPOSURE/DNN, plus NF-Rollen (AMF/SMF/UPF etc.).
• Objekttyp: Pod CIDR, Service CIDR, VIP Pool, Underlay Subnet, P2P Link, Loopback Container.
• Owner: Plattformteam, Transportteam, Security, Partner/Wholesale (bei Interconnects).
• Status: planned/active/deprecated/retired, inkl. Change-Referenz.
• Security-Hinweise: Trust-Level, erlaubte Flows, Policy-Punkt (Firewall/ACL/SCP/SEPP).

Typische Fehlerbilder im 5G-Core-IP-Design und ihre Ursachen

• „SBA ist instabil“: DNS/Service-IPs nicht sauber geplant, VIP-Pools vermischt, Zonen nicht getrennt, SCP wird zum Bottleneck ohne klare MTU/OAM.
• „UPF hat sporadische Drops“: MTU inkonsistent, N3/N9/N6 nicht sauber segmentiert, uRPF/Filter greifen falsch wegen unklarem Scope.
• „Policies sind unwartbar“: IP-Plan ohne Rollencontainer, daher ACLs mit zu vielen Ausnahmen.
• „Overlaps bei Enterprise-DNNs“: fehlende VRF-Isolation oder Leak-Allow-Lists, zu breite RFC1918-Leaks.
• „Monitoring bricht unter Last weg“: OAM nicht getrennt, Telemetry konkurriert mit UP/SBA.

Praxis-Checkliste: IP-Design für 5G Core sauber umsetzen

• Hierarchie festlegen: Region → DC/PoP → Core-Cluster → Rolle; Prefixe sind daran gebunden.
• Zonen/VRFs definieren: MGMT, OAM, SBA, UP, Exposure, DNN (optional) als klare Trust Boundaries.
• Kubernetes-IP-Domänen planen: Pod CIDR, Service CIDR, VIP/LB Pools getrennt und im IPAM als Container dokumentiert.
• NF-Naming standardisieren: Site/Cluster/Role/NF/Instanz in konsistenten FQDNs und Labels; keine Interface-Details im Namen.
• SBA-Endpunkte stabil machen: NRF/SCP/NEF/SEPP als definierte Service-Endpunkte mit klaren VIP-Pools und DNS-Strategie.
• User Plane separieren: N3, N9, N6 logisch getrennt, mit MTU-Profilen und deterministischen Policies.
• Prefix-Filter und Anti-Spoofing: containerbasierte Allow-Lists, default-deny an Exposures, VRF-aware Overlap-Handling.
• Dual Stack konsequent: IPv6 /64-/127-/128 Standards; IPv4 sparsam und geshardet; keine späteren „Notlösungen“ einplanen.
• Dokumentation und Versionierung: Owner/Status/Scope/Role als Pflichtfelder, Changes nachvollziehbar, Drift Detection zwischen SoT und Konfiguration.

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.