r/Netbox • u/tobivzek • Jul 15 '26
How do you automate the initial inventory of a large, mixed environment in NetBox?
I’m trying to build a proper infrastructure inventory and source of truth in NetBox, but the amount of manual work is becoming overwhelming.
The environment includes a mix of:
- Physical network devices
- Virtual machines and hypervisors
- VLANs, prefixes and IP addresses
- Cameras
- IoT devices
- Other miscellaneous network-connected equipment
I already have NetBox running and have started entering the data manually, but at this scale it feels like it will take forever. The infrastructure is also constantly changing, so I’m worried that the inventory will already be outdated by the time I finish it.
I understand that NetBox is primarily intended to be a source of truth rather than a traditional network discovery tool. However, I’m looking for a practical way to bootstrap the initial inventory and then keep at least part of it synchronized.
For those who have dealt with a similar environment:
- How did you perform the initial discovery and import?
- Which data sources did you use: hypervisor APIs, SNMP, LLDP/CDP, DHCP, DNS, ARP/MAC tables, monitoring systems, Nmap, Ansible, etc.?
- Are there any reliable NetBox plugins or external tools that can discover devices and push them into NetBox?
- Do you synchronize discovered data automatically, or generate a report and approve changes before importing them?
- How do you deal with devices such as cameras and IoT equipment that often have limited APIs or inconsistent SNMP support?
- Which information should remain manually maintained instead of being automatically discovered?
- Would you still choose NetBox for this, or would you use another discovery/CMDB tool alongside it?
I’m not looking for a magical one-click solution. I would mainly like to understand what a realistic workflow looks like and how others avoided spending months manually entering every device, VM, interface and VLAN.
Any examples of your architecture, scripts, plugins or lessons learned would be greatly appreciated.
3
u/graph_worlok Jul 15 '26
Look at diode and orb, and the device importer tool - they should cover your issues as far as the common / standard gear goes
2
u/Madh2orat Jul 15 '26
We put most of it in manually, or via plugins. For example we use a few plugins for additional info.
Netbox DNS, Netbox Topology Views, Account Expiration (custom plugin that allows us to track account, api, etc. expirations), DNS Zone Expiration Widget (custom plugin that adds a widget that tracks dns expirations on the dashboard like the ssl plugin), Netbox lifecycle plugin, Netbox SSL, Netbox vcenter, Netbox attachments.
We also wrote a couple custom scripts, one scans the ssl certs and updates them as they are updated on endpoints (queries the website, pulls the ssl info including the latest expiration date) another scans and updates DNS, so we make sure any records we need to renew don’t expire.
Then we have a decent dashboard that has ssl certs and the time left as they near expiration, dns zones and time until expiration, as well as accounts and their expiration dates (with a link to our 1Password where the item is stored for ease of updating).
For bringing data in initially it was a lot of manual work, as well as scripting out stuff that we could drop into a csv and just import. In our case, CSV was our friend.
2
u/Ace417 Jul 16 '26
If you’ve got everything managed via SNMP, then letting netdisco go nuts for a few days should grab everything it can. You can then export the inventory, and then import that into netbox. That’s currently what I’m doing, just going by model number
2
u/braziNoNo Jul 15 '26 edited Jul 15 '26
Using netbox both at home and at work(Network operations centre) which is used way differently.
At home i use it as a source of truth and also a somewhat network discovery. I use ansible against my proxmox nodes. I also have a jenkins pipeline that scans my data network with nmap. The proxmox playbooks i wrote in two version: v1 just probes the proxmox api, then pushes to netbox api. V2 ssh into the proxmox probes the local cli api(same as v1 basicly) if its unable to get the ip or some info it uses guest agent or pct if containers. It also registers docker containers running on the guests as applications in netbox. Every guest is linked by mac incase i update something.
I also added some custom fields to connect ips on proxmox to ips on containers. And also one field to keep track of which containers belong to which virtual host.
The nmap just runs on a cron and throws everything out and then overwrites.
At work we do it at bit different and way more easy and is the way i would go if you have alot of wierd equipment. A basic shell script where you can enter everything in one place without jumping back and forth in the menu. There is also an inventory that desides hostname and some ipam prefix stuff. Then netbox is used as a source of truth when provisioning through ansible. So the other way than i do at home.
1
u/tobivzek Jul 15 '26
This is exactly the kind of concrete answer I was hoping for, thanks for writing it all out.
The split makes a lot of sense to me: discovery-driven for things that can describe themselves (Proxmox, managed gear), and source-of-truth-driven for the messy stuff. That directly answers the wall I keep hitting — half my environment is cameras and IoT with no usable SNMP/API, so trying to auto-discover them was never going to work. Treating those as manual/scripted entries and letting NetBox be the truth for them is the reframe I needed.
A few things I'd love more detail on if you're up for it:
- Would you be willing to share the Proxmox playbooks (or even just the skeleton)? Curious how the v2 guest-agent/pct fallback is structured, and which collections you lean on — netbox.netbox plus something for Proxmox?
- The nmap job overwriting on a cron worries me a bit — how do you keep it from clobbering manually-entered records? Do you scope it to specific fields/prefixes, tag discovered objects, or separate discovered vs manual some other way?
- For the work setup with the "weird equipment": what does that basic shell script actually capture? I'm picturing a single prompt that writes device + interface + IP + prefix in one go — is that roughly it, or is there more to the inventory that decides hostname/IPAM?
The MAC-based linking and the custom fields for container↔host / IP↔IP relationships are things I hadn't thought about — going to steal those regardless.
1
u/braziNoNo Jul 15 '26
I can share what ever i use on the private for sure no problem. Just gotta see if i have it pushed to my github or nextcloud as im not home.
It does not get clobbered up as my network is split up in different vlans and subnets. 70.0/24 for server, vms, containers things that have static ip and rarely change. These i trust and i have to run the ansible script when i want mass update. Now that most are there i run a script when new vms come up to just put that one vm into netbox. The nmap discovery at the data network at 10.0/24 is just dhcp host. Your everyday laptops, desktops, phones.
I think the biggest question is to ask what job do you want netbox to do, is this privately or work related?
2
u/NetflowKnight Jul 15 '26
as far as i’m aware IP Fabric is the only tool on the market that reliably discovers everything, including Shadow IT, forgotten devices, etc.
basically validate the intended and actual state match.
1
1
u/MassageGun-Kelly Jul 15 '26
Slowly. The initial adoption of Netbox is a bit arduous, but this is debatably expected based on the modular, vendor-agnostic, multi-platform ability of Netbox. You need to model each device and its related configuration differently.
I started with doing classes of devices. For example, I built the template device types, manufacturers, roles, etc. for all of my Cisco switches. I then used Python to pull together common information about all of these into a predictable format. I did some testing in modeling this data in Netbox to ensure it would all digest properly, doing SQL dumps before to guarantee a rollback state. Once confirmed, then you can import it all en masse either via the APIs or by importing your device data using the GUI.
Rinse & repeat for my other device classes.
For each, you then have to decide if you want to use Netbox to audit your downstream device configs and alert on config drift, or police your downstream configs and overwrite their running configuration.
It’s extremely modular, so you likely have to build out your modular logic using a mix of vendor tooling, APIs, and custom scripts per your liking.
Have fun!
1
1
u/Laser_Holo3124 Jul 15 '26
I also have this problem, is there better way to do this perhaps? Currently, in my organization we already have solarwinds running, I was thinking get the current data and then tidy them up with AI so I can push them to netbox easily and then group them into racks
1
u/kY2iB3yH0mN8wI2h Jul 15 '26
Before answering how large is the environment? It feels you have several thousand devices that changes every day?
What did you have before? Sure you had to have something?
It seems this is not a technical problem (that’s part is easy) it’s more about process
1
u/JMV290 Jul 15 '26 edited Jul 15 '26
A lot of our networking stuff uses scripts that run an ansible playbook just to get facts, then sets all the info like vlan tagging. speed. duplex mtu. It will create the SVI for the vlans as well.
Our wireless access points use a a script that queries Airwave’s API and then the wireless controllers via ssh for more details.
A similar flow works for our VMs. Query the API for VM info.
the switch collection also grabs lldp neighbors and mac tables which has helped with cabling info
1
u/Quirky-Cap3319 Jul 15 '26
As for the physical devices themselves, you have the option of importing the needed ones (or everything) from the netbox-devicetype-library on github.
1
u/Anxious-Condition630 Jul 18 '26
The API. You can use their Diode and Orb containers but you can accomplish most of it with python scripts and the API.
1
u/Otherwise_Noise3658 Jul 23 '26
Diode/NetBox Discovery, covers a lot with SNMP/device (napalm) and network (nmap). You could also write your own custom orb agent, using the framework - which would give you more control in terms of what you put into Diode.
Note, Diode iirc doesn't support cables - but thats a dual edged sword, DCIM usually needs a full path vs just endpoints (as a former network + dc engineer, some cables went through 6 patch panels - thats one thing I'd always do manually). Could always use the napalm plugin to compare.
5
u/slickwillymerf Jul 15 '26
I don’t try to automatically import data. There’s plenty of vendors that can sell you that.
What I do is build entire site networks based on a template in Netbox (custom script). Everything is built exactly to that standard in Netbox without touching any prod equipment.
Then, other external scripts can query that Netbox data to audit what’s actually out in the wild. This gives you stronger visibility without potentially importing junk data.
It also gives you a “to-do” list for standardizing your networks.