jedigrover wrote

I have read the FAQ at https://www.tp-link.com/us/support/faq/2814/

 

I have a few questions now.

 

I have an established non-Omada network on 192.168.1.x, which I wish to migrate to Omada (router, controller, switches, etc.).

I already have 3 EAP-225v3 on my existing network, that I will adopt in once I move over.

I started setting up the Omada gear (adopting, etc.) separately, on a bench, not connected into my existing LAN or the WAN.

I got everything (router, controller, 4 switches) adopted in, firmware updated, etc.
It is configured with LAN on 192.168.0.x as default.
I have not setup any VLANs yet.

My desired setup is:
Main LAN on 192.168.1.x
Management VLAN on 192.168.0.x
Other VLANs as I build out, not really germane to this discussion.

 

So the first thing I planned to do was move LAN to 192.168.1.x, which is where I want it to end up.  Then I need create the management VLAN and move the Omada gear onto that.

 

@jedigrover 

Yes. You are doing this right. 

I think I understand the FAQ, but since I'm setting up "fresh", could I disassociate & then factory-reset the router, then setup Mgmt VLAN on the controller & switches,
and then adopt the router again once I've setup the Management VLAN?  Would that be easier than having to run the Discovery Tool?  Since it comes up by default in 0.x, would it be "seen" by the controller (even though it doesn't have the mgmt vlan tag) and able to be adopted?  

Then I could go enable management vlan on it?

Or is there a need to use the discovery utility anyway?

 

Or is it better to change the LAN IP range, go ahead and switch over my network, adopt my EAPs, and then go through the process to enable Mgmt VLAN?

 

Your understanding is also right. Run the utility because the management VLAN is in another subnet. The condition for the controller to discover the devices is LAN broadcasting packets. It cannot do a cross-network discovery without the help of the discovery utility. 

So, in the end, when you run the utility, you are doing a batch adoption. Telling the devices the IP address of the controller so that they can link to each other. 

I think first quote is the right understanding to this. You do the first quote and follow the instructions from the FAQ and it'll be good.

  @John1234

The end state after this FAQ is unclear to me.

I understand the controller, switches and APs end up in the management VLAN.

Q1: Does the gateway stay in the default LAN (merely informed of the IP of the controller via step 5)?

Q2: Assuming the answer to Q1 is true, does the gateway show up in the controller's management UX or does it appear as disconnected because the controller and gateway are not in the same network?

I actually tried to follow the steps in the FAQ once and managed to lock myself out with an ACL...

I was starting fresh so I reset everything (ER605, 2x SG2008, OC200, EAP245 all recently purchased) and reconfigured from scratch.

I might try to set this up again but I'll do a settings backup first this time!

This said, I have chosen a slightly different option.

I changed the IP range of the default LAN and created VLANs and corresponding SSIDs for each group of devices (per 3091 FAQ).

So at this point, the only devices left in the default LAN are the tp-link devices above (and for now the PC I use to manage the OC), and all my end devices are in their respective VLANs. Given this state, the OC management UX clearly has visibility into the gateway.

I have not yet configured switch ACLs for VLAN isolation.

Q3: Is this approach significantly different from the management VLAN approach (2814 FAQ)?

Q4: Am I going to run into switch ACL issues because the gateway is included in the default LAN?

In other words, the destination can not be the entire LAN network, but maybe an IP group excluding the gateway?

[Disclaimer: noob at all this, but I'm doing this to learn]