Ethernet: qué ocurre realmente en la capa de enlace
Ethernet (IEEE 802.3) define cómo se envían tramas dentro de una red local (LAN) usando direcciones MAC. En una LAN conmutada, la entrega se decide por la MAC de destino y por la información que el switch aprende al observar el tráfico.
Dirección MAC (Media Access Control)
Una MAC suele representarse como 6 bytes (48 bits) en hexadecimal, por ejemplo 00:1A:2B:3C:4D:5E. En Ethernet, la MAC se usa para identificar interfaces dentro del mismo dominio de broadcast (por ejemplo, dentro de una VLAN). Puntos clave:
- Unicast: destino a una MAC específica.
- Broadcast: destino
FF:FF:FF:FF:FF:FF(llega a todos en la LAN/VLAN). - Multicast: destino a un grupo (MAC con bit I/G activado).
Trama Ethernet (visión práctica)
Sin entrar en historia, conviene reconocer los campos que afectan a la conmutación:
- MAC destino y MAC origen: el switch decide el puerto de salida mirando la MAC destino y aprende con la MAC origen.
- EtherType/Longitud: indica el tipo de carga útil (por ejemplo, IPv4, IPv6, ARP).
- FCS: verificación de errores (CRC). Si falla, la trama se descarta.
Switching: cómo un switch decide por dónde reenviar
Tabla CAM (MAC Address Table)
Un switch mantiene una tabla (comúnmente llamada CAM o tabla MAC) que asocia MAC → puerto (y normalmente también VLAN). Ejemplo conceptual:
| VLAN | MAC | Puerto | Edad |
|---|---|---|---|
| 10 | 00:1A:2B:3C:4D:5E | Gi0/3 | 120s |
| 10 | 8C:85:90:AA:BB:CC | Gi0/7 | 15s |
La tabla no es eterna: las entradas envejecen (aging) y se eliminan si no se ven tramas de esa MAC durante un tiempo.
- Escuche el audio con la pantalla apagada.
- Obtenga un certificado al finalizar.
- ¡Más de 5000 cursos para que explores!
Descargar la aplicación
Aprendizaje (learning)
Cuando una trama entra por un puerto, el switch observa la MAC origen y registra: “esa MAC está detrás de este puerto (en esta VLAN)”. Esto ocurre de forma automática.
Ejemplo: si el host A envía una trama y entra por Gi0/3, el switch aprende MAC_A → Gi0/3.
Reenvío (forwarding) y filtrado (filtering)
Con la tabla CAM, el switch toma decisiones:
- Si conoce la MAC destino: reenvía la trama solo por el puerto asociado (unicast).
- Si la MAC destino está en el mismo puerto de entrada: filtra (no reenvía) porque ya está “del mismo lado”.
Flooding (cuando no sabe a dónde ir)
Si el switch no conoce la MAC destino (unicast desconocido), hace flooding: envía la trama por todos los puertos de esa VLAN excepto el puerto de entrada. Esto también ocurre con broadcast y, según configuración, con ciertos multicast.
El flooding es normal en el arranque de la comunicación (por ejemplo, al inicio de una conversación entre dos equipos que aún no están en la tabla), pero un exceso puede indicar problemas (bucles, tormentas de broadcast, aprendizaje inestable).
Colisiones: qué eran y por qué disminuyen con switching
Las colisiones ocurren cuando dos dispositivos transmiten al mismo tiempo en un medio compartido (típico de hubs o Ethernet half-duplex). En redes modernas con switches:
- Cada puerto del switch es un dominio de colisión independiente.
- Con full-duplex (lo habitual), no hay colisiones porque se transmite y recibe simultáneamente por pares separados.
Por eso, al pasar de hub a switch, las colisiones disminuyen drásticamente: ya no compites por un único medio compartido, sino que cada enlace es punto a punto.
Negociación de velocidad y dúplex (autonegotiation)
En Ethernet, los extremos del enlace (NIC y switch) suelen negociar automáticamente:
- Velocidad: 10/100/1000/2500/5000/10000 Mbps (según hardware).
- Dúplex: half o full (en la práctica, full).
Buenas prácticas:
- Deja auto/auto en ambos extremos cuando sea posible (especialmente en 1G/10G), para evitar incompatibilidades.
- Si necesitas fijar manualmente, fija ambos extremos con los mismos valores.
Dúplex mismatch: el fallo clásico
Un dúplex mismatch ocurre cuando un lado está en full-duplex y el otro en half-duplex. Síntomas típicos:
- Rendimiento muy bajo e intermitente.
- Errores de capa 2 y retransmisiones a nivel superior.
- En el lado half-duplex: colisiones/late collisions.
- En el lado full-duplex: errores como FCS/CRC y drops (según plataforma).
Cableado y conectores comunes en Ethernet
Par trenzado (cobre): UTP/STP y RJ45
En servidores y switches de acceso es común usar cobre con conector RJ45. Categorías habituales:
- Cat5e: común para 1Gbps (y a veces 2.5Gbps en distancias cortas).
- Cat6: mejor margen, común en instalaciones nuevas.
- Cat6a: recomendado para 10Gbps hasta 100 m.
Detalles prácticos:
- La distancia típica máxima en cobre para Ethernet es 100 m (90 m de enlace permanente + 10 m de latiguillos).
- Un mal crimpado, pares mal ordenados o exceso de tensión mecánica puede causar errores intermitentes.
Fibra óptica y módulos (SFP/SFP+/QSFP)
En enlaces de distribución o servidores con NICs avanzadas se usa fibra con transceptores:
- SFP (1G), SFP+ (10G), QSFP (40G/100G, según variante).
- Conectores comunes: LC (muy frecuente), SC (menos en entornos modernos).
Problemas típicos: polaridad TX/RX invertida, tipo de fibra incorrecto (multimodo vs monomodo), suciedad en conectores.
MTU: tamaño máximo de trama y su impacto
MTU (Maximum Transmission Unit) es el tamaño máximo de carga útil que una interfaz puede transportar en una trama sin fragmentación a niveles superiores. En Ethernet, el valor típico es 1500 bytes (para la carga útil de capa superior). Existen jumbo frames (por ejemplo, MTU 9000) en redes que lo soportan.
Qué pasa si la MTU no coincide
- Si un enlace o dispositivo intermedio tiene una MTU menor, los paquetes grandes pueden fragmentarse (en algunos escenarios) o fallar (por ejemplo, cuando se depende de PMTUD y hay filtrado de ICMP).
- Los síntomas suelen ser: conexiones que “se quedan colgadas”, transferencias que se cortan, o rendimiento anómalo solo para ciertos tamaños.
Cuándo considerar jumbo frames
Puede ser útil en almacenamiento, virtualización o tráfico este-oeste intenso, pero requiere consistencia: NIC + switch + toda la ruta deben soportar la misma MTU. Si no, introduces fallos difíciles de diagnosticar.
Bloque práctico: diagnóstico físico y validación desde el sistema operativo
Paso 1: interpretar indicadores físicos (link up/down)
En NICs y puertos de switch suelen existir LEDs:
- Link: indica si hay enlace físico (cable conectado, señal válida).
- Activity: parpadea con tráfico.
- Speed (a veces por color): sugiere 10/100/1000/10G según el fabricante.
Acciones rápidas:
- Si está link down: prueba otro puerto, otro cable, revisa que el transceptor (SFP) esté bien asentado, y verifica que el equipo remoto esté encendido y habilitado.
- Si hay link pero no hay tráfico: revisa VLAN/puerto, configuración del host, o si el switch está bloqueando (por ejemplo, seguridad de puerto, STP, etc., según aplique).
Paso 2: errores comunes y cómo reconocerlos
- Cable defectuoso o mala terminación: link intermitente, renegociaciones, errores CRC/FCS, baja velocidad negociada (por ejemplo, cae a 100 Mbps).
- Dúplex mismatch: rendimiento errático, errores y colisiones/late collisions en el lado half.
- MTU inconsistente: ciertos servicios fallan solo con cargas grandes; pings pequeños funcionan, pings grandes fallan.
Paso 3: validar desde Linux (comandos esenciales)
1) Ver estado del enlace y velocidad/dúplex
ip link show dev eth0ethtool eth0Qué mirar en ethtool:
Link detected: yes/noSpeedyDuplex- Si
Auto-negotiationestá on/off
2) Ver contadores de errores
ip -s link show dev eth0Observa incrementos en RX/TX errors, dropped, overruns. Para detalle por driver:
ethtool -S eth0Busca contadores como CRC/FCS, alignment errors, symbol errors (nombres varían por NIC).
3) Probar MTU con ping sin fragmentación
ping -M do -s 1472 192.0.2.10En Ethernet con MTU 1500, -s 1472 + 28 bytes de cabeceras ICMP/IP = 1500. Si falla, reduce el tamaño hasta que funcione para estimar la MTU efectiva del camino.
Paso 4: validar desde Windows (comandos esenciales)
1) Estado del adaptador y negociación
Get-NetAdapter | Format-Table -Auto Name, Status, LinkSpeed2) Contadores y estadísticas
Get-NetAdapterStatistics -Name "Ethernet"3) Probar MTU con ping
ping 192.0.2.10 -f -l 1472Si falla con -f (don’t fragment), reduce -l para encontrar el máximo que pasa.
Paso 5: correlacionar con el switch (contadores de interfaz)
En el switch, la validación típica consiste en revisar el estado del puerto y sus contadores. Aunque el comando exacto depende del fabricante, el objetivo es el mismo:
- Estado: up/down, velocidad, dúplex, errores.
- Errores: CRC/FCS, drops, input errors, collisions/late collisions (si aplica), flaps (cambios de estado).
Flujo recomendado:
- Si el host muestra CRC en RX, revisa el cableado o el puerto del switch (y viceversa).
- Si hay sospecha de dúplex mismatch, confirma velocidad/dúplex en ambos extremos y corrige para que coincidan.
- Si el enlace negocia a menor velocidad de la esperada, prueba otro cable/categoría, evita adaptadores intermedios y valida que el puerto soporte esa velocidad.