Hub

telcel

telcel-jacala

active medium work
Creado
2026-05-13
Actualizado
2026-05-29
Enlace
Jacala-La Reforma Zimapan
Aliases
Jacala, Jacala-Zimapan

Pendientes abiertos (2)

Ver todos →

🎯 Top de ataque (2)

  • #032 📅 2026-06-08 Pendiente investigar (no toqué): identificar MAC origen del broadcast con tcpdump -i switch0 -nne 'ether broadcast and src host 206.135.14.86' (NO ejecutado — solo investigación read-only en esta sesión).
  • #033 📅 2026-06-08 erx-jacala NO está en /var/lib/oxidized/router.db — si queremos backups automáticos de config, hay que darlo de alta.

Actividad en bitácora 1 día

jun
jul
ago
sep
oct
nov
dic
ene
feb
mar
abr
may
L
X
V
Menos
Más

Telcel — Enlace Jacala-La Reforma Zimapan

Contexto

Enlace de Telcel en el sitio Jacala-La Reforma Zimapan (también referido como Jacala o Jacala-Zimapan). Electrosystems le da servicio a este enlace.

Equipo conocido en sitio:

  • EdgeRouter X (Ubiquiti, EdgeOS) en 10.5.0.126.

Tareas pendientes

EdgeRouter X 10.5.0.126 — SNMP daemon se cuelga (2026-05-13)

  • (2026-05-13) SSH cerrado/corrupto — reparado. Puerto 58695 (estándar Electrosystems).
  • (2026-05-13) Llave de autenticación SSH instalada vía script /opt/oxidized-tools/scripts/fleet_provision_edgeos.sh en servidor oxidized. La llave administrativa de Electrosystems para EdgeOS es oxidized@oxidized-vm (ed25519). End-to-end verificado: sudo -u oxidized ssh -p 58695 ubnt@10.5.0.126 'hostname' → erx-jacala.
  • (2026-05-13) Fix inmediato aplicado — sudo /etc/init.d/snmpd restart (PID 2535 → 29950). Post-restart: rx_queue=0, drops=0. snmpwalk -v2c -c public 10.5.0.126 1.3.6.1.2.1.1.5.0 desde oxidized → STRING: "erx-jacala". Instalado paquete snmp en oxidized (no estaba).
  • (2026-05-13) Watchdog permanente instalado — script /config/scripts/post-config.d/30-snmpd-watchdog.sh (chmod +x, root:vyattacf 589 bytes). Reinstala /etc/cron.d/snmpd-watchdog en cada boot. Cron */5 * * * * hace snmpwalk local a 127.0.0.1 OID sysName.0; si timeout reinicia snmpd y loguea a /var/log/snmpd-watchdog.log. Ejecutado manualmente una vez post-instalación → cron activo sin esperar reboot. Cron daemon corriendo (PID 169, /usr/sbin/cron -f).

Causa raíz confirmada — NO es persistencia de config, es snmpd colgado

SNMP está correctamente configurado y persiste en /config/config.boot (service snmp { community public { authorization ro } contact gchavira }). El daemon snmpd (PID 2535) está vivo y escuchando en 0.0.0.0:161, pero no consume del socket UDP — está en sleep (wait_woken).

Evidencia dura (/proc/net/udp línea para puerto 0x00A1 = 161):

  • rx_queue = 181,824 bytes acumulados sin leer.
  • drops = 90,330 paquetes UDP dropeados por kernel porque la cola está llena.
  • show snmp consulta 127.0.0.1:161 y se va a timeout — su propio paquete también se dropea.

Por qué el síntoma parece “SNMP se desactiva al apagar”: el daemon arranca bien post-boot, atiende un rato (horas/días), y entra en hang. Visto desde monitoreo externo se interpreta como “se cayó después del reboot/apagón”. Es un patrón conocido de net-snmp en EdgeOS bajo carga.

Posibles causas del hang:

  1. smux peers de Quagga/Zebra — snmpd.conf tiene 10+ smuxpeer. Si Quagga reconecta o un peer hace algo raro, snmpd se atora.
  2. Floods de martian source — /var/log/messages saturado con martian source 255.255.255.255 from 206.135.14.86 on dev switch0/eth4. Hay un host en LAN/WAN mandando broadcasts mal formados. Genera alta carga.
  3. Cron de monitoreo externo queryeando con periodo muy corto + walks pesados.

Acción a tomar — APLICADO 2026-05-13

  • (2026-05-13) Fix inmediato — sudo /etc/init.d/snmpd restart exit=0. PID nuevo 29950. /proc/net/udp:161 post: rx_queue=0, drops=0 (era 181824 / 90359). SNMP responde end-to-end.
  • (2026-05-13) Watchdog cron permanente — instalado en /config/scripts/post-config.d/30-snmpd-watchdog.sh. No hubo que tocar smux ni la causa raíz: si vuelve a colgarse, el watchdog lo recoge en ≤5 min.

Hallazgos colaterales — investigados 2026-05-13

Skew de reloj — RESUELTO/explicado

  • date → Wed May 13 22:24:52 UTC 2026. Uptime: 102857s (~28.5h). No hay skew real ahora — el “skew de ~16h” que vi en la sesión anterior probablemente vino del log timestamp del último kernel boot vs hoy, no de offset del clock vivo.
  • NTP correctamente configurado: set system ntp server {0,1,2,3}.ubnt.pool.ntp.org. ntpq -pn muestra 4 peers sincronizados (*45.63.54.13 primario, jitter <1ms, reach 377). Sync limpio.
  • TZ está en UTC (/etc/timezone: UTC, /etc/localtime → /usr/share/zoneinfo/UTC). No es bug, pero amerita revisión: el resto del fleet probable usa America/Mexico_City. Logs en UTC complica correlación.
  • (2026-05-14) TZ alineada a America/Mexico_City. Aplicado vía script-template (configure → set system time-zone America/Mexico_City → commit → save) desde oxidized → ubnt@10.5.0.126:58695. Verificado: /etc/timezone = America/Mexico_City, date ahora reporta CDT en vez de UTC. Persistido en /config/config.boot. Logs y show del fleet ahora correlacionan en hora local.

Martian source 206.135.14.86 — diagnóstico claro, NO es problema externo

  • 206.135.14.86 ES la propia IP WAN del router (set interfaces ethernet eth4 address 206.135.14.86/30 description 'WAN IENTC'). El “martian” es el router viendo broadcasts con src=su propia IP llegando por switch0 (LAN) y a veces por eth4 (WAN).

  • Frecuencia: ~20 eventos cada 31 segundos = ~40/min, sostenido por al menos 2h40m. Total acumulado en /var/log/messages: 2,975 eventos en la sesión actual.

  • Cadencia exacta de 31s sugiere timer fijo en algún daemon/CPE mandando broadcast (DHCP-Discover sin source IP correcto, o ICMP/UDP de keepalive con src spoofeada).

  • ARP en eth4: solo el gateway upstream 206.135.14.85 (64:9d:99:d2:03:74). /30 → solo 2 hosts útiles. switch0 es la LAN (eth1+eth2+eth3 bridge), port-forward apunta a switch0.100 (VLAN 100).

  • Hipótesis fuerte: algo en LAN está enviando broadcasts L2 con src=206.135.14.86. Posibles:

    1. CPE del cliente con WAN mal configurada (copió la IP pública del ERX como su propia IP).
    2. Loop o eco entre eth4 y switch0 — el broadcast viene del WAN, entra por eth4, el router lo “ve” otra vez por switch0 (de ahí los dobles eventos por timestamp).
    3. NAT outbound reflejándose.

  • Lo más probable es (1): un dispositivo en LAN clonó la IP WAN del router como su propia config (común en CPEs Telcel mal puestos). Frecuencia 31s coincide con DHCPDISCOVER/INFORM o announce de algunos CPEs.

  • #032 📅 2026-06-08 — Pendiente investigar (no toqué): identificar MAC origen del broadcast con tcpdump -i switch0 -nne 'ether broadcast and src host 206.135.14.86' (NO ejecutado — solo investigación read-only en esta sesión).

  • #033 📅 2026-06-08 — erx-jacala NO está en /var/lib/oxidized/router.db — si queremos backups automáticos de config, hay que darlo de alta.

Notas técnicas

Acceso (actualizado 2026-05-13)

  • Ping desde VPN: OK (~47 ms).
  • SSH en puerto 58695 (Sergio reparó acceso). Usuario probable ubnt. Llave id_rsa_es.
  • SNMP UDP/161: abierto, community public.
  • GUI HTTPS/HTTP: abierta. Banner EdgeOS (Ubiquiti, Copyright 2025).
  • VPN para llegar al equipo: vía ssh wireguard (la VM con WireGuard).

SNMP community / versión

  • Community: public (confirmado 2026-05-13).
  • Versión: pendiente confirmar v1/v2c/v3 (asumir v2c por default en EdgeRouter).

Bitácora

2026-05-13

  • Pidió Sergio: revisar por qué SNMP del EdgeRouter X en 10.5.0.126 se desactiva tras apagar el equipo.
  • Hice (mañana): primer diagnóstico read-only — SSH cerrado en 22/2222/22022/8022. Hipótesis inicial: commit sin save. Capturado el contexto.
  • Aclaró Sergio: cliente Telcel, enlace Jacala-La Reforma Zimapan. Convención de naming establecida. Reparó SSH al puerto 58695 (estándar Electrosystems). Community SNMP esperada: public.
  • Hice (tarde): segundo intento por SSH:58695 — autenticación falló con id_rsa_es. Sergio aclaró que Electrosystems tiene un script en oxidized para subir llaves a equipos Ubiquiti. Lancé agente que encontró /opt/oxidized-tools/scripts/fleet_provision_edgeos.sh, lo ejecutó para 10.5.0.126:58695 ubnt, e instaló la llave de oxidized en system login user ubnt authentication public-keys. Verificado: sudo -u oxidized ssh -p 58695 ubnt@10.5.0.126 'hostname' → erx-jacala.
  • Hice (diagnóstico final): SSH al equipo desde oxidized. Hipótesis “commit sin save” REFUTADA. SNMP persiste correctamente en /config/config.boot. Causa raíz real: snmpd colgado — PID 2535 vivo y escuchando en 0.0.0.0:161 pero no consume del socket UDP. rx_queue=181824 bytes, drops=90330 packets en /proc/net/udp. El daemon arranca bien y se cuelga después de un rato; visto desde monitoreo externo parece “SNMP se desactivó al apagar”. Patrón conocido de net-snmp en EdgeOS bajo carga (smux peers de Quagga, martian flood, walks pesados).
  • Falta: Sergio decide entre (a) restart inmediato como fix temporal, (b) watchdog cron permanente en post-config.d/, (c) deshabilitar smux. Adicional: investigar martian source 206.135.14.86 → 255.255.255.255 en switch0/eth4; skew de reloj ~16h; dar de alta erx-jacala en /var/lib/oxidized/router.db para backups.

2026-05-13 (sesión tarde — fixes aplicados)

  • Pidió Sergio: aplicar fix de snmpd colgado + watchdog permanente + diagnosticar skew y martian (read-only).
  • A) Restart snmpd: pre rx_queue=181824, drops=90359. sudo /etc/init.d/snmpd restart exit=0. Post rx_queue=0, drops=0. PID 2535 → 29950. Instalado apt install snmp en oxidized (no estaba; usar OIDs numéricos: las MIBs cortas no resuelven). Test end-to-end OK: snmpwalk -v2c -c public 10.5.0.126 1.3.6.1.2.1.1.5.0 → STRING: "erx-jacala". Igual desde 127.0.0.1 en el router.
  • B) Watchdog: instalado /config/scripts/post-config.d/30-snmpd-watchdog.sh (modo 755). Genera /etc/cron.d/snmpd-watchdog con entry */5 * * * * que hace snmpwalk local; si falla, restart + log a /var/log/snmpd-watchdog.log. Ejecutado manualmente una vez → cron activo. cron daemon corriendo. Idempotente: se regenera en cada boot porque /etc/cron.d/ se pierde y /config/ persiste.
  • C) Skew: NTP bien configurado y sincronizado (4 servidores *.ubnt.pool.ntp.org, peer primario 45.63.54.13, jitter <1ms). Reloj actual coherente con uptime. TZ=UTC (no America/Mexico_City) — no urgente pero amerita homologar con el fleet.
  • D) Martian: 206.135.14.86 es la propia IP WAN del router (eth4, descripción “WAN IENTC”). El martian es el router viéndose a sí mismo en broadcasts L2 que aparecen tanto por eth4 (WAN, /30 con gateway 206.135.14.85) como por switch0 (LAN). Frecuencia ~40 ev/min, cadencia fija de 31s, 2,975 eventos acumulados. Hipótesis principal: algún CPE en LAN clonó la IP pública del ERX como su propia config (típico de CPEs Telcel mal puestos). No corregido — solo investigado.
  • Riesgos / cosas raras:
    • Watchdog usa snmpwalk -v2c -c public 127.0.0.1 — si Sergio cambia community SNMP en el router, hay que actualizar el cron también.
    • set -e en el script + heredoc: si el script crece, cuidado con efectos colaterales que aborten el resto del post-config.
    • El watchdog también restartea aunque la causa sea otra (router lento, alta carga puntual). Para producción de largo plazo, vale agregar contador de restarts/hora para no entrar en loop.
  • Falta: decidir si cambiar TZ del router a México; identificar el CPE en LAN que está mandando broadcasts con src=206.135.14.86 (requiere tcpdump en switch0, no hecho); dar de alta erx-jacala en /var/lib/oxidized/router.db.