Add support for IP Routing #5770

New Issue

adam · 2025-12-29T19:32:30+01:00

adam commented

2025-12-29 19:32:30 +01:00

Originally created by @micko on GitHub (Dec 14, 2021).

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.

Originally created by @micko on GitHub (Dec 14, 2021). ### 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.

adam added the plugin candidate label 2025-12-29 19:32:30 +01:00

adam closed this issue

2025-12-29 19:32:30 +01:00

adam commented

2025-12-29 19:32:31 +01:00

@jeremystretch commented on GitHub (Dec 15, 2021):

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.

@jeremystretch commented on GitHub (Dec 15, 2021): > 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.

adam commented

2025-12-29 19:32:31 +01:00

@micko commented on GitHub (Dec 15, 2021):

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.

@micko commented on GitHub (Dec 15, 2021): > > 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.

adam commented

2025-12-29 19:32:31 +01:00

@jeremystretch commented on GitHub (Dec 15, 2021):

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

@jeremystretch commented on GitHub (Dec 15, 2021): I'm afraid that modeling an entire routing topology is out of scope for NetBox. What are you trying to accomplish here?

adam commented

2025-12-29 19:32:31 +01:00

@micko commented on GitHub (Dec 15, 2021):

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

@micko commented on GitHub (Dec 15, 2021): > 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..

adam commented

2025-12-29 19:32:31 +01:00

@DanSheps commented on GitHub (Dec 15, 2021):

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

@DanSheps commented on GitHub (Dec 15, 2021): For something the scope of routing infrastructure (static routes, etc), you are better to look into custom plugins.

adam commented

2025-12-29 19:32:31 +01:00

@micko commented on GitHub (Dec 15, 2021):

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

@micko commented on GitHub (Dec 15, 2021): 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..

adam commented

2025-12-29 19:32:32 +01:00

@candlerb commented on GitHub (Dec 18, 2021):

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)

@candlerb commented on GitHub (Dec 18, 2021): 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)

adam commented

2025-12-29 19:32:32 +01:00

@jeremystretch commented on GitHub (Dec 22, 2021):

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.

@jeremystretch commented on GitHub (Dec 22, 2021): 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.

Sign in to join this conversation.

Branches Tags

main

21102-fix-graphiql-explorer

update-changelog-comments-docs

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#5770