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 l’interface ou les erreurs CRC et les pertes de paquets du périphérique Les statistiques et les journaux de l’interface peuvent aider à identifier 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 le SFP (small form factor pluggable) spécifique et indique un problème potentiel avec d’autres composants de l’IX.

Important à noter :

Type d’interface, de SFP et de câble
  • 1 Gbit/s 1000BASE-LX [10 km ; duplex sur fibre optique en mode simple (SMOF)]
  • 10 Gbits/s 10GBASE-LR [10 km ; duplex sur fibre optique en mode simple (SMOF)]
  • 100 Gbits/s 100GBASE-LR4 [10 km ; duplex sur fibre optique en mode simple (SMOF)]
MTU (taille de cadre Ethernet maximum)
  • 9 100 bits pour les VXC entre des ports de client.
  • Le MCR et le MVE prennent en charge la MTU standard de 1 500 bits.
  • Les ports IX et de nombreux autres CSP ne prennent pas en charge les cadres jumbo mais tous prennent en charge la MTU standard de 1 500 bits.
LAG (groupe d’agrégation de liens)
  • 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. Le système attribuera au hasard un numéro de VLAN, équivalent à un port avec les VLAN autorisés du côté de votre périphérique en laissant l’ID du VLAN vide.
tunneling 802.1Q (Q-in-Q) IEEE 802.1ad (Azure VXC)
  • Pour accéder à Microsoft Azure ExpressRoute, Q-in-Q (IEEE 802.1ad) est requis. 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 de la couche 2
  • Vérifiez que la taille 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 couche 3
  • 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 de protocole de routage (EIGRP/OSPF/BGP) sont correctes.
  • Exécutez le test ping entre les périphériques réseau de couche 3 (par exemple les routeurs Edge 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 ARP et 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 les journaux traceroute 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 BGP et masque de sous-réseau
  • Numéro AS 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 pairs BGP
  • Filtrage et manipulation des routes BGP, si applicable
    Cherchez des messages d’erreur BGP 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 de la 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)

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