Résumé

  • Une présentation de NANOG 98 décrit le transfert progressif de ports TCP vers un cloud, pendant que le site historique continuait d’annoncer l’adresse du service.
  • L’intervenant rapporte 3 000 ports déplacés en six mois, deux retours arrière liés à l’application et aucune perte de transaction ; la RFC 8955 ne normalise pas l’action redirect-nh montrée.

Une migration peut être « progressive » sur le diagramme et brutale pour une session de paiement. À NANOG 98, l’architecte infrastructure Hervé Hildenbrand a décrit un service dont les clients utilisaient une adresse IP codée en dur et du TCP brut. Impossible de modifier une entrée DNS, d’ajouter un proxy que l’application aurait toléré ou de mettre à jour le micrologiciel des clients. Déplacer tout le /32 d’un coup aurait emporté plus de 3 000 ports TCP ; l’annoncer depuis deux sites risquait de couper les sessions en cours.

La réponse, exposée dans la présentation de NANOG, consistait à garder le trafic ordinaire sur le site historique et à rediriger uniquement certaines combinaisons d’adresse de destination, de protocole et de port. Les diapositives montrent des règles BGP FlowSpec qui changent le prochain saut vers un point Anycast dans un nouveau cloud, avec MPLS entre les sites. On déplace un port lorsqu’il est prêt ; les autres restent en place. À la fin, le /32 est annoncé depuis le nouveau site, retiré de l’ancien, puis les redirections FlowSpec sont supprimées.

C’est une utilisation habile d’un mécanisme surtout connu pour filtrer du trafic. Mais « FlowSpec » désigne le mécanisme de correspondance et de diffusion, pas une commande universelle d’orientation. La RFC 8955 permet de faire correspondre préfixe de destination, protocole et ports. Elle dit toutefois que le prochain saut du NLRI FlowSpec est ignoré. Son action de redirection normalisée envoie le trafic vers une VRF sélectionnée par une route-target. Les diapositives de Hildenbrand montrent plutôt redirect-nh vers une adresse Anycast. La RFC permet que d’autres actions soient normalisées séparément ou restent propres à une implémentation ; elle ne rend pas ce changement de prochain saut interopérable par magie. Les diapositives ne précisent ni l’implémentation ni l’encodage sur le fil.

Les protections font donc partie du résultat. Le jeu de diapositives décrit des règles déclarées dans Git/Terraform, une chaîne CI/CD qui vérifie adresses de destination, plages de ports et prochains sauts autorisés, puis des filtres sur les routeurs qui rejettent les cibles non approuvées. Une règle erronée peut toucher le trafic à la vitesse du plan de transfert. La validation avant injection et le filtre matériel limitent la possibilité qu’une migration ciblée se transforme en incident à l’échelle du backbone.

Les diapositives rapportent 3 000 ports TCP déplacés en six mois, une convergence inférieure à une seconde, deux retours arrière attribués à l’application et zéro perte de transaction. Ce sont les chiffres du cas présenté, pas un journal de service audité indépendamment. L’adresse 192.0.2.50 des schémas appartient à TEST-NET-1, réservé à la documentation par la RFC 5737 ; 10.100.0.254 relève de l’espace privé défini par la RFC 1918. Le dossier ne nomme ni client ni adresse réelle.

Le résultat utile n’est pas « FlowSpec sait déplacer un service ». L’équipe a découpé une identité partagée — l’adresse IP — en petites décisions d’exploitation, chacune assortie d’un critère précis, d’une destination autorisée et d’un retour arrière. Cela lui a permis de traiter les problèmes applicatifs sans transformer chaque erreur en bascule générale.

Sources : session NANOG 98 ; diapositives de Hildenbrand ; RFC 8955 ; RFC 5737 ; RFC 1918.