Ethernet atascado a 100 Mbps: el mito del cable vs la solución real

Qué significa realmente 100 Mbps (y qué no)

Un enlace a 100 Mbps en una NIC y un switch capaces de gigabit rara vez es un “problema de rendimiento” per se. Es un resultado de negociación. Los dos PHY (transceptores de capa física) intentaron ponerse de acuerdo en el mayor denominador común y se conformaron con 100BASE-TX. Eso suele ocurrir por una de cuatro razones:

1. Sólo dos pares funcionan efectivamente (100BASE-TX usa dos pares; 1000BASE-T necesita los cuatro).
2. La autonegociación está rota o desajustada (velocidad/duplex forzado en un extremo; dispositivo intermedio extraño).
3. La configuración del puerto del switch está intencionalmente restringida (política de seguridad, compatibilidad con dispositivos antiguos, mitos de ahorro de energía).
4. El PHY está descontento (errores, rarezas EEE, problemas de driver/firmware, SNR marginal o puerto dañado).

“Simplemente cambia el cable” es reconfortante porque suena mecánico y sin culpables. Pero si sustituyes un cable en un trayecto que incluye un panel de parcheo, una toma keystone, un recorrido en pared, una base de escritorio y un puerto de switch medio muerto, estás haciendo ciencia por sensaciones.

Broma #1: Cambiar cables al azar es como reiniciar impresoras: a veces funciona y nadie sabe por qué, incluida la impresora.

Además: no confundas velocidad de enlace con rendimiento. Puedes tener un enlace de 1 Gbps y aun así obtener 80 Mbps por congestión, CPU, desajuste de MTU, almacenamiento, ventana TCP o un firewall que inspecciona paquetes con la eficiencia de un perezoso. Este artículo trata lo opuesto: el propio enlace está atascado a 100 Mbps.

Guía de diagnóstico rápido (primero/segundo/tercero)

Primero: confirma qué está negociando y dónde

• En el host: confirma la velocidad/duplex negociados realmente y si la autoneg está activada.
• En el switch: confirma qué piensa el switch que hace el puerto y si el puerto está forzado.
• En el trayecto: identifica todo lo que hay entre la NIC y el switch (dock, acoplador en línea, toma de pared, panel de parcheo).

Segundo: aisla el trayecto físico rápidamente

• Mueve el host al switch con un cable corto conocido bueno. Si negocia 1G allí, el problema está en el cableado estructurado o en el hardware intermedio.
• Intercambia el puerto en el switch. Si el problema sigue al puerto, es configuración o hardware del puerto. Si sigue al cable/trayecto, ya aprendiste algo.

Tercero: busca asesinos de negociación

• Desajuste de velocidad/duplex forzado (clásico: switch forzado a 100/full, host en autoneg).
• Interacciones EEE (Energy Efficient Ethernet) en switches baratos, docks y algunas NIC.
• Regresiones de driver/firmware, especialmente en NICs USB y estaciones de acoplamiento.

Si haces estas tres pasadas, normalmente puedes dejar de adivinar en 10–15 minutos y empezar a arreglar.

El mito del cable: por qué es popular y por qué es incompleto

Los cables fallan. Pero “el cable” rara vez es solo un cable. En oficinas y centros de datos, el “cable” es una cadena: patch cord → keystone jack → recorrido en pared → patch panel → patch cord → switch. Cualquiera de esos puntos puede perder un par, introducir diafonía o terminarse tan mal que el gigabit falla pero 100 Mbps sigue caminando.

Aquí está la verdad incómoda: 100BASE-TX es tolerante. Puede funcionar con dos pares útiles y ruido tolerable. 1000BASE-T no lo es. Necesita los cuatro pares y usa un signaling más sofisticado (PAM-5 con cancelación de eco). Eso significa que una sola terminación marginal puede ser invisible a 100 y catastrófica a 1000.

Así que sí, podrías “arreglarlo” reemplazando un patch cord—porque inadvertidamente eliminaste el segmento defectuoso. Pero si el problema real es una mala punzonadura en una toma de pared, solo lanzaste los dados y lo llamaste ingeniería.

Las causas reales: autoneg, pares, errores PHY y rarezas del switch

1) Un par malo (o dos) en el trayecto de cobre

El gigabit necesita los cuatro pares: (1,2), (3,6), (4,5), (7,8). 100 Mbps usa solo (1,2) y (3,6). Si el par (4,5) o (7,8) está abierto, cortocircuitado, intercambiado o apenas hace contacto, la autonegociación suele caer a 100.

Razones comunes:

• Toma keystone punzonada con mal contacto en un par.
• Terminación en el patch panel hecha por alguien que se fue corriendo a comer.
• Cable viejo con dobleces, grapas o curvas cerradas (sí, la gente grapa Ethernet; sí, es tan malo como suena).
• Acopladores en línea y extensores baratos que en realidad no están clasificados como Cat5e/6.

2) Desajuste de autonegociación y ajustes forzados

La autonegociación no es opcional para gigabit en la práctica. El estándar 1000BASE-T espera autoneg para establecer la temporización master/slave y capacidades. Si un lado está forzado y el otro en auto, puedes acabar con 100 Mbps, half-duplex o un enlace intermitente.

Modo de fallo corporativo clásico: alguien forzó 100/full en el switch “por estabilidad” hace años y luego lo olvidó. El puerto se convierte en trampa para cualquier endpoint moderno que espere gigabit.

3) Desajuste de duplex (todavía existe, pero más sigiloso)

El desajuste de duplex es menos común ahora porque auto/auto suele funcionar. Pero aún ocurre con configuraciones forzadas, equipos antiguos o dispositivos intermedios. Los síntomas pueden parecer “el enlace está arriba, pero todo funciona mal”: colisiones tardías altas, mal rendimiento TCP, retransmisiones aleatorias.

4) Energy Efficient Ethernet (EEE) y “funciones” de ahorro

EEE (802.3az) puede funcionar bien. También puede ser una molestia de negociación en algunos chipsets y especialmente en docks/NICs USB. Si ves flaps de enlace o negociación obstinada a 100 Mbps en un trayecto que por lo demás es bueno, probar a desactivar EEE merece los 60 segundos que toma.

5) Docks, NICs USB y adaptadores “útiles”

Los adaptadores Ethernet USB y las estaciones de acoplamiento son milagros de productividad hasta que dejan de serlo. Muchos tienen PHYs marginales, firmware raro y magnetismos de bajo coste. Además introducen más conectores y más puntos de fallo.

Regla: si un portátil mediante dock está atascado a 100 Mbps, prueba el mismo cable con un dispositivo no acoplado conocido bueno o bypassea completamente el dock. No lo debatas. Demuéstralo.

6) Degradación de hardware del puerto del switch o contaminación

Los puertos de los switches pueden dañarse. También puede dañarse el conector RJ-45 de un patch cord que se mueve con frecuencia. En entornos polvorientos, los puertos acumulan residuos que son invisibles hasta que iluminas y te das cuenta de que los contactos parecen haber pasado por una pequeña guerra.

7) Regresiones de driver/firmware

Especialmente en servidores con NICs específicas, una actualización de firmware puede cambiar el comportamiento de autoneg o los valores predeterminados de EEE. En la empresa, esto a menudo aparece después de una ventana de mantenimiento donde “nada relacionado con la red cambió”, salvo que todo cambió.

8) Lo aburrido pero real: políticas y limitación intencional de velocidad

Algunas organizaciones establecen intencionalmente ciertos puertos de acceso a 100 Mbps para reducir el impacto de broadcast, desalentar switches no autorizados o acomodar equipos antiguos. Si estás solucionando, considera siempre que “roto” puede significar “configurado”.

Tareas prácticas (comandos, salidas, decisiones)

Esto no es teoría. Son los movimientos que haces un martes cuando la gente espera y la multitud de “simplemente cambia el cable” merodea.

Tarea 1: Confirma la velocidad/duplex negociados en Linux (ethtool)

cr0x@server:~$ sudo ethtool enp3s0
Settings for enp3s0:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Full
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Advertised link modes:  1000baseT/Full
	                        100baseT/Full
	                        10baseT/Full
	Advertised auto-negotiation: Yes
	Speed: 100Mb/s
	Duplex: Full
	Auto-negotiation: on
	Link detected: yes

Qué significa: La NIC soporta gigabit pero actualmente está a 100/full. La autoneg está activada. Eso apunta a que no es “100 forzado en el host” y sí al cable/trayecto, configuración del switch o al extremo remoto que anuncia solo 100.

Decisión: Comprueba el estado y los contadores del puerto del switch a continuación. Si el switch también informa 100, estás ante un resultado de negociación. Si el switch informa 1000 pero el host muestra 100, tienes un problema de driver/firmware o del lado del host.

Tarea 2: Muestra el estado del enlace rápidamente (ip)

cr0x@server:~$ ip -br link show enp3s0
enp3s0             UP             3c:ec:ef:12:34:56 <BROADCAST,MULTICAST,UP,LOWER_UP>

Qué significa: La interfaz está administrativamente arriba y tiene portadora. Esto no te dice la velocidad, pero indica que no estás depurando un enlace caído.

Decisión: Si falta la portadora (no LOWER_UP), detente e inspecciona la conexión física, el puerto del switch en err-disable o las políticas VLAN antes de tocar ajustes de velocidad.

Tarea 3: Busca mensajes del kernel sobre renegociación de enlace (dmesg)

cr0x@server:~$ sudo dmesg -T | tail -n 12
[Mon Feb  5 10:12:03 2026] e1000e 0000:03:00.0 enp3s0: Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
[Mon Feb  5 10:14:17 2026] e1000e 0000:03:00.0 enp3s0: Link is Down
[Mon Feb  5 10:14:20 2026] e1000e 0000:03:00.0 enp3s0: Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx

Qué significa: El enlace está haciendo flapping. Eso apunta fuertemente a la capa física marginal (cable/terminación/puerto) o a rarezas de ahorro/EEE.

Decisión: Cambia el puerto del switch y bypassea cualquier dock/adapter. Si se estabiliza a 1G con un cable corto conocido bueno, has aislado el cableado estructurado o el dispositivo intermedio.

Tarea 4: Busca errores CRC, de trama y de alineación (ethtool -S)

cr0x@server:~$ sudo ethtool -S enp3s0 | egrep -i 'crc|align|error|drop' | head
     rx_crc_errors: 184
     rx_frame_errors: 0
     rx_errors: 184
     rx_dropped: 3
     tx_errors: 0

Qué significa: Los errores CRC indican tramas corruptas en la capa 2—a menudo un problema de capa física (cable/p pares, EMI, puerto malo) o desajuste de duplex.

Decisión: Si el CRC sube sostenidamente con poca carga, trátalo primero como físico: cable/trayecto/puerto. Si el CRC sube solo con carga y el duplex está desajustado, corrige duplex/autoneg.

Tarea 5: Confirma qué está anunciando la NIC (ethtool advertise)

cr0x@server:~$ sudo ethtool enp3s0 | egrep -A2 'Advertised link modes|Advertised auto'
	Advertised link modes:  1000baseT/Full
	                        100baseT/Full
	                        10baseT/Full
	Advertised auto-negotiation: Yes

Qué significa: El host ofrece 1000/full. Si estás atascado en 100, el extremo remoto puede no estar ofreciendo 1000 (por configuración o limitación), o la capa física impide que el gigabit haga el entrenamiento.

Decisión: Entra al switch y comprueba si el puerto está en auto y si soporta gigabit.

Tarea 6: Fuerza una renegociación sin reiniciar (bajar/subir la interfaz)

cr0x@server:~$ sudo ip link set dev enp3s0 down
cr0x@server:~$ sudo ip link set dev enp3s0 up
cr0x@server:~$ sudo ethtool enp3s0 | egrep 'Speed|Duplex|Auto-negotiation|Link detected'
	Speed: 1000Mb/s
	Duplex: Full
	Auto-negotiation: on
	Link detected: yes

Qué significa: La renegociación tuvo éxito. Eso puede ocurrir cuando el extremo remoto estaba en un estado raro o un dock/NIC tuvo un problema transitorio.

Decisión: Si esto “lo arregla” repetidamente, aún tienes una causa raíz—a menudo EEE, firmware o cableado marginal. No declares victoria hasta que sobreviva a inactividad, carga y algunos eventos de enlace.

Tarea 7: Desactiva EEE temporalmente para probar (ethtool –set-eee)

cr0x@server:~$ sudo ethtool --show-eee enp3s0
EEE Settings for enp3s0:
	EEE status: active
	Tx LPI: enabled
	Rx LPI: enabled
	Supported EEE link modes: 1000baseT/Full
	Advertised EEE link modes: 1000baseT/Full
	Link partner advertised EEE link modes: 1000baseT/Full

cr0x@server:~$ sudo ethtool --set-eee enp3s0 eee off
cr0x@server:~$ sudo ethtool --show-eee enp3s0 | egrep 'EEE status|Tx LPI|Rx LPI'
	EEE status: disabled
	Tx LPI: disabled
	Rx LPI: disabled

Qué significa: EEE está ahora apagado en el lado del host. Si el enlace ahora negocia correctamente y deja de hacer flapping, has encontrado un problema de compatibilidad.

Decisión: Si desactivar EEE lo arregla, considera desactivarlo también en el puerto del switch (o actualizar firmware del dock/NIC). Luego decide si el ahorro de energía vale incidentes recurrentes. Usualmente: no.

Tarea 8: Verifica el modelo/driver de la NIC PCIe (lspci)

cr0x@server:~$ lspci -nnk | grep -A3 -i ethernet
03:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection I219-LM [8086:15d7] (rev 31)
	Subsystem: Dell Device [1028:07a1]
	Kernel driver in use: e1000e
	Kernel modules: e1000e

Qué significa: Conoces el chipset y el driver. Eso importa cuando lo correlacionas con rarezas de negociación conocidas o requisitos de firmware.

Decisión: Si esto es una NIC USB o un chipset menos reputado y ves repetidos 100 Mbps, prueba con otro adaptador. La vida es corta.

Tarea 9: Comprueba errores del lado del switch desde la perspectiva del host (LLDP neighbor)

cr0x@server:~$ sudo lldpctl enp3s0
-------------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------------
Interface:    enp3s0, via: LLDP, RID: 1, Time: 0 day, 00:00:25
  Chassis:
    ChassisID:    mac 00:11:22:33:44:55
    SysName:      access-sw-7f
  Port:
    PortID:       ifname Gi1/0/17
    PortDescr:    GigabitEthernet1/0/17

Qué significa: Has identificado el switch exacto y el puerto sin jugar a “¿qué armario?”.

Decisión: Ahora puedes comprobar esa interfaz específica y sus contadores en el switch. Si LLDP está ausente, puede que estés conectado a través de un dispositivo intermedio tonto (mini-switch, dock, conversor de medios) que no habla LLDP.

Tarea 10: En el switch, comprueba estado de interfaz y negociación (estilo Cisco)

cr0x@server:~$ ssh netops@access-sw-7f "show interfaces gi1/0/17 status"
Port      Name               Status       Vlan       Duplex  Speed Type
Gi1/0/17  user-desk-117      connected    20         a-full  a-100  10/100/1000BaseTX

Qué significa: El switch está de acuerdo: autoneg full duplex, velocidad autoneg pero aterrizó en 100. El puerto es capaz de gigabit, así que la limitación es de negociación/física, no de capacidad del puerto.

Decisión: Revisa los contadores de errores y confirma que el puerto no esté manualmente limitado.

Tarea 11: Revisa contadores del puerto del switch por CRC y errores de entrada (estilo Cisco)

cr0x@server:~$ ssh netops@access-sw-7f "show interfaces gi1/0/17 counters errors"
Port        Align-Err  FCS-Err  Xmit-Err  Rcv-Err  UnderSize  OutDiscards
Gi1/0/17           0      219         0        0          0            0

Qué significa: Los errores FCS coinciden con la historia de CRC del host. Los problemas de capa física ahora son el principal sospechoso.

Decisión: Mueve el endpoint a un cable/puerto conocido bueno; si los errores paran, el trayecto de cable es malo. Si los errores persisten a través de cables, sospecha del hardware del puerto NIC o del puerto del switch.

Tarea 12: Comprueba si el puerto del switch está forzado a 100 (show running-config)

cr0x@server:~$ ssh netops@access-sw-7f "show running-config interface gi1/0/17"
Building configuration...

Current configuration : 162 bytes
!
interface GigabitEthernet1/0/17
 description user-desk-117
 switchport access vlan 20
 spanning-tree portfast
 speed auto
 duplex auto
end

Qué significa: El puerto no está forzado. Si hubieras visto speed 100 o duplex half, tendrías tu respuesta inmediatamente.

Decisión: Si el puerto está forzado, arréglalo (ponlo en auto salvo que tengas una excepción documentada y con dueño). Si está en auto, céntrate en pares del cable, terminaciones, dispositivos intermedios o puertos defectuosos.

Tarea 13: Usa una prueba de paquetes para demostrar rendimiento vs velocidad de enlace (iperf3)

cr0x@server:~$ iperf3 -c 10.20.30.40 -P 4 -t 10
Connecting to host 10.20.30.40, port 5201
[SUM]   0.00-10.00  sec   112 MBytes  94.1 Mbits/sec  0             sender
[SUM]   0.00-10.00  sec   111 MBytes  93.2 Mbits/sec                receiver

Qué significa: Estás tocando el techo de un enlace de 100 Mbps (después de overhead). Esto confirma que el síntoma no es “la app va lenta”; el enlace está genuinamente capado.

Decisión: Para la optimización de capa 4/7. Arregla la negociación del enlace primero.

Tarea 14: Identifica si hay una NIC USB involucrada (lsusb)

cr0x@server:~$ lsusb | grep -i ethernet
Bus 001 Device 006: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter

Qué significa: Estás usando un adaptador USB gigabit. Pueden funcionar bien, pero también son frecuentes causantes de negociaciones raras y rarezas EEE.

Decisión: Prueba con otro adaptador o NIC directa si está disponible. Si el problema desaparece, deja de culpar el cableado del edificio. No era inocente, pero tampoco culpable.

Tarea 15: En Windows, confirma la velocidad negociada (PowerShell)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-NetAdapter | Select-Object Name, Status, LinkSpeed"
Name      Status LinkSpeed
----      ------ ---------
Ethernet  Up     100 Mbps

Qué significa: Windows coincide en 100 Mbps. Esto no es un problema exclusivo del driver de Linux.

Decisión: Revisa cableado, configuración del switch y dispositivos intermedios. Si solo un SO ve 100, céntrate en ajustes de driver (Speed & Duplex, EEE) para ese SO.

Tarea 16: Restablece propiedades avanzadas del adaptador en Windows (Speed & Duplex)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-NetAdapterAdvancedProperty -Name Ethernet | Where-Object DisplayName -Match 'Speed|Duplex' | Select-Object DisplayName, DisplayValue"
DisplayName       DisplayValue
-----------       ------------
Speed & Duplex    Auto Negotiation

Qué significa: El adaptador está en auto, lo cual suele ser correcto. Si esto estuviera forzado a 100, te habrías causado un problema auto infligido.

Decisión: Déjalo en auto salvo que estés depurando un bug conocido. Forzar gigabit en un lado es cómo creas un nuevo incidente mientras “arreglas” el actual.

Tres microhistorias corporativas desde el terreno

Microhistoria 1: El incidente causado por una suposición equivocada

En una empresa mediana con oficina híbrida, el equipo de finanzas se quejó de que “el recurso compartido de archivos va lento”. El equipo de almacenamiento revisó el NAS: discos bien, CPU bien, gráficas de red aburridas. Así que la culpa migró—porque la culpa siempre migra—a “la nueva política de firma SMB” y “actualizaciones de Windows”.

Un administrador junior hizo lo que todos hacen: cambió el cable de parche en el escritorio del usuario. El enlace volvió a 1 Gbps. Ticket cerrado. Todos siguieron. Dos días después, el mismo usuario abrió el mismo ticket. Cable cambiado otra vez. Arreglo temporal otra vez.

Finalmente alguien hizo lo poco glamuroso: trazó el camino. Patch cord de escritorio → toma de pared → patch panel → switch. Moveron el puerto del patch panel del usuario a otro puerto del switch y el problema desapareció para siempre. La causa real fue un único puerto de switch cuyo interfaz física se había vuelto inestable; negociaba a 100 bajo ciertas temperaturas y cargas y ocasionalmente arrojaba errores FCS.

La suposición equivocada fue “es el cable porque cambiarlo ayudó”. La lección real: correlación temporal no es causalidad. El cambio de cable alteró la presión de contacto y reasentó conectores, enmascarando el componente realmente fallando.

Después de retirar el puerto, documentaron una regla: si un problema de 100 Mbps reaparece dos veces en la misma ubicación, deja de cambiar patch cords y empieza a aislar puertos y terminaciones. Esa regla previno futuros déjà vu.

Microhistoria 2: La optimización que se volvió en contra

Otra organización decidió estandarizar puertos de escritorio a 100 Mbps “para reducir tormentas de broadcast y mejorar estabilidad”. Se vendió como una optimización ordenada: menos ruido, menos riesgo, menos tickets. También sonaba deliciosamente decisivo, lo que es catnip en algunas reuniones.

Por un tiempo pareció bien. La mayoría de cargas de oficina no eran ruidosas. Luego la empresa desplegó backups endpoint cifrados por LAN durante la noche. De repente el trabajo nocturno duraba hasta la mañana. Los portátiles seguían subiendo cuando la gente llegaba y el rendimiento interactivo se hundió. Soporte se inundó de “VPN va lenta” y “Wi‑Fi está roto”, porque los usuarios no distinguen métodos de acceso; solo sienten el dolor.

Ingeniería investigó y encontró lo obvio en retrospectiva: algunos endpoints estaban en gigabit y terminaban rápido, otros estaban artificialmente capados a 100 y generaban congestión de larga duración. La red no se volvió más estable. Se volvió más predeciblemente sobrecargada.

El fracaso no fue solo en throughput. Algunos puertos estaban forzados a 100/full mientras los endpoints seguían en auto. Un puñado negoció incorrectamente, resultando en síntomas de desajuste de duplex y tormentas de retransmisiones que parecían “inestabilidad aleatoria de red”.

Terminaron revirtiendo la política: por defecto auto/auto al 1G, y abordaron tormentas de broadcast con controles reales (storm control, segmentación, DHCP snooping, higiene adecuada del switch). La optimización fue un atajo. Los atajos están bien, hasta que se convierten en la vía.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Un equipo de centro de datos tenía una práctica que nadie alardeaba: cada tirada de cobre nueva se certificaba con un probador de cables y se etiquetaba de extremo a extremo, incluyendo IDs de puertos del patch panel. También guardaban un pequeño lote de patch cords cortos conocidos buenos, sellados en una caja, usados solo para troubleshooting.

Una tarde, un nuevo rack de servidores entró en línea y la mitad de los nodos negociaron a 100 Mbps. El caos habitual intentó formarse. Pero el equipo tenía recibos: el cableado horizontal estaba certificado y los patch cords usados en despliegue eran de un lote nuevo sin validar.

Sacaron un servidor con un cordón conocido bueno de la caja sellada: 1 Gbps al instante. Probaron algunos cords del lote nuevo: varios tenían pares fallando. No “baja calidad”—realmente defectuosos.

Porque el equipo tenía etiquetas de extremo a extremo y registros de certificación, la resolución no degeneró en discusión. Aislaron la variable, lo confirmaron, reemplazaron todo el lote y siguieron adelante. Sin heroicidades. Sin noche en vela.

Ese es el punto de las prácticas aburridas: no te hacen sentir listo. Te hacen sentir hecho.

Errores comunes: síntoma → causa raíz → solución

1) “Es Cat5, así que no puede hacer gigabit”

Síntoma: El enlace negocia a 100; alguien señala la chaqueta del cable.

Causa raíz: Confusión entre la clasificación de categoría y la calidad real de la instalación. Muchos tramos Cat5 pueden hacer gigabit a corta distancia; muchos tramos Cat5e fallan en gigabit por malas terminaciones.

Solución: No discutas por la etiqueta. Prueba moviendo a un cable corto conocido bueno directamente al switch. Si eso da 1G, certifica el cableado estructurado o re-termina la toma/panel.

2) “Forzar la velocidad arregla problemas de negociación”

Síntoma: Alguien fuerza 1000/full en el host o switch; el enlace se vuelve inestable o se queda en 100.

Causa raíz: En la práctica, el gigabit espera autoneg. Forzar un lado puede romper el acuerdo master/slave y provocar retrocesos silenciosos.

Solución: Usa auto/auto salvo que estés trabajando alrededor de un bug documentado—y entonces arregla el bug, no vivas eternamente con la solución temporal.

3) “No hay errores en los logs de la app, así que no es la red”

Síntoma: Usuarios reportan lentitud; la app parece bien; el enlace está a 100.

Causa raíz: La red funciona, solo está capada. Muchas apps no registran “tu NIC negociò mal hoy”.

Solución: Comprueba la velocidad negociada primero. Es más rápido que leer logs de aplicaciones sobre los que no puedes actuar.

4) “Debe ser el switch, los switches son malvados”

Síntoma: Múltiples endpoints en diferentes puertos muestran 100 Mbps, de forma intermitente.

Causa raíz: A menudo un lote de patch cords defectuosos, una fila de patch panel dudosa o un nuevo modelo de dock desplegado.

Solución: Identifica la comunidad: mismo patch panel, mismo dock, mismo lote de cables. Usa LLDP para localizar puertos y correlacionar.

5) “El Wi‑Fi es más rápido que el cable aquí”

Síntoma: El portátil obtiene mejores velocidades por Wi‑Fi que por cable.

Causa raíz: El cableado está atascado a 100 por pares/negociación; el Wi‑Fi se conecta a mayores tasas PHY y tiene mejor throughput en ese momento.

Solución: Trátalo como un problema de cableado/puerto, no como una condena al concepto Ethernet.

6) “Es full duplex, así que no puede ser físico”

Síntoma: Duplex muestra full en ambos extremos; aun así 100 Mbps y ocurren errores.

Causa raíz: Full duplex puede existir a 100 mientras el entrenamiento gigabit falla por un par faltante o SNR pobre.

Solución: Busca errores CRC/FCS y aísla segmentos de cable. Full duplex no es un certificado de salud.

7) “El puerto dice GigabitEthernet, así que es gigabit”

Síntoma: El nombre del switchport implica gigabit; la velocidad negociada es 100.

Causa raíz: La capacidad del puerto no es el resultado. El enlace elige lo que puede soportar con fiabilidad.

Solución: Comprueba la velocidad negociada real en ambos extremos y qué se anuncia. Luego arregla la razón por la que la negociación no llega a 1000.

8) “Cambiamos el cable dos veces; no es cableado”

Síntoma: Múltiples cambios de cable no ayudaron.

Causa raíz: El cable no es el único componente físico. La toma, el panel y el puerto importan. Además: la gente sigue usando el mismo repuesto cuestionable del cajón de “cables varios”.

Solución: Usa un patch cord conocido bueno y probado, bypassea dispositivos intermedios y mueve puertos. Trata la resolución como aislamiento, no como ritual.

Listas de verificación / plan paso a paso

Paso a paso: aisla el problema en 20 minutos

1. Confirma el síntoma: ejecuta ethtool (Linux) o Get-NetAdapter (Windows) y registra velocidad/duplex/autoneg.
2. Identifica el puerto del switch: usa LLDP si está disponible; de lo contrario traza vía tablas MAC (pide a NetOps si es necesario).
3. Revisa configuración del switchport: asegura que velocidad/duplex estén en auto salvo que haya una excepción documentada.
4. Revisa contadores del switchport: FCS/CRC apuntan a físico; contadores limpios apuntan a configuración o endpoint.
5. Bypassea intermedios: quita docks, acopladores, extensores en línea y placas de pared si es posible.
6. Cable corto conocido bueno al switch: esto es la prueba de aislamiento físico más rápida.
7. Cambia de puerto en el switch: muévete a otro puerto con configuración conocida buena y observa la negociación.
8. Prueba con otro endpoint: si otro host negocia 1G en el mismo cable/trayecto, el NIC/dock original es sospechoso.
9. Desactiva EEE como prueba: si lo arregla, decide un cambio permanente de configuración.
10. Documenta la causa raíz: “patch cable malo” es aceptable solo si puedes reproducir la falla con ese cable en otro sitio o validarlo con un tester.

Checklist operacional: qué estandarizar para que esto deje de pasar

• Mantén un set sellado de patch cables cortos conocidos buenos solo para troubleshooting.
• Exige certificación (o al menos prueba de continuidad de pares) para nuevas tiradas estructuradas y trabajo en paneles de parcheo.
• Por defecto deja los puertos de acceso del switch en auto/auto y documenta cualquier excepción forzada con razón y dueño.
• Registra modelos de docks/NIC USB y versiones de firmware; trátalos como dispositivos de red, porque lo son.
• Alerta sobre contadores de error de switchport (FCS, input errors) y flaps de enlace; “100 Mbps” a menudo es precedido por inestabilidad física.

Hechos e historia que realmente ayudan

• 100BASE-TX usa dos pares; 1000BASE-T usa cuatro. Un solo par muerto suele significar “100 Mbps para siempre”.
• 10BASE-T y 100BASE-TX a menudo pueden sobrevivir a cableado feo; el gigabit es menos tolerante porque envía más bits por el mismo cobre.
• La autonegociación se volvió esencial conforme aumentaron las velocidades. Los días en que podías forzar ajustes en todas partes sin consecuencias ya terminaron en la mayoría de entornos.
• Ethernet sobre par trenzado fue diseñada para ser barata y resiliente, por eso funciona en paredes de oficina y terminaciones cuestionables.
• Las etiquetas de categoría no garantizan rendimiento. La calidad de la instalación (radio de curvatura, terminación, diafonía) suele dominar el resultado real.
• El gigabit por cobre usa cancelación de eco y DSP sofisticado. Por eso los PHY pueden “entrenar” y decidir que el canal no es suficientemente bueno.
• EEE (802.3az) llegó para ahorrar energía en reposo. En algunas combinaciones de dispositivos también llegó para crear “flaps misteriosos”.
• El nombre del switchport puede engañar. “GigabitEthernet” es una capacidad, no una garantía de velocidad negociada.
• Los patch cords fallan más de lo que la gente espera porque se doblan, son aplastados por sillas y se cambian constantemente—su vida es más dura que la del cable en pared.

Una idea para la confiabilidad parafraseada de W. Edwards Deming encaja perfectamente en networking: ideas parafraseadas — “Sin datos, solo eres otra persona con una opinión.” — W. Edwards Deming

Broma #2: La autonegociación es como la diplomacia: cuando ambas partes se niegan a hablar, todos vuelven a acuerdos antiguos.

Preguntas frecuentes

¿Por qué un cable malo a menudo aún funciona a 100 Mbps?

Porque 100BASE-TX necesita solo dos pares y tolera condiciones de señal más marginales. El gigabit necesita los cuatro pares y mejores características de canal.

Si tengo Cat6, ¿por qué sigo atascado a 100?

Porque la clasificación de categoría no es lo mismo que un camino correctamente terminado e intacto. Un patch cord Cat6 enchufado en una keystone mal punzonada sigue siendo una keystone mal punzonada.

¿Forzar 1000 Mbps es una solución válida?

Casi nunca. Forzar ajustes es una buena herramienta de diagnóstico solo si entiendes ambos extremos y puedes revertir con seguridad. En producción, auto/auto es la opción por defecto por una razón.

¿Podría ser un desajuste de duplex siquiera si ambos extremos dicen “full”?

Si ambos extremos realmente negocian full y coinciden, el desajuste de duplex es poco probable. Pero si un extremo está forzado y el otro en auto, el lado en auto puede detectar mal el duplex. Verifica siempre la configuración de ambos extremos, no solo la lectura actual.

¿Cuál es la forma más rápida de demostrar que no es el switch?

Lleva el endpoint al switch y usa un cable corto conocido bueno. Si negocia 1G allí, probablemente el switch está bien y el trayecto de cableado estructurado no.

¿Realmente los docks y adaptadores USB causan negociación a 100 Mbps?

Sí. Pueden tener PHYs peores, quirks de firmware y más puntos físicos de conexión. Prueba bypassear el dock/adaptador y compara resultados.

¿Cómo sé si un puerto de switch está configurado para limitar a 100?

Revisa la configuración en ejecución para esa interfaz. En muchos switches verás explícito speed 100 o similar. Si está auto pero aún en 100, el puerto reacciona a condiciones de negociación/físicas.

Mi enlace es 1 Gbps pero el rendimiento sigue siendo malo. ¿Está relacionado?

Problema distinto. Ahora miras congestión, offload de CPU, desajustes MTU, cuellos de botella de almacenamiento, pérdida de paquetes o límites a nivel de aplicación. No persigas arreglos de 100 Mbps cuando ya tienes 1 Gbps.

¿Un solo pin doblado en un conector RJ-45 puede causar esto?

Sí. Contactos doblados o contaminados pueden cortar un par intermitentemente. El enlace puede estabilizarse en 100 Mbps porque el entrenamiento gigabit falla. Inspecciona y prueba con componentes conocidos buenos.

¿Es seguro desactivar EEE en todas partes?

Generalmente sí en redes de acceso empresariales, especialmente si has observado problemas. El ahorro de energía suele ser pequeño comparado con el costo operativo de enlaces inestables. Valida según la mezcla de hardware.

Conclusión: siguientes pasos que no te hagan perder el día

Si tu enlace Ethernet está atascado a 100 Mbps, no empieces por el folclore. Empieza por la evidencia.

1. Comprueba velocidad/duplex/autoneg negociados en el host y el switch.
2. Identifica el puerto exacto del switch (LLDP ayuda) y revisa contadores por CRC/FCS.
3. Aísla el trayecto con un cable corto conocido bueno directamente al switch; bypassea docks e intermedios.
4. Si es físico, arregla lo físico: re-termina la toma/panel, reemplaza el lote de patch cords defectuosos o retira el puerto que falla.
5. Si es configuración, normaliza a auto/auto y documenta excepciones como documentarías una regla de firewall: con dueño y razón.

El objetivo no es “lograr 1G una vez”. El objetivo es que se mantenga a 1G a través de reinicios, eventos de enlace y de la próxima persona que “ordene” el armario.