CPE Benito Juárez — atención y diagnóstico
Contexto
Servicio de internet de 200 Mbps a un cliente en Benito Juárez (Chihuahua), entregado por fibra desde el POP de Villa Ahumada al CPE MikroTik RB4011iGS+ del cliente. Reporte recurrente o futuro de problemas se documenta aquí; el detalle técnico vive en electrosystems/servers/cpe-benito-juarez/findings.md.
Tareas pendientes
🔒 Pendiente con disparo condicional — limitar tráfico a 200 Mbps en la entrega formal
- #092 📅 2026-06-04 — Limitar el servicio a 200 Mbps cuando se haga la entrega formal del cliente.
- Estado actual (2026-05-08): sin límite por acuerdo verbal. La entrega formal no se ha hecho porque la fibra óptica todavía está en construcción/trabajo. Hoy el MK pasa ~980 Mbps RX (medido en muestras consecutivas — ver findings.md).
- Disparo: cuando se complete la fibra y se haga la entrega formal del servicio al cliente. Sin fecha definitiva — Sergio confirmará cuando esté cerca.
- Acción al disparar: aplicar el shaping de 200 Mbps. Lugar más probable: Netonix
sw-villa-ahumada(port-level rate limit hacia la fibra del cliente) o queue tree en el MK del cliente. Decidir el lugar antes de aplicar. - Por qué no enforce hoy: acuerdo verbal con el cliente mientras se termina la entrega; no es bug, es intencional.
Próxima sesión
- #088 📅 2026-06-06 — Subir llave SSH al Netonix
sw-villa-ahumada(mismo flujo que el MK; aún sin key auth).
Diagnóstico abierto
- #089 📅 2026-06-08 — Confirmar con el cliente la metodología del speedtest del 2026-05-08 (dispositivo, cableado, WiFi, server).
- #090 📅 2026-06-10 — Probar speedtest desde detrás del MK directamente (ether3/7/8 libres, cable, target conocido — Cloudflare/speedtest.net/etc.).
Mantenimiento
- #091 📅 2026-06-20 — Re-checar SFP rx-power en 2-4 semanas (hoy −26.38 dBm, dentro de spec pero en zona baja).
En progreso
- (nada — diagnóstico inicial cerrado el 2026-05-08, esperando feedback del cliente)
Notas técnicas
Topología
Sergio WSL ── WG client ── wireguard VM (10.255.255.1) ── ES intranet ──
──> Villa Ahumada Netonix sw-villa-ahumada (192.168.167.2)
──> fibra SFP ──>
cpe-benito-juarez MikroTik (sfp-sfpplus1, 192.168.167.15/24, GW .1)
──> bridge LAN (10.167.0.0/28)
──> 3× Grandstream GWN7003 + 1× TP-Link TL-WR840N + PCs
Acceso configurado
- SSH alias
cpe-benito-juarez→192.168.167.15, useradmin, key auth con~/.ssh/id_rsa_es(importada 2026-05-08 vía/user ssh-keys import). - SSH alias
sw-villa-ahumada→192.168.167.2, useradmin, key auth pendiente.
Comandos útiles para futuros diagnósticos del MK
Read-only, una sola línea cada uno:
ssh cpe-benito-juarez '/system identity print; /system resource print; /system clock print'
ssh cpe-benito-juarez '/interface print; /ip address print; /ip route print'
ssh cpe-benito-juarez '/interface ethernet monitor [find] once'
ssh cpe-benito-juarez '/interface ethernet print stats'
ssh cpe-benito-juarez '/queue simple print; /queue tree print'
ssh cpe-benito-juarez '/ip firewall filter print; /ip firewall mangle print; /ip firewall nat print'
ssh cpe-benito-juarez '/ip arp print where interface=bridge; /ip dhcp-server lease print'
ssh cpe-benito-juarez '/log print without-paging where !topics~"info" and !topics~"ssh"'
ssh cpe-benito-juarez ':for i from=1 to=5 do={/interface monitor-traffic [find name=sfp-sfpplus1] once; :delay 2s}'
Bitácora
2026-05-08
- Pidió Sergio: diagnosticar reporte del cliente: “el servicio de 200 Mbps me da 30 Mbps”.
- Hice:
- Setup de acceso: agregué
Host cpe-benito-juarezyHost sw-villa-ahumadaa~/.ssh/config. Sergio subióid_rsa_es.pubal MK e hizo/user ssh-keys import(en su terminal con password). Key auth verificada. - Diagnóstico read-only completo en el MK (ver
electrosystems/servers/cpe-benito-juarez/findings.md). - Documentación: creé README + findings del MK; stub README del Netonix; client doc; este project file; actualicé inventarios e índices.
- Setup de acceso: agregué
- Hallazgo clave: El MK está moviendo cerca de 1 Gbps (978-988 Mbps RX) en muestras consecutivas, sin drops ni errores, sin queues ni rate-limit configurado, fasttrack activo, CPU 10%. No es el cuello de botella. El “30 Mbps” del cliente debe venir de su LAN interna (3 Grandstream + 1 TP-Link cascadeados), del WiFi, o de la metodología del test.
- Anomalía menor: SFP+ rx-power −26.38 dBm — dentro de spec del módulo EZX 120km pero en la zona baja. Vigilar.
- Nota operativa: El MK reinició hoy ~17:26 CDT por probable corte de luz; flapeo de puertos LAN del cliente entre 18:33-18:40. Considerar UPS.
- Falta: confirmar con el cliente la metodología de medición; probar desde detrás del MK directamente; setup de key auth en Netonix para ver el lado del switch.
- Aclaración tardía de Sergio: la ausencia de cap de 200 Mbps en el MK no es un olvido — es por acuerdo verbal mientras se termina la fibra. Cuando se haga la entrega formal del servicio (sin fecha aún, fibra en construcción) se debe aplicar el límite. Documentado como pendiente con disparo condicional al inicio de “Tareas pendientes”.