SG3452 disables "OMADA Management" settings by itself or buggy OMADA infos - recovery is a mess
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Dear OMADA gurus,
i have a scenario with a SG3254, OMADA on DEBIAN , a couple of other OMADA switches and some EAPs. So far all went very good. I used all available LAGG on the SG3452 groups with LACP to connect ESX, Proxmox, Firewall, etc. A number of VLANs, etc. etc. All of a sudden - during a configuration the SG lost connection to the OMADA controller (5.0.30). After some research to ensure that is is not a VLAN config failure I took a look with console / CLI and ...
=> CLI shows up with - Cloud-Based Controller Management: Disabled - magically change of this parameter ...
Network is running without any problems with the current configuration while the switch is disconnected - reboot(s) no change - so no chance to put the SG back into OMADA. The issue here is that it is impossible to put the Paramter back to the right direction because if the switch is under OMADA Control you can't access the appropriate config mode in CLI. So this is a catch22 situation.
As I had daily OMADA Backups I thought to go with a reset of the Switch via CLI and recover the last good known running config. Therefore I prepared a "special" subnet / DHCP / etc. with the appropriate Parameter so that the SG could find the OMADA after reset based on the device factory network 192.168.0.x/24. But the problem is after resetting the SG with all the LAG / LACP cabling the switch totally go crazy with >90% CPU load according to the "now" messy cabling if the switch comes up fresh from the reset.
Even trying to set quickly the respective ports down with CLI is in fact not possible because the SG CPU is > 90% and not really responsive at all. So the solution is to plug out most of the cables and then start the recovery procedure.
After understanding all this the recovery worked but as a conclusion I would like to state two things:
1.) Why or under which conditions does the Switch change the OMADA Paramter and drop itself out of the game - I would say > heavy BUG
2.) In case of recovery needs there should be some kind of accessible settings via CLI even the device is under OMADA control or a kind of boot/rescue mode with putting ip/dns/gateway, may be to de/activate ports for rescue procedure to avoid switch load because of the cabling issue which are good for original configuration OMADA settings in. Being forced to plug out all cabling is a mess. Funny enough firstly I picked a too young backup file where the switch went from adopting => configuring to disconnected - sp the same procedure again with all the cable mess. So I would suggest something strange happens or is in the config file.
These are my 2 cents
Any fruitful feedback would be highly appreciated.
Kind regards: a still convinced OMADA user ;-)
Hello John1234, please find my anserws inline in yours...
John1234 wrote
Ah. Can you reproduce this with the same steps? I don't quite understand some parts.
If the switch is under the Omada, and you cannot set it up anyway, you can simply reset the switch. Or forget the switch via the Controller(this equals a reset) Your settings/configs are saved on the Controller. You don't have to worry.
***
Basically You are right, but the issue is that the switch configuration could not being recovered by reset to load the recent config from the controller due to the fact as I described the switch has "switched" to => CLI shows up with - Cloud-Based Controller Management: Disabled. So there is a catch22 situation.
1.) the switch moves into a mode where OMADA Control is switched off, access via HTTP is not possible (it says - controlled by OMADA (haha) , If I reset the switch transferring the recent config from the controller has no effect - because, it seems the parameter to disable the OMADA control enablement is also transferred after the switch moved into discomnnected.
Basically there could be no configuration issue in terms that I doing something to lose the connection - why? - there are a could of other switches and APs connected to this switch. Funny enough all devices work according to their configuration, even the disconencted switch, but I have no chance to reach the device anymore
Asking me what I have done before this situation came up - I have a quite straightforward configuration with some VLANs, LAGG groups, RADIUS profile, but only for WiFi... From my point of view the situation came up when I deleted a VLAN (in fact not the management VLAN ;-)) which was not used anymore. May be there is an issue ... I didn't disable this particular VLAN from the profile it was used - I just deleted it from the network section aassuming that it is consequently removed from all the profiles regardles it is used as tagged or native.
So all in all it must not be possible that the switchs locks up in a way to disable the Cloud Management as I have seen looking into the CLI paramters. and there is no possiblitly to recover this without resetting. The only way is user an older backup before the change was made. For me a clear bug simply that the system could run in a kind of locked down situation. If there is a possibility to provide the OMADA config File to TP-Links system Enginners / Support for decoding an analyzing I would support this. If made a couplke of different, even some bigger customer OMADA INstallation with up to 30 Switches and/or 70 APs but as this behavior is something which every installation has as an sleeping inside risk, I would be very scared.
I will put some screenshots to give You some Impresseion about the network....
Regards
This picture shows how it is seen with the disconencted switch
"The issue here is that it is impossible to put the Paramter back to the right direction because if the switch is under OMADA Control you can't access the appropriate config mode in CLI"
Do you mean that you want to access your config on the switch? No. You should do it on your controller. Adopt the switch to the controller equals a reset, a fresh start. Reset/forget a device from the controller is the same.
Default IP of the switch is under the L3 features > interface > IPv4. Default IP should be 192.168.0.1 static, you can make it to DHCP or change it to another IP address.
+
About your high CPU usage, are you describing that you have high usage when you swapping with different cables? If so, that sounds okay to me. Like your PC boots up or do some heavy load tasks, that will definitely have high usage. If you have high usage and no matter what you do, even your device is idle and now devices are connected or sending packets, that is legitimately abnormal. That should be considered as some kinda serious issue.
You have to plug all the cables out and start the recovery. I begin to suspect that you may have some trouble with the config?? Like the first sentence I said, can you reproduce this every time? If so, and you are certain about your config's 100% good, the switch takes the fault on that.
At most, you can share the config with the community. People can look it up and find faults in the config.
