Change interface naturalize function

[PieterL75]

NetBox version

v3.2.2

Feature type

Change to existing functionality

Proposed functionality

The interface name is naturalized to make it sortable in a proper way. (1,2,10,11,20,21; and not 1,10,11,2,20,21)
The current implementation is not covering all use cases to sort interfaces properly.

By making the function more generic, it could cover more use cases:

output = ''
parts = re.split(r'(\d+)',value.lower())
for part in parts:
    if part.isdigit():
        output += part.rjust(4, '0')
    elif part not in ['.',':','/']:
        output += part

It splits the interfacename into parts with and without numbers. the numbers are pre-padded with zero's and the chars [dot,colon,slash] are removed from between the numbers.
There might be corner cases with mixed number schema's on one device, but it will keep them grouped.

Unless there was a reason why the slot/subslot/position/.. were prepended to the interfacetype, rather then post ?

Use case

On Arista we have interfaces that are split in lanes, without slot/pos/subpos identifiers.

Ethernet1
Ethernet2
Ethernet3
Ethernet48/1
Ethernet48/2
Ethernet48/3
Ethernet48/4
Ethernet49/1
Ethernet49/2
Ethernet49/3
Ethernet49/4

The current rules sorts them as

Ethernet48/1
Ethernet48/2
Ethernet48/3
Ethernet48/4
Ethernet49/1
Ethernet49/2
Ethernet49/3
Ethernet49/4
Ethernet1
Ethernet2
Ethernet3

because the /1 is prepended to the interfacetype, while with non-slashed interfaces, the prepend is 9999

netbox/netbox/utilities/ordering.py

Line 46 in a2203da

def naturalize_interface(value, max_length):

Database changes

All _name fields of all interfaces need to be re-calculated.

External dependencies

No response

[mgoetze5]

While someone is looking at this... on NetApp an "e" is prepended to Ethernet interfaces whereas FC interfaces have nothing prepended. The current sort looks like this:

10a
10b
10c
10d
e9a
e9e
e11a
e11e

but I would prefer:

e9a
e9e
10a
10b
10c
10d
e11a
e11e

[sleepinggenius2]

I have the same issue in two places, but would also need to add '-' to the list of split characters.

On Cisco ASR 9K 1/10G linecards you can specify which interfaces are 1G and which are 10G and the router accordingly labels them as GigabitEthernet and TenGigE, but they currently end up sorted with all the 1G interfaces first, then the 10G ones, and not in proper port order, which is really confusing. With modules now, even putting them all on the same module doesn't fix the sort order.

The other example is on a Cisco ONS 15454/NCS 2K you can have a QSFP+ 4x10G breakout optic inserted that will create something like VCFAC-1-1-1 for the optic and VLINE-1-1-1-1-[1-4] for the individual 10G lanes, except it sorts it so that all the facility interfaces come first, then the line interfaces. In that case, they can even be modeled as child interfaces and that doesn't affect the sort order either.

[PieterL75]

While someone is looking at this... on NetApp an "e" is prepended to Ethernet interfaces whereas FC interfaces have nothing prepended. The current sort looks like this:

10a
10b
10c
10d
e9a
e9e
e11a
e11e

but I would prefer:

e9a
e9e
10a
10b
10c
10d
e11a
e11e

That will be difficult. the order function only knows the interface names, not the underlaying device model.

[DanSheps]

I think there could be some room for improvement, perhaps we have to look at considering how the sort happens when a slot, module, or port are missing.

That said, I think we still need to maintain the sort with the interface type, but perhaps have interface type be sorted just before port (if it isn't already).

Maybe it would make sense for all of these to be individual fields and then have the name be a computed field that is the combination of all fields.

This sort of individual field setup would only work well with most network switches, regular interfaces for the most part, don't have a concept of slot/module.

[PieterL75]

Dan, why would we need to name the parts of an interface and try to fit ?
I think that is we just make the numbers a zero pretended 5 digit number, that all sorting cases work. (Except the one mgoetze5 mentioned).

[jeremystretch]

@PieterL75 you can find the existing tests for the natural ordering of interfaces here. As it has taken several years for us as a community to settle on the current scheme, we will only entertain modifications that do not alter or violate any of the existing tests. Is this something you want to pursue?

[PieterL75]

So, as long as the new sorting returns the same order for the test , we should be good?
The 'calculated' values will change of course, the displayed order must remain the same.

[jeremystretch]

So, as long as the new sorting returns the same order for the test , we should be good?

Provided the proposed change makes sense, yes. It'll also need a new test for the scenario you described above.

[jeremystretch]

The 'calculated' values will change of course, the displayed order must remain the same.

We need to be careful with this. Any changes that would result in recalculating raw names will require that users run renaturalize against all interfaces when upgrading, which is best avoided.

[PieterL75]

Sounds good. Im good to create a PR for this

[PieterL75]

I've been thinking that too, but it might be something that is inevitable and needs to be weighted...
Could (if needed) a migration script take care of that?