Aller au contenu

Dépannage d’une session BGP IX en panne

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

Conseil

Megaport exploite un MegaIX Looking Glass public, accessible sur le web, qui permet aux pairs et aux opérateurs de réseau d’examiner l’état actuel du routage. Vous pouvez interroger les serveurs de routage primaires 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 CRCCyclic Redundancy Check (Contrôle de redondance cyclique).
Un type de code de détection d’erreur utilisé pour identifier les erreurs de transmission dans les données.
et les pertes de paquets sur le périphérique
Les statistiques et les journaux de l’interface peuvent faciliter l’identification de l’extrémité de la connexion transversale à l’origine du problème et la solution potentielle. Par exemple, un nombre croissant d’erreurs entrantes sur une interface réseau exclut généralement ce SFPSmall Form Pluggable (Appareil enfichable compact).
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 périphériques.
spécifique et indique un problème potentiel avec d’autres composants de l’IX.

Remarque importante :

Type d’interface, de SFP et de câble
  • 1 Gbit/s 1000BASE-LX [10 km ; duplex sur SMOFSingle-Mode Optical Fiber (Fibre optique monomode).
    Une fibre optique avec un cœur compact prenant en charge un seul mode ou chemin de lumière en permanence.
    ]
  • 10 Gbits/s 10GBASE-LR [10 km ; duplex sur SMOF]
  • 100 Gbits/s 100GBASE-LR4 [10 km ; duplex sur SMOF]
MTU (Maximum Ethernet Frame Size, Taille de trame Ethernet maximale)
  • 9 100 octets pour les VXC entre des ports clients.
  • Le MCR et le MVE prennent en charge une MTU standard de 1 500 octets.
  • Les ports IX et de nombreux ports CSP ne prennent pas en charge les trames géantes, mais tous prennent en charge la MTU standard de 1 500 octets.
LAGLink Aggregation Group (Groupe d’agrégation de liens).
Utilise plusieurs connexions réseau parallèles pour augmenter le débit au-delà de la limite d’une liaison unique (une connexion).
  • Protocole : LACP
  • Interface : 10GBASE-LR (10 Gbits/s) ou 100GBASE-LR4 (100 Gbits/s). Les ports de 1 Gbit/s ne sont pas pris en charge.
  • Le nombre maximal d’interfaces dans un LAG unique : 8
  • L’agrégation de liens multi-châssis (MC-LAG) sur plusieurs appareils n’est pas prise en charge.
Preferred A-End VLAN (VXC/IX) (VLAN préféré de l’A-End (VXC/IX))
  • Untag (enabled) (Annuler le balisage (Activé)) – Ceci limitera le port de l’A-End à un seul service. Une seule connexion VXC/IX par port, équivalant à un port d’accès du côté de votre périphérique.
  • Untag (disabled) (Annuler le balisage (Désactivé)) – Spécifiez le numéro VLAN 802.1q sur le port de l’A-End. Chaque VXC est livrée comme un VLAN séparé sur le port. Il doit s’agir d’un ID VLAN unique sur ce port, qui peut être compris entre 2 et 4093. Si vous indiquez un ID VLAN déjà utilisé, le système affiche le prochain numéro VLAN disponible. Si vous laissez l’ID de VLAN vide, le système attribue de manière aléatoire un numéro de VLAN, équivalent à un port de jonction avec les VLAN autorisés du côté de votre périphérique.
Tunnelage 802.1Q (Le tunnelage Q-in-Q802.1Q (également connu sous le nom de Q-in-Q ou 802.1ad) est une technique utilisée par les fournisseurs de couche 2 OSI pour les clients. 802.1ad fournit à la fois une balise interne et une balise externe, la balise externe (S-tag) pouvant être retirée afin d’exposer les balises internes (C-tag) qui segmentent les données) IEEE 802.1ad (VXC Azure)
  • Pour accéder à Microsoft Azure ExpressRoute, le Q-in-Q (IEEE 802.1ad) est nécessaire. En fonction de la méthode choisie, votre configuration de périphérique peut varier et être soit Q-in-Q, rupture Q-in-Q, une VXC ou un MCR sans balise.
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 gigabits.
  • Vérifiez que le câble de connexion transversale est connecté au port correct aux deux extrémités.
  • Vérifiez que les niveaux de puissance optique (Tx et Rx) SFP affichent une lumière adéquate aux deux extrémités.
Vérifiez les configurations decouche 2La couche de liaison de données du modèle OSI. La couche L2 permet le transfert de données de nœud à nœud (un lien entre deux nœuds directement connectés). La plupart des connexions transversales virtuelles (VXC) Megaport fonctionnent sur la couche L2..
  • Vérifiez que la taille de la MTU est correcte.
  • Vérifiez que la configuration LACP est correcte si le LAG est utilisé. MC-LAG n’est pas pris en charge.
  • Vérifiez que vos périphériques sont configurés conformément au « VLAN de l’A-End préféré » sur le Portail Megaport.
  • Si le VLAN est utilisé, confirmez si le bon numéro VLAN est configuré du côté de votre périphérique.
  • Si la VXC Azure est utilisée, vérifiez que vos périphériques sont configurés en utilisant l’une des méthodes Q-in-Q.
Vérifiez les configurations de la couche 3La couche réseau du modèle OSI. La couche L3 traduit l’adresse réseau logique en adresse machine physique (adressage IP).
  • Vérifiez que l’adresse IP de l’interface et l’adresse de sous-réseau sont configurées correctement.
  • Vérifiez que les protocoles de routage (EIGRP/OSPF/BGP) sont configurés correctement.
  • Exécutez le test ping entre les périphériques réseau de couche 3 (par exemple les routeurs de périphérie et les 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 ARPAddress Resolution Protocol (Protocole de résolution d’adresses).
    Une table de routage ARP contient une liste de mappages d’adresses MAC (couche 2) vers des 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 dans la table de routage aux deux extrémités, récupérez les journaux tracerouteUn outil de diagnostic qui examine comment les données se déplacent via lnternet pour déterminer si la destination est atteignable. depuis les deux extrémités.

Vérifiez les niveaux de puissance optique sur le périphérique Les lectures de lumière optique du terminal aident à comprendre si les lectures sont comprises dans la plage de seuil. Vérifiez les graphiques de port et de périphérique à la recherche d’erreurs et consultez l’historique des graphiques optiques Megaport. Les graphiques se mettent à jour toutes les cinq minutes, le vacillement est donc rare, les graphiques sont susceptibles de ne pas capturer une perte de lumière optique. Assurez-vous que les lectures optiques respectent les spécifications.
Effectuez un test ping pour les serveurs de routage au sein du réseau IX et/ou les pairs bilatéraux Un test ping transmet des paquets de données à une adresse IP spécifique et confirme ou infirme la connectivité entre des périphériques en réseau IP. Une confirmation inclut la latence (le temps de réponse) de la connexion.

Vérifiez la connectivité de couche 2 (ARP) vers les serveurs de routage et/ou les 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 de la correction possible des erreurs de la couche 1. Les problèmes de connectivité de la couche 2 peuvent affecter la fonctionnalité de vos VXC connectées à votre MCR. Lors de la connexion à un fournisseur de services cloud (CSP), assurez-vous que les détails de la configuration VLAN sont corrects. Faites preuve de prudence lorsque vous vous connectez à Azure, car vous utiliserez 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 périphériques lors de l’utilisation des services IX avec Megaport. En fonction de la conception de votre réseau, si vous faites le peering avec Megaport ou d’autres organisations, assurez-vous que vous avez indiqué la bonne adresse MAC dans le Portail Megaport.
    Effectuez ces vérifications avant de faire une demande d’assistance :

  1. Vérifiez le statut de votre service IX avec l’outil Looking Glass. Vous pouvez accéder aux informations pour les serveurs de routage primaires et redondants pour obtenir des données BGP en direct. Les problèmes de la couche 2 peuvent être plus délicats à diagnostiquer que les problèmes physiques de la couche 1. Fournir à Megaport les détails sur la connectivité de couche 2 aidera à isoler le problème.
  2. Si vous ne faites pas directement le peering avec Megaport, confirmez tout changement de configuration avec une entreprise avec laquelle vous faites le peering.
  3. Exécutez un test ping pour vérifier si vous êtes connecté à la couche 2.
  4. Vérifiez les tables ARP et confirmez que l’adresse MAC est visible sur le Portail Megaport.
  5. Confirmez que la configuration respecte les Spécifications techniques Megaport.

    Pour obtenir plus d’aide, contactez votre gestionnaire de compte et demandez à rencontrer un architecte de solutions Megaport.
Vérifiez la configuration BGP
  • Paramètres de l’interface, y compris le numéro de VLAN
  • Adresse IP et masque de sous-réseau du BGP
  • ASNAutonomous System Number (Numéro de système autonome)
    Un réseau ou groupe de réseaux très étendu avec une seule politique de routage.
    du BGP
  • Adresses réseau BGP à annoncer
  • Adresse IP et masque de sous-réseau du voisin BGP
  • ASN du voisin BGP
  • Adresses réseau du voisin BGP à recevoir
  • Authentification BGP entre les pairs BGP
  • Filtrage et manipulation des routes BGP, si applicable
    Check for BGP error messages (Rechercher les messages d’erreur BPG) Le protocole BGP envoie un message de notification lorsqu’il détecte une erreur dans la session BGP, par exemple : une expiration du minuteur de maintien, une modification des capacités des voisins 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 de détails, voir Aperçu des échanges Internet.

    Prochaines étapes

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

    Résultats du dépannage

    • Indiquez en détail toutes les étapes de dépannage suivies. Par exemple, si des boucles ont été placées, notez leur emplacement et la direction dans laquelle elles sont orientées.

    Extraits des configurations de périphérique réseau

    • Configurations de l’interface
    • Routes statiques et les configurations de protocole de routage (EIGRP/OSPF/BGP).
    • Règles de pare-feu et les configurations ACL pour le flux de données qui pose 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.
    • Statut du protocole de routage et les tables aux deux extrémités, par exemple la table du voisin BGP qui affiche l’état BGP (show ip bgp summary) et les détails du voisin BGP (show ip bgp neighbors <neighbor-ip-address>).
    • Entrées de la table de routage BGP qui présentent des problèmes de routage BGP (sortie de la commande show IP BGP)
    • Routes BGP annoncées (show IP BGP neighbors <neighbor-ip-address> advertised-routes)
    • Routes BGP reçues (sortie de la commande show IP BGP neighbors <neighbor-ip-address> routes)- Table de routage (show IP route <ip-address>).
    • Journaux Traceroute entre l’hôte source et l’hôte de destination
    • Journaux de capture de paquets, si possible (la taille du fichier peut atteindre 10 M)

    Remarque

    Si un technicien de service sur site est requis dans le centre de données, consultez la rubrique Services client sur site pour plus de détails.


    Dernière mise à jour: 2022-10-13