How does Netbox as a DCIM & IPAM tool fit alongside DDI? #13691
Replies: 3 comments 5 replies
-
|
If you want NetBox to be the source of truth for DHCP/DNS information then you need to adopt or develop add-ons to NetBox that actually make it the source of truth. For example you can enable the netbox-dns plugin to store all of your DNS data in NetBox. Then there are various tools that can be run regularly to export that data and reconfigure your DNS servers with that data (I export my data to text zone files and use Unbound). But the main thing is that people can't configure DNS anymore without going through NetBox. The same goes for DHCP servers, etc. Of course using certain DNS & DHCP servers makes this easier. I wouldn't want the task of configuring Windows DNS & DHCP servers - but then that's mainly because I'm not a Windows person. It's also certainly possible to do things the other way around - merely using NetBox as a way to aggregate and make queryable data obtained from other system. This is actually what I mostly do because I can't force NetBox as the central DDI database in some environments - they're too tied to the standard Windows DNS & DHCP servers and refuse to change. In that case too you'll need to develop scripts that scan the network and update NetBox appropriately. I've got a bunch of scripts that do that but they make too many assumptions currently about our networks to be able to share them in their current state. |
Beta Was this translation helpful? Give feedback.
-
|
We're far too large of an organization for a change of this size to make sense. We have a server team that has dedicated personnel for managing DNS, DHCP, and a variety of other Windows Server AD-associated services at this time. I can't see them getting behind an open source tool with a plugin as the organization's accepted DDI tool. Can you write me some pseudocode that details your logic behind your scripts? Curious to know how you scrape DNS and DHCP servers for data currently, including frequency and verbosity. Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
It's fairly crude right now, and I've scaled back from a lot of what I used to do. What I mostly do right now (at least with respect to DDI) is log into all of the routers in the network and grab all of the arp tables. I then use the mac address to locate the device in NetBox and then if it's one of a certain class of devices I update the IP address on the interface and possibly the primary IP. I only do this periodically, maybe once a week or so. Scraping DHCP server data and DNS data proved to be too noisy as the data can persist hours or days after the device has dropped off the network (we have a lot of client devices that come and go). I can understand where you're coming from, as that's basically where I am now - I'd love to move everything to use NetBox as the source of truth but the DHCP and DNS servers are controlled by the Windows server teams and there's a major anti-open source bias there. We'd be more likely (as an organization) to spend $100K on InfoBlox or some similar commercial software... |
Beta Was this translation helpful? Give feedback.
-
|
We do DNS updates this way :
The main function :
|
Beta Was this translation helpful? Give feedback.
-
|
This is a great discussion and the way I have envisioned this for my org, where we already have a DDI platform, is that Netbox data is authoritative for the network devices themselves (just like you've done assigning IPs to interfaces, VLANs to subnets) as that is what's useful for config templating and audit, the DDI is authoritative for devices we don't manage and we are a customer of the DDI the same as say the VMware team, using Netbox data to push in IP/DNS/DHCP records for network devices only.
* Fundamentally, Netbox is meant to be the source of truth, not allow other systems to be truthful for certain items, and Netbox be the root of truth for others. I'm not entirely certain of how to tackle this issue.
Netbox doesn't need to eat the world, you can choose whether you manage prefix assignments from Netbox or your existing DDI (I am choosing Netbox) but Netbox doesn't need to contain the entirety of your DDI config if that doesn't provide any abstraction or value (eg I'm not creating IP Address records for devices we don't manage), different data can be managed and authoritative in different tools, when a vendor tool or something purpose built is a better fit for config management.
In those cases I might set some baseline config, like syslog and ntp IPs, but leave the day-to-day changes to the config management tool, unless there is some abstraction that can add value, I do not want to spend time re-creating every config element in some third party system as custom fields and config contexts in Netbox to sync 1:1 just to say the data is in Netbox. I'd rather just create a custom URL to point to the place where further details are configured so that Netbox is the central jumping-off point.
* I have no way, other than with scheduled auditing, to ensure that Netbox stays up-to-date with downstream devices.
Yeah, you'll need audit scripts and/or change your provisioning process to push this config from Netbox to the managed device, so the right way to provision is by using tools backed by Netbox, rather than expecting engineers to hand-edit configs and only then hand-update Netbox. It won't happen. You don't want to add a bunch of administrivia to the process that will get ignored, you want to make the process easier, so the path of least resistance is through good record keeping and automation. If you have done so and your audit tool reports that a downstream device is out of compliance than that needs a response to bring it into compliance, by updating Netbox with the correct data and pushing it down, and figuring out why something was changed outside your process.
* I have no way, other than with scheduled auditing, to ensure that Netbox stays up-to-date with our DHCP server's configurations.
I don't think you need to do this, if you have a DDI platform that manages your DHCP config you don't need to duplicate this functionality. What you may need is to push configs into DDI from Netbox for things that Netbox manages, and not other things that DDI manages internally.
* I have no way, other than with scheduled auditing, to ensure that Netbox stays up-to-date with our DNS server's configurations. This one would be particularly tricky to evaluate each IP address against its associated A and PTR records without generating a metric-ton of traffic.
Same here, except for network device DNS records themselves, which can use the ip-address dns_name field, you don't need to duplicate the DNS server config, although like with DHCP you might have some subset of data which is managed in Netbox and pushed to DDI.
That said, there are plugins to Netbox to add some DDI functionality, so you could use Netbox as a base to build a DDI system, but it's probably not worth the effort to do so if you already have perfectly functional config management, and instead spend your time on data for devices/applications/configs which aren't well managed today.
—
Mark Tinberg ***@***.***>
Division of Information Technology-Network Services
University of Wisconsin-Madison
…________________________________
From: Bradley Rose ***@***.***>
Sent: Tuesday, September 5, 2023 12:20 PM
To: netbox-community/netbox ***@***.***>
Cc: Subscribed ***@***.***>
Subject: [netbox-community/netbox] How does Netbox as a DCIM & IPAM tool fit alongside DDI? (Discussion #13691)
TL;DR
I've shown colleagues the tool, and DCIM has been immediately appreciated; but, IPAM has been lacklustre. Features desired from other members:
* phpIPAM has a network scanning utility. I absolutely understand why Netbox doesn't incorporate one (decision making on historical data, live vs. documented, etc.), but people with experience in this tool enjoy being able to compare documented to live data.
* DDI: Those with experience with commercial DDI tools (DNS, DHCP, IPAM) have concerns with the inability to act as a production DNS server, DHCP server, etc. This becomes just another tool that everyone is expected to update without policing. Auditing, sure. Policing? Not possible.
Our business is under a re-evaluation of a few tools right now, and IPAM / DDI is top-of-mind. How does Netbox philosophically fit into the big-picture of IPAM when DDIs exist to act as the documentation and actual source?
________________________________
Org Netbox Setup
I've spent the last year configuring Netbox in my organization's environment. We've desperately needed rack diagrams and a unified DCIM tool, and Netbox is absolutely the answer to those woes. We've got 100+ sites, so this is crucial to our operations, and so far it's been a treat.
Initially, I loaded in and parsed all of our data from our various controller systems. Now, it's all about upkeep. I've got the following data loaded into Netbox:
* Sites / Locations (organizational data)
* Devices: types, roles, racks, etc.
* Prefixes / VLANs: I've got a good chunk of L2/L3 data as well.
With the above information alone, I'm able to perform a ton of work that I was unable to do previously, and a huge chunk of this is related directly to network automation / querying the Netbox database for a specific subset of devices and performing work on those.
IPAM Problem
IPAM is tricky. I have enough information in here to have included a good chunk of subnet information. I was able to query all of our L3 devices with some automation, parse the interfaces/subnets downstream, and import these into Netbox quite nicely. I was then able to assign interfaces to devices, and assign Primary IPs to our devices.
1. I have no way, other than with scheduled auditing, to ensure that Netbox stays up-to-date with downstream devices.
2. I have no way, other than with scheduled auditing, to ensure that Netbox stays up-to-date with our DHCP server's configurations.
3. I have no way, other than with scheduled auditing, to ensure that Netbox stays up-to-date with our DNS server's configurations.
* This one would be particularly tricky to evaluate each IP address against its associated A and PTR records without generating a metric-ton of traffic.
Fundamentally, Netbox is meant to be the source of truth, not allow other systems to be truthful for certain items, and Netbox be the root of truth for others. I'm not entirely certain of how to tackle this issue.
Many commercially available DDI systems aim to be exactly that section of an IPAM: the root source of documentation and truth. I've got colleagues with experience with DDIs that have seen these shortfalls since I've brought this tool to light. I don't have the necessary answers, so at this time, there's been conversations about introducing a commercial DDI tool that could better answer those concerns.
With that said, assuming a DDI goes live, do I just disable IPAM in Netbox outside of configuring a single Primary IP for each device, and potentially their interface assignments?
Help me understand how Netbox is supposed to live in a large organizational environment where DDIs are of high desire, network scanning / nmap-like solutions are desirable, and certain functions of Netbox exist. I don't want to introduce Netbox to the Business only for it to introduce further complexity in documentation and thus not get digested into standard procedural tasks.
—
Reply to this email directly, view it on GitHub<#13691>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM2SK7ROX3WBYSDNR3DXY5NO5ANCNFSM6AAAAAA4MDKF5M>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the very detailed reply. I appreciate the insight into someone else's perspective(s). Just to confirm, you're using Netbox for only what may relate directly to network devices. This is a tool for your "network", and not anyone else involved in the organization (less maybe the Server team(s) that also rack & stack). Netbox houses (as a SSOT):
You choose to allow Netbox to ignore:
Follow up questions:
|
Beta Was this translation helpful? Give feedback.
-
|
Hi Bradley, I recognize this convo is a little stale at this point. However - if you're open to it I'd like to connect with you on the DDI use cases / challenges your colleagues raised and you discussed in this thread. I do think there are some current gaps or challenges in how NetBox fits into footprints with heavy traditional DDI footprints today along lines you've mentioned. We're (NetBox Labs) working on identifying the best strategy for meeting the needs of these kind of use cases and it'd be really helpful to pick your brain directly. If you're open to that - I'm at [email protected] and would really appreciate it. Best, |
Beta Was this translation helpful? Give feedback.
-
|
You've got it. We do use Netbox for Prefix assignments and not our commercial DDI/IPAM system to keep our provisioning workflow in one place, but the only IP addresses we manage in Netbox are for network equipment, our commercial DDI has a webUI and API which we delegate out with access control to various IT departments for self-service. Not even all deparments use our DDI, some run their own DNS/DHCP outside of our control. There is nothing I would do with that data if I tried to sync it back to Netbox, aside from making the Netbox IP usage statistics more accurate.
followups
1. We provide self-service tools to IT departments, like MAC L2/L3 data and API access to the proprietary off-the-shelf DDI tool, for them to implement reconciliation if they so desire. Our Netbox is SOT for what Prefixes are assigned but there is no complete central IPAM, although our DDI is the most comprehensive view and used by the vast majority, but not all.
2. I too am early in this journey, we have some mature processes for one-time config templating and initial provisioning, most changes made "by-hand" are copy-pasted from a config tool, so they start consistent, but things can drift over time as engineers change design and the central templates, and make by-hand customizations beyond the defaults the templates provide. I'm in the process of refactoring our config tools to provision records in Netbox, then read those records back to render the templates, so we can re-gen any config and check for drift. I'm using Ansible for that now but I might switch to NSO in the future, when I have time to learn more about it. We have mature process around config backups and RCS using an in-house fork of RANCID and parsing data out of configs into JSON in a standard format that other tools can consume and audit, including synching/auditing with Netbox to close the loop.
I began small, moving our site management from an RCS versioned flat text file to use Netbox Sites with a webhook + cronjob keep the legacy file updated, and did that again with HA group/cluster management. Small tasks but it got people using the tool, documentation created, AAA, Scripts and Reports that people use. Moved on to creating an automated provisioning tool for Netbox to sync VLAN, Prefix, IP-Address and Device records based on our existing in-house tools, device JSON files, that could run periodically out of cron to maintain a mirror of records from our existing sources of truth. Once that was established, we were able to integrate downstream usage of that data more easily with off-the-shelf tools like Ansible, using the Netbox REST API where it had good-enough data while we migrate process/procedure/tooling from our legacy systems that sync to Netbox to managing the data in Netbox and synching to our legacy systems which then become a read-only view.
Netbox can become a source-of-truth one field and one data type at a time, which can be a little confusing and disruptive in the interim, but that can be mitigated with communication and documentation, including warning comments in templated config that engineers might be tempted to hand-edit, so they aren't surprised when their changes get reverted.
Once you have something simple, low impact and low risk demonstrated, then look to what config management lack is taking engineer time or causing problems and get just enough working to fix that problem. If you make a process easier, it won't be too hard to convince them to use it, but it might take a while. My big advice is to not try and model everything or template everything all at once, or try too hard for accuracy unless it's necessary for config management, eg. my process which creates new Device records creates a virtual management interface called "placeholder" to associate the management IP with, and that gets fixed later when the device is being staged and more config data needs to be populated, rather than making the engineers figure out even more stuff (that could change later) when they just want to reserve the IP and DNS name.
Whether you use Ansible or Nornir or NSO or something else to effect changes on the devices, you'll have to carve out one thing at a time that becomes managed by automation and no longer managed by hand. A candidate is AAA, DNS, NTP, and Syslog settings, working a project to standardize those settings using Config Contexts and an automation tool can get your feet wet and probably doesn't have a lot of variability so is low complexity/low risk (well don't mess up the AAA settings 😉). You don't even need to have the IP records and primary_ip populated to use Ansible if the Device name is the DNS name, just Name, Device Role, Device Type, Site and Status.
Iterate on that and people will learn the process, start making suggestions and you might be able to entice them away from cowboy change mananagement.
—
Mark Tinberg ***@***.***>
Division of Information Technology-Network Services
University of Wisconsin-Madison
…________________________________
From: Bradley Rose ***@***.***>
Sent: Tuesday, September 5, 2023 5:37 PM
To: netbox-community/netbox ***@***.***>
Cc: Mark Tinberg ***@***.***>; Comment ***@***.***>
Subject: Re: [netbox-community/netbox] How does Netbox as a DCIM & IPAM tool fit alongside DDI? (Discussion #13691)
Thank you for the very detailed reply. I appreciate the insight into someone else's perspective(s).
Just to confirm, you're using Netbox for only what may relate directly to network devices. This is a tool for your "network", and not anyone else involved in the organization (less maybe the Server team(s) that also rack & stack). Netbox houses (as a SSOT):
* All DCIM information
* Some IPAM information as it relates to network devices and their downstream configurations/templates (interfaces, addresses, etc.)
You choose to allow Netbox to ignore:
* DHCP server configurations / ranges as a DDI would manage this better
* DNS as a DDI would manage this better (with a potential sole exception for DNS entries that map to an interface in Netbox)
Follow up questions:
1. IPAM: How do you compare actuals (something that nmap or a network scanning utility could identify) to what Netbox is aware of? Do you use IPAM as the central IPAM source of truth for the business, or do you use another piece of software as IPAM?
2. How do you introduce config templating/pushes to downstream devices with auditing? I know this is a larger question that may not be simply answered, but all I have right now is legacy-style operations (CLI changes made manually) and Netbox as two separate entities. I'd like to bridge that gap, but I'm not sure where to begin. I don't know anything about web hooks, let alone how to build auditing tools into Netbox.
—
Reply to this email directly, view it on GitHub<#13691 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM2SZYW65RFB3SJZWVDXY6SRDANCNFSM6AAAAAA4MDKF5M>.
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
TL;DR
I've shown colleagues Netbox, and DCIM has been immediately appreciated; but, IPAM has been lacklustre. Features desired from other members:
Our business is under a re-evaluation of a few tools right now, and IPAM / DDI is top-of-mind. How does Netbox philosophically fit into the big-picture of IPAM when DDIs exist to act as the documentation and actual source?
Org Netbox Setup
I've spent the last year configuring Netbox in my organization's environment. We've desperately needed rack diagrams and a unified DCIM tool, and Netbox is absolutely the answer to those woes. We've got 100+ sites, so this is crucial to our operations, and so far it's been a treat.
Initially, I loaded in and parsed all of our data from our various controller systems. Now, it's all about upkeep. I've got the following data loaded into Netbox:
With the above information alone, I'm able to perform a ton of work that I was unable to do previously, and a huge chunk of this is related directly to network automation / querying the Netbox database for a specific subset of devices and performing work on those.
IPAM Problem
IPAM is tricky. I have enough information in here to have included a good chunk of subnet information. I was able to query all of our L3 devices with some automation, parse the interfaces/subnets downstream, and import these into Netbox quite nicely. I was then able to assign interfaces to devices, and assign Primary IPs to our devices.
Fundamentally, Netbox is meant to be the source of truth, not allow other systems to be truthful for certain items, and Netbox be the root of truth for others. I'm not entirely certain of how to tackle this issue.
Many commercially available DDI systems aim to be exactly that section of an IPAM: the root source of documentation and truth. I've got colleagues with experience with DDIs that have seen these shortfalls since I've brought this tool to light. I don't have the necessary answers, so at this time, there's been conversations about introducing a commercial DDI tool that could better answer those concerns.
With that said, assuming a DDI goes live, do I just disable IPAM in Netbox outside of configuring a single Primary IP for each device, and potentially their interface assignments?
Help me understand how Netbox is supposed to live in a large organizational environment where DDIs are of high desire, network scanning / nmap-like solutions are desirable, and certain functions of Netbox exist. I don't want to introduce Netbox to the Business only for it to introduce further complexity in documentation and thus not get digested into standard procedural tasks.
Beta Was this translation helpful? Give feedback.
All reactions