Technical Overview

Lightweight agents. Deep discovery. Real data.

NetLoom uses a distributed agent model to collect structured network data using the protocols your devices already speak — SNMP, ICMP, SSH, WinRM, Redfish, and more — and organizes it into a coherent inventory and topology model.

Architecture

Agents at the edge. API at the center. Data model underneath.

Each site runs a NetLoom agent that performs local discovery. Agents communicate with the NetLoom cloud API over HTTPS using SignalR for real-time coordination. All data lives in NetLoom's cloud-hosted PostgreSQL database with TimescaleDB for time-series observation logs.

ARCHITECTURE DIAGRAM — Agent to API Data Flow
AI image prompt Technical system architecture diagram on dark navy background. Left column shows two "Edge Site" boxes, each containing a small server icon labeled "Agent" with a small SQLite database icon below it. Center column shows "NetLoom API" box with .NET runtime icon. Right column shows "Web UI" box and below it a "PostgreSQL + TimescaleDB" cylinder. Arrows flow left to right. Clean, minimal, monochrome accent colors (blue and orange), no text readable in the image, just iconic representations.
Edge Agents collect and cache locally
API coordinates, stores, and serves
NetLoom Agent Lightweight .NET service. Runs on Windows or Linux. Performs local discovery using network protocols. Caches results in SQLite. Communicates with the API via SignalR over HTTPS.
NetLoom API ASP.NET Core API. Coordinates agents, manages job dispatch, stores structured discovery results. Handles credential storage and serves all data to the web UI.
Web UI React frontend. Inventory, topology, device detail, agent management, and operational workflow. No separate install — served directly from the API container.
Discovery protocols

Built on the protocols your network already speaks.

NetLoom agents use a stack of discovery and enrichment methods to build accurate, structured device records. No proprietary protocol or custom agent is required on the managed devices.

Core Discovery SNMP v1 / v2c / v3

Primary discovery method. Collects system identity, interface tables, routing data, ARP/FDB tables, LLDP and CDP neighbor lists, VLAN memberships, and device-class MIBs for routers, switches, and access points.

Reachability ICMP Ping

Used for initial host sweep across subnets and for ongoing reachability confirmation. Forms the basis of the discovery queue before richer enrichment begins.

Host Discovery ARP Sweep

Private ARP cache sweep discovers hosts on local subnets that do not respond to ICMP, providing MAC address to IP mappings before protocol-level enrichment.

Port Intelligence Port Scanning

Targeted port scanning and service fingerprinting identify open services, application roles, and device classification signals when SNMP or other management protocols are not available.

Remote Management SSH

Used for deeper enrichment on Linux hosts, network devices with SSH management, and command-line interfaces that expose richer platform data than SNMP alone.

Windows Management WinRM

Windows Remote Management enables PowerShell-level inventory on Windows hosts — hardware components, installed software, VM guest and host relationships, and detailed system metadata.

Server Management Redfish

DMTF Redfish API support enables inventory of server BMCs and out-of-band management interfaces on modern server hardware, including health, firmware, and hardware component data.

Specialized Polycom / Video

Purpose-built collector for Polycom video conferencing devices enables structured inventory of AV/UC infrastructure that standard SNMP discovery often misses or misclassifies.

VLAN Intelligence VLAN Extraction

VLAN membership data is derived from SNMP bridge and Q-bridge MIBs, including dot1q VLAN FDB table mapping, native VLAN detection, and tagged/untagged port membership tracking.

Screenshot

Device detail with enriched interface and SNMP data.

A single device page carries everything collected by discovery: interfaces, IP addresses, VLAN memberships, neighbor relationships, credentials, and observation history.

SCREENSHOT — Device Detail with SNMP Interface Data
AI image prompt Dark-themed network device detail panel for a Cisco switch. Header shows: hostname, IP address (192.168.1.1), device type badge (Switch), manufacturer (Cisco), and OS version. Below: tabbed sections. Active tab shows interface table with columns: interface name (GigabitEthernet0/1), type, speed, status (Up/Down badge), MAC address, VLAN, and peer device. Adjacent panel shows SNMP system data: uptime, location, contact, and OID. Professional enterprise SaaS UI, dark navy background, blue accent.
Data model

A coherent hierarchy from location to interface.

NetLoom organizes discovery data into a structured relational model. Every device, interface, and observation has context: the location it belongs to, the network it was found on, the agent that discovered it, and the credentials used to enrich it.

1

Locations

Top-level organizational unit. A location maps to a physical or logical site — an office, data center, customer environment, or remote site.

2

Networks

Each location contains one or more IP networks defined by CIDR range. Discovery runs against these networks to produce the device inventory for that site.

3

Devices

A device represents a discovered host — router, switch, server, workstation, printer, IP camera, or any other networked asset — with identity, status, and metadata.

4

Interfaces

Every device carries its observed interfaces: name, type, MAC address, IP bindings, VLAN membership, speed, and state — derived from SNMP interface table data.

5

Topology

Neighbor relationships between devices are inferred from LLDP, CDP, and FDB table data collected via SNMP, building a link-layer topology graph with port-level precision.

6

Observations

Each discovery run creates timestamped observation records stored in TimescaleDB, enabling history, change detection, and trend visibility over time.

Screenshot

Topology graph with interface-level relationships.

The topology view is built from structured LLDP, CDP, and FDB data — not guesswork. Every edge in the graph corresponds to a real observed interface relationship.

SCREENSHOT — Topology Graph View
AI image prompt Dark-background interactive network topology visualization. Nodes are circular with device type icons (router, switch, server, access point, workstation). Edges are labeled with interface names (e.g., Gi0/1). Selected node is highlighted in blue glow. Sidebar on the right shows interface list for selected node. Layout uses a tree structure with a core switch at center. Dark navy background, blue primary colors, orange highlight for active/selected elements.
Agent deployment

Deploy anywhere your network is.

NetLoom agents are self-contained .NET services distributed as single-file executables. They install as a system service, cache discovery data locally in SQLite, and connect to the central API when available. No runtime dependencies are required on the target host.

Windows (x64)

Installs as a Windows Service. Supports WinRM-based enrichment of the local machine, SNMP discovery of neighboring devices, and PowerShell-level hardware inventory.

Linux (x64)

Runs as a systemd service on any x86-64 Linux host. Suitable for server-hosted agents in data centers or headless deployment on network management servers.

Linux ARM

ARM build supports Raspberry Pi and similar single-board computers. Deploy an agent at a branch office or remote site using inexpensive edge hardware.

Edge sites

Agents operate independently if the WAN link to the central API is interrupted. Pending observations are queued locally and synchronized when connectivity is restored.

Screenshot

Agent fleet and health overview.

See every deployed agent, its target platform, online status, version, last contact time, and discovery history from a single management view.

SCREENSHOT — Agent Fleet and Health Overview
AI image prompt Dark-themed enterprise agent management table. Each row represents a deployed agent with columns: agent name, location (Main Office, Branch A, etc.), platform (Windows x64 / Linux x64 / Linux ARM badge), status (Online/Offline badge with green/red dot), version number, last seen timestamp, and device count discovered. Action column shows Update and Restart buttons. Table header has search bar. Dark navy background, blue accent colors, professional SaaS UI.
Security and credentials

Credentials stay encrypted and scoped.

NetLoom maintains a credential vault for SNMP community strings, SNMPv3 auth/priv settings, SSH keys and passwords, and WinRM accounts. Credentials are stored encrypted, scoped to specific networks or devices, and never transmitted in discovery logs or topology data.

Credential vault

SNMP v1/v2c community strings, SNMPv3 auth and privacy settings, SSH credentials, WinRM accounts, and device-specific login profiles are stored with encryption at rest and scoped by network or device group.

Protocol-aware scoping

Credentials are matched to discovery targets by protocol and network scope. The right credentials are applied to the right devices automatically, without manual per-device assignment.

Isolated cloud data boundary

All credential material, discovery results, and network topology data are stored in a dedicated, encrypted environment within the NetLoom cloud platform. There is no cross-tenant data access and no third-party data pipeline involved.

Audit trail

Discovery jobs, credential tests, and enrichment runs produce structured log records with timestamps and outcomes, providing a traceable history of what was accessed and when.

Technology stack

Built on proven, production-grade components.

Backend ASP.NET Core (.NET 10)

The NetLoom API and agent runtime are both built on .NET 10. High performance, cross-platform, and well-suited to long-running service and background job workloads.

Frontend React + TypeScript

The web UI is a React TypeScript application with TanStack Table for data-dense inventory views and a custom design system tuned for operations workflows.

Database PostgreSQL + TimescaleDB

Application data lives in PostgreSQL via Entity Framework. Time-series observation logs use TimescaleDB hypertables for efficient retention and range queries over discovery history.

Agent storage SQLite (local cache)

Each agent maintains a local SQLite database for caching pending observations and configuration state. This ensures agents remain operational if the central API is temporarily unreachable.

Real-time SignalR over HTTPS

Agent-to-API communication uses ASP.NET Core SignalR for real-time bidirectional coordination — job dispatch, status updates, and discovery result streaming — over a single HTTPS connection.

Hosting Managed cloud platform

The NetLoom API, database, and web UI are hosted and operated by NetLoom. Customers install a lightweight agent at each site — no server provisioning, no platform maintenance required.

Preview opens July 1, 2026

Ready to evaluate? Get in early.

Request preview access and get 50% off the first year. Technical teams get priority for early slots.