Grouping tcp+udp services #4197

New Issue

adam · 2025-12-29T18:33:48+01:00

adam commented

2025-12-29 18:33:48 +01:00

Originally created by @Matze1224 on GitHub (Oct 17, 2020).

Environment

Python version: 3.7.3
NetBox version: 2.9.7

I have some services which both listen on TCP and UDP. There are DNS, mumble and some gameservers.

Proposed Functionality

Instead of creating the service twice for TCP and UDP, it would be better to select both (by marking both in the drop-down) or simply select "TCP+UDP" in the service creation UI. This would assume to store this information in a single entry.

Use Case

Easier creation instead of repeating the service creation a second time.

Database Changes

Maybe to allow storing TCP and UDP in the same database entry.

External Dependencies

n/a

Originally created by @Matze1224 on GitHub (Oct 17, 2020). ### Environment * Python version: 3.7.3 * NetBox version: 2.9.7 I have some services which both listen on TCP and UDP. There are DNS, mumble and some gameservers. ### Proposed Functionality Instead of creating the service twice for TCP and UDP, it would be better to select both (by marking both in the drop-down) or simply select "TCP+UDP" in the service creation UI. This would assume to store this information in a single entry. ### Use Case Easier creation instead of repeating the service creation a second time. ### Database Changes Maybe to allow storing TCP and UDP in the same database entry. ### External Dependencies n/a

adam closed this issue

2025-12-29 18:33:48 +01:00

adam commented

2025-12-29 18:33:48 +01:00

@jeremystretch commented on GitHub (Oct 20, 2020):

This would violate the strict meaning of the protocol field. As the service model is often employed for generating firewall rules and similar constructs, allowing this field to convey non-protocol values would introduce undue complexity for API consumers.

For example, if you have a script that generates a firewall policy from services populated in NetBox, you could no longer rely on the protocol field to convey a literal value. In the event it returned a value representing the combination of TCP and UDP, additional logic would be needed to replicate this into two rules (one for each protocol) each with its appropriate literal value.

@jeremystretch commented on GitHub (Oct 20, 2020): This would violate the strict meaning of the `protocol` field. As the service model is often employed for generating firewall rules and similar constructs, allowing this field to convey non-protocol values would introduce undue complexity for API consumers. For example, if you have a script that generates a firewall policy from services populated in NetBox, you could no longer rely on the protocol field to convey a literal value. In the event it returned a value representing the combination of TCP and UDP, additional logic would be needed to replicate this into two rules (one for each protocol) each with its appropriate literal value.

adam commented

2025-12-29 18:33:48 +01:00

@Matze1224 commented on GitHub (Oct 20, 2020):

And what's about just grouping them in the UI? So there are still two entries, but it's easier to configure.

@Matze1224 commented on GitHub (Oct 20, 2020): And what's about just grouping them in the UI? So there are still two entries, but it's easier to configure.

adam commented

2025-12-29 18:33:49 +01:00

@jeremystretch commented on GitHub (Oct 20, 2020):

Seems like it would be too much effort for very little value.

@jeremystretch commented on GitHub (Oct 20, 2020): Seems like it would be too much effort for very little value.

adam commented

2025-12-29 18:33:49 +01:00

@Matze1224 commented on GitHub (Oct 23, 2020):

Yes, I understand. My last idea would be to have presets which could create the required services, but I guess this is already covered by custom scripts. So I guess it's not a great pain to copy'n'paste it over (as I'm the first one thinking about it) - just some idea to optimize it a bit.

@Matze1224 commented on GitHub (Oct 23, 2020): Yes, I understand. My last idea would be to have presets which could create the required services, but I guess this is already covered by custom scripts. So I guess it's not a great pain to copy'n'paste it over (as I'm the first one thinking about it) - just some idea to optimize it a bit.

adam commented

2025-12-29 18:33:49 +01:00

@Matze1224 commented on GitHub (Nov 3, 2020):

Closing it because it doesn't look that something like this will be implemented.

@Matze1224 commented on GitHub (Nov 3, 2020): Closing it because it doesn't look that something like this will be implemented.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

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#4197