Zusammenfassung

  • Keama kann erkannte Konstrukte einer ISC-DHCP-Konfiguration in eine Kea-JSON-Konfiguration überführen. Die offizielle Dokumentation behandelt die Konvertierung jedoch konstruktbezogen und releaseabhängig; nicht unterstützte oder nicht konvertierte Teile müssen geprüft und manuell bearbeitet werden.
  • Eine Produktionsmigration ist deshalb mehr als ein Formatwechsel. Betreiber müssen Keas eigenes Modell für DHCPv4 und DHCPv6, Lease-Speicher, Hochverfügbarkeit, DHCP-DDNS, Erweiterungen, Startverhalten, Überwachung und Wiederherstellung separat nachweisen.

Die Frage hinter dem Konvertierungsversprechen

Eine Konfigurationsmigration wirkt auf den ersten Blick wie eine klar begrenzte Softwareaufgabe: Quelldatei einlesen, Zieldatei erzeugen, Dienst starten. Für DHCP ist diese Abkürzung gefährlich. Eine DHCP-Umgebung besteht nicht nur aus deklarativen Zeilen. Sie umfasst Adresspools, Reservierungen, Lease-Zustand, Schnittstellen, Protokollierung, Relays, DNS-Aktualisierungen, Failover- oder Hochverfügbarkeitsbeziehungen und gegebenenfalls eigene Erweiterungen. Ein Teil davon steht in der Konfiguration, ein anderer Teil in Datenbanken, Partnerdiensten, Laufzeitbeziehungen oder betrieblichen Verfahren.

Die zentrale Frage lautet daher nicht, ob ein Werkzeug eine Datei erzeugen kann. Sie lautet: Welche Eigenschaften des laufenden Dienstes sind nach der Erzeugung tatsächlich abgebildet, welche müssen in Keas nativem Modell neu entworfen werden, und welche müssen durch Tests belegt werden?

Die Dokumentation zu keama beschreibt ein Kommandozeilenwerkzeug, das ISC-DHCP-Konfigurationen in Kea-JSON-Konfigurationen umwandelt. Sie unterscheidet dabei zwischen DHCPv4- und DHCPv6-Konvertierung. Das ist ein nützlicher Automatisierungsschritt. Es ist aber keine Zusicherung, dass jede Semantik der Quellumgebung, jeder Zustand und jedes externe Verhalten in der Zielumgebung reproduziert wurde.

Aus dieser Unterscheidung folgen drei verschiedene Grenzen. Die erste ist syntaktisch: Lässt sich ein Quellkonstrukt in eine Zielstruktur überführen? Die zweite ist semantisch: Bewirkt die Zielkonfiguration bei Anfragen, Reservierungen und Präfixen dasselbe wie die alte Umgebung? Die dritte ist betrieblich: Bleibt der Dienst bei Neustart, Partnerausfall, DNS-Problemen oder einer fehlerhaften Änderung verfügbar und wiederherstellbar? Keama adressiert vor allem die erste Grenze und Teile der zweiten. Die dritte bleibt eine Aufgabe der Migration selbst.

Was die Konvertierung bei DHCPv4 leistet – und offenlässt

Keas DHCPv4-Dokumentation beschreibt ein eigenes JSON-Modell für Servereinstellungen, Schnittstellen, Lease-Datenbanken, Protokollierung, Subnetze, Pools, Reservierungen, Optionen, Client-Klassen und Hooks. Diese Komponenten sind nicht einfach eine andere Schreibweise derselben Datei. Sie bilden den Dienst ab, den Kea anschließend ausführt.

Für ein Migrationsteam bedeutet das: Die erzeugte Datei darf zunächst nur als Kandidat für Keas natives Modell gelten. Sie muss gegen die beabsichtigte Topologie und gegen das beobachtete Verhalten des alten Dienstes geprüft werden. Ein Pool kann syntaktisch vorhanden sein und dennoch die falsche Größe, das falsche Subnetz oder eine andere Ausschlusslogik enthalten. Eine Reservierung kann übernommen aussehen und trotzdem an einer anderen Kennung, Option oder Client-Klasse hängen. Eine Schnittstelle kann in der Datei stehen, ohne dass der Start unter der tatsächlichen Netzwerkkonfiguration geprüft wurde.

Ein belastbarer Vergleich sollte mindestens die folgenden Fragen beantworten:

  • Stimmen Subnetze, Pools, Ausschlüsse und Lease-Zeiten mit dem gewünschten Betriebsverhalten überein?
  • Funktionieren feste Reservierungen sowohl für bekannte als auch für unbekannte Clients?
  • Werden Optionen und Client-Klassen in den Fällen angewendet, in denen die alte Umgebung sie verwendet hat?
  • Wird die Lease-Datenbank korrekt angelegt, geöffnet und nach Neustarts wieder verwendet?
  • Startet und lädt der Dienst mit den tatsächlichen Schnittstellen, Berechtigungen und Protokollierungszielen?
  • Sind Überwachung und Alarmierung an Keas Laufzeitverhalten angepasst, statt nur den alten Prozessnamen zu prüfen?

Diese Punkte sind keine Behauptung, dass jede Migration dieselben Fehler erzeugt. Sie sind die Konsequenz daraus, dass die Zielsoftware mehrere eigene Dienstkomponenten besitzt. Ein erfolgreicher Parserlauf beantwortet keine dieser Fragen vollständig. Er zeigt nur, dass ein Teil des Inputs in eine Zielstruktur gebracht werden konnte.

Die Dokumentation von keama weist außerdem darauf hin, dass die Unterstützung von Konstrukten begrenzt und von der jeweiligen Version abhängig ist. Nicht unterstützte oder nicht konvertierte Konstrukte verlangen Prüfung und manuelle Bearbeitung. Für Betreiber ist deshalb eine Liste der Konvertierungswarnungen wichtiger als die bloße Existenz einer Ausgabedatei. Ein ungeklärtes Konstrukt ist kein kleiner redaktioneller Rest, sondern ein offener Nachweis darüber, ob ein bestimmtes Verhalten im neuen Dienst weiter existiert.

IPv6 ist kein nachträglicher Schalter

Bei DHCPv6 wächst die Prüfaufgabe über die einfache Übertragung von Subnetzen hinaus. Keas DHCPv6-Dokumentation beschreibt ein eigenes Modell für IPv6-Subnetze, Pools, delegierte Präfixe, Optionen, Reservierungen, Lease-Speicherung und den Betrieb über Relays. Konfigurationen ohne direkte Entsprechung in Kea verlangen deshalb ein neues Design oder zumindest eine explizite Verifikation.

Das ist besonders relevant, wenn eine Umgebung gleichzeitig Adressen und Präfixe verteilt. Eine Prüfung, die nur einen einzelnen Adressbezug bestätigt, kann die Delegation eines Präfixes, die Verarbeitung eines Relays oder die Anwendung einer Option übersehen. Auch hier muss die Frage lauten, welches Verhalten die Infrastruktur benötigt, nicht nur, ob ein ähnliches Feld im JSON-Dokument vorhanden ist.

Ein IPv6-Testplan sollte daher getrennte Fälle für Adresszuweisung, Präfixdelegation, Reservierungen, Relay-Pfade und Wiederanlauf enthalten. Die Ergebnisse müssen mit dem gewünschten Netzwerkdesign verglichen werden. Wenn ein Quellkonstrukt nicht direkt abgebildet werden kann, sollte das Team festhalten, ob es durch eine Kea-Einstellung, eine andere Topologie oder eine externe Betriebslogik ersetzt wurde. Ohne diese Entscheidung bleibt die Konfiguration zwar möglicherweise gültig, aber die Migration inhaltlich unvollständig.

Zustandsdaten sind etwas anderes als Deklarationen

Der wichtigste Unterschied zwischen einer Konfigurationsdatei und einem laufenden DHCP-Dienst liegt im Zustand. Lease-Datenbanken werden in den nativen DHCPv4- und DHCPv6-Modellen ausdrücklich als eigene Dienstkomponente behandelt. Daraus folgt nicht automatisch, dass der bisherige Lease-Zustand durch die Konvertierung übertragen wird. Die vorliegenden Dokumente belegen eine Konfigurationsgrenze, aber keinen universellen Mechanismus zur Übernahme jeder bestehenden Lease-Historie.

Ein Betreiber sollte deshalb nicht annehmen, dass eine frisch erzeugte JSON-Datei eine sichere Fortsetzung des alten Zustands darstellt. Vor einem Wechsel muss geklärt werden, welche Lease-Informationen erhalten bleiben müssen, ob sie in einem kompatiblen Format vorliegen, wie Konflikte behandelt werden und wie ein Rollback aussehen würde. Wenn eine Umgebung während des Wechsels weiter Adressen vergibt, ist außerdem zu prüfen, wie Doppelzuweisungen, veraltete Reservierungen und gleichzeitig aktive Server verhindert werden.

Das ist ein operatives Risiko, keine pauschale Aussage über ein bestimmtes Produktverhalten. Die Dokumentation liefert hier keine gemessene Ausfallrate und keinen für alle Installationen gültigen Zeitplan. Sie macht aber sichtbar, dass Lease-Speicher zum Dienstmodell gehört und deshalb nicht mit der Konfigurationsdatei gleichgesetzt werden darf.

Hochverfügbarkeit muss neu nachgewiesen werden

Eine besonders klare Grenze zeigt sich bei der Ausfallsicherheit. Keas Dokumentation zur Hochverfügbarkeit beschreibt Hochverfügbarkeit über einen eigenen HA-Hook und eine eigene Konfiguration. Partnerkommunikation, Rollen oder Modi, Synchronisierung und Ausfalltests sind darin eigenständige Bestandteile. Sie sind nicht einfach die direkte Wiederverwendung von ISC-DHCP-Failover-Peer-Deklarationen.

Für eine Migration bedeutet das, dass ein aus der alten Umgebung bekanntes Failover-Verhalten nicht allein deshalb weiterbesteht, weil die Server- und Pooldefinitionen konvertiert wurden. Das Team muss die Partnerbeziehung in Keas Modell abbilden, die Kommunikationswege prüfen und festlegen, welcher Server in welchem Zustand welche Verantwortung übernimmt. Danach braucht es Tests, die nicht nur den Normalbetrieb, sondern auch Unterbrechungen und die Rückkehr eines Partners abdecken.

Ein sinnvoller Nachweis umfasst mindestens:

  • den Aufbau der Partnerverbindung unter den realen Netzwerkbedingungen;
  • die Synchronisierung relevanter Zustände;
  • das Verhalten bei Ausfall des aktiven Partners;
  • die Wiederaufnahme eines zurückkehrenden Partners;
  • die Behandlung von Änderungen während der Störung;
  • die eindeutige Entscheidung, wann ein Rollback oder ein manueller Eingriff erforderlich ist.

Ein grüner Prozessstatus oder eine formal akzeptierte Konfiguration ist dabei kein Beweis für eine funktionierende Ausfallstrategie. Hochverfügbarkeit ist eine zeitliche Beziehung zwischen Diensten. Sie kann nur durch Zustands- und Fehlerprüfungen beurteilt werden.

DHCP-DDNS liegt neben der Konvertierung

Viele DHCP-Umgebungen sind nicht nur für Adresszuweisung zuständig. Sie aktualisieren auch DNS-Einträge. Keas Dokumentation zu DHCP-DDNS beschreibt dafür den separaten D2-Dienst mit eigener Konfiguration und einem Kommunikationsendpunkt. DNS-Aktualisierungsregeln, Zugangsdaten, Zonen, Erreichbarkeit und die Prüfung von Vorwärts- und Rückwärtsaktualisierungen werden dadurch zu einem eigenen Migrationspfad.

Die Konsequenz ist praktisch: Eine konvertierte DHCP-Konfiguration kann den Adressbezug scheinbar korrekt bedienen und trotzdem eine unvollständige DNS-Integration hinterlassen. Die Prüfungen müssen deshalb beide Richtungen umfassen. Ein Team sollte feststellen, ob ein neuer Lease die erwartete Vorwärtsauflösung erzeugt, ob eine Freigabe oder Änderung die Rückwärtsauflösung korrekt behandelt und wie sich ein nicht erreichbarer D2-Dienst auf den DHCP-Betrieb auswirkt.

Auch Zugangsdaten und Zonen gehören in den Nachweis. Sie sind nicht bloß Textfelder, die aus einer alten Datei kopiert werden können. Sie müssen in Keas Dienstbeziehung, in die Sicherheitskontrollen und in die tatsächliche Erreichbarkeit der DNS-Infrastruktur passen. Erst wenn diese Kette getestet ist, lässt sich sagen, dass DHCP und DNS gemeinsam migriert wurden.

Erweiterungen können Verhalten verbergen

Die Dokumentation zu Keas Hook-Bibliotheken beschreibt Hooks als Erweiterungsmechanismus. Ereignisbehandlung, eigene Skripte oder anderes ausführbares Verhalten aus einer ISC-DHCP-Umgebung besitzen möglicherweise keine direkte keama-Abbildung. Sie können eine manuelle Neuimplementierung über einen passenden Hook oder eine externe Integration erfordern, gefolgt von Konfigurations- und Betriebstests.

Das ist der Bereich, in dem eine kurze Konfiguration besonders irreführend sein kann. Eine kleine externe Routine kann für Abrechnung, Zugriffskontrolle, Inventarisierung oder ein lokales Provisioning entscheidend sein, obwohl sie in der Hauptkonfiguration kaum auffällt. Wird sie beim Wechsel vergessen, funktioniert der Kernprozess vielleicht weiterhin, während ein nachgelagerter Geschäfts- oder Sicherheitsprozess ausfällt.

Die richtige Frage lautet deshalb nicht nur, ob ein altes Skript in Kea syntaktisch vorkommt. Das Team muss jedes relevante Ereignis, seine Eingaben, seine Nebenwirkungen und seine Fehlerbehandlung erfassen. Anschließend muss es entscheiden, ob die Funktion durch einen Kea-Hook, einen externen Dienst oder bewusst nicht mehr ersetzt wird. Die letzte Option ist zulässig, aber sie muss eine bewusste Betriebsentscheidung sein und darf nicht als stiller Nebeneffekt der Konvertierung erscheinen.

Ein prüfbarer Übergang statt eines einmaligen Imports

Aus den einzelnen Grenzen lässt sich ein praktikabler Migrationsablauf ableiten. Er ist keine universelle Produktvorgabe, sondern eine Kontrollstruktur für Betreiber:

Erstens: Verhalten und Abhängigkeiten inventarisieren. Vor der Konvertierung sollten die verwendeten DHCPv4- und DHCPv6-Funktionen, Lease-Speicher, Reservierungen, Relays, DNS-Beziehungen, HA-Partner und Erweiterungen dokumentiert werden. Entscheidend ist nicht nur, was in einer Datei steht, sondern welche Antwort- und Wiederherstellungswege im Betrieb erwartet werden.

Zweitens: IPv4 und IPv6 getrennt bewerten. Die beiden Kea-Modelle haben unterschiedliche Prüfgegenstände. Ein gemeinsamer Importauftrag darf nicht zu einem gemeinsamen, undifferenzierten Abnahmekriterium führen.

Drittens: Konvertierungsgrenzen markieren. Jede Warnung, jedes nicht unterstützte Konstrukt und jede manuelle Änderung sollte mit einer Entscheidung verbunden werden: direkte Abbildung, redesignte Funktion, externe Integration oder bewusster Verzicht. Ohne diese Zuordnung bleibt der offene Rest unsichtbar.

Viertens: Das native Kea-Modell prüfen. Servereinstellungen, Schnittstellen, Pools, Reservierungen, Optionen, Client-Klassen, Lease-Datenbanken, Protokollierung und Hooks müssen gegen die gewünschte Zielarchitektur geprüft werden. Die Frage ist, ob Kea den vorgesehenen Dienst ausführt, nicht ob die Datei der alten Datei ähnelt.

Fünftens: Zustands- und Nebendienste testen. Lease-Verhalten, DHCP-DDNS, DNS-Zonen und Zugangsdaten benötigen eigene Tests. Für IPv6 kommen Präfixdelegation und Relay-Pfade hinzu.

Sechstens: Fehler und Wiederherstellung simulieren. HA-Partner, D2-Erreichbarkeit, Neustarts, Änderungen während einer Störung und die Rückkehr eines ausgefallenen Systems müssen in einer kontrollierten Umgebung geprüft werden. Die Ergebnisse sollten festhalten, wer welche Entscheidung trifft, wenn der Test nicht wie erwartet endet.

Siebtens: Rollback und Überwachung abnehmen. Ein Wechsel ist erst dann betrieblich belastbar, wenn ein Rückweg existiert und die Überwachung den neuen Dienst tatsächlich beobachtet. Das umfasst Start, Reload, Lease-Zustand, DNS-Verhalten, Partnerstatus und die relevanten Erweiterungen.

Dieser Ablauf verschiebt die Aufmerksamkeit von der Datei auf den Dienst. Das ist der eigentliche Wert der Konvertierung: Sie kann wiederholbare mechanische Arbeit reduzieren und damit Zeit für die Prüfung freimachen. Sie nimmt dem Betreiber aber nicht die Verantwortung ab, die verbleibenden Funktionen und Zustände zu beweisen.

Was die ISC-Dokumentation belegt – und was nicht

Die öffentlich dokumentierten Komponenten zeigen, wie Kea-Konfiguration, DHCPv4, DHCPv6, Hochverfügbarkeit, DHCP-DDNS und Hooks zusammenspielen können. Sie belegen damit wichtige technische Grenzen. Sie belegen aber nicht den Erfolg oder Misserfolg der Migration eines bestimmten Betreibers. Ebenso liefern sie keine allgemeine Ausfallrate, keinen universellen Zeitbedarf und keinen Beweis, dass jede Installation dieselbe HA-, D2- oder Hook-Architektur benötigt.

Diese Grenze ist für die Zuschreibung wichtig. ISC stellt Software und Dokumentation bereit. Der Betreiber entscheidet über Topologie, Zustandsübernahme, Zugangsdaten, Testtiefe, Rollback und die Freigabe für den Produktionsverkehr. Wenn eine Konfiguration konvertiert wurde, ist das daher kein Nachweis für eine vollständige Migration durch ISC und auch kein Nachweis für die Einsatzbereitschaft beim Betreiber.

Die Kausalität ist dennoch klar genug, um eine strategische Aussage zu tragen: Automatisierung entfernt einen Teil der manuellen Übertragung, verlagert das Risiko aber auf die nicht rein mechanischen Teile des Übergangs. Je mehr eine Umgebung von Lease-Zustand, Partnerkoordination, DNS-Nebenbedingungen oder eigenen Erweiterungen abhängt, desto größer ist der Abstand zwischen erzeugter Konfiguration und bewiesenem Dienstverhalten.

Die eigentliche Betriebsgrenze

Keama ist deshalb weder ein Scheinwerkzeug noch eine vollständige Migrationsgarantie. Sein Wert liegt darin, erkannte Konfigurationskonstrukte in eine Kea-nahe Form zu bringen und damit die mechanische Ausgangsarbeit zu verkürzen. Seine Grenze liegt darin, dass Dienstsemantik, Laufzeitzustand, Nebenservices, Ausfallsicherheit und lokale Erweiterungen nicht allein aus dem Vorhandensein einer JSON-Datei folgen.

Ein Betreiber kann die Migration als abgeschlossen behandeln, wenn die offenen Konstrukte bewertet, das native Kea-Modell geprüft, der Zustand und die Nebenservices nachvollziehbar behandelt, die Ausfallpfade getestet und die Beobachtung im Zielbetrieb eingerichtet sind. Was nicht getestet wurde, sollte als Annahme bezeichnet werden. Was nur aus der Konfigurationsähnlichkeit abgeleitet wurde, sollte nicht als bewiesene Kontinuität gelten.

Die entscheidende Verschiebung lautet damit: Nicht die Konvertierung ist der Produktionswechsel. Sie ist der Anfang eines Nachweises, dass ein anderer Dienst dieselben oder bewusst neu definierten Aufgaben zuverlässig erfüllt.