Add support for IP Routing

[micko]

NetBox version

v3.1.1

Feature type

New functionality

Proposed functionality

Support for IP Routing, i.e. static routing.

Use case

Every device requires routing, servers/end devices require a default route (yes I have a custom field now but it's ugly so maybe make a permanent field).

Network devices (routers/firewalls/switches) have and require routing capabilities to set various static routes.

Database changes

routes table:

• prefix (ipv4 or ipv6 network subnet)
• next hop address (either an ipv4 or ipv6 but check the prefix type before you allow the address family).
• next hop interface (in some cases the next-hop will require to be an interface so tie that option with the available interfaces on the devices.
• distance/preference (this is administrative and pretty much the same just depending on the vendor, i.e. cisco vs juniper)

External dependencies

None.

[jeremystretch]

Support for IP Routing, i.e. static routing.

You're going to need to provide much more detail in your proposal than that I'm afraid.

[micko]

Support for IP Routing, i.e. static routing.

You're going to need to provide much more detail in your proposal than that I'm afraid.

The request is fairly straightforward - every system that is on the internet or any sort of network (even private) requires routing. The ask is to create a table where you can maintain any routing entries (system default route included). My specific use case (network device, i.e. juniper, cisco, arista, etc) also require various (non default) static route entries, i.e.:

cisco example: ip route 100.100.100.0 255.255.255.0 200.200.200.200 100 or example using next-hop as an interface: ip route 100.100.100.0 255.255.255.0 tunnel1 100

The model for this is:

• id (serial)
• device (check device against device table)
• type (optional and check against a separate table [note bellow])
• prefix (cidr) not null
• nexthop ip (inet)
• nexthop interface (check interface against interface table as well as the device id)
• null (this is a special meaning - i.e. send the traffic to /dev/null) (this can been a 'bool')
• description (varchar 64 or 128) null (sometimes there is a need for description)
• created (date)
• updated (timestamp)

constraints:

• family(prefix) == family (nexthop inet)
• check what is set and choose one (nexthop ip OR nexthop interface OR null)
• unique: device, prefix, nexthop (ip, interface, null)

Regarding route types, sometimes there is a need to categorize routes based on their usage - aggregates being one of them but there is also "global", "regional", etc.

[jeremystretch]

I'm afraid that modeling an entire routing topology is out of scope for NetBox. What are you trying to accomplish here?

[micko]

I'm afraid that modeling an entire routing topology is out of scope for NetBox. What are you trying to accomplish here?

It falls inline with RIR, Route Targets, VRFs..

[DanSheps]

For something the scope of routing infrastructure (static routes, etc), you are better to look into custom plugins.

[micko]

The underlying requirement for VRFs, VLANs, Route Targets is routing in order to communicate anywhere outside of their boundary. The request is not to model a routing infrastructure (which in 99% of the cases requires and IGP and MPLS/BGP these days) but to enable simple & basic routing.

Even your headline says "application designed to empower network automation" but you are saying that the most elementary thing in "networking" is out of scope..

[candlerb]

I was thinking about this too.

From my point of view, routes are primarily prefixes. Therefore if you create a prefix, and you add some tags or custom fields to say how and where you want to announce it, that should do the job. I don't think Netbox should prescribe how you do this; things like nexthop IP and nexthop interface are only a custom field away.

The only problem I can see is that you will end up creating additional layers of prefix when announcing summary routes. This in itself isn't a problem, but if you mark them as "Container" it messes up the usage calculation (which isn't really documented, but see #8091)

It would work to mark them as "Active", although this then doesn't distinguish between a prefix which is actually active on some interfaces (i.e. this particular prefix and mask is a broadcast domain) versus this is a prefix which is an summary route announcement. Perhaps that distinction is not too important, although adding another Prefix status of "Summary" would be possible.

Note: what I propose just models routes in your network in general; it could control how routes are injected into your IBGP or announced to peers. However, if you want to say "add this as a static route on this particular device" then that's something else - it becomes be a device-level configuration instruction. Config contexts might be usable here, but otherwise I think you're looking at a plugin, because there's not currently a way to have multiple instances of a custom field on an object.

Alternatively, for some environments, a custom field on interface might do the job (#5401 - this was added in v2.11.0). That is, you would add a prefix in a custom field, and that would indicate that you wanted it static-routed down this interface. Again, you could only set a single prefix that way, although "route1", "route2", "route3" might cover your use cases. For now, you'd have to enter the prefix address/mask as a text string, but there's an open FR for being able to have a custom field which references another object (#7006)

[jeremystretch]

As previously stated, attempting to model a routing topology is out of scope for NetBox, however it may be a good use case for a plugin. I will caution that what you want to do is probably much more involved than you assume, but you're free to prove me wrong.