Restore ability to collapse prefix hierarchy to uppermost level #4123

Originally created by @marbarmar on GitHub (Sep 21, 2020).

Environment

Python version: 2.7.5
NetBox version: 2.9.3

Buttons Collapse and Expand are missing in 2.9.3 netbox while they were present in 2.8 version of netbox

Proposed Functionality

Collapse and expand buttons would collapse/expand the view of prefixes so we will see only parent subnets on top of our network hierarchy (in case of collapse) or see all networks (in case of expand).

Use Case

We do manual search in Netbox Prefixes quiet often. We need to do this searches hierarchically, which mean start from the parent super-net and follow through parent networks down to end device subnet. Without collapse and expand button this became more difficult.

Also opening Prefixes in collapsed form is more lucid and we do see the hirerarchy of most parent subnets.

Database Changes

no database changes are expected

External Dependencies

no external dependencies are expected

Originally created by @marbarmar on GitHub (Sep 21, 2020). ### Environment * Python version: 2.7.5 * NetBox version: 2.9.3 Buttons Collapse and Expand are missing in 2.9.3 netbox while they were present in 2.8 version of netbox ### Proposed Functionality Collapse and expand buttons would collapse/expand the view of prefixes so we will see only parent subnets on top of our network hierarchy (in case of collapse) or see all networks (in case of expand). ### Use Case We do manual search in Netbox Prefixes quiet often. We need to do this searches hierarchically, which mean start from the parent super-net and follow through parent networks down to end device subnet. Without collapse and expand button this became more difficult. Also opening Prefixes in collapsed form is more lucid and we do see the hirerarchy of most parent subnets. ### Database Changes no database changes are expected ### External Dependencies no external dependencies are expected

adam added the type: feature status: needs owner pending closure labels 2025-12-29 18:33:17 +01:00

adam closed this issue

adam commented

@jeremystretch commented on GitHub (Sep 21, 2020):

This change was necessary to greatly improve performance when rendering the prefixes list; please see #4639.

We need to do this searches hierarchically, which mean start from the parent super-net and follow through parent networks down to end device subnet.

This is still possible in NetBox, both from the list view and from an individual prefix.

@jeremystretch commented on GitHub (Sep 21, 2020): This change was necessary to greatly improve performance when rendering the prefixes list; please see #4639. > We need to do this searches hierarchically, which mean start from the parent super-net and follow through parent networks down to end device subnet. This is still possible in NetBox, both from the list view and from an individual prefix.

adam commented

@marbarmar commented on GitHub (Sep 22, 2020):

Hello and thank you for your update.

I do understand that listing all prefixes without dealing with depth improved the response speed.

Would it be possible to add Collapse and Expand button back and while listing prefixes (IPAM > Prefixes) we will get the output the netbox 2.9.3 is currently giving (expanded) but using those buttons (Collapse/Expand) we will get the collapsed/expanded output as before?
This will get the the same results while listing prefixes but we will have the option to get collapsed output.

As I have described we quiet often open prefix, lets say /12, under which there are lots of /22s and under each there are host subnets /24, /25, /28, etc. Hierarchical listing is what we really need to go through and find what we are looking for.

Getting those buttons back would help us a lot.

If this is not an option for you than at least we need to see all subnets in Prefixes even those which are unassigned. Currently if I open lets say prefix 10.0.0.0/12 I do see all assigned prefixes and their child prefixes but I do see ONLY unassigned/available prefixes which are directly under 10.0.0.0/12.
For example if there is child prefix 10.0.4.0/22 under which there are lots of /28 prefixes and some of them are available I do not see those when going to IPAM > Prefixes.
This makes finding Available network almost impossible. We just have to go manually through all prefixes and hope to find one with some unassigned/available child prefix.

@marbarmar commented on GitHub (Sep 22, 2020): Hello and thank you for your update. I do understand that listing all prefixes without dealing with depth improved the response speed. Would it be possible to add Collapse and Expand button back and while listing prefixes (IPAM > Prefixes) we will get the output the netbox 2.9.3 is currently giving (expanded) but using those buttons (Collapse/Expand) we will get the collapsed/expanded output as before? This will get the the same results while listing prefixes but we will have the option to get collapsed output. As I have described we quiet often open prefix, lets say /12, under which there are lots of /22s and under each there are host subnets /24, /25, /28, etc. Hierarchical listing is what we really need to go through and find what we are looking for. Getting those buttons back would help us a lot. If this is not an option for you than at least we need to see all subnets in Prefixes even those which are unassigned. Currently if I open lets say prefix 10.0.0.0/12 I do see all assigned prefixes and their child prefixes but I do see ONLY unassigned/available prefixes which are directly under 10.0.0.0/12. For example if there is child prefix 10.0.4.0/22 under which there are lots of /28 prefixes and some of them are available I do not see those when going to IPAM > Prefixes. This makes finding Available network almost impossible. We just have to go manually through all prefixes and hope to find one with some unassigned/available child prefix.

adam commented

@jeremystretch commented on GitHub (Sep 22, 2020):

Any work toward this feature would need to be accomplished without sacrificing the performance gains achieved under #4639. @marbarmar are you interested in volunteering to own this work?

@jeremystretch commented on GitHub (Sep 22, 2020): Any work toward this feature would need to be accomplished without sacrificing the performance gains achieved under #4639. @marbarmar are you interested in volunteering to own this work?

adam commented

@Joezeppe commented on GitHub (Sep 26, 2020):

I am looking into potential solutions and will try to come back with an implementation without sacrificing the performance gains achieved under #4639.

@Joezeppe commented on GitHub (Sep 26, 2020): I am looking into potential solutions and will try to come back with an implementation without sacrificing the performance gains achieved under #4639.

adam commented

@jeremystretch commented on GitHub (Sep 28, 2020):

Assigning to @Joezeppe. Please follow-up with your progress within a few weeks.

@jeremystretch commented on GitHub (Sep 28, 2020): Assigning to @Joezeppe. Please follow-up with your progress within a few weeks.

adam commented

@jeremystretch commented on GitHub (Oct 30, 2020):

@Joezeppe have you been able to make any progress with this?

@jeremystretch commented on GitHub (Oct 30, 2020): @Joezeppe have you been able to make any progress with this?

adam commented

@vladsol commented on GitHub (Oct 30, 2020):

upvote!

Navigation with 600+ prefixes is not very confortable :)

@vladsol commented on GitHub (Oct 30, 2020): upvote! Navigation with 600+ prefixes is not very confortable :)

adam commented

@jeremystretch commented on GitHub (Oct 30, 2020):

I honestly don't understand the problems some people complain about with the current implementation. I have around 15K prefixes loaded into a development instance and I much prefer the current approach to the old, slow rendering.

@jeremystretch commented on GitHub (Oct 30, 2020): I honestly don't understand the problems some people complain about with the current implementation. I have around 15K prefixes loaded into a development instance and I much prefer the current approach to the old, slow rendering.

adam commented

@vladsol commented on GitHub (Oct 30, 2020):

I honestly don't understand the problems some people complain about with the current implementation. I have around 15K prefixes loaded into a development instance and I much prefer the current approach to the old, slow rendering.

You scroll through all of the 100 ... pages to find the prefix you want? :) You have a lot of free time :)

@vladsol commented on GitHub (Oct 30, 2020): > I honestly don't understand the problems some people complain about with the current implementation. I have around 15K prefixes loaded into a development instance and I much prefer the current approach to the old, slow rendering. You scroll through all of the 100 ... pages to find the prefix you want? :) You have a lot of free time :)

adam commented

@jeremystretch commented on GitHub (Oct 30, 2020):

No, I filter for it. For example, if I want to see all prefixes within 10.16.128.0/17 (whether or not that has been created as a prefix in NetBox), I type "10.16.128/17" into the "search within" box, and get only those prefixes. From there, I can use the "max length" selector to omit lower tiers if desired. This makes it very convenient to carve out a specific view with both upper and lower bounds, and was not possible prior to v2.9.

@jeremystretch commented on GitHub (Oct 30, 2020): No, I filter for it. For example, if I want to see all prefixes within `10.16.128.0/17` (whether or not that has been created as a prefix in NetBox), I type "10.16.128/17" into the "search within" box, and get only those prefixes. From there, I can use the "max length" selector to omit lower tiers if desired. This makes it very convenient to carve out a specific view with both upper and lower bounds, and was not possible prior to v2.9.

adam commented

@itdependsnetworks commented on GitHub (Oct 30, 2020):

I am thinking about potential solutions that can keep the performant updates and all of the prior functionality.

@itdependsnetworks commented on GitHub (Oct 30, 2020): I am thinking about potential solutions that can keep the performant updates and all of the prior functionality.

adam commented

@igloo777 commented on GitHub (Nov 20, 2020):

Hello!
How about the way it was implemented in Racktables? There we can click on aggregated prefix to "open" it's content (subnets). It allows to reduce a scope of search (as it implemented with "search within"), and adds simplicity in some cases (for some people it's much simple to do 3-4 clicks than type a prefix; personally I would like to have the both possibilities).

@igloo777 commented on GitHub (Nov 20, 2020): Hello! How about the way it was implemented in Racktables? There we can click on aggregated prefix to "open" it's content (subnets). It allows to reduce a scope of search (as it implemented with "search within"), and adds simplicity in some cases (for some people it's much simple to do 3-4 clicks than type a prefix; personally I would like to have the both possibilities).

adam commented

@jeremystretch commented on GitHub (Nov 25, 2020):

Removing @Joezeppe as it's been two months with no updates. If no one else volunteers after some time it will be closed automatically.

@jeremystretch commented on GitHub (Nov 25, 2020): Removing @Joezeppe as it's been two months with no updates. If no one else volunteers after some time it will be closed automatically.

adam commented

@martinkiska commented on GitHub (Nov 30, 2020):

Hello, I think that this update also came up with confused display of available networks in child prefixes. When I search parent prefix I see only available subnets in that parent prefix but when this update came I started to seeing also subnets in child prefixes (it would be great if we could collapse them, as most of the time you just want to see their supernets), which make situation for zero trust concepts and small subnets very confusing. Especially when only allocated child prefixes are shown, but not available one. Please check attached picture. On left I have opened parent prefix 10.64.0.0/16 and free subnets in that prefix are displayed (note number 1). Confusing part you can see on note number 2. Even in parent prefix you display 2 used subnets, you don't show any other available subnets. From the first look 10.64.0.0/24 is full, even it is not - you just need to open that prefix in new page.

@martinkiska commented on GitHub (Nov 30, 2020): Hello, I think that this update also came up with confused display of available networks in child prefixes. When I search parent prefix I see only available subnets in that parent prefix but when this update came I started to seeing also subnets in child prefixes (it would be great if we could collapse them, as most of the time you just want to see their supernets), which make situation for zero trust concepts and small subnets very confusing. Especially when only allocated child prefixes are shown, but not available one. Please check attached picture. On left I have opened parent prefix 10.64.0.0/16 and free subnets in that prefix are displayed (note number 1). Confusing part you can see on note number 2. Even in parent prefix you display 2 used subnets, you don't show any other available subnets. From the first look 10.64.0.0/24 is full, even it is not - you just need to open that prefix in new page. ![image](https://user-images.githubusercontent.com/75117548/100579337-54b4cf00-32e4-11eb-9086-e662977d2914.png)

adam commented

@jeremystretch commented on GitHub (Nov 30, 2020):

@martinkiska Please open a separate bug report for this as it is not related to the feature request.

@jeremystretch commented on GitHub (Nov 30, 2020): @martinkiska Please open a separate bug report for this as it is not related to the feature request.

adam commented

@martinkiska commented on GitHub (Nov 30, 2020):

@jeremystretch thx, I will create it... I thought that it is related. Because if netbox would be able to collapse those sub prefixes of 10.64.0.0/24, we wouldn't see them and it would also resolve the issue.

@martinkiska commented on GitHub (Nov 30, 2020): @jeremystretch thx, I will create it... I thought that it is related. Because if netbox would be able to collapse those sub prefixes of 10.64.0.0/24, we wouldn't see them and it would also resolve the issue.

adam commented

@marbarmar commented on GitHub (Dec 1, 2020):

@jeremystretch the comment from @martinkiska is relevant. It is what I wrote in the use case:
Also opening Prefixes in collapsed form is more lucid and we do see the hierarchy of most parent subnets.

@marbarmar commented on GitHub (Dec 1, 2020): @jeremystretch the comment from @martinkiska is relevant. It is what I wrote in the use case: Also opening Prefixes in collapsed form is more lucid and we do see the hierarchy of most parent subnets.

adam commented

@jeremystretch commented on GitHub (Dec 1, 2020):

@marbarmar The display of available prefixes is a separate concern not directly related to collapsing/expanding the hierarchy of existing prefixes. It is being tracked in #5397.

@jeremystretch commented on GitHub (Dec 1, 2020): @marbarmar The display of available prefixes is a separate concern not directly related to collapsing/expanding the hierarchy of existing prefixes. It is being tracked in #5397.

adam commented

@baguilar951 commented on GitHub (Dec 18, 2020):

Hello everyone,

We recently implemented Netbox for production use and I have been maintaining it as a tool for multiple teams in my organization. We upgraded from 2.8.6 to 2.9.9 and we are receiving reports from our Infrastructure teams that the ability to collapse and expand the prefixes is an easier and visual way to audit and organize the subnets within the IPAM. Although I am not a coder myself, I would like to provide testing for bringing this functionality back.

Although the prefixes can be limited to a block size and filtered thereafter, it is proving to be a vital way to visualize the hierarchy of our networks as it is for most of the people who use Netbox (our teams pretty much live in it now). The child prefix view is also problematic in it's current state because of how we carve our VPC networks in different regions across multiple cloud providers, much like @marbarmar describes with /16 supernets, /23 subnets and /28 VPCs.

What version was this changed in? If there is a way to revert to a build where the IPAM had the accordions, I would appreciate some pointers.

Thank you @jeremystretch for such an amazing project and we will continue to use this tool and support however we can.

@baguilar951 commented on GitHub (Dec 18, 2020): Hello everyone, We recently implemented Netbox for production use and I have been maintaining it as a tool for multiple teams in my organization. We upgraded from 2.8.6 to 2.9.9 and we are receiving reports from our Infrastructure teams that the ability to collapse and expand the prefixes is an easier and visual way to audit and organize the subnets within the IPAM. Although I am not a coder myself, I would like to provide testing for bringing this functionality back. Although the prefixes can be limited to a block size and filtered thereafter, it is proving to be a vital way to visualize the hierarchy of our networks as it is for most of the people who use Netbox (our teams pretty much live in it now). The child prefix view is also problematic in it's current state because of how we carve our VPC networks in different regions across multiple cloud providers, much like @marbarmar describes with /16 supernets, /23 subnets and /28 VPCs. What version was this changed in? If there is a way to revert to a build where the IPAM had the accordions, I would appreciate some pointers. Thank you @jeremystretch for such an amazing project and we will continue to use this tool and support however we can.

adam commented

@jeremystretch commented on GitHub (Dec 18, 2020):

Although the prefixes can be limited to a block size and filtered thereafter, it is proving to be a vital way to visualize the hierarchy of our networks as it is for most of the people who use Netbox (our teams pretty much live in it now). The child prefix view is also problematic in it's current state because of how we carve our VPC networks in different regions across multiple cloud providers, much like @marbarmar describes with /16 supernets, /23 subnets and /28 VPCs.

Several people in the thread have made similar vague complaints, but I have yet to see anyone prescribe a specific sets of steps to reproduce a problem. The old prefix hierarchy provided only two options: show only the top-level prefixes, or show all of them. The new approach lets you filter out prefixes beyond an arbitrary length, while preserving the ability to filter by summary to carve out whatever specific view you'd like to see. This is clearly a far more flexible approach, so I'm confused as to where people are getting hung up. I suspect it may simply be a matter of educating users about the tools available to them.

@baguilar951 perhaps you can share an example of specifically where you're running into a limitation. Please be sure to detail what prefixes you've created, and what you want to see in the list.

@jeremystretch commented on GitHub (Dec 18, 2020): > Although the prefixes can be limited to a block size and filtered thereafter, it is proving to be a vital way to visualize the hierarchy of our networks as it is for most of the people who use Netbox (our teams pretty much live in it now). The child prefix view is also problematic in it's current state because of how we carve our VPC networks in different regions across multiple cloud providers, much like @marbarmar describes with /16 supernets, /23 subnets and /28 VPCs. Several people in the thread have made similar vague complaints, but I have yet to see anyone prescribe a _specific sets of steps_ to reproduce a problem. The old prefix hierarchy provided only two options: show only the top-level prefixes, or show all of them. The new approach lets you filter out prefixes beyond an arbitrary length, while preserving the ability to filter by summary to carve out whatever specific view you'd like to see. This is clearly a far more flexible approach, so I'm confused as to where people are getting hung up. I suspect it may simply be a matter of educating users about the tools available to them. @baguilar951 perhaps you can share an example of specifically where you're running into a limitation. Please be sure to detail what prefixes you've created, and what you want to see in the list.

adam commented

@baguilar951 commented on GitHub (Dec 18, 2020):

Hi @jeremystretch,

In the previous version, the collpased view:

In our current version, we have a completely expanaded view of the subnets in a supernet:

I understand this may seem trivial and I would agree, being able to filter to the max CIDR length is a much logical implementation to view the hierarchy, the issue is readability. In our case some of those /22 subnets we don't need to see unless we absolutely need to drill down into them.

We would like to easily view /16s and /17s that are assigned to regions as well as determine the next available subnet without having to dig through page after page of noise. The expectation is that the default view be the top-most level of the prefixes in our environment. A choice to do either a top-level collapse and/or a CIDR length filter might be the best of both worlds for those who prefer it to be that way. I would try to come up with a solution myself but my python knowledge is limited.

@baguilar951 commented on GitHub (Dec 18, 2020): Hi @jeremystretch, In the previous version, the collpased view: ![image](https://user-images.githubusercontent.com/76227134/102665537-da84a700-4139-11eb-96f6-e3bdad6091c5.png) In our current version, we have a completely expanaded view of the subnets in a supernet: ![image](https://user-images.githubusercontent.com/76227134/102665607-fb4cfc80-4139-11eb-882e-f0ba8bfc7c4b.png) I understand this may seem trivial and I would agree, being able to filter to the max CIDR length is a much logical implementation to view the hierarchy, the issue is readability. In our case some of those /22 subnets we don't need to see unless we absolutely need to drill down into them. We would like to easily view /16s and /17s that are assigned to regions as well as determine the next available subnet without having to dig through page after page of noise. The expectation is that the default view be the top-most level of the prefixes in our environment. A choice to do either a top-level collapse and/or a CIDR length filter might be the best of both worlds for those who prefer it to be that way. I would try to come up with a solution myself but my python knowledge is limited.

adam commented

@jeremystretch commented on GitHub (Dec 18, 2020):

In the previous version, the collpased view is

You can easily replicate this exact view by applying the "max length" filter:

Selecting "16" will show only prefixes up to /16 in length, resulting in a view identical to your first screenshot.

@jeremystretch commented on GitHub (Dec 18, 2020): > In the previous version, the collpased view is You can easily replicate this exact view by applying the "max length" filter: ![Screenshot from 2020-12-18 15-55-05](https://user-images.githubusercontent.com/13487278/102660707-7c5fc000-4149-11eb-9441-94dd4b0fdd88.png) Selecting "16" will show only prefixes up to /16 in length, resulting in a view identical to your first screenshot.

adam commented

@baguilar951 commented on GitHub (Dec 18, 2020):

Hi @jeremystretch,

My apologies, the screenshots are updated for the child prefix view. But the top-level collapse is the feature that is also being requested in the IPAM.

@baguilar951 commented on GitHub (Dec 18, 2020): Hi @jeremystretch, My apologies, the screenshots are updated for the child prefix view. But the top-level collapse is the feature that is also being requested in the IPAM.

adam commented

@jeremystretch commented on GitHub (Dec 18, 2020):

Please restore your original screenshot so that future readers may still have some hope of following the discussion, and make a new comment below with the correction.

@jeremystretch commented on GitHub (Dec 18, 2020): Please restore your original screenshot so that future readers may still have some hope of following the discussion, and make a _new_ comment below with the correction.

adam commented

@baguilar951 commented on GitHub (Dec 18, 2020):

Apologies @jeremystretch,

In the old version, the child prefix view (Note how the rest of the available /17 get rolled up into a /15):

In the new build:

@baguilar951 commented on GitHub (Dec 18, 2020): Apologies @jeremystretch, In the old version, the child prefix view (Note how the rest of the available /17 get rolled up into a /15): ![102661223-46164680-4131-11eb-8db5-ce7a5b451587](https://user-images.githubusercontent.com/76227134/102665724-2b949b00-413a-11eb-96ae-d5db97481a9f.png) In the new build: ![102661326-7231c780-4131-11eb-9171-deecf3720e03](https://user-images.githubusercontent.com/76227134/102665653-0d2e9f80-413a-11eb-91f2-a116e04c4dcc.png)

adam commented

@christheradioguy commented on GitHub (Dec 29, 2020):

Just wanted to chime in here with my use case for the old system.

In my situation, I have several parent prefixes (a /29, a /32, a /48 and others) and then a number of suballocations for customers below those parents. When I go into Netbox and look for my /48 parent prefix, I have to scroll through a huge number of customer /48's to find it. The 'Max Length' dropdown doesn't help me in my case because all the suballocted networks I don't want to see are also /48's so they show up regardless.

@christheradioguy commented on GitHub (Dec 29, 2020): Just wanted to chime in here with my use case for the old system. In my situation, I have several parent prefixes (a /29, a /32, a /48 and others) and then a number of suballocations for customers below those parents. When I go into Netbox and look for my /48 parent prefix, I have to scroll through a huge number of customer /48's to find it. The 'Max Length' dropdown doesn't help me in my case because all the suballocted networks I don't want to see are also /48's so they show up regardless.

adam commented

@stale[bot] commented on GitHub (Feb 13, 2021):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@stale[bot] commented on GitHub (Feb 13, 2021): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented