---
title: "Mettre en place une architecture OVHcloud Connect résiliente"
description: "Connectez votre infrastructure à OVHcloud via deux liens OVHcloud Connect redondants pour assurer la haute disponibilité et la bascule automatique."
url: https://docs.ovhcloud.com/fr/guides/network/ovhcloud-connect/resilient-architecture
lang: fr
lastUpdated: 2026-06-16
---
# Mettre en place une architecture OVHcloud Connect résiliente

## Objectif

Ce tutoriel vous guide pour connecter votre infrastructure à OVHcloud à l’aide de **deux liens OVHcloud Connect indépendants** afin d’obtenir la haute disponibilité. Si un lien tombe en panne, le trafic bascule automatiquement vers l’autre.

## En pratique

Vous trouverez ci-dessous les prérequis et les instructions pour cinq cas d’usage distincts, que vous pouvez choisir selon l’architecture souhaitée.


**On-Premises**

[](#)### Prérequis
- Deux services OVHcloud Connect (Direct, Provider ou un mix) se terminant sur **des PoPs différents**
- Un routeur (ou deux routeurs) capable de gérer **plusieurs sessions BGP** avec bascule
- Un plan d’adressage IP couvrant **deux AZ** chez OVHcloud
- Un vRack avec des ressources dans les deux AZ
### Architecture
![Schéma d’architecture résiliente On-Premises](/images/network/ovhcloud-connect/resilient-architecture/fig-1.fr.svg)### Quand utiliser cette architecture
| ✅ Recommandée pour                  | Détails                                                   |
| ----------------------------------- | --------------------------------------------------------- |
| Production critique pour l’activité | Workloads ne tolérant aucune indisponibilité              |
| Environnements réglementés          | Cadres de conformité exigeant la haute disponibilité      |
| Exigences de SLA ≥ 99,99 %          | Architecture multi-chemins nécessaire pour un SLA premium |
| Reprise après sinistre              | Bascule automatique sans intervention manuelle            |
#### 1. Commander deux liens OVHcloud Connect
Commandez deux services OVHcloud Connect distincts sur **des PoPs différents** pour assurer la diversité physique :
- **Lien 1 (principal) :** commandez sur le PoP A — voir [Commander Direct](/fr/guides/network/ovhcloud-connect/order-direct.md) ou [Commander Provider](/fr/guides/network/ovhcloud-connect/order-provider.md).
- **Lien 2 (secours) :** commandez sur le PoP B — même processus, PoP différent.
> **Conseil de diversité :** utilisez des datacenters différents ou, à défaut, des chemins physiques distincts pour éviter un point de défaillance partagé.
#### 2. Installer les deux connexions physiques
Pour chaque lien :
- **Direct :** installez les cross-connects sur chaque PoP. Voir [LOA Cross Connect](/fr/guides/network/ovhcloud-connect/cross-connect-loa.md).
- **Provider :** partagez les clés d’appairage respectives avec votre ou vos opérateurs.
#### 3. Configurer BGP avec bascule
Mettez en place **deux sessions BGP** — une par lien — avec des politiques de routage qui définissent le chemin préféré.
##### Exemple actif/passif (Cisco IOS)
```text
router bgp 65001
 ! Primary link via PoP A
 neighbor 192.0.2.1 remote-as 35540
 neighbor 192.0.2.1 description OVHcloud-Primary
 neighbor 192.0.2.1 route-map PRIMARY-IN in
 neighbor 192.0.2.1 route-map PRIMARY-OUT out

 ! Backup link via PoP B
 neighbor 198.51.100.1 remote-as 35540
 neighbor 198.51.100.1 description OVHcloud-Backup
 neighbor 198.51.100.1 route-map BACKUP-IN in
 neighbor 198.51.100.1 route-map BACKUP-OUT out

! Prefer primary path using Local Preference
route-map PRIMARY-IN permit 10
 set local-preference 200

route-map BACKUP-IN permit 10
 set local-preference 100

! Influence OVHcloud's return traffic using AS-path prepending on backup
route-map PRIMARY-OUT permit 10

route-map BACKUP-OUT permit 10
 set as-path prepend 65001 65001
```
##### Attributs BGP clés pour la bascule
| Attribut               | Effet                                                           | Cas d’usage                                                               |
| ---------------------- | --------------------------------------------------------------- | ------------------------------------------------------------------------- |
| **Local Preference**   | Contrôle la préférence du chemin sortant (plus élevé = préféré) | Rendre le chemin principal préféré pour le trafic sortant de votre réseau |
| **AS-path prepending** | Fait paraître un chemin plus long (moins préféré)               | Influencer le choix du chemin de retour par OVHcloud                      |
| **MED**                | Suggère une préférence au côté distant                          | Peut ne pas être pris en compte dans toutes les configurations OVHcloud   |
#### 4. Associer les deux liens à votre vRack
Associez les deux services OVHcloud Connect au **même vRack**. Voir [Associer à un vRack](/fr/guides/network/ovhcloud-connect/associate-vrack.md).
#### 5. Configurer les sous-réseaux dans les deux AZ
Configurez des sous-réseaux privés dans les deux Availability Zones. Voir [Configurer votre réseau vRack](/fr/guides/network/ovhcloud-connect/vrack-network-setup.md).
#### 6. Tester la bascule
**Cette étape est critique.** Ne sautez pas les tests de bascule.
1. **Vérifiez le fonctionnement normal :**
   - Les deux sessions BGP sont à l’état Established.
   - Le trafic transite par le lien principal.

2. **Simulez la défaillance du lien principal :**
   - Arrêtez la session BGP principale ou déconnectez physiquement le lien principal.
   - Vérifiez que le trafic bascule vers le lien de secours dans le délai de convergence BGP (généralement 30 à 90 secondes ; cela peut être plus rapide avec BFD).
   - Confirmez l’absence de perte de paquets au-delà de la fenêtre de convergence.

3. **Restaurez le lien principal :**
   - Remettez le lien principal en service.
   - Vérifiez que le trafic revient sur le chemin principal.

4. **Testez l’inverse :**
   - Simulez une défaillance du lien de secours pendant que le principal est actif. Cela confirme que les deux liens fonctionnent indépendamment.
#### 7. Mettre en place la supervision
Supervisez les **deux liens** indépendamment. Configurez des alertes pour :
- Les chutes de session BGP sur l’un ou l’autre lien
- Le déséquilibre de trafic (tout le trafic sur un seul lien peut indiquer une défaillance de l’autre)
- La bande passante approchant la capacité maximale sur l’un ou l’autre lien
Voir [Superviser](/fr/guides/network/ovhcloud-connect/monitor.md).
### Avancé : configuration actif/actif
Pour un débit maximal et une bascule plus rapide, vous pouvez exploiter les deux liens en mode **actif/actif** :
- Définissez une **Local Preference égale** sur les deux chemins.
- Utilisez **ECMP (Equal-Cost Multi-Path)** s’il est pris en charge.
- Le trafic est réparti sur les deux liens.
- Si un lien tombe en panne, l’intégralité du trafic transite immédiatement par le lien restant.
> Le mode actif/actif offre une bande passante agrégée plus élevée mais nécessite une planification de capacité rigoureuse — chaque lien doit être en mesure d’absorber seul la totalité de la charge en cas de défaillance.


**WAN**

[](#)### Prérequis
- Un compte OVHcloud avec un vRack
- Deux services OVHcloud Connect (Direct, Provider ou un mix) se terminant sur **des PoPs différents**
- Un backbone WAN (MPLS ou SD-WAN) avec des circuits atteignant les deux PoPs
- Des équipements de bordure WAN compatibles BGP
- Un plan d’adressage IP sans recouvrement entre vos sous-réseaux WAN et OVHcloud
### Architecture
![Schéma d’architecture résiliente WAN](/images/network/ovhcloud-connect/resilient-architecture/fig-2.fr.svg)### Quand utiliser cette architecture
- **Connectivité WAN critique pour l’activité** — plusieurs sites dépendent de l’accès à OVHcloud.
- **Exigences de SLA ≥ 99,99 %** — des liens redondants sont nécessaires pour des garanties de disponibilité premium.
- **SD-WAN avec chemins diversifiés** — les plateformes SD-WAN peuvent router automatiquement sur le meilleur chemin disponible.
### Étape par étape
#### 1. Commander deux liens OVHcloud Connect
Commandez sur **des PoPs différents** pour assurer la diversité physique. Vous pouvez combiner connexions Direct et Provider.
#### 2. Provisionner les deux circuits WAN
Coordonnez-vous avec votre opérateur WAN pour livrer des circuits sur les deux PoPs. Si vous utilisez une plateforme SD-WAN, configurez les deux chemins comme connexions de transport (underlay).
#### 3. Configurer BGP avec bascule
Mettez en place deux sessions BGP avec des politiques de routage adaptées :
- **Actif/passif :** utilisez la Local Preference et l’AS-path prepending (voir l’onglet On-Premises pour des exemples BGP détaillés).
- **Actif/actif :** utilisez ECMP pour répartir la charge sur les deux liens.
- **Intégration SD-WAN :** de nombreuses plateformes SD-WAN détectent la qualité des liens et redirigent le trafic automatiquement, en complément de la bascule BGP.
#### 4. Associer les deux liens à votre vRack
Les deux services OVHcloud Connect doivent être associés au même vRack.
#### 5. Configurer les sous-réseaux dans les AZ
Répartissez les sous-réseaux entre les deux AZ pour une redondance complète. Voir [Configurer votre réseau vRack](/fr/guides/network/ovhcloud-connect/vrack-network-setup.md).
#### 6. Tester la bascule
1. Vérifiez que les deux sessions BGP sont à l’état Established.
2. Arrêtez le lien principal et confirmez que le trafic bascule vers le lien de secours.
3. Restaurez le lien principal et vérifiez que le trafic revient.
4. Répétez pour le lien de secours.
#### 7. Superviser les deux chemins
Mettez en place une supervision indépendante pour chaque lien, chaque session BGP et chaque circuit WAN. Voir [Superviser](/fr/guides/network/ovhcloud-connect/monitor.md).
### Considérations SD-WAN
Si vous utilisez un overlay SD-WAN :
- Configurez les liens OVHcloud Connect comme **transports underlay** dans votre contrôleur SD-WAN.
- La plateforme SD-WAN peut effectuer une **sélection de chemin** basée sur la latence, la gigue et la perte de paquets — plus rapidement que la convergence BGP.
- Assurez-vous que les politiques BGP et SD-WAN sont **alignées** (évitez les décisions de routage contradictoires).


**AWS**

[](#)### Prérequis
- Un **compte AWS** avec un VPC configuré
- Un **compte OVHcloud** avec un vRack
- Deux connexions AWS Direct Connect sur **des emplacements différents**
- Deux services OVHcloud Connect Provider sur **des PoPs différents**
- Un opérateur partagé (Megaport ou Equinix) présent sur les deux emplacements
- Des plages IP non chevauchantes entre le VPC AWS et les sous-réseaux OVHcloud
### Architecture
![Schéma d’architecture résiliente AWS](/images/network/ovhcloud-connect/resilient-architecture/fig-3.fr.svg)### Stratégie de résilience
Pour une disponibilité maximale entre AWS et OVHcloud :
1. **Deux connexions AWS Direct Connect** sur des emplacements AWS Direct Connect différents.
2. **Deux VXC opérateur** (ou opérateurs distincts) reliant deux PoPs OVHcloud.
3. **Deux services OVHcloud Connect** sur des PoPs différents, tous deux associés à votre vRack.
4. **Bascule BGP** configurée sur les deux chemins.
### Étape par étape
#### 1. Commander des connexions AWS Direct Connect redondantes
Dans la **console AWS**, créez deux connexions Direct Connect sur **des emplacements différents** :
- Connexion 1 : emplacement AWS Direct Connect A
- Connexion 2 : emplacement AWS Direct Connect B
Créez une **Private VIF** sur chaque connexion pointant vers votre VPC (via Virtual Private Gateway ou Transit Gateway).
> AWS recommande d’utiliser **Transit Gateway** avec plusieurs Direct Connect Gateways pour des architectures multi-régions résilientes.
#### 2. Commander deux services OVHcloud Connect Provider
Commandez sur **deux PoPs OVHcloud différents**. Récupérez deux clés d’appairage distinctes. Voir [Commander Provider](/fr/guides/network/ovhcloud-connect/order-provider.md).
#### 3. Créer des ponts opérateur redondants
Sur la plateforme de votre opérateur :
- **Pont 1 :** AWS Direct Connect 1 ↔ OVHcloud PoP A
- **Pont 2 :** AWS Direct Connect 2 ↔ OVHcloud PoP B
Si vous utilisez un MCR (Cloud Router), créez des instances MCR séparées ou des sessions de peering pour chaque chemin.
#### 4. Configurer la bascule BGP
Assurez-vous que les préférences de routage BGP sont définies de telle sorte que le trafic privilégie le chemin principal et bascule sur le chemin de secours :
- Utilisez la **Local Preference** côté OVHcloud.
- Utilisez l'**AS-path prepending** sur le chemin de secours.
- Sur AWS, utilisez **Direct Connect Gateway** avec des priorités de routes adaptées.
Consultez [Configurer OCC L3 avec BGP](/fr/guides/network/ovhcloud-connect/l3-bgp.md) pour les instructions détaillées.
#### 5. Associer les deux liens à votre vRack
Associez les deux services OVHcloud Connect au même vRack. Voir [Associer à un vRack](/fr/guides/network/ovhcloud-connect/associate-vrack.md).
#### 6. Tester la bascule
1. Vérifiez que les deux chemins sont actifs et acheminent du trafic.
2. Désactivez la VIF AWS Direct Connect principale — confirmez que le trafic transite par le chemin de secours.
3. Désactivez le service OVHcloud Connect principal — confirmez que le trafic transite par le chemin de secours.
4. Restaurez les deux et vérifiez que le trafic revient sur le chemin préféré.
### Considérations de coût
Une connectivité résiliente entre AWS et OVHcloud nécessite :
- 2× connexions AWS Direct Connect (facturation AWS)
- 2× VXC opérateur ou sessions MCR (facturation opérateur)
- 2× services OVHcloud Connect (facturation OVHcloud)
Planifiez votre budget en conséquence. Le coût de la redondance est généralement justifié par la réduction du risque pour les workloads de production.
> Pour plus d’informations, veuillez consulter la [documentation AWS Direct Connect](https://docs.aws.amazon.com/directconnect/).


**Azure**

[](#)### Prérequis
- Un **abonnement Azure** avec les autorisations nécessaires pour créer des circuits ExpressRoute
- Un **compte OVHcloud** avec un vRack
- Deux circuits Azure ExpressRoute sur **des emplacements de peering différents**
- Deux services OVHcloud Connect Provider sur **des PoPs différents**
- Un opérateur partagé (Megaport ou Equinix) présent sur les deux emplacements
- Un vRack avec Multi-AZ activé ([guide Multi-AZ](/fr/guides/network/ovhcloud-connect/multi-az.md))
- Des plages IP non chevauchantes entre le VNet Azure et le vRack OVHcloud
### Architecture
![Schéma d’architecture résiliente Azure](/images/network/ovhcloud-connect/resilient-architecture/fig-4.fr.svg)### Stratégie de résilience
Microsoft recommande **deux circuits ExpressRoute sur des emplacements de peering différents** pour une disponibilité maximale. Combinés à deux services OVHcloud Connect Provider sur des PoPs différents, cela offre une redondance de bout en bout :
| Composant          | Principal                 | Secours                   |
| ------------------ | ------------------------- | ------------------------- |
| Azure ExpressRoute | Circuit 1 (emplacement A) | Circuit 2 (emplacement B) |
| VXC opérateur      | Set VXC 1                 | Set VXC 2                 |
| OVHcloud Connect   | Service 1 (PoP A)         | Service 2 (PoP B)         |
| AZ OVHcloud        | AZ 1                      | AZ 2                      |
### Étape par étape
#### 1. Créer deux circuits ExpressRoute
Dans le **portail Azure** → **Créer ExpressRoute** (à répéter pour chaque circuit) :
| Paramètre              | Circuit 1                          | Circuit 2                              |
| ---------------------- | ---------------------------------- | -------------------------------------- |
| Provider               | Megaport (ou Equinix)              | Megaport (ou Equinix)                  |
| Emplacement de peering | Emplacement A (par exemple, Paris) | Emplacement B (par exemple, Francfort) |
| Bande passante         | 1 Gbps                             | 1 Gbps                                 |
| SKU                    | Standard ou Premium                | Standard ou Premium                    |
Notez la **clé de service** de chaque circuit.
> **Astuce :** utilisez **ExpressRoute Premium** si vos VNets se trouvent dans des régions Azure différentes des emplacements de peering.
#### 2. Commander deux services OVHcloud Connect Provider
[Commandez deux services OVHcloud Connect Provider](/fr/guides/network/ovhcloud-connect/order-provider.md) sur des PoPs différents correspondant aux emplacements de peering ExpressRoute :
- OVHcloud Connect 1 → PoP A
- OVHcloud Connect 2 → PoP B
Récupérez les deux **clés d’appairage**.
#### 3. Créer les ponts opérateur pour chaque chemin
**Chemin 1 (principal) :**
1. Créez un MCR ou un port à l’emplacement A.
2. VXC : Azure ExpressRoute 1 (clé de service 1) → MCR A.
3. VXC : MCR A → OVHcloud Connect 1 (clé d’appairage 1).
**Chemin 2 (secours) :**
1. Créez un MCR ou un port à l’emplacement B.
2. VXC : Azure ExpressRoute 2 (clé de service 2) → MCR B.
3. VXC : MCR B → OVHcloud Connect 2 (clé d’appairage 2).
#### 4. Configurer le peering privé Azure sur les deux circuits
Pour chaque circuit ExpressRoute, configurez l'**Azure Private Peering** :
| Paramètre      | Circuit 1                | Circuit 2                |
| -------------- | ------------------------ | ------------------------ |
| ASN du peer    | ASN du provider          | ASN du provider          |
| /30 principal  | 169.254.100.0/30         | 169.254.101.0/30         |
| /30 secondaire | 169.254.100.4/30         | 169.254.101.4/30         |
| ID VLAN        | Attribué par le provider | Attribué par le provider |
#### 5. Lier les deux circuits à votre VNet
Dans Azure :
1. Accédez à **Virtual Network Gateways** → **Connections**.
2. Ajoutez Connection 1 → ExpressRoute Circuit 1 (poids : **100**).
3. Ajoutez Connection 2 → ExpressRoute Circuit 2 (poids : **50** — plus bas = secours).
Azure utilise le **poids de connexion** pour privilégier un chemin par rapport à l’autre.
#### 6. Configurer BGP côté OVHcloud avec bascule
Côté OVHcloud, utilisez [Configurer OCC L3 avec BGP](/fr/guides/network/ovhcloud-connect/l3-bgp.md) pour privilégier le chemin principal :
| Chemin                         | Local Preference | AS-path prepend |
| ------------------------------ | ---------------- | --------------- |
| OVHcloud Connect 1 (principal) | 200              | Aucun           |
| OVHcloud Connect 2 (secours)   | 100              | 1× prepend      |
#### 7. Associer les deux services à votre vRack
[Associez les deux services OVHcloud Connect](/fr/guides/network/ovhcloud-connect/associate-vrack.md) au même vRack. Les deux injecteront des routes ; le vRack utilisera le chemin avec la Local Preference la plus élevée.
#### 8. Tester la bascule
| Test                          | Action                                      | Résultat attendu                                                       |
| ----------------------------- | ------------------------------------------- | ---------------------------------------------------------------------- |
| Défaillance du lien principal | Désactiver la VIF ExpressRoute 1 dans Azure | Le trafic bascule vers ExpressRoute 2 dans le délai de convergence BGP |
| Défaillance OCC principal     | Désactiver OVHcloud Connect 1               | Le trafic bascule vers OVHcloud Connect 2                              |
| Défaillance opérateur         | Mettre hors service les VXC du MCR A        | Le trafic bascule sur le chemin via MCR B                              |
| Récupération complète         | Réactiver tous les liens                    | Le trafic revient sur le chemin principal                              |
> **Temps de convergence :** la bascule BGP s’effectue généralement en **30 à 90 secondes** selon les hold timers et la configuration BFD.
### Considérations spécifiques à Azure
- **ExpressRoute Global Reach :** si les deux PoPs OVHcloud sont dans des régions Azure différentes, envisagez d’activer [Global Reach](https://learn.microsoft.com/fr-fr/azure/expressroute/expressroute-global-reach) pour permettre la communication directe entre circuits.
- **FastPath :** pour les passerelles Ultra Performance ou ErGw3AZ, activez [FastPath](https://learn.microsoft.com/fr-fr/azure/expressroute/about-fastpath) afin d’améliorer les performances réseau.
- **Limites de routes :** Azure Private Peering prend en charge jusqu’à **4 000 routes** par circuit. Agrégez les préfixes OVHcloud pour rester dans la limite.
> Pour plus d’informations, veuillez consulter la [documentation Azure ExpressRoute](https://learn.microsoft.com/fr-fr/azure/expressroute/).


**GCP**

[](#)### Prérequis
- Un **projet GCP** avec le rôle Compute Network Admin
- Deux Cloud Routers (un par région ou domaine de disponibilité)
- Un **compte OVHcloud** avec un vRack
- Deux services OVHcloud Connect Provider sur **des PoPs différents**
- Un opérateur partagé (Megaport ou Equinix) présent sur les deux emplacements
- Un vRack avec Multi-AZ activé
- Des **plages IP non chevauchantes** entre le VPC GCP et le vRack OVHcloud
### Architecture
![Schéma d’architecture résiliente GCP](/images/network/ovhcloud-connect/resilient-architecture/fig-5.fr.svg)### Stratégie de résilience
Google Cloud recommande d’utiliser des VLAN attachments dans **des edge availability domains différents** pour atteindre un SLA de 99,9 % à 99,99 %. Combiné à des liens OVHcloud Connect en double, vous obtenez une résilience complète de bout en bout :
| Composant           | Principal         | Secours           |
| ------------------- | ----------------- | ----------------- |
| GCP VLAN attachment | Edge domain zone1 | Edge domain zone2 |
| VXC opérateur       | Set VXC 1         | Set VXC 2         |
| OVHcloud Connect    | Service 1 (PoP A) | Service 2 (PoP B) |
| AZ OVHcloud         | AZ 1              | AZ 2              |
##### Niveaux de SLA GCP
| Configuration                                                 | SLA GCP   |
| ------------------------------------------------------------- | --------- |
| Un seul VLAN attachment                                       | Aucun SLA |
| Deux attachments dans des edge domains différents, même metro | 99,9 %    |
| Quatre attachments dans deux metros différents                | 99,99 %   |
### Étape par étape
#### 1. Créer deux Cloud Routers
Créez un Cloud Router dans chaque région ou pour chaque edge availability domain :
| Router              | Région         | ASN                |
| ------------------- | -------------- | ------------------ |
| `router-ovhcloud-1` | `europe-west1` | 16550 (par défaut) |
| `router-ovhcloud-2` | `europe-west3` | 16550 (par défaut) |
#### 2. Créer deux VLAN attachments
Pour chaque Cloud Router, créez un **VLAN attachment Partner Interconnect** :
| Attachment     | Cloud Router        | Edge availability domain |
| -------------- | ------------------- | ------------------------ |
| `attachment-1` | `router-ovhcloud-1` | `zone1`                  |
| `attachment-2` | `router-ovhcloud-2` | `zone2`                  |
Notez les deux **clés d’appairage GCP**.
#### 3. Commander deux services OVHcloud Connect Provider
[Commandez deux services OVHcloud Connect Provider](/fr/guides/network/ovhcloud-connect/order-provider.md) sur des PoPs différents :
- OVHcloud Connect 1 → PoP A
- OVHcloud Connect 2 → PoP B
Récupérez les deux **clés d’appairage OVHcloud**.
#### 4. Créer les ponts opérateur pour chaque chemin
**Chemin 1 (principal) :**
1. MCR ou port à l’emplacement A.
2. VXC : GCP Partner Interconnect (clé d’appairage GCP 1) → MCR A.
3. VXC : MCR A → OVHcloud Connect 1 (clé d’appairage OVHcloud 1).
**Chemin 2 (secours) :**
1. MCR ou port à l’emplacement B.
2. VXC : GCP Partner Interconnect (clé d’appairage GCP 2) → MCR B.
3. VXC : MCR B → OVHcloud Connect 2 (clé d’appairage OVHcloud 2).
#### 5. Activer les deux VLAN attachments GCP
Dans la console GCP :
1. Accédez à **Hybrid Connectivity** → **VLAN attachments**.
2. Pour chaque attachment : cliquez sur **Activate** dès qu’il affiche « Pending customer ».
3. Vérifiez que les sessions BGP sont établies dans les deux Cloud Routers.
#### 6. Configurer la bascule BGP
**Côté GCP :**
Le Cloud Router de GCP utilise le **MED (Multi-Exit Discriminator)** pour influencer la sélection du chemin. Définissez des valeurs MED différentes :
| Attachment                 | MED annoncé              |
| -------------------------- | ------------------------ |
| `attachment-1` (principal) | 100 (plus bas = préféré) |
| `attachment-2` (secours)   | 200                      |
Vous pouvez configurer le MED via les annonces de routes personnalisées dans les paramètres du peer BGP du Cloud Router.
**Côté OVHcloud :**
Utilisez [Configurer OCC L3 avec BGP](/fr/guides/network/ovhcloud-connect/l3-bgp.md) :
| Chemin                         | Local Preference | AS-path prepend |
| ------------------------------ | ---------------- | --------------- |
| OVHcloud Connect 1 (principal) | 200              | Aucun           |
| OVHcloud Connect 2 (secours)   | 100              | 1× prepend      |
#### 7. Associer les deux services à votre vRack
[Associez les deux services OVHcloud Connect](/fr/guides/network/ovhcloud-connect/associate-vrack.md) au même vRack.
#### 8. Tester la bascule
| Test                    | Action                          | Résultat attendu                          |
| ----------------------- | ------------------------------- | ----------------------------------------- |
| Défaillance du lien GCP | Désactiver le VLAN attachment 1 | Le trafic bascule vers l’attachment 2     |
| Défaillance du lien OCC | Désactiver OVHcloud Connect 1   | Le trafic bascule vers OVHcloud Connect 2 |
| Défaillance opérateur   | Mettre hors service le MCR A    | Le trafic bascule sur le chemin via MCR B |
| Récupération complète   | Tout réactiver                  | Le trafic revient sur le chemin principal |
### Considérations spécifiques à GCP
- **Annonces de routes personnalisées :** utilisez les annonces de routes personnalisées du Cloud Router pour contrôler les sous-réseaux annoncés à OVHcloud. Évitez d’annoncer le VPC entier si seuls certains sous-réseaux sont nécessaires.
- **Dataplane v2 :** si vous utilisez GKE avec Dataplane v2, veillez à inclure les plages CIDR des Pods dans les annonces de routes si les pods GKE doivent communiquer avec OVHcloud.
- **Shared VPC :** si vous utilisez un Shared VPC, créez l’Interconnect dans le projet hôte et partagez-le avec les projets de service.
- **MTU :** GCP Interconnect prend en charge un **MTU de 1440** pour Partner Interconnect. Assurez-vous qu’OVHcloud Connect et les VXC opérateur utilisent des paramètres MTU correspondants.
> Pour plus d’informations, veuillez consulter la [documentation GCP Interconnect](https://docs.cloud.google.com/network-connectivity/docs/interconnect) et la [documentation GCP Cloud Router](https://docs.cloud.google.com/network-connectivity/docs/router).


### Et ensuite ?

- [Architecture simple](/fr/guides/network/ovhcloud-connect/simple-architecture.md) pour les cas d’usage non critiques
- [Superviser vos connexions](/fr/guides/network/ovhcloud-connect/monitor.md)
- [Configuration Multi-AZ](/fr/guides/network/ovhcloud-connect/multi-az.md) pour la résilience côté OVHcloud

### Aller plus loin

Pour une formation ou une assistance technique sur la mise en œuvre de nos solutions, contactez votre commercial ou consultez la page [Professional Services](https://www.ovhcloud.com/fr/professional-services/) pour obtenir un devis et faire analyser votre projet par nos experts.

Échangez avec notre [communauté d’utilisateurs](https://community.ovhcloud.com/).