Dépannage des pertes de paquets avec les techniques de coloration des paquets ou les compteurs de plate-forme

Options de téléchargement

  • PDF     (1.4 MB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (1.2 MB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (950.5 KB)
    Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Mis à jour:8 avril 2025
ID du document:222938

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

    Introduction

    Ce document décrit comment suivre un flux réseau à l'aide de techniques de coloration des paquets.

    Conditions préalables

    Exigences

    • Connaissances de base de l'ACI
    • Groupes de terminaux et contrat
    • Connaissances de base de Wireshark

    Composants utilisés

    Ce document n'est pas limité à des versions matérielles et logicielles spécifiques.

    Périphériques utilisés :

    • Cisco ACI version 5.3(2)
    • Couvrir la destination
    • Commutateurs Gen2

    The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.


    Informations générales

    Comment créer des filtres dans Wireshark.

    Ouvrez la capture. À l'aide d'une trame dans le paquet de commutateur distant encapsulé, sélectionnez la ligne SpanID et cliquez avec le bouton droit de la souris.

    Sélectionnez Appliquer comme filtre > Sélectionné comme le montre l'image :

    Select Apply as Filter

    Topologie

    Topology

    Option 1. Configuration d'ERSPAN avec Flow-id

    Si un serveur de destination est capable de gérer tout le trafic, l'en-tête ERSPAN inclut une option permettant de définir un ID de flux. Cet ID de flux peut être configuré pour identifier le trafic entrant vers le fabric, tandis qu'un autre ID de flux peut être configuré pour le trafic sortant.

    Étape 1. Configuration de la destination ESPAN

    L’ID de flux d’un groupe de destinations sera égal à 1

    Sous Fabric > Access Policies > Policies > Troubleshooting > SPAN > SPAN Destination Groups

    Create SPAN Destination Group Flow-ID of 1

    Sur le deuxième groupe de destinations, configurez l'ID de flux 2 :

    Create SPAN Destination Group Flow-ID of 2

    Étape 2a. Créer une source étendue pour le trafic directement connecté à la SRC

    Sous Fabric > Access Policies > Policies > Troubleshooting > SPAN > SPAN Source Groups

    Create SPAN Source for Traffic Directly

    Filtrez davantage le trafic en ajoutant le chemin et l'EPG. L'exemple de TP est Tenant jr Application Profile ALL et EPG app.

    Filter the Traffic Both and EPG

    Étape 2b. Création d'une source étendue pour le trafic directement connecté à l'heure d'été


    Sous Fabric > Access Policies > Policies > Troubleshooting > SPAN > SPAN Source Groups

    Create SPAN Source for Traffic Directly Connected to the DST

    Filtrez davantage le trafic en ajoutant non seulement le chemin, mais aussi la base de données EPG :

    Filter the Traffic Enabled

    Étape 3. Analyse rapide de Wireshark

    Dans cet exemple, vous vérifiez que le nombre de paquets de requête ICMP correspond au nombre de paquets de réponse ICMP, en vous assurant qu'il n'y a pas d'abandon de paquets dans le fabric ACI.

    Ouvrez la capture sur wireshark pour créer le filtre à l'aide de l'ID de SPAN /ID de flux configuré avec l'IP SRC et DST :

    (erspan.spanid ==  and ) && (ip.src==  and ip.dst == )

    Filtre utilisé pour le flux testé en laboratoire :

    (erspan.spanid == 1 and icmp) && (ip.src== 10.1.2.1 and ip.dst == 10.1.1.1)

    Vérifiez que le paquet affiché est de la même quantité que celui envoyé :

    Verify the Displayed Packet is the Same Amount as Sent

    L'ID SPAN suivant doit avoir le même montant ; dans le cas contraire, le paquet a été abandonné dans le fabric.

    Filtre :

    (erspan.spanid == 2 and icmp) && (ip.src== 10.1.2.1 and ip.dst == 10.1.1.1)

    Next SPAN ID must have the Same Amount

    Option 2. Compteurs de plate-forme

    Cette méthode tire parti du fait que Nexus suit les performances des interfaces individuelles avec différentes tailles de paquets, mais la méthode ne nécessite pas qu'au moins une file d'attente ait un faible volume de trafic, si ce n'est zéro.

    Effacer les compteurs de plateforme

    Accédez au commutateur individuel et effacez l'interface individuelle qui se connecte aux périphériques.

    Switch#vsh_lc -c “clear platform internal counters port ”
    LEAF3# vsh_lc -c “clear platform internal counters port 6”
    LEAF1# vsh_lc -c “clear platform internal counters port 45”
    LEAF2# vsh_lc -c “clear platform internal counters port 45”

    Identification d’une taille de paquet avec des paquets faibles ou nuls

    Trouvez une taille de paquet qui n'a peut-être aucun compteur dans toutes les Leafs pour RX et TX :

    vsh_lc -c ‘show platform internal counters port ’ | grep X_PKT

    Dans l'exemple suivant, taille de paquet supérieure à 512 et inférieure à 1024 :

    LEAF101# vsh_lc -c "show platform internal counters port 45 " | grep X_PKT
                     RX_PKTOK          1187
                     RX_PKTTOTAL       1187
                     RX_PKT_LT64          0
                     RX_PKT_64            0
                     RX_PKT_65         1179
                     RX_PKT_128           8
                     RX_PKT_256           0
                     RX_PKT_512           0 <<
                     RX_PKT_1024          0
                     RX_PKT_1519          0
                     RX_PKT_2048          0
                     RX_PKT_4096          7
                     RX_PKT_8192          43
                     RX_PKT_GT9216        0
                     TX_PKTOK          3865
                     TX_PKTTOTAL       3865
                     TX_PKT_LT64          0
                     TX_PKT_64            0
                     TX_PKT_65         3842
                     TX_PKT_128          17
                     TX_PKT_256           6
                     TX_PKT_512           0 <<
                     TX_PKT_1024          10
                     TX_PKT_1519          3
                     TX_PKT_2048          662
                     TX_PKT_4096          0
                     TX_PKT_8192          0
                     TX_PKT_GT9216        0

    L'étape doit être effectuée sur la liaison vers laquelle les paquets sont transférés.

    Suivi du flux de trafic

    À partir du serveur 10.1.2.1, 1 000 paquets sont envoyés avec une taille de paquet de 520.

    Vérifiez sur l'interface Leaf 103 1/6, où le trafic est initié sur RX :

    MXS2-LF103# vsh_lc -c "show platform internal counters port 6 " | grep X_PKT_512
                     RX_PKT_512        1000
                     TX_PKT_512         647

    1 000 paquets RX, mais seulement 647 ont été envoyés en réponse.

    L'étape suivante consiste à vérifier les interfaces sortantes des autres serveurs :

    Pour Leaf102 :

    MXS2-LF102# vsh_lc -c "show platform internal counters port 45 " | grep X_PKT_512
                     RX_PKT_512           0
                     TX_PKT_512        1000

    Le fabric n'a pas abandonné la requête.

    Pour le Leaf 101, les paquets RX 647 et 648 représentent la même quantité de paquets TX par l'ACI.

    MXS2-LF101#  vsh_lc -c "show platform internal counters port 45 " | grep X_PKT_512
                     RX_PKT_512        647
                     TX_PKT_512          0

    Informations connexes

    Dépannage du transfert intra-fabric ACI - Pertes intermittentes

    Historique de révision

    Révision Date de publication Commentaires
    1.0
    08-Apr-2025
    Première publication
    TAC Authored

    Contribution d’experts de Cisco

    • Jessica Rueda
      Responsable technique de l'ingénierie de livraison client

    Ce document vous est-il utile?

    FeedbackCommentaires

    Contacter Cisco

    Ce document s’applique à ces produits