MPLS/Segment Routing und IP-Planung: Was sich ändert (und was nicht)

MPLS/Segment Routing und IP-Planung ist ein Thema, das in Telco- und Provider-Teams regelmäßig für Missverständnisse sorgt. Der Grund ist nachvollziehbar: Segment Routing (SR) wird oft als „neue Technologie“ eingeführt, während MPLS als „klassisch“ gilt – und viele erwarten, dass damit auch die IP-Adressierung komplett neu gedacht werden muss. In der Praxis ist es umgekehrt: Der größte Teil der IP-Planung bleibt gleich, weil die Grundlagen von Routing, Erreichbarkeit und Stabilität unverändert sind. Was sich ändert, sind vor allem die Anforderungen an Identitäten (Loopbacks), an die Rollen bestimmter Adressen (Node-SIDs, Anycast-SIDs, SRv6 Locators), an die Konsequenz bei Hierarchie und Aggregation sowie an die Art, wie Sie Traffic Engineering und Services operationalisieren. Wer SR einführt, ohne die IP-Planung für diese neuen Identitäten und Kontrollpfade sauber zu strukturieren, bekommt keine „magische Vereinfachung“, sondern zusätzliche Komplexität: inkonsistente SIDs, unklare Mapping-Regeln, schwer nachvollziehbare Pfade und Troubleshooting, das an fehlenden Standards scheitert. Wer dagegen seine bestehende, hierarchische IP-Planung bewusst erweitert, kann SR stabil und skalierbar betreiben – mit besserer Automatisierbarkeit, klareren Service-Modellen und oft weniger State in der Control Plane. Dieser Artikel erklärt praxisnah, was sich bei der IP-Planung durch MPLS und Segment Routing wirklich ändert (und was nicht), welche Best Practices für Loopbacks, P2P-Links, IGP-Design und Service-Adressräume gelten und wie Sie die Migration so gestalten, dass Betrieb und Dokumentation nicht auseinanderlaufen.

MPLS und Segment Routing in einem Satz: Was ist der eigentliche Unterschied?

MPLS ist ein Weiterleitungsmechanismus mit Labels. Klassisches MPLS Traffic Engineering (TE) und L3VPN/L2VPN bauen häufig auf Protokollen wie LDP oder RSVP-TE auf, die Label-State im Netz verteilen. Segment Routing nutzt ebenfalls Labels (bei SR-MPLS) oder IPv6-Segmentlisten (bei SRv6), aber verteilt den notwendigen State anders: Viele Informationen werden über das IGP (z. B. IS-IS/OSPF mit SR-Erweiterungen) signalisiert, und der Pfad wird als Segmentliste beschrieben.

• Gemeinsamkeit: Beide benötigen ein stabiles IGP und verlässliche Router-Identitäten (Loopbacks).
• Unterschied: SR reduziert oft zusätzliche Signalisierungsprotokolle (z. B. LDP/RSVP), indem es Segmente über das IGP verteilt.
• Konsequenz für IP-Planung: Nicht „alles neu“, sondern „Loopbacks und Rollen sauberer als je zuvor“.

Was sich nicht ändert: Die Grundpfeiler der IP-Planung bleiben gleich

Unabhängig davon, ob Sie LDP, RSVP-TE oder Segment Routing einsetzen: Ihr Netz braucht weiterhin eine konsistente, hierarchische IP-Adressierung, die Routing stabil hält und Betrieb ermöglicht. Folgende Punkte ändern sich durch SR nicht grundsätzlich:

• Hierarchische Container: Region → Metro/Cluster → PoP → Rolle bleibt die sinnvollste Struktur.
• Loopbacks als Identitäten: Router-IDs und Loopbacks bleiben das Fundament für IGP/BGP und Services.
• P2P-Linknetze: Punkt-zu-Punkt Adressierung (IPv4 /31, IPv6 /127) bleibt Best Practice.
• Summarisierung: Aggregation und saubere Prefix-Container bleiben entscheidend, um Routingtabellen klein zu halten.
• Management/OAM-Trennung: MGMT- und OAM-Adressräume müssen weiterhin getrennt und auditierbar sein.

Wenn Ihr IP-Plan vor SR schon unstrukturiert war, wird SR ihn nicht „reparieren“. Im Gegenteil: SR macht die Konsequenzen inkonsistenter Identitäten sichtbarer.

Was sich ändert: Neue Identitäten und neue Bedeutungen für bestehende IPs

Der wichtigste Unterschied ist nicht, dass Sie „andere Subnetze“ brauchen, sondern dass bestimmte IPs (vor allem Loopbacks) neue Rollen bekommen. Bei SR-MPLS kommen SIDs (Segment Identifiers) hinzu, die auf Knoten (Node-SIDs), Links (Adjacency-SIDs) oder Services (z. B. VPN/TE Policies) referenzieren. Bei SRv6 kommen Locators und Segment-IDs in IPv6 hinzu.

• Node-SIDs: sind logisch an den Knoten gebunden und referenzieren typischerweise die Loopback/Router-ID.
• Anycast-SIDs: können für redundante Funktionen genutzt werden (z. B. mehrere Knoten teilen sich eine SID).
• SRv6 Locators: IPv6-Prefixe, aus denen SRv6-SIDs abgeleitet werden; sie brauchen klare Hierarchie und Aggregation.
• Operationaler Anspruch: IP-Planung muss SID-Planung und Rollenmodell integrieren (Source of Truth).

Loopback-Design wird noch wichtiger: Struktur für IGP, BGP und SR

Loopbacks waren schon immer wichtig. Mit SR werden sie häufig noch zentraler, weil Node-SIDs und Steuerpfade direkt daran hängen. Ein sauberes Loopback-Design ist daher der erste IP-Plan-Baustein, den Sie vor einer SR-Einführung reviewen sollten.

• IPv4 Loopbacks: als /32, rollenbasiert (P, PE, RR, BNG, Services, VTEP).
• IPv6 Loopbacks: als /128, parallel nach denselben Rollenblöcken strukturiert.
• Rollencontainer: getrennte Bereiche für Core-P, PE, RR – damit Policies und Monitoring klar bleiben.
• Stabilität: keine „umgezogenen“ Loopbacks ohne Versionierung und Migrationsplan; SR-Policies referenzieren sie.

Best Practice: Loopbacks als „API“ des Netzes behandeln

Wenn viele Systeme (Traffic Engineering, Monitoring, Automation, Security) Loopbacks als Anker nutzen, sind Loopbacks funktional wie eine API: stabil, eindeutig, dokumentiert und versioniert.

SID-Planung bei SR-MPLS: Warum der IP-Plan hier indirekt wirkt

Bei SR-MPLS sind SIDs Labelwerte (typischerweise aus einem SRGB – Segment Routing Global Block). Die SID selbst ist kein IP-Prefix, aber die Zuordnung „Node-SID ↔ Router/Loopback“ muss sauber dokumentiert und konsistent sein. Je nach Implementierung kann die Node-SID an die Loopback gekoppelt sein oder separat gepflegt werden.

• SRGB konsistent: Provider definieren SRGB netzweit einheitlich, um Interoperabilität und Betrieb zu vereinfachen.
• Node-SID-Mapping: pro Router eindeutig; keine Doppelbelegung, keine „Lücken“ ohne Dokumentation.
• Rollensicht: SIDs nach Rollen gruppieren (Core vs. Edge), damit Automation und Policies leichter werden.
• Migration: Koexistenz mit LDP/RSVP erfordert klare Regeln, wann welcher Mechanismus aktiv ist.

SRv6 und IP-Planung: Hier ändert sich tatsächlich mehr

Wenn Sie SRv6 einführen, wird IP-Planung noch stärker relevant, weil SIDs in IPv6-Adressen kodiert sind. SRv6 braucht typischerweise Locator-Prefixe, aus denen Segment-IDs generiert werden. Das ist IP-Design im engeren Sinne: Locators müssen hierarchisch, aggregierbar und eindeutig sein, sonst wachsen Routing und Policies unnötig.

• Locator-Hierarchie: z. B. nach Region/PoP/Node strukturieren, damit Aggregation möglich bleibt.
• Locator-Größe: so wählen, dass genug SID-Space pro Node/Service bleibt, ohne den globalen Plan zu fragmentieren.
• Aggregation: Locators sollten summarizierbar sein, damit Routing-Policies einfach bleiben.
• Trennung von Rollen: Infrastruktur-Locators getrennt von Service-/Function-Locators (wo Ihr Design das vorsieht).

P2P-Linknetze: /31 und /127 bleiben Best Practice

Auch mit SR ändern sich die Regeln für Punkt-zu-Punkt Links nicht. Im Gegenteil: Standardisierung wird wichtiger, weil SR auf stabilen IGP-Nachbarschaften basiert. Konsistente P2P-Adressierung reduziert Fehlerbilder (Masken-Mismatch, On-link Verwirrung, ARP/ND-Probleme) und macht Troubleshooting schneller.

• IPv4 P2P: /31 als Default, /30 nur mit dokumentierter Ausnahme.
• IPv6 P2P: /127 als Default, konsistent über Core und Metro.
• Container: dedizierte P2P-Prefix-Container pro Region/PoP (Scope-Disziplin).
• Link-Metadaten: Gegenstelle, MTU, IGP-Level/Area, Link-ID gehören in die Doku/IPAM.

IGP-Design und IP-Planung: Stabilität, Konvergenz und RPF-ähnliche Effekte

Segment Routing basiert stark auf dem IGP als Verteilmechanismus für SR-Informationen. Damit wird IGP-Disziplin noch wichtiger: saubere Areas/Levels, klare Summaries (wo sinnvoll), stabile Loopbacks, konsistente MTU und durchdachte Filter. Ein IP-Plan Review vor SR sollte deshalb IGP-relevante Prefixe und deren Verteilung explizit betrachten.

• IGP-Scope: Welche Prefixe müssen wirklich im IGP sein (Loopbacks, P2P)? Welche nicht (MGMT, Kundennetze)?
• Summarisierung: nur dort, wo sie nicht die Pfadberechnung oder Troubleshooting erschwert.
• Konvergenz: stabile IGP-Topologie ist für SR-TE-Policies besonders wichtig, weil Pfade auf Knoten-Identitäten referenzieren.
• Dokumentation: IGP-Adressräume (Loopbacks/P2P) als eigener Planbestandteil, nicht „irgendwo“ verteilt.

Traffic Engineering: Was IP-Planung indirekt beeinflusst

Viele Erwartungen an SR drehen sich um Traffic Engineering: explizite Pfade, bessere Auslastung, schnellere Reaktion auf Störungen. IP-Planung beeinflusst das indirekt über die Eindeutigkeit und Stabilität der Ankerpunkte, die TE verwendet.

• Stable Endpoints: TE Policies referenzieren meist Router-Loopbacks (Headend/Tailend). Diese müssen stabil sein.
• Anycast vs. Unicast Identitäten: Anycast kann Resilienz erhöhen, kann aber auch Troubleshooting erschweren, wenn es unklar dokumentiert ist.
• Policy-Scopes: TE-Policies sollten an Regionen/Metro-Ringe angepasst sein; das sollte sich in der IP-/Locator-Hierarchie widerspiegeln.
• OAM/Monitoring: Pfadmessung und Telemetry hängen an konsistenter Source-IP und klaren Rollenblöcken.

L3VPN/L2VPN bleibt: Service-Adressräume und VRFs ändern sich nicht grundlegend

Segment Routing ersetzt nicht automatisch die Serviceebene. MPLS L3VPN, EVPN, L2VPN – all diese Services existieren weiterhin. Für IP-Planung heißt das: VRF-Container, Customer-Pools, Übergabenetze und Management-/Service-Zonen bleiben relevant. SR ändert eher den Transportmechanismus im Core, nicht die Notwendigkeit sauberer Service-Isolation.

• VRF-Adressierung: weiterhin getrennte Container pro VRF/Serviceklasse, besonders bei Overlapping RFC1918.
• Übergabenetze: PE-CE Links und Kundenhandoffs bleiben (oft /31 oder /30 je nach Design).
• EVPN/VXLAN Edge: kann parallel existieren; die IP-Planung muss beide Welten sauber abbilden.
• Dokumentationspflicht: VLAN-to-VRF, Prefixe, Gateways, Policies – unabhängig vom Transport.

Migration von MPLS (LDP/RSVP) zu SR: IP-Plan-Fallen und wie man sie vermeidet

Die Migration ist der Moment, in dem IP-Planung „sichtbar“ wird: Koexistenz bedeutet mehr Zustände, mehr Policies, mehr Möglichkeiten für Inkonsistenz. Häufige Fehler liegen nicht im SR selbst, sondern in fehlender Versionierung und unklaren Rollen.

• Unklare Loopback-Rollen: wenn Loopbacks historisch gewachsen sind, wird Node-SID-Zuordnung fehleranfällig.
• Inkonsequente IGP-Verteilung: einige Knoten sehen bestimmte Loopbacks/P2P, andere nicht → SR-Paths werden unvollständig.
• Drift zwischen Doku und Config: SIDs und Zuordnungen sind nicht in der Source of Truth, sondern „nur im Router“.
• MTU/Encapsulation: SR-Policy nutzt andere Pfade; MTU-Probleme werden sichtbar, wenn Standards fehlen.
• Zu breite Leaks/Filters: Prefixlisten, die „zufällig“ funktionieren, brechen bei neuen Rollenblöcken.

Dokumentation und Source of Truth: Ohne saubere Daten wird SR teuer

Segment Routing ist stark automatisierungsfreundlich – aber nur, wenn Ihre Daten sauber sind. IP-Planung, SID-Planung und Rollenmodell gehören zusammen in eine Source of Truth (IPAM/Inventory). Damit werden Reviews möglich, Diffs nachvollziehbar und Rollouts wiederholbar.

• Pflichtdaten pro Node: Loopbacks (v4/v6), Rolle, Standort/PoP, Node-SID/Locator, Status, Owner.
• Pflichtdaten pro Link: P2P-Prefix, Endpunkte, IGP-Kontext, MTU, Link-ID.
• Pflichtdaten pro Service: VRF, Prefix-Container, Übergabenetze, Policies/Leaks.
• Versionierung: Änderungen an Loopback-/Locator-Containern müssen nachvollziehbar sein, weil sie TE und Services beeinflussen.

Praktische Checkliste: Was Sie am IP-Plan vor SR prüfen sollten

• Loopback-Hygiene: konsistente /32 und /128, Rollenblöcke, keine Doppelbelegung, sauber im IGP verteilt.
• P2P-Standardisierung: /31 und /127 konsequent, dedizierte Container pro Region/PoP, vollständige Link-Metadaten.
• IGP-Scope: nur notwendige Prefixe im IGP, klare Policy, stabile Konvergenz, Summaries bewusst.
• SID/Locator-Plan: Node-SIDs (SR-MPLS) eindeutig, SRGB konsistent; bei SRv6 Locators hierarchisch und aggregierbar.
• VRF- und Service-Container: bleiben getrennt, Overlaps VRF-aware, Leaks als Allow-List.
• MTU-Standards: end-to-end MTU inkl. Overheads dokumentiert, PMTUD funktional.
• Source of Truth: IP- und SID-Daten zentral, versioniert und mit Owner/Status gepflegt.

Praxis-Checkliste: Was sich bei MPLS/Segment Routing und IP-Planung ändert (und was nicht)

• Ändert sich nicht: hierarchische IP-Container, saubere Loopbacks, /31-/127-P2P, Summarisierung, MGMT/OAM-Trennung, VRF-Adressräume.
• Ändert sich: Loopbacks bekommen noch mehr Bedeutung (Node-SIDs/TE-Anker), zusätzliche Planobjekte (SIDs/Locators) müssen versioniert und dokumentiert werden.
• Bei SR-MPLS: SID-Planung ist primär Mapping und Governance (SRGB, Node-SIDs), nicht neue Subnetze.
• Bei SRv6: Locator-Design ist echtes IP-Design und muss hierarchisch/aggregierbar geplant werden.
• Operationalisierung: Source of Truth, Templates, Drift-Checks und Preflight-Validierung werden wichtiger als „manuelle Listen“.

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.