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

Device service ports (TCP/UDP) #421

New Issue
Closed
opened 2025-12-29 16:21:54 +01:00 by adam · 7 comments
adam commented 2025-12-29 16:21:54 +01:00
Owner
Copy Link

Originally created by @if-fi on GitHub (Sep 7, 2016).

Hi NetBox maintainers,

I know according to the CONTRIBUTING guidelines for this project an issue should be opened prior to starting any work on extending NetBox functionality.
For the project I worked on the more convenient approach was to develop the functionality first so it can be used. Now I'd like to discuss with you if it fits your project vision and what changes I should make in order to contribute it to the NetBox project.

What I have developed is a functionality to make it possible to add a Service Port to a Device's IP address.
The port fields include - a reference to IP address, a type (tcp/udp), a port number, a name and a description.
Here's how it looks like:
selection_034

And here's how the Add Service Port screen looks like:
selection_035

I have also added ability to edit and delete Service Port.

I have done my best to stick to the code and design style of the whole application and I am open for further discussion any suggestions for improvements from your side.

I'm also ready to open a pull request whenever you give me a green light for that.

Thank you for your time for considering this new functionality.

Originally created by @if-fi on GitHub (Sep 7, 2016). Hi NetBox maintainers, I know according to the CONTRIBUTING guidelines for this project an issue should be opened prior to starting any work on extending NetBox functionality. For the project I worked on the more convenient approach was to develop the functionality first so it can be used. Now I'd like to discuss with you if it fits your project vision and what changes I should make in order to contribute it to the NetBox project. What I have developed is a functionality to make it possible to add a Service Port to a Device's IP address. The port fields include - a reference to _IP address_, a _type_ (_tcp/udp_), a _port number_, a _name_ and a _description_. Here's how it looks like: ![selection_034](https://cloud.githubusercontent.com/assets/935942/18314775/23a3f820-751d-11e6-8081-de81350dde43.png) And here's how the Add Service Port screen looks like: ![selection_035](https://cloud.githubusercontent.com/assets/935942/18314817/4e7bcf14-751d-11e6-819a-34f12ab6ae47.png) I have also added ability to edit and delete Service Port. I have done my best to stick to the code and design style of the whole application and I am open for further discussion any suggestions for improvements from your side. I'm also ready to open a pull request whenever you give me a green light for that. Thank you for your time for considering this new functionality.
adam closed this issue 2025-12-29 16:21:54 +01:00
adam commented 2025-12-29 16:21:55 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 7, 2016):

Thank you for opening an issue before submitting a PR!

I feel like this would be too tedious to track explicitly per device. For instance, I wouldn't want to create an SSH service for each device, since nearly every device supports it. NETCONF, SNMP, etc. would also need to be tracked for each device.

An alternate approach might be to define services per platform rather than per individual device. For example, we could pretty safely assume that every Juniper Junos device supports SSH and NETCONF. The device page could show the relevant services based on the device's platform. It would probably be sufficient to assume the services run on the device's primary IP, rather than attempting to tie each to a specific IP.

Interested to hear what others think.

@jeremystretch commented on GitHub (Sep 7, 2016): Thank you for opening an issue before submitting a PR! I feel like this would be too tedious to track explicitly per device. For instance, I wouldn't want to create an SSH service for each device, since nearly every device supports it. NETCONF, SNMP, etc. would also need to be tracked for each device. An alternate approach might be to define services per platform rather than per individual device. For example, we could pretty safely assume that every Juniper Junos device supports SSH and NETCONF. The device page could show the relevant services based on the device's platform. It would probably be sufficient to assume the services run on the device's primary IP, rather than attempting to tie each to a specific IP. Interested to hear what others think.
adam commented 2025-12-29 16:21:55 +01:00
Author
Owner
Copy Link

@avelin commented on GitHub (Sep 8, 2016):

I don't mind "services-per-platform" approach, it will be useful, but the individual setting port-on-ip-on-device has its uses, especially in servers (as opposed to network devices). It will be very useful to have the opportunity, if one wants, to define specific services working on that particular server.

@avelin commented on GitHub (Sep 8, 2016): I don't mind "services-per-platform" approach, it will be useful, but the individual setting port-on-ip-on-device has its uses, especially in servers (as opposed to network devices). It will be very useful to have the opportunity, if one wants, to define specific services working on that particular server.
adam commented 2025-12-29 16:21:56 +01:00
Author
Owner
Copy Link

@puck commented on GitHub (Sep 8, 2016):

I think we'd make use of this - we're already feeding information from netbox into our Icinga2 installation and dynamically creating checks based on that data.

Being able to specify ports to check, and the type of service it is could also feed into those dynamically generated checks.

I agree that we wouldn't put in the bog standard ssh, snmp, etc ports.

@puck commented on GitHub (Sep 8, 2016): I think we'd make use of this - we're already feeding information from netbox into our Icinga2 installation and dynamically creating checks based on that data. Being able to specify ports to check, and the type of service it is could also feed into those dynamically generated checks. I agree that we wouldn't put in the bog standard ssh, snmp, etc ports.
adam commented 2025-12-29 16:21:56 +01:00
Author
Owner
Copy Link

@if-fi commented on GitHub (Sep 19, 2016):

@jeremystretch The functionality was developed for the scenario when we want to define that a specific service is running on a concrete device and port.

In a more general approach, an IP address 0.0.0.0 can be added to the device and adding service to this IP means that it runs on the same port on all of its IP addresses.

I thought about your proposal about adding service per platform, but this is a different scenario. One possible solution to incorporate the 2 may be - when creating a new Device Type we can create behind the scenes an IP 0.0.0.0 for it and present the user some input boxes to define service ports for this IP. But such solution would require a separate discussion and can be implemented later as a second iteration of the functionality.

I suggest focus on the primary use case - when we want to specify a specific service running on specific Device's IP.

@if-fi commented on GitHub (Sep 19, 2016): @jeremystretch The functionality was developed for the scenario when we want to define that a specific service is running on a concrete device and port. In a more general approach, an IP address `0.0.0.0` can be added to the device and adding service to this IP means that it runs on the same port on all of its IP addresses. I thought about your proposal about adding service per platform, but this is a different scenario. One possible solution to incorporate the 2 may be - when creating a new Device Type we can create behind the scenes an IP `0.0.0.0` for it and present the user some input boxes to define service ports for this IP. But such solution would require a separate discussion and can be implemented later as a second iteration of the functionality. I suggest focus on the primary use case - when we want to specify a specific service running on specific Device's IP.
adam commented 2025-12-29 16:21:56 +01:00
Author
Owner
Copy Link

@bellwood commented on GitHub (Sep 28, 2016):

My .02 - we have A LOT of customers with SSH on custom ports so while having the presumption of SSH being on 0.0.0.0/22 for say a switch/router is safe, presuming that on a server isn't.

Perhaps when creating a device there could be the options:

[ ] "inherit service ports from RFC" (or "inherit service ports from 'service port roles'", etc)
[ ] "allow custom service ports"

This way you're only tracking service ports for devices that have custom ports

@bellwood commented on GitHub (Sep 28, 2016): My .02 - we have A LOT of customers with SSH on custom ports so while having the presumption of SSH being on 0.0.0.0/22 for say a switch/router is safe, presuming that on a server isn't. Perhaps when creating a device there could be the options: ``` [ ] "inherit service ports from RFC" (or "inherit service ports from 'service port roles'", etc) [ ] "allow custom service ports" ``` This way you're only tracking service ports for devices that have custom ports
adam commented 2025-12-29 16:21:57 +01:00
Author
Owner
Copy Link

@avelin commented on GitHub (Oct 7, 2016):

I see there's a pull request for this... could we expect soon this to be merged ?

@avelin commented on GitHub (Oct 7, 2016): I see there's a pull request for this... could we expect soon this to be merged ?
adam commented 2025-12-29 16:21:57 +01:00
Author
Owner
Copy Link

@hdinthkld commented on GitHub (Nov 24, 2016):

Having the ability to specify a service port is also useful where NAT is involved.

For example in order to conserve some of our IP address's we'll say NAT 1.1.1.1:80 to 192.168.1.10:80 but then also use 1.1.1.1:25 t 192.168.1.11:25 for a mail server. This cannot currently be reflected in the inside/outside IP address assignment.

@hdinthkld commented on GitHub (Nov 24, 2016): Having the ability to specify a service port is also useful where NAT is involved. For example in order to conserve some of our IP address's we'll say NAT 1.1.1.1:80 to 192.168.1.10:80 but then also use 1.1.1.1:25 t 192.168.1.11:25 for a mail server. This cannot currently be reflected in the inside/outside IP address assignment.
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#421
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?