Feature Request: Folder-like hierarchical view for IPAM (like phpIPAM)

[negritodominic]

Feature Request: Hierarchical Tree View for IP Prefix Management

Problem Statement:
The current IPAM interface lacks a native hierarchical tree view, making large-scale prefix management (35,000+ prefixes across multiple nesting levels) impractical. Users must navigate through paginated flat lists or open individual prefix pages, breaking workflow continuity and obscuring parent-child relationships critical for network design and troubleshooting.

Technical Use Case & Current Limitations:

• Hierarchy Depth: Networks are designed with deep nesting (e.g., /12 → /16 → /24 → /28 → /30), but NetBox only displays immediate parent-child relationships without recursive visualization.
• Navigation Overhead: Each prefix click opens a new page, disrupting context and slowing down operations like IP allocation or audit trails.
• Missing "Folder" Analogy: Unlike systems like phpIPAM (with isfolder-like functionality), NetBox lacks a collapsible/expandable UI to browse prefixes as a tree structure within a single view.

Proposed Solution:
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.).
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 expansion depth (e.g., show up to 5 nesting levels by default).
4. Inline Metrics: Display utilization metrics (used/available IPs) at each tree node without leaving the view.
5. API Integration: Extend the REST API to support tree-based queries (e.g., GET /api/ipam/prefixes/?tree=true&parent_id=<id>).

Why This Matters for Large Networks:

• Operational Efficiency: Trace IP allocations across nested subnets in seconds, not minutes.
• Capacity Planning: Visualize utilization at every hierarchy level (not just top-level aggregates).
• Network Documentation: Reflect actual network design principles (regional/distribution/access layers) in the UI.
• Migration Path: Enable smoother migration from tools like phpIPAM, where hierarchical views are a core feature.

Example Hierarchy Visualization:

10.0.0.0/8 (Backbone) [65% utilized]
├── 10.16.0.0/12 (Region A) [40% utilized]
│   ├── 10.16.0.0/16 (District 1) [60% utilized]
│   │   ├── 10.16.0.0/24 (Building A) [80% utilized]
│   │   │   ├── 10.16.0.0/28 (Servers) [100% utilized]
│   │   │   └── 10.16.0.16/28 (WiFi) [50% utilized]
│   │   └── 10.16.1.0/24 (Building B) [20% utilized]
│   └── 10.17.0.0/16 (District 2) [10% utilized]
└── 10.32.0.0/12 (Region B) [5% utilized]

Reference & Community Demand:
This issue has been raised repeatedly (e.g., [Reddit thread from 2022] https://www.reddit.com/r/Netbox/comments/scfhgb/looking_for_plugins_or_anything_that_generate/ , with users highlighting the need for folder-like navigation. While NetBox excels in features like tagging, tenant management, and plugin ecosystems, the absence of hierarchical IPAM views remains a barrier for large-scale adopters.

Requested Priority:
Consider this a core IPAM enhancement for enterprises managing complex networks. A plugin-based approach could be an interim solution, but native support would ensure scalability and UI consistency.

[Space-Monkey54321]

Agreed, these features would be SUPER handy to have and would give Netbox feature parity to specialized IPAM managers while serving as the single source for truth!

[mkarel]

I would post this in the issues section as a Feature Request.