-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Frequently Asked Questions
- Why Doesn't NetBox Scan for IPs?
- Why Does NetBox Require Every IP to Have a Mask?
- Why Can't I Connect a Virtual Circuit to an Interface?
- How Can I Add New Interface Form Factors?
- Can We Add Custom Fields to More Models?
- Why Does NetBox Support Only Image Attachments?
NetBox does not do any probing of IP addresses natively, for several reasons.
There are myriad standalone IP scanning tools available. nmap is arguably the most popular, though many others exist. We could not begin to match the maturity and efficiency of these tools by writing our own from scratch. Users are much better served by using these tools directly and then, after careful review of the results, importing data into NetBox manually.
Let's assume we implemented some form of wrapper around nmap or another tool so that it could be used directly from NetBox. This means that everything you want to scan must be reachable by the server(s) on which NetBox is installed. It's very likely that your security policy may not allow NetBox to talk directly with every node on the network.
And even if it does, you might not want it to. For example, suppose you have NetBox running in the United States and need to scan a /16 of IPv4 space in China. Rather than transmitting 65,000 probes across the Pacific, it would be much more efficient to scan the network from a bastion host in the same country.
But suppose your network is entirely constrained to a single geographic region and NetBox can talk to everything. You still have to deal with the reality that scanning isn't going to be 100% correct. Scanning can't tell you for certain whether an IP is in use; only whether it is responsive at a given moment. For example, suppose a host is temporarily offline, or has been configured to block ICMP requests. These won't show up in your scan.
What happens when a previously defined IP stops showing up in a scan? Should it be deleted? The host might actually still exist, though. Maybe we should mark it as "previously used" somehow. But then we're still using a database record to track an IP that might not even exist. And should we automatically add new IPs that pop up? What if they're not supposed to be there?
All this boils down to a single concept: NetBox is intended to represent the intended state of the network, as defined by humans, whereas scanning a live network reflects only its actual state at that moment. When you attempt to define the correct state by referencing the actual state with no intermediate process of validation, bad things happen.
The subnet mask is part of an IP address: You cannot assign an IP address to an interface in the real world without also specifying its subnet mask. A device uses its interface's mask to determine the boundary of its layer two domain.
In keeping with its core design philosophy of directly modeling the real world, NetBox requires that the subnet mask be stored along with each IP address. This allows users to validate real-world configurations against NetBox data in a very efficient manner, as well as aiding the detection of invalid addresses within NetBox.
Omitting the mask from the IP address model would require us to make dangerous inferences about each IP address. For example, if you are given only the IP address 192.0.2.123, you cannot determine its network without additional information. You could look for its most-specific parent prefix: let's assume 192.0.2.0/24 has been created. But that doesn't necessarily indicate that our IP has a /24 mask. That /24 might be a smaller container used for administrative organization inside a larger parent, or there might be a more-specific /25 or /26 prefix missing from NetBox. Or it could be a loopback IP that should have a /32 mask.
Treating an IP address and its subnet mask as an atomic unit ensures a much greater degree of efficiency and accuracy.
It's important to understand the difference between physical and virtual circuits. Suppose you have five sites arranged in a hub-and-spoke topology. The hub site has a point-to-point virtual circuit to each of its spoke sites; spoke-to-spoke traffic must pass through the hub. The virtual circuits are configured as 802.1Q-tagged subinterfaces on the hub site's router.
In this scenario, there are five physical circuits: One to each of the five sites from the provider. These five circuits carry traffic to support an overlay comprising four virtual circuits (one to each spoke site from the hub). A physical circuit is responsible for the physical transmission of a signal from one point to another, whereas a virtual circuit is a purely logical construct.
NetBox models only physical circuits, which can be terminated to physical interfaces on devices. While the ability to model virtual circuits would certainly be useful, it is impractical to account for the myriad technologies which might be used to establish a topology.
The set of available interface form factors is statically defined in NetBox; users cannot add arbitrary form factors. This is done to remove the potential for creating duplicate or illegitimate form factors that would degrade the data model. If there's a form factor you'd like to see added to NetBox, consider opening a feature request detailing your use case. (However, bear in mind that only actual hardware interface types will be added.)
Custom fields allow users to define additional data fields on certain NetBox objects. These can be used to track object attributes which are important to an individual organization, but that wouldn't make sense to implement in the official NetBox database schema. For example, maybe you need to add a legacy_name field to the Device model, or ticket_number field to an IP address.
NetBox allows custom fields to be added only to primary models. Within the DCIM application, for instance, custom fields can be added only to the Site, Rack, DeviceType, and Device models. They cannot be added to the Region, RackGroup, DeviceRole, or other models which are used primarily for organizational purposes. The relevant distinction is that primary models have dedicated views (e.g. /dcim/devices/<pk>/ for a device) whereas secondary models do not. Thus, it doesn't make sense to included arbitrary additional data. (Custom fields should not be included in object lists due to the overhead they impose, which is one additional query per field, per object in the list.)
NetBox supports the attachment of images to certain models, namely sites, racks, and devices. This feature was added as a convenience to provide readily-accessible photographic documentation of installations. For instance, a data center technician might opt to upload a close-up photo of a device and its connections to clarify where each named interface resides on the box.
While NetBox might seem like an ideal place to store additional documents (PDFs, configurations, etc.), these are best maintained with the rest of your network's static documentation in a dedicated file store with appropriate access controls and revision history. Although other files cannot be uploaded to NetBox, you can link to them from NetBox in the comments section of an object, or within a custom URL field. Feature request #969 (currently a work in progress) will make this approach easier by introducing support for templatized URLs to external resources.