netbox icon indicating copy to clipboard operation
netbox copied to clipboard

Show child interfaces under his parent

Open CyrielRct opened this issue 2 years ago • 6 comments

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

CyrielRct avatar Jul 31 '23 19:07 CyrielRct

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 avatar Oct 04 '23 19:10 davidgwatkins

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 avatar Oct 04 '23 22:10 eric-eisenhart

this would improve interface view of device greatly.

dejantep avatar Nov 22 '23 20:11 dejantep

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] avatar Feb 21 '24 04:02 github-actions[bot]

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 avatar Mar 12 '24 14:03 jeremystretch

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 avatar Mar 12 '24 19:03 dejantep

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 avatar Mar 20 '24 16:03 PieterL75

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 avatar May 17 '24 01:05 davidgwatkins