Questions, answered

Lantern maps a network's switches, firewalls and access points, and the devices behind them, from what those devices already know: neighbour tables, MAC tables, VLANs and spanning tree. It finds loops and traces where they start, finds unmanaged switches hiding behind access ports, keeps an inventory, scores best practice, and monitors SNMP values. See the product tour.

IT teams and managed service providers who look after switched networks and want an accurate, current picture of them without logging in to one switch at a time.

The full collector: the map, loop and unmanaged-switch detection, inventory, health and best-practice checks, SNMP monitoring with alerts and notifications, change history, reports, recorded SSH sessions, and sign-in with local accounts, LDAP / Active Directory or cloud identity providers. It also includes a simulated network to explore. Lantern is in a private preview: request a demo to see it and get access.

Yes. Every build includes a simulator: a 13-device sample network you can break on purpose (a loop, a pulled cable, a device powered off) and watch recover. On Windows, double-click Start Lantern (demo).cmd. See Simulator and test faults.

No. You install the Lantern collector on a Windows or Linux machine inside the network you want to map. It polls your devices and serves the web UI itself. Your network data stays on that machine, and Lantern sends nothing to us.

A 64-bit Windows 10, 11 or Server 2016+ machine, or 64-bit Linux (x86-64 or ARM64) with systemd, that stays on and can reach your devices over SNMP. It is one self-contained program with the web UI built in; there is nothing else to install. See Requirements.

A collector maps the devices it can reach and that you list or let it discover, so one collector can cover several sites joined by your WAN. Each collector shows one customer and site name, and keeps its data, keys and accounts to itself; for separate customers, run separate collectors.

No. Lantern learns about endpoints from your switches' MAC tables, named through DHCP and ARP where available. Nothing is installed on endpoints.

You choose: the example configuration polls every 5 minutes, and anything from 15 seconds up works. Loops are confirmed from your switches' syslog as they happen, whatever the interval; without syslog, Lantern can only show possible loops.

Lantern reads standard MIBs, so most managed switches, routers and firewalls work. It understands vendor specifics for Cisco, HPE Aruba (ProCurve/AOS-S, CX and Comware), Juniper, Fortinet and Ubiquiti UniFi. Validation against real equipment is ongoing during the preview.

Not on its own. The SNMP collector sends GET, GETNEXT and GETBULK and never SET, and an automated test fails if any code adds a device write path. The optional SSH sessions are opened and typed by a technician, and recorded. See Security.

SNMP v2c and v3. SNMPv3 with authentication and privacy (SHA or SHA-2 and AES) on a read-only view restricted to the collector is recommended. See Configure the collector.

A loop is declared only when several signals agree: MAC addresses flapping, broadcast storms, a switch seeing its own frames or hearing its own LLDP, loop protection triggering, or links coming up at that moment. A single MAC address moving is never enough. See Loops and unmanaged switches.

No. Lantern points at the port where the loop most likely starts and tells you what to do; a person makes the change. Lantern never changes a device on its own.

With a local Lantern account, their LDAP / Active Directory account, or a cloud identity provider: Microsoft Entra ID, Google Workspace, Okta, or any OpenID Connect provider (Auth0, Keycloak, JumpCloud, Duo and others). See Sign-in and roles.

Through your identity provider: with cloud sign-in, people sign in at Entra ID, Google or Okta with that provider's MFA and Conditional Access. Local and LDAP accounts use a password only in this preview.

Three roles: Viewer sees everything and changes nothing; Operator also polls, opens SSH sessions, manages monitors and maintenance; Administrator also manages settings, checks, notification channels, sign-in and users. Directory and cloud accounts get their role from your groups.

No. For LDAP, the directory checks the password; for cloud sign-in, Lantern never sees it. Local account passwords are stored as bcrypt hashes. The LDAP service account's password and cloud client secrets are stored encrypted on the collector.

Secrets you type into the collector configuration are encrypted (AES-256-GCM) the next time Lantern starts, with a key kept in a separate file. They are never shown again in the web UI.

Yes: every sign-in, failed attempt, sign-out and change to sign-in settings or accounts is recorded, as are monitoring changes and every SSH session with its commands and a redacted recording.

Not yet. Preview builds are not code-signed; verify each build against the SHA-256 checksum that comes with it. Signing comes with the release.

Not yet. In the preview, end-of-sale and end-of-support dates and recommended firmware come from a sample catalogue. Lantern labels them Sample data in inventory, reports and CSV exports; the Health page's Recommended firmware and Supported hardware checks use the same catalogue but are not labelled yet. Verify dates with your vendors before planning replacements.

Monitoring history (samples, alerts and events) is stored on disk and survives restarts. In the preview, the topology change history (snapshots you can compare on the map) is kept in memory and starts again after a restart. Sessions also end, so people sign in again.

Stop it, copy its data folder, start it again. The folder holds the configuration, accounts, monitoring database and the encryption keys, so store backups carefully. See Backups and updates.