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

Improve network interface IP list #7152

New Issue
Closed
opened 2025-12-29 20:19:46 +01:00 by adam · 4 comments
adam commented 2025-12-29 20:19:46 +01:00
Owner
Copy Link

Originally created by @danie-dejager on GitHub (Oct 24, 2022).

NetBox version

v3.3.5

Feature type

Change to existing functionality

Proposed functionality

Currently all IP addresses linked to an interface is displayed as a list in the interface
image
We linked the IP addresses up, internal/external NAT. Is it not possible to display that linkup in the Network interface as well?
image

Use case

It will clean up the list of IP addresses and show how they are linked.

Database changes

unknown

External dependencies

unknown

Originally created by @danie-dejager on GitHub (Oct 24, 2022). ### NetBox version v3.3.5 ### Feature type Change to existing functionality ### Proposed functionality Currently all IP addresses linked to an interface is displayed as a list in the interface ![image](https://user-images.githubusercontent.com/13314239/197463829-97bd12b8-68b4-4410-9115-3ded36a0155e.png) We linked the IP addresses up, internal/external NAT. Is it not possible to display that linkup in the Network interface as well? ![image](https://user-images.githubusercontent.com/13314239/197464475-765994cd-086e-4ca6-99ed-818a97a8c297.png) ### Use case It will clean up the list of IP addresses and show how they are linked. ### Database changes unknown ### External dependencies unknown
adam added the type: feature label 2025-12-29 20:19:46 +01:00
adam closed this issue 2025-12-29 20:19:46 +01:00
adam commented 2025-12-29 20:19:47 +01:00
Author
Owner
Copy Link

@t8simon commented on GitHub (Oct 25, 2022):

I also just stumbled over this missing feature, as the current situation does not provide optimal overview for NAT relationships and is not quite intuitive.
In the "Primary IP" Field this sort of thing is already implemented:
image

This view although struggles when an inside and outside NAT is defined on the same IP (yes, this can exist in the wild)

In the Interfaces list it should be clear, which IP is actually configured on this particular interface (and which IPs are just IPs that are from a NAT relationship but configured on another device).

So one solution could be (adapted from your proposal):

10.190.0.53                                                   # normal single IP
10.190.0.54 (-> NAT IP 10.150.68.5)                           # Interface IP is Outside NAT
(NAT IP 10.170.55.7 ->) 10.190.0.55                           # Interface IP is Inside NAT
(NAT IP 10.160.78.97 ->) 10.190.0.56 (-> NAT IP 10.165.4.63)  # Interface IP is both Inside and Outside NAT

Probably it would also help to color Separate the NAT part for further user guidance in the GUI.

As the unaligned IP addresses could trigger some OCDs (including myself):

10.190.0.53                                                             # normal single IP
10.190.0.54 (Inside NAT IP: 10.150.68.5)                                # Interface IP is Outside NAT
10.190.0.55 (Outside NAT IP: 10.170.55.7)                               # Interface IP is Inside NAT
10.190.0.56 (Outside NAT IP: 10.160.78.97, Inside NAT IP: 10.165.4.63)  # Interface IP is both Inside and Outside NAT

Another possibility could be by adding an "Inside NAT" and "Outside NAT" column to the interfaces table.

I'm not sure yet, what option provides the most intuitive way to make the NAT relationships more visible.

@t8simon commented on GitHub (Oct 25, 2022): I also just stumbled over this missing feature, as the current situation does not provide optimal overview for NAT relationships and is not quite intuitive. In the "Primary IP" Field this sort of thing is already implemented: ![image](https://user-images.githubusercontent.com/104978710/197722544-78b87679-2c5a-45fa-aaff-39db99864ab1.png) This view although struggles when an inside and outside NAT is defined on the same IP (yes, this can exist in the wild) In the Interfaces list it should be clear, which IP is actually configured on this particular interface (and which IPs are just IPs that are from a NAT relationship but configured on another device). So one solution could be (adapted from your proposal): ``` 10.190.0.53 # normal single IP 10.190.0.54 (-> NAT IP 10.150.68.5) # Interface IP is Outside NAT (NAT IP 10.170.55.7 ->) 10.190.0.55 # Interface IP is Inside NAT (NAT IP 10.160.78.97 ->) 10.190.0.56 (-> NAT IP 10.165.4.63) # Interface IP is both Inside and Outside NAT ``` Probably it would also help to color Separate the NAT part for further user guidance in the GUI. As the unaligned IP addresses could trigger some OCDs (including myself): ``` 10.190.0.53 # normal single IP 10.190.0.54 (Inside NAT IP: 10.150.68.5) # Interface IP is Outside NAT 10.190.0.55 (Outside NAT IP: 10.170.55.7) # Interface IP is Inside NAT 10.190.0.56 (Outside NAT IP: 10.160.78.97, Inside NAT IP: 10.165.4.63) # Interface IP is both Inside and Outside NAT ``` Another possibility could be by adding an "Inside NAT" and "Outside NAT" column to the interfaces table. I'm not sure yet, what option provides the most intuitive way to make the NAT relationships more visible.
adam commented 2025-12-29 20:19:47 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 25, 2022):

NATted IPs aren't displayed because they aren't relevant to the interface, and this is a list of interface attributes. When you start trying to cram in tangential data, the UI quickly degrades into an unusable mess. To view IPs related to the assigned IP, you can easily navigate to its dedicated view.

@jeremystretch commented on GitHub (Oct 25, 2022): NATted IPs aren't displayed because they aren't relevant to the interface, and this is a list of interface attributes. When you start trying to cram in tangential data, the UI quickly degrades into an unusable mess. To view IPs related to the assigned IP, you can easily navigate to its dedicated view.
adam commented 2025-12-29 20:19:47 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 2, 2022):

Going to decline this proposal for the reason cited above.

@jeremystretch commented on GitHub (Nov 2, 2022): Going to decline this proposal for the reason cited above.
adam commented 2025-12-29 20:19:47 +01:00
Author
Owner
Copy Link

@t8simon commented on GitHub (Nov 3, 2022):

Maybe a bit late, but i still would love to see some discussion about the visibility of NAT addresses.
You're right, the interface is maybe the wrong place for that. As I am managing quite a few firewalls it would be useful, to have a good overview over the NAT relationship, that does not involve clicking a lot of IP addresses.

As a NAT is clearly linked to the IP configuration of the device/VM, it should be visible somewhere in the device view. The NAT information for the primary IP is doing some of that already, but the scope of just this one IP is just a small part in the whole picture about how the device/VM is handling IP related things.

The only way I can think of to achieve this visibility is by going to the IP section, add the NAT colums and then apply filter for the device / vm. This is also rather inconvenient when someone is starting from a device/vm perspective and lowers user acceptance due to that.

Some more ideas how NAT visibility could be improved on device level:

  • A NAT Card on the device/VM view (like the Service card for example)
  • A tab on the device/VM view (like Interfaces)
  • A card with stats on the device/VM view, where NAT is one of the stats (like the stats card in the tenants view) -> this would forward you directly to the correct filter (also similar to the tenants stats card)

What is your view on NAT relationship visibility or visibility of peripheral data around devices/vms? What should be the correct and most efficient workflow to gain quick overview over such data? Especially in environments, where there are 100+ IPs on a device and dozens of NAT on the IPs as well?

@t8simon commented on GitHub (Nov 3, 2022): Maybe a bit late, but i still would love to see some discussion about the visibility of NAT addresses. You're right, the interface is maybe the wrong place for that. As I am managing quite a few firewalls it would be useful, to have a good overview over the NAT relationship, that does not involve clicking a lot of IP addresses. As a NAT is clearly linked to the IP configuration of the device/VM, it should be visible somewhere in the device view. The NAT information for the primary IP is doing some of that already, but the scope of just this one IP is just a small part in the whole picture about how the device/VM is handling IP related things. The only way I can think of to achieve this visibility is by going to the IP section, add the NAT colums and then apply filter for the device / vm. This is also rather inconvenient when someone is starting from a device/vm perspective and lowers user acceptance due to that. Some more ideas how NAT visibility could be improved on device level: - A NAT Card on the device/VM view (like the Service card for example) - A tab on the device/VM view (like Interfaces) - A card with stats on the device/VM view, where NAT is one of the stats (like the stats card in the tenants view) -> this would forward you directly to the correct filter (also similar to the tenants stats card) What is your view on NAT relationship visibility or visibility of peripheral data around devices/vms? What should be the correct and most efficient workflow to gain quick overview over such data? Especially in environments, where there are 100+ IPs on a device and dozens of NAT on the IPs as well?
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 type: feature
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#7152
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?