Confusing limitation for Omanda on managing switch VLAN

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.

Confusing limitation for Omanda on managing switch VLAN

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Confusing limitation for Omanda on managing switch VLAN
Confusing limitation for Omanda on managing switch VLAN
2020-10-20 01:37:25
Model: T1500G-10MPS  
Hardware Version: V2
Firmware Version: 2.0.6

I see TP-Link released updated firmware for T1500G-10MPS to be compatible with the Omada controller

but when I try to config VLAN on Omada I found a wired limitation that are definitely capable in the standalone mode

why is Omada forcing native network to be untagged?

 

in this picture my native network is vlan 10 and I cannot keep vlan 10 tagged???

native network is the equivalent of the old PVID in the standalone mode and there is no problem to keep traffic tagged on the same VLAN before

 

so now when I try to upgrade my EAP AP in the future I will be in trouble!

the only way for me to get a fix on my current APs is I need to set all of my APs to be on the managed VLAN for them to get assign IPs under the correct subnet so Omada can manage them correctly

 

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, I need to go over all the trouble just to find a way to set these new APs to the correct management VLAN if I do not want to install the discovery tool!!

 

Please have this fixed!!! This is enterprise level gears and such limitation is unacceptable

 

  0      
  0      
#1
Options
5 Reply
Re:Confusing limitation for Omanda on managing switch VLAN
2020-10-21 13:13:04 - last edited 2020-10-21 14:18:17

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?

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  1  
  1  
#2
Options
Re:Confusing limitation for Omanda on managing switch VLAN
2020-10-26 03:04:51 - last edited 2020-10-26 03:05:19

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/

Happy New Year! Meet Us at CES 2023 | Featuring Wi-Fi 7, Omada Business Networking, VIGI Video Surveillance
  0  
  0  
#3
Options
Re:Confusing limitation for Omanda on managing switch VLAN
2020-10-26 14:27:54 - last edited 2020-10-26 14:37:04

 

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.

 

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.

 

 

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#4
Options
Re:Confusing limitation for Omanda on managing switch VLAN
2020-10-28 02:04:31

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.

 

 

This is absolute correct, currently there is no simple way to add new EAPs to the switch because the cotroller is on a different VLAN, if I set the EAP to a management VLAN in the standlaone mode, controller will be able to discover it, but once I click on adopt, the setting in the EAP will be erased and the management VLAN on the EAP will be gone

 

the only way for me right now is to remove the controller from the management VLAN after adopt the EAP and then set the EAP on to the management VLAN again (now the EAP becomes unmanageable because of the subnet change), then set the controller back to the correct management VLAN to correctly manage the EAP

  0  
  0  
#5
Options
Re:Confusing limitation for Omanda on managing switch VLAN
2021-05-03 13:58:00

I vote also for the removal of this limitation. I run also into trouble to setup my switch that should be in tagged management vlan. Definitely you should be able to decide yourself if a network is untagged or not. Forcing it by default makes life harder without any reason....Or at least allow to choose "None" in the Native Network drop down.

  3  
  3  
#6
Options

Information

Helpful: 0

Views: 1688

Replies: 5

Related Articles