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

Vary interface ordering depending on platform #209

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

Originally created by @cstueckrath on GitHub (Jul 13, 2016).

#248 helped with device bays, but there are other instances:

Racks (e.g. B1.0.[1-12])

Interfaces (e.g. INT[1-14], EXT[1-11], which leads to something like this:
EXT1
INT1
INT2
EXT2
EXT3
INT3
...)

Originally created by @cstueckrath on GitHub (Jul 13, 2016). #248 helped with device bays, but there are other instances: Racks (e.g. B1.0.[1-12]) Interfaces (e.g. INT[1-14], EXT[1-11], which leads to something like this: EXT1 INT1 INT2 EXT2 EXT3 INT3 ...)
adam closed this issue 2025-12-29 16:19:23 +01:00
adam commented 2025-12-29 16:19:23 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 13, 2016):

When I create INT[1-3] and EXT[1-3] on a device, they are ordered as:

  • EXT1
  • INT1
  • EXT2
  • INT2
  • EXT3
  • INT3

This is due to how interfaces are ordered by their manager, sorting on the trailing numeric ID before the alphabetic type.

@jeremystretch commented on GitHub (Jul 13, 2016): When I create INT[1-3] and EXT[1-3] on a device, they are ordered as: - EXT1 - INT1 - EXT2 - INT2 - EXT3 - INT3 This is due to [how interfaces are ordered](https://github.com/digitalocean/netbox/blob/develop/netbox/dcim/models.py#L97) by their manager, sorting on the trailing numeric ID before the alphabetic type.
adam commented 2025-12-29 16:19:23 +01:00
Author
Owner
Copy Link

@Zanthras commented on GitHub (Jul 13, 2016):

For the simple case of just one integer field might it be worth sorting on sub-section A then B? Modular order usually does not apply when there isnt a module number (because its just a single integer field)

@Zanthras commented on GitHub (Jul 13, 2016): For the simple case of just one integer field might it be worth sorting on sub-section A then B? Modular order usually does not apply when there isnt a module number (because its just a single integer field)
adam commented 2025-12-29 16:19:24 +01:00
Author
Owner
Copy Link

@bellwood commented on GitHub (Jul 13, 2016):

I'm having some issues as well:

Cisco switch

TenGigabitEthernet1/0/1
GigabitEthernet1/0/1
TenGigabitEthernet1/0/2
GigabitEthernet1/0/2
...

Another Cisco switch

...
 GigabitEthernet1/0/51    
 GigabitEthernet1/0/52  
 vlan1

An HP Switch

 vlan 1  
 interface 1
...

Another HP Switch

 interface 1      
 vlan 1  
 interface 2
...

Juniper Router

...
xe-1/0/0
xe-1/1/0
xe-1/2/0
xe-1/3/0
GigabitEthernet2/0/0
GigabitEthernet2/0/1
GigabitEthernet2/0/2
GigabitEthernet2/0/3
GigabitEthernet2/0/4
GigabitEthernet2/0/5
GigabitEthernet2/0/6
GigabitEthernet2/0/7
GigabitEthernet2/0/8
GigabitEthernet2/0/9
GigabitEthernet2/1/0
GigabitEthernet2/1/1
GigabitEthernet2/1/2
GigabitEthernet2/1/3
GigabitEthernet2/1/4
GigabitEthernet2/1/5
GigabitEthernet2/1/6
GigabitEthernet2/1/7
GigabitEthernet2/1/8
GigabitEthernet2/1/9
xe-2/2/0
xe-2/3/0
...

I would say for consistency sort alphabetically then numerically on the leading interface digit otherwise you end up with what I've got above

@bellwood commented on GitHub (Jul 13, 2016): I'm having some issues as well: Cisco switch ``` TenGigabitEthernet1/0/1 GigabitEthernet1/0/1 TenGigabitEthernet1/0/2 GigabitEthernet1/0/2 ... ``` Another Cisco switch ``` ... GigabitEthernet1/0/51 GigabitEthernet1/0/52 vlan1 ``` An HP Switch ``` vlan 1 interface 1 ... ``` Another HP Switch ``` interface 1 vlan 1 interface 2 ... ``` Juniper Router ``` ... xe-1/0/0 xe-1/1/0 xe-1/2/0 xe-1/3/0 GigabitEthernet2/0/0 GigabitEthernet2/0/1 GigabitEthernet2/0/2 GigabitEthernet2/0/3 GigabitEthernet2/0/4 GigabitEthernet2/0/5 GigabitEthernet2/0/6 GigabitEthernet2/0/7 GigabitEthernet2/0/8 GigabitEthernet2/0/9 GigabitEthernet2/1/0 GigabitEthernet2/1/1 GigabitEthernet2/1/2 GigabitEthernet2/1/3 GigabitEthernet2/1/4 GigabitEthernet2/1/5 GigabitEthernet2/1/6 GigabitEthernet2/1/7 GigabitEthernet2/1/8 GigabitEthernet2/1/9 xe-2/2/0 xe-2/3/0 ... ``` I would say for consistency sort alphabetically then numerically on the leading interface digit otherwise you end up with what I've got above
adam commented 2025-12-29 16:19:24 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 15, 2016):

can interfaces not be sorted wholly as a string? if they were, then all characters should sort as expected. that includes trailing numbers. this is a snippet of my virtual interfaces. they're not sorted this way in the menus (by last 4 digits), but, sorted alphabetically in a spreadsheet or other app, they end up as desired:

V01-0199
V01-0299
V01-0399
V01-0499
...
V01-1999
V01-2099
V02-0199
V02-0299
V02-0399
V02-0499
...
V02-1899
V02-1999
V02-2099

edit: even better, sort by name in the select statement, let the DB do the sorting work. that should return everything sorted alphabetically based on what i've seen in the DB.

@ghost commented on GitHub (Jul 15, 2016): can interfaces not be sorted wholly as a string? if they were, then all characters should sort as expected. that includes trailing numbers. this is a snippet of my virtual interfaces. they're not sorted this way in the menus (by last 4 digits), but, sorted alphabetically in a spreadsheet or other app, they end up as desired: V01-0199 V01-0299 V01-0399 V01-0499 ... V01-1999 V01-2099 V02-0199 V02-0299 V02-0399 V02-0499 ... V02-1899 V02-1999 V02-2099 edit: even better, sort by name in the select statement, let the DB do the sorting work. that _should_ return everything sorted alphabetically based on what i've seen in the DB.
adam commented 2025-12-29 16:19:24 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 15, 2016):

can interfaces not be sorted wholly as a string?

This leads to chaos on some platforms. For instance, a Juniper switch might show

ge-0/0/0
ge-0/0/1
ge-0/0/3
...
ge-0/0/47
xe-0/0/2

Hence the need to order on slot/number rather than by type.

It doesn't seem like there exists a one-size-fits-all solution, unfortunately. Maybe we need to implement a few different ordering options (e.g. Cisco style, Juniper style, etc.) and make it an option on the device type.

@jeremystretch commented on GitHub (Jul 15, 2016): > can interfaces not be sorted wholly as a string? This leads to chaos on some platforms. For instance, a Juniper switch might show ``` ge-0/0/0 ge-0/0/1 ge-0/0/3 ... ge-0/0/47 xe-0/0/2 ``` Hence the need to order on slot/number rather than by type. It doesn't seem like there exists a one-size-fits-all solution, unfortunately. Maybe we need to implement a few different ordering options (e.g. Cisco style, Juniper style, etc.) and make it an option on the device type.
adam commented 2025-12-29 16:19:25 +01:00
Author
Owner
Copy Link

@bellwood commented on GitHub (Jul 15, 2016):

I'm actually OK with that Juniper example, all the ge interfaces come first followed by the xe interfaces

Ideally I don't want ge and xe mixing as the actual conf has them sorted out as you indicate above

Sorting of interfaces should be just as you'd see them on a switch config.

@bellwood commented on GitHub (Jul 15, 2016): I'm actually OK with that Juniper example, all the ge interfaces come first followed by the xe interfaces Ideally I don't want ge and xe mixing as the actual conf has them sorted out as you indicate above Sorting of interfaces should be just as you'd see them on a switch config.
adam commented 2025-12-29 16:19:25 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 15, 2016):

Sorting of interfaces should be just as you'd see them on a switch config.

I agree. Junos always sorts interfaces by slot and position, both in the configuration and in the output of show interfaces. It disregards interface type entirely because this can change (e.g. by using a different transceiver). NetBox replicates this ordering.

Cisco IOS, conversely, lists interfaces first by media type and then by slot/position. I can't think of any practical way to consolidate both strategies in a single function.

@jeremystretch commented on GitHub (Jul 15, 2016): > Sorting of interfaces should be just as you'd see them on a switch config. I agree. Junos always sorts interfaces by slot and position, both in the configuration and in the output of `show interfaces`. It disregards interface type entirely because this can change (e.g. by using a different transceiver). NetBox replicates this ordering. Cisco IOS, conversely, lists interfaces first by media type and then by slot/position. I can't think of any practical way to consolidate both strategies in a single function.
adam commented 2025-12-29 16:19:25 +01:00
Author
Owner
Copy Link

@bellwood commented on GitHub (Jul 15, 2016):

Maybe then as you stated we have different ones that can be tied to the devices' platform:

-Cisco IOS
-HP OS
-JunOS

...and so forth.

We'd have to ship with a few default platforms to match up with the associated sorting strategies.

This could also can-of-worms where in people will want to define their own sorting strategies (is that accomplishable?)

Just thinking the angles

@bellwood commented on GitHub (Jul 15, 2016): Maybe then as you stated we have different ones that can be tied to the devices' platform: -Cisco IOS -HP OS -JunOS ...and so forth. We'd have to ship with a few default platforms to match up with the associated sorting strategies. This could also can-of-worms where in people will want to define their own sorting strategies (is that accomplishable?) Just thinking the angles
adam commented 2025-12-29 16:19:25 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 21, 2016):

Per #373, it would be nice to add some capability to dynamically group interfaces by slot.

@jeremystretch commented on GitHub (Dec 21, 2016): Per #373, it would be nice to add some capability to dynamically group interfaces by slot.
adam commented 2025-12-29 16:19:26 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 6, 2017):

I've added an interface_ordering field to the DeviceType model, which allows for toggling the natural order of Interfaces (and InterfaceTemplates) per device type. The two options provided (by position and by name) seem sufficient, but if additional use cases arise we can handle them in a new issue.

@jeremystretch commented on GitHub (Jan 6, 2017): I've added an `interface_ordering` field to the DeviceType model, which allows for toggling the natural order of Interfaces (and InterfaceTemplates) per device type. The two options provided (by position and by name) seem sufficient, but if additional use cases arise we can handle them in a new issue.
adam commented 2025-12-29 16:19:26 +01:00
Author
Owner
Copy Link

@JNR8 commented on GitHub (Jan 25, 2017):

After the 1.8.2 release I now get the otoin to toggle the Interface list using the tow options above, but this only works on the Device Type Page. The Actual device page doesn't take any notice of this and does not have an optoin to toggle the sort options.

@JNR8 commented on GitHub (Jan 25, 2017): After the 1.8.2 release I now get the otoin to toggle the Interface list using the tow options above, but this only works on the Device Type Page. The Actual device page doesn't take any notice of this and does not have an optoin to toggle the sort options.
adam commented 2025-12-29 16:19:26 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 25, 2017):

@jennec The device view inherits interface ordering from its parent device type. This can be observed by creating, for example, interfaces named Gi0/[1-4] and Te0/[1-4] on a device. If the parent device type is configured to order interfaces by slot/position, the interfaces will appear intermingled; if it is configured to order alphabetically, all the Gi interfaces will be listed first, followed by all the Te interfaces. This is confirmed to be working on v1.8.2.

@jeremystretch commented on GitHub (Jan 25, 2017): @jennec The device view inherits interface ordering from its parent device type. This can be observed by creating, for example, interfaces named `Gi0/[1-4]` and `Te0/[1-4]` on a device. If the parent device type is configured to order interfaces by slot/position, the interfaces will appear intermingled; if it is configured to order alphabetically, all the Gi interfaces will be listed first, followed by all the Te interfaces. This is confirmed to be working on v1.8.2.
adam commented 2025-12-29 16:19:26 +01:00
Author
Owner
Copy Link

@JNR8 commented on GitHub (Jan 26, 2017):

1
2

@jeremystretch That doesn't match up wtih my expirience. I have a switch setup with 54 ports. Each labeled similarly to "04 - 10GBE (SFP+)". The Switch Device Type is set for Alphabetical sorting. When viewing the interfaces from the Device Type page the interfaces are sorted in reverse order (which is OK). But when viewed from the Device page they are in, what seems like, a random order. Perhaps it's related to the way I've named the interfaces, but that doesn;t make sense when it works on the Device Type Page but not the Device page.

Is the sort order inherited, when changed, for existing Devices using that Device Type or will it only affect new Devices created using that Device Type?

(see attached screen shots)

@JNR8 commented on GitHub (Jan 26, 2017): ![1](https://cloud.githubusercontent.com/assets/4245161/22327835/1ccb8c2c-e3b1-11e6-89b6-4448066f9804.PNG) ![2](https://cloud.githubusercontent.com/assets/4245161/22327843/2b571c2a-e3b1-11e6-965d-a707d52251af.PNG) @jeremystretch That doesn't match up wtih my expirience. I have a switch setup with 54 ports. Each labeled similarly to "04 - 10GBE (SFP+)". The Switch Device Type is set for Alphabetical sorting. When viewing the interfaces from the Device Type page the interfaces are sorted in reverse order (which is OK). But when viewed from the Device page they are in, what seems like, a random order. Perhaps it's related to the way I've named the interfaces, but that doesn;t make sense when it works on the Device Type Page but not the Device page. Is the sort order inherited, when changed, for existing Devices using that Device Type or will it only affect new Devices created using that Device Type? (see attached screen shots)
adam commented 2025-12-29 16:19:27 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 26, 2017):

You've appended the interface type to the name, which is evading the natural ordering logic. The interfaces should be named as they appear on the device; the interface form factor is maintained in a separate field. If you name the interfaces using only their numeric IDs (as they appear on the device), they will be sorted correctly.

@jeremystretch commented on GitHub (Jan 26, 2017): You've appended the interface type to the name, which is evading the [natural ordering logic](https://github.com/digitalocean/netbox/blob/develop/netbox/dcim/models.py#L684). The interfaces should be named as they appear on the device; the interface form factor is maintained in a separate field. If you name the interfaces using only their numeric IDs (as they appear on the device), they will be sorted correctly.
adam commented 2025-12-29 16:19:27 +01:00
Author
Owner
Copy Link

@JNR8 commented on GitHub (Jan 26, 2017):

I can appreciate the logic in that. But its competing against the sorting working correctly in the Device Type page but not on the Device itself. Are there differences between the two pages?

@JNR8 commented on GitHub (Jan 26, 2017): I can appreciate the logic in that. But its competing against the sorting working correctly in the Device Type page but not on the Device itself. Are there differences between the two pages?
adam commented 2025-12-29 16:19:27 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 26, 2017):

Since the ordering logic can't work with the names you've given the interfaces, the objects effectively aren't being ordered. This can result in non-deterministic behavior.

@jeremystretch commented on GitHub (Jan 26, 2017): Since the ordering logic can't work with the names you've given the interfaces, the objects effectively aren't being ordered. This can result in non-deterministic behavior.
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
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#209
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?