Device service ports (TCP/UDP)

[if-fi]

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:

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

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.

[jeremystretch]

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.

[avelin]

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.

[puck]

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.

[if-fi]

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

[bellwood]

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

[avelin]

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

[hdinthkld]

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.