Comment résoudre les problèmes de couche 3 dans Direct Connect ?
Je souhaite dépanner ma connexion AWS Direct Connect lorsqu'elle tombe en panne en raison de problèmes de couche 3.
Résolution
Remarque : pour les problèmes de couche 1, consultez la section Comment résoudre les problèmes de couche 1 dans Direct Connect ? Pour les problèmes de couche 2, consultez la section Comment résoudre les problèmes de couche 2 dans Direct Connect ?
Vérifier les activités de maintenance dans le tableau de bord AWS Health
Les connexions Direct Connect peuvent s’INTERROMPRE en raison de la maintenance continue d'AWS, qui peut durer de quelques minutes à quelques heures. Pendant la maintenance, les connexions du protocole de passerelle frontière (BGP) passent à l'état inactif.
Consultez la section Événements du tableau de bord AWS Health pour connaître les opérations de maintenance AWS en cours ou récemment terminées susceptibles d'affecter votre connexion Direct Connect.
Configurez des notifications pour les métriques critiques afin de recevoir des alertes immédiates.
Vérifier la configuration du BGP
Si l'état de votre interface virtuelle est disponible mais que vous ne parvenez pas à établir de connexion BGP, procédez comme suit :
- Vérifiez l’existence de problèmes de configuration avec le numéro de système autonome (ASN) du BGP local et l'ASN AWS.
- Vérifiez l’existence de problèmes de configuration avec les adresses IP homologues des deux côtés de la session d'appairage du BGP.
- Configurez votre clé d'authentification MD5 afin qu'elle corresponde à la clé du fichier de configuration du routeur téléchargé. Assurez-vous que la clé ne contient pas d'espaces ni de caractères supplémentaires.
- Ne publiez pas plus de 100 préfixes pour les interfaces virtuelles privées ou 1 000 préfixes pour les interfaces virtuelles publiques.<br id=hardline_break/> Remarque : vous ne pouvez pas modifier ni dépasser ces quotas.
- Désactivez les règles de pare-feu ou de liste de contrôle d'accès au réseau (ACL réseau) qui bloquent le port TCP 179 ou les ports TCP éphémères à numéro élevé.<br id=hardline_break/> Remarque : ces ports sont nécessaires pour que le BGP établisse une connexion TCP entre les homologues.
- Vérifiez que vos journaux BGP ne contiennent pas d'erreurs ou de messages d'avertissement.
Si les étapes précédentes ne permettent pas de résoudre les problèmes de BGP, procédez comme suit :
- Vérifiez que vous avez correctement configuré le BGP sur votre passerelle.
- Effectuez un test ping entre les adresses IP homologues du BGP.
- Collectez les captures de paquets pour le trafic entre les adresses IP homologues du BGP depuis votre périphérique de passerelle.
Résoudre les problèmes liés aux états du BGP
Si vous avez correctement configuré le BGP et que vous rencontrez toujours des problèmes de couche 3, résolvez les états du BGP.
Remarque : l’état Inactif est le premier état dans lequel le BGP attend un événement de démarrage. L'événement de démarrage se produit lorsque vous configurez un nouveau voisin BGP ou réinitialisez un appairage de BGP établi. Le BGP initialise certaines ressources, réinitialise un temporisateur ConnectRetry, puis initie une connexion TCP avec le voisin BGP distant.
État de connexion
Durant l’état de connexion, le BGP attend la fin de l'établissement de la liaison tridirectionnelle du TCP. Si l’établissement d’une liaison est réussi, la connexion passe à l'état OpenSent.
Exemple de connexion réussie :
2021-07-04 22:50:20 169.254.60.146 169.254.60.145 TCP 74 34516 → 179 [SYN] Seq=0 Win=2920 Len=0 MSS=1460 SACK_PERM TSval=3030456 TSecr=0 WS=1 2021-07-04 22:50:20.719228 169.254.60.145 169.254.60.146 TCP 74 179 → 34516 [SYN, ACK] Seq=0 Ack=1 Win=26844 Len=0 MSS=1375 TSval=64921081 TSecr=3030456 WS=128 2021-07-04 22:50:20.719453 169.254.60.146 169.254.60.145 TCP 66 34516 → 179 [ACK] Seq=1 Ack=1 Win=2920 Len=0 TSval=3030476 TSecr=64921081
Si la connexion ou ConnectRetry échoue, la connexion demeure à l'état Actif et ne passe pas à l'état OpenSent.
Pour résoudre les problèmes liés à l'état de connexion, procédez comme suit :
- Pour vérifier qu'il existe une connectivité TCP entre les deux voisins BGP, exécutez un test telnet sur le port TCP 179. S'il n'y a pas de connectivité TCP, recherchez dans les journaux d’éventuels erreurs ou paquets abandonnés pendant la connexion TCP.
- Vérifiez que vous avez correctement configuré l'adresse IP du voisin BGP sur le BGP, votre passerelle et AWS.
- Vérifiez que vous avez saisi l'authentification BGP appropriée sur les routeurs.
État OpenSent
Une fois que BGP a envoyé un message OPEN à l'homologue, BGP attend la réponse OPEN à l’état OpenSent. Si le BGP reçoit une réponse avec succès, l'état du BGP passe à OpenConfirm et envoie un message keepalive au pair. Lorsqu'une connexion échoue, le BGP revient à l'état Inactif ou Actif.
Si le BGP n'établit pas de connexion, recherchez dans vos journaux un message OPEN envoyé et reçu par le voisin BGP qui inclut des paramètres BGP.
Exemple de message OPEN :
Border Gateway Protocol - OPEN MessageType: OPEN Message (1) Version: 4 My AS: 65000 Hold Time: 30 BGP Identifier: 54.241.242.80
Consultez également les journaux OpenSent pour identifier la cause de l'échec.
Remarque : AWS n'accepte pas la valeur 0 comme valeur de Temps d'attente.
État OpenConfirm
Le BGP attend dans l'état OpenConfirm un message keepalive de l'homologue. Si le BGP reçoit correctement un message, l'état passe à l’état Établi. Dans le cas contraire, l'état revient à l'état Inactif ou Actif.
Dans vos journaux, vérifiez que l’homologue a envoyé le message keepalive et que le BGP l'a bien reçu.
Exemples de messages keepalive entre les homologues du BGP :
65 2021-07-04 22:50:20.744297 169.254.60.146 169.254.60.145 BGP 85 KEEPALIVE Message 66 2021-07-04 22:50:20.765323 169.254.60.145 169.254.60.146 BGP 85 KEEPALIVE Message
État Établi
À l'état Établi, le BGP échange des informations entre les homologues.
Exemple de message de mise à jour du BGP :
Border Gateway Protocol - UPDATE Message Path attributes Path Attribute - AS_PATH: 65000 Path Attribute - NEXT_HOP: 169.254.60.146 Network Layer Reachability Information (NLRI) 192.168.0.0/16
Si le BGP n'établit pas de connexion, procédez comme suit :
- Consultez les journaux pour vous assurer que les routeurs échangent correctement les mises à jour. Vérifiez que les préfixes annoncés correspondent aux routes attendues.
- Assurez-vous que les filtres BGP ou les listes de préfixes n'empêchent pas la propagation des routes dans la table de routage.
- Vérifiez que les entrées de routage annoncées sur les tables de routage homologues sont correctes.
- Vos journaux BGP ou vos appareils sur site peuvent indiquer que la session d'appairage du BGP est passée de l'état Établi à l’état Inactif sur l'interface virtuelle Direct Connect de votre passerelle virtuelle. Dans ce cas, assurez-vous que l’homologue annonce moins de 100 routes au cours de la session d’appairage du BGP.
Résoudre les problèmes liés à la BFD
AWS active automatiquement la détection de transfert bidirectionnel (BFD) asynchrone pour les interfaces virtuelles Direct Connect sur AWS.
Pour résoudre ces problèmes, procédez comme suit :
- Si vous avez activé la BFD sur votre routeur, vérifiez que vous l'avez correctement configurée.
- Assurez-vous que la session d’appairage de la BFD est à l’état UP sur votre routeur.
- Consultez les événements ou journaux BFD de votre routeur.
Remarque : l'intervalle minimum de détection d’activité BFD par défaut pour AWS est de 300 millisecondes (ms). Le multiplicateur de détection d’activité BFD par défaut est de 3.
Pour éviter les problèmes de basculement ou de connexion, il est recommandé de ne pas configurer le redémarrage progressif et la BFD en même temps. Pour un basculement rapide, configurez la BFD avec le redémarrage progressif désactivé.
Informations connexes
- Balises
- AWS Direct Connect
- Langue
- Français

Contenus pertinents
- demandé il y a 2 ans
- demandé il y a 2 ans
- demandé il y a 2 ans
AWS OFFICIELA mis à jour il y a 5 mois
AWS OFFICIELA mis à jour il y a 5 mois
AWS OFFICIELA mis à jour il y a 3 ans