Das lernst du
- Poolbedarf aus Gleichzeitigkeit und Gerätewechsel herleiten.
- Grenzen einfacher Modelle und sinnvolle Warnschwellen benennen.
Voraussetzungen: G07 · Adressplanung mit ReserveG08 · Lease: Nutzung auf ZeitF05 · T1, T2 und Lease-Ablauf
80 gleichzeitig verbundene Gäste können mehr als 80 gültige Leases erzeugen. Alte Nutzungsrechte bleiben nach dem Weggang häufig bestehen, während neue Identitäten hinzukommen.
Anwesend ist nicht gleich gebunden
Grafik vergrößern
Ein Modell mit ausdrücklichen Annahmen
Ein einfaches stationäres Näherungsmodell lautet: zusätzliche gehaltene Leases ≈ Abgangsrate ohne RELEASE × mittlere Restlaufzeit. Es setzt ungefähr gleichmäßige Ankünfte/Abgänge und ein bekanntes Verhalten voraus. Bei Veranstaltungen, zufälligen Identitäten und plötzlichen Lastspitzen kann es deutlich danebenliegen.
Die benötigte Menge enthält aktive Identitäten, noch gehaltene Leases, Reservierungen und Betriebsreserve. Eine kürzere Lease kann die gehaltenen Altbestände reduzieren, erhöht aber Erneuerungsverkehr und Abhängigkeit vom Dienst. Ein größerer Adressraum ersetzt keine Beobachtung von Rate und Verteilung.
Messwerte und Warnungen
Überwache mindestens freie/vergebene Adressen je Scope, Vergabe- und Fehlerrate, DECLINEs, Dienst- und Partnerstatus, Relaypfade sowie DNS-Updatefehler. Ein globaler Gesamtwert verdeckt einen einzelnen erschöpften Bereich.
Eine Warnung bei 80 % Belegung kann ein Ausgangspunkt sein, ist aber keine universelle Sicherheitsgrenze. Ein Scope mit 20 freien Plätzen und 40 neuen Identitäten pro Minute verlangt eine andere Reaktion als ein ruhiges Büro. Schwellen sollten Handlungsspielraum in Zeit und Adressen ausdrücken.
Belegung als Verlauf statt einzelner Prozentzahl messen
Eine Momentaufnahme von 60 Prozent Auslastung kann harmlos wirken, obwohl kurz darauf ein kompletter Veranstaltungsblock eintrifft. Erfasse deshalb Spitzen, neue Identitäten pro Zeit, ablaufende Leases und konfliktbedingt gesperrte Adressen. Ein hohes Verhältnis gebundener zu aktuell sichtbaren Clients kann durch lange Leases und häufige Wechsel entstehen; es beweist noch keinen Angriff.
In einem vereinfachten Modell kommen jede Stunde 30 neue, nicht wiederkehrende Gäste hinzu und behalten ihre vierstündige Lease ohne Freigabe. Nach dem Hochlauf sind ungefähr 120 Adressen zeitlich gebunden, selbst wenn die tatsächliche Anwesenheit kürzer ist. Das Modell setzt gleichmäßigen Zugang und keine Erneuerungen voraus. Werden diese Annahmen verletzt, muss die Rechnung angepasst statt als feste Kapazitätsformel verwendet werden.
Ausfallreserve und Reaktionszeit zusammen planen
Wenn ein Alarm erst bei der letzten freien Adresse auslöst, bleibt keine Zeit für Prüfung und geordnete Erweiterung. Lege deshalb eine Warnschwelle anhand der Wachstumsrate und der realistischen Reaktionsdauer fest. Ein Bereich mit zehn freien Adressen und einem neuen Client pro Minute benötigt eine andere Reaktion als derselbe freie Bestand in einem stabilen Druckernetz.
Prüfe zusätzlich, welche Kapazität in einem Ausfallzustand tatsächlich verfügbar bleibt. Ein HA-Produkt kann Verantwortung zeitweise begrenzen; ein Split-Scope stellt nicht automatisch beide Teilmengen über den verbleibenden Server bereit. Dokumentiere Normal- und Fehlerfall getrennt und teste neue Bezüge unter diesen Bedingungen. Eine geplante Reserve zählt nur dann, wenn sie im benötigten Zustand auch nutzbar ist.
Gästenetz mit Wechselverkehr
- 120 aktive Gäste, Abgangsrate ohne RELEASE etwa 20 pro Stunde, mittlere Restlaufzeit zwei Stunden: grob 40 zusätzlich gehaltene Leases.
- Mit 20 Plätzen Reserve und 5 reservierten Geräten ergibt die Näherung 120+40+20+5=185 Adressen. Ein /25 ist zu klein; ein geeignet geplantes /24 kann reichen.
- Ein Event erzeugt in zehn Minuten 90 neue Identitäten. Die stationäre Näherung ist dafür unzureichend. Zeitreihen und ein Last-/Spitzenplan ergänzen.
- Vergleiche eine kürzere Guest-Lease mit größerem Pool und begründe die Entscheidung anhand von Wiederverwendung, Ausfalltoleranz und Messwerten.
Ergebnis: Das Modell macht Annahmen sichtbar. Eine gemessene Spitzenlast entscheidet, ob die Planung auch außerhalb des Durchschnitts trägt.
Typische Fehler
- Aktive Geräte und gültige Leases sind nicht dieselbe Zahl.
- Prozentwerte ohne absolute Restkapazität können täuschen.
- Zufällige MACs können Identitätswechsel stark erhöhen.
Praktisch anwenden
Offizielle Quellen
Versionsbezüge geprüft am 14. Oktober 2026. Produktkonfigurationen werden im jeweiligen isolierten Labor validiert.
- RFC 2131 · DHCPv4 ↗Protokollbasis, insbesondere §§ 3 und 4; März 1997
- ISC · Kea DHCPv4 Server ↗Festes Lehrprofil: Kea 3.0.2; keine Annahme, dass dies die neueste Version ist
- Microsoft · DHCP-Failover ↗Windows Server 2025; DHCPv4, nicht DHCPv6