NetBox Capabilities

The NetBox authors proudly stress that they have put much thought into how to manage data in NetBox. The outcome is an extended data model that distinguishes between objects of different types, with a type for each resource that NetBox can manage, such as data centers or sites, racks, devices (servers or switches), network interfaces, IP addresses, and VLANs, to cite a few examples. NetBox garnishes the management of IP addresses and hardware in the rack with additional features, all of which focus on infrastructure management.

Connections between two points have their own object type: circuit. The best data center in the world is of little use if it does not have a connection to the outside world, but such a connection has previously challenged DCIM and IPAM systems, especially when data sets include multiple data centers and the links between these data centers need to be shown.

NetBox also allows you to define different types of circuits, including the Internet transit, out-of-band connectivity, peering, and private backhaul types. Therefore, NetBox even allows ISPs to map existing peering relationships to other providers.

Multitenant Capability

One killer feature in NetBox is its multitenant capability, which allows you to define levels and allocate them to organizations; NetBox can then map the dependencies between these organizations. In one possible scenario, a customer can rent part of a rack's capacity and in turn resell space in the rack commercially to others.

All objects in NetBox can be assigned to tenants, who can then be grouped. This capability is more of a logical division for the sake of clarity. For example, if you want to show customers and partners separately in NetBox, you can use tenancy for this purpose.

The NetBox developers specifically point out that they follow the Pareto principle, which states that 80 percent of the desired and required functionality can be achieved with 20% of the code. Or to put this another way: NetBox does not offer every single function that may be desirable in the IPAM and DCIM context. Instead of PostgreSQL, an already existing MySQL can be used. The NetBox codebase is small and manageable, so you do not need to do battle with a feature-bloated monster. The sleek design is also very conducive to performance.

Export Templates

With DCIM and IPAM playing an increasingly important role for providers, it will be necessary to exchange data with other services sooner or later. NetBox offers several options in this respect, the most important of which is based on export templates. For each object type, you create templates that define a specific output format. NetBox relies on the Django template language in this context; in turn, Django draws heavily on the Jinja2 language (i.e., the template language used by Ansible). Using predetermined parameters, you can then access objects in Ansible with these templates.

All values stored for an object can be used in the NetBox export templates. The export itself is ultimately initiated via the appropriate pages in the web interface. For example, it is possible to create configuration files for Nagios automatically in NetBox.

If you like things colorful, you will find useful add-ons. External links let you integrate graphs into the NetBox interface – RRD data from an existing monitoring system can be displayed in a graphical interface in close proximity to the switches to which the data belongs.

The topology maps that NetBox generates are equally practical: Using a search box, you enter the devices you want to display on such a map. NetBox then automatically generates an attractive image that clearly shows how the individual devices are connected to each other – even down to the level of individual interfaces.