View a markdown version of this page

Liste de contrôle pour le dépannage du réseau rack Outposts - AWS Outposts
Connectivité avec les appareils du réseau OutpostDirect Connect connectivité de l'interface virtuelle publique à AWS RégionDirect Connect connectivité d'interface virtuelle privée à AWS RégionConnectivité Internet publique du FAI à AWS RégionOutposts se trouve derrière deux dispositifs de pare-feu

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.

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

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 assurez-vous 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 AWS Support, en utilisant votre plan de support Enterprise.

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.

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

Utilisez la liste de contrôle suivante pour dépanner les routeurs Edge connectés Direct Connect lorsqu'une interface virtuelle publique est utilisée pour la connectivité par liaison 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 lien de service VRF, vérifiez les points suivants.

    1. Vérifiez l'état de la Direct Connect liaison à partir du routeur Edge ou du Console de gestion AWS.

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

    3. Si l'état du peering BGP est définiDOWN, envoyez une requête ping à l'adresse AWS IP de l'homologue et vérifiez la configuration BGP sur le routeur Edge. Pour plus d'informations, consultez la section Résolution des problèmes Direct Connect dans le Guide de 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 l'itinéraire par défaut ou les plages d'adresses IP AWS publiques ne s'affichent pas 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 doté d'un état, assurez-vous que les règles sortantes autorisent la plage d'adresses IP de liaison de service de l'Outpost aux plages d'adresses IP AWS publiques. Pour de plus amples informations, veuillez consulter AWS Outposts connectivité à AWS Régions.

    3. Si le pare-feu n'est pas doté d'un état, assurez-vous d'autoriser également le flux entrant (des plages d'adresses IP AWS publiques à la plage d'adresses IP de la liaison 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 MTR/traceroute/paquets depuis votre routeur Edge vers les adresses IP Direct Connect homologues. Partagez les résultats des tests avec AWS Support, en utilisant votre plan de support Enterprise.

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

Utilisez la liste de contrôle suivante pour dépanner les routeurs Edge connectés Direct Connect lorsqu'une interface virtuelle privée est utilisée pour la connectivité par liaison de service.

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

    1. Envoyez une requête ping à l'adresse AWS IP d'appairage à distance depuis le routeur Edge et confirmez l'état du peering BGP.

    2. Assurez-vous que le peering BGP via l'interface virtuelle Direct Connect privée entre votre VPC de point de terminaison de liaison de service et l'Outpost installé dans vos locaux est correct. UP Pour plus d'informations, consultez la section Résolution des problèmes Direct Connect dans le Guide de 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 Direct Connect privée est une connexion privée à votre routeur Edge à l' Direct Connect emplacement que vous avez choisi, et elle utilise le 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, consultez la section 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 publier un itinéraire par défaut sur la session BGP AWS sur votre 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 MTR/traceroute/paquets depuis votre routeur Edge vers les adresses IP Direct Connect homologues. Partagez les résultats des tests avec AWS Support, en utilisant votre plan de support Enterprise.

Connectivité Internet publique du FAI à AWS Région

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) depuis les plages d'adresses IP de la liaison de service Outpost vers 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 révèlent 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 AWS support en utilisant votre plan de support Enterprise.

Outposts se trouve derrière deux dispositifs de pare-feu

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 de la liaison de service peut se produire. Cela signifie que le trafic entrant peut passer par le firewall-1, tandis que le trafic sortant passe par le firewall-2. Utilisez la liste de contrôle suivante pour identifier le routage asymétrique potentiel de la liaison de service, en particulier si elle fonctionnait correctement auparavant.

  • Vérifiez si des modifications récentes ou des opérations de maintenance en cours ont été apportées à la configuration de routage de votre réseau d'entreprise qui auraient pu entraîner un routage asymétrique de la liaison de service via les pare-feux.

    • Utilisez les graphiques de trafic du pare-feu pour vérifier les modifications apportées aux modèles de trafic qui correspondent 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 partagé qui aurait pu empêcher vos pare-feux de synchroniser leurs tables de connexion entre eux.

    • Vérifiez les liens indisponibles ou les modifications récentes apportées au routage (modifications des OSPF/ISIS/EIGRP métriques, modifications de la feuille de route BGP) sur votre réseau d'entreprise qui correspondent au début du problème de liaison de service.

  • Si vous utilisez une connectivité Internet publique pour la liaison de service vers la région d'origine, la maintenance d'un fournisseur de services aurait pu entraîner un routage asymétrique de la liaison de service via les pare-feux.

    • Consultez les graphiques de trafic pour les liens vers votre ou vos FAI pour connaître les modifications apportées aux modèles de trafic correspondant au début du problème de liaison de service.

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

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

    • Notez que si vous disposez de Direct Connect services redondants, vous pouvez tester de manière proactive le routage de la liaison 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 Direct Connect services peut entraîner un routage asymétrique de la liaison de service. La résilience de la Direct Connect partie de la connectivité réseau de bout en bout peut être testée à l'aide de la boîte à outils Direct Connect Resiliency with Resiliency. Pour plus d'informations, voir Testing Direct Connect Resiliency with Resiliency Toolkit — Failover Testing.

Après avoir parcouru la liste de contrôle précédente et identifié le routage asymétrique de la liaison de service comme cause première possible, vous pouvez prendre un certain nombre d'autres mesures :

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

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

  • Filtrez temporairement les annonces BGP via l'un des pare-feux 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 des 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.