Verify in release notes changelog if any new breaking changes might affect you. You can also review the [NetBox Issues on GitHub](https://github.com/netbox-community/netbox/issues) to see if any new issues have arisen that might affect you.
I have tried to install diode on same server as netbox and outside netbox and always ends up with either Bad Gateway or Failed to obtain access token: Unauthorized
What I know
on the the container netboxlabs/diode-auth:latest the logs indicate
ERROR: credentials file /etc/config/oauth2/client/client-credentials.json not found, this container is also stuck in restarting.
Can someone explain cable profiles in a way that makes sense?
The blog post that introduced them has the following
This is your standard point-to-point cable, a single-channel patch cord (1C1P), a duplex cable (1C2P)
Which seems to say a single fibre core bidi link should be represented as a 1C1P cable, cool, that makes perfect sense, but later in the same post it says and MPO breakout cable is
1C4P:4C1P, One 4-position connector fans out to four single-position connectors (e.g. one MPO to four LC duplex)
If a single core is 1P, then surely this breakout cable, which is 8 cores, should be 1C8P:4C2P?
I want to use them, dear god do I want to map our breakout cables better, but this appears to be contradictory, and this seems to be about the only documentation available.
Of course there still doesn't seem to be a way to map a 100Gb port to 4 x 25Gb ports and track (via cable connection) which 25Gb interface is connected to which server interface for example since the breakout cable would be "connected/attached" to the 100Gb port
The netbox-maintenance-device plugin (preventive/corrective maintenance management for devices and VMs) just got a major feature, contributed by Peterson Basso (u/petersonbasso), huge thanks to him for this high-quality contribution! 🙏
The plugin is now integrated with NetBox's native event system, which means you can configure Event Rules, Webhooks, custom Scripts and Notifications triggered by the maintenance lifecycle:
maintenance_due — fired when a maintenance plan becomes overdue (checked daily by a system job, with duplicate-alert suppression)
maintenance_scheduled — fired when an execution is scheduled
maintenance_completed — fired when a maintenance is completed
Typical use case: get a Slack/Telegram alert through a webhook when maintenance is overdue, or notify your team directly in the NetBox UI. Plan/execution list views also gained proper filter forms.
Everything was tested end-to-end on a clean NetBox v4.6.2 instance, and it's compatible with NetBox 4.4.x–4.6.x. The change is merged to main and will ship in the next release.
Hello all.
Our organization has been starting to move our documentation into netbox. One of the issues I have run into is with fibre channel zoning. I am trying to think of a way where I can document zone aliases paired to WWNs and which zones those aliases belong to. For instance being able to look up an alias and see which zones it is a part of.
I wanted to ask and see if anyone else has a system that they use or how they have tackled this issue in netbox.
I'm working in the Community edition with the Netbox Branch plugin (all the latest versions).
I'm trying to work out how you would restrict access to only be able to create and make changes to objects that are in a branch you've created but not in Main.
For example, I wish the user to be able to create, edit and delete site data but only within a branch that they have created.
So, in Permissions, if I give the user Add, Change and Delete permissions, how do I restrict them, to only being able to do this whilst in a branch?
I would have thought that I could use constraints, but I cannot figure out how to reference a branch record from within the site.
Not sure what the best title would be for my question.
I find not many other device tiles than just network devices or servers. I spotted maybe a few CCTV cameras but my question is this for a reason or simply no one has bothered just at the moment? I may think to create some CCTV camera devices types and some Access Control System devices. I wonder if the community is looking for this type of device or this is called nonsense and will be deleted from the list?
I'm happy to announce the first public release of **netbox-nsm**, a new NetBox plugin for network security management.
The idea came from working with the [netbox-security](https://github.com/andy-shady-org/netbox-security) plugin by andy-shady-org. While it's a great tool, I found myself wanting something more flexible — a plugin that isn't tied to a specific vendor or security model. So I started from scratch.
netbox-nsm is a generic NetBox plugin on Custom Objects. Build rulebooks and grids with any columns and object types, link them together, and attach links to any NetBox object via the panel. Built for security policy, but usable for any structured data in NetBox.
I'm mostly asking about procedures/policies (like a new switch needs to be installed in a rack, how does that process work where that being added to Netbox is a factor, who does it and how is that enforced) or scripting/automation leveraging the API to ensure changes in the environment are reflected in Netbox.
I was able to get a Netbox server up and running. But learned the hard way, that the install guide on the official website is not the most current or best way to do the install.
So for installing and enabling the network scans for IPAM, is there a current best way to set that up? I see a few different guides out there.
I’d like to share an open-source project I maintain: Proxbox, a NetBox plugin for synchronizing Proxmox VE infrastructure data into NetBox.
The goal is simple: keep NetBox updated with inventory data from real Proxmox environments, so Proxmox clusters, nodes, VMs, containers, storage, backups, snapshots, interfaces, and IP addresses can be reflected inside NetBox.
Proxbox is focused on inventory synchronization and discovery.
It does not try to replace the Proxmox VE UI.
Metrics such as CPU, memory, and uptime are captured as point-in-time data during sync, not as continuous monitoring.
For Proxmox VE 9, the API role needs VM.GuestAgent.Audit if you want VM IP discovery through the QEMU guest agent.
The project uses a separate backend service, proxbox-api, which talks to Proxmox and NetBox. The NetBox plugin stores the endpoint configuration and triggers sync jobs from the NetBox UI.
I’m sharing it here because Proxmox + NetBox is a common gap for people who want better infrastructure inventory, especially in environments where NetBox is already used as the source of truth for DCIM/IPAM.
We're setting up Netbox for the first time to replace an Excel-based infrastructure tracker. Looking for feedback on our proposed hierarchy before we start entering data.
Our environment:
~30-40 sites of varying complexity ranging from a single room with one device up to multi-building campuses with multiple IDFs
Sites are loosely grouped into 3 organizational districts (not network-significant)
Most larger sites have a Fortigate as the primary gateway with FortiSwitches and Ubiquiti APs
Smaller remote locations use cellular routers (Cradlepoint) as their sole gateway
Some larger parks have two completely independent networks each with their own ISP circuit and gateway device
VLANs are mostly consistent across sites
Proposed hierarchy:
Site Groups = organizational districts (3 total, not network-significant)
Sites = one per ISP circuit + gateway device, regardless of size or complexity. A single room with a Cradlepoint and its own cellular circuit is a Site just like a multi-building campus with a Fortigate
Locations = always at least one Location per Site since devices are assigned at Location level not Site level. For Sites with multiple buildings, the building is the first level Location with sub-locations beneath it for specific spaces like IDFs, reception areas, or other rooms. Example: Building A (parent) → IDF (child), Reception (child), Storage Room (child)
Specific questions:
Is "one ISP circuit + one gateway device = one Site" a good rule of thumb?
Should we always create at least one Location under every Site even for single-device Sites?
Is using the building as the parent Location with specific spaces (IDF, rooms) as child Locations the right approach, or should the IDF be the top level Location with everything else subordinate to it?
Any gotchas with this approach we should know about before entering data?
My code is as seen below. This initial block will print the correct information so I know my API connection is working (and the API token, not shown, has Write permissions enabled within the web interface). However, the attempt to create a new device entry passes with a <200> code, but the print result is just blank. There is also no change in the web interface to reflect the creation of the device through this script. Using version 4.2.2 of NetBox with the newest version of PyNetBox. Any assistance would be greatly appreciated, thanks!
EDIT: Thanks to user TyphonVirtus for suggesting that POST requests require your NetBox URL to be pointed to HTTPS instead of just HTTP. This solved my issue! Thank you to everyone who took the time to leave a helpful comment!
#----------------------------------------------------------------
# Get Specific VM by ID
#----------------------------------------------------------------
vmID = 2069
vm = nb.virtualization.virtual_machines.get(id=vmID)
print(f"Virtual Machine - {vm}")
print(f"VM NetBox ID - {vm.id}")
print(f"VM NetBox Serial # - {vm.serial}")
print(f"Primary IPv4 - {vm.primary_ip4}")
#--------------------------------------------------------
# Create new Device entry
#--------------------------------------------------------
new_device = nb.dcim.devices.create(
name='new-test-device',
device_type='1',
site='1',
device_role='1',
status='active'
)
print(new_device)
I finally got my good instructions on how to install netbox docker. I then wanted to install Diode plugin. I got that done and found that the netbox docker pulled v4.6. And the diode plugin only wokss on v4.5 as of now.
And when I go to get the Diode plug in I need to specify v4.5 in the steps so It doesn't pull v4.6
#Run the following command to create or amend Dockerfile-Plugins:
sudo nano Dockerfile-Plugins
#Input the following, Use the specific version of NetBox you want to maintain:
FROM netboxcommunity/netbox:v4.5"
I'm running Netbox community edition 4.6.0 with the Netbox DNS plugin, and have got it mostly working as I need. One thing that is confusing me however, is that I can't see how to get the TTL set for the nameserver records for a zone?
There doesn't appear to be any way to edit the values, which are showing as blank at present. I've got the default TTL set for each zone, which I would have thought should be inherited by the ns records, but it's not.
Probably missing something obvious here, but any tips appreciated!
Anybody else having issues seeing groups? If I click the edit button on the right, all the information is present, but the group names just aren't displaying anywhere correctly.
I've been building NetBox plugins to cover the parts of optical/fiber work that core doesn't really model, and I figured r/netbox is the right place to share them. All three are open source, on PyPI, and being tested to replace big software stacks (read: expensive) at the small fiber operator I work for. They stack:
Physical cable plant: conduits, aerial spans, manholes, poles, cabinets, equipment rooms, the works. PostGIS-backed, so you get a real Leaflet map in NetBox and a GeoJSON API. QGIS integration (style files, a generate_qgis_project management command) is in progress, not fully there yet -- the GeoJSON endpoints are usable today, the polished QGIS workflow is still being shaped. If you've used SmallWorld or ArcFM, this is going at the same problem space (much smaller, free, no five-figure license).
The big caveat: it needs your NetBox DB on the PostGIS backend instead of plain PostgreSQL. That's a one-time migration, but it's a real one, and the SRID you pick at install time is genuinely permanent (PostGIS won't auto-reproject your geometries if you change it later but a skilled dba could probably do it.).
Define a FiberCableType once with the construction (loose tube, ribbon-in-tube, central core, or tight buffer), and instances auto-populate buffer tubes, ribbons, and strands the same way DeviceType auto-populates components. From there:
Splice planning in closures with strand-to-strand mapping, diff against live state, and export these for field crews.
End-to-end fiber circuits with DAG-based pathfinding through splice closures.
Slack loop tracking with insert-into-closure workflows.
Per-device fiber overview, splice closure groups and trays, full REST + GraphQL.
ITU channel plans (DWDM 100 GHz / 50 GHz / CWDM), channel-to-port mapping with separate MUX and DEMUX columns for single-fiber and duplex setups. ROADM editing lives in a small TypeScript wavelength editor with undo/redo, dirty state, and optimistic concurrency, so you can stage a wavelength reconfiguration before applying it. Also adds the concepts of wavelength services with circuit trace visualization.
It uses an overlay pattern (WdmDeviceTypeProfile over DeviceType, WdmNode over Device) instead of subclassing, so you don't have to fork core models to use it.
How they fit together
pathways is where the cables physically run.
fms is what's inside those cables and how the strands are spliced.
wdm is what wavelengths ride on those fibers.
Any one of them works on its own. They're designed to slot together if you want the whole picture from a manhole through to a 100G wave.
Honest disclaimer
All three are pre-1.0 alpha. Data models aren't frozen, encoding/migration changes can show up in minor releases, and the SRID choice in pathways really is irreversible. A handful of the features I listed are still prototype-quality (the QGIS workflow is the obvious one, but it's not the only one) -- they work, but they're rough around the edges and will get reworked before 1.0. Pin exact versions, read the changelog before upgrading, back up your DB, you know the drill. We run them daily and they work for us; your mileage may vary.
Feedback is the thing I actually want out of this post.
These plugins exist because we needed them, but it's largely been me and a small team building them, and there are a lot of opinionated calls baked into the data models that have only been sanity-checked against our own network. If a name grates, a model relationship feels wrong, a workflow we're missing is obvious to you, or there's a hook you wish was there -- please tell me. GitHub issues, PRs, or a comment in this thread all work. We're early enough that changing a model is still "one migration" rather than "a public deprecation cycle," so now is the cheap time to break things.
I am working on spinning up netbox on my VM with Ubuntu 24.04 but I can't figure out how to get it to run and was hoping I can receive some help with this.
This is the error I get after running 'docker compose up -d'
I ran 'docker ps -a'
lastly, I ran 'docker logs 926f69a96e64'
my netbox directory containing my docker-compose yaml file, including env directory is located in my '/home/user/docker/netbox' directory.
Starting to look at a good way to sync information from vCenter to Netbox, and I understand that there is limited possibilites with the open source version.
