--- title: "Dépannage d’OVHcloud Connect" description: "'Diagnostiquez et résolvez les problèmes les plus courants rencontrés avec OVHcloud Connect'" url: https://docs.ovhcloud.com/fr/guides/network/ovhcloud-connect/troubleshooting lang: fr lastUpdated: 2026-06-16 --- # Dépannage d’OVHcloud Connect ## Objectif Ce guide vous aide à diagnostiquer et à résoudre les problèmes les plus courants rencontrés avec OVHcloud Connect. Chaque section décrit un problème connu, ses causes possibles ainsi que les étapes pour le corriger. ## Avant de commencer ### Considérations générales - **Vérifiez toujours les deux côtés** — La plupart des problèmes liés à OVHcloud Connect impliquent des éléments de configuration ou physiques de votre côté comme du côté OVHcloud. Vérifiez votre routeur, le cross-connect (ou le circuit virtuel du fournisseur) ainsi que l’espace client OVHcloud avant d’ouvrir un ticket. - **Collectez les diagnostics au préalable** — Avant toute modification, recueillez l’état des interfaces, l’état BGP, un traceroute et les valeurs optiques. Ces informations accélèrent la résolution, que vous régliez le problème vous-même ou que vous deviez contacter le support. - **Vérifiez les maintenances planifiées** — Certains problèmes peuvent être causés par des travaux planifiés sur l’infrastructure OVHcloud ou chez votre fournisseur. Consultez toujours la page de statut avant d’approfondir le dépannage. ### Ressources utiles | Ressource | Lien | | -------------------------------- | ------------------------------------------------------------------------------------------ | | **FAQ** | [Foire aux questions](/fr/guides/network/ovhcloud-connect/faq.md) | | **Glossaire** | [Glossaire des termes OVHcloud Connect](/fr/guides/network/ovhcloud-connect/glossary.md) | | **Statut des services OVHcloud** | [status.ovhcloud.com](https://www.status-ovhcloud.com/) | | **Prérequis et limitations** | [Prérequis et limitations](/fr/guides/network/ovhcloud-connect/limits.md) | | **Guide de monitoring** | [Superviser votre OVHcloud Connect](/fr/guides/network/ovhcloud-connect/monitor.md) | | **Suivi d’incident** | [Déclarer et suivre un incident](/fr/guides/network/ovhcloud-connect/incident-followup.md) | *** ## Problème 1 — Aucune lumière sur le lien physique (OVHcloud Connect Direct) Après la commande d’OVHcloud Connect Direct, le lien physique n’affiche aucun signal optique d’un côté ou des deux. ### Causes possibles et solutions | # | Cause possible | Solution | | - | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | 1 | **Cross-connect non encore installé** | Contactez l’opérateur de votre datacenter et fournissez-lui la LOA. Consultez [Commander un cross-connect avec une LOA](/fr/guides/network/ovhcloud-connect/cross-connect-loa.md). | | 2 | **LOA mal interprétée par le datacenter** | Vérifiez les détails de la LOA avec l’opérateur du PoP : baie, cage, panneau de brassage, port, terminaison de la fibre. Consultez [Comment lire les informations d’une LOA](#comment-lire-les-informations-dune-loa) ci-dessous. | | 3 | **Inversion des fibres Tx/Rx** | Les fibres d’émission et de réception peuvent être inversées, ce qui fait arriver la lumière sur le mauvais port. Demandez à l’opérateur du datacenter de vérifier l’absence d’inversion Tx/Rx sur le cross-connect. | | 4 | **Problème de module SFP** | Assurez-vous que le SFP correspond à la bande passante commandée : 1000Base-LX/LH pour 1 Gbps, 10GBase-LR pour 10 Gbps, 100GBase-LR4 pour 100 Gbps. Remplacez le SFP s’il est défectueux. Consultez [Prérequis et limitations](/fr/guides/network/ovhcloud-connect/limits.md). | | 5 | **Port désactivé ou verrouillé** | Vérifiez l’espace client OVHcloud — le port peut être verrouillé administrativement. Si la valeur optique OUT est DOWN, le port peut également être en cours de résiliation. | | 6 | **Câble cross-connect défectueux** | Demandez à l’opérateur du datacenter de tester le câble ou de provisionner un nouveau câble. | ### Comment lire les informations d’une LOA Une LOA classique contient des informations formatées ainsi : ```text Equipment: 103 PA3:OG:00GMC3:OVH Patch Panel: PP:0103:1132697 Port: P16/FO31-32/BCK Fiber Termination: SC/PC ``` Interprétation : | Champ | Valeur | Signification | | ---------------------------- | ----------------- | ---------------------------------------- | | Baie | 103 | Position de la baie où se trouve le rack | | Cage | PA3:OG:00GMC3:OVH | Référence du rack | | Panneau de brassage (côté Z) | PP:0103:1132697 | Position du switch côté OVHcloud | | Port | 16 | Position sur le switch | | Port fibre optique A | 31 | Identifiant de la fibre A | | Port fibre optique B | 32 | Identifiant de la fibre B | | Côté | BCK (Back) | Avant ou arrière de l’équipement | | Terminaison de fibre | SC/PC | Type de connecteur | ### Vérifier les valeurs optiques Dans l’espace client OVHcloud, accédez à `Network ` > `OVHcloud Connect `, sélectionnez votre service, puis vérifiez les valeurs optiques IN/OUT : - **OUT est DOWN** — Le port côté OVHcloud n’émet pas de lumière. Causes possibles : problème de port, service en cours de résiliation, port verrouillé, panne de SFP. - **IN est DOWN** — OVHcloud ne reçoit pas de lumière de votre côté. Causes possibles : cross-connect non installé, votre équipement non connecté, votre port désactivé, inversion des fibres Tx/Rx. ### Logigramme de diagnostic ![Logigramme de diagnostic en l’absence de lumière sur le lien physique](/images/network/ovhcloud-connect/troubleshooting/fig-1.fr.svg) *** ## Problème 2 — Lien Ethernet down (pas de peering) malgré une lumière UP Les valeurs optiques sont UP des deux côtés, mais l’interface Ethernet reste DOWN et aucun peering ne peut être établi. ### Causes possibles et solutions | # | Cause possible | Solution | | - | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **Type de SFP incompatible** | Le SFP doit correspondre à la bande passante commandée. Utilisez **1000Base-LX/LH** pour 1 Gbps, **10GBase-LR** pour 10 Gbps, **100GBase-LR4** pour 100 Gbps. | | 2 | **Auto-négociation activée** | L’auto-négociation **n’est pas prise en charge** sur OVHcloud Connect. Désactivez-la sur votre routeur (voir les commandes ci-dessous). | | 3 | **Vitesse incompatible** | La vitesse de votre interface doit correspondre à celle du lien commandé. Configurez-la explicitement. | | 4 | **SFP ou transceiver défectueux** | Essayez de remplacer le module SFP de votre côté. | ### Désactiver l’auto-négociation **Cisco IOS :** ```text interface GigabitEthernet0/0 no negotiate auto ``` ou : ```text interface GigabitEthernet0/0 speed nonegotiate ``` **Cisco NX-OS :** ```text interface Ethernet1/1 speed 1000 no negotiate auto ``` **Juniper JunOS :** ```text set interfaces ge-0/0/0 ether-options no-auto-negotiation ``` *** ## Problème 3 — Session BGP bloquée à l’état Active ou Idle Le lien physique est up, mais la session BGP n’atteint pas l’état `Established`. ### Causes possibles et solutions | # | Cause possible | Solution | | - | ---------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **Adresse IP du pair incorrecte** | Vérifiez que l’IP du pair configurée sur votre routeur correspond exactement à l’IP attribuée par OVHcloud dans l’espace client. Le sous-réseau de peering du PoP est un /30 : OVHcloud prend la première IP, vous prenez la seconde. Consultez [Configurer OCC L3 avec BGP](/fr/guides/network/ovhcloud-connect/l3-bgp.md). | | 2 | **ASN incorrect** | Vérifiez que vous établissez le peering avec l’ASN OVHcloud **35540** et que votre propre ASN est correctement configuré (plage d’ASN privés 64512-65534 recommandée). Évitez les ASN réservés : **65501** (PoP UE), **65502** (PoP CA), **65519** (PoP Asie). | | 3 | **ID de VLAN incompatible** | Le tag VLAN sur votre interface doit correspondre à l’ID de VLAN configuré dans la configuration du PoP de l’espace client OVHcloud. Vérifiez avec `show interfaces` ou `show vlans`. | | 4 | **Pare-feu bloquant le port TCP 179** | BGP utilise le port TCP 179. Assurez-vous qu’aucun pare-feu ou ACL ne bloque ce port entre les deux pairs. | | 5 | **Interface non configurée avec l’encapsulation correcte** | Pour les connexions L3, l’interface doit utiliser l’encapsulation 802.1Q avec l’ID de VLAN correct. Consultez les exemples de configuration dans [Configurer OCC L3 avec BGP](/fr/guides/network/ovhcloud-connect/l3-bgp.md). | | 6 | **Configuration du PoP non créée chez OVHcloud** | Vérifiez dans l’espace client OVHcloud qu’une configuration de PoP a bien été créée pour votre service. Sans cela, le routeur OVHcloud n’établira pas le peering. | | 7 | **Authentification MD5 incompatible** | Si MD5 est configuré, le mot de passe doit correspondre des deux côtés. Vérifiez avec les détails de votre service OVHcloud Connect. | ### Commandes de vérification **Cisco IOS :** ```bash show ip bgp summary show bgp ipv4 unicast neighbors 192.0.2.1 show interfaces GigabitEthernet0/0 show ip interface brief ``` **Juniper JunOS :** ```bash show bgp summary show bgp neighbor 192.0.2.1 show interfaces terse ``` ### Logigramme de diagnostic ![Logigramme de diagnostic pour une session BGP bloquée à l’état Active ou Idle](/images/network/ovhcloud-connect/troubleshooting/fig-2.fr.svg) *** ## Problème 4 — Session BGP établie mais aucune route reçue La session BGP affiche `Established`, mais aucun préfixe n’est reçu d’OVHcloud (ou de votre réseau). ### Causes possibles et solutions | # | Cause possible | Solution | | - | --------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **Instruction `network` ou politique d’export manquante** | Sur votre routeur, assurez-vous d’annoncer les bons préfixes via les commandes `network` (Cisco) ou les politiques d’export (Juniper). Consultez [Configurer OCC L3 avec BGP](/fr/guides/network/ovhcloud-connect/l3-bgp.md). | | 2 | **Filtre de préfixes bloquant les routes** | Votre prefix-list d’import peut être trop restrictive et filtrer les routes OVHcloud. Vérifiez vos prefix-lists et vos politiques de routage. | | 3 | **vRack non associé** | Les routes OVHcloud ne sont échangées que si le service OVHcloud Connect est associé à un vRack. Vérifiez l’association dans l’espace client. Consultez [Associer à un vRack](/fr/guides/network/ovhcloud-connect/associate-vrack.md). | | 4 | **Sous-réseaux d’AZ non configurés** | Si aucun sous-réseau n’est défini dans la configuration de l’Availability Zone, aucune route ne pourra être échangée. Consultez [Configurer votre réseau vRack](/fr/guides/network/ovhcloud-connect/vrack-network-setup.md). | | 5 | **Limite maximale de préfixes atteinte** | OVHcloud prend en charge jusqu’à **100 préfixes** par session BGP. Si vous dépassez cette limite, la session peut cesser d’accepter de nouvelles routes. Agrégez vos préfixes. | | 6 | **Route absente de la table de routage** | Le préfixe que vous tentez d’annoncer doit exister dans la table de routage de votre routeur (via un réseau connecté, une route statique ou un IGP). | ### Commandes de vérification **Cisco IOS :** ```bash show ip bgp summary show ip bgp neighbors 192.0.2.1 received-routes show ip bgp neighbors 192.0.2.1 advertised-routes show ip route bgp ``` **Juniper JunOS :** ```bash show bgp summary show route receive-protocol bgp 192.0.2.1 show route advertising-protocol bgp 192.0.2.1 show route protocol bgp ``` *** ## Problème 5 — Session BGP qui flappe en permanence (montées et descentes répétées) La session BGP oscille entre les états `Established` et `Active`/`Idle`, provoquant une connectivité intermittente. ### Causes possibles et solutions | # | Cause possible | Solution | | - | --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **Lien physique instable** | Vérifiez les compteurs d’erreurs des interfaces (`show interfaces`) pour les erreurs CRC, les erreurs d’entrée ou les drops de sortie. Inspectez le SFP, le câble cross-connect et le panneau de brassage. | | 2 | **MTU incompatible** | Une incompatibilité de MTU entre votre équipement et OVHcloud peut entraîner la perte des grands paquets de mise à jour BGP. Le MTU par défaut est de **1500 octets**. Confirmez les paramètres de MTU des deux côtés. | | 3 | **Expiration du hold timer BGP** | Le hold timer BGP par défaut est de 90 secondes. Si des keepalives sont perdus à cause de l’instabilité du lien, la session tombe. Envisagez d’ajuster les timers BGP, mais corrigez d’abord la cause racine. | | 4 | **Surcharge CPU ou mémoire de votre routeur** | Le traitement BGP peut être retardé si le routeur est en forte charge. Vérifiez l’utilisation CPU et mémoire. | | 5 | **Changements agressifs de préfixes** | Le retrait et l’annonce rapides de routes peuvent déclencher du flap dampening. Stabilisez vos annonces de routage. | ### Commandes de vérification **Cisco IOS :** ```bash show interfaces GigabitEthernet0/0 show ip bgp summary show ip bgp flap-statistics show log | include BGP ``` **Juniper JunOS :** ```bash show interfaces ge-0/0/0 extensive show bgp summary show log messages | match BGP ``` *** ## Problème 6 — Le trafic ne circule pas malgré une session BGP établie et des routes échangées BGP est up, les routes apparaissent dans la table de routage des deux côtés, mais le trafic réel (ping, données applicatives) ne passe pas. ### Causes possibles et solutions | # | Cause possible | Solution | | - | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **Pare-feu ou ACL bloquant le trafic** | Vérifiez les règles de pare-feu et les listes de contrôle d’accès sur votre routeur, sur vos ressources OVHcloud (security groups, iptables) et sur tout équipement intermédiaire. | | 2 | **Tag VLAN incompatible** | L’ID de VLAN sur votre interface doit correspondre au VLAN configuré chez OVHcloud. Une incompatibilité entraîne un drop silencieux du trafic taggé. | | 3 | **Configuration de sous-réseau incorrecte** | Vérifiez que les IPs source et destination appartiennent aux bons sous-réseaux et qu’aucune plage ne se chevauche. Consultez [Configurer votre réseau vRack](/fr/guides/network/ovhcloud-connect/vrack-network-setup.md). | | 4 | **Routage asymétrique** | Si vous avez plusieurs chemins (par exemple internet + OVHcloud Connect), le trafic retour peut emprunter un chemin différent. Garantissez un routage symétrique grâce aux attributs BGP (Local Preference, AS-path prepending). | | 5 | **Ressource vRack non rattachée** | La ressource OVHcloud cible (serveur Bare Metal, instance Public Cloud, Hosted Private Cloud) doit être rattachée au même vRack qu’OVHcloud Connect. Vérifiez dans l’espace client. | | 6 | **MTU incompatible entraînant de la fragmentation** | Les grands paquets peuvent être perdus silencieusement si le MTU diffère entre les segments. Testez avec différentes tailles de paquets : `ping -s 1472 -M do ` (Linux) pour vérifier les problèmes de fragmentation. | ### Commandes de vérification **De votre côté :** ```bash ping 172.16.1.1 traceroute 172.16.1.1 ``` **Depuis un hôte Linux dans OVHcloud :** ```bash ping -c 10 10.0.0.1 traceroute 10.0.0.1 mtr -r -c 50 10.0.0.1 ``` *** ## Problème 7 — Performances lentes ou latence élevée La connexion fonctionne, mais le débit est inférieur aux attentes ou la latence est plus élevée que la normale. ### Causes possibles et solutions | # | Cause possible | Solution | | - | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | 1 | **Saturation de la bande passante** | Vérifiez l’utilisation des interfaces dans l’espace client OVHcloud et sur votre routeur. Si vous dépassez régulièrement 80 % de la bande passante provisionnée, planifiez une montée en gamme. | | 2 | **MTU incompatible entraînant de la fragmentation** | Les paquets fragmentés réduisent le débit effectif. Vérifiez le MTU de bout en bout et exécutez une découverte de path MTU : `ping -s 1472 -M do `. | | 3 | **Erreurs d’interface (CRC, FCS, drops)** | Vérifiez les compteurs d’erreurs avec `show interfaces`. Les problèmes physiques (fibre encrassée, SFP défectueux, connecteur mal serré) provoquent des retransmissions et dégradent les performances. | | 4 | **Routage sous-optimal** | Le trafic peut emprunter un chemin plus long qu’attendu. Vérifiez le `traceroute` et les attributs BGP (Local Preference, AS-path) pour garantir une sélection optimale du chemin. | | 5 | **Congestion chez le fournisseur** | Si vous utilisez OVHcloud Connect Provider, vérifiez le portail du fournisseur (Megaport, Equinix Fabric, Console Connect) pour l’utilisation et les alertes sur le circuit virtuel. | | 6 | **Mauvaise configuration de la taille de fenêtre TCP** | Pour les liens à haute bande passante et latence élevée, assurez-vous que le TCP window scaling est activé sur les hôtes afin de maximiser le débit. | ### Commandes de vérification **Cisco IOS :** ```bash show interfaces GigabitEthernet0/0 | include rate|error|drop|CRC show ip route 172.16.1.0 ``` **Depuis un hôte Linux :** ```bash iperf3 -c -t 30 mtr -r -c 100 ``` *** ## Problème 8 — Circuit virtuel du fournisseur ne s’établit pas (OVHcloud Connect Provider) Vous avez commandé un service OVHcloud Connect Provider, mais la connexion via votre fournisseur (Megaport, Equinix Fabric ou Console Connect) ne monte pas. ### Causes possibles et solutions | # | Cause possible | Solution | | - | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **Pairing key / clé de service incorrecte** | Vérifiez que la pairing key (ou clé de service) saisie dans le portail de votre fournisseur correspond exactement à la clé issue de l’espace client OVHcloud. | | 2 | **Circuit virtuel du fournisseur non provisionné** | Vérifiez le statut du VXC (Megaport), de la connexion virtuelle (Equinix) ou de la connexion (Console Connect) dans le portail du fournisseur. Il doit être affiché « Active » ou « Provisioned ». | | 3 | **Le fournisseur n’est pas présent au PoP** | Le fournisseur doit être disponible au PoP OVHcloud que vous avez sélectionné. Vérifiez la disponibilité du PoP dans [Fournisseurs](/fr/guides/network/ovhcloud-connect/providers.md) et [Localisations des PoP](/fr/guides/network/ovhcloud-connect/pop-locations-regions.md). | | 4 | **Bande passante incompatible** | La bande passante commandée côté fournisseur doit correspondre, ou être compatible, avec la bande passante du service OVHcloud Connect. | | 5 | **Maintenance ou incident côté fournisseur** | Consultez la page de statut de votre fournisseur pour vérifier les incidents en cours ou les maintenances planifiées. | :::tip **Astuce :** si le portail du fournisseur affiche la connexion comme « Active » mais qu’OVHcloud l’affiche encore comme « Pending », attendez quelques minutes que le provisionnement se termine. Si cela persiste au-delà de 30 minutes, contactez le support OVHcloud. ::: *** ## Problème 9 — Service commandé mais non livré / non configurable Votre service OVHcloud Connect apparaît dans l’espace client mais ne peut pas être configuré. ### Causes possibles et solutions | # | Cause possible | Solution | | - | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **Cross-connect non encore installé (Direct)** | Le service devient configurable une fois qu’OVHcloud détecte de la lumière sur le port. Commandez le cross-connect auprès de l’opérateur de votre datacenter à l’aide de la LOA et assurez-vous que votre équipement est connecté. | | 2 | **Fenêtre d’interconnexion de 60 jours (Direct)** | Après la commande, vous disposez de **60 jours** pour finaliser l’interconnexion (commander le cross-connect et interconnecter votre équipement). Au-delà de 60 jours — même sans détection de lumière — le service est considéré comme opérationnel et la facturation démarre. | | 3 | **Circuit du fournisseur non encore relié (Provider)** | Assurez-vous que le circuit virtuel du fournisseur est provisionné et relié au service OVHcloud à l’aide de la pairing key correcte. | | 4 | **Provisionnement en cours** | Les nouveaux services peuvent mettre quelques minutes à devenir configurables après la commande. Patientez et rafraîchissez l’espace client. | | 5 | **Problème de commande** | Si le service reste à l’état « Pending » pendant une période prolongée, contactez le support OVHcloud avec la référence de votre commande. | *** ## Problème 10 — Bascule inopérante en configuration Multi-AZ Vous disposez de deux liens OVHcloud Connect pour la redondance, mais le trafic ne bascule pas lorsque l’un des liens tombe. ### Causes possibles et solutions | # | Cause possible | Solution | | - | ---------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **Les deux liens dans le même PoP** | Pour une véritable résilience Multi-AZ, les deux liens doivent se terminer sur des **PoP différents** et des **Availability Zones différentes**. Consultez [Multi-AZ](/fr/guides/network/ovhcloud-connect/multi-az.md). | | 2 | **Bascule BGP non configurée** | Configurez les attributs BGP pour contrôler la sélection du chemin : utilisez la **Local Preference** pour privilégier le chemin principal et l'**AS-path prepending** sur le secours. Consultez [Configurer OCC L3 avec BGP](/fr/guides/network/ovhcloud-connect/l3-bgp.md). | | 3 | **BFD non activé** | Sans BFD, la bascule BGP repose sur les hold timers (90 secondes par défaut). Activez **BFD (Bidirectional Forwarding Detection)** pour réduire le temps de bascule à moins d’une seconde. Contactez le support OVHcloud pour confirmer la disponibilité de BFD pour votre service. | | 4 | **vRack non partagé entre les deux services** | Les deux services OVHcloud Connect doivent être associés au **même vRack** pour que la bascule fonctionne. Vérifiez dans l’espace client. Consultez [Associer à un vRack](/fr/guides/network/ovhcloud-connect/associate-vrack.md). | | 5 | **Prefix-list filtrant les routes de secours** | Assurez-vous que vos filtres de préfixes en import/export autorisent les mêmes préfixes sur les deux liens. | ### Commandes de vérification **Cisco IOS :** ```bash show ip bgp show ip bgp summary show ip route bgp show ip bgp neighbors 192.0.2.1 show ip bgp neighbors 198.51.100.1 ``` Vérifiez que les deux sessions BGP sont à l’état `Established` et que les routes sont reçues des deux pairs avec des attributs différents (Local Preference, longueur de l’AS-path). *** ## Problème 11 — Conflit d’adresses IP dans la configuration PoP ou DC La session BGP peut ne pas s’établir, ou le trafic peut être mal routé en raison de conflits d’adresses IP. ### Causes possibles et solutions | # | Cause possible | Solution | | - | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **Utilisation d’IPs réservées par OVHcloud** | Dans le sous-réseau /30 du PoP, la **première IP** est réservée à OVHcloud. Dans le sous-réseau /28 (minimum) du DC, les **trois premières IPs** sont réservées à OVHcloud. Assurez-vous d’utiliser les bonnes IPs. | | 2 | **Sous-réseaux qui se chevauchent** | Vos sous-réseaux on-premises ne doivent pas se chevaucher avec les sous-réseaux utilisés dans le vRack OVHcloud. Planifiez soigneusement votre adressage IP. Consultez [Configurer votre réseau vRack](/fr/guides/network/ovhcloud-connect/vrack-network-setup.md). | | 3 | **ASN en doublon** | Votre ASN BGP doit être différent de celui d’OVHcloud (35540) et des ASN réservés (65501, 65502, 65519). | *** ## Problème 12 — Fonctionnalités non prises en charge ou comportement inattendu Certaines fonctionnalités peuvent ne pas se comporter comme attendu en raison des limitations actuelles de la plateforme. ### Limitations connues | Fonctionnalité | Statut | Notes | | ----------------------------- | ------------------ | ------------------------------------------------------------------------------ | | **IPv6** | Non pris en charge | OVHcloud Connect ne prend en charge qu’IPv4 actuellement. | | **QoS / CoS** | Non pris en charge | Aucun mécanisme de qualité de service ou de classe de service 802.1p. | | **Tag VLAN 802.1q (mode L2)** | Pris en charge | Le mode L2 n’est toutefois disponible que sur OVHcloud Connect Direct. | | **Multi-VRF** | Non pris en charge | Une seule instance de routage par service OVHcloud Connect. | | **eBGP Multi-Hop** | Non pris en charge | Le peering BGP doit être directement connecté (single hop). | | **iBGP** | Non pris en charge | Seul l’eBGP est pris en charge. | | **Routage statique au PoP** | Non pris en charge | Tout le routage se fait via BGP. | | **Spanning Tree (L2)** | Non pris en charge | Le mode L2 ne transmet pas les BPDU. | | **Multicast / IGMP (L2)** | Non pris en charge | Seul le trafic unicast est pris en charge en mode L2. | | **FCoE (L2)** | Non pris en charge | Fibre Channel over Ethernet n’est pas pris en charge. | | **LACP (L2)** | Pris en charge | Peut être utilisé pour l’agrégation de liens en mode L2 au sein d’un même PoP. | Pour la liste complète des prérequis et limitations, consultez [Prérequis et limitations](/fr/guides/network/ovhcloud-connect/limits.md). *** ## Référence rapide : commandes de diagnostic ### Cisco IOS / IOS-XE | Objectif | Commande | | ------------------------ | --------------------------------------------------- | | État de l’interface | `show interfaces GigabitEthernet0/0` | | Résumé des interfaces | `show ip interface brief` | | Résumé de la session BGP | `show ip bgp summary` | | Détails du voisin BGP | `show bgp ipv4 unicast neighbors ` | | Routes reçues du pair | `show ip bgp neighbors received-routes` | | Routes annoncées au pair | `show ip bgp neighbors advertised-routes` | | Table de routage BGP | `show ip route bgp` | | Statistiques de flap BGP | `show ip bgp flap-statistics` | | Logs | `show log \| include BGP` | ### Juniper JunOS | Objectif | Commande | | ------------------------ | ----------------------------------------------- | | État de l’interface | `show interfaces ge-0/0/0 extensive` | | Résumé des interfaces | `show interfaces terse` | | Résumé de la session BGP | `show bgp summary` | | Détails du voisin BGP | `show bgp neighbor ` | | Routes reçues du pair | `show route receive-protocol bgp ` | | Routes annoncées au pair | `show route advertising-protocol bgp ` | | Table de routage BGP | `show route protocol bgp` | | Logs | `show log messages \| match BGP` | ### Hôte Linux | Objectif | Commande | | -------------------------------- | ---------------------------------- | | Test de connectivité | `ping -c 10 ` | | Trace de chemin | `traceroute ` | | Ping + trace combinés | `mtr -r -c 50 ` | | Test de MTU (sans fragmentation) | `ping -s 1472 -M do ` | | Test de débit | `iperf3 -c -t 30` | *** ## Quand contacter le support Si vous avez suivi les étapes de dépannage ci-dessus et que le problème persiste, ouvrez un ticket de support : 1. Depuis l'espace client OVHcloud, allez dans Support > Créer un ticket. 2. Sélectionnez Network > OVHcloud Connect. 3. Incluez : - Le **nom/ID de service** de votre OVHcloud Connect - L'**horodatage** du problème (UTC) - Les **symptômes** observés - Les **sorties de diagnostic** (résumé BGP, état des interfaces, traceroute, valeurs optiques) - Les **étapes déjà entreprises** pour le dépannage 4. Consultez [Déclarer et suivre un incident](/fr/guides/network/ovhcloud-connect/incident-followup.md) pour le processus complet de gestion des incidents. *** ## Et ensuite ? - Mettez en place un [monitoring](/fr/guides/network/ovhcloud-connect/monitor.md) proactif pour détecter les problèmes avant qu’ils n’impactent vos utilisateurs - Consultez [Prérequis et limitations](/fr/guides/network/ovhcloud-connect/limits.md) pour éviter les écueils connus - Consultez la [FAQ](/fr/guides/network/ovhcloud-connect/faq.md) pour les réponses aux questions courantes - Vérifiez les [SLA](/fr/guides/network/ovhcloud-connect/slas.md) pour les garanties de disponibilité et les avoirs de service ## 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/).