Telcel — Enlace L2L Capellina ↔ La Junta

L2L (Ethernet punto a punto, VID 89) que Telcel contrata y Electrosystems transporta por radio entre Capellina y La Junta, pasando por Gasachi. “Telcel Q Junta Capellina”.

🎯 Pendientes (top de ataque)

• #384 📅 cond:respuesta-telcel · ⚠️ — Seguimiento con Telcel: su CPE en La Junta inyecta ~0 kbps pese a enlace 1G activo. Pedir que revisen puerto lado-servicio / mapeo de VLAN/EVC en su equipo de La Junta. Lado ES ya agotado y probado sano (ver bitácora 2026-05-28).

En progreso

Prueba de ancho de banda para Telcel (CIR = 500 Mbps). Estado 2026-05-28:

• Capacidad RF del cuello (hop1, 72 km/7x): ~532 Mbps PHY → throughput Ethernet útil estimado ~480-505 Mbps. Margen casi nulo vs el CIR de 500 (y bajo rain-fade cae). Dato de diseño importante: el path actual está dimensionado al filo del comprometido.
• iperf end-to-end por VID 89 entre los 2 EdgeRouter X (Capellina ↔ La Junta): ~420 Mbps TCP limpio, pero limitado por la CPU de los ER-X, no por el enlace (al forzar UDP a 560M el router se ahogó: 88% CPU, 60% pérdida). No valida los 500 — el generador es el cuello.
• Falta para certificar 500: una PC por sitio detrás de cada ER-X (el ER-X forwardea con hardware-offload a gigabit, la PC genera el tráfico). Decisión pendiente: conseguir las PCs, o entregar a Telcel lo medido (≥420 Mbps) + la capacidad RF (532) y abordar el margen ajustado.
• El #384 (CPE Telcel La Junta mudo) sigue en cancha de Telcel.

Backlog del proyecto

• #386 📅 sin-fecha — Reactivar el pipeline de monitoreo de estos equipos en es-monitoreo (lecturas muertas desde ~2026-04-17 → no hubo timeline disponible durante este incidente).
• #397 📅 cond:activar-puertos-T2 — Provisionar la llave de oxidized en los 4 radios de redundancia T2 (27.81/27.80/37.126/37.125) para que entren al backup automático. Hoy inalcanzables (puertos apagados en Gasachi); ya están listados en router.db, solo falta la llave cuando se activen.

Contexto

Telcel entrega un servicio L2L entre dos de sus sitios (Capellina y La Junta). Electrosystems es el transporte intermedio: el tráfico entra por el handoff de Telcel en Capellina, cruza la red de radios de ES (2 saltos AF-11FX vía el repetidor Gasachi) y sale por el handoff de Telcel en La Junta. La VLAN de servicio extremo-a-extremo es VID 89.

Topología (según Sergio, 2026-05-28)

Telcel Capellina
   │ FO
[.24 Netonix Capellina]  P1 = handoff Telcel  ·  P7 ──FO── P25 ──▶ [.168 Netonix Capellina]
                                                                        │ P6
                                                                  AF11 27.165 ))) hop1 ((( AF11 27.166
                                                                        │ P3
[.101 Netonix Gasachi] ◀── repetidor ──────────────────────────────────┘
        │ P4
   AF11 37.137 ))) hop2 ((( AF11 37.136
        │ P1
[.29 Netonix La Junta] ──FO P13◀▶P7── [.37 Netonix La Junta]  P5 = handoff Telcel
                                                                   │ FO
                                                              Telcel La Junta

• Handoffs Telcel confirmados por medición: .24 P1 (Capellina) y .37 P5 (La Junta).
• Saltos de radio: hop1 Capellina↔Gasachi (27.165 ↔ 27.166), hop2 Gasachi↔La Junta (37.137 ↔ 37.136). Todos AF-11FX, firmware AF09.v4.1.0.
• Redundancia (apagada por default): hop1 27.81↔27.80, hop2 37.126↔37.125. Los puertos están apagados en Gasachi; se pueden prender si hay que conmutar.
• Nota pendiente de precisar: la relación exacta .29↔.37 en el sitio La Junta no se cerró en esta sesión read-only (ambos están del lado La Junta; .37 P5 es el demarc de Telcel confirmado por la medición). El radio del hop2 (37.136) baja a .29; .37 cuelga de .29 por FO.

Notas técnicas

Acceso

• VPN: ssh wireguard (VM WireGuard).
• Mediciones / SNMP / SSH a radios: desde la VM oxidized (ssh oxidized, 192.168.20.27) — tiene snmp, sshpass, NOPASS sudo para user electrosystems, y el repo de backups oxidized.
• SNMP: v2c, community RO public, en los 5 Netonix (uptime, puertos, VLANs Q-BRIDGE). Los radios AF11 no contestaron SNMP en este incidente.
• SSH a radios AF11 (crypto legacy obligatorio):

  O='-o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa -o KexAlgorithms=+diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 -o StrictHostKeyChecking=no -o BatchMode=yes'
  sudo -u oxidized ssh $O ubnt@<ip-radio> "mca-status"

  La llave administrativa de ES (oxidized) se instala con backup-system/scripts/provision_airos.sh (usa sshpass -e, mete pubkey a /etc/persistent/.ssh/authorized_keys + /etc/dropbear/authorized_keys, corre cfgmtd -w).

Backups oxidized (referencia de config histórica)

• Repo: /var/lib/oxidized/configs.git (leer como sudo -u oxidized git -C ...), espejado al NAS.
• Netonix: la config se guarda con la primera y última línea recortadas (cfg.cut_both) → para parsear el JSON hay que envolver con { echo "{"; git show ...; echo "}"; }.

Diseño de VLANs

• VID 89 = VLAN de servicio L2L extremo-a-extremo (troncalizada en los 5 Netonix).
• VID 123 = VLAN de transporte sobre el hop1 (los radios bridgean solo eth0.123/air0.123).
• Hay stitching / Q-in-Q VID89↔VID123 en los puntos de borde (.168, .101).

Medir tráfico en vivo (delta SNMP)

Script validado: 2 snapshots de ifHCInOctets/ifHCOutOctets con ~12s de separación sobre los Netonix, y se calcula kbps. Ver electrosystems/servers/l2l-telcel-capellina-lajunta/findings.md.

Capacidad RF del transporte (lectura mca-status, 2026-05-28)

Todos AF-11FX, canal 56 MHz, firmware AF09.v4.1.0. Capacidades en Mbps (PHY; throughput Ethernet útil ~5-8% menos).

• Cuello de botella = hop1 (~532 Mbps full-duplex) — salto largo (72 km), un escalón de modulación abajo (7x vs 8x del hop2). Netonix y FO son gigabit → no limitan. Techo del L2L extremo-a-extremo lado ES ≈ 530 Mbps.
• Rain-fade (banda 11 GHz): el hop1 a 72 km/7x tiene poco margen de modulación; en lluvia intensa la capacidad puede degradar temporalmente. Sin problema si el CIR contratado está holgadamente debajo de ~500 Mbps.
• Throughput medido — corrección (2026-05-28): el AF-11FX no tiene la herramienta Speed Test de la GUI (esa es de airMAX/airOS). Su plano de datos va hardware-offloaded (en /proc/net/dev del radio, eth0=0 bytes mientras air0 mueve tráfico) → la CPU del radio (ARM am1808) no puede generar/sumir ~500 Mbps, por eso no hay generador interno ni serviría iperf/nc corriendo en el propio radio (mediría la CPU, no el enlace). La única medición real con tráfico es iperf end-to-end por la VLAN 89 con un host en cada extremo (sin equipos en sitio = no factible hoy). La métrica entregable sin eso es la capacidad de modulación ya leída (tabla arriba); la GUI del airFiber la muestra en el campo Capacity (TX/RX) del dashboard → sirve de screenshot para Telcel.

Entregable a Telcel

• PDF de evidencia: deliverables/telcel/capellina-lajunta/evidencia-l2l-2026-05-28.pdf (fuente HTML junto al PDF). Cliente-facing en español: resumen ejecutivo, topología, pruebas del lado ES, tabla de medición en handoffs, conclusión y solicitud a Telcel. Generado con Chrome headless (Docker selenium/standalone-chrome) — regenerar: editar el HTML y reimprimir con docker run --rm --user root -v <dir>:/data --entrypoint google-chrome selenium/standalone-chrome --headless --disable-gpu --no-sandbox --no-pdf-header-footer --print-to-pdf=/data/out.pdf file:///data/in.html.

Bitácora

2026-05-28 — Incidente: L2L sin tráfico (cayó ~1:30–2:00 AM)

• Pidió Sergio: el L2L no pasa tráfico; “a simple vista se ve todo bien”; Telcel dice que de su lado está bien. Quiere agotar posibilidades del lado de ES antes de regresar con Telcel. Funcionaba y se cayó de golpe entre ~1:30 y 2:00 AM de hoy. Autorizó diagnóstico read-only e instalar la llave oxidized en los radios.

• Topología real: Sergio corrigió el path (arriba). Handoffs Telcel: .24 P1 y .37 P5.

• Monitoreo (es-monitoreo): el pipeline de lecturas de estos equipos está muerto desde ~2026-04-17 → no hubo timeline histórico que consultar. (La DB exponía contraseñas de equipos — redactadas, nunca escritas al workspace.)

• Lo que se descartó del lado ES (read-only):

  • Los 5 Netonix arriba, sin reboot espontáneo a la 1:30 AM, VID 89 bien troncalizada extremo-a-extremo.
  • Ambos hops AF11 con RF sana (mca-status saludable) y config idéntica al backup oxidized de fin de abril (diff git). El eth0 carrier=0 resultó ser normal (offloaded; también en el hop sano).
  • Hipótesis refutadas en el camino: (a) “RF de AF11 caída” → refutada por mca-status; (b) “br0 disabled + eth0 NO-CARRIER en 27.165 = el bug” → refutada por el diff del backup (br0 disabled es normal desde el 30-abr, sin cambios).

• Quirk conocido de Sergio: las VLANs a veces dejan de pasar tráfico en los Netonix aunque la config se vea bien — siempre tras aplicar un cambio, nunca de repente. Sergio reinició proactivamente .29, las orillas, y probó la redundancia del hop1 (27.81↔27.80) → sin cambio.

• Reboot de .168 Capellina (único switch de stitching sin reiniciar, 50 días uptime): no restauró el circuito.

• Medición decisiva (delta SNMP, post-reboot .168):

  Punto	in	out
  .24 P1 (Telcel Capellina)	16.1 kbps	0.1
  .37 P5 (Telcel La Junta)	0.1	17.0 kbps
  .24 P7 (FO transporte)	104	24 kbps
  .37 P7 (FO transporte)	108	1.9 kbps

• Veredicto: lo que entra por el handoff de Capellina (16 kbps) sale casi idéntico por el handoff de La Junta (17 kbps) → el transporte de ES SÍ reenvía el L2L extremo-a-extremo (cruza ambos hops y los 5 Netonix sin pérdida; es el único camino entre esos puntos, así que el match byte-por-byte lo prueba). El circuito está muerto porque el CPE de Telcel en La Junta inyecta ~0 kbps (.37 P5 in = 0.1) pese a enlace 1G activo. ES no puede transportar lo que Telcel no entrega.

• Lado ES: agotado y probado sano. Falla del lado Telcel (su CPE de La Junta mudo).

• Falta: seguimiento #384 con Telcel con la evidencia (su CPE La Junta no inyecta; el tráfico que sí ofrecen cruza completo el enlace de ES). Reactivar monitoreo (#386) y completar alta en oxidized (#385).

2026-05-28 (tarde) — Telcel pide prueba de ancho de banda; lectura RF de los 4 hops + provisión oxidized

• Pidió Sergio: Telcel solicita pruebas de ancho de banda del tramo L2L Capellina↔La Junta. No hay forma de poner equipos en ambos sitios → descarta iperf end-to-end. Plan acordado: (paso 1) leer capacidad RF de los 4 hops; (paso 2, pendiente) speed-test integrado del airFiber por salto en ventana coordinada.
• Acceso destrabado (de paso, #385): solo .137 tenía la llave de oxidized (del incidente AM); los otros 3 fallaban key-auth (Permission denied (publickey,password) — la pubkey de oxidized no estaba en su authorized_keys). Sergio autorizó provisionar. Corrió provision_airos.sh (vía ! ssh -t, password en /tmp/.afpw, ya borrado) en .165/.166/.136 → key-auth OK en los 3 (llaves RSA+ed25519 en /etc/persistent/.ssh + /etc/dropbear, cfgmtd -w). El classifier bloqueó la mutación desde mi lado (sesión arrancó read-only); por eso la corrió Sergio con !.
• Lectura RF (mca-status, los 4): tabla en Notas técnicas → Capacidad RF del transporte. Resumen: hop1 (72 km, 7x) ~532 Mbps, hop2 (37 km, 8x) ~609 Mbps, todos 56 MHz, link operacional, LAN 1G full.
• Cuello de botella = hop1 ≈ 532 Mbps full-duplex → techo del L2L extremo-a-extremo lado ES. Netonix + FO gigabit no limitan. Ojo rain-fade en 11 GHz (hop1 con poco margen de modulación).
• #385 (backup oxidized): descubrimiento — los 8 radios ya estaban en router.db; el inventario nunca fue el faltante, era la llave. Con los 4 del path activo provisionados, oxidized ya puede respaldarlos. Los 4 T2 de redundancia (.81/.80/.126/.125) tienen puertos apagados → inalcanzables, sin llave → nuevo #397 condicional a activar puertos.
• Falta (paso 2): speed-test del airFiber por hop para confirmar throughput sostenido. Satura RF compartido con otros clientes → ventana de mantenimiento coordinada (madrugada), no improvisado.
• Resuelto 2026-05-28 [#385]: llave de oxidized provisionada en los 4 radios del path activo (.137 ya la tenía; .165/.166/.136 hoy); los 8 ya estaban en router.db → backup automático del path operativo. Redundancia T2 → #397.

2026-05-28 (tarde-2) — Intento de speed-test → el AF-11FX no lo soporta (corrección de método)

• Pidió Sergio: correr el speed-test “ahora” aprovechando que el L2L no tiene tráfico (CPE Telcel mudo). Confirmó que los otros clientes (Agnico/Molymex/Diabras/Mina Dolores) no cruzan estos hops, así que saturar no afectaba a nadie.
• Se armó el monitor de throughput en vivo de air0 (delta de bytes vía SSH al radio .166, muestreo 2s/240s) para capturar el pico mientras Sergio disparaba el test desde la GUI.
• Bloqueo: Sergio no halló el botón Speed Test en la GUI. El monitor registró solo fondo (pico tx=4 Mbps, sin test).
• Causa (confirmada por doc UI + lectura del radio): el airFiber no tiene la herramienta Speed Test (es exclusiva de airMAX/airOS). Razón de fondo: el plano de datos del AF-11FX está hardware-offloaded — eth0=0 bytes mientras air0 mueve tráfico → la CPU no toca el tráfico de cliente y no puede generar tráfico de línea. Por eso no hay generador interno y iperf/nc en el radio no mediría el enlace. (Mi error: confundí airFiber con airMAX al proponer el “paso 2”.)
• Conclusión: sin hosts en ambos extremos no hay throughput medido posible con este hardware. El entregable defendible es la capacidad reportada por el airFiber (hop1 ~532, hop2 ~609 Mbps; campo Capacity del dashboard → screenshot). Un iperf end-to-end por VID 89 queda como única vía de medición real, condicionada a conseguir 2 equipos en sitio. Decisión de entregable pendiente de qué exige Telcel (validar CIR vs throughput medido).

2026-05-28 (tarde-3) — iperf end-to-end con los 2 EdgeRouter X (CIR confirmado = 500 Mbps)

• Sergio: Telcel exige throughput medido con tráfico; CIR = 500 Mbps. Propuso usar 2 EdgeRouter X que ya tiene en sitio (Capellina 192.168.37.190, La Junta 192.168.37.52); autorizó entrar a configurarlos y aceptó el blip productivo (ambos ER-X son routers de producción: Capellina con IP pública, La Junta con uplink Alestra + WireGuard).

• Perfilado: ambos ER-X = ER-X (MT7621, 4 hilos, 256 MB), EdgeOS v3.0, con iperf e iperf3. Capellina ya tenía vif 89 (“Telcel”, 192.168.13.50/24); La Junta no.

• Fase A — conectividad L2 por VID 89 (config aplicada a producción):

  • ER-X Capellina: vif 89 reasignado 192.168.13.50/24 → 10.99.37.1/30 (Sergio pidió mover de la subred .13 que se usa en otro sitio; .13.50 no se usaba). commit; save.
  • ER-X La Junta: agregado eth0 vif 89 = 10.99.37.2/30 mtu 1500. commit; save.
  • Netonix La Junta .29 puerto 3 (donde cuelga el ER-X): Sergio agregó VID 89 tagged (no la tenía → primer ping falló con host-unreachable; tras agregarla, OK).
  • Ping 10.99.37.2 → .1: 0% pérdida, RTT ~1.4 ms → dominio L2 VID 89 completo extremo-a-extremo.

• Fase B — iperf por VID 89 (Junta ↔ Capellina):

  Método	Throughput	Pérdida	CPU ER-X La Junta
  TCP iperf3 -P8 (ambas dir.)	418 Mbps	0%	44% de 4 cores
  TCP iperf2 -P8	420 Mbps	0%	58% (no escaló)
  UDP iperf2 -P4 @560M target	~137 Mbps recibido	52-67%	88% (colapsó)

• Veredicto: ~420 Mbps TCP limpio medidos, pero el cuello es la CPU de los ER-X generando (el hardware-offload no acelera tráfico self-generated), no el enlace. No valida los 500 del CIR. El enlace probablemente da más (RF 532), pero no se puede demostrar con los ER-X solos.

• air0 por /proc/net/dev no mide el throughput (mismo hardware-offload del airFiber → el tráfico de datos no toca la CPU del radio; marcó 0). El número válido es el del propio iperf.

• Estado de la config: los vif 89 quedan montados (Capellina 10.99.37.1, La Junta 10.99.37.2) + VID 89 en pto3 del Netonix La Junta — listos para repetir con PCs. iperf servers ya matados. Pendiente decidir: (a) PC por sitio detrás de cada ER-X para certificar 500, o (b) entregar ≥420 medido + capacidad RF y abordar el margen ajustado; y si se revierte el setup de prueba o se deja.

• Secreto: la config del ER-X La Junta incluía la private-key del WireGuard — NO se guardó en el workspace.

• Entregable cliente-facing: ../deliverables/telcel/capellina-lajunta/prueba-ancho-banda-2026-05-28.pdf — reporte de prueba de ancho de banda para Telcel (capacidad ~530 Mbps, throughput ~420 Mbps sin pérdida, limitado por equipos de prueba). Sin mención del CIR por instrucción de Sergio; foco en capacity real + throughput medido. Generado con Chrome headless Docker, fuente HTML junto al PDF.