Aggregates
IP addressing is by nature hierarchical. The first few levels of the IPv4 hierarchy, for example, look like this:
Circuit and provider management
View all tagsIP addressing is by nature hierarchical. The first few levels of the IPv4 hierarchy, for example, look like this:
The registry is an in-memory data structure which houses various application-wide parameters, such as the list of enabled plugins. It is not exposed to the user and is not intended to be modified by any code outside of NetBox core.
Circuits can be assigned to circuit groups for correlation purposes. For instance, three circuits, each belonging to a different provider, may each be assigned to the same circuit group. Each assignment may optionally include a priority designation.
Circuits can be arranged into administrative groups for organization. The assignment of a circuit to a group is optional.
Each circuit may have up to two terminations, designated A and Z. At either termination, a circuit may connect to a site, device interface (via a cable), or to a provider network.
Circuits are classified by functional type. These types are completely customizable, and are typically used to convey the type of service being delivered over a circuit. For example, you might define circuit types for:
NetBox is ideal for managing your network's transit and peering providers and circuits. It provides all the flexibility needed to model physical circuits in both data center and enterprise environments, and allows for "connecting" circuits directly to device interfaces via cables.
A circuit represents a physical point-to-point data connection, typically used to interconnect sites across considerable distances (e.g. to deliver Internet connectivity).
IPSEC VPN Tunnels
A cluster type represents a technology or mechanism by which a cluster is formed. For example, you might create a cluster type named "VMware vSphere" for a locally hosted cluster or "DigitalOcean NYC3" for one hosted by a cloud provider.
Much like tenancy, contact assignment enables you to track ownership of resources modeled in NetBox. A contact represents an individual responsible for a resource within the context of its assigned role.
CUSTOM_VALIDATORS
NetBox provides a read-only GraphQL API to complement its REST API. This API is powered by Strawberry Django.
NetBox
Beginning with NetBox v4.0, NetBox will leverage Django's automatic translation to support languages other than English. This page details the areas of the project which require special attention to ensure functioning translation support. Briefly, these include:
This document serves as a handbook for maintainers of plugins that were written prior to the release of NetBox v4.0. It serves to capture all the changes recommended to ensure a plugin is compatible with NetBox v4.0 and later releases.
Thanks for your interest in contributing to NetBox! This introduction covers a few important things to know before you get started.
Model Types
v2.0.10 (2017-07-14)
v2.1.6 (2017-10-11)
v2.10.10 (2021-04-15)
v2.11.12 (2021-08-23)
v2.2.10 (2018-02-21)
v2.3.7 (2018-07-26)
v2.5.13 (2019-05-31)
v2.6.12 (2020-01-13)
v2.7.12 (2020-04-08)
v2.9.11 (2020-12-11)
v3.0.12 (2021-12-06)
v3.1.11 (2022-04-05)
v3.2.9 (2022-08-16)
v3.3.10 (2022-12-13)
v3.4.10 (2023-04-27)
v3.5.9 (2023-08-28)
v3.7.8 (2024-05-06)
v4.0.11 (2024-09-03)
v4.1.11 (2025-01-06)
v4.2.9 (2025-04-30)
v4.3.4 (2025-07-15)
This guide outlines the steps necessary for planning a successful migration to NetBox. Although it is written under the context of a completely new installation, the general approach outlined here works just as well for adding new data to existing NetBox deployments.
As part of its DCIM feature set, NetBox supports modeling facility power as discrete power panels and feeds. These are most commonly used to document power distribution within a data center, but can serve more traditional environments as well.
This model can be used to represent individual accounts associated with a provider.
This model can be used to represent the boundary of a provider network, the details of which are unknown or unimportant to the NetBox user. For example, it might represent a provider's regional MPLS network to which multiple circuits provide connectivity.
A provider is any entity which provides some form of connectivity of among sites or organizations within a site. While this obviously includes carriers which offer Internet and private transit service, it might also include Internet exchange (IX) points and even organizations with whom you peer directly. Each circuit within NetBox must be assigned a provider and a circuit ID which is unique to that provider.
NetBox releases are numbered as major, minor, and patch releases. For example, version 3.1.0 is a minor release, and v3.1.5 is a patch release. Briefly, these can be described as follows:
What is a REST API?
Most core objects within NetBox's data model support tenancy. This is the association of an object with a particular tenant to convey ownership or dependency. For example, an enterprise might represent its internal business units as tenants, whereas a managed services provider might create a tenant in NetBox to represent each of its customers.
This model represents the connection of a virtual interface to a virtual circuit.
Like physical circuits, virtual circuits are classified by functional type. These types are completely customizable, and can help categorize circuits by function or technology.
A virtual circuit can connect two or more interfaces atop a set of decoupled physical connections. For example, it's very common to form a virtual connection between two virtual interfaces, each of which is bound to a physical interface on its respective device and physically connected to a provider network via an independent physical circuit.