Der Adressplan als verbindliche Grundlage für das ganze Netz

Warum gewachsene Netze kollidieren

Kollisionen entstehen fast nie im eigenen Netz, sondern an seinen Rändern. Der häufigste Fall ist das Homeoffice: Viele Heimrouter verwenden 192.168.0.0/24, 192.168.1.0/24 oder 192.168.178.0/24. Liegen interne Netze in denselben Bereichen, kann der Client das Ziel im Firmennetz nicht vom eigenen Heimnetz unterscheiden, und die VPN-Route verliert gegen die direkt angeschlossene.

Der zweite Fall sind Partner und Dienstleister. Zwei Unternehmen, die beide in 10.0.0.0/16 begonnen haben, können ohne NAT kein Site-to-Site-VPN aufbauen, wenn auf beiden Seiten dieselben Netze angesprochen werden müssen. NAT löst das technisch, macht aber jede Fehlersuche und jedes Log schwerer lesbar, weil Adressen auf dem Weg ihre Bedeutung wechseln.

Der dritte Fall sind Fusionen und Container-Plattformen. Bei einer Übernahme treffen zwei Adresspläne aufeinander, die beide gute Gründe hatten. Und Docker legt sein Standard-Bridge-Netz in 172.17.0.0/16; wer interne Server in diesem Bereich betreibt, erlebt auf Docker-Hosts Routen, die plötzlich auf die lokale Bridge zeigen.

Der Bereich 100.64.0.0/10 ist übrigens keine Ausweichlösung. RFC 6598 reserviert ihn als Shared Address Space für Provider mit Carrier-Grade NAT und warnt ausdrücklich, dass eine andere Nutzung Probleme bereitet, sobald der Anschluss selbst über CGN läuft.

Schema-Entscheidungen: Bereich, Standortbits und Reserven

Für die meisten Unternehmen ist 10.0.0.0/8 die richtige Wahl, weil er 16 Millionen Adressen bietet und eine klare Hierarchie zulässt. Ein bewährtes Muster nutzt das zweite Oktett für den Standort und das dritte für die Funktion. Ein /16 je Standort ist großzügig, aber genau diese Großzügigkeit macht den Plan lesbar und lässt Platz für Wachstum.

Wer Regionen zusammenfassen will, teilt das zweite Oktett in Region und Standort, etwa vier Bits für die Region und vier für den Standort, also 16 Regionen mit je bis zu 16 Standorten. Dann lässt sich jede Region mit einer einzigen Route zusammenfassen, und Firewall-Regeln zwischen Regionen werden kurz. Wer mehr Standorte erwartet, als das zweite Oktett hergibt, gibt kleinen Standorten statt eines /16 nur ein /20 oder /18.

Lege Reserven bewusst an und nenne sie so. Ein Block, der im IPAM als reserviert für Übernahmen oder für Cloud-Netze markiert ist, wird nicht aus Versehen vergeben. Ein Block, der einfach frei ist, wird es irgendwann.

Der Vergabeprozess vom Antrag bis zum Gerät

Die Reihenfolge entscheidet darüber, ob das IPAM aktuell bleibt. Solange Netze zuerst auf dem Gerät und erst danach in der Dokumentation entstehen, hinkt die Dokumentation immer hinterher. Wenn der Eintrag im IPAM der erste Schritt ist, kann die Konfiguration sogar daraus erzeugt werden.

1. 1

   Antrag mit Zweck und Größe

   Wer ein Netz oder eine feste Adresse braucht, nennt Standort, Funktion, erwartete Gerätezahl und eine verantwortliche Person. Ein Formular oder ein Ticket-Template reicht, wichtig ist, dass die Angaben vollständig sind.

2. 2

   Block im IPAM reservieren

   Das Netzwerkteam nimmt den nächsten freien Block passender Größe aus dem Container des Standorts und setzt ihn auf reserviert. Damit kann niemand denselben Block parallel vergeben.

3. 3

   Konfiguration und DNS

   Erst jetzt entstehen VLAN, Interface, DHCP-Bereich und DNS-Einträge. Wer automatisiert, liest die Werte direkt aus dem IPAM, etwa über die NetBox-API oder ein Ansible-Inventory.

4. 4

   Status auf aktiv setzen

   Nach dem erfolgreichen Test wechselt der Block auf aktiv. Ein Block, der nach einer Frist noch auf reserviert steht, ist ein Hinweis auf einen abgebrochenen Antrag und wird nachgefragt.

NetBox als Source of Truth statt Tabellenkalkulation

Eine Tabelle kann Adressen auflisten, aber sie kann keine Hierarchie durchsetzen und keine Überlappung verhindern. NetBox modelliert Präfixe mit Status, Rolle, VRF, VLAN und einem Geltungsbereich wie Standort oder Region. Ein Präfix mit dem Status Container gruppiert untergeordnete Präfixe, und die Auslastung eines Blocks berechnet NetBox aus den enthaltenen Präfixen und Adressen. Über VRFs lassen sich auch überlappende Bereiche sauber trennen, etwa bei einem übernommenen Netz, das vorübergehend parallel läuft.

Den eigentlichen Nutzen bringt die API. Über den Endpunkt für verfügbare Präfixe fragt ein Skript den nächsten freien Block passender Größe ab und legt ihn im selben Schritt an. Dasselbe gibt es für einzelne Adressen. So entsteht kein Zeitfenster, in dem zwei Personen denselben Block für frei halten.

Der Abgleich mit DHCP und DNS ist der Teil, an dem IPAM-Projekte scheitern, wenn er nicht automatisiert ist. Ein Skript, das täglich DHCP-Leases und DNS-Einträge mit dem IPAM vergleicht und Abweichungen als Liste meldet, ist wertvoller als jede Pflegeanweisung. Die Abweichungen werden dann im IPAM korrigiert, nicht am Gerät stillschweigend hingenommen.

import pynetbox

nb = pynetbox.api("https://netbox.example.internal", token="<API-Token>")

# Container des Standorts 12
standort = nb.ipam.prefixes.get(prefix="10.12.0.0/16")

# Nächsten freien /24 anlegen und reservieren
neu = standort.available_prefixes.create({
    "prefix_length": 24,
    "status": "reserved",
    "description": "VLAN 140 Drucker 2. OG, Ticket NET-4711",
})
print(neu.prefix)

# Erste freie Adresse daraus für das Gateway vergeben
gw = neu.available_ips.create({"description": "Gateway VLAN 140"})
print(gw.address)

IPv6 im selben Plan mitdenken

RFC 6177 hat die frühere Empfehlung eines festen /48 für jedes Endkundennetz aufgehoben. Es betont aber, dass ein einzelnes /64 für einen Standort nicht reicht und Standorte in aller Regel deutlich mehr bekommen sollen. Das RIPE-Dokument 690 zur Präfixvergabe nennt als eine gängige Option /48 für Geschäftskunden und /56 für Privatkunden. Es hält außerdem fest, dass jedes LAN-Segment mindestens ein /64 braucht und Präfixe an Nibble-Grenzen enden sollten, also an Vielfachen von 4.

Mit einem /48 je Standort hast du 16 Bit für Subnetze, das sind 65.536 Netze der Größe /64. Diese 16 Bit lassen sich wie eine Hexadezimalzahl mit vier Stellen lesen, und genau das macht IPv6-Pläne übersichtlich: Eine Stelle steht für den Zweck, die drei übrigen für die VLAN-Nummer, so dass 1020 Clients in VLAN 20 bezeichnet. Eine Stelle entspricht einem Nibble, deshalb bleiben alle Grenzen sauber lesbar.

RIPE-690 empfiehlt außerdem persistente Präfixe als Normalfall. Für Unternehmen heißt das: Ein Präfix, das sich bei jedem Neustart des Anschlusses ändert, taugt nicht für Firewall-Regeln und Adresspläne. Kläre die Präfixgröße und ihre Beständigkeit mit dem Provider, bevor der Plan entsteht.

Pflegeregeln und Review-Takt

Ein Plan bleibt verlässlich, wenn wenige klare Regeln gelten und ihre Einhaltung gemessen wird. Ausnahmen gibt es, aber sie stehen im IPAM mit Begründung und Ablaufdatum.

• Kein Netz ohne IPAM-Eintrag

  Ein VLAN-Interface oder DHCP-Bereich, der im IPAM fehlt, gilt als Fehler und wird beim nächsten Abgleich gemeldet. Automatisierte Konfiguration aus dem IPAM macht die Regel fast von selbst wahr.

• Feste Adressen nur außerhalb des DHCP-Bereichs

  Statische Adressen und Reservierungen liegen in einem festgelegten Teil des Netzes, der DHCP-Pool überlappt damit nie. Wo Geräte es erlauben, sind Reservierungen statischen Einträgen am Gerät vorzuziehen.

• Jeder Eintrag hat eine zuständige Person

  Eine Adresse ohne Ansprechpartner lässt sich nicht bereinigen. Pflichtfelder im IPAM für Zuständigkeit und Ticket-Referenz sind ein kleiner Aufwand mit großer Wirkung.

• Vierteljährlicher Abgleich mit der Realität

  ARP-Tabellen der Gateways, DHCP-Leases und DNS werden mit dem IPAM verglichen. Einträge ohne Aktivität seit 90 Tagen gehen an die zuständige Person mit der Frage, ob sie noch gebraucht werden.

• Jährlicher Blick auf das Schema

  Einmal im Jahr prüft die Netzwerkarchitektur, ob Reserven reichen, ob neue Standorte oder Cloud-Umgebungen anstehen und ob das Schema noch zur Organisation passt.

Checkliste für den Start

Wer mit einem gewachsenen Netz beginnt, braucht keinen perfekten Plan am ersten Tag. Wichtiger ist, dass der Ist-Zustand erfasst ist und neue Vergaben ab sofort nach dem neuen Schema laufen. Die Migration alter Netze folgt dann in Etappen, etwa bei ohnehin anstehenden Umbauten.

1. 1

   Ist-Zustand erfassen

   Importiere alle Netze aus Routingtabellen, DHCP-Servern, Firewalls und Cloud-Konsolen ins IPAM, auch die unschönen.

2. 2

   Kollisionen mit außen prüfen

   Lege Partner-VPNs, Cloud-Netze, Docker-Hosts und typische Heimnetze gegen die eigenen Bereiche und notiere jede Überlappung.

3. 3

   Schema beschließen

   Halte Bereich, Standort- und Funktionsbits, Reserven und IPv6-Aufteilung schriftlich fest und lass das Schema von der IT-Leitung bestätigen.

4. 4

   Rollen benennen

   Trage für Genehmigung, Vergabe und Bereinigung je eine Person oder ein Team ein, jeweils mit Stellvertretung.

5. 5

   Abgleich automatisieren

   Richte vor dem ersten Review ein Skript ein, das das IPAM mit DHCP, DNS und ARP vergleicht.

6. 6

   Neue Vergaben nur noch nach Schema

   Ab einem Stichtag entsteht jedes neue Netz aus dem IPAM, alte Netze werden bei Umbauten nachgezogen.