CCNA v2.0

CCNA v2.0/Módulo 2 · Capa física y Ethernet

0% del curso completado

Lectura

Diagnóstico de interfaces y cableado (1.1)

📋 En esta lección

Un enlace que "funciona" puede estar degradado sin dar errores evidentes. Aquí aprendes a leer la salida de show interfaces como un experto: entender el estado de la interfaz, interpretar los contadores de error, y diagnosticar los problemas más comunes de capa 1 y capa 2 antes de que se conviertan en una llamada de emergencia a las 3 de la mañana.

La filosofía del diagnóstico en capas

Cuando una conexión falla o va lenta, el instinto de mucha gente es mirar la configuración IP. Error clásico. El modelo OSI dice: empieza por la capa más baja. Si la capa 1 (física) está rota, ninguna configuración de capa 3 te va a salvar.

El orden correcto:

¿Tiene conexión física? (¿LED encendido? ¿Cable bien enchufado?)
¿Está el enlace up/up? (show interfaces)
¿Hay errores de capa 2? (CRC, runts, giants, late collisions)
¿La VLAN es la correcta? (show interfaces trunk, show vlan brief)
¿Hay conectividad L3? (ping, show ip arp)

Esta lección cubre los pasos 1, 2 y 3. Los pasos 4 y 5 vienen en módulos posteriores.

`show interfaces` — la navaja suiza del diagnóstico

El comando más importante para diagnosticar interfaces en Cisco IOS es show interfaces. Veamos su salida completa y qué significa cada línea:

Switch# show interfaces GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  Hardware is Gigabit Ethernet, address is 001a.2b3c.4d5e (bia 001a.2b3c.4d5e)
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX
  input flow-control is off, output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:02, output 00:00:01, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 1000 bits/sec, 2 packets/sec
  5 minute output rate 500 bits/sec, 1 packets/sec
     12345 packets input, 1234567 bytes, 0 no buffer
     Received 500 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 500 multicast, 0 pause input
     12000 packets output, 1200000 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out

La línea de estado: el primer diagnóstico

La primera línea de show interfaces es la más importante:

GigabitEthernet0/1 is up, line protocol is up

Hay cuatro combinaciones posibles:

Estado de interfaz	Estado del protocolo	Significado
`up`	`up`	✅ Enlace operativo — capa 1 y capa 2 funcionan
`up`	`down`	⚠️ Señal física pero sin keepalives — problema de protocolo (encapsulación, VLAN, etc.)
`down`	`down`	❌ Sin señal física — cable desconectado, otro extremo apagado, cable defectuoso
`administratively down`	`down`	🔒 Puerto apagado por configuración (`shutdown`) — no es un fallo, es intencional

⚡ down/down vs admin down

La diferencia importa. Si ves administratively down, alguien ejecutó shutdown en ese puerto. Si ves simplemente down, line protocol is down, el problema es físico: cable, conector, dispositivo apagado, o incompatibilidad de medio. Revisa el hardware antes de tocar la configuración.

Contadores de error: qué buscar

Los contadores son acumulativos desde el último clear counters o reinicio. Nunca son perfectamente cero en el mundo real — lo que importa es si crecen activamente durante tu diagnóstico.

Input errors y sus subcategorías

Runts (tramas pequeñas): tramas de menos de 64 bytes. Indican colisiones (en entornos half-duplex) o hardware defectuoso. En un enlace full-duplex no deberían existir. Un contador de runts que crece apunta a mismatch de dúplex o cable con impedancia incorrecta.

Giants (tramas grandes): tramas de más de 1518 bytes (sin VLAN) o 1522 bytes (con 802.1Q). Pueden indicar un dispositivo mal configurado con jumbo frames, o problemas de hardware. En sí mismos no son dramáticos a menos que sean muchos.

CRC errors: la suma de comprobación FCS de la trama no coincide con lo calculado por el receptor. La trama se descarta. Causas habituales:

Cable de categoría insuficiente para la velocidad configurada
Cable dañado (aplastado, doblado en ángulo agudo, con el conector mal crimpado)
Interferencia electromagnética
Duplex mismatch

Input errors: suma total de runts + giants + CRC + frame + overrun + ignored. Un número alto con muchos CRC apunta a capa física. Un número alto con muchos runts en full-duplex apunta a duplex mismatch.

Frame errors: tramas con tamaño correcto pero no alineadas al límite de byte (número impar de bits). Casi siempre indica un problema de capa física.

Output errors y sus subcategorías

Output errors: número de tramas que el switch intentó transmitir y falló. En condiciones normales debería ser 0.

Collisions: en full-duplex no deberían existir. Si ves colisiones en un enlace supuestamente full-duplex, el problema es el dúplex mismatch — un lado está en half-duplex.

Late collisions: colisiones detectadas después del primer bit 64 (después de que el proceso de detección de colisiones CSMA/CD debería haber terminado). Son el síntoma más claro de duplex mismatch: el lado half-duplex sigue transmitiendo después de que el lado full-duplex ya empezó su frame, y se detecta tarde. Un contador de late collisions creciendo = busca mismatch de dúplex.

Interface resets: la interfaz se reinició (fue reseteada por el software). Puede ocurrir por keepalive failures, desbordamiento de colas o problemas de hardware.

Diagnóstico de dúplex mismatch: caso práctico

Escenario: un servidor se queja de que la red "va lenta". El ping funciona pero la transferencia de archivos grandes es miserable.

Switch# show interfaces GigabitEthernet0/5
GigabitEthernet0/5 is up, line protocol is up
  Full-duplex, 1000Mb/s
  ...
     0 runts, 0 giants, 0 throttles
     127 input errors, 127 CRC, 0 frame, 0 overrun, 0 ignored
     ...
     0 output errors, 0 collisions, 0 interface resets
     0 babbles, 45 late collision, 0 deferred

El switch dice Full-duplex. Pero hay 127 CRCs y 45 late collisions. Esto es una contradicción — en full-duplex no debería haber late collisions. Lo que está pasando:

El switch negoció full-duplex.
La NIC del servidor, por algún motivo (driver antiguo, configuración manual errónea), está en half-duplex.
El servidor detiene su transmisión cuando detecta que el switch también está transmitiendo (CSMA/CD half-duplex).
El switch (full-duplex) no sabe que el servidor está esperando y sigue transmitiendo.
Resultado: los frames del servidor se "mezclan" con los del switch → CRC errors en el switch, late collisions en el servidor.

Solución: forzar manualmente la misma velocidad y dúplex en ambos extremos, o dejar autonegociación activa en los dos.

! Forzar a full-duplex y 1Gbps en el puerto del switch:
Switch(config)# interface GigabitEthernet0/5
Switch(config-if)# duplex full
Switch(config-if)# speed 1000

! O dejar autoneg (recomendado si el extremo la soporta correctamente):
Switch(config-if)# duplex auto
Switch(config-if)# speed auto

`show interfaces status` — la vista de resumen

Para ver el estado de todos los puertos a la vez, sin el detalle de contadores:

Switch# show interfaces status

Port      Name               Status       Vlan       Duplex  Speed Type
Gi0/1                        connected    1          a-full  a-1000 10/100/1000BaseTX
Gi0/2                        connected    10         a-full  a-1000 10/100/1000BaseTX
Gi0/3                        notconnect   1            auto   auto 10/100/1000BaseTX
Gi0/4                        disabled     1            auto   auto 10/100/1000BaseTX

a-full y a-1000: la a- indica que se negoció automáticamente (autoneg).
connected: enlace up.
notconnect: sin conexión física — cable desenchufado o extremo apagado.
disabled: shutdown aplicado — apagado administrativamente.

💡 💡 Interpretación rápida de show interfaces status

Si un puerto muestra notconnect y debería estar conectado: empieza por lo más tonto — ¿está el cable bien enchufado en ambos extremos? ¿El LED del puerto está encendido? Si el cable parece bien, prueba con otro cable.

`show mac address-table` — validar que el switch ve el dispositivo

Si el enlace está up/up pero el dispositivo no aparece en la red:

Switch# show mac address-table interface GigabitEthernet0/1
          Mac Address Table
-------------------------------------------
Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
   1    001a.2b3c.4d5e    DYNAMIC     Gi0/1

Si no aparece ninguna MAC: el dispositivo no está transmitiendo nada o hay un problema de VLAN (el Puerto puede estar en la VLAN equivocada). Si aparece la MAC pero el ping falla, el problema es de capa 3 o superior.

Limpiando contadores para medir en tiempo real

Los contadores son acumulativos desde el inicio o el último clear. Para medir si los errores están ocurriendo ahora:

Switch# clear counters GigabitEthernet0/1
Clear "show interface" counters on this interface [confirm]

! Espera 1-2 minutos, luego:
Switch# show interfaces GigabitEthernet0/1

Si los contadores de CRC o late collisions vuelven a subir rápidamente, el problema está activo en este momento.

Problemas comunes y su diagnóstico rápido

Síntoma	`show interfaces` dice	Causa probable	Solución
Sin conectividad	`down, down`	Cable desconectado o roto	Verificar cable y extremos
Puerto bloqueado administrativamente	`administratively down`	`shutdown` en configuración	`no shutdown` en el puerto
Rendimiento pésimo sin errores evidentes	`up, up` pero late collisions	Duplex mismatch	Forzar dúplex igual en ambos extremos
Muchos CRC, rendimiento bajo	`up, up`, CRC alto	Cable dañado o mala categoría	Reemplazar cable, verificar conector
`up, up` pero sin tráfico de datos	`up, up`, contadores de broadcast altos	VLAN incorrecta	Verificar VLAN de acceso

Relación con otros conceptos

Los errores de CRC y runts son problemas de capa 1 — el cableado es el primer sospechoso (lección 2.1).
El duplex mismatch es un problema de la trama Ethernet (capa 2) — lo estudiaste en la lección 2.2.
La tabla MAC (show mac address-table) complementa el diagnóstico — la explicamos en la lección 2.3.
Las VLANs añaden otra dimensión al diagnóstico de L2 — las estudiaremos en el Módulo 5.

Resumen

show interfaces te da todo lo que necesitas para diagnosticar capas 1 y 2: la línea de estado (up/up, down/down, administratively down), la velocidad y dúplex negociados, y los contadores de error. Los CRC indican problemas de cabling o de señal. Las late collisions indican mismatch de dúplex (un extremo full, el otro half). Los runts en full-duplex también apuntan a mismatch. show interfaces status da la vista de resumen de todos los puertos. clear counters te permite medir si el problema está activo ahora mismo. Empieza siempre por la capa más baja antes de subir a IP.

Fuentes oficiales

← Anterior

Lab · Ver aprender al switch