Hello pixielark,

I absolutely agree with you that it is a very bad idea in SDN Controller to enforce a certain policy for managed switches at the expense of a general mechanism available in the same switch if not being managed by SDN Controller. Enforcing policies is the Windows way of doing things and in case of a »native VLAN« it's wrong in my opinion. Enforcing policies is a no-go in UNIX/Linux ecosystems, which are by far the preferred operating systems for Internet servers.

»Native VLANs« had their use case when migrating non-VLAN networks to VLAN networks without interruption of services, but that's been long time ago. Modern VLAN networks don't need a »Native VLAN« at all (not to be confused with a »Default VLAN« to which yet unused switch ports are assigned to by default). Maybe some users want to still use »Native VLANs« and they should still be able to do so if they want, but enforcing them is counterproductive in my opinion.

pixielark wrote 

Now imagine if I want to upgrade all my current APs to the new WIFI 6 APs, I plug the new ones in the same port, Omada won't be able to manage them because by default new APs does not have proper management VLAN set

That's right. It even makes things more complicated when using a Management VLAN and just adding more EAPs, which have not (yet) set the Management VLAN. We need to add switch ports as untagged members of the Management VLAN to be able to adopt new EAPs and then the switch port must be set to a tagged member to complete the configuration process after the EAPs have been provisioned and Management VLAN setting is in effect.

So, add my vote to the feature request to allow setting switch ports as untagged/tagged members of a Management VLAN.

Dear @Fae, any comments on this? How are we supposed to add EAPs with factory settings to a Management VLAN in SDN Controller if the switch is managed by the controller?

Dear @R1D2,

add my vote to the feature request to allow setting switch ports as untagged/tagged members of a Management VLAN.

Thank you for your valued feedback. I've forwarded this feature request to the engineer for further evaluation.

How are we supposed to add EAPs with factory settings to a Management VLAN in SDN Controller if the switch is managed by the controller?

To add EAPs with factory settings to a Management VLAN when the switch is managed by the SDN controller, you could select the management VLAN as Native Network first, getting the Controller to discover and manage the new EAPs, then set the management VLAN for the new EAPs and modify the profile for the switch ports that are linked to the EAPs accordingly.

Sorry for any inconvenience caused. Any additional feedback, please do not hesitate to leave your comments.

BTW, For anyone who may have trouble configuring the Management VLAN with Omada SDN Controller, here is an instruction for your reference.

https://www.tp-link.com/support/faq/2814/

Fae wrote

To add EAPs with factory settings to a Management VLAN when the switch is managed by the SDN controller, you could select the management VLAN as Native Network first, getting the Controller to discover and manage the new EAPs, then set the management VLAN for the new EAPs and modify the profile for the switch ports that are linked to the EAPs accordingly.

thaks for your reply, but IMO this won't work since OC200 can be an untagged member of only one VLAN.

My point is not to create a Mgmt VLAN after adoption of all EAPs, my point is how to add additional new EAPs to an existing Mgmt VLAN. Ok, I can add new EAPs to an untagged native VLAN. But the OC200 is an untagged member of the existing Mgmt VLAN, not of the native VLAN.

The way an additional EAP is added to an existing Mgmt VLAN on a standalone switch is as follows (assume Mgmt-VLAN 100, EAP connected to switch port #7):

1. Define switch port #7 an untagged member of Mgmt VLAN 100.
2. Set PVID for port #7 to 100.
3. Turn on the EAP, it will reach state »Pending«.
4. Adopt EAP, it will be provisioned. Now the Mgmt VLAN is set in the EAP, the EAP starts to transmit tagged traffic from now on.
5. Change switch port #7 to be a tagged member of Mgmt VLAN 100, PVID becomes irrelevant. Configuration succeeds, the new EAP changes to state »Connected«.

Now, if I understand correctly, the only way to set a PVID for a trunk port in SDN Controller is to define a native VLAN and bind it to the network the trunk port is a member of, right?

So how can we accomplish step #2 above: set PVID=100 for the port #7, which must be member of the Mgmt VLAN in order to allow OC200 to send data to the EAP?

Correct me if I'm wrong, but to define a native VLAN whose VLAN ID will be used as the PVID for the Mgmt VLAN 100 trunk, I cannot use VLAN ID 100, right?

BTW, For anyone who may have trouble configuring the Management VLAN with Omada SDN Controller, here is an instruction for your reference.

https://www.tp-link.com/support/faq/2814/

I did read this FAQ before several times already. In my opinion there is no isolation of EAPs in the Mgmt VLAN from clients, since the FAQ suggests to add a routable VLAN as the Mgmt VLAN (by selecting »Interface« instead of »VLAN«). Of course it almost certainly does so because clients need to reach the Omada Controller's portal residing in the Mgmt VLAN.

But then without »Block« ACLs for every other device in the Mgmt VLAN (and we have usually many more devices in the Mgmt VLAN, not only Omada devices), clients can indeed access devices in the Mgmt VLAN, since it's a routed VLAN.

How do we solve this with a non-SDN router?

We create a fully isolated Mgmt VLAN and use a stateful firewall such as iptables/netfilter on the router to allow initial connects from clients to the Omada Controller's portal only. No messing around with ACLs or routed VLANs.