Home
Help
Search
Login
Register
OPNsense Forum
»
Archive
»
22.1 Legacy Series
»
[SOLVED] 22.1.4_1: Weird device nomenclature on 11th vlan subinterface
« previous
next »
Print
Pages: [
1
]
Author
Topic: [SOLVED] 22.1.4_1: Weird device nomenclature on 11th vlan subinterface (Read 4727 times)
5SpeedFun
Full Member
Posts: 119
Karma: 7
[SOLVED] 22.1.4_1: Weird device nomenclature on 11th vlan subinterface
«
on:
April 13, 2022, 12:10:13 am »
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:
«
Last Edit: April 22, 2022, 04:10:37 pm by 5SpeedFun
»
Logged
franco
Administrator
Hero Member
Posts: 17619
Karma: 1605
Re: 22.1.4_1: Weird device nomenclature on 11th vlan subinterface
«
Reply #1 on:
April 13, 2022, 09:27:35 am »
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
Logged
5SpeedFun
Full Member
Posts: 119
Karma: 7
Re: 22.1.4_1: Weird device nomenclature on 11th vlan subinterface
«
Reply #2 on:
April 13, 2022, 12:13:06 pm »
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.
Logged
franco
Administrator
Hero Member
Posts: 17619
Karma: 1605
Re: 22.1.4_1: Weird device nomenclature on 11th vlan subinterface
«
Reply #3 on:
April 13, 2022, 01:46:10 pm »
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
Logged
Layer8
Full Member
Posts: 193
Karma: 4
Re: [SOLVED] 22.1.4_1: Weird device nomenclature on 11th vlan subinterface
«
Reply #4 on:
April 26, 2022, 10:58:22 pm »
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.
«
Last Edit: April 26, 2022, 11:06:22 pm by Layer8
»
Logged
franco
Administrator
Hero Member
Posts: 17619
Karma: 1605
Re: [SOLVED] 22.1.4_1: Weird device nomenclature on 11th vlan subinterface
«
Reply #5 on:
April 27, 2022, 08:15:31 am »
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
Logged
franco
Administrator
Hero Member
Posts: 17619
Karma: 1605
Re: [SOLVED] 22.1.4_1: Weird device nomenclature on 11th vlan subinterface
«
Reply #6 on:
April 27, 2022, 08:25:10 am »
Another one here
https://github.com/opnsense/core/issues/3120
Basically "_vlan" "_wlan" and "_stf" trickery all suffer from this problem.
Logged
Patrick M. Hausen
Hero Member
Posts: 6709
Karma: 565
Re: [SOLVED] 22.1.4_1: Weird device nomenclature on 11th vlan subinterface
«
Reply #7 on:
April 27, 2022, 09:05:47 am »
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
Logged
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do.
(Isaac Asimov)
franco
Administrator
Hero Member
Posts: 17619
Karma: 1605
Re: [SOLVED] 22.1.4_1: Weird device nomenclature on 11th vlan subinterface
«
Reply #8 on:
April 27, 2022, 09:38:35 am »
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
Logged
Patrick M. Hausen
Hero Member
Posts: 6709
Karma: 565
Re: [SOLVED] 22.1.4_1: Weird device nomenclature on 11th vlan subinterface
«
Reply #9 on:
April 27, 2022, 09:43:25 am »
Understood, thanks.
I tend to think of interface configuration rather statically. Set once - and reboot after every change.
Logged
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do.
(Isaac Asimov)
anicoletti
Newbie
Posts: 36
Karma: 2
Re: [SOLVED] 22.1.4_1: Weird device nomenclature on 11th vlan subinterface
«
Reply #10 on:
April 27, 2022, 04:24:19 pm »
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.
Logged
Print
Pages: [
1
]
« previous
next »
OPNsense Forum
»
Archive
»
22.1 Legacy Series
»
[SOLVED] 22.1.4_1: Weird device nomenclature on 11th vlan subinterface