Un error CRC es un síntoma, no una ubicación — puede ser tanto el puerto local, como el cable o módulo óptico, o el dispositivo del extremo remoto. Este es el procedimiento de intercambio en tres pasos que aísla cuál de ellos es, cambiando exactamente una variable a la vez, y cómo leer cada resultado sin adivinar.
By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026
Un error CRC solo indica que una trama llegó corrupta — no dice nada sobre cuál de los tres elementos físicos entre dos dispositivos realmente la corrompió.
Un contador CRC en aumento en display interface — parte de la misma ruta de descarte/error que cubre la nota complementaria de diagnóstico de pérdida de paquetes — significa que llegan tramas con una suma de verificación que no coincide con su contenido. Eso puede ocurrir exactamente en tres lugares: el propio transceptor y PHY del puerto local, el cable o módulo óptico intermedio, o el puerto del dispositivo del extremo remoto. El instinto es cambiar los tres a la vez — cambiar el cable y el transceptor y pasar a otro puerto del peer en la misma visita — pero eso solo indica que el problema desapareció, no qué cambio realmente lo solucionó.
El método de tres pasos a continuación cambia exactamente una variable por paso, en un orden fijo, e indica, a partir de la línea base del contador y el resultado de cada paso, exactamente dónde dejar de buscar.
Cada paso mantiene fijos dos de los tres elementos e intercambia solo el tercero — el resultado de ese único paso indica si hay que escalar o continuar.
Presentado como árbol de decisión, el orden importa: primero el puerto local, luego el enlace físico, luego el dispositivo del extremo remoto — porque cada paso es más rápido y económico de probar que el siguiente, y descartar primero las posibilidades baratas evita un intercambio de hardware innecesario o una llamada innecesaria al soporte del peer.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Antes de ejecutar cualquiera de los tres pasos, borre los contadores de la interfaz con reset counters interface, para que lo que lea después refleje solo esta ventana de prueba, no el historial acumulado desde el último reinicio del dispositivo.
Un intercambio, una lectura limpia del contador, una decisión — repetido como máximo tres veces.
display interface acumula desde el último reinicio o el último reseteo — leerlo sin borrar antes mezcla semanas de errores antiguos con la prueba de hoy.
<HUAWEI> reset counters interface GigabitEthernet 0/0/5
<HUAWEI> display interface GigabitEthernet 0/0/5
GigabitEthernet0/0/5 current state : UP
Line protocol current state : UP
Total Error: 10
CRC: 4, Giants: 0
Jabbers: 1, Fragments: 0
Runts: 0, DropEvents: 0
Alignments: 0, Symbols: 5
// CRC incrementing after a clean reset -- a real, current problem, not old historyMantenga el cable y el puerto del extremo remoto exactamente como están — cambie solo a qué puerto local se conecta el enlace.
Mantenga el puerto local y el puerto del extremo remoto exactamente como están — cambie solo el cable, la fibra o el módulo óptico intermedio.
Mantenga el puerto local y el enlace exactamente como están — cambie solo lo que hay en el extremo remoto.
| Paso | Qué intercambió | Si el error sigue al intercambio | Conclusión |
|---|---|---|---|
| 1 | Puerto local | El error permanece en la posición de puerto original | Hardware del dispositivo local — abrir un caso de soporte |
| 1 | Puerto local | El error desaparece al moverse al otro puerto | El puerto está limpio — continuar al Paso 2 |
| 2 | Cable / fibra | El error sigue al cable | Problema de calidad del enlace — inspeccionar y reemplazar |
| 2 | Módulo óptico | El error sigue al módulo certificado | Escalar al I+D del fabricante — no un simple intercambio |
| 2 | Cable y módulo | El error permanece pese a ambos intercambios | El enlace está limpio — continuar al Paso 3 |
| 3 | Puerto peer (peer multipuerto) | El error desaparece en otro puerto peer | Problema de puerto del lado peer — equipo de soporte propio del peer |
| 3 | Dispositivo peer (peer de un solo puerto) | El error persiste en otro puerto o unidad peer | Problema de compatibilidad — soporte de ambos fabricantes en conjunto |
El método es simple; estas son las formas en que en la práctica se obtiene una lectura falsa.
SYMPTOMLa interfaz nunca queda administrativamente ni operacionalmente down, así que un problema de capa física se descarta pronto — seguramente una falla real haría caer el enlace.
CAUSEUn conector en deterioro, un cable marginal o un presupuesto óptico al límite no necesariamente hacen caer el enlace en absoluto — simplemente corrompen una fracción creciente de tramas mientras el enlace permanece Up todo el tiempo. El contador CRC suele ser el único síntoma que obtendrá antes de que finalmente falle por completo.
FIXNunca use "el enlace está Up" como razón para omitir el método de intercambio — un contador CRC en aumento en una interfaz Up es exactamente el caso para el que existe este método.
SYMPTOMUn puerto muestra Total Error con errores de CRC, Alignments y Symbol en aumento, junto con un gran contador Discard de salida — y el puerto oscila repetidamente entre Up y Down en el registro.
CAUSEEn un caso real, un puerto de conmutador negoció automáticamente hacia abajo a 10Mbit/s semidúplex frente a un peer que esperaba 1000Mbit/s dúplex completo, porque los modos de negociación de ambos extremos no eran coherentes. El propio desajuste produjo los errores de CRC/Alignment/Symbol y el enorme contador de descarte — no hubo ninguna falla de cable u óptica involucrada.
FIXAntes de ejecutar el método de intercambio, verifique los campos Negotiation y Duplex con display interface en ambos extremos. Si no coinciden, fuerce ambos extremos a la misma velocidad y dúplex sin autonegociación en lugar de intercambiar hardware.
<HUAWEI> display interface GigabitEthernet 0/0/5
Duplex: FULL, Negotiation: ENABLE // port working in auto-negotiation mode
// diagnostic log showed CurrDuplex=HALF, Speed=10M during the fault window
[HUAWEI] interface GigabitEthernet 0/0/5
[HUAWEI-GigabitEthernet0/0/5] undo negotiation auto
[HUAWEI-GigabitEthernet0/0/5] speed 1000
// confirm the peer is also forced to the same speed/duplex, non-auto-negotiationSYMPTOMCambia el cable, espera, y revisa display interface — el conteo de CRC sigue siendo distinto de cero, así que la conclusión es que el cable no era el problema después de todo.
CAUSEdisplay interface acumula desde el último reinicio o el último reseteo manual, no desde el momento en que hizo el intercambio. Un conteo distinto de cero después de la corrección puede ser simplemente los errores ocurridos antes de que cambiara algo, todavía presentes en el contador.
FIXEjecute reset counters interface inmediatamente después de cada intercambio, antes de generar cualquier tráfico de prueba — lea el contador solo después de ese reinicio, nunca antes.
SYMPTOMUnos pocos pings de prueba tras un intercambio muestran un contador limpio, así que el paso se marca como resuelto — luego el conteo de CRC vuelve unos días después.
CAUSELas causas intermitentes — un cable bajo estrés mecánico, un presupuesto óptico marginal solo a ciertas temperaturas, EMI que solo aparece bajo un volumen de tráfico real — no necesariamente se manifiestan en una ventana de prueba breve y de bajo tráfico justo después del intercambio.
FIXDeje que cada paso funcione bajo tráfico real de producción durante una ventana significativa — horas, no unos pocos pings — antes de concluir que ese paso resolvió el problema.
SYMPTOMSe ejecuta el Paso 3, se intercambia el puerto peer, y persisten los mismos errores CRC — la conclusión inmediata es un problema de interoperabilidad entre fabricantes.
CAUSELos errores que persisten tras un intercambio de puerto peer sí apuntan a la compatibilidad como explicación principal, pero solo si los Pasos 1 y 2 se completaron realmente de forma limpia primero. Si el puerto local o el enlace nunca se descartó adecuadamente como causa, el resultado del Paso 3 es ambiguo, no concluyente.
FIXSolo interprete el resultado del Paso 3 como compatibilidad una vez que los Pasos 1 y 2 hayan descartado cada uno de forma independiente su elemento — no salte directamente al Paso 3 para ahorrar tiempo.
Extraídas directamente del campo — las que vale la pena tener respondidas de antemano.
Sí, si no tiene ya una razón sólida para sospechar de un elemento específico — el orden prioriza lo más económico y rápido primero. Pero si el mismo cable o módulo óptico ya mostró un problema recientemente en otro par de puertos, es razonable comenzar en el Paso 2 en lugar de repetir el Paso 1 desde cero.
Cualquier puerto del mismo dispositivo que actualmente esté libre de errores bajo tráfico similar sirve como referencia conocida como buena — no necesita ser un tipo de puerto idéntico, solo estar limpio después de reset counters interface.
Sí. Un aumento lento y constante suele ser la señal temprana de un conector en deterioro o un cable acercándose a su límite de radio de curvatura o longitud — exactamente el tipo de cosa que más adelante se convierte en un evento de caída física total si se deja pasar. Detectarlo mientras todavía es solo un incremento lento de CRC es más barato que diagnosticar una falla dura horas después.
No. Si los errores desaparecieron al cambiar solo el cable o la fibra dejando intacto el módulo óptico, el enlace (cable/fibra) es la causa confirmada — el módulo óptico no necesita ser reemplazado ni escalado por separado.
Sí — ejecútelo de forma independiente en ambos extremos, comenzando por el que tenga el conteo de CRC más alto o sea más fácil de acceder. Si ambas direcciones se despejan con el mismo intercambio, ese paso fue casi con certeza la solución. Si se despejan en pasos distintos, puede estar ante dos fallas separadas apiladas en el mismo enlace, no una sola.
Esta nota se basa en el modelo de contador de CRC/error del conmutador Huawei serie S y su flujo de trabajo reset counters interface / display interface, además de los casos de campo detrás de ella. El método subyacente — aislar una variable por intercambio, en un orden fijo de costo — es independiente del fabricante y se traslada directamente a otras plataformas, aunque los comandos exactos cambien. No cubre en profundidad el presupuesto de potencia óptica ni los diagnósticos a nivel de OTDR, y asume que puede acceder físicamente a ambos extremos para intercambiar cosas — un extremo remoto totalmente inaccesible lo limita solo a los Pasos 0 y 1, con los Pasos 2 y 3 necesitando a alguien en el sitio del peer.
Cuéntenos en qué paso está, y qué hizo el contador antes y después, y le ayudamos a interpretarlo.