What I want to express here is whether this process can be separated or simplified. My needs do not conflict with the standards or openwrt definitions you mentioned. Compliance with standards should not be contradictory to the ease of use.
1 Like
I wonder if the VLAN Filtering can be disabled to produce the user's desired affect?
Edit:
Also, the you may be able to bridge the VLANs to a [different] VLAN or PHY (e.g. bridge VLANs 1 and 2 to VLAN 3 or another ethx). I don't want to elaborate because I'm not sure it's a documentation config - even at the Linux level. I only know from seeing the behavior accidentially from personal configuration and thru witnessing the same from others on this forum.
In fact, it is not that the existing method is completely impossible to implement. It is nothing more than creating more than 4,000 new vlan ids and then configuring rules for each interface separately. The focus here is that this configuration process is unreasonable. This configuration method is not suitable for application scenarios with multiple vlan ids. The configuration file will be extremely large after configuration according to the process, which is inconvenient to intuitive management at all. Common switch trunk ports generally do not need to be pre-configured. Secondly, when configuring multiple lines can be configured at one time according to the scope, for example: 5, 8, 9, 10-100
Linux needs to have each vlan id configured on an interface.
And OpenWrt Luci is only parsing the UCI config and does not reflect the current running state.
As you need to configure each vlan interface anyway I don't see how you would or could do this "Auto set each and every vlan id" in any sane way ATM.
Again you miss that Linux does not work as a network oa based on Cisco ios or juniper.
If you use cumulus Linux or ms sonic then it is a totally different story because these Linux distributions have their own user space tools and wrapper for these kinds of configs where you can configure a trunk port for all vlans or are able to use a vlan range. But the current config model of openwrt does not support it.
And if you have more then 5 vlan like many here in the forum then write scripts or templates and prepare all config files and sync them to the router/AP or bake it into the image.
I don't think this is a problem brought by Linux, because openvswitch(ovs) also runs on the Linux system, but without as many problems as you mentioned, I think more about the limitations of openwrt positioning and its own unwillingness to improve. If I still stay at whether it is standard, whether Cisco has truly implemented this function and is unwilling to refer to other mature product functions, there is no need to continue discussing it. After all, the functions I am talking about are implemented by many products and are actually needed in many scenarios. These are not something I have seen out of thin air.
Let's go back to something important...
Or is the issue that you don't actually know the VLAN IDs of the upstream connection?
That's not a "standard", it's only a way how to do the configuration.
I imagine, managing an environment with more than 1000 vlans could be confusing in the openwrt's way.
This reply has correctly understood the most core part of my needs.
1 Like
Openvswich is a totally different thing.
Can we please stick with one topic and do not mix everything together?!
Btw then just use an other product or make your self familiar with the difference but please for fukk sake dream about something which is simply not possible because the Kernel behaves totally different
ovs and openwrt are indeed not the same thing, but ovs is a switch running on Linux, which can be explained that linux does not have the problems you mentioned. In fact, my needs have always been clear, and some people have understood my needs in reply, such as: rwalli #15. Many replies focused on whether the standard, whether Cisco has implemented it, etc., and turned a blind eye to other product functions in reality, and it was all about it. I no longer want to discuss this requirement, it has no value.
1 Like
The fact it's not a standard is the core part of our confusion.
Feel free to test this, but I also noted (and others) the same:
Feel free to hazard a guess and produce a working config. A lot of the steps are indeed functional if you do so in Linux and in OpenWrt configs at that level of abstraction. But none of what you're describing is documented "Internet standard" (i.e., RFC), and is not generally supported [anywhere] - save where it's documented. 
Proceed at your own risk.
I imagine, managing an environment with more than 1000 vlans could be confusing in the openwrt's way.
I think the next paragraph should be the focus
1 Like
Cool, OK. I have less than a paragraph:
This is a very important question.
Why do you need the VLANs to end up/exist in one broadcast domain?
Routing is the solution to this (after they've been divided into VLANs).
It also can cause issues.
First of all, this passage itself highlights the situation where existing implementation paths are not conducive to managing multiple vlans. Secondly, the question you asked is just to deny this requirement, not in the direction of improvement. And my speech has stated many times before that this requirement is required in many scenarios, and it has also been implemented by many products. It is not a sudden idea. If this is not understood, then I don’t know how to explain it. If you are an administrator, please end this topic, I don’t want to continue discussing it.
Openvswich does not use most of the Kernel implementation of most layer 2 stuff.
A Linux bridge has nothing in common with an openvswitch bridge.
1 Like
If you have more then a handful of vlans then do it as everyone else use a template engine and a script.
Be it, that you write the whole config file or loop over UCI instances.
1 Like
I am closing this thread since it is no longer productive.
The OP has stated a requirement that cannot (and will not) be met by OpenWrt. It seems that the best solution for the OP is Cisco and/or OpenVSwitch, or the (few) other switch vendors/firmware out there that support this "pass all VLANs without specifying them" type of setup.
2 Likes