Para qué sirve
Hasta esta versión, el escáner automático de red reconocía cada equipo por su dirección IP. Si un equipo cambiaba de IP — por ejemplo un punto de acceso reconfigurado, o que recibía una IP distinta del servidor DHCP — la próxima vez que se escaneaba la red aparecía como un dispositivo nuevo: la ficha antigua se quedaba huérfana y había que borrarla a mano. Pasó de verdad con un punto de acceso Xirrus XR8 del CCIB.
Decisión de Edu (14-09-2026, task #314): lo que identifica de verdad a un equipo es su MAC, que no cambia — no su IP. Ahora, al re-escanear, si la MAC ya vive en otro perfil de la misma organización con otra IP, ese perfil se actualiza con la IP nueva (reutilizando el mismo servicio de cambio de IP de la v1.132.5, feature--network--edit-ip-desde-ficha si existiera — aquí network/services/readdress.py::change_profile_ip) en vez de crear una copia.
Dos matices a propósito:
- Dos IP de gestión reales: si la misma MAC aparece en dos IP DENTRO de la misma pasada de escaneo por lotes (un equipo con varias interfaces de gestión), no se re-direcciona ninguna — son dos direcciones vivas de verdad, no un cambio.
- Colisión no resoluble: si la IP nueva ya tiene su propio perfil, no se borra nada — el equipo sigue el camino normal, por IP, como antes.
De paso, la misma pasada resuelve dos flecos relacionados:
- Un perfil ya vinculado a una sonda de Observatory (monitorización) refresca su nombre/SNMP/tipo de equipo en cada re-escaneo, en vez de quedarse con el dato de la primera vez.
- Si un equipo ya conocido tenía un informe detallado (Deep Discover) y el re-escaneo se lo invalida — pasa cuando el equipo habla SNMP —, el propio sistema lo vuelve a pedir solo, sin que haga falta entrar a la ficha y pulsar el botón otra vez. Solo ocurre cuando hay un Agente local con conexión en vivo (WebSocket); en el modo de respaldo por HTTP no hay nadie esperando la tarea.
Límite honesto: un equipo con dos IP de gestión cuyas interfaces tienen MAC distintas puede seguir saliendo duplicado — el reconocimiento va por MAC, y si son dos MAC de verdad, el sistema no tiene forma de saber que es el mismo equipo físico.
Cómo se usa
No hay ningún paso nuevo para el usuario: el comportamiento es automático en cada escaneo (equipo único o lote/subred) del asistente de Auto-Provision. Lo único visible es que un equipo que cambió de IP ya no aparece duplicado, y que su sonda de Observatory y su Deep Discover se mantienen al día solos.
Implementación
- Identidad por MAC — nuevo módulo
network/services/device_discovery/mac_identity.py:normalize_mac()reduce cualquier formato de MAC (AA-BB-CC-DD-EE-FF,aabbccddeeff,aa:bb:cc:dd:ee:ff) a una forma canónica, y descarta la MAC nula (00:00:00:00:00:00);mac_query_variants()genera las formas en que perfiles antiguos (guardados sin normalizar) pudieron quedar en base de datos, para que la búsqueda los encuentre igual. - El re-direccionado — nuevo módulo
network/services/device_discovery/rescan_hooks.py:readdress_profile_by_mac()busca la MAC en otros perfiles de la organización y llama achange_profile_ip()cuando hay un único candidato inequívoco;refresh_linked_observatory_target()reutiliza elAutoConfigService.configure_observatory()ya idempotente;auto_deep_discover_after_rescan()relanza el Deep Discover comprobando primero si hay un Agenteprimarycon WebSocket activo (has_online_ws_agent). - Punto de entrada —
network/services/device_discovery/provision_stages.py::_persist_profilenormaliza la MAC, llama areaddress_profile_by_macantes delupdate_or_create, guarda si el perfil ya tenía datos de Deep Discovery ANTES del re-escaneo (porque el propio escaneo puede borrarlos), y encadena los tres ganchos tras persistir. Nuevo parámetrobatch_ips: set[str] | Noneque viaja desdenetwork/api/discovery.py::bulk_enrich_hostspara detectar el caso de dos IP en la misma pasada. - Despacho del Deep Discovery extraído a servicio propio —
network/services/deep_discovery_dispatch.py::dispatch_deep_discovery()es la misma lógica que antes vivía solo dentro del endpointnetwork/api/discovery.py::deep_discover_profile(resolución de vendor, OIDs, envío por WebSocket o fallback REST); ahora la reutilizan tanto el botón manual “Deep Discover” como el re-escaneo automático. - Tests:
tests/network/test_discovery_mac_identity.py(289 líneas) cubre normalización de MAC, re-direccionado con un único candidato, el caso de dos IP en la misma pasada, colisión no resoluble, y el refresco de Observatory.
Commits relacionados
72e717c0— feat(network): el auto-discovery identifica un equipo por su MAC (v1.132.6, 2026-09-14, task #314, PR #536).
Véase también
- [[feature—network—auto-provision-snmp-community-order]]
- [[feature—network—discovery-audit-sa1]]
- [[feature—network—autoprovision-refresh-dispositivo]]
- [[feature—network—auto-provision-refresh-agent-fix]]
- [[crearack—monitoring—deep-discovery]]
- [[incident—20260907—ccib-comando-bloqueante-websocket]]
- [[crearack-tech—backend—auto-provision-guide]]