El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe los detalles sobre los errores de Verificación por redundancia cíclica (CRC) observados en los contadores de interfaz y las estadísticas de los switches Cisco Nexus.
Cisco recomienda que comprenda los conceptos básicos de switching Ethernet y la interfaz de línea de comandos (CLI) de Cisco NX-OS. Para obtener más información, consulte uno de estos documentos aplicables:
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
La información de este documento se originó a partir de dispositivos dentro de un ambiente de laboratorio específico. All of the devices used in this document started with a cleared (default) configuration. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
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 tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Este documento describe los detalles relacionados con los errores de Verificación por redundancia cíclica (CRC) observados en los contadores de interfaces en los switches de la serie Cisco Nexus. Este documento describe qué es un CRC, cómo se utiliza en el campo Secuencia de verificación de tramas (FCS) de las tramas Ethernet, cómo se manifiestan los errores CRC en los switches Nexus, cómo interactúan los errores CRC en los escenarios de conmutación de almacenamiento y reenvío y de conmutación de corte, las causas principales más probables de los errores CRC, y cómo solucionar y resolver los errores CRC.
La información de este documento es aplicable a todos los switches Nexus de Cisco. Parte de la información de este documento también puede aplicarse a otras plataformas de routing y switching de Cisco, como routers y switches Cisco Catalyst.
Un CRC es un mecanismo de detección de errores que se utiliza comúnmente en las redes informáticas y de almacenamiento para identificar los datos cambiados o dañados durante la transmisión. Cuando un dispositivo conectado a la red necesita transmitir datos, el dispositivo ejecuta un algoritmo de cálculo basado en códigos cíclicos contra los datos que resultan en un número de longitud fija. Este número de longitud fija se denomina valor CRC, pero coloquialmente, a menudo se denomina CRC para abreviar. Este valor CRC se agrega a los datos y se transmite a través de la red hacia otro dispositivo. Este dispositivo remoto ejecuta el mismo algoritmo de código cíclico con respecto a los datos y compara el valor resultante con el CRC agregado a los datos. Si ambos valores coinciden, el dispositivo remoto asume que los datos se transmitieron a través de la red sin estar dañados. Si los valores no coinciden, el dispositivo remoto asume que los datos se dañaron durante la transmisión a través de la red. Estos datos dañados no se pueden confiar y se descartan.
Los CRC se utilizan para la detección de errores en varias tecnologías de redes informáticas, como Ethernet (ambas variantes, por cable e inalámbricas), Token Ring, Asynchronous Transfer Mode (ATM) y Frame Relay. Las tramas Ethernet tienen un campo de Secuencia de verificación de tramas (FCS) de 32 bits al final de la trama (inmediatamente después de la carga útil de la trama) donde se inserta un valor CRC de 32 bits.
Por ejemplo, considere un escenario en el que dos hosts denominados Host-A y Host-B estén directamente conectados entre sí a través de sus Tarjetas de Interfaz de Red (NIC). El Host A necesita enviar la frase "Este es un ejemplo" al Host-B a través de la red. El Host A crea una trama Ethernet destinada al Host-B con una carga útil de "Esto es un ejemplo" y calcula que el valor CRC de la trama es un valor hexadecimal de 0xABCD. Host-A inserta el valor CRC de 0xABCD en el campo FCS de la trama Ethernet y luego transmite la trama Ethernet fuera de la NIC del Host-A hacia el Host-B.
Cuando el Host B recibe esta trama, calculará el valor CRC de la trama con el uso del mismo algoritmo exacto que el Host-A. Host-B calcula que el valor CRC de la trama es un valor hexadecimal de 0xABCD, lo que indica al Host-B que la trama Ethernet no estaba dañada mientras la trama se transmitía al Host-B.
Un error CRC ocurre cuando un dispositivo (ya sea un dispositivo de red o un host conectado a la red) recibe una trama Ethernet con un valor CRC en el campo FCS de la trama que no coincide con el valor CRC calculado por el dispositivo para la trama.
La mejor manera de demostrar este concepto es a través de un ejemplo. Considere un escenario en el que dos hosts denominados Host-A y Host-B se conectan directamente entre sí a través de sus tarjetas de interfaz de red (NIC). El Host A necesita enviar la frase "Este es un ejemplo" al Host-B a través de la red. El Host A crea una trama Ethernet destinada al Host-B con una carga útil de "Esto es un ejemplo" y calcula que el valor CRC de la trama es el valor hexadecimal 0xABCD. Host-A inserta el valor CRC de 0xABCD en el campo FCS de la trama Ethernet y luego transmite la trama Ethernet fuera de la NIC del Host-A hacia el Host-B.
Sin embargo, el daño en los medios físicos que conectan al Host A al Host B corrompe el contenido de la trama de modo que la frase dentro de la trama cambie a "Este fue un ejemplo" en lugar de la carga útil deseada de "Este es un ejemplo".
Cuando el Host B recibe esta trama, calcula el valor CRC de la trama, incluida la carga útil dañada. Host-B calcula que el valor CRC de la trama es un valor hexadecimal de 0xDEAD, que es diferente del valor CRC 0xABCD dentro del campo FCS de la trama Ethernet. Esta diferencia en los valores CRC indica al Host-B que la trama Ethernet estaba dañada mientras la trama se transmitía al Host-B. Como resultado, el Host-B no puede confiar en el contenido de esta trama Ethernet, por lo que la descartará. El host B normalmente incrementará también algún tipo de contador de errores en su tarjeta de interfaz de red (NIC), como los contadores de "errores de entrada", "errores CRC" o "errores RX".
Los errores CRC normalmente se manifiestan de dos maneras:
Estos errores se manifiestan de maneras ligeramente diferentes dependiendo del dispositivo con el que esté trabajando. Estas subsecciones se detallan para cada tipo de dispositivo.
Los errores CRC en los hosts de Windows se manifiestan normalmente como un contador de errores recibidos distinto de cero que se muestra en la salida del comando netstat -e del símbolo del sistema. A continuación se muestra un ejemplo de un contador de errores recibidos que no es cero desde el símbolo del sistema de un host de 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 NIC y su controlador respectivo deben soportar la contabilización de los errores CRC recibidos por la NIC para que el número de errores recibidos reportados por el comando netstat -e sea preciso. La mayoría de los NIC modernos y sus respectivos controladores admiten una contabilidad precisa de los errores CRC recibidos por el NIC.
Los errores CRC en los hosts Linux se manifiestan normalmente como un contador de "errores RX" distinto de cero que se muestra en la salida del comando ifconfig. Un ejemplo de un contador de errores RX no cero de un host Linux está aquí:
$ 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
Los errores CRC en los hosts Linux también pueden manifestarse como un contador de "errores RX" no cero que se muestra en la salida del comando ip -s link show. Un ejemplo de un contador de errores RX no cero de un host Linux está aquí:
$ 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 NIC y su controlador respectivo deben soportar la contabilización de los errores CRC recibidos por la NIC para que el número de errores RX informados por los comandos ifconfig o ip -s link show sea preciso. La mayoría de los NIC modernos y sus respectivos controladores admiten una contabilidad precisa de los errores CRC recibidos por el NIC.
Los dispositivos de red funcionan en uno de los dos modos de reenvío: modo de reenvío de almacenamiento y reenvío y modo de reenvío de corte. La forma en que un dispositivo de red maneja un error CRC recibido varía según sus modos de reenvío. Las subsecciones aquí describirán el comportamiento específico para cada modo de reenvío.
Cuando un dispositivo de red que funciona en modo de reenvío de almacenamiento y reenvío recibe una trama, el dispositivo de red almacenará la trama completa ("Almacenar") antes de validar el valor CRC de la trama, tomará una decisión de reenvío en la trama y transmitirá la trama fuera de una interfaz ("Reenviar"). Por lo tanto, cuando un dispositivo de red que opera en un modo de reenvío de almacenamiento y reenvío recibe una trama dañada con un valor CRC incorrecto en una interfaz específica, descartará la trama e incrementará el contador "Errores de entrada" en la interfaz.
En otras palabras, los dispositivos de red que funcionan en modo de reenvío Store-and-Forward no reenvían tramas Ethernet dañadas; se suprimen al ingreso.
Los switches Nexus de Cisco serie 7000 y 7700 funcionan en modo de reenvío de almacenamiento y reenvío. A continuación se muestra un ejemplo de un contador de errores de entrada distinto de cero y un contador CRC/FCS distinto de cero de un switch Nexus serie 7000 o 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
Los errores CRC también pueden manifestarse como un contador "FCS-Err" distinto de cero en la salida de errores show interface counters. El contador "Rcv-Err" en la salida de este comando también tendrá un valor distinto de cero, que es la suma de todos los errores de entrada (CRC o de otro tipo) recibidos por la interfaz. Aquí se muestra un ejemplo de esto:
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
Cuando un dispositivo de red que funciona en modo de reenvío de conexión directa comienza a recibir una trama, el dispositivo de red tomará una decisión de reenvío en el encabezado de la trama y comenzará a transmitir la trama desde una interfaz tan pronto como reciba suficiente de la trama para tomar una decisión de reenvío válida. Como los encabezados de trama y de paquete están al principio de la trama, esta decisión de reenvío se toma generalmente antes de que se reciba la carga útil de la trama.
El campo FCS de una trama Ethernet se encuentra al final de la trama, inmediatamente después de la carga útil de la trama. Por lo tanto, un dispositivo de red que opera en un modo de reenvío por corte ya habrá comenzado a transmitir la trama fuera de otra interfaz para el momento en que pueda calcular el CRC de la trama. Si el CRC calculado por el dispositivo de red para la trama no coincide con el valor CRC presente en el campo FCS, significa que el dispositivo de red reenvió una trama dañada a la red. Cuando esto sucede, el dispositivo de red incrementará dos contadores:
Aquí se muestra un ejemplo de esto, donde la salida del comando show interface indica que se recibieron varias tramas dañadas en Ethernet1/1 del dispositivo de red y se transmitieron desde Ethernet1/2 debido al modo de reenvío por corte del dispositivo de red:
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
Los errores CRC también pueden manifestarse como un contador "FCS-Err" distinto de cero en la interfaz de ingreso y contadores "Xmit-Err" no nulos en las interfaces de salida en la salida de errores show interface counters. El contador "Rcv-Err" en la interfaz de ingreso en la salida de este comando también tendrá un valor distinto de cero, que es la suma de todos los errores de entrada (CRC o de otro tipo) recibidos por la interfaz. Aquí se muestra un ejemplo de esto:
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
El dispositivo de red también modificará el valor CRC en el campo FCS de la trama de una manera específica que significa para los dispositivos de red ascendentes que esta trama está dañada. Este comportamiento se conoce como "pisotear" el CRC. La forma precisa en que se modifica el CRC varía de una plataforma a otra, pero generalmente implica invertir el valor actual de CRC presente en el campo FCS de la trama. Un ejemplo de esto es aquí:
Original CRC: 0xABCD (1010101111001101)
Stomped CRC: 0x5432 (0101010000110010)
Como resultado de este comportamiento, los dispositivos de red que funcionan en un modo de reenvío de conexión directa pueden propagar una trama dañada a través de una red. Si una red consta de varios dispositivos de red que funcionan en modo de reenvío de conexión directa, una única trama dañada puede provocar que los contadores de errores de entrada y de salida aumenten en varios dispositivos de red dentro de la red.
El primer paso para identificar y resolver la causa raíz de los errores CRC es aislar el origen de los errores CRC a un link específico entre dos dispositivos dentro de su red. Un dispositivo conectado a este link tendrá un contador de errores de salida de interfaz con un valor de cero o no está aumentando, mientras que el otro dispositivo conectado a este link tendrá un contador de errores de entrada de interfaz que no sea cero o que aumentará. Esto sugiere que el tráfico que sale de la interfaz de un dispositivo intacto se daña en el momento de la transmisión al dispositivo remoto y se cuenta como un error de entrada por la interfaz de ingreso del otro dispositivo en el link.
Identificar este link en una red que consta de dispositivos de red que funcionan en modo de reenvío de almacenamiento y reenvío es una tarea sencilla. Sin embargo, es más difícil identificar este link en una red que consta de dispositivos de red que funcionan en modo de reenvío de conexión directa, ya que muchos dispositivos de red tendrán contadores de errores de entrada y salida distintos de cero. Un ejemplo de este fenómeno se puede ver en la topología aquí, donde el link resaltado en rojo se daña de tal manera que el tráfico que atraviesa el link está dañado. Las interfaces etiquetadas con una "I" roja indican interfaces que podrían tener errores de entrada distintos de cero, mientras que las interfaces etiquetadas con una "O" azul indican interfaces que podrían tener errores de salida distintos de cero.
La identificación del link defectuoso requiere que realice un seguimiento recursivo de las tramas dañadas de "trayectoria" que siguen en la red a través de contadores de errores de entrada y salida no nulos, con errores de entrada no nulos que apuntan hacia el link dañado en la red. Esto se demuestra en el diagrama aquí.
La mejor manera de demostrar a través de un ejemplo es un proceso detallado para rastrear e identificar un link dañado. Considere la topología aquí:
En esta topología, la interfaz Ethernet1/1 de un switch Nexus denominado Switch-1 se conecta a un host denominado Host-1 a través de la Tarjeta de interfaz de red (NIC) eth0 del host-1. La interfaz Ethernet1/2 del Switch-1 está conectada a un segundo switch Nexus, denominado Switch-2, a través de la interfaz Ethernet1/2 del Switch-2. La interfaz Ethernet1/1 del Switch-2 está conectada a un host denominado Host-2 a través de la NIC eth0 del Host-2.
El link entre el Host-1 y el Switch-1 a través de la interfaz Ethernet1/1 del Switch-1 está dañado, lo que causa que el tráfico que atraviesa el link se dañe intermitentemente. Sin embargo, todavía no sabemos que este link esté dañado. Debemos rastrear la trayectoria que dejan las tramas dañadas en la red a través de contadores de errores de entrada y salida no nulos o incrementando los contadores de errores de entrada y salida para localizar el link dañado en esta red.
En este ejemplo, la NIC del host 2 informa que está recibiendo errores 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
Usted sabe que la NIC del Host 2 se conecta al Switch-2 a través de la interfaz Ethernet1/1. Puede confirmar que la interfaz Ethernet1/1 tiene un contador de errores de salida distinto de cero con el comando 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
Dado que el contador de errores de salida de la interfaz Ethernet1/1 no es cero, es muy probable que haya otra interfaz del Switch-2 que tenga un contador de errores de entrada distinto de cero. Puede utilizar el comando show interface counters errors non-zero para identificar si alguna interfaz del Switch-2 tiene un contador de errores de entrada distinto de cero.
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 --------------------------------------------------------------------------------
Puede ver que Ethernet1/2 del Switch-2 tiene un contador de errores de entrada distinto de cero. Esto sugiere que el Switch-2 recibe tráfico dañado en esta interfaz. Puede confirmar qué dispositivo está conectado a Ethernet1/2 del switch 2 a través de las funciones de protocolo de detección de Cisco (CDP) o protocolo de detección local de enlaces (LLDP). Aquí se muestra un ejemplo de esto con el comando 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
Ahora sabe que el Switch-2 está recibiendo tráfico dañado en su interfaz Ethernet1/2 de la interfaz Ethernet1/2 del Switch-1, pero todavía no sabe si el link entre Ethernet1/2 del Switch-1 y Ethernet1/2 del Switch-2 está dañado y causa la corrupción, o si el Switch-1 es un switch de conexión directa que reenvía el tráfico dañado que recibe. Debe iniciar sesión en el Switch-1 para verificar esto.
Puede confirmar que la interfaz Ethernet1/2 del Switch 1 tiene un contador de errores de salida distinto de cero con el comando 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
Puede ver que Ethernet1/2 del Switch-1 tiene un contador de errores de salida distinto de cero. Esto sugiere que el link entre Ethernet1/2 del Switch-1 y Ethernet1/2 del Switch-2 no está dañado; en cambio, el Switch-1 es un switch de conexión directa que reenvía el tráfico dañado que recibe en alguna otra interfaz. Como se demostró anteriormente con el Switch-2, puede utilizar el comando show interface counters errors non-zero para identificar si alguna interfaz del Switch-1 tiene un contador de errores de entrada distinto de cero.
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 --------------------------------------------------------------------------------
Puede ver que Ethernet1/1 del Switch-1 tiene un contador de errores de entrada distinto de cero. Esto sugiere que el Switch-1 está recibiendo tráfico dañado en esta interfaz. Sabemos que esta interfaz se conecta con la NIC eth0 del Host 1. Podemos revisar las estadísticas de la interfaz NIC eth0 del Host-1 para confirmar si el Host-1 envía tramas dañadas fuera de esta interfaz.
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
Las estadísticas de la NIC eth0 del Host-1 sugieren que el host no está transmitiendo tráfico dañado. Esto sugiere que el link entre el eth0 del Host 1 y Ethernet1/1 del Switch-1 está dañado y es la fuente de esta corrupción del tráfico. Será necesario realizar más troubleshooting en este link para identificar el componente defectuoso que causa esta corrupción y reemplazarlo.
La causa principal más común de los errores CRC es un componente dañado o en mal funcionamiento de un link físico entre dos dispositivos. Algunos ejemplos son:
También es posible que uno o más dispositivos mal configurados provoquen errores CRC inadvertidamente dentro de una red. Un ejemplo de esto es una discordancia de configuración de la unidad máxima de transmisión (MTU) entre dos o más dispositivos dentro de la red, lo que hace que los paquetes grandes se trunquen incorrectamente. La identificación y resolución de este problema de configuración también puede corregir los errores CRC dentro de una red.
Puede identificar el componente específico del mal funcionamiento a través de un proceso de eliminación:
Si el componente que falla es un producto de Cisco (como un dispositivo de red o transceptor de Cisco) que está cubierto por un contrato de soporte activo, puede abrir un caso de soporte con el TAC de Cisco detallando su solución de problemas para que el componente que falla sea reemplazado a través de una Autorización de devolución de mercancía (RMA).
Revisión | Fecha de publicación | Comentarios |
---|---|---|
3.0 |
10-Nov-2021 |
Mejorar el formato secundario del documento |
2.0 |
10-Nov-2021 |
Versión inicial |
1.0 |
10-Nov-2021 |
Versión inicial |