starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Gateway / Router role for IP Addresses #1321

New Issue
Closed
opened 2025-12-29 16:31:26 +01:00 by adam · 2 comments
adam commented 2025-12-29 16:31:26 +01:00
Owner
Copy Link

Originally created by @hamishforbes on GitHub (Oct 17, 2017).

Issue type

[x] Feature request
[ ] Bug report
[ ] Documentation

Environment

  • Python version: 2.7.5
  • NetBox version: 2.2.1

Description

It would be helpful to be able to somehow identify the default gateway address within a prefix.
This is something Racktables offers and is a minor sticking point on our migration to Netbox.

Unless there are any better suggestions I think a 'Gateway' role for IP addresses would fit our needs at least.

Originally created by @hamishforbes on GitHub (Oct 17, 2017). <!-- Before opening a new issue, please search through the existing issues to see if your topic has already been addressed. Note that you may need to remove the "is:open" filter from the search bar to include closed issues. Check the appropriate type for your issue below by placing an x between the brackets. If none of the below apply, please raise your issue for discussion on our mailing list: https://groups.google.com/forum/#!forum/netbox-discuss Please note that issues which do not fall under any of the below categories will be closed. ---> ### Issue type [x] Feature request <!-- Requesting the implementation of a new feature --> [ ] Bug report <!-- Reporting unexpected or erroneous behavior --> [ ] Documentation <!-- Proposing a modification to the documentation --> <!-- Please describe the environment in which you are running NetBox. (Be sure to verify that you are running the latest stable release of NetBox before submitting a bug report.) --> ### Environment * Python version: 2.7.5 * NetBox version: 2.2.1 <!-- BUG REPORTS must include: * A list of the steps needed to reproduce the bug * A description of the expected behavior * Any relevant error messages (screenshots may also help) FEATURE REQUESTS must include: * A detailed description of the proposed functionality * A use case for the new feature * A rough description of any necessary changes to the database schema * Any relevant third-party libraries which would be needed --> ### Description It would be helpful to be able to somehow identify the default gateway address within a prefix. This is something Racktables offers and is a minor sticking point on our migration to Netbox. Unless there are any better suggestions I think a 'Gateway' role for IP addresses would fit our needs at least.
adam closed this issue 2025-12-29 16:31:26 +01:00
adam commented 2025-12-29 16:31:27 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 17, 2017):

This came up briefly in #819 and again in #1434. I decided against adding it in part because the designation of an IP address as the default gateway is unrelated to its type: A default gateway IP can be of any type. But more importantly, a default gateway a property of the sending host, not the IP assigned on the router. (It's perfectly plausible that two sets of hosts sharing a common prefix use different nodes as their default gateways.)

As I mentioned in #1434, there are other attributes you can use in identifying default gateways. Tagging (#132) might also help address this once implemented.

@jeremystretch commented on GitHub (Oct 17, 2017): This came up briefly in #819 and again in #1434. I decided against adding it in part because the designation of an IP address as the default gateway is unrelated to its type: A default gateway IP can be of any type. But more importantly, a default gateway a property of the sending host, not the IP assigned on the router. (It's perfectly plausible that two sets of hosts sharing a common prefix use different nodes as their default gateways.) As I [mentioned](https://github.com/digitalocean/netbox/issues/1434#issuecomment-323170257) in #1434, there are other attributes you can use in identifying default gateways. Tagging (#132) might also help address this once implemented.
adam commented 2025-12-29 16:31:27 +01:00
Author
Owner
Copy Link

@hamishforbes commented on GitHub (Oct 17, 2017):

Hmm, I see your point, although I still think some way to mark an IP as a 'gateway' i.e. capable of forwarding traffic is useful.
It's not necessarily the default gateway because, as you say, thats a property of the source host.

I suppose its really a property of the relationship between an IP and an interface more than anything.
Which is how Racktables handles it, the assignment of an IP to an device has a type (loopback/router/shared etc) independent of the IP, device and interface objects.

I will say trying to identify a gateway IP within a prefix with the current tools is difficult though.
They may be at the top or bottom of a range, but we have cases where gateways are at arbitrary offsets as well (for legacy reasons mostly).
They might be assigned to a router or a switch, but not all IPs assigned to a router or switch are gateway IPs.
Trying to, programmatically, check all of these options is unwieldy, slow and prone to errors.

Arbitrary tagging would definitely solve this for us too though.

@hamishforbes commented on GitHub (Oct 17, 2017): Hmm, I see your point, although I still think some way to mark an IP as a 'gateway' i.e. capable of forwarding traffic is useful. It's not necessarily the *default* gateway because, as you say, thats a property of the source host. I suppose its really a property of the relationship between an IP and an interface more than anything. Which is how Racktables handles it, the assignment of an IP to an device has a type (loopback/router/shared etc) independent of the IP, device and interface objects. I will say trying to identify a gateway IP within a prefix with the current tools is difficult though. They may be at the top or bottom of a range, but we have cases where gateways are at arbitrary offsets as well (for legacy reasons mostly). They might be assigned to a router or a switch, but not all IPs assigned to a router or switch are gateway IPs. Trying to, programmatically, check all of these options is unwieldy, slow and prone to errors. Arbitrary tagging would definitely solve this for us too though.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#1321
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?