So migrieren Sie Ihre IP-Infrastruktur ohne Ausfallzeit auf geleastes IPv4

IP-Migrationen bringen eine besondere Art von Stress mit sich. Anders als die meisten Infrastrukturänderungen, die sich in Sekunden zurückrollen lassen, berührt der Umzug auf eine neue IP-Adresse alles – DNS-Einträge, Firewall-Regeln, BGP-Routen, Anwendungskonfigurationen, Monitoring-Systeme und die Erwartungen jedes Nutzers und Dienstes, der sich mit Ihnen verbindet. Gehen Sie nachlässig vor, bekommen Sie keine Warnung. Sie bekommen einen Ausfall.

Die gute Nachricht: Eine gut geplante IPv4-Migration auf ein geleastes Subnetz lässt sich ohne Dienstunterbrechung durchführen. Der Unterschied zwischen einer reibungslosen Umstellung und einem Produktionsvorfall ist fast nie technisches Können – es sind Vorbereitung, Reihenfolge und Timing. Dieser Leitfaden behandelt alle drei.

Ob Sie zum ersten Mal auf einen geleasten IPv4-Block umziehen oder Subnetze innerhalb eines bestehenden Leasings neu zuweisen: Die folgenden Schritte geben Ihnen einen verlässlichen Rahmen, um IPs ohne Ausfallzeit zu wechseln.

Checkliste vor der Migration

Bevor die technische Konfiguration beginnt, brauchen Sie ein vollständiges Bild dessen, was sich ändern wird. Diesen Schritt zu überspringen ist der häufigste Grund, warum IP-Migrationen ungeplante Vorfälle verursachen.

Details Ihres geleasten Subnetzes bestätigen

Beginnen Sie mit den Grundlagen: CIDR-Notation, Subnetzgröße und alle Details Ihres Leasingvertrags. Ihre Subnetzkonfiguration bei IPbnb zeigt das genaue Ihnen zugewiesene Präfix, die Angaben zum IP-Eigentümer und die Laufzeit. Stellen Sie sicher, dass diese Informationen korrekt sind, bevor Sie irgendetwas anderes tun.

Bestätigen Sie außerdem:

• Ob der IP-Eigentümer eine Route Origin Authorization (ROA) für Ihr Subnetz und Ihre ASN angelegt hat. Ohne gültige ROA im RPKI kann Ihr Präfix von RPKI-validierenden Peers gefiltert werden.

• Ob in der zuständigen Routing-Registry ein IRR-Route-Objekt existiert. Für von RIPE verwaltete Ressourcen ist das die RIPE-Datenbank.

Ihre aktuellen IP-Abhängigkeiten erfassen

Erstellen Sie eine vollständige Liste aller Systeme, Dienste und Konfigurationen, die auf Ihre aktuellen IP-Adressen verweisen. Dazu gehören:

• Alle DNS-A-Einträge und PTR-Einträge (Reverse DNS), die auf aktuelle IPs zeigen

• Firewall- und Zugriffsregeln mit aktuellen Adressen

• Anwendungskonfigurationsdateien mit fest eingetragenen IPs

• Monitoring- und Alarmsysteme, die aktuelle Adressen überwachen

• Konfigurationen von Drittdiensten (CDNs, DDoS-Schutz, Zahlungsdienstleister)

• Konfigurationen von BGP-Peers und Upstream-Providern

• SPF-Einträge, falls Ihr Subnetz ausgehende E-Mails versendet

Diese Erfassung ist mühsam. Sie ist auch der Teil, der Sie um 3 Uhr nachts rettet.

Reputation Ihres neuen Subnetzes prüfen

Geleaste IPv4-Blöcke haben eine Vergangenheit. Bevor Sie Produktionstraffic auf Ihr neues Subnetz verlagern, prüfen Sie seinen Status in den wichtigsten IP-Reputationsdatenbanken: Spamhaus, Talos Intelligence, MXToolbox und AbuseIPDB. Ein Block mit schlechter Reputation kann Filter bei Mailservern, CDNs oder Sicherheits-Appliances auslösen, noch bevor Sie die Migration abgeschlossen haben. Finden Sie Reputationsprobleme, beheben Sie sie vor dem Migrationsfenster – nicht danach.

Rollback-Plan festlegen

Jeder Migrationsplan braucht einen Ausstieg. Dokumentieren Sie vor dem Start genau, wie Sie zu Ihrem alten Subnetz zurückkehren, falls etwas schiefgeht. Das bedeutet, Ihre alten IP-Adressen während des gesamten Migrationsfensters aktiv und routbar zu halten – nicht nur während der eigentlichen Umstellung.

DNS-TTL vorbereiten

Die DNS-TTL (Time to Live) legt fest, wie lange Resolver einen Eintrag zwischenspeichern, bevor sie nach einer Aktualisierung fragen. Bei einer IPv4-Migration bestimmt die TTL, wie schnell sich Ihre DNS-Änderungen im Internet verbreiten – und damit, wie lang das Übergangsfenster tatsächlich ist.

Warum die TTL wichtig ist

Haben Ihre aktuellen A-Einträge eine TTL von 86.400 Sekunden (24 Stunden), können Resolver weltweit selbst nach der Aktualisierung auf Ihr neues Subnetz bis zu 24 Stunden lang die alte IP-Adresse ausliefern. In diesem Zeitraum erreicht ein Teil des Traffics Ihre alten Adressen, ein Teil die neuen. Ist Ihr altes Subnetz nicht mehr aktiv, geht der Traffic zu den alten Adressen schlicht verloren.

Die Lösung: die TTL lange vor der Migration senken.

So bereiten Sie vor

Senken Sie Ihre TTL auf 300 Sekunden (5 Minuten) – bei kritischen Einträgen bis auf 60 Sekunden –, mindestens einen vollen TTL-Zyklus vor Beginn Ihres Migrationsfensters. Der Zeitpunkt hängt ganz von Ihrem aktuellen TTL-Wert ab:

• Beträgt Ihre aktuelle TTL 86.400 s (24 Stunden), senken Sie sie mindestens 24 Stunden vor der Migration

• Beträgt Ihre aktuelle TTL 3.600 s (1 Stunde), senken Sie sie mindestens 1 Stunde vor der Migration

Warten Sie nach dem Senken die volle Dauer ab, bevor Sie IP-Änderungen vornehmen. So hält bei der Aktualisierung Ihrer Einträge kein Resolver mehr eine zwischengespeicherte Kopie des alten Werts.

Welche Einträge zu aktualisieren sind

• A-Einträge: direkte Zuordnungen von Hostname zu IP – das Hauptziel jeder IP-Migration

• PTR-Einträge: Reverse-DNS-Einträge, die IP-Adressen Hostnamen zuordnen. In der RIPE-Region wird die Reverse-DNS-Delegation über die RIPE-Datenbank verwaltet – der IP-Eigentümer oder die LIR, die die Ressource verwaltet, legt ein domain-Objekt an, das auf Ihre Nameserver verweist. Das geschieht nicht automatisch und erfordert eine ausdrückliche Abstimmung mit Ihrem IP-Eigentümer vor dem Migrationsfenster, nicht währenddessen. Sprechen Sie das in der Vorbereitungsphase an.

• SPF-Einträge: Wird Ihr Subnetz für den E-Mail-Versand genutzt, nehmen Sie das neue Präfix in Ihren SPF-Eintrag auf und entfernen das alte

Sobald die Migration abgeschlossen und stabil ist, setzen Sie die TTL wieder auf einen höheren Wert (3.600 Sekunden oder mehr). Eine niedrige TTL erhöht das DNS-Abfragevolumen und sollte nicht dauerhaft bestehen bleiben.

BGP-Ankündigung einrichten

Wenn Sie Ihren geleasten IPv4-Block per BGP ankündigen – direkt aus Ihrer eigenen Infrastruktur oder über eine BYOIP-Vereinbarung mit einem Cloud-Anbieter –, muss das Routing-Setup abgeschlossen und geprüft sein, bevor Traffic auf das neue Subnetz gelenkt wird.

RPKI und ROA

Die Route Origin Authorization (ROA) ist der Mechanismus, der eine bestimmte ASN autorisiert, ein bestimmtes Präfix in BGP zu originieren. In der RIPE-Region werden ROAs vom Ressourceninhaber angelegt – also vom IP-Eigentümer, nicht vom IP-Mieter. Bestätigen Sie vor der Migration mit Ihrem IP-Eigentümer, dass eine ROA für Ihr Präfix und Ihre ASN mit der korrekten maximalen Präfixlänge existiert.

Den ROA-Status prüfen Sie mit dem RPKI-Validator des RIPE NCC, Cloudflares RPKI Toolkit oder Routinator. Eine fehlende ROA lässt Ihr Präfix im Zustand UNKNOWN, den die meisten Netzwerke akzeptieren, manche konservativen Peers aber filtern. Eine falsche ROA – falsche ASN oder maximale Präfixlänge – markiert es als INVALID und führt zur aktiven Filterung durch alle RPKI-validierenden Peers. Der Unterschied zählt: Unknown und Invalid sind zwei verschiedene Probleme mit zwei verschiedenen Lösungen.

IRR-Route-Objekte

Über RPKI hinaus filtern viele Netzwerke BGP-Ankündigungen anhand von IRR-Daten (Internet Routing Registry). Für von RIPE verwaltete Präfixe sollten Route-Objekte in der RIPE-Datenbank registriert sein. Bestätigen Sie, dass für Ihr Präfix ein Route-Objekt mit der richtigen Origin-ASN existiert. Fehlt es, muss es angelegt werden – in der Regel vom IP-Eigentümer oder der RIPE-LIR, die die Ressource verwaltet.

Das Präfix ankündigen

Sobald ROA und IRR-Objekte vorhanden sind, konfigurieren Sie Ihre BGP-Session für die Ankündigung des neuen Präfixes. Testen Sie die Ankündigung vor der Migration mit einem BGP Looking Glass – Tools wie RIPE RIS, BGPView oder das HE BGP Toolkit zeigen, ob Ihr Präfix von mehreren Messpunkten aus sichtbar ist und die Origin-ASN zur ROA passt.

Beginnen Sie die IP-Migration nicht, bevor Ihr Präfix sichtbar ist und korrekt geroutet wird. Ein nicht angekündigtes oder falsch geroutetes Präfix bedeutet, dass Traffic zu Ihrem neuen Subnetz einfach ins Leere läuft.

Minimale Präfixlänge

Bestätigen Sie vor der BGP-Konfiguration, dass Ihr geleaster IPv4-Block ein /24 oder größer ist. Die überwiegende Mehrheit der Internet-Peers und IXP-Route-Server wendet Filter auf die Präfixlänge an, die Ankündigungen länger als /24 still verwerfen – /25, /26 und kleinere Präfixe verbreiten sich also nicht im Internet, selbst wenn ROA und IRR-Objekte korrekt konfiguriert sind. Ist Ihr geleaster Block kleiner als /24, klären Sie mit Ihrem IP-Eigentümer oder Upstream-Provider die Ankündigungsoptionen. Die übliche Lösung: Der IP-Eigentümer kündigt das übergeordnete Aggregat an und nutzt intern spezifischere Routen.

Bei BYOIP auf AWS, GCP oder Azure übernimmt der Cloud-Anbieter die BGP-Ankündigung für Sie, nachdem Sie den Adresspool bereitgestellt haben. Die Einrichtung je Plattform beschreibt der BYOIP-Leitfaden von IPbnb für AWS, GCP und Azure.

Migration Schritt für Schritt

Mit abgearbeiteter Checkliste, gesenkter TTL und geprüftem BGP-Routing sind Sie bereit für die Migration. Der sicherste Ansatz ist der Parallelbetrieb: das neue Subnetz vollständig in Betrieb nehmen, bevor das alte abgeschaltet wird.

Phase 1: Parallelbetrieb

Konfigurieren Sie alle Dienste und Anwendungen auf dem neuen geleasten Subnetz, während die alten Adressen aktiv bleiben. In dieser Phase sind beide Subnetze gleichzeitig live. Testen Sie Ihre Dienste gründlich von den neuen IPs aus, bevor Sie DNS-Änderungen vornehmen. Unterstützt Ihr Upstream BGP Communities, können Sie in dieser Phase eine NO_EXPORT-Community nutzen, um die Ankündigung des neuen Präfixes auf bestimmte Peers zu begrenzen, während Sie das Routing validieren – und sie entfernen, sobald Sie sicher sind, dass sich das Präfix korrekt verhält. Das ist Ihr letzter risikoarmer Kontrollpunkt.

Bestätigen Sie vor dem nächsten Schritt:

• Dienste antworten korrekt von den neuen IP-Adressen

• Das BGP-Routing ist stabil und das Präfix global sichtbar

• Das Monitoring ist auf dem neuen Subnetz aktiv

• PTR-Einträge für das neue Subnetz sind live und korrekt konfiguriert

Phase 2: DNS-Umstellung

Aktualisieren Sie Ihre DNS-A-Einträge auf das neue Subnetz. Da die TTL in der Vorbereitung gesenkt wurde, verbreitet sich diese Änderung innerhalb von 5 Minuten – bzw. innerhalb Ihrer reduzierten TTL.

Aktualisieren Sie alle betroffenen Einträge nach Möglichkeit gleichzeitig, um das Fenster der Inkonsistenz klein zu halten. Prüfen Sie danach die DNS-Verbreitung über mehrere Resolver:

# Verify resolution from different public resolvers

dig A yourdomain.com @8.8.8.8

dig A yourdomain.com @1.1.1.1

dig A yourdomain.com @9.9.9.9

Phase 3: Traffic-Monitoring

Beobachten Sie nach der DNS-Umstellung die Traffic-Werte auf altem und neuem Subnetz. Der Traffic auf dem alten Subnetz sollte stetig sinken, während zwischengespeicherte DNS-Einträge im Internet ablaufen. Der Traffic auf dem neuen Subnetz sollte entsprechend steigen. Warten Sie, bis der Traffic auf dem alten Subnetz nahezu null ist, bevor Sie zur nächsten Phase übergehen.

Phase 4: Abschaltung des alten Subnetzes

Sobald bestätigt ist, dass kein nennenswerter Traffic mehr an den alten Adressen ankommt:

• Entfernen Sie die alten IP-Adressen aus Ihren Diensten und Anwendungskonfigurationen

• Ziehen Sie das alte BGP-Präfix zurück, falls Sie es direkt angekündigt haben

• Aktualisieren oder entfernen Sie verbleibende Verweise auf alte IPs in Firewall-Regeln und Konfigurationsdateien

• Informieren Sie Partner und externe Dienste, dass die alten Adressen nicht mehr aktiv sind

Überstürzen Sie diese Phase nicht. Die alten Adressen nach dem Abfließen des Traffics weitere 24–48 Stunden aktiv zu halten, kostet nichts und bietet ein Sicherheitsnetz für zwischengespeicherte DNS-Einträge, die bei der ersten Erfassung nicht aufgefallen sind.

Wenn Sie noch in der Planung sind und einen geleasten IPv4-Block für die Migration suchen, sehen Sie sich verfügbare Subnetze bei IPbnb an, um das Passende für Ihre Infrastrukturanforderungen zu finden.

Prüfung nach der Migration

Die Umstellung ist nicht das Ende des Prozesses. Die folgenden Stunden und Tage erfordern aktives Monitoring, um zu bestätigen, dass alles wie erwartet funktioniert und Ihr neues Subnetz sich sauber verhält.

Routing testen

Die Routing-Prüfung bestätigt, dass Traffic Ihr neues Subnetz aus allen relevanten Regionen korrekt erreicht – nicht nur aus Ihrer eigenen Perspektive.

Verbreitung der BGP-Routen

Bestätigen Sie mit BGP Looking Glasses, dass Ihr Präfix von mehreren AS-Messpunkten aus sichtbar ist und keine unerwarteten Routenanomalien aufgetreten sind:

• RIPE RIS Looking Glass (ris.ripe.net) – starke Abdeckung europäischer und globaler Peers

• HE BGP Toolkit (bgp.he.net) – zeigt Upstream-Pfade und Sichtbarkeit bei Peers

• BGPView (bgpview.io) – übersichtliche Sichtbarkeit und Historie pro Präfix

Prüfen Sie, dass die Origin-ASN zu Ihrer ROA passt, das Präfix nicht mit unerwarteten Path Prepends angekündigt wird und keine spezifischeren Präfixe aus unbeabsichtigten Quellen durchsickern.

Ende-zu-Ende-Konnektivität

Testen Sie die Konnektivität von mehreren Standorten mit Traceroute oder MTR, um zu bestätigen, dass der Traffic die erwarteten Pfade zu Ihrem neuen Subnetz nimmt:

# Traceroute to verify the path

traceroute -n yourdomain.com

# MTR for continuous path monitoring (-r report mode, -n skip DNS resolution)

mtr -rn yourdomain.com

Wenn Sie BYOIP über einen Cloud-Anbieter nutzen, prüfen Sie, dass der Traffic korrekt durch die Edge-Infrastruktur des Anbieters fließt, bevor er Ihre Workloads erreicht. Der BYOIP-Leitfaden von IPbnb beschreibt anbieterspezifische Prüfschritte für AWS, GCP und Azure.

IP-Reputation überwachen

Die IP-Reputation ist nach einer Migration nicht statisch. Selbst ein sauberes Subnetz kann schnell negative Signale sammeln, wenn etwas schiefgeht – ein falsch konfigurierter Mailserver, ein offener Proxy oder ein kompromittierter Dienst kann Ihre neuen IPs binnen Tagen nach der Migration auf eine Blocklist bringen.

Richten Sie laufendes Monitoring ein für:

• E-Mail-Blacklists: Spamhaus (SBL, XBL, PBL), Barracuda, SpamCop – entscheidend, wenn Ihr Subnetz ausgehende Mails versendet

• Allgemeine Reputationsdatenbanken: Talos Intelligence, AbuseIPDB, AlienVault OTX

• MXToolbox: nützlich für einen gebündelten Blick auf die gängigsten Blacklists

Prüfen Sie diese 24 Stunden, 72 Stunden und eine Woche nach der Migration. Taucht Ihr neues Subnetz auf einer Blacklist auf, untersuchen Sie die Ursache sofort. Es kann auf eine Fehlkonfiguration oder einen kompromittierten Dienst in Ihrer Infrastruktur hinweisen – nicht zwingend auf ein historisches Problem des IP-Blocks selbst.

Bestätigen Sie außerdem, dass PTR-Einträge für das neue Subnetz korrekt konfiguriert sind. Fehlende oder nicht passende PTR-Einträge verursachen Soft Failures bei der Mailzustellung und werden von vielen Sicherheitsscannern markiert.

Für die genauen Konfigurationsschritte und die korrekte Einrichtung Ihres geleasten Blocks von Anfang an ist der Leitfaden zur Subnetzkonfiguration von IPbnb die richtige Referenz.

Eine letzte Sache

Eine erfolgreiche IPv4-Migration ist zu 80 % Vorbereitung und zu 20 % Ausführung. Die technischen Schritte – DNS aktualisieren, BGP konfigurieren, Dienste umstellen – sind nicht kompliziert. Schief gehen sie durch unvollständige Erfassung der Abhängigkeiten, unzureichende TTL-Planung und zu schnelles Durchlaufen der Phasen.

Arbeiten Sie die Checkliste ab. Senken Sie die TTL früh. Prüfen Sie das BGP-Routing, bevor Sie DNS anfassen. Halten Sie das alte Subnetz live, bis der Traffic vollständig abgeflossen ist. Überwachen Sie die Reputation nach der Umstellung aktiv.

Tun Sie diese fünf Dinge, und eine IP-Migration, die riskant wirkt, wird zu einer routinemäßigen Betriebsaufgabe.