A little confusion on the purpose of netbox

[Cody Kochmann]

Our team at NASA has been preparing a transition from ipplan to netbox for some time and someone pointed out that in the first couple pages of the docs, its recommended to use netbox as a source of hand entered truth. This makes total sense on one hand but also confused us a lot too.

One of the biggest selling points of netbox for us was its really clean api that would allow us to make a centralized storage of all of our networking spaces. We have hundreds of subnets, vlans, vpns and racks and hundreds of thousands of ip addresses that netbox seems to be able to map out really nicely compared to the extreme bending over backwards we needed to do with ipplan.

We would like a little bit of advice in what the correct use of netbox would be since at this scale, its a little beyond the point that we can hand enter all of this data.

This app seems to be saturated with apis to cleanly automate bringing in data but the section of the documentation on this page https://netbox.readthedocs.io/en/latest/ makes us believe the recommendation is secretly a lesson learned from going too far with automation.

Any enlightenment on the subject would be super appreciated. Thanks in advance.

[Dave Noonan]

I can't speak for the Netbox folks but as a user I would take "hand entered truth" as "human entered truth.  We might have entered the data via import or API or one-at-a-time but this is the way the humans say the network is supposed to look.  How it actually looks is a different matter and having gotten the available data into NetBox my current task is finding or making tools that verify the data is correct and tell us about changes going forward.

Regards,

Dave Noonan

--
You received this message because you are subscribed to the Google Groups "NetBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netbox-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to netbox-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/netbox-discuss/acff129d-e44e-4c5b-a4f5-7e621a8930b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Joseph Wegner]

Hi Cody,

We transitioned from IPPlan to Netbox as well, and I made some scripts to help ease the transition: https://github.com/jwegner89/netbox-utilities

While I removed our organization specific logic, some of the scripts should still be helpful. In particular, export_ipplan.py will take your IPPlan MySQL dump and output CSV files that you can use to import.

While I understand the documentation's warning against automation, I would argue that it doesn't always apply. We have ~37,000 IPs tracked in Netbox, so there is no feasible way for us to handle those without automation at some point. We also have ~800 VMs that may change, so I created Sync-Netbox.ps1 to help synchronize our vCenter inventory with Netbox. 

Sure, not everything will be 100% correct using automation, but I would argue that it isn't always correct when you enter everything by hand either.

-Joe

[Brian Candler]

I think there are a couple of ways you can think about this.

In one approach, the database represents the network *as it is*.  If a new IP address is detected on the network, you automatically record it; if a new connection between network ports on two device appears, you automatically record it; and so on.  This is definitely a low maintenance approach, as used by tools like Netdot and Netdisco.

In the other approach, the database represents the network *as it should be* - the state as it was designed or approved.  Any divergence between reality and this would then represent a failure of process which needs to be resolved: either in favour of updating the design to match the new reality, or in favour of removing the offending object from the physical network.  Netbox then becomes a tool for controlling and auditing your environment.

I think Netbox tries to edge you towards the second approach, but even so that doesn't rule out automation.  For example: when you assign an IP address you might enter it in "Reserved" state.  Automation could transition it from "Reserved" to "Active" when it sees the address in your ARP tables.  Similarly, a human might transition an address from Active to Deprecated when it is about to be removed.  Automation could then remove the address entirely when it is no longer seen (or after it has been inactive for N hours or whatever) - or alert if the address has remained active for too long.

This approach is similar to what you might do with racks: first make a reservation, then enter a device with state "Planned", and then change the device to "Active".  Of course, rack space allocation is something that would be very hard to automate anyway.  Similarly, power cables and console cables are very hard to automate as well: there is no LLDP for power :-)

In the case of IPAM and Virtualization, it's up to you how much to automate.  If you want to scrape your VM clusters and automatically sync all the instances into Netbox, that's very doable.  But equally you could have Netbox act as the control platform: your policy might be that VMs cannot be created until they have been formally registered in Netbox first, and any VMs which appear on the platform without approval are flagged up as exceptions.

Entering data manually may also make more sense when you're using Netbox as a source of information for configuring your monitoring systems.  You might find it a bit strange if any random device that was plugged into the network was automatically added to monitoring; and in any case it would be hard to know what services should be monitored on that device.  From that point of view, I think it makes more sense for devices and services to be added manually.  Of course, if you detect any active IP address which is not recorded either as a Device or a Virtual Machine or as a known virtual IP, and is not within a DHCP pool, it should be flagged up.

So what would be perfect is if you could run a tool like Netdisco beside Netbox, and have an intermediate system which compares them, flags up things which Netdisco detected which are not in Netbox, and offer to make the corresponding updates to Netbox for you.  But unfortunately if you want that today, you have to build it yourself.

HTH... Brian.

[Jeremy Stretch]

Quoting the docs:

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

What this means is that NetBox expects that a human has validated all data being entered into it. You can of course import data in bulk via the API or some other mechanism (there is no need to manually enter data), but only after ensuring the integrity of that data.

For example, users are discouraged from blindly creating interface connections using data gleaned from device LLDP tables without first checking that the connections reported by LLDP are as expected. (LLDP tells us that Gi0/1 on switch A is connected to eth0 on server3, but only a human knows if it should be.) Importing data blindly does not create a source of truth: it merely establishes a snapshot of the network at one point in time which may or may not be correct (and probably isn't).

Hope that helps!

Jeremy

--

You received this message because you are subscribed to the Google Groups "NetBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netbox-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to netbox-discuss@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/netbox-discuss/6ec5a77f-7379-495a-b266-59ffd7700bb5%40googlegroups.com.