Zusammenfassung

  • Ein NANOG-98-Vortrag beschreibt, wie TCP-Ports schrittweise in eine Cloud verlegt wurden, während der alte Standort die Dienst-IP weiter bekanntgab.
  • Der Referent berichtet von 3.000 Ports in sechs Monaten, zwei anwendungsbedingten Rücknahmen und null verlorenen Transaktionen; RFC 8955 standardisiert die gezeigte Aktion redirect-nh nicht.

Ein Migrationsplan kann „schrittweise“ sagen; einer Zahlungssitzung ist wichtig, ob ihr nächstes Paket noch denselben Dienst erreicht. Auf der NANOG 98 beschrieb Infrastrukturarchitekt Hervé Hildenbrand einen Dienst, dessen Clients eine fest einprogrammierte IP und rohes TCP verwendeten. Es gab keinen DNS-Eintrag zum Umstellen, keinen für die Anwendung tragbaren Proxy und keine Client-Firmware, die das Team ändern konnte. Eine einmalige Verlagerung des gesamten /32 hätte mehr als 3.000 TCP-Ports mitgezogen; zwei gleichzeitige Standorte hätten aktive Sitzungen aufteilen können.

Die Lösung laut NANOG-Sitzung: Der normale Verkehr blieb am alten Standort; nur ausgewählte Kombinationen aus Zieladresse, Protokoll und Port wurden umgeleitet. Die Folien zeigen BGP-FlowSpec-Regeln, die den Next Hop auf einen Anycast-Anker in einer neuen Cloud ändern; MPLS transportiert den Verkehr zwischen den Standorten. Ein Port wechselt, sobald er bereit ist. Der Rest bleibt. Am Ende kündigt der neue Rand das /32 an, der alte zieht es zurück, danach verschwinden die FlowSpec-Umleitungen.

Das ist eine raffinierte Nutzung eines Werkzeugs, das meist für Verkehrsfilter bekannt ist. „FlowSpec“ bezeichnet aber die Beschreibung und Verteilung von Treffern, keinen universellen Weiterleitungsbefehl. RFC 8955 erlaubt Regeln nach Zielpräfix, Protokoll und Ports. Zugleich verlangt sie, die Next-Hop-Adresse im FlowSpec-NLRI zu ignorieren. Die standardisierte Umleitung führt passenden Verkehr anhand eines Route Targets in eine VRF. Hildenbrands Folien zeigen dagegen redirect-nh zu einer Anycast-Adresse. RFC 8955 lässt zusätzliche Aktionen durch separate Standards oder herstellerspezifische Implementierungen zu; die Verwendung von FlowSpec macht diese Next-Hop-Umschreibung nicht automatisch portabel. Die Folien nennen weder die Implementierung noch die Kodierung der Aktion auf dem Draht.

Die Schutzmaßnahmen gehören zum Fall. Die Präsentation beschreibt in Git/Terraform deklarierte Regeln, eine CI/CD-Prüfung von Zieladressen, Portbereichen und freigegebenen Next Hops sowie Routerfilter, die nicht genehmigte Ziele ablehnen. Eine falsche Regel kann den Verkehr mit Weiterleitungsgeschwindigkeit im Backbone treffen. Prüfung vor der Einspeisung und eine harte Grenze im Gerät erschweren es, dass eine gezielte Migration zum netzweiten Problem wird.

Die Folien berichten von 3.000 TCP-Ports in sechs Monaten, Konvergenz unter einer Sekunde, zwei wegen Anwendungsproblemen zurückgenommenen Schritten und null verlorenen Transaktionen. Das sind Angaben aus dem Fallbericht des Referenten, kein unabhängig geprüftes Betriebsprotokoll. 192.0.2.50 in den Diagrammen liegt im nur für Dokumentation vorgesehenen TEST-NET-1 aus RFC 5737; 10.100.0.254 gehört zum privaten Adressraum aus RFC 1918. Kundenname und echte Dienstadresse wurden nicht genannt.

Der brauchbare Befund lautet nicht „FlowSpec kann Dienste umziehen“. Das Team zerlegte eine gemeinsame Identität – die IP – in kleinere Betriebsentscheidungen mit genauer Übereinstimmung, freigegebenem Ziel und rückgängig zu machender Änderung. So ließen sich Anwendungsprobleme beheben, ohne bei jedem Fehler das gesamte Netz umzuschalten. Die ausführlichen Fallangaben stammen aus Hervé Hildenbrands Folien bei NANOG 98.