Controller migration - failed?
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Dear All,
experiencing difficulties while migrating from an OC300 to a Windows-based Software controller.
Situation:
- migration from an OC 300 to the Windows-based software controller
- both controllers run the newest version
- both controllers sit in the same network and have a 192.168.0.- IP.
- OC 300 is reachable in the network by 192.168.0.x
- Software controller shows "localhost:nnnn" in the browser and 192.168.0.y in the controller system settings ( an not reach the SW controller from another PC in the same network by, e.g., 192.168.0.y:8046 ( guess that's the port indicated after "localhost") ==> corrected, used he wrong port, software controller reachable
- both controllers are connected to the cloud
- migration runs smoothly until the last step
- both controllers show the Omada devices as "disconnected"
- on the OC300 side there is however a status message "migration" plus an option to cancel the migration in the device tab of the sites controlled by the OC300
- at the side of the SW controller it just says "disconnected"
- that is now the status since more than 1H
- both devices sit behind a Firewall, any ports openings/forwardings needed, perhaps?
Have absolutely no clue why this is not working.
Any ideas welcome ...
Thanks, Thomas
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Eg64 wrote
Hello @Hank21,
Thanks for your reply!
Yes, I have followed all steps in the section "Controller migration". Forgot to mention that the OC300 controls two sites. Wanted however to migrate the full controller, not individual sites.
The machine running the Software Controller can ping all Omada devices operating in the same network (192.168.0.x); obviously not the ones in the remote location. The two sites are not connected, e.g., by a VPN. Will be configured later.
The software release versions are: 5.13.30.20 on the OC300 and 5.13.30.8 on the Software Controller.
On the Firewall on site A- where both controllers sit - , Ports 29810 - 29814 are open so that the Controller operating on site A can find and communicate wit the Omada devices on site B. Works without any problems. But as both controllers sit in the same environment, ports should not play a role, or?
Yes, have specfied "192.168.0.10" (IP adress of the Software Controller) as migration target in the OC300.
Devices are not migrating. They are visible as "Disconnected" on both sides. On OC300, devices carry an additional "migration" note (can not remember the exact text). Nothing changes, same status even after hours. Am able to stop the migration process on the OC300, which brings the devices back under the control of the OC300. Devices continue to work during that process.
By the way: the Software Controller runs on a Windows 2022 Server, Standard Edition, I.e. no Proxmox, containers, etc. Perhaps anything to configure in Windows Defender/Firewall?
Br´s Thomas
Hi @Eg64
Thanks for confirmation. Could you try to disable the anti-virus or firewalls on the PC that the Omada Software Controller is installed in your network first for checking? You should be able to migrate the devices on site A at least.
If you would rather, you can try to download the discovery utility and try to adopt one of the devices which are managed by OC300 and see whether there is any error.
- Copy Link
- Report Inappropriate Content
@Hank21 , Hi,
thanks for your reply!
As mentioned, the controller runs on a Win Sever, without any specific firewall/anti-virus other than the Windows Firewall/Defender.
Disabled and the local site was migrated. The devices of the remote site still showed "disconnected". Switched the Windows Firewall/Defender back on - all migrated devices showed "missed heartbeat".
Then configured a Windows Firewall/Defender rule allowing ports 29810-29184 to pass. The heartbeat error went away and all devices were shown as connected. Solved.
For site B, I rechecked the port forwarding rule on the external site firewall and reconfigured slightly. Migrated site B then which also worked.
All solved now, thanks. Opening the ports on the local firewall did the magic trick.
Consider the case as closed.
Br's Thomas
- Copy Link
- Report Inappropriate Content
Eg64 wrote
Dear All,
experiencing difficulties while migrating from an OC300 to a Windows-based Software controller.
Situation:
- migration from an OC 300 to the Windows-based software controller
- both controllers run the newest version
- both controllers sit in the same network and have a 192.168.0.- IP.
- OC 300 is reachable in the network by 192.168.0.x
- Software controller shows "localhost:nnnn" in the browser and 192.168.0.y in the controller system settings ( an not reach the SW controller from another PC in the same network by, e.g., 192.168.0.y:8046 ( guess that's the port indicated after "localhost") ==> corrected, used he wrong port, software controller reachable
- both controllers are connected to the cloud
- migration runs smoothly until the last step
- both controllers show the Omada devices as "disconnected"
- on the OC300 side there is however a status message "migration" plus an option to cancel the migration in the device tab of the sites controlled by the OC300
- at the side of the SW controller it just says "disconnected"
- that is now the status since more than 1H
- both devices sit behind a Firewall, any ports openings/forwardings needed, perhaps?
Have absolutely no clue why this is not working.
Any ideas welcome ...
Thanks, Thomas
Hi @Eg64
Had you referred to the Controller migration steps before? And when you set up the controller IP/Inform URL, have you input the IP address of the PC's IP address such as 192.168.0.y? Besides, please try to PING the Omada devices' IP address from the PC, is it reachable?
Meanwhile, please help to confirm the controller version of both the OC300 and software controller.
- Copy Link
- Report Inappropriate Content
Hello @Hank21,
Thanks for your reply!
Yes, I have followed all steps in the section "Controller migration". Forgot to mention that the OC300 controls two sites. Wanted however to migrate the full controller, not individual sites.
The machine running the Software Controller can ping all Omada devices operating in the same network (192.168.0.x); obviously not the ones in the remote location. The two sites are not connected, e.g., by a VPN. Will be configured later.
The software release versions are: 5.13.30.20 on the OC300 and 5.13.30.8 on the Software Controller.
On the Firewall on site A- where both controllers sit - , Ports 29810 - 29814 are open so that the Controller operating on site A can find and communicate wit the Omada devices on site B. Works without any problems. But as both controllers sit in the same environment, ports should not play a role, or?
Yes, have specfied "192.168.0.10" (IP adress of the Software Controller) as migration target in the OC300.
Devices are not migrating. They are visible as "Disconnected" on both sides. On OC300, devices carry an additional "migration" note (can not remember the exact text). Nothing changes, same status even after hours. Am able to stop the migration process on the OC300, which brings the devices back under the control of the OC300. Devices continue to work during that process.
By the way: the Software Controller runs on a Windows 2022 Server, Standard Edition, I.e. no Proxmox, containers, etc. Perhaps anything to configure in Windows Defender/Firewall?
Br´s Thomas
- Copy Link
- Report Inappropriate Content
Eg64 wrote
Hello @Hank21,
Thanks for your reply!
Yes, I have followed all steps in the section "Controller migration". Forgot to mention that the OC300 controls two sites. Wanted however to migrate the full controller, not individual sites.
The machine running the Software Controller can ping all Omada devices operating in the same network (192.168.0.x); obviously not the ones in the remote location. The two sites are not connected, e.g., by a VPN. Will be configured later.
The software release versions are: 5.13.30.20 on the OC300 and 5.13.30.8 on the Software Controller.
On the Firewall on site A- where both controllers sit - , Ports 29810 - 29814 are open so that the Controller operating on site A can find and communicate wit the Omada devices on site B. Works without any problems. But as both controllers sit in the same environment, ports should not play a role, or?
Yes, have specfied "192.168.0.10" (IP adress of the Software Controller) as migration target in the OC300.
Devices are not migrating. They are visible as "Disconnected" on both sides. On OC300, devices carry an additional "migration" note (can not remember the exact text). Nothing changes, same status even after hours. Am able to stop the migration process on the OC300, which brings the devices back under the control of the OC300. Devices continue to work during that process.
By the way: the Software Controller runs on a Windows 2022 Server, Standard Edition, I.e. no Proxmox, containers, etc. Perhaps anything to configure in Windows Defender/Firewall?
Br´s Thomas
Hi @Eg64
Thanks for confirmation. Could you try to disable the anti-virus or firewalls on the PC that the Omada Software Controller is installed in your network first for checking? You should be able to migrate the devices on site A at least.
If you would rather, you can try to download the discovery utility and try to adopt one of the devices which are managed by OC300 and see whether there is any error.
- Copy Link
- Report Inappropriate Content
@Hank21 , Hi,
thanks for your reply!
As mentioned, the controller runs on a Win Sever, without any specific firewall/anti-virus other than the Windows Firewall/Defender.
Disabled and the local site was migrated. The devices of the remote site still showed "disconnected". Switched the Windows Firewall/Defender back on - all migrated devices showed "missed heartbeat".
Then configured a Windows Firewall/Defender rule allowing ports 29810-29184 to pass. The heartbeat error went away and all devices were shown as connected. Solved.
For site B, I rechecked the port forwarding rule on the external site firewall and reconfigured slightly. Migrated site B then which also worked.
All solved now, thanks. Opening the ports on the local firewall did the magic trick.
Consider the case as closed.
Br's Thomas
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 583
Replies: 4
Voters 0
No one has voted for it yet.