Subnetting für Point-to-Point: /31, /30 oder /29 – was passt wann?

Beim Subnetting für Point-to-Point im Provider-Netz ist die Frage „/31, /30 oder /29 – was passt wann?“ nicht nur eine Rechenübung, sondern eine Designentscheidung mit direkten Auswirkungen auf IPv4-Verbrauch, Betriebssicherheit und Standardisierung. Punkt-zu-Punkt-Links (P2P) sind im Telco-Umfeld allgegenwärtig: Backbone-Links zwischen Core-Routern, Metro-Ringe, Aggregations-Uplinks, Interconnects zu Firewalls, PE-Links, BNG-Anbindungen oder Transportstrecken zwischen Standorten. Genau weil es so viele dieser Links gibt, multipliziert sich jede ineffiziente Präfixwahl sofort zu einem echten IPv4-Problem. Klassisch wurde lange /30 genutzt: vier Adressen, davon zwei nutzbar – perfekt für zwei Router. Moderne Provider verwenden heute sehr häufig /31, weil damit zwei Adressen ohne Broadcast-Overhead nutzbar sind und sich IPv4 deutlich effizienter einsetzen lässt. /29 hat im P2P-Kontext eher Spezialrollen: Es ist kein „besseres /30“, sondern ein kleines Mehrpunktnetz mit sechs nutzbaren Hostadressen, das z. B. bei Übergaben mit mehreren Geräten, bei kleinen DMZ-/Interconnect-Szenarien oder bei „Mini-Segmenten“ sinnvoll sein kann. Dieser Artikel erklärt praxisnah, wie /31, /30 und /29 funktionieren, welche Vor- und Nachteile sie im Provider-Betrieb haben und nach welchen Kriterien Sie entscheiden – inklusive Best Practices, typischer Fallstricke und einer schnellen Entscheidungslogik für Techniker und Planer.

Grundlagen: Was liefern /31, /30 und /29 an nutzbaren Adressen?

IPv4 hat 32 Bit. Die Präfixlänge bestimmt, wie viele Hostbits bleiben und damit, wie viele Adressen in einem Subnetz liegen. Für die schnelle Einordnung reichen drei Fakten:

• /29: 8 Adressen insgesamt, klassisch 6 nutzbar (Netz + Broadcast sind reserviert).
• /30: 4 Adressen insgesamt, klassisch 2 nutzbar.
• /31: 2 Adressen insgesamt, beide nutzbar (P2P-Spezialfall ohne Broadcast-Problem).

Mathematisch: Wenn h die Hostbits sind, gilt $h=32–\mathrm{Prefix}$ und klassisch $\mathrm{nutzbare\; Hosts}=2^h–2$. Bei /31 greift in P2P-Szenarien die Praxisregel, dass beide Adressen genutzt werden können, weil Broadcast im klassischen Sinn nicht erforderlich ist.

Warum P2P-Subnetting im Telco-Netz so wichtig ist

In Enterprise-Netzen machen P2P-Links oft nur einen kleinen Anteil aus. In Provider-Netzen sind sie massiv: Jede zusätzliche Backbone-Strecke, jeder neue PoP, jeder Aggregationsknoten bringt neue Links. Wenn Sie bei jedem Link „zu groß“ planen, verbrennen Sie IPv4 in Größenordnungen, die später schmerzen – besonders in Zeiten von IPv4-Exhaustion und CGNAT-Projekten.

• Skalierung: tausende Links sind normal; Effizienz pro Link ist entscheidend.
• Standardisierung: ein einheitlicher Link-Standard reduziert Konfigfehler und beschleunigt Provisionierung.
• Routing-Policies: klare Link-Prefix-Blöcke sind filterbar und erleichtern IGP/BGP-Design.
• IPAM: Linknetze lassen sich als eigener Rollenblock verwalten und automatisiert vergeben.

/30: Der klassische P2P-Standard – stabil, verständlich, aber ineffizient

Ein /30 ist das traditionelle Punkt-zu-Punkt-Subnetz: Es hat vier Adressen, zwei davon sind nutzbar. Viele Teams mögen /30, weil es leicht zu erklären ist, in alten Templates steckt und nahezu jedes Gerät es problemlos unterstützt. Der Preis ist IPv4-Verbrauch: Pro Link gehen effektiv zwei Adressen „verloren“ (Netz und Broadcast).

• Vorteil: universell verständlich und historisch etabliert.
• Vorteil: sehr hohe Kompatibilität mit Legacy-Geräten und alten Betriebsprozessen.
• Nachteil: ineffizient – 50% der Adressen im /30 sind nicht als Host nutzbar.
• Nachteil: bei tausenden Links summiert sich die Verschwendung massiv.

/30-Beispiel in Sekunden erkennen

Bei /30 ist die Blockgröße im letzten Oktett 4. Netzstarts sind …0, …4, …8, …12 usw. Beispiel 198.51.100.8/30: Hosts sind .9 und .10, Broadcast ist .11. Das ist im Feldbetrieb sehr schnell zu prüfen.

/31: Der moderne Provider-Standard – maximale Effizienz für echte Punkt-zu-Punkt-Links

Ein /31 besteht aus genau zwei IPv4-Adressen. In Punkt-zu-Punkt-Szenarien können beide genutzt werden – perfekt für Router A und Router B. Dadurch sparen Sie im Vergleich zu /30 pro Link zwei Adressen. In großen Netzen ist das einer der effektivsten IPv4-Sparhebel überhaupt.

• Vorteil: maximale Effizienz – genau zwei Adressen für zwei Endpunkte.
• Vorteil: weniger IP-Verbrauch im Link-Adressraum, längere Lebensdauer interner IPv4-Pools.
• Vorteil: sehr gut geeignet für automatisierte Provisionierung (gleiches Muster überall).
• Nachteil: erfordert saubere Standardisierung und die Zusicherung, dass alle relevanten Plattformen /31 korrekt unterstützen.
• Nachteil: manche ältere Tools/Prozesse denken „Broadcast“ immer mit und stolpern über /31, wenn sie nicht angepasst sind.

Wann /31 exakt passt

/31 passt dann, wenn es wirklich ein zwei-Endpunkte-Link ist: Router↔Router, Firewall↔Router (sofern genau zwei Geräte), Core↔PE, Metro↔Aggregation – überall dort, wo auf diesem L3-Segment keine weiteren Teilnehmer vorgesehen sind.

/29: Kein P2P-Standard, sondern ein kleines Mehrpunktnetz für Sonderfälle

Ein /29 liefert sechs nutzbare Adressen. Für einen reinen Punkt-zu-Punkt-Link ist das meist überdimensioniert. Dennoch hat /29 im Provider-Netz sinnvolle Anwendungsfälle – nur eben nicht als „Standard-P2P“. Typischerweise wird /29 genutzt, wenn Sie mehr als zwei Geräte in einem sehr kleinen L3-Segment benötigen oder wenn Übergaben mehrere Endpunkte erfordern (z. B. Router + Firewall + zusätzliche Appliance oder Management/Out-of-Band-Elemente in einem Mini-Segment).

• Vorteil: bietet Platz für mehrere Endpunkte in einem kleinen Segment.
• Vorteil: geeignet für Übergaben/Interconnects, bei denen mehr als zwei Geräte beteiligt sind.
• Nachteil: erhöht die Failure Domain (mehr Geräte im gleichen L3-Segment).
• Nachteil: weniger effizient, wenn es nur zwei Endpunkte sind.
• Nachteil: kann „Sondernetze“ fördern, wenn man es als Standard missbraucht.

Entscheidungskriterien: Was passt wann?

Die richtige Präfixwahl hängt nicht nur von „Adresssparen“ ab, sondern von Designzielen, Betriebsprozessen und Geräte-/Tooling-Realität. Diese Kriterien helfen bei einer sauberen Entscheidung.

• Teilnehmerzahl: 2 Endpunkte → /31 (oder /30). Mehr als 2 → /29 oder größer, oder besser: Design überdenken (Segmentierung).
• Kompatibilität: unterstützen Router/Firewalls/Transportgeräte /31 zuverlässig? Wenn ja: Standardisieren.
• Operationalisierung: können NOC-Tools, IPAM, Templates und Runbooks /31 sauber abbilden?
• Fehlerdomäne: /31 und /30 sind klar begrenzt; /29 vergrößert die gemeinsame Domäne.
• Adressknappheit: je knapper IPv4, desto größer der Nutzen von /31.

Best Practices für Provider: Link-Adressräume als eigener Rollenblock

Unabhängig davon, ob Sie /31 oder /30 nutzen: Linknetze sollten in dedizierten Prefix-Blöcken liegen, getrennt von Management, Services und Kundenpools. Das erleichtert Aggregation, Filter und Audits.

• Eigener Link-Container: pro Region/PoP ein definierter P2P-Adressblock.
• Standardpräfix festlegen: z. B. „P2P immer /31“, mit klaren Ausnahmen für Legacy.
• Dokumentation: Link-ID, Gegenstellen, Interface-Zuordnung, VRF/IGP-Kontext in IPAM pflegen.
• Routing-Policy: P2P-Blocks können in IGP-/Filterregeln gezielt behandelt werden.

Interconnects zu Firewalls und Services: /31 ist gut – aber Rückwege müssen deterministisch bleiben

Viele Provider interconnecten Firewalls, Load Balancer oder CGNAT-Systeme per P2P-Links. Hier ist /31 oft ideal, solange das Design die Stateful-Natur mancher Systeme berücksichtigt: Rückwege müssen kontrolliert sein, sonst brechen Sessions. Die Präfixwahl allein löst das nicht, aber ein klares P2P-Adressschema unterstützt deterministisches Routing.

• Stateful Systeme: Firewalls/NAT erwarten symmetrische Pfade – Routing-Design und HA-Konzept sind entscheidend.
• Transit strikt trennen: Interconnect-Netze nicht mit DMZ-/Servernetzen mischen.
• Dual Stack: für IPv6 ist /127 der direkte Analogon zu /31 im P2P-Bereich.

Typische Stolperfallen und wie Sie sie vermeiden

• /29 als „bequemer Standard“: führt zu größeren Failure Domains und IPv4-Verschwendung – nur für echte Mehrpunkt-Szenarien nutzen.
• Gemischte Standards im selben Bereich: mal /30, mal /31 ohne klare Regeln – erhöht Fehlerquote; klare Policy und Migration definieren.
• Tooling denkt classful: alte Scripts/Checks erwarten Broadcast – Runbooks und Tools auf /31 anpassen.
• Falsche Netzgrenzen: /31 hat Blockgröße 2, /30 Blockgröße 4, /29 Blockgröße 8 – Grenzen strikt einhalten.
• Dokumentation fehlt: Linknetze ohne Gegenstelle/Interface-Info – IPAM-Pflichtfelder definieren.

Schnelle Rechenhilfe: Blockgrößen für /29, /30, /31

• /29: Maske 255.255.255.248, Blockgröße 8 → Netzstarts …0, …8, …16, …24, …
• /30: Maske 255.255.255.252, Blockgröße 4 → Netzstarts …0, …4, …8, …12, …
• /31: Maske 255.255.255.254, Blockgröße 2 → Netzstarts …0, …2, …4, …6, …

Praxis-Checkliste: /31, /30 oder /29 richtig wählen

• Wenn genau 2 Endpunkte: /31 als Standard wählen, sofern Plattformen/Tools es unterstützen.
• Wenn Legacy/Tooling Einschränkungen: /30 als kompatibler Standard, aber langfristige /31-Migration prüfen.
• Wenn mehr als 2 Endpunkte im Segment: /29 (oder größer) nur bewusst einsetzen und Failure Domain bewerten.
• Link-Adressräume separieren: eigener P2P-Container pro Region/PoP, keine Vermischung mit Kunden-/DMZ-Netzen.
• Dual Stack konsequent: IPv6-P2P als /127 planen, analog zu /31.
• IPAM verpflichtend: Link-ID, Gegenstellen, Interface, VRF/IGP-Kontext als Pflichtfelder.
• Runbooks aktualisieren: Blockgrößen und Grenzen für /31 fest in Troubleshooting-Checklisten aufnehmen.

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.