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

Show child interfaces under his parent #8397

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

Originally created by @CyrielRct on GitHub (Jul 31, 2023).

NetBox version

v3.5.4

Feature type

Change to existing functionality

Proposed functionality

Attaches all child interfaces to the parent interface when the parent interface is defined.

Here is an example :

image

Use case

This proposal is designed to improve visibility within breakdown interfaces. Some equipment has no identification of the parent interface number in the breakdown sub-interface name.

This view contributes to greater clarity.

Database changes

None

External dependencies

None

Originally created by @CyrielRct on GitHub (Jul 31, 2023). ### NetBox version v3.5.4 ### Feature type Change to existing functionality ### Proposed functionality Attaches all child interfaces to the parent interface when the parent interface is defined. Here is an example : ![image](https://github.com/netbox-community/netbox/assets/4038285/902a09ff-1d5a-4d3a-91f6-cf7c56959613) ### Use case This proposal is designed to improve visibility within breakdown interfaces. Some equipment has no identification of the parent interface number in the breakdown sub-interface name. This view contributes to greater clarity. ### Database changes None ### External dependencies None
adam closed this issue 2025-12-29 20:36:11 +01:00
adam commented 2025-12-29 20:36:11 +01:00
Author
Owner
Copy Link

@davidgwatkins commented on GitHub (Oct 4, 2023):

Great idea to group them -- maybe something like borrowing from the nesting style used in the Regions table.

Can't help but notice that what you're using for "virtual" interfaces there are actually physical 10Gs out of the 40G. I still want to give breakout modeling a shot. 😄

@davidgwatkins commented on GitHub (Oct 4, 2023): Great idea to group them -- maybe something like borrowing from the nesting style used in the Regions table. Can't help but notice that what you're using for "virtual" interfaces there are actually physical 10Gs out of the 40G. I still want to give breakout modeling a shot. 😄
adam commented 2025-12-29 20:36:11 +01:00
Author
Owner
Copy Link

@eric-eisenhart commented on GitHub (Oct 5, 2023):

FWIW, it would be nice to have LAG members group under the interface they're part of, too...

(not sure if that's covered by this request already or not)

Current 3.6.3 example:
image

But I'd love to see that more like:

bond0
|- e2
|- e3
|- bond0.101
e0
e1
IPMI
@eric-eisenhart commented on GitHub (Oct 5, 2023): FWIW, it would be nice to have LAG members group under the interface they're part of, too... (not sure if that's covered by this request already or not) Current 3.6.3 example: ![image](https://github.com/netbox-community/netbox/assets/1577595/4f0ff59e-0a5d-42c9-8bad-f8d2bf990165) But I'd love to see that more like: ``` bond0 |- e2 |- e3 |- bond0.101 e0 e1 IPMI ```
adam commented 2025-12-29 20:36:12 +01:00
Author
Owner
Copy Link

@dejantep commented on GitHub (Nov 22, 2023):

this would improve interface view of device greatly.

@dejantep commented on GitHub (Nov 22, 2023): this would improve interface view of device greatly.
adam commented 2025-12-29 20:36:12 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Feb 21, 2024):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Feb 21, 2024): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 20:36:12 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 12, 2024):

The trick here is going to be ordering the interfaces as a single Queryset, to ensure that child interfaces appear after their parent but before the next parent. We'd probably need to annotate a concatenation of (parent name, interface name) to effect the proper ordering. For example, to achieve a hierarchy like

  • Eth0
    • Eth0.100
    • Eth0.200
  • Eth1
    • Eth1.100
    • Eth1.200
  • Eth2

we would need to order by the following values:

  • Eth0
  • Eth0-Eth0.100
  • Eth0-Eth0.200
  • Eth1
  • Eth1-Eth1.100
  • Eth1-Eth1.200
  • Eth2

Great idea to group them -- maybe something like borrowing from the nesting style used in the Regions table.

Regions and other recursively-nested models utilize MPTT for this, which isn't really applicable to device components.

@jeremystretch commented on GitHub (Mar 12, 2024): The trick here is going to be ordering the interfaces as a single Queryset, to ensure that child interfaces appear _after_ their parent but _before_ the next parent. We'd probably need to annotate a concatenation of (parent name, interface name) to effect the proper ordering. For example, to achieve a hierarchy like * Eth0 * Eth0.100 * Eth0.200 * Eth1 * Eth1.100 * Eth1.200 * Eth2 we would need to order by the following values: * `Eth0` * `Eth0-Eth0.100` * `Eth0-Eth0.200` * `Eth1` * `Eth1-Eth1.100` * `Eth1-Eth1.200` * `Eth2` > Great idea to group them -- maybe something like borrowing from the nesting style used in the Regions table. Regions and other recursively-nested models utilize MPTT for this, which isn't really applicable to device components.
adam commented 2025-12-29 20:36:12 +01:00
Author
Owner
Copy Link

@dejantep commented on GitHub (Mar 12, 2024):

Would it be possible to somehow use physical interface id as start point?
A child interface could inherit id value with added values of some sort?

dcim.interface:1774

  • dcim.interface:1774.1 or 17741, 17742 etc
@dejantep commented on GitHub (Mar 12, 2024): Would it be possible to somehow use physical interface id as start point? A child interface could inherit id value with added values of some sort? dcim.interface:1774 - dcim.interface:1774.1 or 17741, 17742 etc
adam commented 2025-12-29 20:36:12 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Mar 20, 2024):

The ordering of interfaces is an old pain.. it will never suit everybody's needs...
I'm asking for a long time to sort them different, more naturally, but that never got traction because no solution was fine.
Maybe this request is a good re-start of how interfaces are ordered and get a different system implemented...
ex on a juniper, there are intefaces ordered like this in netbox...
ge-0/0/0
ge-0/0/3
xe-0/0/1
xe-0/0/2
and arista:
Ethernet54/1
Ethernet55/1
Ethernet56/1
Ethernet1
Ethernet2
Ethernet3

I do want to contribute in the 'formula' or a way to get this all working fine for all usecases, but that will require some re-invention of this

@PieterL75 commented on GitHub (Mar 20, 2024): The ordering of interfaces is an old pain.. it will never suit everybody's needs... I'm asking for a long time to sort them different, more naturally, but that never got traction because no solution was fine. Maybe this request is a good re-start of how interfaces are ordered and get a different system implemented... ex on a juniper, there are intefaces ordered like this in netbox... ge-0/0/0 ge-0/0/3 xe-0/0/1 xe-0/0/2 and arista: Ethernet54/1 Ethernet55/1 Ethernet56/1 Ethernet1 Ethernet2 Ethernet3 I do want to contribute in the 'formula' or a way to get this all working fine for all usecases, but that will require some re-invention of this
adam commented 2025-12-29 20:36:13 +01:00
Author
Owner
Copy Link

@davidgwatkins commented on GitHub (May 17, 2024):

Regions and other recursively-nested models utilize MPTT for this, which isn't really applicable to device components.

Could you explain this comment a bit more, please? I am not very familiar with MPTT; is it not performant for large datasets?

Physical port > Physical interface > Logical subinterface is a pretty universal interface hierarchy across most vendor NOS for multi-SERDES ports. Subinterfaces may not use the dot notation or explicitly use the term "subinterface" (JuNOS "unit", SROS "service access points", SAOS "flow points", etc), which is why storing it in a hierarchy that allows flexible naming makes sense, at least to me.

@davidgwatkins commented on GitHub (May 17, 2024): > Regions and other recursively-nested models utilize MPTT for this, which isn't really applicable to device components. Could you explain this comment a bit more, please? I am not very familiar with MPTT; is it not performant for large datasets? Physical port > Physical interface > Logical subinterface is a pretty universal interface hierarchy across most vendor NOS for multi-SERDES ports. Subinterfaces may not use the dot notation or explicitly use the term "subinterface" (JuNOS "unit", SROS "service access points", SAOS "flow points", etc), which is why storing it in a hierarchy that allows flexible naming makes sense, at least to me.
adam commented 2025-12-29 20:36:13 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Aug 24, 2024):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Aug 24, 2024): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 20:36:13 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Sep 23, 2024):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Sep 23, 2024): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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 complexity: high pending closure status: needs owner topic: UI/UX 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#8397
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?