Add support for administrating prefix with /0 mask

[sdktr]

NetBox version

2.11.9

Feature type

Change to existing functionality

Proposed functionality

A (default) prefix (v4/v6 prefix with /0 mask) should be allowed. Since IPAM planning is getting expanded to attach to other entities like Regions/Locations this seems like a logical step to model the hierarcy of the DCIM in the IPAM plan up to the ultimate 'mother-of-all-prefixes'.

Use case

We use this to track how an IPVPN is modelled from an IPAM perspective. The branches in the IPVPN get their own RFC1918 assignment on the Site level, but HQ Site has the default path towards all RFC1918 + Internet destinations. We model the default prefix to attach to this headquarters.

In #3864 a couple of speed enhancements in calculating free space were discussed [1]. Besides limiting the amount of calculated IPs/prefixes PR, a seperate validation to prohibit /0 masks on IPs was raised here. The commit that followed disallows /0 masks for prefixes as well. I think this wasn't intended and should be reverted. Disallowing /0 on IPs only, but allowing on prefixes.

[1] Not sure the performance issues in this area are still applicable since #6087

Database changes

N/A

External dependencies

N/A

[jeremystretch]

I don't follow your use case here. The prefix 0.0.0.0/0 simply means "the entire IPv4 address space;" I don't see any benefit in tracking this as an explicit object. It sounds like you're trying to use it to model a routing topology rather than address space.

[sdktr]

It's true that the 0/0 is not assigned to a specific L3 interface as a directly attached prefix. The same is true though for a lot of other Container prefixes that are part of the overal addressing plan. Prefixes assigned to partners, summaries assigned to Sites etc.

We've been using Netbox as a S-o-T for all prefixes (statically assigned or routed elsewhere) in every corner of each VRF so people have a nice complete overview of everything in one place.

The external tools that do anything with network automation are not allowed to come up with their own subnets. The SoT is the law and any prefix should reference a netbox ID to keep things organized.

Full disclosure: we didn't have to add/change any of the 0.0/0 prefixes since running pre 2.6.12 (introduced the restriction). This was until more recent then I'd like to admit..

[jeremystretch]

I still don't get it. In what scenario would you need to look up some attribute of an object representing 0.0.0.0/0, versus just implicitly applying that attribute to any IPv4 prefix or address?

[sdktr]

In the external systems that rely on netbox as their SoT we do not store the prefixes/IPs, but rather the Netbox IDs or search query of them. Could be a litteral prefix-filter from the API, can be a single ID, you name it.

Upon rendering a config template these are unpacked. When the SoT states that a certain prefix or IP is no longer active (deleted or state changed to Deprecated) the template simply follows. It ('s designer) should not come up with it's own IPA M based on some point-in-time view of the network. We treath the default the same as we do all the other Container prefixes in that regard.

For example to configure which routes could/should point where (eg: route filters or static routes within the WAN core), we lookup the summarised prefix that is attached to a Site. Most sites have a (1) Container prefix from which their internal schema is derived. The main site or Datacenter Site usually has the VRF-specific 0.0/0 attached so we can configure the route filters that point to these sites accordingly. If Netbox would not allow (new) default prefixes to be created we would have to come up with some kind of custom field or external place to store this info. This is something I'd like to avoid, because then we need to overlay the nice IPAM tree of netbox with some additional data to show the true addressing schema.

Hope that makes sense, thanks for sticking around

[DanSheps]

I am just as lost as @jeremystretch.

What exactly are you trying to do with 0/0? Are you using it in route filters? Are you using it to point default routes?

[sdktr]

Yes, among other things, route filters are generated using netbox prefix IDs. Upon rendering the config for our equipment these IDs are translated into the real prefix.

Other applications are data plane filters (acls) for incoming circuits from customer sites to our network. In an external authorization database the network admin configures for example:
'This customer circuit must not have access to prefixIds [1,2] but has access to [3,99]'. When unpacking the config for this circuit this might translate to:
deny ip any 10.0.0.0/24 (id: 1)
deny ip any 10.1.3.0/24 (id: 2)
permit ip any 10.0.0.0/8 (id: 3)
permit ip any 0.0.0.0/0 (id: 99).

This external system where config definitions are put together doesn't have it's own IPAM. It relies on netbox 100%. Using rbac you're allowed to configure your own part of the IPAM backend (eg: within your own VRF you can do anything).

Does this clarify things?

[github-actions]

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.

[kevintedder]

@jeremystretch I'm with @sdktr on this. Since Netbox is to be the SoT for the network topology then all configured static routes should also be captured here. A default route of 0/0 would be set at the edge of a VRF, on an ASBR, and advertised by the internal IGP. If there was another static route, say 15.1/16 to a 3rd party, this too could be set on a different ASBR. Netbox now knows the network topology to other regions outside of its control as there are two exit points out of the VRF. It is simple to determine the VRF router through which these outside regions are access.
When investigating a routing issue we just need to check if the static route and NHG is correctly set on the router according to Netbox's "Source of Truth."
Being able to add static routes to the VRF would be useful.

[DanSheps]

I think in this instance, it is better to come up with a plugin or some other datastore (configuration context perhaps) rather then relying on the prefix to be in the prefix model.

Prefixes themselves don't convey enough information to be capable of establishing a proper static route.

[kevintedder]

@DanSheps agreed. But if a prefix to the outside was defined, then in the VRF you just to attach the device and next hop IP address. There would be enough info to define a static route. We just need a mechanism to do this.

What would it take to write a plugin? It sounds complex.

[DanSheps]

Where do you get the next hop address from?

[kevintedder]

@DanSheps If 2 VRFs were configured, each would have a router device defined to be the associated ASBR. By cabling them together, and assigning a prefix to them, each would know what the Next Hop would be to the other.
If the 2nd VRF where a dummy to represent the Internet then configuring a default prefix (0/0) in it would tell the other VRF where it was, and how to get there.

[sdktr]

I think in this instance, it is better to come up with a plugin or some other datastore (configuration context perhaps) rather then relying on the prefix to be in the prefix model.

Prefixes themselves don't convey enough information to be capable of establishing a proper static route.

In an hypothical Route Plugin (to store static routes) I would assume this to reuse the already defined prefixes from the prefix modal and only store the additional info (like next-hop) in the plugin. Having the same prefix defined in two places doesn't feel very S-o-T-ish.

RouteObject:
prefix: {{ netbox.ipam.prefix }}
next-hop: {{ netbox.ipam.ipaddress }}
distance: int
description: string

We have the exact same reasoning with our external routing/ACL-store. It should not define it's own S-o-T for objects that are already defined within The IPAM (tm). Including supernets (Container prefixes) and the ultimate supernet (0.0/0).

[DanSheps]

I think that depends on the approach you take to Prefixes themselves. Do you only store your own prefixes in there? Depending on that would determine the direction.

Probably a better option would be something like this:

Models:

• Route
• RouteFilter
• RouteFilterEntry
• StaticRoute

Then have the plugin focus on static routes as well as route filters (this could cover both use cases I heard mentioned)

[jeremystretch]

Since Netbox is to be the SoT for the network topology

NetBox is intended to serve as a source of truth for network infrastructure, not routing policy. This is a very significant distinction.

The conversation here seems to have wandered a bit from the original FR, which is simply to allow /0 masks for prefixes.

Here's what I think this boils down to: You want to store some information about a default route, so your instinct is to create a 0.0.0.0/0 prefix in NetBox. However, there's no need to do this, because realistically you can only ever define one default route (per VRF). Thus, there's no reason to ever create a prefix to represent a default route: You can just associate any relevant information directly with the VRF (hence my initial comment).

Ultimately, I think the root issue is that you're trying to convey routing policy in a tool that's not designed for it. As Dan mentioned, you're probably better offer developing a custom plugin to suit your needs.

[jeremystretch]

Closing this out as the original FR is untenable and there's been no further discussion.