Dépannage de la session IX BGP désactivée

Si votre Internet Exchange (IX) est hors service, il y a probablement un problème avec votre session Border Gateway Protocol (BGP). Suivez ces étapes de dépannage pour confirmer si votre session BGP est la cause principale des problèmes de l’IX.

Conseil

Megaport exploite un MegaIX Looking Glass public et accessible via le web pour les pairs et les opérateurs de réseau afin d’enquêter sur l’état actuel du routage. Vous pouvez interroger à la fois les serveurs de route principaux et redondants pour obtenir des données BGP en direct ici: MegaIX Looking Glass.

Actions de dépannage

Action	Étapes
Vérifiez les erreurs d’interface ou de CRCContrôle de redondance cyclique. Un type de code de détection d’erreur utilisé pour détecter les erreurs de transmission dans les données. et les pertes de paquets sur le dispositif	Les statistiques et journaux d’interface peuvent aider à identifier quelle extrémité du cross connect est à l’origine de la panne et la solution potentielle. Par exemple, un nombre croissant d’erreurs entrantes sur une interface réseau écarte généralement ce SFPUn Small Form Pluggable (SFP) est un émetteur-récepteur enfichable à chaud utilisé dans les réseaux de communication de données et de télécommunication pour permettre la transmission de données entre deux dispositifs. spécifique et indique un problème potentiel avec d’autres composants de l’IX. Important à noter: Type d’interface, type de SFP et type de câble 1 Gbps 1000BASE-LX [10km; duplex sur SMOFUn câble à fibre optique avec une petite taille de cœur qui supporte un seul mode ou chemin de lumière à la fois. Le câble à fibre n’a qu’un seul mode de propagation: une seule longueur d’onde de lumière dans le cœur de la fibre. La fibre optique multimode (MMOF) est moins chère mais ne peut fonctionner que sur de courtes distances sans dégradation du signal. ] 10 Gbps 10GBASE-LR [10km; duplex sur SMOF] 100 Gbps 100GBASE-LR4 [10km; duplex sur SMOF] MTU (Taille maximale de trame Ethernet) 9100 octets pour VXCs entre Ports clients. MCR et MVE prennent en charge le MTU standard de 1500 octets. IX et de nombreux ports CSP ne prennent pas en charge les trames jumbo, mais tous supportent le MTU standard de 1500 octets. LAGDécrit diverses méthodes pour utiliser plusieurs connexions réseau parallèles afin d’augmenter le débit au-delà de la limite qu’un seul lien (une connexion) peut atteindre. En général, pour l’agrégation de liens, les Ports physiques doivent résider sur un seul commutateur/routeur. Protocole: LACP Interface: 10GBASE-LR (10 Gbps) ou 100GBASE-LR4 (100 Gbps). Les Ports 1 Gbps ne sont pas pris en charge. Nombre maximal d’interfaces dans un seul LAG: 8 La multi-Chassis Link Aggregation (MC-LAG) entre plusieurs dispositifs n’est pas pris en charge. VLAN A-End Préféré (VXC/IX) Sans étiquette (activé) – Cela limitera le Port A-End à un seul service. Un seul VXC/IX par Port, équivalent à un port d’accès sur le côté de votre dispositif. Sans étiquette (désactivé) – Spécifiez le numéro VLAN 802.1q sur le Port A-End. Chaque VXC est livré en tant que VLAN séparé sur le Port. Il doit s’agir d’un identifiant VLAN unique sur le Port et peut aller de 2 à 4093. Si vous spécifiez un identifiant VLAN déjà utilisé, le système affiche le numéro VLAN disponible suivant. Le système attribuera aléatoirement un numéro VLAN, équivalent à un trunk port avec des VLANs autorisés sur le côté de votre dispositif, en laissant l’identifiant VLAN vide. Tunneling 802.1Q (Q-in-QLe tunneling 802.1Q (également connu sous le nom de Q-in-Q ou 802.1ad) est une technique utilisée par les fournisseurs de niveau 2 OSI pour les clients. 802.1ad permet d’avoir à la fois une étiquette interne et une étiquette externe, l’étiquette externe (parfois appelée S-tag pour fournisseur de services) pouvant être retirée pour exposer les étiquettes internes (C-tag ou client) qui segmentent les données. ) IEEE 802.1ad (Azure VXC) Pour accéder à Microsoft Azure ExpressRoute, Q-in-Q (IEEE 802.1ad) est requis. Selon la méthode choisie, vos configurations de dispositif peuvent varier, soit Q-in-Q, Q-in-Q breakout, VXC sans étiquette ou MCR.
Vérifiez que l’interface, le SFP, le câble et le câblage sont corrects	Vérifiez que l’auto-négociation (vitesse auto et duplex auto) est utilisée sur les interfaces gigabit. Vérifiez que le câble cross connect est connecté au bon port aux deux extrémités. Vérifiez que les niveaux de puissance optique des SFP (Tx et Rx) affichent une bonne lumière aux deux extrémités.
Vérifiez les configurations de couche 2La couche 2 du modèle OSI est la couche de liaison de données. Celle-ci fournit le transfert de données de nœud à nœud (un lien entre deux nœuds directement connectés). La plupart des VXCs de Megaport opèrent à cette couche. La couche 2 est divisée en couche de contrôle d’accès au média (MAC) (contrôle la manière dont les dispositifs d’un réseau accèdent au support et ont la permission de transmettre) et en couche de contrôle de liaison logique (LLC) (responsable de l’identification des protocoles de la couche réseau, de leur encapsulation, et de la vérification des erreurs et de la synchronisation des trames).	Vérifiez que la taille du MTU est correcte. Vérifiez que la configuration LACP est correcte si LAG est utilisé. MC-LAG n’est pas pris en charge. Vérifiez que vos dispositifs sont configurés selon le “VLAN A-End Préféré” sur le Megaport Portal. Si un VLAN est utilisé, confirmez que le numéro VLAN correct est configuré sur le côté de votre dispositif. Si Azure VXC est utilisé, vérifiez que vos dispositifs sont configurés en utilisant l’une des méthodes Q-in-Q.
Vérifiez les configurations de couche 3La couche 3 du modèle OSI est la couche réseau. Elle traduit l’adresse réseau logique en adresse physique de la machine (adressage IP). Les routeurs de couche 3 analysent le trafic en fonction des détails d’adresse et le transfèrent de manière appropriée, nécessitant une connaissance des détails généralement échangés dans les sessions BGP pour les échanges de tables de routage.	Vérifiez que l’adresse IP de l’interface et l’adresse de sous-réseau sont configurées correctement. Vérifiez que les configurations des protocoles de routage (EIGRP/OSPF/BGP) sont configurées correctement. Exécutez un test ping entre les dispositifs de réseau de couche 3 (par exemple, routeurs Edge, pairs BGP). Exécutez un test ping entre l’hôte source et l’hôte de destination (test de connectivité de bout en bout). Si le test ping échoue, vérifiez la table ARPLe tableau de routage du protocole Address Resolution Protocol (ARP) contient une liste de correspondances d’adresses MAC (couche 2) à adresses IP (couche 3). et la table de routage aux deux extrémités. Si le test ping échoue et qu’il n’y a pas de problème sur la table de routage aux deux extrémités, prenez des journaux de tracerouteUn outil de diagnostic qui examine comment les données circulent sur Internet pour déterminer si une destination est accessible. des deux côtés.
Vérifiez les niveaux de puissance optique sur le dispositif	Les lectures de lumière optique depuis le terminal aident à comprendre si les lectures sont dans la plage de seuil. Vérifiez les graphiques de dispositif et de port pour les erreurs et consultez l’historique des graphiques optiques Megaport. Les graphiques se mettent à jour toutes les cinq minutes, donc si le phénomène de battement est rare, les graphiques pourraient ne pas capturer une baisse de lumière optique. Assurez-vous que la lecture optique est conforme aux spécifications.
Effectuez un test ping vers les serveurs de route au sein du réseau IX et/ou vers les pairs bilatéraux	Un test ping envoie des paquets de données à une adresse IP spécifique et confirme ou nie la connectivité entre les dispositifs IP en réseau. Une confirmation inclut la latence (le temps de réponse) de la connexion.
Vérifiez la connectivité de couche 2 (ARP) aux serveurs de route et/ou aux pairs bilatéraux	La couche 2 contrôle le flux de données entre les nœuds sur les segments WAN ou LAN, et est également responsable de la détection et éventuellement de la correction des erreurs de couche 1. Les problèmes de connectivité de couche 2 peuvent affecter la fonctionnalité de vos VXCs, qui se connectent à votre MCR. Lors de la connexion à un fournisseur de services cloud (CSP), assurez-vous que les détails de configuration du VLAN sont corrects. Soyez particulièrement prudent lorsque vous vous connectez à Azure, car vous utiliserez le Q-in-Q. Les problèmes de connectivité de couche 2 peuvent également affecter vos services IX. Les adresses MAC sont utilisées pour authentifier vos dispositifs lors de l’utilisation des services IX avec Megaport. Selon la conception de votre réseau, si vous êtes en peering avec Megaport ou d’autres organisations, assurez-vous d’avoir spécifié l’adresse MAC correcte dans le Megaport Portal. Effectuez ces vérifications avant de soumettre une demande de support: Vérifiez l’état de votre service IX avec l’outil Looking Glass. Vous pouvez accéder aux informations pour les deux serveurs de route principaux et redondants pour obtenir des données BGP en direct. Les problèmes de couche 2 peuvent être plus difficiles à diagnostiquer que les problèmes physiques de couche 1. Fournir à Megaport des détails de connectivité de couche 2 aidera à isoler le problème. Si vous n’êtes pas en peering directement avec Megaport, confirmez tout changement de configuration avec l’entreprise avec laquelle vous êtes en peering. Exécutez un test ping pour vérifier si vous êtes connecté à la couche 2. Vérifiez les tables ARP et confirmez que l’adresse MAC est visible dans le Megaport Portal. Confirmez que la configuration correspond aux Megaport spécifications techniques. Pour obtenir des conseils supplémentaires, contactez votre gestionnaire de compte et demandez une réunion avec un Architecte Solution Megaport.
Vérifiez la configuration BGP	Paramètres d’interface, y compris le numéro VLAN Adresse IP BGP et masque de sous-réseau Numéro BGP ASUn système autonome (AS) est un ensemble de préfixes de routage du protocole Internet (IP) connectés sous le contrôle d’un ou plusieurs opérateurs de réseaux au nom d’une entité ou d’un domaine administratif unique. ASN se réfère au numéro de système autonome et est un identifiant numérique unique attribué à chaque AS pour utilisation dans le routage BGP. Adresses réseau BGP à annoncer Adresse IP du voisin BGP et masque de sous-réseau Numéro AS du voisin BGP Adresses réseau du voisin BGP à recevoir Authentification BGP entre les pairs BGP Filtrage et manipulation de routes BGP, le cas échéant
Vérifiez les messages d’erreur BGP	Le protocole BGP envoie un message de notification lorsqu’il détecte une erreur avec la session BGP telle que l’expiration du minuteur de maintient, un changement des capacités du voisin, ou une demande de réinitialisation d’une session BGP. Lorsqu’une erreur est détectée, la session BGP est fermée. Par exemple, entrez show log %BGP-xxxxx. Pour plus d’informations, voir Aperçu de l’Internet Exchange.

Étapes suivantes

Si les actions de dépannage ne résolvent pas votre problème, contactez le support. Avant de demander de l’aide, recueillez les informations suivantes:

Résultats de dépannage

Fournissez toutes les étapes de dépannage que vous avez réalisées en détail. Par exemple, si des boucles ont été placées, notez leur emplacement et dans quelle direction elles étaient orientées.

Extraits de configurations de dispositifs réseau

Configurations d’interface
Routes statiques et configurations de protocoles de routage (EIGRP/OSPF/BGP)
Règles de pare-feu et configurations ACL pour le flux de données qui a le problème

Sortie de commande BGP et informations de capture de paquets

Table de routage (show IP route <ip-address>) aux deux extrémités.
État du protocole de routage et tables aux deux extrémités, par exemple, la table de voisins BGP qui montre l’état BGP (show ip bgp summary) et les détails des voisins BGP (show ip bgp neighbors <neighbor-ip-address>).
Entrées de table de routage BGP ayant des problèmes de routage BGP (sortie de la commande show IP BGP).
Routes annoncées par BGP (show IP BGP neighbors <neighbor-ip-address> advertised-routes).
Routes reçues par BGP (sortie de la commande show IP BGP neighbors <neighbor-ip-address> routes - Table de routage (show IP route <ip-address>)).
Journaux de Traceroute entre l’hôte source et de destination.
Journaux de capture de paquets, si possible (la taille du fichier peut aller jusqu’à 10 M).

Remarque

Pour plus d’informations sur le moment où un technicien de maintenance sur site est nécessaire au centre de données, voir Services sur site pour les clients.