In case you were struggling to find anything meaningful on the site regarding what netbox actually is:
>NetBox is the leading solution for modeling and documenting modern networks. By combining the traditional disciplines of IP address management (IPAM) and datacenter infrastructure management (DCIM) with powerful APIs and extensions, NetBox provides the ideal "source of truth" to power network automation.
There are a lot of DCIMs out there, where netbox really shines, is that it's got a decent API and is pretty flexible.
We use it as a front end for managing physical datacenters with a host of services that take or store their state in netbox.
Services check boot targets, hosttypes, connected switch and power ports, the service and role a host will or does provide, lifecycle tracking, etc . . .
And, we can give it to our physical datacenter techs and they just set the fields and boot the host.
It's a really nice way to manage a front end, because netbox handles things like ldap and UI and we just write services that make the datacenter look like netbox.
My company went with opendcim over netbox a few years back and filled in the gaps with a custom database and app. We are now migrating a lot of our data into netbox and wondering why we didn't do that in the first place.
Oh. A pity. In my head it would’ve been something like a poor man’s SIEM, monitoring traffic and keeping track of who has been accessing what on my home network.
Hence, a source of truth. The mysterious machinations of the modern datagram hailstorm quantified and exposed.
Hey, I'm a product manager at NetBox Labs, the commercial stewards of the NetBox project. It's great to see such nice and useful feedback.
We're not even a year old yet as a company, and we know that it's currently not easy to find details on netbox.dev, and we're in the middle of a project to address that. In the meantime, I hope you'll check out the resources hosted on https://netboxlabs.com.
Somehow I had no idea that there was a commercial SaaS version of Netbox, as I've been using the OSS version for years hosted internally.
Feedback: the pricing is completely whacked, IMHO. I got excited that I could move to someone else supporting Netbox instead of my team, however due to the number of devices I have, I would have to use the middle license tier -- that's listed as $20,000/yr. This isn't a $20,000/yr problem to me, it would be impossible to justify this to my management, sadly.
Just my feedback on your pricing. Netbox itself, the code and the absolutely stunning dev velocity is inspiring, but unless pricing were drastically lower I couldn't go for it. Would otherwise love to support.
That's comparable to Device42 and Sunbird - what you're really paying for is "one throat to choke". In an enterprise environment, that's pennies.
In prior roles I've seen NetBox explicitly vetoed in favor of technically inferior solutions because there was no available support contract at the time. Also, Sunbird has fancy 3D rack renders, and that's management catnip.
Hey if you're ever looking for any DevOps people with a network engineering background LMK I'm a big fan of NetBox I think it's something I'd enjoy working on.
Just a comment from a smaller user who has moved away from netbox and realistically went back to spreadsheets. Please don't see it as a negative, netbox may purely just be the wrong product for us.
Some background on our usecase, tldr at the bottom. We effectively just need basic documentation.
Which port on which patchpanel does this drop go to?
Which network port is that connected to?
What vlan should be assigned to it?
Which router manages that vlan?
What network range is on that vlan if any?
What IP address should this device be assigned?
I've always found it just a bit difficult to setup things correctly, partly because everything feels slow. To put it into perspective, I was eventually running netbox on a VPS with 2 Genoa cores and 4 gigs of ram and even then some queries would be slow and page loads felt sluggish. Ping to the DC is sub 1ms on that. To need to provide that much horsepower for a DB with an interface just seemed like overkill to management.
Our usecase was great in earlier versions of netbox, the worst performance degradation came around when the graphql API got pushed and newer versions haven't improved it.
As I said, don't take it as a negative, netbox is a good product and to be fair I have never submitted an issue for this nor have I made an attempt to dig into the code to fix it (you can happily blame Django for that). Internally we see netbox as something we probably didn't put enough effort into doing correctly but at the same time the performance issues are a dealbreaker.
I'm intimately familiar with Netbox. It has been the backbone of our WISP for going on 6 years. I just finished a long project where I had to do the first update to it in 5 years (a problem I inherited) and while it was painful to get everything ready on our end, I couldn't be happier with Netbox's side of things. The maintainers were able to easily answer questions on database design from 5 years ago. Great guys, great software.
My group has been running netbox for a few months now and it's been useful for keeping track of departmental address allocations and half a dozen racks of equipment. One note we've learned though: either host it offsite or set up an access point/laptop that you know will let you access it during a local outage.
I actually used this when it first came out in 2016; it was developed by a DevOps person at DigitalOcean as a hobby project (IIRC).
My use at work was just a subset of features (IP and hostname), but I ended up using its Postgres DB as a source for SSH key deployment scripts (these days (maybe back then too) much easier to do with Ansible).
Glad to see it's still actively developed and has a ton of features, yet seems to still be great at its core features!
I've never used it although I've been aware of its existence for a long time. It's great to see a tool actively developed that uses a boring-yet-great-and-well-known framework (Django + Templates). Ironically, it's refreshing to see that stack in a world of JS frameworks, microservices and what not.
Prior to NetBox I spent quite a bit time with RackTables. It was mostly manual documentation but really tickled my OCD itch (lovingly referred to as CrackTables), and it was really simple to use. https://www.racktables.org/
Big fan of NetBox I'm not even sure how I'd manage modern infrastructures without it. Unless your environment happens to be very static it's a huge time sink to document a network using old fashion Visio diagrams. The initial setup of NetBox can be quite an undertaking though. As long as you secure them properly CDP/LLDP/etc make the process much easier. One general rule of advice make sure you keep good backups of your NetBox because it's easy to make changes with unintended consequences that take a lot of time to manually back out
> "The initial setup of NetBox can be quite an undertaking though. As long as you secure them properly CDP/LLDP/etc make the process much easier."
You may have good reasons, but I'll note for other readers that the NetBox documentation takes a position against doing that:
> "Serve as a "Source of Truth" - NetBox intends to represent the desired state of a network versus its operational state. As such, automated import of live network state is strongly discouraged. All data created in NetBox should first be vetted by a human to ensure its integrity. NetBox can then be used to populate monitoring and provisioning systems with a high degree of confidence." - https://docs.netbox.dev/en/stable/introduction/
and
> "ultimately the onus falls to a human operator to assert what is correct and what is not. For example, NetBox can validate the connection of a cable between two interfaces, but it cannot say whether the cable should be there." - https://docs.netbox.dev/en/stable/getting-started/planning/
Monitoring systems reflect the way your network is; ideally NetBox holds the admin side of the way your network should be - from your contracts, services, business agreements - and if the real state differs, you bring the real state into line with NetBox.
I struggle with netbox. I understand their theory of separation of duties, but without it doing DDI and without it having native integration into all the major dns players the usefulness is questionable to me. Relying on people to always update the source of truth never actually works in practice in an organization of any size.
I fundamentally disagree. The source of truth should be naively updating my components, not a script that may or may not break with the next update which has 0 support available.
Given the repeated asks on the GitHub issues, I’m confident I’m not alone in that belief.
Infoblox doesn’t tell me to write a terraform script to update AD/dns and vice versa, they built it into the product.
I understand what it currently does. I’m saying they’re missing the mark and should finish building out the tool. I don’t want a separate tool for each.
Our current focus, with our current resources, is on core functionality. We want to nail that and then grow our roadmap deliberately, rather than go off and add a bunch of half-finished features just to tick some checkboxes. In the meantime, plugin builders are doing an amazing job tackling things like BGP community / session / policy management, DNS record management, and device ACL management.
> Relying on people to always update the source of truth never actually works in practice in an organization of any size
I agree, the only place it has ever worked for me was in a team of 6 with a fixed deadline and liquidated damages for being late, and the source of truth was a binder with all of the drawings. What is highlighted is true, what is not highlighted is yet to be checked. Be careful precisely what you highlight (cable tag, terminal number, relay contacts, etc) or you are throwing the team and company
Under the bus.
Doesn’t scale but works great for getting shit done correctly with no fuss.
I think that's two ways of saying the same thing - that NetBox isn't integrated into anything which forces it into being the source of truth. It's just a place updates sometimes get sent to.
Your ansible (salt, chef, whatever) inventories should be generated from your source of truth, then when they run they should apply against your infrastructure.
You shouldn’t be able to make any changes without driving them through the source of truth.
This is great if your source of truth can be NetBox alone but if NetBox is just a destination for generated workflows relying on things like actual DDI, which is what's actually required for the workflow, as the source of truth the idea every one will remember to update and cleanup NetBox falls apart.
Not to mention not every place can be assumed to declare their entire infrastructure in ansible chef or whathaveyou. If IT people everywhere got the time to redeploy their entire infrastructures only with what works for best practices to make their lives easier then IT people would probably be a lot happier :).
My org switched over to the Nautobot fork for the long term support aspect and integration with our other enterprise apps, both products are pretty great.
EDIT: should note we are using the on-prem version, not cloud/SaaS.
I'm also really excited about the recently (like last week) added IPAM/Rack management in Hudu (kind of like IT Glue). It's pretty rudimentary but they seem to iterate quickly and that will be a great option for people who do IPAM/rack documentation for many customers.
Netbox saved me a lot of headaches when managing clients. Turns out, it's a good idea to keep a network-only management tool that is manually updated, it fixes a lot of stability issues with other client management software, even if ti has an IPAM module
It has quite a different focus than phpipam, which is mostly focused on IP addresses and related information, whereas netbox covers a wider range of items.
The main area where they don't overlap is documenting physical equipment in racks, with which you can use to do some quite useful things.
e.g. document every cable connection, so it can draw the full path from one interface to a switchport through multiple layers of structure cabling/patch panels, and associate an IP address with a specific physical interface on a specific device.
Or track power draw on PSUs, and track that back to the relevant PDU/power feed to ensure it's within permitted power levels.
Needless to say, using all features can be quite time consuming!
A source of truth should only be changed based on a deliberate controlled action. Your VM shouldn’t be changing IPs, if “somebody” changes it you have a chaotic network and you just want a network discovery tool.
The change to the VM’s IP should be done through an auditable change process (like a pull request). If the VM doesn’t match the source of truth, the VM is wrong, not the source of truth.
That PR process would also update your telegraf plugins to ensure that the new IP is being monitored etc.
Net is won’t change the process, your automation (an ansible playbook perhaps) would do the change based on the information in the source of truth
Now it’s possible you only have a couple dozen hosts and a handful of networks and thus your source of truth could be an inventory file, that’s a reasonable solution. When you have dozens or hundreds of switches and hosts in the thousands or more range, I would prefer to have a UI wrapped around that file though, with various links between different locations, switch ports, MDU outputs, etc, that’s where netbox comes in. Your grafana dashboard can take the physical location and tie in with your various monitoring (host and environment) to identify a problem in a specific part of your data centre quickly and reliably, as netbix knows what rack the host is in, what switch it’s connected to, etc
NetBox is indeed intended as a source of truth. It it tightly focused on being the very best DCIM + IPAM solution it can be, which means that discovery / reconciliation and assurance / monitoring are not a problem we're currently trying to solve.
Other products do those things well, and can integrate with NetBox via our extensibility facilities including API, plugins, and scripts. In fact, we just announced partnerships with a couple of vendors that do those very things: https://netboxlabs.com/news/strategic-partnerships-reduce-ad...
So, (sorry I probably should read the docs, and I will, but I'm pretty curious now) the day we implement it, we have to plan to add all our data by hand, am I right? (IP, subnets, details on routes/routers, switches, login URI, notes, locations, ecc ecc..)
For an introduction to life with NetBox that is fast-moving and gentle, yet fairly comprehensive, check out our "Zero to Hero" course: https://netboxlabs.com/zero-to-hero/
>NetBox is the leading solution for modeling and documenting modern networks. By combining the traditional disciplines of IP address management (IPAM) and datacenter infrastructure management (DCIM) with powerful APIs and extensions, NetBox provides the ideal "source of truth" to power network automation.