Prefixes are displayed under containers in different VRFs

[LukeDRussell]

Prefixes aren't displayed under the correct container when they are in difference VRFs

For example, there is a container prefix in VRF A of 192.168.0.0/16. If we expand the prefixes we can see 192.168.128.0/17 in VRF B underneath the VRF A container.

[jeremystretch]

This is intentional. VRFs represent unique IP spaces.

[LukeDRussell]

I'm not really following...

Why would I want to see a prefix in the global table listed under a container in a different VRF?

If I look at prefix's page it is listed under the correct container (see http://netbox-demo01.packetlife.net/ipam/prefixes/27/)

However if I look at the all prefix page with subnets expanded (see http://netbox-demo01.packetlife.net/ipam/prefixes/?parent=&expand=on) our prefix is listed under a different container.

---

From: Jeremy Stretch notifications@github.com
Sent: Sunday, 4 September 2016 12:38 AM
To: digitalocean/netbox
Cc: lukerussell; Author
Subject: Re: [digitalocean/netbox] Prefixes are displayed under containers in different VRFs (#531)

This is intentional. VRFs represent unique IP spaces.

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/531#issuecomment-244550043, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGbGab4SLcJaruHu9Gl3Id6Ox68yoP9hks5qmYZwgaJpZM4J0ScJ.

[jeremystretch]

For a prefix in the global table, NetBox will show child prefixes from all VRFs (see #395). However, a prefix which has been assigned to a VRF will list children only within its own VRF. Hopefully that makes sense. Apologies if I'm misunderstanding your question.

[LukeDRussell]

Thanks for re-opening. Having a read of #395 has given me some good context.

However, a prefix which has been assigned to a VRF will list children only within its own VRF.

It's not working like that right now. 1.5.2 will show global prefixes under a container in a VRF, if there is no container in global. Even adding a container in global later will still show the global prefix under the VRF container. Deleting the VRF container will then put the global prefix under the global container.

[jeremystretch]

I've tried replicating this but it doesn't happen when viewing a specific prefix. Could you post a screenshot of where you're seeing this?

[LukeDRussell]

To clarify, it doesn't happen when viewing specific prefix, it happens when viewing all prefixes. Note 10.0.0.0/9 Global is listed under 10.0.0.0/8 cust_evil01.

[jeremystretch]

Having pondered this further, I think it makes sense to keep the list exactly as it is. When you're viewing the prefix hierarchy, you presumably want to include everything, so it makes sense to include all prefixes from all tables. If you only want to see a specific VRF or tenant, you can utilize the filters to do so.

[LukeDRussell]

I agree that I do want to see everything from all VRFs (including global) with no filters applied.

However, I do not agree that the case illustrated in the screenshot is inline with the "replicate the real world" philosophy. Prefix Global:10.0.0.0/8 literally does contain Global:10.0.0.0/9. cust_evil01:10.0.0.0/8 does not.

What happens when Global:10.0.0.0/8 doesn't exist though? #395 covered this to an extent. My opinion is that Global:10.0.0.0/9 should be shown as a parent/root item, seperate to cust_evil01:10.0.0.0/8. Otherwise what determines a prefixes' parent if it doesn't have a larger container within the same VRF? Global:10.0.0.0/9 could end up listed under any arbitrary VRF (I am guessing this is tied to the order the VRFs were created).

Tangent: I can't find an issue already for this. Can I raise an issue to add "Global" to the list of VRFs in the filter list? It would apply /ipam/prefixes/?parent=&vrf=0

[jeremystretch]

Sorry, when I went to replicate this I didn't realize you had two 10/8s, one in the global table and one in a VRF. I get it now. Will have to do some thinking on how to resolve this.

Can I raise an issue to add "Global" to the list of VRFs in the filter list? It would apply /ipam/prefixes/?parent=&vrf=0

Yes please. I've been meaning to overhaul the method in which filters are generated anyway.

[jeremystretch]

I think the most practical way to fix this is to order prefixes first by VRF, and then by address. Does that make sense? Trying to maintain parallel hierarchies for multiple tables would be very difficult and probably introduce significant performance degradation.

[LukeDRussell]

Could we order by Tenant, then VRF, then prefix? I think it might help visualising address space with #259. But that may be getting out of scope for a single issue.

Order by VRF, then by address sounds good.

I'm not sure I follow with your second sentence though, my Python is absolute beginner.

[jeremystretch]

What I mean is it would be very difficult to do this:

• 10.0.0.0/8 (global)
  • 10.1.0.0/16 (global)
• 10.0.0.0/8 (VRF A)
  • 10.1.0.0/16 (VRF A)
• 192.168.0.0/16 (global)
• 192.168.0.0/16 (VRF A)

This is because 10.1.0.0/16 will be ordered after all 10.0.0.0/8 networks in the hierarchy. However, I believe an acceptable alternative is to simply arrange the hierarchy by VRF, which is much more efficient:

• 10.0.0.0/8 (global)
  • 10.1.0.0/16 (global)
• 192.168.0.0/16 (global)
• 10.0.0.0/8 (VRF A)
  • 10.1.0.0/16 (VRF A)
• 192.168.0.0/16 (VRF A)