OPNsense Forum
Archive => 22.1 Legacy Series => Topic started by: lilsense on March 28, 2022, 08:47:21 pm
-
In the new 22.1, when creating a VLAN, it's not allowed to correctly assign deviceid?
so as an example when one attempts to create VLAN3, deviceId is automatically selected for you as VLAN01 if there are no other VLANs.
One ought to be able to correctly align the two information together.
-
I have also observed this since the latest update. My VLANs created on an older version of OPNsense have sensible deviceid's such as " igb1_vlan22" for VLAN ID 22 on parent interface igb1. This naming makes a lot of sense. I created a VLAN ID 201 today on parent interface igb0 and OPNsense automatically created it with the deviceid of "vlan01" which is not very helpful when I am trying to assign things to it.
Not sure if related, but the latest update also broke my PPPoE configuration and I had to delete my VLAN and PPPoE virtual interface and recreate them (with the same exact settings) to get my ISP connection working again because OPNsense was just sitting there looping PADI/PADO, even after a reboot. This was only after my cronjob to install the latest update 22.1.4_1 fired off last night.
-
https://github.com/opnsense/core/commit/64fb551caa3
The changes are permanent as "igb1_vlan22" is not sustainable for a number of technical reasons:
First and foremost the 16 character limit of network devices which makes stacked VLAN "igb1_vlan22_vlan33" impossible for example. Also, if a parent interface or tag changes the device needs to be renamed and the rename must be carried out in assigned interfaces as well. This is much worse for stacked VLANs where you can't directly edit the parent-parent interface. It's a lot of complexity with bugs slumbering in the depths of the code paths waiting to happen.
FreeBSD ifconfig will create "vlan0", "vlan1", etc. devices by default too and we will now split between "vlan" and "qinq" prefix to make it easier to distinguish stacked VLANs and if you can actually stack one again (the limit is two actually). We use the leading "0" in numbering to avoid clashes with default ifconfig naming as described earlier.
Old names are preserved for the time being but that might change due to mentioned reasons.
Cheers,
Franco
-
Why not just use/pick the tagged ID that the user enters as the deviceId? I do understand the silly naming convention but coming from the networking and coding side you never want to use something and call it something else.
banana = "pickle"
VLAN05 = 99
????
-
Sure, I encourage you to edit the resulting config.xml entry and switch "vlanif" to whatever you prefer. I have to say that for several technical reasons that is a bad idea, but please don't mind that much.
Cheers,
Franco
-
Why not just use/pick the tagged ID that the user enters as the deviceId? I do understand the silly naming convention but coming from the networking and coding side you never want to use something and call it something else.
Because vlan tags aren't unique, multiple interfaces can share the same one, which is where unique sequences come into play. Further more it's easier to cope with changes when "anchors" are fixed.
When it comes to naming and preventing inconsistencies in "data" it might help to take a look at how databases are being designed (https://en.wikipedia.org/wiki/Third_normal_form) as these cope with the same type of problem where changing a name shouldn't lead to changes in related records for example.
-
Thinking of Switching, you'd be incorrect. However, how easily I forgot that OPNsense is a router and interfaces cannot be in the same subnet. :)
So from the perspective of the deviceId vs. tag. I'd highly recommend displaying the tagged information on the Interfaces:Assignments since looking at the VLAN index information is not clear to the configurator what VLAN01, VLAN02, VLAN03 are...
-
https://github.com/opnsense/core/commit/64fb551caa35f83f2c8d47d43d5544cb7590ace6
-
The FreeBSD default for auto-created VLANs is igb0.27, lagg0.2, ... btw.
-
# ifconfig vlan create
vlan0
Nope :)
-
https://github.com/opnsense/core/commit/64fb551caa35f83f2c8d47d43d5544cb7590ace6
I thank you very much. :)
-
# ifconfig vlan create
vlan0
Nope :)
If you put this into /etc/rc.conf:
vlans_lagg0="1 2 3 4"and reboot, you will end up with
lagg0.1
lagg0.2
lagg0.3
lagg0.4
All with the correct vlandev and tag already set.
Kind regards,
Patrick
-
Yes, the rc system does that. I wasn't disagreeing. But since we only use ifconfig ourselves I tried to make it clear which sort of ground rules exist. :)
Cheers,
Franco
-
So I am confused. it seem like I should jus create rc.conf file and do:
vlans_ax0="2 5 33 78 126"
and reboot.
-
If you weren't running OPNsense but stock FreeBSD, yes.
-
Why not just use/pick the tagged ID that the user enters as the deviceId? I do understand the silly naming convention but coming from the networking and coding side you never want to use something and call it something else.
banana = "pickle"
VLAN05 = 99
????
::) - that seems to make a lot of sense, I mean you are not going to have two vlans with the same tag. I am just restoring a client's UTM to new hardware and discovered what @lilsense meant. My VLAN 20 has a device ID of vlan03; see attached. This could be messy when one is onsite dealing with an emergency and in the console trying to match vlan id's with vlan networks.
<side note> awesome job on backup - download config - exports all incl. openvpn stuff - so powerful. Was so proud of this platform when I saw that and everything just works after adding the plug-ins.<end side-note>
How hard would it have been to simply to code the platform to use the inputted tag instead of using a sequential generator. Having symmetry across the naming convention just make simple sense however... I am not a coder/programmer just a glorified end user with 24 years in the business and seen a lot.
Well, lets hope during an emergency support session this doesn't blow up in my face; with the current failure, we were monitoring downtime of the OPNsense router in minutes with the Named Partner of the firm watching over my shoulder as his entire office could not work during tax season.
-
Why not just use/pick the tagged ID that the user enters as the deviceId? I do understand the silly naming convention but coming from the networking and coding side you never want to use something and call it something else.
banana = "pickle"
VLAN05 = 99
????
OMG - I thought this was a little issue but if you do not name / description the VLAN and include the VLAN tag, then the interfaces listing shows the device ID and you cannot tell what the TAG is unless you go into the VLAN section and look.
I get the reasons why not to use the interface reference, I just dealt with it, while I restore the clients configuration on new hardware but this is a messy way to resolve that issue, in my opinion.
Just saying to others who are reading this, make sure you put the TAG in the Description, you are going to be thankful one day ...
LOL - still love the platform but the upgrade to 22.x has been painful - yet I learned a lot restoring to new hardware.
-
Can we stop the ranting now about UX that's already been fixed? If people want to talk about how esoteric and abstract network device names are they can open a new thread in general discussion.
And if people don't give feedback during development releases we gladly receive feedback in community release. That's all there is to it.
Cheers,
Franco
-
Can we stop the ranting now about UX that's already been fixed? If people want to talk about how esoteric and abstract network device names are they can open a new thread in general discussion.
And if people don't give feedback during development releases we gladly receive feedback in community release. That's all there is to it.
Cheers,
Franco
Franco, OPNsense is an awesome platform for many reasons and I spent alot of time looking for a new standard for my clients and chose this over PFsense and other brand named solutions because I saw the potential.
I am sure the development team work very hard to address issues, add function and produce an awesome product overall which for many is free to boot ;)
I am providing critical feedback as a result of having just had to fire fight a situation with a critical failure in the boot process, after the 22.1 upgrade, at a large client where we have a number of VLANs and where I only had console view.
I am not aware of the development cycle or input process, I am busy with business matters not monitoring detailed development aspects; I assume development decisions around networking would follow general standard practices. Suddenly finding out, during a fire fighting critical down event and recovery process, as to these changes is why the reaction and response is coming.
I have not seen how VLANs are listed at the console level yet under the new platform 22.x however I have seen how they are at the GUI level and this is why I provided a visual feedback and comment - mostly for other Users who are starting out or as with me restoring from backup to a new and dis-similar hardware and having to recreate VLANs.
"UX that's already been fixed?" are saying they have addressed this issue? or are you saying that since we are in production release no changes can be made?
My posts are really simply to express shock but mostly to provide guidance as well to those who have not encountered VLANs yet or who are rebuilding like me... that is all.
I love the product and can work around this .. but I can tell you, when you are monitoring down time by the minute ... having to do VLAN ID to interface/tag translation is not fun.. and if adding the vlan tag in the description simplifies things, then let's let people know :)
I thank you for any your support and knowledge you share with the community.
-
I believe there is still a huge confusion here.
I understand the fact that you cannot mix and match tagged and untagged (Native) on a same interface. But does this mean that that once a VLAN is created on assigned to igb0, no other interface can have IP assigned to it, including igb3,4, etc?
-
Don't mix tagged and untagged on the same port. Of course you can run N VLANs on one port tagged and N different ports all untagged. You can even bridge a VLAN with an untagged port to create what would be a port assigned VLAN or an "access port" on a regular switch. Make sure to put the IP address on the bridge interface in that case, same for DHCP and all other services you activate for that VLAN.
The restriction is only due to some peculiarities of the FreeBSD network stack, pf, promiscuous mode (for DHCP) etc.
-
Now this baffles me...
I have one port igb0 default IP and igb1 default WAN.
I went on and created a trunk on igb3, it's not plugged in.Then I created multiple vlans let's say 5, 9 and 16.
When I go on the assignments and create an IP for one VLAN, igb0 is no longer able to use WAN.
-
You need to use a different assignment for your new VLAN and assign an IP from a different subnet than the one used on igb0. You cannot have two interfaces in the same network/subnet/broadcast-domain. That's how IP works. For every product, not just OPNsense.
-
igb0 has defaut IP of 192.168.1.1/24
Vlan 5 has IP address of 10.5.5.1/24
Vlan 9 has IP address of 10.9.9.1/24
VLAN 16 has IP address of 10.16.16.1/24
When I enable any VLAN. the igb0 will no longer able to connect to WAN. As soon as I disable the VLAN, the igb0 is able to connect to WAN.
LOL. Never mind... it looked like a fat fingered IP address... All good now. :o
-
I have not seen how VLANs are listed at the console level yet under the new platform 22.x however I have seen how they are at the GUI level and this is why I provided a visual feedback and comment - mostly for other Users who are starting out or as with me restoring from backup to a new and dis-similar hardware and having to recreate VLANs.
"UX that's already been fixed?" are saying they have addressed this issue? or are you saying that since we are in production release no changes can be made?
I'm saying that if people are not testing development changes for UX we need to fix UX in the community release. It's basically as simple as that. First and foremost we assure that the code will work with the old data and on top we also try to deliver an API and try to rectify some of the technical issues that have been in the product for a decade or more.
Now if we talk about UX it should be noted that *sense/m0n0wall is a GUI-based appliance so we need to focus UX on the GUI part and will fix such things as missing context in the assignments page with the tag/parent information which will be added in 22.1.5. Note that this particular issue is a historic oversight which can't be described as explicitly designed this way because the device happens to be named according to parent and VLAN tag. The explicit design, however, is that a description can be set by user and that doesn't seem to be used a lot in contrast.
If there are further UX issues/uncertainties it's likely easy to fix without talking about device names and these will be dealt with rather swiftly like with the mentioned issue.
Now, going from GUI to CLI is a different beast. We did introduce descriptions for ifconfig output so you can find your assigned interfaces more easily:
# ifconfig igb1
igb1: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: WAN
[...]
Has anyone commented on this? No, not at all. We could add the same approach for unassigned VLANs, but that would imply using the description provided by the user in the first place, wouldn't it? ;)
I get that VLANs are likely the primary device type users work with on a daily basis, but I'm unaware of any "hardship" in dealing with them that stem from not having a device name that boarders on technical breaking point (character limit, shifting name on changing parent or tag). If such an issue exists we need to wait more than a couple of days to act on it, because sometimes we just don't like new things that are like the old things but break our routine more than we are comfortable with today.
Cheers,
Franco
-
First of all I want to thank all the dev team at OPNsense for such a great product. Also I would like to justify that most of us using this product in our professional environment, sadly lack time to be testing the new releases before they go community.
While I understand the reasons behind this change, I'm still not fully satisfied with them. I'm now having a salad of interfaces output @ cli/gui. See below screenshot.
Franco, you've mentioned this might be addressed in a future patch. Would it be possible to give us the option to choose old naming convention/new naming convention somehow on GUI level? For obvious reasons you say is possible to do so via config.xml edit but is not really the best way to go.
Thanks for your patience with us, end users :) Hope you appreciate our feedback even when is not what you'd expect from time to time.
-
I'm not sure what you imply with the screenshot. If I print the primary key column of a database it doesn't make much sense either. Only in combination with the other columns it starts to make sense.
Cheers,
Franco
-
I believe he's talking about the VLAN01 thru 05. I don't believe he's using those vlan numbers.
-
Yes but why crop the screenshot and leave out the actual information next to it using it as a "proof" it's missing context?
I'm just not sure if this shows that there is a problem with that particular GUI page when in reality all the info is there.
Cheers,
Franco
-
Basically all lagg0_vlan3XYZ were created before the new convention was in place, the other VLANXY ifaces are created recently since new convention has become standard.
This, as discussed before doesn't make much sense for end use and doesn't get along with legacy interfaces. I've cropped the picture because I don't feel the need to share more information to make this point.
In GUI is ok because you still have the descriptions of the interfaces as main guidance to know where you are moving around, but in CLI (when you are in a hurry/panic situation) things get messy, especially if you have a salad of interfaces like I ended up having at the moment. Hence, my request to consider allowing us via some GUI option to stay in old naming convention and embrace the potential issues that lead you guys to make this naming convention change.
Not all environments are going to run with stacked vlans, this change is quite niche but affects us all, IMHO.