Moving from standalone to OMADA controller (with management VLAN)

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

Moving from standalone to OMADA controller (with management VLAN)

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Moving from standalone to OMADA controller (with management VLAN)
Moving from standalone to OMADA controller (with management VLAN)
2022-05-05 09:55:26 - last edited 2022-05-06 07:17:55
Model: EAP660 HD  
Hardware Version: V1
Firmware Version: 1.1.0 Build 20211027 Rel. 35153(4555)

Hello,

 

I have a working EAP660 HD running in standalone mode. I have Installed a OMADA controller and want to start managing my EAP using it and unfortunately I'm facing some issues. Maybe you can help me.

 

The context:

 

  • the (software) controller is connected to a (non TP-Link) switch which is connected to a (non TP-Link) router which is connected to the EAP
  • the controller is connected to the switch through an access port which is tagged with management VLAN id
  • the EAP is connected to the router through a trunk port, which carries VLANs required for the different SSIDs and the management VLAN
  • "management VLAN" setting is activated on the EAP with the correct VLAN id
  • the EAP gets an IP address from a DHCP server dedicated to management VLAN
  • Layer 3 accessibility is activated on the EAP (so I can reach the management web page)
  • the controller and the EAP are on the same (management) VLAN
  • prior to "adoption" the controller sees the EAP (it's in the list of "pending" APs)
  • prior to "adoption" the controller can ping the EAP
  • As said above, the EAP is working perfectly in standalone mode.

 

What I'm experiencing:

 

When I click on "adopt" on the controller:

  • the EAP status moves from "pending" to "configuring" then after a while to "disconnected".
  • on the controller's logs there is only a single line stating that the EAP was disconnected
  • The EAP is then unreachable using ping(nor web interface) be it from the controller, nor directly from the router or any device on the managment VLAN.
  • On the DHCP servers, I see no lease for the EAP.
  • On EAP side the blue led is turned on and blinks (off-on) once every now and then.
  • On firewall logs I see nothing wrong

 

My guess is that "adopting" disables the management VLAN setting on the EAP and in turn the EAP cannot get an IP address from the DHCP server.

To have access to the EAP again, I have then to reset it, reconnect it to a non trunk port... already tried twice and lost lots of time.

 

I must be doing something wrong.

 

My request:

 

Can you please help ? How do I have to proceed to make it work (i.e. to make the EAP use the management VLAN once "adopted") ?

 

Thanks in advance

  0      
  0      
#1
Options
1 Accepted Solution
Re:Moving from standalone to OMADA controller (with management VLAN)-Solution
2022-05-05 16:24:44 - last edited 2022-05-06 07:17:55

  @kraal 

 

Ok, but you could temporarily plug it into an untagged port on the switch or router...adopt it there, unplug it, change the config profile, and then plug it into it's proper tagged port.  Speculation...havne't (yet) done this myself.

<< Paying it forward, one juicy problem at a time... >>
Recommended Solution
  2  
  2  
#6
Options
7 Reply
Re:Moving from standalone to OMADA controller (with management VLAN)
2022-05-05 10:07:30 - last edited 2022-05-06 07:17:39
When adopting the Management VLAN must be untagged on the switch. Once adopted you can then go to the AP and go to Config and set the Management VLAN setting. Then at this point change the port on the switch to be Tagged on the Management VLAN. You cannot adopt with the Management VLAN Tagged in my experience.
  2  
  2  
#2
Options
Re:Moving from standalone to OMADA controller (with management VLAN)
2022-05-05 10:32:41
Ok I will try to do it this way this evening (can't do it right now as the EAP is in use). Thank you !
  0  
  0  
#3
Options
Re:Moving from standalone to OMADA controller (with management VLAN)
2022-05-05 15:22:43

  @kraal 

So, through a combination of laziness and lack of service windows and the HUGE PITA it is to climb up and reach my EAP225-outdoors to reset them (like when I bobbled the transition from Laptop controller to OC200), I have not yet enabled my mVLAN.  However, it would seem to me that you could pre-configure the AP prior to adoption with a management VLAN (and all the other bits like SSID profiles) even if it's not plugged in.  That way, when the initial Configuring push happens, it should also push the mVLAN and avoid isolating your AP.

 

Here's an AP that's in my spares box, it's already 'known' by the system, but definitely offline.  I can adjust the Config settings prior to (re)deploying it.

 

<< Paying it forward, one juicy problem at a time... >>
  0  
  0  
#4
Options
Re:Moving from standalone to OMADA controller (with management VLAN)
2022-05-05 16:20:24 - last edited 2022-05-06 07:17:32
Hi, The problem is that the "config" tab is not available until I "adopt" the device. And once adopted, it becomes unreachable. I'll try to untag the port first.
  2  
  2  
#5
Options
Re:Moving from standalone to OMADA controller (with management VLAN)-Solution
2022-05-05 16:24:44 - last edited 2022-05-06 07:17:55

  @kraal 

 

Ok, but you could temporarily plug it into an untagged port on the switch or router...adopt it there, unplug it, change the config profile, and then plug it into it's proper tagged port.  Speculation...havne't (yet) done this myself.

<< Paying it forward, one juicy problem at a time... >>
Recommended Solution
  2  
  2  
#6
Options
Re:Moving from standalone to OMADA controller (with management VLAN)
2022-05-05 17:10:33
That's what I did. And now it's working. I'm just wondering how to achieve this with lots of APs. Thank you all for your help.
  0  
  0  
#7
Options
Re:Moving from standalone to OMADA controller (with management VLAN)
2022-05-05 17:40:23 - last edited 2022-05-05 17:40:56

Glad to hear you got it working...feel free to click the useful post triangle :) )

 

In my case, I kept the default subnet and VLAN (192.168.0.0/24 and VLAN 1) as my management LAN, untagged, and I just moved all my client subnets onto their own VLANs and tagged them and added some ACLs to prevent them accessing the 'management' (and each other's) VLAN/address space. This approach I think is more suitable when the controllers such as the OC200 don't play nice with tagged traffic and/or new APs that need untagged access to get their initial configs.

<< Paying it forward, one juicy problem at a time... >>
  2  
  2  
#8
Options