Folder-like hierarchical tree view for IPAM (like phpIPAM) #386

New Issue

MrUnknownDE · 2026-04-05T16:28:44+02:00

MrUnknownDE commented

2026-04-05 16:28:44 +02:00

Originally created by @negritodominic on 2/11/2026

NetBox version

v4.5.2

Feature type

New functionality

Proposed functionality

Implement a recursive tree view component for the IPAM prefix list with the following capabilities:

Expandable Hierarchy: Render all nested prefixes under a parent prefix without page reloads (e.g., expand a /16 to see all /24s, /28s, etc.) in a single view.
Breadcrumb Navigation: Visualize the current path within the prefix tree (e.g., 10.0.0.0/8 > 10.16.0.0/12 > 10.16.0.0/16).
Configurable Depth: Allow users to set default expansion depth (e.g., show up to 5 nesting levels) with the ability to expand/collapse individual branches.
Inline Metrics: Display utilization metrics (used/available IPs) at each tree node directly in the view, eliminating the need to open individual prefix pages.
API Integration: Extend the REST API to support tree-based queries (e.g., GET /api/ipam/prefixes/?tree=true&parent_id=) to power the UI component.
Folder-like behavior: Similar to phpIPAM, allow prefixes to visually function as "folders" that can be expanded/collapsed to reveal nested child prefixes.

Example visualization:

10.0.0.0/8 (Backbone)
├── 10.16.0.0/12 (Region A)
│ ├── 10.16.0.0/16 (District 1)
│ │ ├── 10.16.0.0/24 (Building A)
│ │ │ ├── 10.16.0.0/28 (Servers)
│ │ │ └── 10.16.0.16/28 (WiFi)
│ │ └── 10.16.1.0/24 (Building B)
│ └── 10.17.0.0/16 (District 2)
└── 10.32.0.0/12 (Region B) ]

Use case

Organizations managing large-scale IPAM deployments (35,000+ prefixes across multiple nesting levels) currently face significant operational inefficiencies:

The current interface forces users to navigate through paginated flat lists or open individual prefix pages, breaking workflow continuity and obscuring parent-child relationships.
Network designs inherently follow hierarchical patterns (e.g., /12 → /16 → /24 → /28 → /30) that are not visually represented in the UI. NetBox currently only shows immediate parent-child relationships without recursive visualization.
Critical operations like IP allocation, audit trails, and capacity planning require tracing allocations across 4-5 nesting levels - currently taking minutes per query instead of seconds.
The absence of folder-like navigation makes NetBox less competitive for enterprises migrating from tools like phpIPAM, where hierarchical views are a core differentiator.
Community demand: This has been repeatedly requested (Reddit 2022, GitHub discussions #8234, #11567) as a barrier for large-scale adopters.

This feature would transform IPAM from a basic inventory tool into an enterprise-grade network documentation platform by:

Reducing navigation overhead by 80%+ for multi-level prefix management
Enabling real-time capacity visualization at every hierarchy level
Reflecting actual network design principles in the UI
Providing a clear migration path from legacy IPAM tools

Database changes

No database schema changes required. This feature relies on:

Existing parent/child relationships already stored in the database (via parent_id foreign key)
Recursive querying capabilities already supported by the ORM
New UI presentation layer only - data model remains unchanged

The API extension would be a new query parameter/filter, not a schema modification.

External dependencies

No new external dependencies required. The tree view can be implemented using:

Existing Django/PostgreSQL recursive query capabilities for backend
Native JavaScript/CSS for the expandable/collapsible UI component
No additional Python packages or third-party libraries needed

All required functionality (tree rendering, async expansion, utilization calculations) can be achieved with current NetBox stack.

*Originally created by @negritodominic on 2/11/2026* ### NetBox version v4.5.2 ### Feature type New functionality ### Proposed functionality Implement a recursive tree view component for the IPAM prefix list with the following capabilities: 1. Expandable Hierarchy: Render all nested prefixes under a parent prefix without page reloads (e.g., expand a /16 to see all /24s, /28s, etc.) in a single view. 2. Breadcrumb Navigation: Visualize the current path within the prefix tree (e.g., 10.0.0.0/8 > 10.16.0.0/12 > 10.16.0.0/16). 3. Configurable Depth: Allow users to set default expansion depth (e.g., show up to 5 nesting levels) with the ability to expand/collapse individual branches. 4. Inline Metrics: Display utilization metrics (used/available IPs) at each tree node directly in the view, eliminating the need to open individual prefix pages. 5. API Integration: Extend the REST API to support tree-based queries (e.g., GET /api/ipam/prefixes/?tree=true&parent_id=<id>) to power the UI component. 6. Folder-like behavior: Similar to phpIPAM, allow prefixes to visually function as "folders" that can be expanded/collapsed to reveal nested child prefixes. Example visualization: 10.0.0.0/8 (Backbone) ├── 10.16.0.0/12 (Region A) │ ├── 10.16.0.0/16 (District 1) │ │ ├── 10.16.0.0/24 (Building A) │ │ │ ├── 10.16.0.0/28 (Servers) │ │ │ └── 10.16.0.16/28 (WiFi) │ │ └── 10.16.1.0/24 (Building B) │ └── 10.17.0.0/16 (District 2) └── 10.32.0.0/12 (Region B) ] ### Use case Organizations managing large-scale IPAM deployments (35,000+ prefixes across multiple nesting levels) currently face significant operational inefficiencies: 1. The current interface forces users to navigate through paginated flat lists or open individual prefix pages, breaking workflow continuity and obscuring parent-child relationships. 2. Network designs inherently follow hierarchical patterns (e.g., /12 → /16 → /24 → /28 → /30) that are not visually represented in the UI. NetBox currently only shows immediate parent-child relationships without recursive visualization. 3. Critical operations like IP allocation, audit trails, and capacity planning require tracing allocations across 4-5 nesting levels - currently taking minutes per query instead of seconds. 4. The absence of folder-like navigation makes NetBox less competitive for enterprises migrating from tools like phpIPAM, where hierarchical views are a core differentiator. 5. Community demand: This has been repeatedly requested ([Reddit 2022, GitHub discussions #8234, #11567](https://www.reddit.com/r/Netbox/comments/scfhgb/looking_for_plugins_or_anything_that_generate/)) as a barrier for large-scale adopters. This feature would transform IPAM from a basic inventory tool into an enterprise-grade network documentation platform by: - Reducing navigation overhead by 80%+ for multi-level prefix management - Enabling real-time capacity visualization at every hierarchy level - Reflecting actual network design principles in the UI - Providing a clear migration path from legacy IPAM tools ### Database changes No database schema changes required. This feature relies on: 1. Existing parent/child relationships already stored in the database (via `parent_id` foreign key) 2. Recursive querying capabilities already supported by the ORM 3. New UI presentation layer only - data model remains unchanged The API extension would be a new query parameter/filter, not a schema modification. ### External dependencies No new external dependencies required. The tree view can be implemented using: 1. Existing Django/PostgreSQL recursive query capabilities for backend 2. Native JavaScript/CSS for the expandable/collapsible UI component 3. No additional Python packages or third-party libraries needed All required functionality (tree rendering, async expansion, utilization calculations) can be achieved with current NetBox stack.

MrUnknownDE closed this issue

2026-04-05 16:28:44 +02:00

Sign in to join this conversation.

Branches Tags

main

21455-sql-indexes-audit

21357-register-model-actions

feature

20924-plugin-ui-components

21766-improve-test-coverage-for-sortable-table-columns

21157-export-template-public-models

21025-pre-render-config-contexts

21364-swagger

feature-ip-prefix-link

20911-dropdown-3

fix_module_substitution

21160-filterset

20911-dropdown-2

20044-elevation-stuck-lightmode

7604-filter-modifiers-v3

20660-script-load

19724-graphql

14884-script

19720-macaddress-interface-generic-relation

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

No Label netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/netbox#386