CreaRack-SL

Pipeline de Discovery (Auto-Provision)

Conceptoactiveverificado 2026-04-21#network#discovery#snmp#ssh#lldp#multi-vendor

Pipeline de Discovery (Auto-Provision)

Qué es

Mecanismo central de CreaRack-Pro para descubrir e identificar dispositivos de red automáticamente. DeviceDiscoveryService hereda de ProvisionStagesMixin y combina hasta 6 etapas secuenciales desde conectividad básica hasta asignación de stencil visual. El resultado es un DeviceProfile con vendor, modelo, versión OS, interfaces, vecinos topológicos y puntuación de confianza.

Por qué existe

Entornos multi-vendor presentan dispositivos con SNMP deshabilitado, credenciales variables y fingerprints heterogéneos. Un único protocolo no basta. El pipeline maximiza tasa de identificación combinando señales complementarias (ICMP, HTTP, SNMP, SSH, LLDP/CDP) y degrada controladamente cuando una etapa falla.

Componentes (los 6 stages)

Stage 1 — Detección de vendor (_detect_vendor): ping ICMP (icmplib.async_ping) + nmap OS detection en paralelo + HTTP banner grabbing en 80/443/8080 + OUI lookup sobre MAC. Consolida señales en un detected_vendor que orienta etapas siguientes.

Stage 2 — SNMP probing (_collect_snmp_data): método principal. Intenta communities priorizando las del vendor detectado (VendorProfileRegistry), seguidas de comunes. Consulta OID sysDescr. Si encuentra community válida: captura completa (sysObjectID, sysUpTime, sysName, walk de ifTable, CPU/memoria). Soporta SNMPv2c, SNMPv3 auth/priv, datos pre-recolectados. Timeout global 60s.

Stage 3 — SSH fallback (discover_ssh): se activa si SNMP no devuelve sys_descr y hay credenciales SSH. Usa scrapli con asyncssh para ejecutar show version, show inventory, show interfaces. Comandos y regex por vendor en VendorProfileRegistry.

Stage 4 — LLDP/CDP discovery (discover_neighbors_snmp): SNMP walk de LLDP Remote Systems (1.0.8802.1.1.2.1.4.1.1.9) y CDP Cache Table Cisco (1.3.6.1.4.1.9.9.23.1.2.1.1.6). Vecinos como [{local_port, neighbor_hostname, neighbor_port}]. Solo modo completo, no quick_mode.

Stage 5 — Stencil matching (match_stencil): 3 niveles por confianza: exact fabricante+nombre (100%), fabricante + fuzzy nombre (60-80%), solo nombre (85%). Fuzzy compara substrings, prefijos, ratio caracteres. Recibe chassis_model, hostname, product_line para cobertura.

Stage 6 — Confidence scoring (calculate_confidence): entero 0-100. Suma puntos: vendor +10, modelo +10, hostname +5, sysDescr +10, sysObjectID +5, os_version +5, interfaces presencia +10, ≥5 interfaces +5, CPU/RAM +5, SSH +10, SNMP/HTTP +5, stencil +5, stencil ≥70% +5, vecinos +5. Base 10 por reachability.

Flujos

Discovery IP única — provision_device(ip, ...) ejecuta los 6 stages en secuencia. Devuelve DeviceProfile persistido. Si encuentra Device existente con la misma IP en management_config, lo vincula automáticamente y propaga interfaces como ports en model_data.

Bulk subnet — bulk_provision_subnet(subnet, ...) expande con ipaddress.ip_network, ping concurrente a todos los hosts, provision_device para cada reachable con semáforo max_concurrent (default 20).

Deep discovery — Con datos pre-recolectados (pre_snmp_data, pre_http_data) desde agente externo, el pipeline salta Stage 1 y 2, normaliza y enriquece con VendorProfileRegistry. Permite colectores out-of-band sin reemplazar la lógica de matching.

  • entity--network--model--deviceprofile — modelo que persiste resultado.
  • entity--network--model--vendorprofile — registros con patrones SNMP/SSH/HTTP.
  • entity--network--model--custommib — MIBs personalizadas para extensión del Stage 2.

Véase también

  • [[entity—network—model—deviceprofile]]
  • [[entity—network—model—vendorprofile]]
  • [[entity—network—model—custommib]]