Comment abandonner FabricPath sans migration « big bang » ?
Introduction
La migration FabricPath vers EVPN VXLAN concerne encore de nombreux environnements datacenter. FabricPath a longtemps permis de simplifier certaines topologies L2, mais les besoins d’évolution conduisent progressivement à préparer son remplacement.
Le sujet ne consiste pas uniquement à déployer une nouvelle fabric EVPN VXLAN. Il faut également organiser la migration des services existants sans imposer une bascule simultanée des workloads, des VLAN et de leurs passerelles.
Ce use case présente une méthode de coexistence temporaire entre FabricPath et EVPN VXLAN reposant sur :
- une extension contrôlée des VLAN
- un échange de préfixes par VRF
- une migration progressive des workloads
- un déplacement maîtrisé des passerelles
Cisco documente également les principes de migration d’un environnement FabricPath vers VXLAN BGP EVPN.
Déployer EVPN en parallèle de FabricPath
La fabric EVPN VXLAN est déployée indépendamment de l’environnement FabricPath, suivant les règles d’ingénierie définies pour l’architecture cible.
Les deux infrastructures sont ensuite reliées par des interconnexions temporaires et dédiées :
- des liaisons de niveau 2 raccordées aux leafs EVPN
- des liaisons de niveau 3 raccordées aux Border Gateways
Cette séparation permet de traiter distinctement la continuité des VLAN et les échanges de préfixes entre les réseaux déjà migrés et ceux encore portés par l’environnement historique.
Assurer la continuité des VLAN pendant la migration
L’interconnexion de niveau 2 repose sur un vPC Port-Channel configuré en trunk Ethernet entre les switchs FabricPath et une paire de leafs EVPN.
Seuls les VLAN nécessaires sont autorisés sur ce trunk au fur et à mesure des migrations.
Côté FabricPath, les VLAN restent configurés en mode FabricPath. Côté EVPN, ils sont associés à des L2VNI afin d’être transportés dans la nouvelle fabric.
Cette extension permet aux workloads historiques et migrés de continuer à communiquer dans le même domaine de niveau 2, sans modifier leur plan d’adressage.
L’interconnexion reste provisoire. Elle sera supprimée lorsque tous les workloads concernés auront quitté l’environnement FabricPath.
Les principes sont les suivants :
- trunk Ethernet entre les deux environnements
- autorisation limitée aux VLAN nécessaires
- correspondance entre VLAN et L2VNI
- conservation des adresses IP des workloads
- suppression de l’interconnexion à la fin de la migration
Maintenir le routage entre les réseaux migrés et non migrés
La migration ne concerne pas uniquement les workloads. Les passerelles SVI doivent également être déplacées progressivement de l’environnement FabricPath vers la fabric EVPN.
Des interconnexions de niveau 3 sont donc établies entre les routeurs historiques et les Border Gateways EVPN.
Chaque VRF dispose de son propre transit, généralement porté par une sous-interface dédiée. Ce fonctionnement permet de conserver le cloisonnement existant entre les différents environnements.
Une session eBGP est établie dans chaque VRF :
- l’environnement historique annonce les sous-réseaux qu’il porte encore
- la fabric EVPN annonce les sous-réseaux dont la passerelle a déjà été migrée
- les préfixes conservent leur adressage d’origine
- les politiques BGP limitent les échanges aux réseaux attendus
- les éventuelles redistributions sont filtrées afin d’éviter les boucles
Cette interconnexion permet aux services migrés et non migrés de continuer à communiquer pendant toute la période de coexistence.
Déplacer les workloads sans déplacer immédiatement la gateway
La migration d’un workload et celle de sa passerelle peuvent être réalisées séparément.
Dans une première phase, certains workloads sont déplacés vers la fabric EVPN alors que leur passerelle SVI reste encore active dans l’environnement FabricPath.
Grâce à l’extension du VLAN, les workloads migrés continuent d’atteindre cette passerelle sans changer d’adresse IP ni de sous-réseau.
Cette étape permet de migrer progressivement les équipements sans imposer immédiatement une modification du routage du VLAN concerné.
Déplacer la passerelle vers EVPN
Lorsqu’un nombre suffisant de workloads a été migré, la passerelle du VLAN peut être déplacée vers la fabric EVPN.
L’Anycast Gateway est préparée à l’avance avec la même adresse IP que la SVI historique. La bascule consiste ensuite à désactiver la SVI côté FabricPath et à activer la passerelle côté EVPN au cours d’une fenêtre de maintenance.
La convergence ARP doit être anticipée et vérifiée. Selon les équipements et les services concernés, l’émission d’un Gratuitous ARP peut accélérer la prise en compte de la nouvelle adresse MAC de passerelle.
Après la bascule :
- l’adresse IP de la passerelle reste inchangée
- les workloads déjà migrés utilisent directement l’Anycast Gateway EVPN
- les workloads encore présents côté FabricPath rejoignent cette passerelle par l’extension du VLAN
- le préfixe est désormais annoncé depuis la fabric EVPN vers l’environnement historique.
Cette opération est répétée pour chaque VLAN et chaque VRF.
Retirer progressivement FabricPath
La migration des workloads peut ensuite se poursuivre sans modification de leur adressage.
Lorsqu’un VLAN ne comporte plus aucun workload côté FabricPath, son extension vers EVPN peut être supprimée. Lorsque tous les réseaux d’une VRF ont été déplacés, les échanges BGP correspondants peuvent également être retirés.
La sortie de FabricPath se termine par :
- la migration des derniers workloads
- la suppression des extensions de VLAN devenues inutiles
- le retrait des annonces BGP historiques
- la suppression des interconnexions temporaires de niveau 2 et de niveau 3
- le nettoyage des configurations
- l’arrêt progressif des équipements FabricPath
Pendant cette phase de coexistence, la surveillance doit couvrir à la fois l’environnement FabricPath, la nouvelle fabric EVPN VXLAN et leurs interconnexions. La corrélation des journaux et des événements permet de détecter les anomalies liées aux migrations. Cette surveillance des infrastructures réseau avec Keperlog contribue à sécuriser la transition ainsi que l’exploitation de la nouvelle fabric.
Conclusion
Le principal enjeu n’est pas simplement de remplacer FabricPath par EVPN VXLAN. Il est de construire une trajectoire permettant de migrer les services sans modifier leur adressage et sans concentrer tous les efforts dans une seule fenêtre de maintenance.
EN 
FR