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 accompagne tout au long des étapes de migration de votre trafic de production sans provoquer de perturbations ou de risques majeurs. Cette méthode s’applique aux migrations vers un nouvel emplacement de peering ou vers le même emplacement.

Si vous avez un circuit ExpressRoute via un fournisseur de services de couche 3, créez le nouveau circuit sous votre abonnement sur 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 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 précédent 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. Bloquer 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 d’itinéraire au circuit B.

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

Empêchez la publication des itinéraires sur un ou plusieurs 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 le nouveau peering 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é

Pour lier le nouveau circuit à la passerelle d’un réseau virtuel de test et vérifier la connectivité de votre peering privé, suivez les étapes de l’article Connecter un réseau virtuel à un circuit ExpressRoute. Après avoir lié les réseaux virtuels au circuit, vérifiez la table de routage du peering privé pour vous assurer que l’espace d’adressage du réseau virtuel est inclus. 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 dans un réseau virtuel de test et un appareil de test local utilisé pour vérifier la connectivité vers 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égies pour filtrer les itinéraires publiés et autoriser l’adresse IP spécifique de l’appareil de test 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. Procédez comme suit pour garantir un processus fluide :

  1. Utiliser des préfixes distincts : configurez le peering Microsoft pour le circuit B avec des préfixes différents de ceux utilisés pour le circuit A afin d’éviter les conflits de routage. Reportez-vous à la création d’un peering Microsoft pour obtenir des conseils.
  2. Séparer les filtres de routage : liez le peering Microsoft du circuit B à un filtre de routage différent du circuit A. Suivez les étapes de configuration des filtres de routage pour le peering Microsoft.
  3. Éviter les itinéraires courants : assurez-vous que les filtres de routage pour les deux circuits ne partagent pas d’itinéraires communs pour empêcher le routage asymétrique. Pour ce faire, procédez comme suit :
    • Sélection d’un service ou d’une région Azure pour tester le circuit B qui n’est pas utilisé par le trafic de production du circuit A.
    • Réduction du chevauchement entre les deux filtres de routage et autorisation des points de terminaison publics de test spécifiques via le circuit B uniquement.

Après avoir lié un filtre de routage, vérifiez les itinéraires publiés et reçus sur l’homologation BGP sur l’appareil CE. Modifiez le mappage d’itinéraire ou la configuration de stratégies Junos pour filtrer les itinéraires publiés de manière à autoriser uniquement les préfixes locaux du peering Microsoft et des adresses IP spécifiques des points de terminaison publics Microsoft sélectionnés à des fins de test.

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, commencez par des tests de connectivité de base comme traceroute à partir d’un site local pour vous assurer que les requêtes passent par des points de terminaison ExpressRoute. Au-delà des points de terminaison ExpressRoute, les messages ICMP sont supprimés sur le réseau Microsoft. De plus, testez la connectivité au niveau de l’application. Par exemple, si vous disposez d’une machine virtuelle Azure avec une adresse IP publique exécutant un serveur web, tentez d’accéder à l’adresse IP publique du serveur web à partir de votre réseau local via la connexion ExpressRoute. Cela confirme que le trafic complexe, tel que les requêtes HTTP, peut atteindre les services Azure.

Peering privé

  1. Déconnectez le circuit B de n’importe quelle passerelle de réseau virtuel de test.
  2. Supprimez les exceptions apportées aux mappages d’itinéraire Cisco ou à la stratégie Junos.
  3. Connectez le circuit B à la passerelle de réseau virtuel de production en suivant les étapes de l’article Connecter un réseau virtuel à un circuit ExpressRoute.
  4. Vérifiez que le circuit B est prêt à publier tous les itinéraires actuellement publiés sur le circuit A. Vérifiez que les interfaces du circuit B sont associées au VRF ou à l’instance de routage appropriés.
  5. Supprimez les mappages d’itinéraire ou la stratégie sur les interfaces du circuit B et appliquez-les aux interfaces du circuit A pour bloquer les publications d’itinéraires sur le circuit A, en basculant le flux de trafic vers le circuit B.
  6. Vérifiez le flux de trafic sur le circuit B. En cas d’échec de la vérification, rétablissez les modifications et reprenez le flux de trafic sur le circuit A.
  7. Si la vérification réussit, supprimez le circuit A.

Peering Microsoft

  1. Supprimez le circuit B de tous les filtres de routage Azure de test.
  2. Supprimez les exceptions apportées aux mappages d’itinéraire ou à la stratégie.
  3. Vérifiez que les interfaces du circuit B sont associées au VRF ou à l’instance de routage appropriés.
  4. Validez et confirmez les préfixes publiés 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 et appliquez-les aux interfaces du circuit A pour bloquer les publications d’itinéraire sur le circuit A, en basculant le flux de trafic vers le circuit B.
  7. Vérifiez le flux de trafic sur le circuit B. En cas d’échec de la vérification, rétablissez les modifications et reprenez le flux de trafic sur le circuit A.
  8. Si la vérification réussit, 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.