Diagnóstico de interfaces
El diagnóstico de interfaces permite aislar problemas de conectividad a nivel de puerto, tarjeta o medio físico sin necesidad de acceso CLI al equipo.
[Imagen sugerida: pestaña Interfaces con listado de puertos, estado por color y gráfico de tráfico seleccionado]
Escenario 1: Una interfaz está en estado Down
Paso 1 — Identificar la interfaz
Desde la vista del activo, acceder a la pestaña Interfaces y localizar la interfaz en estado Down. Verificar si es:
- Down (el enlace físico no tiene señal o el dispositivo vecino cayó)
- Admin Down (fue deshabilitada administrativamente)
Si está en Admin Down, el problema no es una falla sino una decisión de configuración. Verificar si fue deshabilitada intencionalmente.
Paso 2 — Verificar el historial de cambios de estado
En la pestaña Interfaces, seleccionar la interfaz y revisar su historial de cambios de estado. Preguntas clave:
- ¿Cuándo exactamente pasó a Down?
- ¿Pasó a Down gradualmente (fue y volvió varias veces) o de golpe?
- ¿Coincide con algún trabajo de mantenimiento, reinicio de un equipo vecino o evento de red?
Paso 3 — Verificar el dispositivo en el otro extremo
Si la interfaz tiene un enlace declarado en NetMonitor, navegar al activo en el otro extremo del enlace y verificar el estado de la interfaz correspondiente.
Si ambas interfaces están Down simultáneamente → el problema puede ser el cableado o el medio físico entre ellas.
Si solo una interfaz está Down → el problema puede ser local a ese activo (falla de puerto, SFP, configuración).
Paso 4 — Inspector de enlace (para enlaces LAN/MAN con fibra)
Si el enlace es de fibra óptica, abrir la vista del enlace desde el módulo de Gestión de Enlaces y ejecutar el inspector:
- Validación DDM: revisar la potencia Rx del SFP. Si está cerca del threshold mínimo o por debajo, hay un problema de señal óptica.
- Validación de atenuación: si la atenuación supera el presupuesto óptico, la fibra tiene un problema (suciedad, rotura, exceso de curvas).
- Validación LLDP: si LLDP ya no detecta al vecino, la conectividad L2 está perdida.
→ Ver Inspector de enlace LAN/MAN
Escenario 2: Una interfaz está en flapping (cambia de estado repetidamente)
El flapping es cuando una interfaz sube y baja repetidamente en intervalos cortos. Es señal de un problema de capa física.
Causas habituales
| Causa | Indicios |
|---|---|
| Conector o SFP sucio o dañado | DDM muestra variación en potencia Rx |
| Cable mal terminado o dañado | Atenuación alta o asimétrica |
| Discrepancia de velocidad/duplex | Errores de FCS o colisiones frecuentes en las métricas |
| Equipo vecino con problema de hardware | El flapping coincide con el estado anómalo del vecino |
| Alimentación inestable en el equipo | Flapping de múltiples interfaces simultáneamente |
Flujo de diagnóstico
- Revisar el historial de cambios de estado de la interfaz: ¿con qué periodicidad sube y baja? ¿Hay un patrón horario?
- Revisar DDM (si es fibra): variaciones en la potencia Rx suelen indicar problemas de conector o fibra.
- Revisar errores Rx/Tx: errores de FCS, CRC o colisiones son indicadores de problema de capa física.
- Revisar el estado de la interfaz vecina (mediante LLDP o CAM) para descartar que el problema sea del equipo en el otro extremo.
Escenario 3: Alta utilización de una interfaz
Umbral de alerta vs. umbral de saturación
Una interfaz con alta utilización no siempre es un problema, pero puede serlo si afecta la calidad del servicio. Interpretar con contexto:
| Utilización | Interpretación |
|---|---|
| 0–70% | Normal. Sin acción requerida. |
| 70–85% | Observar tendencia. Puede requerir planificación de capacidad. |
| 85–95% | Alto. Puede haber degradación del servicio en picos. Revisar con prioridad. |
| 95–100% | Saturado. Hay descartes activos. Requiere acción urgente. |
Flujo de diagnóstico
- Revisar el histograma de tráfico: ¿la alta utilización es continua o es un pico?
- Si es un pico: identificar en qué horario ocurre y correlacionarlo con eventos programados (backup, replica, mantenimiento).
- Si es continua: revisar la caracterización de tráfico (si hay sFlow/NetFlow configurado) para identificar qué aplicaciones o hosts están generando el tráfico.
- Verificar si hay errores o descartes en la interfaz: si hay descartes activos, la cola de la interfaz está llena y se está perdiendo tráfico.
→ Ver Caracterización de tráfico con NetFlow y sFlow
Escenario 4: Errores en una interfaz
Los errores de transmisión en una interfaz (FCS errors, CRC, input errors, output drops) son indicadores de problemas de capa física o de congestión.
Tipos de errores y su significado
| Contador | Causa probable |
|---|---|
| FCS / CRC errors (Rx) | Problema de capa física: cable, SFP, conector, ruido eléctrico |
| Input drops | La CPU del equipo no puede procesar los paquetes entrantes a la velocidad que llegan |
| Output drops | La cola de salida de la interfaz está llena (interfaz saturada) |
| Collisions | Discrepancia de duplex (half-duplex en un extremo, full-duplex en el otro) |
| Runts / Giants | Tramas malformadas: problema de capa física o configuración de MTU |
Flujo de diagnóstico para FCS/CRC errors
- Verificar si los errores son sostenidos o intermitentes.
- Si la interfaz es de fibra: revisar DDM (potencia Rx, temperatura del transceiver, corriente del láser).
- Si la interfaz es de cobre: revisar el estado del cable (si es posible, reemplazar para descartar).
- Verificar la configuración de velocidad y duplex en ambos extremos del enlace.