Reboot schedules are not EAP215-Bridge friendly.
This is my configuration:
ER7212PC---PoEinjector---EAP650-Outdoor
---PoEinjector---EAP215-BridgeAP >>>WiFi<<< EAP215-BridgeClient---PoEinjector---PoEinjector---EAP610-Outdoor
*Traffic traveling from EAP650-Outdoor to EAP610-Outdoor through the bridge.
After a scheduled reboot:
ER7212PC---PoEinjector---EAP610-Outdoor >>>Mesh<<< EAP610-Outdoor
---PoEinjector---EAP215-BridgeAP >>>WiFi<<< EAP215-BridgeClient---PoEinjector---PoEinjector---EAP610-Outdoor
*Traffic traveling from EAP650-Outdoor to EAP610-Outdoor via mesh.
The only sequence that fixes this is to forget both ends of the bridge (EAP215-BridgeAP and EAP215-BridgeClient), and the EAP610-Outdoor. Reprovision the bridge EAP215-BridgeAP first, reprovision the EAP215-BridgeClient second, and then reprovision the EAP610-Outdoor. The bridge kit does not like scheduled reboots. I hope TPL can do something about this.
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
This is mostly because the EAP610-Outdoor detected the EAP650-Outdoor signal before it detected the wired connection of the EAP215 bridge. In another word, the EAP610-outdoor was successfully meshed with the EAP650-outdoor before the EAP215 bridge KIT was successfully connected.
Suggestion:
1. Set the Tx power of EAP650-outdoor lower, so that the EAP610-outdoor won't mesh with it. But this will also reduce its wireless range.
2. Set different reboot times for these devices. For example: EAP650-outdoor reboot at 1AM every day, EAP215-bridge KIT reboot at 2AM every day, and EAP610-outdoor reboot at 3AM every day. I believe this will avoid this issue.
I would recommend suggestion 2 more.
- Copy Link
- Report Inappropriate Content
This is mostly because the EAP610-Outdoor detected the EAP650-Outdoor signal before it detected the wired connection of the EAP215 bridge. In another word, the EAP610-outdoor was successfully meshed with the EAP650-outdoor before the EAP215 bridge KIT was successfully connected.
Suggestion:
1. Set the Tx power of EAP650-outdoor lower, so that the EAP610-outdoor won't mesh with it. But this will also reduce its wireless range.
2. Set different reboot times for these devices. For example: EAP650-outdoor reboot at 1AM every day, EAP215-bridge KIT reboot at 2AM every day, and EAP610-outdoor reboot at 3AM every day. I believe this will avoid this issue.
I would recommend suggestion 2 more.
- Copy Link
- Report Inappropriate Content
@Vincent-TP this worked, thank you.
Vincent-TP wrote
This is mostly because the EAP610-Outdoor detected the EAP650-Outdoor signal before it detected the wired connection of the EAP215 bridge. In another word, the EAP610-outdoor was successfully meshed with the EAP650-outdoor before the EAP215 bridge KIT was successfully connected.
Suggestion:
1. Set the Tx power of EAP650-outdoor lower, so that the EAP610-outdoor won't mesh with it. But this will also reduce its wireless range.
2. Set different reboot times for these devices. For example: EAP650-outdoor reboot at 1AM every day, EAP215-bridge KIT reboot at 2AM every day, and EAP610-outdoor reboot at 3AM every day. I believe this will avoid this issue.
I would recommend suggestion 2 more.
- Copy Link
- Report Inappropriate Content
First I would like to point out this is not a problem of the bridge units, as I will explain.
The other way to fix this is in controller Site Settings for Mesh, disable the Mesh Auto-Failover.
Providing you don't rely on Mesh auto-failover?
This will prevent the EAP610 from attempting to "heal" its connection by seeking an alternative EAP (your 650) when it detects that its Ethernet cable wired connection has gone down (heartbeat has gone for whatever reason, power loss, disconnected cable somewhere/anywhere, scheduled rebooting, etc.). If Mesh is enabled and Auto-failover is also Enabled it will try to mesh over wireless backhaul with an alternative mesh AP (this is what is happening for you I think).
By disabling Mesh Auto-Failover, it won't attempt to heal and instead will just go to Isolated status and sit there waiting for the wired connection to come back up again (once your rescheduled reboot has finished).
I learned the hard way and did lots of testing to understand the whole failover process and stages.
Failover time from initial disconnect to healed with a different AP can take up to several minutes (anything from 2-7 minutes [and even longer if DFS channels 120-128 are involved as this can add an extra 10 minutes, due to DFS regulations for radio silence and detecting for radar activity before the AP is allowed to broadcast], so you have to be patient).
Getting it back again can likewise take a long time and requires rebooting the failed over device (your EAP610) once the "problem" for whatever reason, has been resolved (eg. scheduled reboot has completed, broken cable fixed/re-plugged, power outage in a section of the site is back on, etc). Note that PoE injectors will keep power applied to EAP's so they continue to hold their mesh connections, whereas when an EAP is connected to a PoE port on a switch (without a PoE injector), if the switch is rebooted it will shut off the PoE and so the EAP also loses power then boots again (detecting heartbeat afresh through the cable again).
However, if Mesh Auto-failover is disabled, the reconnect via wired cable is much faster, perhaps less than a minute or so (because it wasn't connected to anything, just Isolated) and a wired connection is established almost instantly, whereas mesh takes time to establish as indicated above.
Sidenote: Once the EAP610/650 get mesh connected they don't want to release, and there is not a clear "re-Link by cable" option in the device list. Options to reboot are unplug the PoE power (duh, not convenient) or go to the device Config screen and Manage Device section and choose Reboot (or if that is not available do a Force Provision which seems to involve a reboot). When the EAP610 powers up, first it will check its LAN port is connected to see if there is a good cable connection, before it attempts anything else, and hey presto you're back on track with "LAN connection / wired backhaul".
Hope that helps.
Jim
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 340
Replies: 3
Voters 0
No one has voted for it yet.