Site icon bintorosoft.com

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

Red Snapper

Network Engineer Intently Analyzing Data Server Racks in a Neon-Lit High Tech Data Center

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).

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.

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).

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.

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“.

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.

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.

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.

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.

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.

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.

Typische Fehlerbilder und wie saubere Adressierung sie verhindert

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

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:

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.

Exit mobile version