La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Opérateurs grand public alternatifs => 
MilkyWan => Discussion démarrée par: Hugues le 05 mars 2022 à 14:20:22
-
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 !
(https://pix.milkywan.fr/U1WLP3Xh.png)
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. :)
-
Cette opération commando mérite mes meilleurs respects.
-
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 ?
-
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.
-
Normalement, la géolocalisation se fait sur l'adresse IP et pas sur l'AS source.
De plus, cette AS annoncé 0 prefix (https://archive.ph/0rbu6) depuis un moment.
-
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 ::)
-
:-* Cédric
-
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.
-
Bravo pour le challenge technique.
Merci !
Il y a peu d'opérateurs Français à avoir un AS plus petit.
Oui, même Renater est plus grand :P
AS2027 a été crée quand ?
Les plus vieilles traces que je trouve sont aux alentours des années 2000, il était assigné à l'aquivalent du CNRS au Vénézuela.
MSF a récupéré cet AS en 2011 dans des circonstances qui ne sont pas connues, il a servi jusqu'en 2019, date où le préfixe qu'il annonçait a été annoncé par l'AS d'un prestataire en direct.
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.
Super, merci beaucoup !
-
Félicitation à vous pour cette opération d'envergure !
-
Félicitations pour ce challenge. Lancer une migration un vendredi à 15h, ils sont fous chez Milkywan. 😂
Est-ce que ça peut avoir un intérêt d'avoir 2 AS pour séparer la partie GP/pro ou FAI/hébergement ou pas spécialement ?
-
Good ça 8)
Bon, si Renater (AS775, AS776, AS777, AS781, AS789) veut bien en lâcher un maintenant vu que le GIP est en difficultées financières ;D
Optix #PTDQ :P
-
wow ! félicitations et respect...
-
Bravo, beau travail, et merci pour la description technique.
Tu écris "la centaine de peerings directs", mais d'après bgp.he.net vous en avez beaucoup plus que ça, les autres c'est dans des IX sur des route-servers donc pas besoin de les contacter directement, c'est ça ?
Autre question, quand vous faites des modifs qui peuvent casser le routage, vous avez un moyen de secours pour récupérer l'accès aux routeurs si c'est vraiment la m... ? Par exemple les consoles série à travers un serveur de ports ?
Par contre, désolé de casser un peu l'ambiance mais une annonce quelques jours avant ça aurait été pas mal, quand je suis rentré, plus d'internet ni de téléphone, heureusement c'était résolu en 10 minutes par mail avec Hugues, mais si j'avais été en déplacement, en vacances, ça aurait été plus emmerdant... Bon, je crois que je suis un des seuls, peut être le seul concerné, d'après les explications rapides qu'il m'a données : seul client qui peer avec le numéro d'AS public sur le routeur de Vénisseux dont il est question plus haut, et une configuration qui fait que le peering n'est pas remonté tout seul quand Hugues a vu le problème et fait un rollback.
D'ailleurs, pourquoi je suis l'exception sur ce truc ? Je veux dire, pourquoi les autres abonnés peer avec un AS privé ? Est-ce que c'est en rapport avec le combo L2TP + FTTH que tu m'as proposé ?
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.
Alors c'est probablement ça le problème que j'ai eu hier soir, combiné avec le fait que c'est passive de votre côté. Mon routeur qui peer avec Vénisseux est un RB4011 et effectivement après avoir claironné "invalid remote AS" il n'a pas réessayé, ce con.
Qu'est-ce que tu conseilles, un coup de script pour disable+enable si le peering n'est pas established ?
-
Bravo, beau travail, et merci pour la description technique.
Tu écris "la centaine de peerings directs", mais d'après bgp.he.net vous en avez beaucoup plus que ça, les autres c'est dans des IX sur des route-servers donc pas besoin de les contacter directement, c'est ça ?
Voilà
Autre question, quand vous faites des modifs qui peuvent casser le routage, vous avez un moyen de secours pour récupérer l'accès aux routeurs si c'est vraiment la m... ? Par exemple les consoles série à travers un serveur de ports ?
Pas partout mais on tend à le faire. En l'occurence il me restait OSPF pour récupérer la main une fois BGP déconf.
Par contre, désolé de casser un peu l'ambiance mais une annonce quelques jours avant ça aurait été pas mal, quand je suis rentré, plus d'internet ni de téléphone, heureusement c'était résolu en 10 minutes par mail avec Hugues, mais si j'avais été en déplacement, en vacances, ça aurait été plus emmerdant... Bon, je crois que je suis un des seuls, peut être le seul concerné, d'après les explications rapides qu'il m'a données : seul client qui peer avec le numéro d'AS public sur le routeur de Vénisseux dont il est question plus haut, et une configuration qui fait que le peering n'est pas remonté tout seul quand Hugues a vu le problème et fait un rollback.
Le souci c'est surtout que tu as un routeur Mikrotik, et comme je l'ai écrit au dessus, les Mikrotik ne tentent plus jamais de remonter la session une fois qu'elle tombe en erreur, c'est crétin et ça bloque le truc jusqu'a ce qu'une action manuelle soit entreprise.
D'ailleurs, pourquoi je suis l'exception sur ce truc ? Je veux dire, pourquoi les autres abonnés peer avec un AS privé ? Est-ce que c'est en rapport avec le combo L2TP + FTTH que tu m'as proposé ?
Oui. Puis c'était pas prévu de migrer d'AS à la base :)
Qu'est-ce que tu conseilles, un coup de script pour disable+enable si le peering n'est pas established ?
Vu le nombre de trucs qui peuvent bloquer une session sans raison sur un Mikrotik, ça ne serait pas du luxe oui (les sessions bloquées en OpenConfirm j'en ai eu pas mal)
-
Hello !
Petit update du lundi matin :
- L'IRR/ROA a été créé par Gitoyen pour notre préfixe IPv4 80.67.167.0/24, on l'a donc désannoncé d'AS57199
- Hivane et Acorus ont basculé le transit sur notre nouvel AS, il est donc visible de partout maintenant
- 15% de nos peerings directs ont migré sur le nouvel AS
On a envoyé un mail à K-Net avec qui nous avons une session, mais je pense qu'il restera lettre morte ::)
-
On a envoyé un mail à K-Net avec qui nous avons une session, mais je pense qu'il restera lettre morte ::)
C'est triste, mais ils ont l'air encore débordés (toujours pas de téléphone...).
Tu veux bien expliquer au novice en BGP que je suis les conséquences coté MW de cette non réponse?
J'ai un peu de mal avec BGP ou assimilé.
-
Non c'est surtout que vu ce que le CTO dit sur moi en off, je doute qu'on ait une réponse.
Rien, le trafic passera par les route-server une fois que j'aurais coupé la session dans quelques semaines :)
-
Ok merci.
MW perds juste un peering avec K-net.
-
Dans les AS "courts" français, il y a l'AS6 enregistré par Bull en 1984, Atos maintenant, mais l'AS est toujours actif.
-
Dans les AS "courts" français, il y a l'AS6 enregistré par Bull en 1984, Atos maintenant, mais l'AS est toujours actif.
Donc c'est le premier AS français qui a été crée ?
-
Donc c'est le premier AS français qui a été crée ?
Oui:
AS1 -> level3
AS2 -> University of Delaware
AS3 -> MIT
AS4 -> University of Southern California
AS5 -> Symbolics (de mémoire c'est la boite qui a enregistré le premier .com - symbolics.com)
Ça me rajeunit pas tout ça... Après les AS au début c'était comme les IPv4... rien qu'FT/Orange la plage AS2280-AS2370 c'est tout à eux... L'Inria c'est pareil ils ont une centaine d'AS... une autre époque, n'empêche c'est quand même la classe d'avoir l'AS2027 !
-
Update du mardi matin :
- FranceIX/LyonIX ont migré nos sessions de RS
- Fiberway a migré le transit
- environ 40% de nos peers ont migré ou ont indiqué le faire prochainement
- Sans surprise, K-Net nous a dé-peeré quand ils ont reçu le mail
Reste encore :
- Le transit AppliWave
- LillIX
- Quelques peers/clients
Du coup j'ai fixé quelques deadlines :
- 15 Mars : On enlève le local-as sur les sessions de client transit, ils verront bien que ça aura coupé :P
- 1er Avril : On enlève le local-as sur les sessions de peering, tant pis pour les autres.
Voili voilou :)
-
Hop, on a migré Appliwave ce soir, et le bloc 2a0b:cbc0::/32 !
Du coup AS57199 n'existe officiellement plus, sauf chez les peers qui n'ont pas mis à jour le remote-as.
Voili voilou :)
PS : SFR a maj le remote-as super vite, comme quoi. Pas de news chez Bytel par contre
-
Bravo pour la migration. Je sais par expérience que ça doit être très bien planifié, que rien ne doit être oublié et que ça doit se faire rapidement
-
Donc c'est le premier AS français qui a été crée ?
Il était suisse surtout.
Les premiers AS en France sont à chercher sur :
- PHYNet/HEPNet (réseau académique et recherche de la physique des hautes énergie, l'IN2P3 raccroché au CERN et l'EPFL de Lausanne, avec le premier lien ATM entre Eurecom à Sophia Antipolis -Lyon au CC-IN2P3-CERN-EPFL Lausanne.)
- FNET (ne pas confondre avec FDN) branche de EUnet
- Oléane (AS2917) racheté par FT (AS3215)
- INRIA ou des morceaux, les AS775 et suivant étaient des nums ricains assignés à l'INRIA avant l'existence du RIPE et qu'à récup Renater en 1993
- certains industriels Renault, Siemens, GE....
FNET avait aussi la charge de se collecter et se taper les NACR pour les envoyer à la fac de Merit aux USA pour remplir les base du routing arbiter et en extraire les tables de routage.
Après le numérotage est pas toujours "indicatif" de l'âge Par exemple le super hub UUnet AS702/703 qui date de la mise en prod des câbles transat TAT-13 et 14 est postérieur aux AS de l'Inria et de loin.
Oui:
AS1 -> level3
Level 3 c'est aussi de la récup. De mémoire ca devait être celui de BBN (oui cf p.10 https://datatracker.ietf.org/doc/html/rfc820)
Je retourne dans ma grotte A+
EDIT l'AS6 de Bull c'est via les fusions/acquisitions de HoneyWell ou de morceaux de GE
-
Dernier update journalier, y'a plus grand chose à dire :)
Bouygues a mis à jour l'AS, comme 45% de nos peers. On va relancer les 55% d'ici Lundi.
Concernant les downstreams transit, on a relancé les derniers pas migrés aujourd'hui, et on coupe Samedi.
-
D'ailleurs tu pourra update ta banière twitter Hugues,
Sérieusement, une négligence dans la migration... Est-ce vraiment sérieux ? ;D
Ok je sors
-
Rah ouais j'avoue
-
Allez, parce que je m'ennuyais et que je soutiens les associatifs ! x)
-
Allez, parce que je m'ennuyais et que je soutiens les associatifs ! x)
C'est 2027 ou 2707 ???
-
2027 xD
Mais ne t'embête pas ReJac, de toute façon ce routeur n'existe plus, il a été remplacé par celui là :
(https://pix.milkywan.fr/UfSZsCfo.jpg)
-
2027 xD
Mais ne t'embête pas ReJac, de toute façon ce routeur n'existe plus, il a été remplacé par celui là :
(https://pix.milkywan.fr/UfSZsCfo.jpg)
C’est sur y’a pas photo entre ces deux routeurs