Inicio

El grupo principal (arriba) recibe TODAS las alarmas. Cada grupo de aquí recibe además solo lo que le asignes: equipos completos o una interfaz/puerto concreto. Es el mismo bot; solo cambia el chat.

MikroTik: usuario con políticas read,api,rest-api y www-ssl habilitado. Arista: usuario de privilegio 1 con management api http-commands encendido. Las OLT V-SOL no usan usuario: se leen por SNMP con la comunidad de arriba (en la OLT: snmp-server community <c> ro). Esa comunidad la usa el NOC para sondear las OLT, descubrir sus direcciones (IPAM), verificar sus reinicios programados y rellenar «Preparar el equipo»; MikroTik y Arista no usan SNMP.

Si un equipo usa otra credencial, ponla en su ficha (Editar → Credenciales de este equipo) o con user/password en inventory.yml. Las credenciales de consola de las OLT (respaldos) están en Respaldos.

La dirección que los equipos usan para llegar al NOC en los comandos de «Preparar el equipo» (destino de NetFlow y address= del usuario). Debe ser una IP, no un nombre: MikroTik y Arista no aceptan dogcore.fibraslp.com ahí. Si la dejas vacía, se usa el host con el que abriste el panel solo cuando ya es una IP (al entrar por dominio hay que fijarla).

Con «Paquetes de ping» > 1 el equipo cuenta como alcanzable si responde al menos un paquete (un enlace Starlink pierde paquetes sueltos sin estar caído). «Ciclos fallidos» es cuántos sondeos seguidos debe fallar la API antes de alarmar; para un sitio que parpadea, súbelo solo en ese equipo desde su ficha (Editar → «Alarmar tras N ciclos») o con «Aplicar a todo el sitio».

Puerto caído: un puerto de backbone que cae abre una alarma crítica; con la casilla de arriba, cualquier otro puerto habilitado que estaba arriba y lleva caído la espera indicada abre una advertencia (un parpadeo más corto no alarma, y los puertos que ya estaban caídos tampoco). No cuentan VLAN, bridges, loopbacks, los PON de las OLT ni las sesiones PPPoE/L2TP/SSTP/OVPN. Se cierra sola cuando el puerto vuelve o lo deshabilitas.

Errores por puerto: más de ese número de errores por segundo (RX o TX) durante los minutos indicados abre «Errores en puerto» (revisa cable, conector, SFP o dúplex); se cierra tras el mismo tiempo por debajo del 80 % del umbral. 0 la desactiva.

Cada intervalo el NOC lee de cada MikroTik con PPPoE las sesiones (/ppp/active), los bytes de la interfaz dinámica <usuario> (rx = lo que el cliente sube, tx = lo que descarga) y las conexiones simultáneas por IP de origen (conntrack).

Heurística por cliente: sospechoso si el pico de conexiones del día alcanza el primer umbral o el consumo del día (descarga + subida) llega a los GB indicados; revendedor probable si alcanza el umbral crítico de conexiones, o el primero junto con el de consumo.

Un BNG con más de 1,500 clientes puede tener 300,000 conexiones en conntrack (≈ 9.5 MB, cerca de un minuto de lectura): la lectura usa su propio timeout, no el del sondeo. La alarma es de advertencia (clave pppoe_reseller:<usuario>) y se cierra sola cuando el cliente deja de cruzar los umbrales.

Posible equipo infectado (va por encima de revendedor): un revendedor baja mucho; un equipo en una botnet sube (ataques) y abre conexiones que nadie contesta (barridos). Basta una evidencia, con lo de hoy o lo de ayer: un barrido (intentos sin respuesta a telnet 23/2323, SSH 22 o SIP 5060/5061 en una lectura; una sesión SSH o una llamada legítimas sí reciben respuesta); muchas conexiones sin respuesta que además sean buena parte de las suyas; o subir varias veces lo que baja varios días de la semana con un pico de conexiones de sospechoso (sin ese pico la subida sola deja al cliente en sospechoso: puede ser una cámara que sube video). Medido en los BNG reales: un cliente normal tiene 0 a 2 intentos sin respuesta a esos puertos y los infectados de 60 a 900. Alarma pppoe_infected:<usuario> (advertencia) con el nombre del cliente y la evidencia.

Solo se guarda una versión cuando la configuración cambia (si es igual, se anota que se verificó). MikroTik se lee por REST (/export) y Arista por eAPI (show running-config) con el usuario del NOC; para reiniciar o actualizar ese usuario necesita permisos de escritura (MikroTik: políticas write, policy, test, sensitive, reboot).

El contenido de un respaldo solo lo ve un administrador. Un reinicio o actualización que llega más de 15 min tarde (NOC apagado a esa hora) se omite: nunca se ejecuta a destiempo.

Cada intervalo el NOC lee de cada equipo habilitado, sin escribir nada, sus IPs de interfaz e IPv6, las sesiones y los secrets PPPoE, los leases DHCP, el router-id OSPF, los pools y las reglas NAT (MikroTik por REST, Arista por eAPI, OLT V-SOL por SNMP). Lo que se lee nunca pisa lo capturado a mano; los equipos nuevos entran solos en la siguiente corrida.

Las alarmas (ipam_conflict, ipam_pool, ipam_net_full) son advertencias y vienen apagadas: revisa antes los hallazgos en IPAM → Conflictos y hallazgos. El % de una red de acceso cuenta las IPs asignadas por secret aunque el cliente esté desconectado; se cierran 5 puntos por debajo del umbral.

Espejo de una sola vía: DogCore es la fuente de verdad y sobrescribe la sección elegida de phpIPAM (lo que edites a mano ahí se pierde); nunca toca otras secciones. Sube las subredes y las IPs de equipos (interfaces, loopbacks, router-id, WAN y NAT), no los clientes PPPoE.

Por HTTP usa «Usuario + token» y en el config.php de phpIPAM hace falta $api_allow_unsafe = true; el modo «App code» solo funciona con HTTPS. Viene apagado; enciéndelo cuando la conexión esté probada.

Se obtiene en Google Cloud Console (APIs y servicios → Credenciales) habilitando «Maps JavaScript API»; conviene restringirla por referente HTTP a la URL de este NOC. La clave se envía al navegador de los usuarios con sesión para cargar el mapa (nunca aparece en la API de ajustes).

Las colas se leen del router solo mientras alguien tiene abierta la vista Colas (o la pestaña Colas de la ficha); todos los usuarios comparten una sola lectura por router, que se reutiliza los segundos indicados (cuentan desde que termina la lectura, y un fallo también se guarda ese tiempo).

El tiempo máximo cubre la lectura completa (conectar y decodificar); esperar turno tiene otro tope igual, así que en el peor caso la vista espera el doble. Una cola cuenta como saturada cuando su tráfico llega a ese % de su límite.

El rastreo lee en vivo, del MikroTik dueño de la IP, solo las conexiones de esa IP (el filtro lo hace el router). Para saber qué cliente hizo cada consulta bloqueada cruza el puerto público del log DNS con el de cada conexión; como el log llega a Loki con unos segundos de retraso, ese cruce corre aparte y la vista lo recibe al terminar.

El token se crea en Grafana → Administración → Cuentas de servicio, con rol Viewer.

Cada minuto el NOC pregunta a cada IP de cada resolver por un dominio que debe resolver y por otro que tu filtro debe bloquear; mide la latencia y abre una alarma tras los fallos seguidos indicados. La revisión de los MikroTik es solo lectura y genera el script de cada uno; nunca se aplica sola.

Disco: % usado del disco donde vive la base de datos (como df); si se llena, la base se detiene y el NOC deja de medir y de avisar. Se cierra sola al bajar 2 puntos del umbral; 0 desactiva.

Interfaz: la que mide la red (rx/tx) en Diagnóstico → Servidor y en el Inicio. Vacía usa la de la ruta por defecto; si la que escribas no existe, se usa la de la ruta por defecto (o la de más tráfico) y Diagnóstico lo indica.