Missing child prefixes on the prefix page

[Zanthras]

Issue type: bug report

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

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.

[th3goose]

@Zanthras what version of postgresql are you using?

[jeremystretch]

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.

[Zanthras]

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)

[jeremystretch]

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

[Zanthras]

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.

[ktims]

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 😄 .

[martink2]

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

[jeremystretch]

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

[martink2]

@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

[ktims]

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?

[bashioo]

Hi,
by fixing this previous fix #395 has been broken. Last year it was agreed to show children from all VRFs if parent is in Global VRF. Some bits from that change are still there though, you can still see parent prefix from Global VRF regardless of child's VRF.

I would really like to have that behaviour back if possible, please.