Visitar URL original
Allow master subnets from parent Sections · Issue #4664 · phpipam/phpipam · GitHub
Skip to content

Allow master subnets from parent Sections #4664

Open

Description

@maxslaves

Is your feature request related to a problem? Please describe.
I need to manage IP address hierarchies across multiple Sections.

For example, I have the following Section hierarchy:

GLOBAL
└── AZIENDA0

The GLOBAL Section contains the main network:

10.0.0.0/8

The AZIENDA0 Section contains:

10.0.0.0/24

The /24 subnet belongs administratively to AZIENDA0, so it must remain assigned to that Section. However, from an IP addressing perspective, it is a subnet of GLOBAL / 10.0.0.0/8.

Currently, when creating or editing the 10.0.0.0/24 subnet in AZIENDA0, the Master Subnet selector does not allow me to select GLOBAL / 10.0.0.0/8 because the master subnet belongs to a different Section.

This prevents me from representing the actual IP hierarchy while keeping the correct Section ownership.

I also tested manually setting masterSubnetId of the /24 to the ID of the /8. However, the Space Map of the /8 does not correctly consider the /24 as an allocated subnet.

Describe the solution you'd like
I would like phpIPAM to allow a subnet to use a Master Subnet belonging to a parent/ancestor Section, while keeping the child subnet assigned to its own Section.

For example:

GLOBAL
└── 10.0.0.0/8
│
└── AZIENDA0
└── 10.0.0.0/24

The expected configuration would be:

10.0.0.0/8
Section = GLOBAL
masterSubnetId = 0

10.0.0.0/24
Section = AZIENDA0
masterSubnetId = ID of GLOBAL / 10.0.0.0/8

The Master Subnet selector should therefore be able to display compatible subnets from parent/ancestor Sections.

The relationship should only be allowed when the selected Master Subnet actually contains the child subnet according to its CIDR.

Furthermore, the Space Map of the Master Subnet should consider child subnets belonging to descendant Sections as allocated/occupied.

For example, the Space Map of:

GLOBAL / 10.0.0.0/8

should show:

10.0.0.0/24 allocated/occupied

even though the /24 belongs to the AZIENDA0 Section.

Subnets from unrelated Sections should not be selectable as Master Subnets.

Describe alternatives you've considered
I considered assigning the child subnet to the same Section as the Master Subnet, but this does not work for environments where Sections represent administrative or organizational ownership.

Another alternative would be to duplicate or recreate the IP hierarchy within each Section, but this would result in duplicated information and would not accurately represent the actual address hierarchy.

I also tested manually setting masterSubnetId in the database to the ID of the subnet in the parent Section. Although the database relationship can be represented this way, the current UI does not provide a way to select the parent Section's subnet as Master, and the Space Map does not correctly reflect the cross-Section relationship.

Describe how the feature would benefit other users
This feature would be useful for environments where phpIPAM Sections are used to represent organizational, administrative, customer, business-unit, or geographic boundaries, while the Master Subnet hierarchy represents the actual IP address allocation hierarchy.

For example:

GLOBAL
├── 10.0.0.0/8
│
├── COMPANY-A
│ └── 10.0.0.0/16
│
├── COMPANY-B
│ └── 10.1.0.0/16
│
└── COMPANY-C
└── 10.2.0.0/16

Each company could maintain its own Section while the parent Section maintains the larger address space.

The feature would allow phpIPAM to separate two concepts:

Section: administrative/organizational ownership of a subnet.

Master Subnet: hierarchical relationship between IP address spaces.

This would make the Section hierarchy and IP subnet hierarchy usable together without requiring users to move subnets between Sections.

The proposed behaviour could be generalised to allow Master Subnets from the current Section or any parent/ancestor Section, provided that the Master Subnet contains the child subnet.

phpIPAM version: 1.8.3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions