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.
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.
Ce document décrit en détail les erreurs CRC (Cyclic Redundancy Check) observées sur les compteurs d'interface et les statistiques des commutateurs Cisco Nexus.
Cisco vous recommande de comprendre les bases de la commutation Ethernet et de l'interface de ligne de commande (CLI) de Cisco NX-OS. Pour plus d'informations, reportez-vous à l'un des documents suivants :
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
Les informations contenues dans ce document ont été créées à partir des périphériques dans un environnement de laboratoire spécifique. 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.
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.
Ce document décrit en détail les erreurs CRC (Cyclic Redundancy Check) observées sur les compteurs d'interface sur les commutateurs de la gamme Cisco Nexus. Ce document décrit ce qu'est un CRC, comment il est utilisé dans le champ Frame Check Sequence (FCS) des trames Ethernet, comment les erreurs CRC se manifestent sur les commutateurs Nexus, comment les erreurs CRC interagissent dans les scénarios de commutation Store and Forward et de commutation Cut-Through, les causes les plus probables des erreurs CRC, et comment dépanner et résoudre les erreurs CRC.
Les informations de ce document s'appliquent à tous les commutateurs de la gamme Cisco Nexus. Certaines informations de ce document peuvent également s'appliquer à d'autres plates-formes de routage et de commutation Cisco, telles que les routeurs et commutateurs Cisco Catalyst.
Un CRC est un mécanisme de détection d’erreurs couramment utilisé dans les réseaux d’ordinateurs et de stockage pour identifier les données modifiées ou endommagées pendant la transmission. Lorsqu'un périphérique connecté au réseau doit transmettre des données, il exécute un algorithme de calcul basé sur des codes cycliques par rapport aux données qui produisent un nombre de longueur fixe. Ce numéro de longueur fixe est appelé valeur CRC, mais de manière plus familière, il est souvent appelé CRC pour abréger. Cette valeur CRC est ajoutée aux données et transmise par le réseau vers un autre périphérique. Ce périphérique distant exécute le même algorithme de code cyclique sur les données et compare la valeur obtenue avec le CRC ajouté aux données. Si les deux valeurs correspondent, le périphérique distant suppose que les données ont été transmises sur le réseau sans être endommagées. Si les valeurs ne correspondent pas, le périphérique distant suppose que les données ont été endommagées lors de la transmission sur le réseau. Ces données corrompues ne peuvent pas être approuvées et sont ignorées.
Les CRC sont utilisés pour la détection des erreurs sur plusieurs technologies de réseau informatique, telles que Ethernet (variantes filaires et sans fil), Token Ring, ATM (Asynchronous Transfer Mode) et Frame Relay. Les trames Ethernet ont un champ FCS (Frame Check Sequence) 32 bits à la fin de la trame (immédiatement après la charge utile de la trame) où une valeur CRC 32 bits est insérée.
Par exemple, imaginez un scénario où deux hôtes nommés Hôte-A et Hôte-B sont directement connectés l'un à l'autre par le biais de leurs cartes d'interface réseau (NIC). L’hôte A doit envoyer la phrase “ Voici un exemple ” à l’hôte B sur le réseau. L’hôte A crée une trame Ethernet destinée à l’hôte B avec une charge utile de “ Voici un exemple de ” et calcule que la valeur CRC de la trame est une valeur hexadécimale de 0xABCD. L’hôte A insère la valeur CRC 0xABCD dans le champ FCS de la trame Ethernet, puis transmet la trame Ethernet de la carte réseau de l’hôte A vers l’hôte B.
Lorsque l’hôte B reçoit cette trame, il calcule la valeur CRC de la trame à l’aide du même algorithme que l’hôte A. L’hôte B calcule que la valeur CRC de la trame est une valeur hexadécimale de 0xABCD, ce qui indique à l’hôte B que la trame Ethernet n’a pas été endommagée pendant que la trame a été transmise à l’hôte B.
Une erreur CRC se produit lorsqu’un périphérique (un périphérique réseau ou un hôte connecté au réseau) reçoit une trame Ethernet avec une valeur CRC dans le champ FCS de la trame qui ne correspond pas à la valeur CRC calculée par le périphérique pour la trame.
Ce concept est mieux démontré par un exemple. Considérez un scénario dans lequel deux hôtes nommés Hôte-A et Hôte-B sont directement connectés l'un à l'autre par le biais de leurs cartes d'interface réseau (NIC). L’hôte A doit envoyer la phrase “ Voici un exemple ” à l’hôte B sur le réseau. L’hôte A crée une trame Ethernet destinée à l’hôte B avec une charge utile de “ Voici un exemple de ” et calcule que la valeur CRC de la trame est la valeur hexadécimale 0xABCD. L’hôte A insère la valeur CRC 0xABCD dans le champ FCS de la trame Ethernet, puis transmet la trame Ethernet de la carte réseau de l’hôte A vers l’hôte B.
Cependant, les dommages sur le support physique qui connecte l’hôte A à l’hôte B corrompent le contenu de la trame de sorte que la phrase de la trame passe à “ Ceci était un exemple ” au lieu de la charge utile souhaitée de “ Ceci est un exemple ”.
Lorsque l’hôte B reçoit cette trame, il calcule la valeur CRC de la trame, y compris la charge utile endommagée. L'hôte B calcule que la valeur CRC de la trame est une valeur hexadécimale 0xDEAD, qui est différente de la valeur CRC 0xABCD dans le champ FCS de la trame Ethernet. Cette différence dans les valeurs CRC indique à l’hôte B que la trame Ethernet a été endommagée pendant que la trame était transmise à l’hôte B. Par conséquent, l’hôte B ne peut pas faire confiance au contenu de cette trame Ethernet, il l’abandonnera donc. L’hôte B incrémente généralement une sorte de compteur d’erreurs sur sa carte d’interface réseau (NIC), comme les erreurs “ d’entrée ”, “ les erreurs CRC ” ou “ les erreurs RX ” compteurs.
Les erreurs CRC se manifestent généralement de deux manières :
Ces erreurs se manifestent de manière légèrement différente selon le périphérique avec lequel vous travaillez. Ces sous-sections détaillent chaque type de périphérique.
Les erreurs CRC sur les hôtes Windows se manifestent généralement sous la forme d'un compteur Erreurs reçues non nul affiché dans le résultat de la commande netstat -e de l'invite de commandes. Voici un exemple de compteur d'erreurs reçues non nulles à partir de l'invite de commandes d'un hôte Windows :
>netstat -e
Interface Statistics
Received Sent
Bytes 1116139893 3374201234
Unicast packets 101276400 49751195
Non-unicast packets 0 0
Discards 0 0
Errors 47294 0
Unknown protocols 0
La carte réseau et son pilote respectif doivent prendre en charge la comptabilisation des erreurs CRC reçues par la carte réseau afin que le nombre d'erreurs reçues signalées par la commande netstat -e soit exact. La plupart des cartes réseau modernes et leurs pilotes respectifs prennent en charge la comptabilisation précise des erreurs CRC reçues par la carte réseau.
Les erreurs CRC sur les hôtes Linux se manifestent généralement sous la forme d'erreurs RX “ non nulles ” compteur affiché dans la sortie de la commande ifconfig. Voici un exemple d'un compteur d'erreurs RX non nul à partir d'un hôte Linux :
$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.0.2.10 netmask 255.255.255.128 broadcast 192.0.2.255
inet6 fe80::10 prefixlen 64 scopeid 0x20<link>
ether 08:62:66:be:48:9b txqueuelen 1000 (Ethernet)
RX packets 591511682 bytes 214790684016 (200.0 GiB)
RX errors 478920 dropped 0 overruns 0 frame 0
TX packets 85495109 bytes 288004112030 (268.2 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Les erreurs CRC sur les hôtes Linux peuvent également se manifester sous forme d'erreurs RX “ non nulles ” compteur affiché dans la sortie de la commande ip -s link show. Voici un exemple d'un compteur d'erreurs RX non nul à partir d'un hôte Linux :
$ ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 08:62:66:84:8f:6d brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
32246366102 444908978 478920 647 0 419445867
TX: bytes packets errors dropped carrier collsns
3352693923 30185715 0 0 0 0
altname enp11s0
La carte réseau et son pilote respectif doivent prendre en charge la comptabilisation des erreurs CRC reçues par la carte réseau afin que le nombre d'erreurs RX signalées par les commandes ifconfig ou ip -s link show soit exact. La plupart des cartes réseau modernes et leurs pilotes respectifs prennent en charge la comptabilisation précise des erreurs CRC reçues par la carte réseau.
Les périphériques réseau fonctionnent dans l'un des deux modes de transfert : le mode de transfert Store and Forward et le mode de transfert Cut-Through. La manière dont un périphérique réseau gère une erreur CRC reçue varie en fonction de ses modes de transmission. Les sous-sections ici décrivent le comportement spécifique de chaque mode de transfert.
Lorsqu'un périphérique réseau fonctionnant en mode Store and Forward reçoit une trame, le périphérique réseau met en mémoire tampon l'intégralité de la trame (“ Store ”) avant de valider la valeur CRC de la trame, de prendre une décision de transfert sur la trame et de transmettre la trame à partir d'une interface (“ Forward ”). Par conséquent, lorsqu'un périphérique réseau fonctionnant en mode Store-and-Forward reçoit une trame endommagée avec une valeur CRC incorrecte sur une interface spécifique, il abandonne la trame et incrémente le compteur “ Input Errors ” sur l'interface.
En d’autres termes, les trames Ethernet corrompues ne sont pas transmises par les périphériques réseau fonctionnant en mode Store and Forward ; on les laisse entrer.
Les commutateurs des gammes Cisco Nexus 7000 et 7700 fonctionnent en mode Store and Forward. Voici un exemple de compteur d'erreurs d'entrée non nul et de compteur CRC/FCS non nul à partir d'un commutateur de la gamme Nexus 7000 ou 7700 :
switch# show interface
<snip>
Ethernet1/1 is up
RX
241052345 unicast packets 5236252 multicast packets 5 broadcast packets
245794858 input packets 17901276787 bytes
0 jumbo packets 0 storm suppression packets
0 runts 0 giants 579204 CRC/FCS 0 no buffer
579204 input error 0 short frame 0 overrun 0 underrun 0 ignored
0 watchdog 0 bad etype drop 0 bad proto drop 0 if down drop
0 input with dribble 0 input discard
0 Rx pause
Les erreurs CRC peuvent également se manifester sous la forme d'un compteur de ” FCS-Err “ non nul dans la sortie des erreurs show interface counters. Le compteur « Rcv-Err » dans la sortie de cette commande aura également une valeur non nulle, qui est la somme de toutes les erreurs d'entrée (CRC ou autre) reçues par l'interface. Voici un exemple :
switch# show interface counters errors
<snip>
--------------------------------------------------------------------------------
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
--------------------------------------------------------------------------------
Eth1/1 0 579204 0 579204 0 0
Lorsqu’un périphérique réseau fonctionnant en mode de transfert cut-through commence à recevoir une trame, le périphérique réseau prend une décision de transfert sur l’en-tête de la trame et commence à transmettre la trame à partir d’une interface dès qu’il en reçoit suffisamment pour prendre une décision de transfert valide. Comme les en-têtes de trame et de paquet se trouvent au début de la trame, cette décision de transfert est généralement prise avant la réception de la charge utile de la trame.
Le champ FCS d’une trame Ethernet se trouve à la fin de la trame, immédiatement après la charge utile de la trame. Par conséquent, un périphérique réseau fonctionnant en mode de transfert Cut-Through aura déjà commencé à transmettre la trame à partir d’une autre interface au moment où il pourra calculer le CRC de la trame. Si le CRC calculé par le périphérique réseau pour la trame ne correspond pas à la valeur CRC présente dans le champ FCS, cela signifie que le périphérique réseau a transféré une trame endommagée dans le réseau. Dans ce cas, le périphérique réseau incrémente deux compteurs :
Un exemple de ceci est illustré ici, où le résultat de la commande show interface indique que plusieurs trames endommagées ont été reçues sur Ethernet1/1 du périphérique réseau et transmises depuis Ethernet1/2 en raison du mode de transfert Cut-through du périphérique réseau :
switch# show interface
<snip>
Ethernet1/1 is up
RX
46739903 unicast packets 29596632 multicast packets 0 broadcast packets
76336535 input packets 6743810714 bytes
15 jumbo packets 0 storm suppression bytes
0 runts 0 giants 47294 CRC 0 no buffer
47294 input error 0 short frame 0 overrun 0 underrun 0 ignored
0 watchdog 0 bad etype drop 0 bad proto drop 0 if down drop
0 input with dribble 0 input discard
0 Rx pause
Ethernet1/2 is up
TX
46091721 unicast packets 2852390 multicast packets 102619 broadcast packets
49046730 output packets 3859955290 bytes
50230 jumbo packets
47294 output error 0 collision 0 deferred 0 late collision
0 lost carrier 0 no carrier 0 babble 0 output discard
0 Tx pause
Les erreurs CRC peuvent également se manifester sous la forme d'un compteur de ” FCS-Err “ non nul sur l'interface d'entrée et de compteurs Xmit-Err non nuls sur les interfaces de sortie dans la sortie des erreurs show interface counters. Le compteur « Rcv-Err » de l'interface d'entrée dans la sortie de cette commande aura également une valeur non nulle, qui est la somme de toutes les erreurs d'entrée (CRC ou autre) reçues par l'interface. Voici un exemple :
switch# show interface counters errors
<snip>
--------------------------------------------------------------------------------
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
--------------------------------------------------------------------------------
Eth1/1 0 47294 0 47294 0 0
Eth1/2 0 0 47294 0 0 0
Le périphérique réseau modifiera également la valeur CRC dans le champ FCS de la trame d’une manière spécifique qui signifie aux périphériques réseau en amont que cette trame est endommagée. Ce comportement est connu sous le nom “ estomper ” CRC. La manière précise dont le CRC est modifié varie d’une plate-forme à l’autre, mais en règle générale, il s’agit d’inverser la valeur CRC actuelle présente dans le champ FCS de la trame. En voici un exemple :
Original CRC: 0xABCD (1010101111001101)
Stomped CRC: 0x5432 (0101010000110010)
En raison de ce comportement, les périphériques réseau fonctionnant en mode de transfert cut-through peuvent propager une trame corrompue sur un réseau. Si un réseau se compose de plusieurs périphériques réseau fonctionnant en mode de transfert Cut-through, une seule trame corrompue peut entraîner l'incrémentation des compteurs d'erreurs d'entrée et de sortie sur plusieurs périphériques réseau de votre réseau.
La première étape pour identifier et résoudre la cause première des erreurs CRC consiste à isoler la source des erreurs CRC sur une liaison spécifique entre deux périphériques de votre réseau. Un périphérique connecté à cette liaison aura un compteur d'erreurs de sortie d'interface avec une valeur égale à zéro ou n'est pas en train d'incrémenter, tandis que l'autre périphérique connecté à cette liaison aura un compteur d'erreurs d'entrée d'interface différent de zéro ou d'incrémentation. Ceci suggère que le trafic quitte l'interface d'un périphérique intact est endommagé au moment de la transmission vers le périphérique distant et est compté comme une erreur d'entrée par l'interface d'entrée de l'autre périphérique sur la liaison.
L'identification de cette liaison dans un réseau constitué de périphériques réseau fonctionnant en mode de transfert Store and Forward est une tâche simple. Cependant, il est plus difficile d’identifier cette liaison dans un réseau constitué de périphériques réseau fonctionnant en mode de transfert cut-through, car de nombreux périphériques réseau auront des compteurs d’erreurs d’entrée et de sortie différents de zéro. Un exemple de ce phénomène peut être vu dans la topologie ici, où la liaison surlignée en rouge est endommagée de sorte que le trafic traversant la liaison est endommagé. Les interfaces marquées d'un « I » rouge indiquent les interfaces qui peuvent avoir des erreurs d'entrée non nulles, tandis que les interfaces marquées d'un « O » bleu indiquent les interfaces qui peuvent avoir des erreurs de sortie non nulles.
Pour identifier la liaison défectueuse, vous devez suivre de manière récursive le chemin suivi par les trames endommagées dans le réseau via des compteurs d'erreurs d'entrée et de sortie non nuls, avec des erreurs d'entrée non nulles pointant en amont vers la liaison endommagée dans le réseau. Ceci est démontré dans le schéma ici.
Un exemple illustre le mieux un processus détaillé de traçage et d’identification d’une liaison endommagée. Considérez la topologie ici :
Dans cette topologie, l’interface Ethernet1/1 d’un commutateur Nexus nommé Switch-1 est connectée à un hôte nommé Host-1 via la carte réseau eth0 de l’hôte Host-1. L’interface Ethernet1/2 du commutateur 1 est connectée à un deuxième commutateur Nexus, appelé Switch-2, via l’interface Ethernet1/2 du commutateur 2. L’interface Ethernet1/1 du commutateur 2 est connectée à un hôte nommé Host-2 via la carte réseau eth0 de l’hôte 2.
La liaison entre l’hôte 1 et le commutateur 1 via l’interface Ethernet1/1 du commutateur 1 est endommagée, ce qui entraîne la corruption intermittente du trafic qui traverse la liaison. Cependant, nous ne savons pas encore que cette liaison est endommagée. Nous devons suivre le chemin que les trames endommagées laissent dans le réseau via des compteurs d’erreurs d’entrée et de sortie différents de zéro ou incrémentés pour localiser la liaison endommagée dans ce réseau.
Dans cet exemple, la carte réseau de l'hôte 2 signale qu'il reçoit des erreurs CRC.
Host-2$ ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 00:50:56:84:8f:6d brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
32246366102 444908978 478920 647 0 419445867
TX: bytes packets errors dropped carrier collsns
3352693923 30185715 0 0 0 0
altname enp11s0
Vous savez que la carte réseau de l’hôte 2 se connecte au commutateur 2 via l’interface Ethernet1/1. Vous pouvez confirmer que l'interface Ethernet1/1 a un compteur d'erreurs de sortie non nul avec la commande show interface.
Switch-2# show interface <snip> Ethernet1/1 is up admin state is up, Dedicated Interface RX 30184570 unicast packets 872 multicast packets 273 broadcast packets 30185715 input packets 3352693923 bytes 0 jumbo packets 0 storm suppression bytes 0 runts 0 giants 0 CRC 0 no buffer 0 input error 0 short frame 0 overrun 0 underrun 0 ignored 0 watchdog 0 bad etype drop 0 bad proto drop 0 if down drop 0 input with dribble 0 input discard 0 Rx pause TX 444907944 unicast packets 932 multicast packets 102 broadcast packets 444908978 output packets 32246366102 bytes 0 jumbo packets 478920 output error 0 collision 0 deferred 0 late collision 0 lost carrier 0 no carrier 0 babble 0 output discard 0 Tx pause
Puisque le compteur d’erreurs de sortie de l’interface Ethernet1/1 est différent de zéro, il y a probablement une autre interface du commutateur 2 qui a un compteur d’erreurs d’entrée différent de zéro. Vous pouvez utiliser la commande show interface counters errors non-zero afin d'identifier si des interfaces du commutateur 2 ont un compteur d'erreurs d'entrée non zéro.
Switch-2# show interface counters errors non-zero <snip> -------------------------------------------------------------------------------- Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards -------------------------------------------------------------------------------- Eth1/1 0 0 478920 0 0 0 Eth1/2 0 478920 0 478920 0 0 -------------------------------------------------------------------------------- Port Single-Col Multi-Col Late-Col Exces-Col Carri-Sen Runts -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- Port Giants SQETest-Err Deferred-Tx IntMacTx-Er IntMacRx-Er Symbol-Err -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- Port InDiscards --------------------------------------------------------------------------------
Vous pouvez voir qu’Ethernet1/2 du commutateur 2 a un compteur d’erreurs d’entrée différent de zéro. Ceci suggère que le commutateur 2 reçoit du trafic corrompu sur cette interface. Vous pouvez confirmer quel périphérique est connecté à Ethernet1/2 du commutateur 2 via les fonctions CDP (Cisco Discovery Protocol) ou LLDP (Link Local Discovery Protocol). Un exemple de ceci est illustré ici avec la commande show cdp neighbors.
Switch-2# show cdp neighbors <snip> Capability Codes: R - Router, T - Trans-Bridge, B - Source-Route-Bridge S - Switch, H - Host, I - IGMP, r - Repeater, V - VoIP-Phone, D - Remotely-Managed-Device, s - Supports-STP-Dispute Device-ID Local Intrfce Hldtme Capability Platform Port ID Switch-1(FDO12345678) Eth1/2 125 R S I s N9K-C93180YC- Eth1/2
Vous savez maintenant que le commutateur 2 reçoit du trafic corrompu sur son interface Ethernet1/2 de l'interface Ethernet1/2 du commutateur 1, mais vous ne savez pas encore si la liaison entre le commutateur 1 Ethernet1/2 et le commutateur 2 Ethernet1/2 est endommagée et cause la corruption, ou si le commutateur 1 est un commutateur cut-through qui transfère le trafic corrompu qu'il reçoit. Vous devez vous connecter au commutateur Switch-1 pour vérifier cela.
Vous pouvez confirmer que l'interface Ethernet1/2 du commutateur 1 a un compteur d'erreurs de sortie différent de zéro à l'aide de la commande show interfaces.
Switch-1# show interface <snip> Ethernet1/2 is up admin state is up, Dedicated Interface RX 30581666 unicast packets 178 multicast packets 931 broadcast packets 30582775 input packets 3352693923 bytes 0 jumbo packets 0 storm suppression bytes 0 runts 0 giants 0 CRC 0 no buffer 0 input error 0 short frame 0 overrun 0 underrun 0 ignored 0 watchdog 0 bad etype drop 0 bad proto drop 0 if down drop 0 input with dribble 0 input discard 0 Rx pause TX 454301132 unicast packets 734 multicast packets 72 broadcast packets 454301938 output packets 32246366102 bytes 0 jumbo packets 478920 output error 0 collision 0 deferred 0 late collision 0 lost carrier 0 no carrier 0 babble 0 output discard 0 Tx pause
Vous pouvez voir qu’Ethernet1/2 du commutateur 1 a un compteur d’erreurs de sortie non nul. Ceci suggère que la liaison entre Ethernet1/2 du commutateur 1 et Ethernet1/2 du commutateur 2 n'est pas endommagée. Au lieu de cela, le commutateur 1 est un commutateur cut-through qui transfère le trafic corrompu qu'il reçoit sur une autre interface. Comme précédemment démontré avec le commutateur Switch-2, vous pouvez utiliser la commande show interface counters errors non-zero afin d'identifier si une interface du commutateur Switch-1 a un compteur d'erreurs d'entrée différent de zéro.
Switch-1# show interface counters errors non-zero <snip> -------------------------------------------------------------------------------- Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards -------------------------------------------------------------------------------- Eth1/1 0 478920 0 478920 0 0 Eth1/2 0 0 478920 0 0 0 -------------------------------------------------------------------------------- Port Single-Col Multi-Col Late-Col Exces-Col Carri-Sen Runts -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- Port Giants SQETest-Err Deferred-Tx IntMacTx-Er IntMacRx-Er Symbol-Err -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- Port InDiscards --------------------------------------------------------------------------------
Vous pouvez voir qu’Ethernet1/1 du commutateur 1 a un compteur d’erreurs d’entrée différent de zéro. Ceci suggère que le commutateur 1 reçoit du trafic corrompu sur cette interface. Nous savons que cette interface se connecte à la carte réseau eth0 de l’hôte 1. Nous pouvons examiner les statistiques d’interface NIC eth0 de l’hôte 1 pour vérifier si l’hôte 1 envoie des trames endommagées à partir de cette interface.
Host-1$ ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 00:50:56:84:8f:6d brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
73146816142 423112898 0 0 0 437368817
TX: bytes packets errors dropped carrier collsns
3312398924 37942624 0 0 0 0
altname enp11s0
Les statistiques de la carte réseau eth0 de l’hôte 1 indiquent que l’hôte ne transmet pas le trafic corrompu. Ceci suggère que la liaison entre l’eth0 de l’hôte 1 et l’Ethernet1/1 du commutateur 1 est endommagée et est la source de cette corruption de trafic. Un dépannage supplémentaire devra être effectué sur cette liaison pour identifier le composant défectueux à l’origine de cette corruption et le remplacer.
La cause la plus courante des erreurs CRC est un composant endommagé ou défectueux d’une liaison physique entre deux périphériques. Exemples :
Il est également possible qu’un ou plusieurs périphériques mal configurés provoquent par inadvertance des erreurs CRC au sein d’un réseau. Un exemple de ceci est une incompatibilité de configuration de l'unité de transmission maximale (MTU) entre deux ou plusieurs périphériques du réseau, ce qui entraîne une troncation incorrecte des paquets volumineux. L’identification et la résolution de ce problème de configuration peuvent également corriger des erreurs CRC au sein d’un réseau.
Vous pouvez identifier le composant défectueux spécifique au moyen d'un processus d'élimination :
Si le composant défectueux est un produit Cisco (tel qu'un périphérique réseau ou un émetteur-récepteur Cisco) couvert par un contrat d'assistance actif, vous pouvez ouvrir un dossier d'assistance avec le centre d'assistance technique Cisco détaillant votre dépannage pour que le composant défectueux soit remplacé par une autorisation de retour de matériel (RMA).
Révision | Date de publication | Commentaires |
---|---|---|
3.0 |
10-Nov-2021 |
Améliorer la mise en forme mineure du document |
2.0 |
10-Nov-2021 |
Version initiale |
1.0 |
10-Nov-2021 |
Première publication |