Show child interfaces under his parent

[CyrielRct]

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 :

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

[davidgwatkins]

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

[eric-eisenhart]

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:

But I'd love to see that more like:

bond0
|- e2
|- e3
|- bond0.101
e0
e1
IPMI

[dejantep]

this would improve interface view of device greatly.

[github-actions[bot]]

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.

[jeremystretch]

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.

[dejantep]

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

[PieterL75]

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

[davidgwatkins]

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.

[github-actions[bot]]

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]]

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.