NetBox: a source of truth for everything on your network (opens in new tab)

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.

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.

There are also reports you can write to catch any data issues.

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.

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.

Hence, a source of truth. The mysterious machinations of the modern datagram hailstorm quantified and exposed.

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

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...

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!

[1] https://github.com/netbox-community/netbox/tree/develop/netb...

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.

admin:admin