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.

Connectivité avec les appareils du réseau Outpost

Vérifiez l'état du BGP peering sur les appareils du réseau local du client connectés aux appareils du réseau Outpost. Si le statut de BGP peering est défini sur cette DOWN valeur, procédez comme suit :

1. Envoyez une commande ping à l’adresse IP du pair distant sur les appareils du réseau Outpost à partir des appareils du client. Vous trouverez l'adresse IP de l'homologue dans la BGP configuration 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 l'LACPétat 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 le ping est réussi, vérifiez les périphériques du réseau local du client et assurez-vous que les BGP configurations suivantes sont correctes.

   1. Vérifiez que le numéro de système autonome local (clientASN) est correctement configuré.

   2. Vérifiez que le numéro de système autonome distant (OutpostASN) 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 BGP session passe de l'état actif à l'état de connexion, vérifiez que le TCP port 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. BGPet journaux TCP de débogage

   2. BGPjournaux

   3. Capture de paquets

6. Si le problème persiste, effectuez des captures de paquetsMTR/traceroute/depuis votre routeur connecté à Outpost vers les adresses IP homologues du périphérique réseau Outpost. Partagez les résultats des tests avec le AWS support, en utilisant votre plan de support d'entreprise.

Si l'BGPétat d'appairage se situe UP entre les appareils du réseau local du client et les appareils du réseau Outpost, mais que le lien de service existe toujoursDOWN, vous pouvez résoudre le problème en vérifiant les appareils suivants sur les appareils du 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.

• Routeurs Edge connectés à AWS Direct Connect  : interface virtuelle publique utilisée pour la connectivité des liaisons de service. Pour de plus amples informations, veuillez consulter AWS Direct Connect connectivité de l'interface virtuelle publique à AWS la région.

• Routeurs Edge connectés à AWS Direct Connect  : interface virtuelle privée utilisée pour la connectivité des liaisons de service. Pour de plus amples informations, veuillez consulter AWS Direct Connect connectivité d'interface virtuelle privée à AWS la région.

• Routeurs Edge connectés à des fournisseurs de services Internet (ISPs) : Internet public utilisé pour la connectivité des liaisons de service. Pour de plus amples informations, veuillez consulter ISPconnexion Internet publique à AWS la région.

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 qui se connectent directement aux appareils du réseau Outpost reçoivent les plages d'adresses IP du lien de service. BGP

   1. Confirmez les itinéraires reçus BGP depuis votre appareil.

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

2. Pour garantir la connectivité de la région, consultez la table de routage pour le lien de serviceVRF. 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 serviceVRF, 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 c'est le cas du lien physiqueUP, vérifiez l'état de l'BGPappairage depuis le routeur Edge.

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

   4. S'il BGP est établi et que vous ne voyez pas l'itinéraire par défaut ou les plages d'adresses IP AWS publiques dans leVRF, contactez le AWS Support en utilisant votre plan de support d'entreprise.

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.

      • TCPprotocole — Port source : TCP 1025-65535, port de destination : 443.

      • UDPprotocole — 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 de plus amples informations, veuillez consulter 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é NAT le réseau local pour traduire les plages d'adresses IP des liens de service de l'Outpost en vos propres adresses IP publiques, vérifiez les points suivants.

   1. Vérifiez que le NAT périphérique n'est pas surchargé et qu'il dispose de ports libres à allouer aux nouvelles sessions.

   2. Vérifiez que l'NATappareil est correctement configuré pour effectuer la traduction des adresses.

6. Si le problème persiste, effectuez des captures de paquetsMTR/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'BGPappairage.

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

   3. L'interface virtuelle AWS Direct Connect privée est une connexion privée à votre routeur périphérique à l' AWS Direct Connect emplacement de votre choix, utilisée BGP pour échanger des itinéraires. Votre CIDR gamme de cloud privé virtuel privé (VPC) est annoncée via cette BGP session à votre routeur de périphérie. De même, la plage d'adresses IP pour le lien du service Outpost est annoncée à la région via votre BGP routeur périphérique.

   4. Vérifiez que le réseau ACLs associé au point de terminaison privé du lien de service de votre VPC ordinateur autorise le trafic concerné. Pour de plus amples informations, veuillez consulter Liste de contrôle de préparation du réseau.

   5. Si vous disposez d'un pare-feu sur site, assurez-vous qu'il comporte des règles de sortie qui autorisent les plages d'adresses IP des liens de service et les points de terminaison du service Outpost (les adresses IP des interfaces réseau) situés dans le ou le. VPC VPC CIDR Assurez-vous 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. Si le pare-feu n'est pas dynamique, assurez-vous qu'il dispose de règles et de politiques autorisant le trafic entrant vers l'Outpost depuis les points de terminaison du service Outpost situés dans le. VPC

2. Si votre réseau local compte plus de 100 réseaux, vous pouvez annoncer un itinéraire par défaut AWS sur votre interface virtuelle privée au cours de la BGP session. 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 paquetsMTR/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.

ISPconnexion Internet 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 via ou ISP lors de l'utilisation de l'Internet public pour la connectivité des liaisons de service.

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

• Vérifiez que les serveurs publics sont accessibles depuis vos appareils Edge connectés via unISP.

Si Internet ou les serveurs publics ne sont pas accessibles via les ISP liens, procédez comme suit.

1. Vérifiez si le statut BGP de peering avec les ISP routeurs est établi.

   1. Vérifiez que le BGP ne bat pas.

   2. Confirmez BGP que les itinéraires requis sont reçus et annoncés par leISP.

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 via une autre ISP connexion.

4. Si le problème persiste, effectuez des captures de paquetsMTR/traceroute/sur votre routeur Edge. Partagez les résultats avec votre équipe ISP de support technique pour un dépannage plus approfondi.

Si Internet et les serveurs publics sont accessibles via les ISP liens, procédez comme suit.

1. Vérifiez si l'une de vos EC2 instances ou équilibreurs de charge accessibles au public dans la région d'origine d'Outpost est accessible depuis votre appareil périphérique. 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 avez l'VRFshabitude de séparer le trafic sur votre réseau, vérifiez que le lien de service VRF comporte des itinéraires ou des politiques qui dirigent le trafic vers et depuis ISP (Internet) etVRF. Examinez les points de contrôle suivants.

   1. Routeurs Edge connectés au. ISP Vérifiez la table de ISP VRF routage du routeur Edge pour confirmer que la plage d'adresses IP du lien de service est présente.

   2. Appareils du réseau local du client connectés avec l’Outpost. Vérifiez les configurations du VRFs et assurez-vous que le routage et les politiques requis pour la connectivité entre le lien de service VRF et le ISP VRF sont correctement configurés. Généralement, un itinéraire par défaut est envoyé depuis le ISP VRF lien de service VRF pour le trafic vers 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. Assurez-vous qu'il NAT est configuré dans le réseau local pour traduire les plages d'adresses IP des liens de service de l'Outpost en adresses IP publiques. Vérifiez également les points suivants.

   1. L'NATappareil n'est pas surchargé et dispose de ports libres à allouer aux nouvelles sessions.

   2. L'NATappareil est correctement configuré pour effectuer la traduction des adresses.

Si le problème persiste, effectuez les captures de paquetsMTR/traceroute/.

• 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 indiquent que les paquets tombent ou sont bloqués sur le réseau ISP de l'utilisateur, contactez l'équipe ISP de support technique de ce dernier.

• Si les résultats ne montrent aucun problème, collectez les résultats de tous les tests (tels que telnetMTR, traceroute, captures de paquets et BGP journaux) 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 si des liaisons sont en panne ou si des modifications récentes apportées au routage (OSPFISIS//modifications des EIGRP métriques, modifications du BGP plan de route) sur votre réseau d'entreprise 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 de trafic pour voir s'il existe des liens vers votre ISP (vos) réseau (s) afin de détecter toute modification des modèles de trafic correspondant au début du problème lié au 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 BGP annonces passant par 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 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'UDPétat du flux pour les UDP connexions provenant du port 443 et destinées au port 443.