Ou comment MilkyWan a changé d’AS en un temps record

Bonjour à tous,

Je suis heureux de vous annoncer que MilkyWan a changé d’AS !



En effet, nous avons récupéré l’AS2027, auparavant assigné à Médecins Sans Frontières en Suisse. Cet AS demeurait inutilisé depuis 2019 et allait revenir dans le pool du RIPE. Avec l’aide d’un abonné travaillant là-bas et des Services Industriels de Genève (le sponsoring-LIR), nous avons pu le récupérer à notre compte.

Cet ajustement est purement cosmétique et n'aura aucun impact sur les services que nous fournissons.
On a choisi de le faire pour deux raisons :
- Le challenge technique que représente un changement de numéro d’AS,
- La gloire d’avoir un AS à 4 chiffres parmi les plus petits, et surtout précédant ceux d'Orange France (AS 3215), de GTT (AS 3257), ou d'AT&T (AS 7018).

Nous nous sommes inspirés par le RETEX d'une opération similaire menée par IPnG l'année dernière: https://ipng.ch/s/articles/2021/10/24/as8298.html.

J’ai cependant choisi une méthode de migration un poil différente, que je vais détailler ici.

Étape 1 : Récupérer l’AS

Nous sommes le 9 Février, un abonné FTTH dans l’Ain travaillant chez MSF-CH me parle d’un AS qu’il a trouvé en faisant le ménage dans ses mails, le RIPE voulant le récupérer.

Partant d'une blague, je lui propose de le transférer chez nous... il a accepté

Quelques allers-retours de paperasse plus tard, nous avions besoin d'une validation écrite de la part du Directeur Général de l'ONG, puis celle du LIR sponsorisant la ressource. Un grand merci aux Services Industriels de Genève qui ont été très efficaces et professionnels


Le RIPE a finalisé le transfert du numéro le 4 mars 2022 vers 15h.

Ni une ni deux, j’entame la migration, parce qu’on est comme ça chez MilkyWan.

Je crée les objets ROA/IRR correspondants et je demande à nos deux Sponsoring-LIR de créer les objets pour les blocs IP qui leur appartiennent (pas encore de réponse à ce jour).


Étape 2 : Shooter un Route-Reflector et le reconfigurer avec l’AS2027

J’ai donc décidé de tuer RR3. Un coup de “no router bgp” plus tard, le voilà reconfiguré avec le bon AS, j’en ai également profité pour réécrire les communautés BGP avec le nouvel AS.

Ensuite, je configure un peering entre les anciens route-reflector et le nouveau, en n’oubliant pas de mettre la directive “next-hop-unchanged” sur les sessions, pour éviter des aspirations de trafic par les route-reflectors.

Nous avons 3 AFI chez MilkyWan : IPv4 Unicast, IPv6 Unicast et L2VPN/EVPN, les 3 ont été migrés en même temps.

Étape 3 : Configurer un routeur "canari"

J’ai commencé par un routeur assez simple à migrer : le RB4011 de Venissieux. Il n’est pas connecté à d’autres AS, et je peux facilement rollback si besoin.

La migration s’est bien passée, seul bémol : Le fait qu’il y ait un AS en plus dans le Path cassait le trafic engineering de certains abonnés tunnels. Une petite modif' dans la route-map du RR plus tard, le souci est corrigé.

Étape 4 : Migrer les routeurs internes (core/collecte)

J’ai ensuite migré les autres RB4011 de collecte dans la journée, puis les ASR1001 pour les ADSL/FTTH dans la soirée. J’ai aussi migré les routeurs de coeur des sites d’hébergement (CBO/D2S/LYN).

Quelques sessions étaient montées avec l’AS pour des abonnés Housing, j’ai mis un “local-as 57199” sur la session pour maintenir la continuité de service le temps qu’ils changent l’AS de leur coté.

Merci encore à Tchadel de Sapinet qui m'a bien aidé pour la reconfig de notre MX80, JunOS est vraiment différent des autres OS qu'on a en prod.

Étape 5 : Migrer un 2ème RR

Une fois la moitié des routeurs migrés sur AS2027, j’ai shooté RR2 pour le basculer sur le nouvel AS, histoire d’éviter de se retrouver dans le noir a cause d’un RR récalcitrant.

Étape 6 : Migrer les routeurs Backbone

Et là, c’est le drame. Il faut migrer les routeurs qui interconnectent MilkyWan à internet, c’est clairement la partie la plus compliquée.

Pour détailler, la migration d’un routeur se déroule de la manière suivante :
- "sh run" de la config, localisation de toutes les lignes contenant AS57199, préparation d’une config alternative à coté,
- Remplacement des route-map et des community-list,
- "no router bgp 57199", ce qui casse tout le routage passant par ce routeur,
- "router bgp 2027", et toute la conf qui suit,
- Application d’un "local-as" sur les peers eBGP.

Cette opération implique nécéssairement de casser le routage pendant environ 1 minute sur chaque POP. Mener cette opération sur les POP centraux est un peu joueur

Je commence par Venissieux, qui est le moins critique des 3, ensuite DC2 et pour finir, TH2.

Quelques AS ne remontent pas : les routeurs en face sont tous des Mikrotik. Il faut savoir qu’ils n’aiment pas du tout qu'on leur envoie le mauvais AS dans la session BGP. Contrairement à des routeurs bien constitués, ils cessent toute tentative d'ouverture de session BGP (état "Active") après réception d'un ASN non cohérent. C'est au pair de réitérer.

Au final, le 5 mars à 1h du matin, soit moins de 12h après l’assignation de l’AS, tout le backbone était migré !

Étape 7 : Annoncer aux clients la migration (changement remote-as et IRR)

Une fois que tout le backbone a été migré, nous avons pu annoncer le changement au monde. Un mail est parti le 5 mars au matin pour demander aux abonnés ayant des sessions BGP avec nous de changer leur remote-as.

Petit truc sympa sur Arista, avec l’aide de cette commande :
> neighbor X.X.X.X local-as 57199 no-prepend replace-as fallback

Je peux monter la session avec AS2027, et si ça ne marche pas, rabattre sur AS57199. Idéal pour faire une migration d’AS sans se prendre le chou

Étape 8 : Annoncer aux transits/peerings le changement

Là on rentre dans le vif du sujet : Il va falloir contacter la centaine de peerings directs de MilkyWan pour leur demander de changer le remote-as. Début du marathon Lundi

Étape 9 : Réutiliser AS57199 pour autre chose

Une fois que nos LIR auront créé les bons objets route/ROA, on pourra décommissionner AS57199.
On le gardera parce qu’on est des grands sentimentaux, on verra ce qu’on en fait.

Nice bravo !

Fascinant ! Est-ce que ce genre de changement peut avoir un impact sur les différentes bases (de qualités discutables) de géolocalisation IP ?

Normalement non, ils se basent sur les IP et non sur l'AS.

Comme je le dis souvent : ça pète des culs. Et encore le mot est faible.

Annoncer le changement est une chose. Mais putain, donner tout le déroulé, la procédure, comme ça sur un plateau, mais bon sang, respect les mecs !

Bravo à vous !

Au final, le 5 mars à 1h du matin, soit moins de 12h après l’assignation de l’AS, tout le backbone était migré !

Dédicasse à Titi, Fifi et Loulou en train de galérer à migrer le leur 

Bravo pour le challenge technique.

AS2027 a été crée quand ?

Il y a peu d'opérateurs Français à avoir un AS plus petit.

PS : Normalement, j'ai modifié à pas mal d'endroit sur le forum l'AS. Si il reste des AS57199 je peut faire le changement. Je peut aussi faire un rechercher / remplacer dans la base de donnée, il y aura juste ce sujet à sauvegarder et à restaurer à l'identique.

Félicitation à vous pour cette opération d'envergure !