¿Tu conexión se corta, un puerto solo enlaza a 100 Mbps o hay lentitud aunque el MikroTik parece funcionar correctamente? Antes de cambiar reglas o reiniciar equipos, revisa sus interfaces: pueden darte pistas sobre el cableado, la capacidad del enlace y el lugar donde comienza el problema.
En esta guía aprenderás a detectar y resolver fallas en interfaces de MikroTik mediante Winbox y la terminal. Nos centraremos en puertos Ethernet y SFP/SFP+, y veremos cuándo conviene continuar el diagnóstico en el bridge, las VLAN o la configuración IP.
1. Clasificación de las principales fallas
| Tipo de falla | Síntoma habitual | Primera revisión |
|---|---|---|
| Física | Puerto sin enlace, cortes o tramas dañadas. | Cable, conectores, alimentación, puerto y equipo remoto. |
| Negociación | Enlace a una velocidad inferior a la esperada. | Capacidad de ambos extremos y velocidad negociada. |
| Capacidad y congestión | Lentitud o pérdida durante horas de mayor consumo. | Tráfico por dirección, descartes, colas y CPU. |
| Capa 2 | Tormentas de tráfico o equipos inaccesibles dentro de la LAN. | Bucles, bridge, VLAN y topología. |
| Configuración IP o servicios | El enlace está activo, pero no hay navegación o falla una aplicación. | Direcciones, rutas, DNS, firewall, NAT y MTU. |
| Óptica | Enlace de fibra caído o inestable. | Transceptores, conectores y presupuesto óptico. |
Esta clasificación orienta las pruebas; no sustituye la confirmación. Por ejemplo, una desconexión puede deberse tanto a un cable defectuoso como al reinicio del dispositivo remoto.
2. Dónde revisar la información en Winbox
- Ingresa a Interfaces e identifica el puerto afectado.
- Abre la interfaz con doble clic.
- Revisa su estado, velocidad y dúplex en las secciones de Ethernet o estado.
- Consulta las pestañas de estadísticas de recepción y transmisión.
- Observa la gráfica de tráfico mientras se reproduce el problema.
- Consulta Log para relacionar los cortes con otros eventos.
La distribución y los nombres de las pestañas pueden variar según Winbox, RouterOS y el equipo. No todos los puertos muestran los mismos contadores.
3. Qué nos dice la información de una interfaz
| Dato | Qué representa | Cómo utilizarlo |
|---|---|---|
R / running | Interfaz operativa según su tipo. | En Ethernet indica enlace, no conectividad de extremo a extremo. |
X / disabled | Interfaz deshabilitada. | Identifica por qué se deshabilitó antes de activarla. |
rate / full-duplex | Velocidad y dúplex del enlace. | Compara con lo esperado en ambos extremos. |
RX / TX | Recepción / transmisión desde este MikroTik. | En la WAN, RX suele ser descarga; en el puerto hacia el cliente, suele ser TX. |
link-downs | Caídas acumuladas del enlace. | Compara dos lecturas para detectar nuevos cortes. |
last-link-down-time | Última caída registrada. | Contrasta la hora con el reporte del usuario. |
rx-fcs-error | Tramas recibidas con checksum incorrecto. | Si aumenta, investiga el trayecto físico y ambos extremos. |
tx-queue-drop | Paquetes descartados por la cola de la interfaz. | Relaciona su aumento con carga y capacidad. |
rx-broadcast / rx-multicast | Tramas de difusión y multidifusión recibidas. | Observa su ritmo y el comportamiento habitual de la red. |
MTU / L2MTU | Límites de tamaño en las capas correspondientes. | Revísalos si fallan paquetes grandes o tráfico encapsulado. |
Los contadores son acumulativos; las tasas en bits o paquetes por segundo describen actividad instantánea. No sumes tráfico de puertos físicos, bridge y VLAN como si siempre fueran flujos independientes: un mismo paquete puede aparecer en varias interfaces.
Errores y descartes no significan lo mismo. Un FCS incorrecto describe una trama dañada; un descarte puede producirse por congestión. Además, los descartes de una cola o del firewall se investigan en sus propias estadísticas, no únicamente en el puerto.
4. Comandos básicos para comenzar el diagnóstico
Reemplaza ether1 por el nombre real de tu interfaz. Estos comandos consultan información:
/interface print
/interface print detail where name="ether1"
/interface ethernet monitor ether1 once
/interface print stats-detail where name="ether1"
/interface ethernet print stats where name="ether1"
/interface monitor-traffic ether1 once
/log print where message~"ether1"Para observar el tráfico de forma continua:
/interface monitor-traffic ether1Pulsa Ctrl+C para detenerlo. El monitor Ethernet muestra el enlace; las estadísticas generales y Ethernet aportan contadores complementarios.
5. Fallas frecuentes: cómo reconocerlas y resolverlas
5.1. El puerto no levanta enlace
Síntoma: no aparece operativo y el monitor indica ausencia de enlace.
Qué probar: confirma que ambos equipos estén encendidos y el puerto habilitado. Sustituye el patch cord por uno comprobado, revisa conectores y prueba otro puerto compatible. Cambia un elemento cada vez: así podrás identificar cuál modifica el resultado.
Si un cable corto funciona y el tendido instalado no, concentra la revisión en ese tendido, sus uniones y terminaciones.
5.2. Enlaza a 100 Mbps cuando esperabas 1 Gbps
Síntoma: el monitor muestra 100 Mbps y el rendimiento queda limitado por ese enlace.
Qué probar: verifica primero que el puerto remoto sea Gigabit. Después revisa cableado, los cuatro pares, conectores e inyectores PoE intermedios. Un inyector limitado a Fast Ethernet puede convertirse en el cuello de botella.
Para cobre Gigabit, mantén la autonegociación como punto de partida. Forzar una velocidad no repara un cable ni aumenta la capacidad del equipo remoto. En enlaces SFP, comprueba la configuración específica de ambos módulos y puertos.
5.3. Se desconecta y vuelve a conectar
Síntoma: aparecen eventos de caída y recuperación, y aumenta link-downs.
Qué probar: registra las horas y compáralas con reinicios, cortes eléctricos o tareas programadas. Revisa fuente de alimentación, PoE, cableado y equipo remoto. Un patrón periódico justifica revisar automatizaciones, pero no confirma por sí solo su causa.
Evita reiniciar todo antes de guardar los datos: podrías perder la evidencia necesaria para relacionar los eventos.
5.4. Aumentan los errores FCS
Síntoma: el contador sigue subiendo mientras hay tráfico.
Qué probar: sustituye cable y conectores, elimina uniones temporales y compara puertos y equipos. En fibra, revisa conectores y módulos. Que el MikroTik reciba tramas dañadas no demuestra que su puerto sea el responsable: el daño puede originarse antes de la recepción.
Guarda una lectura inicial y otra después de la prueba. Un total histórico estable es distinto de cientos de errores nuevos por minuto.
5.5. Hay lentitud y descartes, pero no errores físicos
Síntoma: el enlace permanece estable, pero aumenta la latencia o la pérdida bajo carga.
Qué probar: observa RX y TX por separado, revisa las colas y comprueba la CPU. En full dúplex, cada dirección tiene su propia capacidad: sumar RX y TX no determina por sí solo la saturación.
/system resource print
/tool profile
/queue simple print stats
/queue tree print statsLos picos breves pueden provocar descartes aunque el promedio de la gráfica parezca bajo. Según lo que confirmes, la solución puede ser ampliar el enlace, distribuir carga, corregir la negociación o ajustar el control de tráfico. No cambies el tipo de cola sin identificar dónde se produce el cuello de botella.
5.6. Hay demasiado broadcast o multicast
Síntoma: tráfico anormal en varios puertos, red inestable o advertencias sobre difusión excesiva.
Qué probar: compara con el comportamiento habitual, identifica el segmento de origen y revisa conexiones duplicadas entre switches. Un contador alto acumulado no confirma un bucle; también puede existir tráfico legítimo.
/interface bridge print detail
/interface bridge port print detail
/interface bridge host printSi confirmas un bucle, elimina la conexión que lo provoca y revisa el diseño de redundancia. RSTP/MSTP permite evitar bucles en topologías compatibles. Loop Protect es una protección adicional que puede deshabilitar una interfaz al detectar sus propias tramas de prueba; su activación requiere considerar la topología.
5.7. La interfaz está activa, pero no hay Internet
Síntoma: el puerto tiene enlace y tráfico, pero no hay navegación.
Qué probar: comprueba primero el vecino inmediato y luego un destino externo. Si funciona por IP y falla por nombre, investiga DNS. Si el cliente no llega al gateway, revisa su direccionamiento y segmento. Si llega al gateway pero no sale, continúa con rutas, políticas, NAT y firewall.
/ip address print
/ip route print detail
/ip arp print
/interface vlan print detail
/interface bridge vlan print detail
/ip firewall filter print stats
/ip firewall nat print statsEstos últimos comandos son para IPv4; IPv6 utiliza sus propios menús de direcciones, rutas, vecinos y firewall. Los descartes de firewall no tienen por qué incrementar los errores físicos del puerto. En VLAN, revisa también la interfaz padre, el ID y la pertenencia tagged/untagged de los puertos.
5.8. El ping funciona, pero algunas páginas o VPN fallan
Síntoma: pasan paquetes pequeños, pero ciertas transferencias quedan detenidas.
Qué probar: considera una incompatibilidad de MTU como hipótesis, especialmente con PPPoE, VLAN o túneles. Compara pings de distintos tamaños sin fragmentación hacia un destino controlado que responda ICMP:
/ping 192.0.2.1 size=1400 do-not-fragment=yes count=5
/ping 192.0.2.1 size=1500 do-not-fragment=yes count=5Reemplaza 192.0.2.1: es una dirección de documentación. Los tamaños son ejemplos de prueba, no valores que debas configurar. Si solo fallan los mayores, revisa la MTU del trayecto y los mensajes ICMP necesarios para descubrirla. Un timeout aislado también puede deberse a filtrado o pérdida.
5.9. Fallas en SFP o SFP+
/interface ethernet monitor sfp-sfpplus1 onceAdapta el nombre. Cuando el módulo lo admite, puedes consultar potencia óptica RX/TX, temperatura y señales de pérdida de recepción o fallo del transmisor.
Qué probar: revisa limpieza, polaridad, tipo de fibra, módulos compatibles y velocidad en ambos extremos. Compara la potencia con la sensibilidad y el máximo de entrada especificados para ese transceptor. No existe un único rango de dBm correcto para todos los módulos; la recepción puede ser insuficiente o excesiva.
6. Cómo comprobar el cable desde MikroTik
/interface ethernet cable-test ether1Solo está disponible en determinados equipos y puertos. La prueba documentada requiere ausencia de enlace, por ejemplo con el extremo remoto desconectado. Puede indicar pares abiertos o en corto y una distancia aproximada.
Un resultado abierto también puede corresponder al extremo desconectado de un cable sano. Interprétalo según la longitud conocida. Planifica la desconexión si ese cable transporta un servicio en producción; la prueba no sustituye una certificación del cableado.
7. Ejemplo práctico: separar dos problemas distintos
Supongamos un caso ilustrativo: un cliente con plan de 500 Mbps reporta lentitud y cortes. En el puerto hacia su equipo observamos:
- Enlace negociado a 100 Mbps.
link-downspasa de 12 a 16 durante diez minutos.rx-fcs-errortambién aumenta.
Hay dos observaciones diferentes: el enlace limita la velocidad y, además, existen señales de inestabilidad física. La primera prueba propuesta es revisar la capacidad de los equipos y sustituir temporalmente cable e inyector por elementos comprobados y compatibles.
Si después enlaza a 1 Gbps y dejan de aumentar las caídas y errores, la comparación respalda que el problema estaba en el tramo sustituido. Para identificar el componente exacto, prueba los elementos por separado. Finalmente, verifica estabilidad y rendimiento desde el cliente.
8. Orden recomendado para diagnosticar
- Delimita el reporte: quién falla, desde cuándo y con qué frecuencia.
- Revisa el enlace: estado, velocidad, dúplex y eventos.
- Compara contadores: toma dos lecturas durante el problema.
- Observa la carga: tráfico, colas, paquetes por segundo y CPU.
- Prueba el tramo físico: cambia un elemento cada vez.
- Continúa por capas: bridge/VLAN, IP, rutas y servicios.
- Valida la solución: repite la prueba que mostraba la falla.
Si necesitas seguir una solicitud concreta, Packet Sniffer puede ayudarte a comprobar por qué interfaz entra o sale. Ten presente que el tráfico conmutado por hardware puede no ser visible para herramientas que trabajan sobre la CPU: una captura vacía no demuestra por sí sola que el enlace no transporte tráfico.
La información de una interfaz es un punto de partida para acotar el problema. Su mayor utilidad aparece cuando relacionas cada cambio de contador con el síntoma y verificas el resultado después de intervenir.
Documentación de referencia
Las definiciones de campos y funciones se basan en la documentación oficial. Las secuencias de comprobación y los casos son propuestas prácticas de diagnóstico, no conclusiones automáticas de RouterOS.
Publicar un comentario