AWS Outposts liste de contrôle pour le dépannage du réseau rack - AWS Outposts
Connectivité avec les appareils du réseau OutpostAWS Direct Connect connectivité de l'interface virtuelle publique à AWS la régionAWS Direct Connect connectivité d'interface virtuelle privée à AWS la régionConnectivité de l’Internet public du FSI à la région AWSOutposts se trouve derrière deux pare-feux

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

AWS Outposts liste de contrôle pour le dépannage du réseau rack

Utilisez cette liste de contrôle pour résoudre les problèmes liés à une liaison de service dont le statut est DOWN.

Réseaux locaux (LAN) virtuels.

Connectivité avec les appareils du réseau Outpost

Vérifiez le statut de l’appairage BGP sur les appareils du réseau local du client qui sont connectés aux appareils du réseau Outpost. Si le statut de l’appairage BGP est DOWN, suivez ces étapes :

  1. Envoyez une commande ping à l’adresse IP du pair distant sur les appareils du réseau Outpost à partir des appareils du client. Vous pouvez trouver l’adresse IP du pair dans la configuration BGP de votre appareil. Vous pouvez également vous reporter à la Liste de contrôle de préparation du réseau qui vous a été communiquée au moment de l’installation.

  2. En cas d’échec de la commande ping, contrôlez la connexion physique et vérifiez que le statut de connectivité est UP.

    1. Vérifiez le statut LACP des appareils du réseau local du client.

    2. Examinez le statut de l’interface sur l’appareil. Si le statut est UP, passez à l’étape 3.

    3. Sur les appareils du réseau local du client, vérifiez que le module optique fonctionne.

    4. Remplacez les fibres défectueuses et vérifiez que les voyants (Tx/Rx) se situent dans une plage acceptable.

  3. Si la commande ping aboutit, vérifiez sur les appareils du réseau local du client que les configurations BGP suivantes sont correctes.

    1. Vérifiez que le numéro ASN (Autonomous System Number) local (ASN du client) est correctement configuré.

    2. Vérifiez que le numéro ASN distant (ASN de l’Outpost) est correctement configuré.

    3. Vérifiez que l’adresse IP de l’interface et les adresses IP des pairs distants sont correctement configurées.

    4. Vérifiez que les routes annoncés et reçues sont correctes.

  4. Si votre session BGP alterne entre l’état actif et l’état de connexion, vérifiez que le port TCP 179 et les autres ports éphémères pertinents ne sont pas bloqués sur les appareils du réseau local du client.

  5. Si vous avez besoin d’un dépannage plus approfondi, vérifiez les points suivants sur les appareils du réseau local du client :

    1. Journaux de débogage BGP et TCP

    2. Journaux BGP

    3. Capture de paquets

  6. Si le problème persiste, effectuez des tests MTR, traceroute ou des captures de paquets entre le routeur connecté à l’Outpost et les adresses IP des appareils pairs du réseau Outpost. Partagez les résultats des tests avec le AWS support, en utilisant votre plan de support d'entreprise.

Si le statut de l’appairage BGP est UP entre les appareils du réseau local du client et les appareils du réseau Outpost, mais que la liaison de service est toujours DOWN, vous pouvez aller plus loin dans le dépannage en vérifiant les appareils suivants sur le réseau local de votre client. Utilisez l’une des listes de contrôle suivantes en fonction du provisionnement de la connectivité de la liaison de service.

AWS Direct Connect connectivité de l'interface virtuelle publique à AWS la région

Utilisez la liste de contrôle suivante pour résoudre les problèmes liés aux routeurs Edge connectés AWS Direct Connect lorsqu'une interface virtuelle publique est utilisée pour la connectivité des liaisons de service.

  1. Vérifiez que les appareils se connectant directement avec les appareils du réseau Outpost reçoivent bien les plages d’adresses IP de la liaison de service via BGP.

    1. Vérifiez les routes qui sont reçues via BGP en provenance de votre appareil.

    2. Vérifiez la table de routage de l’instance de routage et de transfert virtuels (VRF) de la liaison de service. Elle doit indiquer que la plage d’adresses IP est utilisée.

  2. Pour assurer la connectivité de la région, vérifiez l’instance VRF de la liaison de service dans la table de routage. Il doit inclure les plages d'adresses IP AWS publiques ou la route par défaut.

  3. Si vous ne recevez pas les plages d'adresses IP AWS publiques dans le VRF du lien de service, vérifiez les points suivants.

    1. Vérifiez l'état de la AWS Direct Connect liaison depuis le routeur Edge ou le AWS Management Console.

    2. Si la liaison physique est UP, vérifiez le statut de l’appairage BGP sur le routeur de périphérie.

    3. Si le statut d'appairage BGP est définiDOWN, envoyez un ping à l'adresse AWS IP de l'homologue et vérifiez la configuration BGP dans le routeur Edge. Pour plus d'informations, consultez la section Résolution des problèmes AWS Direct Connect dans le guide de AWS Direct Connect l'utilisateur et l'état BGP de mon interface virtuelle est en panne dans la AWS console. Que dois-je faire ?

    4. Si le BGP est établi et que vous ne voyez pas la route par défaut ou les plages d'adresses IP AWS publiques dans le VRF, contactez le AWS Support en utilisant votre plan de support Enterprise.

  4. Si vous disposez d’un pare-feu sur site, vérifiez les points suivants.

    1. Vérifiez que les ports nécessaires à la connectivité de la liaison de service sont autorisés sur les pare-feu du réseau. Utilisez traceroute sur le port 443 ou tout autre outil de résolution des problèmes réseau pour confirmer la connectivité via les pare-feu et les appareils de votre réseau. Les ports suivants doivent être configurés dans les politiques de pare-feu pour la connectivité de la liaison de service.

      • Protocole TCP – Port source : TCP 1025-65535, port de destination : 443.

      • Protocole UDP – Port source : TCP 1025-65535, port de destination : 443.

    2. Si le pare-feu est statique, assurez-vous que les règles de sortie autorisent la plage d'adresses IP du lien de service de l'Outpost vers les plages d'adresses IP AWS publiques. Pour plus d’informations, consultez AWS Outposts connectivité aux AWS régions.

    3. Si le pare-feu n'est pas dynamique, assurez-vous d'autoriser également le flux entrant (des plages d'adresses IP AWS publiques à la plage d'adresses IP du lien de service).

    4. Si vous avez configuré un routeur virtuel au niveau des pare-feu, vérifiez que le routage configuré pour le trafic entre l’Outpost et la région AWS est approprié.

  5. Si vous avez configuré le NAT sur le réseau sur site afin que les plages d’adresses IP de la liaison de service de l’Outpost soient traduites dans vos propres adresses IP publiques, vérifiez les points suivants.

    1. Vérifiez que le périphérique NAT n’est pas surchargé et qu’il a des ports libres à allouer pour de nouvelles sessions.

    2. Vérifiez que le périphérique NAT est correctement configuré pour assurer la traduction d’adresses.

  6. Si le problème persiste, effectuez des captures de paquets MTR/traceroute/depuis votre routeur Edge vers les adresses IP AWS Direct Connect homologues. Partagez les résultats des tests avec le AWS support, en utilisant votre plan de support d'entreprise.

AWS Direct Connect connectivité d'interface virtuelle privée à AWS la région

Utilisez la liste de contrôle suivante pour résoudre les problèmes liés aux routeurs Edge connectés AWS Direct Connect lorsqu'une interface virtuelle privée est utilisée pour la connectivité des liaisons de service.

  1. Si la connectivité entre le rack Outpost et la AWS région utilise la fonctionnalité de connectivité AWS Outposts privée, vérifiez les points suivants.

    1. Envoyez un ping à l'adresse AWS IP d'appairage à distance depuis le routeur Edge et confirmez l'état de l'appairage BGP.

    2. Assurez-vous que l'appairage BGP via l'interface virtuelle AWS Direct Connect privée entre votre VPC de point de terminaison de liaison de service et l'Outpost installé dans vos locaux l'est. UP Pour plus d'informations, consultez la section Résolution des problèmes AWS Direct Connect dans le guide de AWS Direct Connect l'utilisateur. L'état BGP de mon interface virtuelle est en panne dans la AWS console. Que dois-je faire ? et Comment dépanner les problèmes de connexion BGP sur Direct Connect ?

    3. L'interface virtuelle AWS Direct Connect privée est une connexion privée à votre routeur de périphérie à l' AWS Direct Connect endroit que vous avez choisi, et elle utilise le protocole BGP pour échanger des itinéraires. La plage CIDR de votre cloud privé virtuel (VPC) est annoncée à votre routeur de périphérie par l’intermédiaire de cette session BGP. De même, la plage d’adresses IP de la liaison de service Outpost est annoncée à la région via BGP à partir de votre routeur de périphérie.

    4. Vérifiez que les listes ACL réseau associées au point de terminaison privé de la liaison de service de votre VPC autorisent le trafic approprié. Pour plus d’informations, consultez Liste de contrôle de préparation du réseau.

    5. Si vous disposez d’un pare-feu sur site, vérifiez qu’il dispose de règles de trafic sortant qui autorisent les plages d’adresses IP de la liaison de service et les points de terminaison du service Outpost (adresses IP de l’interface réseau) situés dans le VPC ou le CIDR du VPC. Vérifiez que les ports TCP 1025-65535 et UDP 443 ne sont pas bloqués. Pour plus d'informations, voir Présentation de la connectivité AWS Outposts privée.

    6. S’il ne s’agit pas d’un pare-feu avec état, vérifiez qu’il dispose de règles et de politiques autorisant le trafic entrant dans l’Outpost en provenance des points de terminaison du service Outpost du VPC.

  2. Si votre réseau local compte plus de 100 réseaux, vous pouvez annoncer un itinéraire par défaut via la session BGP vers votre AWS interface virtuelle privée. Si vous ne souhaitez pas annoncer de route par défaut, résumez les routes de sorte que le nombre de routes annoncées soit inférieur à 100.

  3. Si le problème persiste, effectuez des captures de paquets MTR/traceroute/depuis votre routeur Edge vers les adresses IP AWS Direct Connect homologues. Partagez les résultats des tests avec le AWS support, en utilisant votre plan de support d'entreprise.

Connectivité de l’Internet public du FSI à la région AWS

Utilisez la liste de contrôle suivante pour résoudre les problèmes liés aux routeurs de périphérie connectés via un FSI lorsque l’Internet public est utilisé pour la connectivité de la liaison de service.

  • Vérifiez que la liaison Internet est opérationnelle.

  • Vérifiez que les serveurs publics sont accessibles à partir de vos appareils de périphérie connectés via un FSI.

Si Internet ou les serveurs publics ne sont pas accessibles via les liaisons du FSI, effectuez les étapes suivantes.

  1. Contrôlez si le statut de l’appairage BGP avec les routeurs du FSI est établi.

    1. Vérifiez que le protocole BGP n’est pas instable.

    2. Vérifiez que le protocole BGP reçoit et annonce les routes nécessaires à partir du FSI.

  2. Dans le cas d’une configuration de route statique, vérifiez que la route par défaut est correctement configurée sur l’appareil de périphérie.

  3. Vérifiez si vous pouvez accéder à Internet en utilisant la connexion d’un autre FSI.

  4. Si le problème persiste, effectuez des tests MTR, traceroute ou des captures de paquets sur votre routeur de périphérie. Partagez les résultats avec l’équipe de support technique de votre FSI pour un dépannage plus approfondi.

Si Internet et les serveurs publics sont accessibles via les liaisons du FSI, effectuez les étapes suivantes.

  1. Vérifiez si l’une de vos instances EC2 ou l’un de vos équilibreurs de charge accessibles publiquement dans la région d’origine de l’Outpost sont accessibles depuis votre appareil de périphérie. Vous pouvez utiliser une commande ping ou telnet pour vérifier la connectivité et utiliser ensuite traceroute pour vérifier le chemin réseau.

  2. Si vous utilisez des instances VRF pour séparer le trafic sur votre réseau, vérifiez que l’instance VRF de la liaison de service dispose de routes ou de politiques qui dirigent le trafic à destination et en provenance du FSI (Internet) et de l’instance VRF. Examinez les points de contrôle suivants.

    1. Routeurs de périphérie connectés avec le FSI. Examinez la table de routage VRF du FSI sur les routeurs de périphérie pour vérifier la présence de la plage d’adresses IP de la liaison de service.

    2. Appareils du réseau local du client connectés avec l’Outpost. Examinez la configuration des instances VRF et vérifiez que le routage et les politiques nécessaires à la connectivité entre l’instance VRF de la liaison de service et l’instance VRF du FSI sont correctement configurés. En règle générale, une route par défaut est envoyée de l’instance VRF du FSI vers l’instance VRF de la liaison de service pour le trafic à destination d’Internet.

    3. Si vous avez configuré un routage en fonction de la source sur les routeurs connectés à votre Outpost, vérifiez que la configuration est correcte.

  3. Assurez-vous que les pare-feux locaux sont configurés pour autoriser la connectivité sortante (ports TCP 1025-65535 et UDP 443) entre les plages d'adresses IP du lien du service Outpost et les plages d'adresses IP publiques. AWS S’il ne s’agit pas de pare-feu avec état, vérifiez que la connectivité entrante à destination de l’Outpost est également configurée.

  4. Vérifiez que le NAT est configuré sur le réseau sur site afin que les plages d’adresses IP de la liaison de service de l’Outpost soient traduites dans vos propres adresses IP publiques. Vérifiez également les points suivants.

    1. Le périphérique NAT n’est pas surchargé et a des ports libres à allouer pour de nouvelles sessions.

    2. Le périphérique NAT est correctement configuré pour assurer la traduction d’adresses.

Si le problème persiste, effectuez des tests MTR, traceroute ou des captures de paquets.

  • Si les résultats montrent que des paquets sont abandonnés ou bloqués dans le réseau sur site, contactez votre équipe réseau ou technique pour obtenir des conseils supplémentaires.

  • Si les résultats montrent que l’abandon ou le blocage des paquets se produisent dans le réseau du FSI, contactez l’équipe de support technique du FSI.

  • Si les résultats ne montrent aucun problème, collectez les résultats de tous les tests (tels que MTR, telnet, traceroute, captures de paquets et journaux BGP) et contactez le support via votre plan de AWS support d'entreprise.

Outposts se trouve derrière deux pare-feux

Si vous avez placé votre Outpost derrière une paire de pare-feux synchronisés à haute disponibilité ou deux pare-feux autonomes, un routage asymétrique du lien de service peut se produire. Cela signifie que le trafic entrant peut passer par le pare-feu-1, tandis que le trafic sortant passe par le pare-feu-2. Utilisez la liste de contrôle suivante pour identifier le routage asymétrique potentiel du lien de service, en particulier s'il fonctionnait correctement auparavant.

  • Vérifiez si des modifications récentes ou une maintenance continue ont été apportées à la configuration du routage du réseau de votre entreprise qui auraient pu entraîner un routage asymétrique de la liaison de service à travers les pare-feux.

    • Utilisez les graphiques du trafic du pare-feu pour vérifier les modifications des modèles de trafic correspondant au début du problème de liaison de service.

    • Vérifiez s'il s'agit d'une défaillance partielle du pare-feu ou d'un scénario de paire de pare-feux à cerveau divisé qui aurait pu empêcher vos pare-feux de synchroniser leurs tables de connexion entre eux.

    • Vérifiez s'il existe des liaisons en panne ou des modifications récentes apportées au routage (modifications des métriques OSPF/ISIS/EIGRP, modifications de la feuille de route BGP) dans votre réseau d'entreprise qui correspondent au début du problème de liaison de service.

  • Si vous utilisez une connexion Internet publique pour le lien de service vers la région d'origine, la maintenance d'un fournisseur de services peut avoir entraîné un routage asymétrique du lien de service à travers les pare-feux.

    • Consultez les graphiques du trafic pour voir s'il existe des liens vers votre ou vos fournisseurs de services Internet afin de détecter les modifications des modèles de trafic correspondant au début du problème de lien de service.

  • Si vous utilisez la AWS Direct Connect connectivité pour le lien de service, il est possible qu'une maintenance AWS planifiée ait déclenché un routage asymétrique du lien de service.

    • Vérifiez les notifications de maintenance planifiée sur vos AWS Direct Connect services.

    • Notez que si vous disposez de AWS Direct Connect services redondants, vous pouvez tester de manière proactive le routage du lien de service Outposts sur chaque chemin réseau probable dans des conditions de maintenance. Cela vous permet de tester si une interruption de l'un de vos AWS Direct Connect services peut entraîner un routage asymétrique du lien de service. La résilience de la AWS Direct Connect partie de la connectivité end-to-end réseau peut être testée par le kit d'outils AWS Direct Connect Resiliency with Resiliency. Pour plus d'informations, voir Tester AWS Direct Connect la résilience avec le Resiliency Toolkit — Failover Testing.

Après avoir passé en revue la liste de contrôle précédente et identifié le routage asymétrique du lien de service comme cause possible, vous pouvez prendre un certain nombre d'autres mesures :

  • Restaurez le routage symétrique en annulant toute modification apportée au réseau de l'entreprise ou en attendant la fin de la maintenance planifiée par le fournisseur.

  • Connectez-vous à un pare-feu ou aux deux et effacez toutes les informations relatives à l'état des flux depuis la ligne de commande (si le fournisseur du pare-feu les prend en charge).

  • Filtrez temporairement les annonces BGP via l'un des pare-feu ou fermez les interfaces d'un pare-feu afin de forcer le routage symétrique à travers l'autre pare-feu.

  • Redémarrez chaque pare-feu à tour de rôle pour éliminer toute corruption potentielle dans le suivi de l'état du flux du trafic des liaisons de service dans la mémoire du pare-feu.

  • Contactez votre fournisseur de pare-feu pour vérifier ou assouplir le suivi de l'état du flux UDP pour les connexions UDP provenant du port 443 et destinées au port 443.