Add support for administrating prefix with /0 mask #5108

@sdktr commented on GitHub (Jul 29, 2021):

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

@sdktr commented on GitHub (Jul 29, 2021): 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..

adam commented

@jeremystretch commented on GitHub (Aug 4, 2021):

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?

@jeremystretch commented on GitHub (Aug 4, 2021): 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?

adam commented

@sdktr commented on GitHub (Aug 4, 2021):

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

@sdktr commented on GitHub (Aug 4, 2021): 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

adam commented

@DanSheps commented on GitHub (Aug 12, 2021):

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?

@DanSheps commented on GitHub (Aug 12, 2021): 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?

adam commented

@sdktr commented on GitHub (Aug 12, 2021):

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?

@sdktr commented on GitHub (Aug 12, 2021): 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?

adam commented

@github-actions[bot] commented on GitHub (Oct 12, 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.

@github-actions[bot] commented on GitHub (Oct 12, 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

@kevintedder commented on GitHub (Nov 4, 2021):

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

@kevintedder commented on GitHub (Nov 4, 2021): @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.

adam commented

@DanSheps commented on GitHub (Nov 4, 2021):

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.

@DanSheps commented on GitHub (Nov 4, 2021): 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.

adam commented

@kevintedder commented on GitHub (Nov 4, 2021):

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

@kevintedder commented on GitHub (Nov 4, 2021): @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.

adam commented

@DanSheps commented on GitHub (Nov 4, 2021):

Where do you get the next hop address from?

@DanSheps commented on GitHub (Nov 4, 2021): Where do you get the next hop address from?

adam commented

@kevintedder commented on GitHub (Nov 5, 2021):

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

@kevintedder commented on GitHub (Nov 5, 2021): @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.

adam commented

@sdktr commented on GitHub (Nov 5, 2021):

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

@sdktr commented on GitHub (Nov 5, 2021): > 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).

adam commented

@DanSheps commented on GitHub (Nov 5, 2021):

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)

@DanSheps commented on GitHub (Nov 5, 2021): 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)

adam commented

@jeremystretch commented on GitHub (Nov 18, 2021):

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 commented on GitHub (Nov 18, 2021): > 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](https://github.com/netbox-community/netbox/issues/6825#issuecomment-889121176)). 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.

adam commented