[SOLVED] 22.1.4_1: Weird device nomenclature on 11th vlan subinterface

[5SpeedFun]

I just created my 11th vlan subinterface.  And while it works, the device nomenclature (deviceid under  is very odd.

Rather than sfxge0_vlan<x> it's appearing as "vlan01"

See attachments:

[franco]

Hi,

The prefix changed to something more portable in 22.1.4 since we now support stacked VLANs which would break 16 character limit when using e.g. sfxge0_vlanXX_vlanYY.

Prefix "vlan" is used for unstacked, "qinq" is used for stacked. The zero-pad in the numbering is to avoid clashes with manually created devices which are numbered "vlan0", "vlan1", etc.


Cheers,
Franco

[5SpeedFun]

Is there a way to get them all renamed then, to have name consistently (without deleting/recreating them) ?

If not I'll just live with it.  Everything else works otherwise.

[franco]

For the time being we would refrain from touching existing configuration since it entails changing current assignments in interfaces as well, but it's entirely possible to edit the config.xml and and replace all old name references with new ones making sure they don't overlap. Stacked did not exist in the old format so changing all the old ones to "vlan0X" where all these are unique and then afterwards rebooting should do it. But mind you the things may or may not work below 22.1.4 when restoring this configuration for recovery purposes.


Cheers,
Framco

[Layer8]

First of all, QinQ is a nice feature. Thanks for implementation.

But, in my opionion, naming new vlan devices like vlan01, vlan02 and so one is a really bad idea. 

It should be possible to identify the NIC, the outer Q and the inner Q through a meaningful devicename. With the new scheme vlan##, one simply dont know which NIC and inner/outer Q is assigne to the interface when hes whatching in the Assignement-menu. Imagine how work-intensive it is to verify if interfaces are assigned to the correct vlan devices in case of troubleshooting or reconfigurations. For example, we have a installation with around 30 interfaces...

If the main reason is a limitation of 16 chars, just use shorter strings for QinQ/AD-tagging. But first of all, leave the old convention (vmx#_vlan####) for 802.1q-tagging, because this is the established gold-standard for standard vlan devices, which is described in nearly every sense-documentation out there. You create  massive confusion if you change this for Q-tagging-devices.

For 802.1AD-tagging, please use smarter or a total new convention, because there is no established spelling for this. The reason is simple: QinQ is simply not widely spread.




nicN_QQQQinADAD = vmx0_1111in0022 (15 chars)
nicniN_QQQQiADAD = sfxge0_1111i0022 (16 chars)

or, if you think that one will install more than 10 NICs in one server:

nicniNN_QQQQADAD = sfgge10_11110022 (16chars)

OK, i hope, that there are no NICs with 6 chars + N, but i think there will a solution.... Just be creative for QinQ-device-names, but please, leave the device-names meaningful and Q-tagged devices in the old scheme. Thanks.

[franco]

Honestly this is not what is going to happen because I am tired of running into bugs with naming/renaming such as  https://github.com/opnsense/core/issues/3222

If you want to underestimate the effort to maintain integrity across a 16 character limit please be our guest and provide a pull request on GitHub and please be available with a number of work hours through the years when new issues are reported because of your change. Good luck!


Cheers,
Franco

[franco]

Another one here https://github.com/opnsense/core/issues/3120

Basically "_vlan" "_wlan" and "_stf" trickery all suffer from this problem.

[Patrick M. Hausen]

Why don't you use <parent interface>.<vlan id> as the FreeBSD rc system does when using something like

vlans_lagg0="1 2 3 4 5"

?

Kind regards,
Patrick

[franco]

To make the code simpler and less prone to renaming side effects. Adding QinQ we really really really need to avoid renaming interfaces because: the stacked VLAN's VLAN parent name changes which causes two renames...

igb0.12
igb0.12.34

igb0.12 -> igb1.12
igb0.12.34 -> igb1.12.34

And then also fiddle with the assigned interfaces to make this still work on the next boot.

There is a lot that can go wrong. Now or in the future. We don't need these timebombs in the code for everyone's sake.

We can fix all UX visibility issues without supporting arbitrary device names. We have a GUI after all, there is a lot of abstraction underneath and that's ok.


Cheers,
Franco

[Patrick M. Hausen]

Understood, thanks.

I tend to think of interface configuration rather statically. Set once - and reboot after every change.

[anicoletti]

We noticed this change when we were adding additional VLANs to our setup. The reasoning makes sense, just in our use case it causes issues. We relied on the VLAN naming to help us quickly identify the physical port and VLAN# for an Interface in OPNsense. Now when we open an Interface, we have to get the VLAN##, then go under Other \ VLANs and look it up there. What would be beneficial to resolve this issue is if on the Interface display it listed the Parent and Tag on the Device Line. Not sure if that information is easily exposed to that panel or not.