IP-Adressierung für Interconnects: Peering, Transit und IXPs sauber planen

IP-Adressierung für Interconnects ist im Provider-Umfeld viel mehr als „zwei IPs auf einen Link“. Ob Peering, Transit oder IXPs (Internet Exchange Points): Interconnect-Links sind kritische Übergänge zwischen Routing-Domänen, sie beeinflussen Stabilität und Sicherheit Ihrer BGP-Session, sie sind oft Bestandteil von SLAs – und sie sind ein häufiger Ort für Betriebsfehler, wenn Adressierung, MTU, Filtering und Dokumentation nicht sauber standardisiert sind. Ein typisches Anti-Pattern ist ein historisch gewachsener Mix aus /30-Netzen, zufällig gewählten privaten Adressen, inkonsistenten IPv6-/127-Links, fehlender Trennung zwischen IXP-LAN und direkten Cross-Connects, sowie fehlenden Namens- und IPAM-Konventionen. Das Ergebnis sind schwer reproduzierbare Störungen (BGP flapt, ARP/ND instabil, PMTUD bricht), Security-Risiken (falscher Scope, falsche ACLs, unklare Trust Boundaries) und höhere Betriebskosten (lange Fehlersuche, unklare Ownership, fehlende Standard-Runbooks). Dieser Artikel zeigt praxisnah, wie Sie Interconnect-Adressierung für Peering, Transit und IXPs sauber planen: welche Präfixgrößen sich bewährt haben, wie Sie IPv4-Knappheit effizient managen, welche Besonderheiten bei IXPs gelten, wie Sie IPv6 konsequent ergänzen, und welche Prozess- und Dokumentationsstandards Telcos nutzen, um Interconnects dauerhaft stabil zu betreiben.

Interconnect-Typen verstehen: Peering, Transit, Private Interconnect und IXP-LAN

Bevor Sie Adressen vergeben, müssen Sie den Interconnect-Typ klar benennen. Denn je nach Typ unterscheiden sich Trust-Level, Routing-Policies, Adressquellen und sogar die Frage, ob Sie überhaupt ein eigenes Linknetz vergeben (z. B. beim IXP-LAN vs. Private Peering).

• Private Peering (PNI): direkter Cross-Connect zwischen zwei Netzen, typischerweise genau zwei Router-Ports (oder LAG) in einem Rechenzentrum/PoP.
• Transit: Provider ↔ Upstream, meist mit strikteren Security- und Policy-Anforderungen, häufig redundant über mehrere Standorte.
• IXP Peering: Peering über ein gemeinsames Exchange-LAN (Layer-2-Switch-Fabric des IXPs); mehrere Teilnehmer im selben L2-Segment.
• Private Interconnect/Cloud Interconnect: zu Cloud-Providern oder Content-Netzen; oft spezielle MTU/Encapsulation-Profile.

Die Unterscheidung ist wichtig, weil die Adressierung beim IXP in der Regel durch den IXP vorgegeben wird (IXP-LAN Prefix), während bei PNI/Transit das Linknetz von Ihnen (oder dem Partner) geplant werden kann.

Grundprinzipien der Interconnect-Adressierung

Saubere Interconnect-IP-Planung folgt wenigen, aber sehr wirksamen Prinzipien. Diese reduzieren Fehler, erleichtern Automatisierung und machen Audits einfacher.

• Dedizierte Rollenblöcke: Interconnect-Linknetze getrennt von MGMT, Loopbacks, Services, Kundennetzen.
• Minimaler Adressverbrauch: Punkt-zu-Punkt mit /31 (IPv4) und /127 (IPv6) wo sinnvoll.
• Stabilität und Eindeutigkeit: konsistente Standards pro Interconnect-Typ (PNI/Transit/IXP) statt Einzelfälle.
• Trennung nach Trust: IXP-LAN als shared L2 hat andere Sicherheitsanforderungen als private Cross-Connects.
• Dual Stack als Standard: IPv6 auf Interconnects konsequent mitführen, nicht „später“ nachrüsten.
• Dokumentation als Pflicht: jeder Interconnect hat Owner, Scope, Link-ID, Gegenstelle, BGP-Parameter und IPs im IPAM.

IPv4 für Punkt-zu-Punkt Interconnects: /31 als Default

Für direkte Links zwischen zwei Routern (PNI oder Transit-Cross-Connect) ist IPv4 /31 in modernen Netzen ein etabliertes Best Practice: Es verbraucht nur zwei Adressen ohne Network/Broadcast-Overhead und ist operativ gut standardisierbar. /30 ist meist Legacy oder für Sonderfälle nötig (z. B. wenn ein Gerät /31 nicht unterstützt oder zusätzliche Adressen am Link gebraucht werden).

• Empfehlung: IPv4 P2P-Links als /31 planen.
• Ausnahme: /30 nur mit dokumentierter Begründung und klarer Standardisierung.
• Vorteil: weniger IP-Verbrauch, einfachere Planung, weniger Fragmentierung im Linknetz-Pool.
• Operative Regel: ein Interconnect-Link = genau ein /31, keine „mitgenutzten“ Linknetze.

IPv6 für Punkt-zu-Punkt Interconnects: /127 konsistent einsetzen

Bei IPv6 ist /127 für Punkt-zu-Punkt Links ein verbreitetes Muster, weil es die On-Link-Nachbarschaft stark begrenzt und Fehlersuche vereinfacht. Für Router-zu-Router Links ist /127 in der Praxis sehr gut beherrschbar. Wichtig ist, dass Sie es konsistent umsetzen und in Ihren Templates und Runbooks verankern.

• Empfehlung: IPv6 P2P-Links als /127 planen.
• Loopbacks: IPv6 Loopbacks als /128, getrennte Rollenblöcke (RR/P/PE/BNG).
• Dokumentation: Link-ID und beide Endpunkte (A/B) im IPAM, plus MTU-Profile.

IXP-Adressierung: Besonderheiten des Exchange-LANs

Das IXP-LAN ist kein P2P-Linknetz, sondern ein gemeinsames Layer-2-Segment, in dem viele Teilnehmer sitzen. Das beeinflusst Adressierung und Sicherheit erheblich: Sie nutzen in der Regel Adressen aus dem vom IXP bereitgestellten Prefix (IPv4 und häufig auch IPv6). Die Adressen dienen meist ausschließlich der BGP-Session auf dem IXP-LAN, nicht als „allgemeines Transitnetz“.

• Adressquelle: IXP weist in der Regel eine IPv4- und IPv6-Adresse aus dem IXP-LAN zu.
• Scope: nur für Peering im IXP-LAN; keine Vermischung mit internen Management- oder Servicefunktionen.
• Sicherheit: L2-shared Umgebung; strikte ACLs, Neighbor/ARP-Protection und klare BGP-Policies sind wichtiger als bei PNI.
• Operationalisierung: IXP-Ports klar kennzeichnen (Naming), Standard-Template für IXP-Interfaces.

Best Practice: IXP-IP ist nur „BGP-on-LAN“

Ein häufiger Fehler ist, IXP-IPs wie normale Interconnect-IPs zu behandeln und plötzlich Monitoring, Services oder gar Management darüber zu führen. Das erhöht Angriffsfläche und erschwert Incident-Containment. IXP-IP gehört in einen klaren, minimalen Zweck: Peering.

Peering vs. Transit: Was sich im IP-Plan unterscheiden sollte

Die IP-Adressierung selbst kann bei PNI und Transit identisch aussehen (P2P /31 und /127). Unterschiede liegen eher in Scope, Dokumentation, Naming und Security-Defaults.

• Transit-Links: häufig strengere Standard-ACLs (nur BGP und ggf. BFD/ICMP), klarere Ownership, oft mehrfache Redundanz über Regionen.
• PNI-Peering: oft pro Standort/PoP; Adresspool kann nach PoP organisiert sein, um Wiederholbarkeit zu erreichen.
• Policy-Referenzen: Transit hat klar definierte Import/Export-Policies; Peering oft policy je Peer-Gruppe.

Adresspools und Hierarchie: Interconnect-Container nach PoP und Rolle

In Telco-Umgebungen ist die beste Praxis, Linknetze aus dedizierten Containern zu vergeben, die entlang der Topologie organisiert sind. Das verhindert Überschneidungen, erleichtert Summaries (wo sinnvoll) und macht Audits einfach.

• Region → PoP → Rolle: z. B. REG-DE-BER → POP-BER1 → P2P-INTERCONNECT.
• Separate Pools: getrennte Pools für PNI, Transit, ggf. Cloud-Interconnect, damit Policies nicht vermischt werden.
• Reserve: ausreichend Reserve pro PoP/Region einplanen, um Wachstum ohne „Pool-Hop“ zu ermöglichen.
• IPAM Pflicht: jedes /31-/127-Linknetz wird reserviert, bevor es konfiguriert wird.

MTU und Overhead: Interconnects sind häufig MTU-Flaschenhälse

Interconnects wirken oft wie reine L3-Links, sind aber in der Praxis häufig die Stelle, an der MTU-Probleme sichtbar werden: LAGs, optische Plattformen, QinQ, MPLS, VXLAN oder Provider-spezifische Overheads können dazu führen, dass PMTUD bricht oder große Pakete blackholen. Deshalb gehört MTU in die Interconnect-Doku.

• Service-MTU dokumentieren: pro Interconnect-Typ definieren (PNI, Transit, Cloud-Interconnect, IXP).
• PMTUD sicherstellen: ICMP/ICMPv6 funktional zulassen, nicht blind blocken.
• Einheitliche Templates: MTU in Interface-Templates verankern, nicht als Einzelfall.

Sicherheitsstandards: ACLs, ARP/ND und „nur das Nötigste“

Interconnect-Interfaces sind exponiert: Sie führen in fremde Routing-Domänen. Deshalb sollten sie standardmäßig restriktiv sein. Viele Provider arbeiten mit einem Baseline-Filterprofil je Interconnect-Typ.

• Transit/PNI Baseline: erlauben typischerweise nur BGP (TCP/179) und notwendige Control-Protokolle (z. B. BFD, ICMP für PMTUD/Debug) – je nach Policy.
• IXP Baseline: besonders restriktiv, weil shared L2; klare Anti-Spoofing- und Neighbor-Controls sind wichtig.
• Source Addressing: BGP-Sessions sollten stabile Source-IPs/Interfaces nutzen; unklare Source kann Debugging erschweren.
• Logging: Drops und Policy-Hits sollten sichtbar sein, ohne Log-Flooding zu erzeugen.

Dokumentation: Was pro Interconnect zwingend erfasst werden sollte

Interconnects sind ideale Kandidaten für standardisierte Dokumentation, weil sich die Struktur wiederholt. Eine saubere Telco-Doku spart hier sehr viel Zeit, insbesondere bei Peerings mit vielen Partnern oder bei großen IXP-Fabrics.

• Link-ID: eindeutiger Identifier (inkl. Standort/PoP, Partner, Port/LAG).
• Interconnect-Typ: PNI, Transit, IXP, Cloud-Interconnect.
• Gegenstelle: Partner/ASN, Kontakt, NOC-Handovers (ohne Details zu überladen).
• IPs und Prefixe: IPv4 /31 und IPv6 /127 (oder IXP-LAN Adressen), Interface-Zuordnung.
• BGP-Parameter: Session-IPs, BFD ja/nein, Communities/Policy-Group, Max-Prefix (wo relevant).
• MTU/QoS: Interface-MTU, besondere Anforderungen (Cloud/Encapsulation).
• Security Baseline: welche ACL/Filterprofile gelten?
• Status/Lifecycle: planned/active/deprecated/retired, Change-Referenz, Owner.

Naming Standards: Interconnects und Linknetze klar benennen

Ein konsistentes Naming reduziert Fehlkonfigurationen und beschleunigt Troubleshooting. Besonders hilfreich ist, wenn aus dem Namen Standort, Partner und Typ erkennbar sind.

• Interface-Label: POP-BER1-PNI-AS12345-A oder POP-FRA2-TRANSIT-AS3356-B
• Subnetz-Label: POP-BER1-PNI-AS12345-P2P-V4 oder POP-BER1-IXP-DE-CIX-LAN-V6
• Policy-Gruppen: PEER-GRP-IXP, PEER-GRP-TRANSIT, PEER-GRP-PNI (damit Config wiederholbar bleibt)

Typische Fehlerbilder und wie saubere Adressierung sie verhindert

• BGP kommt nicht hoch: falsches /31-/127, falsche Neighbor-IP, falscher VRF/Interface-Kontext, falsche ACL.
• ARP/ND instabil am IXP: falsche Neighbor-Policies, falsche L2-Annäherung, unerwartete Broadcast-Domäne.
• Blackholing bei großen Paketen: MTU/PMTUD nicht konsistent, ICMP geblockt.
• Policy-Missmatch: Transit/Peering-Prefixlisten erwarten bestimmte Längen; falsche Summaries führen zu Drops.
• Dokumentationslücke: Owner/Gegenstelle unklar, Change dauert länger, Incident eskaliert unnötig.

Praxis-Checkliste: Interconnect-Adressierung für Peering, Transit und IXPs

• Interconnect-Typ klassifizieren: PNI, Transit, IXP, Cloud-Interconnect – jedes hat eigene Defaults.
• Dedizierte Adresspools: separate Container für Interconnect-P2P (IPv4/IPv6), getrennt nach PoP/Region und Rolle.
• P2P Standards: IPv4 /31 und IPv6 /127 als Default; /30 nur mit begründeter Ausnahme.
• IXP korrekt behandeln: IXP-LAN Adressen nur für Peering, shared L2 Sicherheitsprofil anwenden.
• Dual Stack konsequent: IPv4 und IPv6 auf Interconnects standardmäßig ausrollen.
• MTU dokumentieren: Service-MTU je Interconnect-Typ, PMTUD funktional halten.
• Security Baselines: restriktive ACLs, Anti-Spoofing, nur notwendige Protokolle erlauben.
• IPAM & Doku Pflicht: Link-ID, Partner/ASN, IPs, VRF, Policy-Gruppe, Owner, Status, Change-Referenz.
• Templates statt Einzelfall: Standardkonfigurationen für Transit/PNI/IXP-Ports, inklusive Naming.

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.