Partager via


Migrer vers un nouveau circuit ExpressRoute

Si vous souhaitez passer d’un circuit ExpressRoute à un autre, vous pouvez le faire sans problème avec une interruption de service minimale. Ce document vous aide à suivre les étapes de migration de votre trafic de production sans provoquer de perturbations ou de risques majeurs. Vous pouvez utiliser cette méthode que vous passiez à un nouvel emplacement ou au même emplacement de peering.

Si vous avez un circuit ExpressRoute via un fournisseur de services de couche 3, créez le nouveau circuit depuis votre abonnement dans le portail Azure. Collaborez avec votre fournisseur de services pour basculer le trafic de manière fluide vers le nouveau circuit. Une fois que le fournisseur de services a déprovisionné votre ancien circuit, supprimez-le du portail Azure.

Le reste de l’article s’applique à vous si vous avez un circuit ExpressRoute via un fournisseur de services de couche 2 ou des ports directs ExpressRoute.

Étapes à suivre pour une migration de circuit ExpressRoute fluide

Diagramme montrant une migration de circuit ExpressRoute du circuit A vers le circuit B.

Le diagramme ci-dessus illustre le processus de migration depuis un circuit ExpressRoute existant, appelé circuit A, vers un nouveau circuit ExpressRoute, appelé circuit B. Le circuit B peut se trouver dans le même emplacement de peering que le circuit A. Le processus de migration se compose des étapes suivantes:

  1. Déployez le circuit B en isolation : tandis que le trafic continue de circuler sur le circuit A, déployez un nouveau circuit B sans affecter l’environnement de production.

  2. Bloquez le flux de trafic de production sur le circuit B : empêchez tout trafic d’utiliser le circuit B jusqu’à ce qu’il soit entièrement testé et validé.

  3. Terminez et validez la connectivité de bout en bout du circuit B  assurez-vous que le circuit B peut établir et maintenir une connexion stable et sécurisée avec tous les points de terminaison requis.

  4. Basculez le trafic : redirigez le flux de trafic du circuit A vers le circuit B et bloquez le flux de trafic sur le circuit A.

  5. Désaffectez le circuit A : supprimez le circuit A du réseau et libérez ses ressources.

Déployer un nouveau circuit en isolation

Pour un remplacement un-à-un du circuit existant, sélectionnez l’option de résilience standard et suivez les étapes décrites dans le guide Créer un circuit avec ExpressRoute pour créer votre nouveau circuit ExpressRoute (circuit B) à l’emplacement de peering souhaité. Suivez ensuite les étapes décrites dans Configurer le peering pour un circuit ExpressRoute pour configurer les types de peering requis, privé et Microsoft.

Pour empêcher le trafic de production de peering privé d’utiliser le circuit B avant qu’il ne soit testé et validé, ne liez pas la passerelle de réseau virtuel qui a un déploiement de production vers le circuit B. De même, pour éviter le trafic de production de peering Microsoft d’utiliser le circuit B, n’associez pas de filtre de routage au circuit B.

Bloquer le flux de trafic de production sur le circuit nouvellement créé

Empêchez la publication d’itinéraires sur les nouveaux peerings sur les appareils CE.

Pour Cisco IOS, vous pouvez utiliser route-map et prefix-list pour filtrer les itinéraires publiés sur un peering BGP. L’exemple suivant montre comment créer et appliquer route-map et prefix-list à cet effet :

route-map BLOCK ADVERTISEMENTS deny 10
 match ip address prefix-list BLOCK-ALL-PREFIXES

ip prefix-list BLOCK-ALL-PREFIXES seq 10 deny 0.0.0.0/0 le 32

router bgp <your_AS_number>
 neighbor <neighbor_IP_address> route-map BLOCK-ADVERTISEMENTS out
 neighbor <neighbor_IP_address> route-map BLOCK-ADVERTISEMENTS in

Utilisez la stratégie d’exportation/importation pour filtrer les itinéraires publiés et reçus sur les nouveaux peerings sur les appareils Junos. L’exemple suivant montre comment configurer une stratégie d’exportation/importation à cet effet :

user@router>show configuration policy-options policy-statement BLOCK-ALL-ROUTES

term reject-all {

    the reject;
}

protocols {
    bgp {
        group <your_group_name> {
            neighbor <neighbor_IP_address> {
                export [ BLOCK-ALL-ROUTES ];
                import [ BLOCK-ALL-ROUTES ];
            }
        }
    }
}

Valider la connectivité de bout en bout du circuit nouvellement créé

Peering privé

Suivez les étapes de l’article Connecter un réseau virtuel à un circuit ExpressRoute pour lier le nouveau circuit à la passerelle d’un réseau virtuel de test et vérifier votre connectivité de peering privé. Après avoir lié des réseaux virtuels au circuit, examinez la table de route du peering privé du circuit et vérifiez que l’espace d’adressage du réseau virtuel y figure. L’exemple suivant montre une table de route du peering privé d’un circuit ExpressRoute dans le portail de gestion Azure :

Capture d’écran de la table de routage pour le lien principal du circuit ExpressRoute.

Le diagramme suivant illustre une machine virtuelle de test configurée dans un réseau virtuel de test et un appareil de test local pour vérifier la connectivité via le peering privé ExpressRoute.

Diagramme montrant une machine virtuelle dans Azure communiquant avec un appareil de test local via la connexion ExpressRoute.

Modifiez le mappage d’itinéraire ou la configuration de stratégie que vous avez appliquée pour filtrer les itinéraires publiés et autoriser l’adresse IP spécifique de l’appareil de test à partir d’un emplacement local. De même, autorisez l’espace d’adressage du réseau virtuel de test à partir d’Azure.

route-map BLOCK ADVERTISEMENTS permit 5
 match ip address prefix-list PERMIT-ROUTE

route-map BLOCK ADVERTISEMENTS deny 10
 match ip address prefix-list BLOCK-ALL-PREFIXES

ip prefix-list PERMIT-ROUTE seq 10 permit 10.17.1.0/24
ip prefix-list PERMIT-ROUTE seq 20 permit 10.1.18.10/32

ip prefix-list BLOCK-ALL-PREFIXES seq 10 deny 0.0.0.0/0 le 32


Pour autoriser des préfixes IP spécifiques pour les appareils de test sur Junos, configurez une liste de préfixes. Ensuite, configurez la stratégie d’importation/exportation BGP pour autoriser ces préfixes et rejeter tout le reste.

user@router>show configuration policy-options policy-statement BLOCK-ADVERTISEMENTS

term PERMIT-ROUTES {
    from {
        prefix-list PERMIT-ROUTE;
    }
    then accept;
}

term reject-all {
    then reject;
}

user@router>show configuration policy-options prefix-list PERMIT-ROUTE

10.1.18.10/32;
10.17.1.0/24;

Vérifiez la connectivité de bout en bout sur le peering privé. Par exemple, vous pouvez effectuer un test ping sur la machine virtuelle de test dans Azure à partir de votre appareil de test local et vérifier les résultats. Pour obtenir une validation détaillée pas à pas, consultez Vérification de la connectivité ExpressRoute.

Peering Microsoft

La vérification de votre peering Microsoft nécessite une planification minutieuse pour éviter tout effet sur le trafic de production. Vous devez utiliser des préfixes distincts pour le peering Microsoft du circuit B. Ces préfixes doivent être différents de ceux utilisés pour le circuit A, afin d’éviter tout conflit de routage entre les deux circuits. Vous devez également lier le peering Microsoft du circuit B à un filtre de routage distinct de celui lié au circuit A, en suivant les étapes décrites dans Configuration des filtres de routage pour le peering Microsoft. En outre, vous devez vous assurer que les filtres de routage pour les deux circuits n’ont pas d’itinéraires en commun publiés sur le réseau local, afin d’éviter le routage asymétrique entre le circuit A et le circuit B. Pour ce faire, vous pouvez soit :

  • sélectionner un service ou une région Azure pour tester le circuit B qui n’est pas utilisé par le trafic de production sur le circuit A, soit
  • réduire le chevauchement entre les deux filtres de routage et autoriser uniquement des points de terminaison publics de test plus spécifiques reçus via le circuit B

Une fois que vous avez lié un filtre de routage, vous devez vérifier les itinéraires publiés et reçus via le peering BGP sur l’appareil CE. Pour filtrer les itinéraires publiés et autoriser uniquement les préfixes locaux du peering Microsoft et l’adresse IP spécifique des points de terminaison publics Microsoft sélectionnés à des fins de test, vous devez modifier le mappage d’itinéraire ou la configuration de la stratégie Junos que vous avez appliquée.

Pour tester la connectivité aux points de terminaison Microsoft 365, suivez les étapes décrites dans Implémentation d’ExpressRoute pour Microsoft 365 – Générer vos procédures de test. Pour les points de terminaison publics Azure, vous pouvez commencer par des tests de connectivité de base tels que traceroute à partir d’un site local et vérifier que la requête passe sur les points de terminaison ExpressRoute. Au-delà des points de terminaison ExpressRoute, les messages ICMP sont supprimés sur le réseau Microsoft. Vous pouvez également tester la connectivité au niveau de l’application, en plus des tests ping de base. Par exemple, si vous disposez d’une machine virtuelle Azure avec une adresse IP publique Azure exécutant un serveur web, vous pouvez essayer d’accéder à l’adresse IP publique du serveur web à partir de votre réseau local via la connexion ExpressRoute. Cela vous aide à confirmer que le trafic plus complexe, tel que les requêtes HTTP, peut atteindre les services Azure.

Basculer sur le trafic de production

Peering privé

  1. Déconnectez le circuit B des passerelles de réseau virtuel de test auxquelles vous l’avez connecté.
  2. Supprimez les exceptions que vous avez apportées aux mappages d’itinéraire Cisco ou à la stratégie Junos.
  3. Suivez les étapes de l’article Connecter un réseau virtuel à un circuit ExpressRoute et connectez le circuit B à la ou les passerelles de réseau virtuel de production.
  4. Sur le CE, assurez-vous que vous êtes prêt à publier tous les itinéraires que vous publiez actuellement sur le circuit A sur le circuit B lorsque vous supprimez le mappage d’itinéraire ou la stratégie appliquée aux interfaces du circuit B sur le CE. Assurez-vous également que les interfaces du circuit B sont associées à la VRF ou à l’instance de routage appropriée, le cas échéant.
  5. Supprimez les mappages d’itinéraire ou la stratégie sur les interfaces du circuit B. Appliquez les mappages d’itinéraire ou la stratégie sur les interfaces du circuit A pour bloquer la publication de l’itinéraire sur le circuit A. Cela permet de basculer le flux de trafic sur le circuit B.
  6. Vérifiez le flux de trafic sur le circuit B. Si la vérification échoue, annulez l’association du mappage d’itinéraire ou du pare-feu que vous avez effectuée à l’étape précédente et basculez le flux de trafic sur le circuit A.
  7. Si la vérification du flux de trafic sur le circuit B est concluante, supprimez le circuit A.

Peering Microsoft

  1. Supprimez le circuit B de n’importe quel filtre de routage Azure de test auquel vous l’avez lié.
  2. Supprimez les exceptions que vous avez apportées aux mappages d’itinéraire ou à la stratégie.
  3. Sur le CE, vérifiez que l’interface du circuit B est associée à la VRF ou à l’instance de routage appropriée.
  4. Validez et confirmez le préfixe publié sur le peering Microsoft.
  5. Associez le peering Microsoft du circuit B au filtre de routage Azure actuellement associé au circuit A.
  6. Supprimez les mappages d’itinéraire ou la stratégie d’exportation/importation sur les interfaces du circuit B. Appliquez les mappages d’itinéraire ou la stratégie d’exportation/importation sur les interfaces du circuit A pour bloquer la publication de l’itinéraire sur le circuit A. Cela permet de basculer le flux de trafic sur le circuit B.
  7. Vérifiez le flux de trafic sur le circuit B. Si la vérification échoue, annulez l’association du mappage d’itinéraire ou de la stratégie que vous avez effectuée à l’étape précédente et basculez le flux de trafic sur le circuit A.
  8. Si la vérification du flux de trafic sur le circuit B est concluante, supprimez le circuit A.

Étape suivante

Pour plus d’informations sur la configuration de routeur, consultez Exemples de configuration de routeur pour configurer et gérer le routage.