Missing child prefixes on the prefix page #752

Originally created by @Zanthras on GitHub (Mar 6, 2017).

Issue type: bug report

Python version: Python 3.5.2
NetBox version: branch api2 commit 90fe556e5f

django versions:
Django (1.10.6)
django-auth-ldap (1.2.9)
django-debug-toolbar (1.6)
django-filter (0.15.3)
django-mptt (0.8.7)
django-rest-swagger (0.3.10)
django-tables2 (1.4.1)
djangorestframework (3.5.4)

Created 3 prefixes null site/vrf everything.
10.0.0.0/23
10.0.0.0/24
10.0.1.0/24

When selecting 10.0.0.0/23 i would expect to see 2 child prefixes. However I dont see any on this netbox version, on a much older install I do see it. Checking the git history nothing has really changed in the code pathway recently so possibly it was a django behavioral change.

After tracing through the code I believe the problem to be in add_available_prefixes.

After reading all the rows of the prefix_list to find the available space the original django filter prefix_list is now empty. Thus the attempt to add all the original rows with the new available_prefixes results in just delivering the available_prefixes.

Originally created by @Zanthras on GitHub (Mar 6, 2017).  ### Issue type: bug report  **Python version: Python 3.5.2** **NetBox version: branch api2 commit 90fe556e5fd5fbb1149fc58cca78a80022b68761** django versions: Django (1.10.6) django-auth-ldap (1.2.9) django-debug-toolbar (1.6) django-filter (0.15.3) django-mptt (0.8.7) django-rest-swagger (0.3.10) django-tables2 (1.4.1) djangorestframework (3.5.4)  Created 3 prefixes null site/vrf everything. 10.0.0.0/23 10.0.0.0/24 10.0.1.0/24 When selecting 10.0.0.0/23 i would expect to see 2 child prefixes. However I dont see any on this netbox version, on a much older install I do see it. Checking the git history nothing has really changed in the code pathway recently so possibly it was a django behavioral change. After tracing through the code I believe the problem to be in add_available_prefixes. After reading all the rows of the prefix_list to find the available space the original django filter prefix_list is now empty. Thus the attempt to add all the original rows with the new available_prefixes results in just delivering the available_prefixes.

adam added the type: bug label 2025-12-29 16:25:28 +01:00

adam closed this issue

adam commented

@th3goose commented on GitHub (Mar 7, 2017):

@Zanthras what version of postgresql are you using?

@th3goose commented on GitHub (Mar 7, 2017): @Zanthras what version of postgresql are you using?

adam commented

@jeremystretch commented on GitHub (Mar 7, 2017):

I'm not able to replicate this on either the develop or the api2 branch. After creating the three prefixes listed, I see both child /24s listed beneath the /23.

@jeremystretch commented on GitHub (Mar 7, 2017): I'm not able to replicate this on either the `develop` or the `api2` branch. After creating the three prefixes listed, I see both child /24s listed beneath the /23.

adam commented

@Zanthras commented on GitHub (Mar 7, 2017):

Old version was running on a postgres 9.2.15 db, new version is a 9.6.2 install. Im going to spin up some test vm's real quick to check some combinations, see if i can isolate it down. (And hopefully replicate on a fresh vm)

@Zanthras commented on GitHub (Mar 7, 2017): Old version was running on a postgres 9.2.15 db, new version is a 9.6.2 install. Im going to spin up some test vm's real quick to check some combinations, see if i can isolate it down. (And hopefully replicate on a fresh vm)

adam commented

@jeremystretch commented on GitHub (Mar 7, 2017):

@Zanthras Much appreciated. Interested to hear what you find out.

@jeremystretch commented on GitHub (Mar 7, 2017): @Zanthras Much appreciated. Interested to hear what you find out.

adam commented

@Zanthras commented on GitHub (Mar 7, 2017):

Well that was easy, its just a python3 vs a python2 difference.

Fresh postgres install of 9.6.2 with both python2.7 and 3.5 installed and all pip requirement installed to both I can replicate both working and missing with the manage.py debug server.

Im assuming the functionality of the django filter was changed to be a generator when running under py3.

@Zanthras commented on GitHub (Mar 7, 2017): Well that was easy, its just a python3 vs a python2 difference. Fresh postgres install of 9.6.2 with both python2.7 and 3.5 installed and all pip requirement installed to both I can replicate both working and missing with the manage.py debug server. Im assuming the functionality of the django filter was changed to be a generator when running under py3.

adam commented

@ktims commented on GitHub (Mar 7, 2017):

Confirming the same behaviour on Python3, only available prefixes are shown. I actually thought it was intentional and was about to file an enhancement request 😄 .

@ktims commented on GitHub (Mar 7, 2017): Confirming the same behaviour on Python3, only available prefixes are shown. I actually thought it was intentional and was about to file an enhancement request 😄 .

adam commented

d89314a559/netbox/ipam/views.py (L423)

@martink2 commented on GitHub (Mar 13, 2017):

Hi,
unfortunately since the update to v1.9.1 i have the following:

10.46.7.0/24, VRF=Global
10.46.7.0/25, VRF=VRF-a
10.46.7.128/25, VRF=VRF-b

before the update the two /25 were listed as child prefixes
now they are not anymore. Only way to get them back is
to mark them both as global.

Shouldn't the vrf=prefix.vrf be made conditional depending
on the prefix being global or not ?

child_prefixes = Prefix.objects.filter(vrf=prefix.vrf, prefix__net_contained=str(prefix.prefix))

Thanks

Martin

@martink2 commented on GitHub (Mar 13, 2017): Hi, unfortunately since the update to v1.9.1 i have the following: 10.46.7.0/24, VRF=Global 10.46.7.0/25, VRF=VRF-a 10.46.7.128/25, VRF=VRF-b before the update the two /25 were listed as child prefixes now they are not anymore. Only way to get them back is to mark them both as global. Shouldn't the vrf=prefix.vrf be made conditional depending on the prefix being global or not ? `child_prefixes = Prefix.objects.filter(vrf=prefix.vrf, prefix__net_contained=str(prefix.prefix))` https://github.com/digitalocean/netbox/blob/d89314a559a887484e2fd8e5985bb1b2cdf8777f/netbox/ipam/views.py#L423 Thanks Martin

adam commented

@jeremystretch commented on GitHub (Mar 13, 2017):

@martink2 This is intended behavior. The global table and the two VRFs you've defined are all separate address spaces.

@jeremystretch commented on GitHub (Mar 13, 2017): @martink2 This is intended behavior. The global table and the two VRFs you've defined are all separate address spaces.

adam commented

@martink2 commented on GitHub (Mar 13, 2017):

@jeremystretch thanks for the clarification. We always understood the global table to be a globally unique address space and not as the routers "default vrf". We have a lot of /24 defined as global with type container which we use to group prefixes we want to sub-allocate for Router-ID's or Transit Networks between devices. So we have a large number of /31 neatly hidden in the hierarchy
under the container. Each /31 of cause belonging to the respective vrf. Since the upgrade we now have an exploded list of prefixes cluttered with hundreds of /31's.

I hope we are not totally misusing Netbox here but we would like to group our Transits back together somehow.

So may i make the case to maybe exclude Containers in Global from the restriction that all sub-prefixes need to belong to the same VRF or allow a prefix of type container without a vrf set at all?

Thanks for the quick response

Martin

@martink2 commented on GitHub (Mar 13, 2017): @jeremystretch thanks for the clarification. We always understood the global table to be a globally unique address space and not as the routers "default vrf". We have a lot of /24 defined as global with type container which we use to group prefixes we want to sub-allocate for Router-ID's or Transit Networks between devices. So we have a large number of /31 neatly hidden in the hierarchy under the container. Each /31 of cause belonging to the respective vrf. Since the upgrade we now have an exploded list of prefixes cluttered with hundreds of /31's. I hope we are not totally misusing Netbox here but we would like to group our Transits back together somehow. So may i make the case to maybe exclude Containers in Global from the restriction that all sub-prefixes need to belong to the same VRF or allow a prefix of type container without a vrf set at all? Thanks for the quick response Martin

adam commented

@ktims commented on GitHub (Apr 5, 2017):

As a corollary to this VRF situation, I've noticed that 'parent' prefixes that are not in the same VRF (at least if they are Global) do appear in the list on the child prefix's page. I guess this is a bug.

I would like to see some way to maintain the parent/child relationship when crossing VRF boundaries. This is more important in IPv6, where it is very common to route across a firewall boundary from the global table to a private VRF. In IPv4 there would normally be NAT there, so address consistency doesn't matter. Or maybe I am missing a way to do this with the current implementation?

@ktims commented on GitHub (Apr 5, 2017): As a corollary to this VRF situation, I've noticed that 'parent' prefixes that are *not* in the same VRF (at least if they are Global) do appear in the list on the child prefix's page. I guess this is a bug. I would like to see some way to maintain the parent/child relationship when crossing VRF boundaries. This is more important in IPv6, where it is very common to route across a firewall boundary from the global table to a private VRF. In IPv4 there would normally be NAT there, so address consistency doesn't matter. Or maybe I am missing a way to do this with the current implementation?

adam commented