Building an L2 Network Map: 6 Tools That Find Switch Connections for You

1. Diagnosis

You added a switch to the network back in 2019. Then five more in 2021. You drew the diagram in Visio once, on install day. Since then everything in the rack changed, and that file sits on the desktop of an admin who quit a year ago. Sound familiar?

This is usually how every incident starts where you need an L2 network map: the physical topology of switches, ports and MAC addresses that nobody keeps up to date by hand, because keeping it up to date by hand is simply not possible.

We’re breaking down six tools that build this map automatically over SNMP, CDP and LLDP. Each one comes with real strengths and real spots where it breaks down. At the end you get a step-by-step install of the one that best earns its “free” label.

What you’ll get out of this:

• A clear picture of how an L2 map differs from a regular network diagram
• A comparison of 6 tools on criteria that actually matter, not marketing fluff
• A working NetDisco setup from scratch on Ubuntu, with verification steps and the usual gotchas
• Short recipes for the other five options
• A security checklist for SNMP that people tend to skip
• What to do when the map builds but connections between switches don’t show up
• How to pick a tool for your network size and budget

Reading this will take about 40 minutes, and your first working install about an hour and a half. You’ll need a Linux host or VM for NetDisco, SNMP access on your switches, and patience: LLDP on older switches doesn’t always come up on the first try.

2. Why you still don’t have an L2 map

It’s not as bad as you think. It’s worse: several of these reasons hit at once, and the map fails to build not because of one problem, but because of three stacked on top of each other.

3. Recipe: installing NetDisco and building your first L2 map

I picked NetDisco as the main recipe for a reason. It’s open source, has been around since 2003, is still maintained, and does exactly what you need for L2: SNMP polling, CDP/LLDP neighbor discovery, MAC tables, ARP, all stored in PostgreSQL with a web interface on top.

System requirements

Port table

Architecture

Prep: enabling SNMP and LLDP on your switches

Without SNMP and LLDP/CDP enabled on the switch side, NetDisco only sees an IP address and nothing else. Prepare your environment first.

snmp-server community netdisco_ro RO
cdp run
cdp timer 30
cdp holdtime 90

/snmp community
add name=netdisco_ro read-access=yes write-access=no

/snmp
set enabled=yes contact="admin@it-apteka.com" location="server-room"

/ip neighbor discovery-settings
set discover-interface-list=all

Step 1. Install dependencies

Update packages, install PostgreSQL and the system libraries the Perl modules need to compile.

sudo apt update && sudo apt upgrade -y
sudo apt install -y postgresql postgresql-contrib build-essential libsnmp-dev snmp git curl

Result: the postgresql service should come up, check it with systemctl status postgresql.

Step 2. Create a user and a database

NetDisco doesn’t run as root. Create a separate system user and a separate PostgreSQL user, this isn’t just a formality from the docs, it’s a baseline security measure.

sudo adduser netdisco
sudo -u postgres createuser -DRSP netdisco
sudo -u postgres createdb -O netdisco netdisco

When prompted for a password for the netdisco role, set a strong one, not a default. Result: psql -U netdisco -d netdisco -h localhost should let you in without access errors.

Step 3. Install NetDisco

Install it via cpanm into the netdisco user’s home directory, without cluttering system paths.

su - netdisco
curl -L http://cpanmin.us/ | perl - --notest --verbose --local-lib ~/perl5 App::Netdisco
mkdir ~/bin
ln -s ~/perl5/bin/{localenv,netdisco-*} ~/bin/

The install takes about 15-20 minutes — dozens of Perl modules get pulled in. Don’t panic: if the process sits silently for more than five minutes, it’s not frozen, it’s compiling XS modules, just wait it out.

Step 4. Configuration

mkdir ~/environments
cp ~/perl5/lib/perl5/auto/share/dist/App-Netdisco/environments/deployment.yml ~/environments/
nano ~/environments/deployment.yml

In the file, set your database connection and the SNMP community you configured on the switches:

database:
  name: netdisco
  user: netdisco
  pass: your_password_from_step_2
  host: localhost

snmp:
  community_ro:
    - netdisco_ro

Step 5. Start it up and add networks to scan

~/bin/localenv netdisco-daemon start
~/bin/localenv netdisco-web

Result: the web interface comes up on port 5000. Go to Admin → Device Discovery, add your management network range (for example 10.10.0.0/24) as a seed for scanning.

The first scan shows CDP/LLDP neighbors and builds an initial graph. The full map with ports and MAC addresses shows up after the second or third polling cycle — discovery works iteratively, don’t expect a perfect picture on the first run.

4. Verification

Three commands to confirm everything actually works, not just that a process is spinning.

~/bin/localenv netdisco-daemon status

Result: status of the discovery, macsuck, arpnip workers, all should say “running” or “idle”, never “dead”.

sudo -u postgres psql -d netdisco -c "SELECT count(*) FROM device;"

Result: a number greater than zero means devices actually landed in the database, not just got pinged.

tail -f ~/perl5/var/log/netdisco/daemon.log

Watch for SNMP timeout lines. If there are a lot of them, your community string is wrong or an ACL is blocking traffic from the NetDisco host.

5. Complications

show interface FastEthernet0/1 switchport

And the queries you can get… the database just said “nice job” and hung when I first fed it a 400-switch network without a properly tuned connection pool. Not a joke for the sake of a joke, actually check max_connections in PostgreSQL if your network is large.

6. Alternatives

NetDisco isn’t the only option, and not always the best one for a given job. Here are the other five, short and to the point.

LanTopoLog

Shareware for Windows and Linux, topology mapping is free even without buying a license. Installs in five minutes, needs no separate database, works with any switch over SNMP. Shows VLAN, STP, LACP right on the map. Pick this one if your network is small (up to a hundred ports) and standing up a full NetDisco server would be overkill. Official page: lantopolog.com.

Scanopy

A newer tool, but its L2 view is a dedicated, honest one: every switch, port and link over SNMP+LLDP, plus separate views for L3, workloads and application dependencies. Self-hosted via Docker or a cloud version. A good fit if your environment is a network plus containers plus VMs, and you want all of it visible in one place. Official site: scanopy.net.

SolarWinds Network Topology Mapper

Paid, Windows-based, discovery via ICMP, SNMP, WMI, CDP, VMware, Hyper-V. Can export the map straight to Visio, a big win if your company’s documentation already lives in Visio. More expensive than everything else on this list, but you get support and compliance reports (PCI, HIPAA) out of the box. Official page: solarwinds.com/network-topology-mapper.

ManageEngine OpManager

Not a dedicated L2 mapping tool, part of a larger monitoring suite. Builds Layer 2 Maps via CDP, LLDP, ARP, FDB, with three display views to choose from. Makes sense if you need a full NMS anyway and an L2 map is a bonus, not the main goal. Network mapping section: manageengine.com/network-monitoring.

UVexplorer

Windows tool, detailed topology down to the port level, including wireless and virtual infrastructure. Exports to Visio, Lucidchart, PRTG. Worth noting for verification: UVnetworks (the developer) was acquired this year by Paessler, the company behind PRTG, so the PRTG integration is now official and runs deeper than before. Official site: uvexplorer.com.

Comparison table

7. Prevention

An L2 map doesn’t die the day it’s built, it dies six months later without upkeep. Three things that keep it alive.

• Monitoring: set an alert for the NetDisco daemon process going down (or the equivalent worker), otherwise the map quietly stops updating and nobody notices
• Backup: dump the PostgreSQL database daily, keep at least 14 days of history, the map plus the history of topology changes is valuable on its own
• Autostart: wrap the daemon and web interface in a systemd unit with Restart=on-failure, so the server survives a reboot without manual intervention
• Regular rescans: at least every 24 hours, otherwise new switches show up on the network before they show up on the map
• A dedicated read-only SNMP user, never read-write, this isn’t paranoia, it’s the baseline
• Restrict access to the topology map’s web interface by IP or VPN, a topology map in the wrong hands is ready-made network reconnaissance
• Review community strings quarterly, especially after team departures

8. FAQ

Why doesn’t the L2 map build after setting up NetDisco?

In 90% of cases it’s SNMP: either the community string doesn’t match, or an ACL is blocking UDP 161. Check daemon.log for timeouts and confirm the port is open from the NetDisco host toward the management VLAN.

How do I verify the map is building correctly?

Go to Device Search and look up a switch by IP. If you see its ports, MAC table, and LLDP/CDP neighbors, discovery worked correctly. An empty neighbor list on a live device is a signal to check LLDP on that port.

LLDP is enabled but there’s still no link between switches, what now?

Confirm LLDP is enabled on the trunk port between the switches, not just on access ports. Some vendors disable LLDP on uplinks by default for security reasons, you have to turn it on manually.

How is NetDisco different from LanTopoLog?

NetDisco is a server-based solution with its own database, built for networks of fifty devices and up, and needs a Linux host. LanTopoLog is a Windows desktop app, installs in minutes, but scales worse and doesn’t keep as deep a history of changes.

9. Outlook

Once NetDisco (or whichever alternative fits your network better) is running, the L2 map updates itself daily, with no input from you. No more trying to remember which server is plugged into which port in rack three, just type the MAC address into search and get the switch port in five seconds.

What’s left is not forgetting the prevention steps above: monitoring the daemon and backing up the database. A map that fails silently is worse than no map at all, it creates a false sense that documentation exists, right up until an incident forces you to dig in and you discover the data hasn’t updated in three months.

If something didn’t work, drop a comment, we’ll sort it out.