Skip to content

Discovery

Discovery scans the customer network via the collector, identifies devices from multiple sources (nmap, ARP, SNMP, mDNS, SSDP, LLDP, CDP, routing) and suggests profiles. If you don't want to create the found devices by hand, let Automatic setup turn them into hosts with checks.

Page structure

Five tabs: Overview · Set up automatically · Devices · Scan history · Settings. The "Devices" tab carries a number: all devices found so far — exactly what the tab lists under "All". The header shows the number of connected collectors and a docs link; with more than one tenant, a tenant multiselect appears.

On a fresh installation the page shows, instead of "no collector configured", that the Active Collector (still called by its old name "Check-Executor" in that message) is being set up automatically — usually 1–3 minutes after the setup wizard. If that fails, the error is shown there with a link to the admin page.

Overview

KPIs

KPI Meaning
Networks detected number of known subnets, plus "of which N actively watched"
Total devices all devices found so far
Coverage handled ÷ found, in % — below it "all handled" or "N unhandled"
New (7 days) new devices in the last week

Actions

  • "Find devices (scan)" (primary) — opens the scan dialog. Disabled while no collector is online or a scan is already running.
  • In the Networks section, right next to the list:
    • "Find networks automatically" — not a device scan: the collector checks which networks it knows (its own interfaces, routing table, ARP, SNMP on the gateway, on layer-3 switches and on SNMP devices that are already monitored). The result is shown right at the button ("Done — N new networks found", "no new networks", or the failure reason). Needs an online collector.
    • "Add network" — for networks the collector doesn't see on its own (collector, CIDR, optional label). An added network appears in the list immediately; it doesn't need a running collector, only a configured one.

The network search doesn't run on its own

"Find networks automatically" starts by itself only once, when a collector reports in for the first time (the Active Collector after installation included). After that only on click, or before a scheduled scan if "Refresh subnets first" is ticked in the schedule. Up to v1.9.436 the search additionally ran daily on its own — from v1.9.437 it no longer does; existing collectors don't trigger a new search after the update.

The SNMP part of the network search doesn't need a separately maintained community: Vesana tries the communities learned on the collector (most successful first), then the tenant's credential sets (SNMP v2c), and finally public.

Below the networks, the overview lists "New devices" of the last 7 days with the same actions as in the Devices tab; "Show handled" also includes devices already added or ignored.

Networks (subnet list)

Each row shows: status icon, CIDR (mono), an optional label, an "excluded" pill if applicable, source badges, a coverage bar (monitored/total, color-graded) and a lightning-bolt button "Scan this subnet". Clicking the row opens the subnet drawer.

Filters: collector dropdown, "show/hide excluded", search over CIDR/label.

Subnet drawer

Two tabs:

  • Details — set a label, sources with confidence, history of scans in this network, "Scan this subnet now", "Exclude subnet" (with an optional reason; hosts already monitored stay monitored, only further discovery stops) and "Delete subnet from the list". Deleting removes the network including its sources and label from the detection list — devices and hosts are untouched. If the collector still sees the network, it reappears on the next network search; keeping it out permanently only works via "Exclude".
  • Devices — all devices found in this network with status (Monitored / New / Ignored) and "Open host" for monitored ones.

Source tags per subnet

Tag Origin Confidence
Interface local NIC of the collector VM Very reliable
Route routing table of the collector VM Very reliable
Manual entered by the operator Very reliable
SNMP route routing table via SNMP from the gateway Reliable
SNMP ARP ARP table (ipNetToMediaTable) via SNMP Reliable
LLDP reported by the switch Reliable
CDP Cisco Discovery Protocol Reliable
mDNS passive Bonjour capture Guess
SSDP passive UPnP capture Guess
Traceroute derived from traceroute hops Guess
Scanned seen directly in the last active scan Very reliable
Ping sweep pure ICMP response Reliable
Implicit (host) a host references the subnet, but it was never directly observed Implicit
Implicit (scan) side effect of a scan in an adjacent network Implicit

Color code: implicit tags grey, passive sources (mDNS/SSDP/traceroute) amber, everything else in the accent color.

Not finding all networks?

Common reasons:

  • The gateway doesn't answer any of the known communities → add the matching community in the SNMP settings or as a credential set, then click "Find networks automatically" again
  • LLDP disabled on the switch → enable it on the switch, or add the network manually
  • The route doesn't go via the collector VM → add it as a manual subnet, then you can still scan it

Starting a scan

"Find devices (scan)" opens the scan modal:

  1. Collector picker (multi-select, grouped by tenant). Selecting more than one collector shows an amber warning with a type-to-confirm (type exactly "N COLLECTORS").
  2. Estimate grid: number of subnets (plus "N excluded"), number of sub-jobs (/24 chunks — red if over 256 per collector), total IPs (~), estimated duration (parallel).
  3. "Advanced options (change scan profile)" — three profile cards, see below. Default is Normal.

Hardcap of 256 sub-jobs per collector

A /16 network is 256 /24 chunks — more sub-jobs per collector than that is rejected by the server. Split large networks into smaller scans first.

Scan profiles

Parameter Stealth Normal Aggressive
Rate limit (pps) 50 200 1000
Parallel /24 subnets 1 (sequential) 4 16
Service ports 22, 80, 443, 3389 (SSH, HTTP, HTTPS, RDP) 22, 80, 443, 3306, 3389, 5432, 6379, 8080 (+ MySQL, PgSQL, Redis, app server) 24 ports, incl. FTP, Telnet, SMTP, DNS, SNMP, LDAP, SMB, JetDirect
Bandwidth peak ~30 kbit/s ~120 kbit/s ~600 kbit/s
Load low medium high
IDS visibility low medium high
Type-to-confirm no no exactly "AGGRESSIV" (danger button)

What's identical across all profiles: the host-discovery phase (ICMP echo + TCP probe) runs the same for all three profiles — the differences are in rate, parallelism, and the following service-port list. If an SNMP community is known, every found host is classified equally precisely via sysOID/sysDescr in every profile — Stealth only saves on TCP ports, not on device identification itself. Vendor banners and device certificates are evaluated on all probed ports.

Pure SNMP-only/DNS-only devices with no open TCP port and blocked ICMP aren't found by any profile — those need to be added as a host manually.

Which profile for what

  • Stealth — production with an active SOC, banks, hospitals, regulated environments.
  • Normal — office networks without a hard IDS, standard customer setup.
  • Aggressive — greenfield inventory, lab, maintenance window with IDS whitelist, fast audits.

Device lifecycle

Every found device has one of four states: new, known, added, ignored. The "Devices" tab bundles them into four segments:

Segment Contains
Untreated new + known
Ignored ignored
Added added
All everything, including ignored devices

The list refreshes itself every 15 seconds. The search understands IP, hostname, device type ("synology", "mikrotik") and tenant. Long lists are capped at 500 entries — narrow the search then.

Per row: "Add" opens the host form pre-filled (IP, hostname, matching mode, suggested profile — see Adding hosts), "Ignore" moves the device into the Ignored segment, "Stop ignoring" brings it back — both without a reload.

If a device is already created as a host, instead of the actions you get an "Open host" button plus a green "Added" pill — prevents accidental duplicates. If automatic setup is currently handling a device, the row says "in automatic setup".

Bulk: checkboxes + "Add selected (N)", "Ignore". Select-all only picks the visible/filtered rows; in the "All" view, bulk actions only affect untreated devices. Bulk adding checks the license host limit for the whole selection and, if exceeded, tells you how many slots are free — no host is created in that case.

Device name

A found device carries its name, not just an IP — even without credentials. Vesana evaluates several name sources and takes the most reliable one, in this order:

  1. Reverse DNS
  2. SNMP (sysName)
  3. LLDP (reported by the neighbouring switch)
  4. RDP certificate (Windows)
  5. SMB
  6. mDNS
  7. NetBIOS (only within the same subnet)
  8. TLS certificate
  9. Web redirect

A weaker source never overwrites a better one: if the DNS server doesn't answer during a later scan, the cleanly resolved name stays. Placeholders such as "localhost", "WORKGROUP" or factory names never end up as the device name. The origin is shown in the tooltip ("Name from DNS", "Name from the RDP certificate", …).

If the names live on a DNS server inside the customer network (e.g. the domain controller) that the collector VM doesn't use as its resolver: Settings → "DNS servers for name resolution" per collector — IP addresses separated by commas, effective from the next scan. Empty means the collector resolves via its own system configuration.

Identity

Whether and what a found device "is" shows up as the identity traffic light — computed at read time, not a stored truth that can go stale.

The light is deliberately two-stage: confirmed and likely both show green, a mere hint shows amber. There is no red identity light — an uncertain guess is never shown as an error.

The badge shows a colored dot, a concrete label ("Windows", "Proxmox VE", "MikroTik RouterOS", "MikroTik Switch", …) and, in the tooltip, the evidence (strongest first, e.g. "port 3389 (RDP) open"). A single open standard port such as 443 never counts as a strong vendor signal, and a confidently identified identity (e.g. Debian) wins over ambiguous rule matches. Without any evidence it reads "Unknown device (responds to ping)".

VM detection runs orthogonally: if Vesana detects that a device runs on a hypervisor, the badge gets a suffix — e.g. "· VM on Proxmox" (likewise for QEMU-KVM, VMware, Hyper-V, VirtualBox, Xen).

If the profile classifier has a concrete guess, a dedicated profile-suggestion pill (with its own confidence, including conflict status) replaces the identity badge. After importing a community profile, further devices of the same type remain unambiguous — the local copy doesn't compete with the hub entry.

Ghost filter

Discovery automatically filters out known network artifacts — entirely collector-side, no user control. Only provable artifacts get dropped: a proxy-ARP MAC address responding for more than three IPs, or blanket RST-response sweeps. A device that merely responds to ping behind a firewall stays visible — the filter is deliberately conservative and never drops too much.

Scheduled scans

In the Settings tab, per collector: "Scheduled scans" with a toggle "Scheduled scanning active". All times are entered in local time (stored as UTC internally).

Three modes:

Mode Configuration
Interval every N hours (presets: 1/2/4/6/8/12/24 h, 2/3 days, 1 week)
Daily fixed time (hour + minute, 5-minute grid)
Weekly weekdays (multi-select, at least one) + time

A plain-text summary shows e.g. "Scans daily at 02:00…" plus "Last run"/"Next scan". Plus a scan profile dropdown (Stealth/Normal/Aggressive) — the scheduled scan runs across all non-excluded subnets of the collector and uses the same SNMP communities as the network search (learned communities, credential sets, public).

"Refresh subnets first" (checkbox, off by default; from v1.9.437): before every scheduled scan the collector first looks for new networks and then scans the fresh list. Without the checkbox only the already-known subnets are scanned.

If the collector is offline at the scheduled time, Vesana doesn't create a scan job that would never run — the scan starts once the collector is back.

New-device alerts

Also in Settings: "new device" alert rules. A rule fires a notification once per genuinely new device at scan time — not on every subsequent sighting of the same device.

Per rule:

  • Name
  • Collector (optional — empty = all)
  • Subnet/CIDR (optional — empty = all)
  • Notification channels (multiselect)
  • Toggle active/inactive, delete

Rules apply tenant-wide. Only new devices from final scan results are evaluated — intermediate results from the first scan phase don't trigger an alert yet. Result and errors when saving are shown directly in the card.

Multi-source discovery

The collector combines several sources instead of relying on one:

  • Active nmap scan — first ping/ARP sweep, then port/SNMP/TLS/HTTP/SSH fingerprinting
  • Interface and route — local network config of the collector VM
  • SNMP route (gateway routing table) and SNMP ARP (ARP table via SNMP)
  • LLDP — neighborhood reported by the switch
  • Ping sweep — pure ICMP
  • Passive mDNS/Bonjour, passive LLDP and CDP (Linux-only), passive SSDP/UPnP

Passive listeners are opt-in — they only listen, never send anything themselves.

Scan history

The history is paginated (25 per page) with a status filter All · Running & waiting · Done · Failed. Each row shows tenant, collector, exact start time, duration, probed ports, SNMP community used, retries and, on failure, the error text; partial scans of a "Scan everything" run are marked as such. Delete asks directly in the row ("Delete scan + results?").

While a scan is still running, the row shows e.g. blue "N devices found – gathering details…" or "Searching devices…".

If a scan is waiting, the reason shows in amber:

  • Collector update pending — "Waiting for collector update ({vX → vY}) – starts automatically afterwards." A staged scan is held back while the collector is older than the version intended for that scan — this prevents an auto-update from killing the running nmap process.
  • Collector offline — "Collector offline – scan waiting to be picked up."

SNMP settings

Three places that work together:

  • Per collector (Settings → "SNMP communities"): add a community (default "public"), stored encrypted (shown as ***), with a success/fail counter — communities are tried in order of success rate. For a new entry to take effect in the network search, click "Find networks automatically" afterwards.
  • Per tenant (credential sets, type "SNMP v2c"): tried after the collector communities in scheduled scans and the network search. SNMPv3 sets are used by Automatic setup; discovery classification itself speaks v1/v2c.
  • Platform-wide (super admin only, Settings → "Platform defaults", collapsed): "Default community for new collectors" plus toggles "ICMP pingsweep active" / "read ARP cache" / "mDNS / SSDP listener (passive)".

Excludes & manual subnets

  • Excluded subnets are created from the subnet drawer; the list lives in Settings. A /16 exclude also blocks all its underlying /24 subnets (CIDR inheritance).
  • Manual subnets are entered via "Add network" — they carry the source tag "Manual" and can be removed again in Settings.

Reset instead of automatic purge

No automatic time-based purge

Discovery results and scan history are not deleted automatically by age. Cleanup is always a deliberate action:

  • a single scan can be deleted in the scan history, or
  • Reset discovery (Settings, per collector): "Reset…" and then "Reset permanently" — one click to confirm, no confirmation phrase. Wipes scan results (new, known, ignored), the scan history and "Scan everything" runs of this collector. Kept: hosts (including those created from discovery), SNMP communities, excludes, manual subnets and the observed subnet sources. The result ("Reset done — N scans deleted") is shown directly in the card.

Prerequisites

  • At least one collector in the customer network — or the Active Collector on the Vesana server, which counts for every tenant but only sees the networks the server itself reaches. See Collector.
  • nmap on the collector — auto-installed by the installer
  • SNMP community for the target devices, if SNMP classification is wanted

Discovery for agent-capable hosts

Discovery detects the existence of a Linux/Windows server (ICMP, SSH banner, RDP, SMB, SNMP if active), but can't install an agent. Two ways:

  • By hand: create the host (straight from the device list via "Add") → generate an agent token → roll out the token on the machine.
  • Via Automatic setup: for detected Windows/Linux machines the task "Install agent" appears with a ready-made install command; once the agent reports in, Vesana creates the checks.

Tips

  • Subnet size: /24 scans fast, split a /16 or run it with the aggressive profile
  • Set an SNMP community early — otherwise devices stay "unknown device" even though SNMP would be available
  • Scheduled scans instead of manually repeating — see above
  • Missing a VLAN? First "Find networks automatically", then "Add network"

Next