Omada RSTP
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.Omada RSTP
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Hi,
Looking for some clarification as I think either my switch or Omada in general has a problem with RSTP. I have an ER605 working as my main router, with 2 switches as core switches. Both switches are connected to the LAN of the ER605 and to each other with RSTP enabled. These are not omada switches (yet).
Downstream of the core switches, one is the SG3210XHP-M2, this is connected to 5 EAPs and the OC200. The other is a SG2008P (V1 so no omada )
I have RSTP enabled on all the connecting ports between the switches. When i simulate an outage on one of the core switches the other 3 behave as expected and are back up and running in a matter of seconds. The 3210 loses its mind, and cannot be recovered with a reboot.
because of that I lose access to the ~OC200 and all my wifi.
is there a problem with RSTP in omada or is my switch faulty?
Please help!
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Hi, I have a V2 and I don't have that firmware availble yet so I can't comment. I received a beta firmware from TP-link which appears to have solved the issue so I assume that this latest release will incorporate that fix.
- Copy Link
- Report Inappropriate Content
Thanks for posting in our business forum.
Then how do you connect your whole network? Can you draw a diagram and illustrate more? What did you do to verify that the 3210XHP-M2 is offline? e.g. ping? Is there any connection from the switch?
- Copy Link
- Report Inappropriate Content
Hopefully this helps. All of the links are participating in RSTP. Blue links are 10gbps, Green are 1gbps. Yes I use pings to verify the response of the 3210. I have tried connecting the controller to a different switch (SW4) and it remains responsive when the 3210 is not. However it cannot control it because it gets stuck in an adopting loop as i guess the 3210 keeps blocking the port. I have tried increasing the priority of 3210 to 24576 and the results are the same. if SW1 or SW2 are powered off the 3210 struggles but sometimes established a link. however when that SW comes back online that it when it WILL crash.
- Copy Link
- Report Inappropriate Content
Thanks for posting in our business forum.
So, you are setting up something like we have in the User Guide. This is gonna be a failover, right?
I'd suggest you read the User Guide first on configuring the failover connection between the switches. How to configure STP/RSTP on L2 Managed switches using the new GUI
You should not remove VLAN 1. The ext-path cost for SW2 and 3 should be set at a large value. If you are using the Controller mode, use the CLI to modify that.
Moreover, how many ports are blocked on the 3210? I see 3 loops in your picture. And if you power off 1 and 2, then there is no link between the 3 and 4.
- Copy Link
- Report Inappropriate Content
Thanks for your reply. Yes the main aim is redundancy. Currently SW1(root) leaves all ports designated as it should as the root. Sw2 blocks its port to the router, All other ports are designated. The 3210 blocks 1 port to SW2 as does SW4. I am aware there is no link between the 3210 and SW4. Right now it is working fine, the correct ports are blocked but as soon as an upstream link is removed it's the reconfiguration process that crashes. Until I can get this simple model working I abandoned further links. I understand why you suggest increasing the path cost but rstp should figure this out automatically. As I mentioned in my previous post, the other none Omada switches work perfectly and reconfigure in seconds. My other TP-link is brilliant at it. It's only the 3210 that can't behave itself which is what leads me to believe that rstp within Omada is the problem
- Copy Link
- Report Inappropriate Content
Thanks for posting in our business forum.
So I'd like to escalate your case for further analysis. But I gotta know the following details:
1. What other switches do you have? What's the TP-Link model you mentioned? Firmware of the TP-Link switch. Can you put the model in the drawing you have earlier? BTW, Can you make sure the diagram you sent in the reply is the current setup?
2. Backup of your TL-Link switches. You can export them first and wait for my email once you have answered other questions.
3. When you reconfigure it, which one line is disconnected? Can you specify it in another diagram so that we can get it correctly?
- Copy Link
- Report Inappropriate Content
Hi @Clive_A
Thanks again for your reply. I am currently away on holiday so I can't get everything you have asked for, but I will get all of the info you need when I return next week. Thanks again
- Copy Link
- Report Inappropriate Content
My current config details are as follows:
SW1 - QNAP QSW-M1208-8C
Bridge Priority 8192
| Port |
Speed |
Destination |
Role |
State |
| 1 |
10gbps |
SW3 |
Designated |
Forwarding |
| 2 |
1gbps (fibre) |
SW4 |
Designated |
Forwarding |
| 7 |
1gbps (copper) |
ER605 |
Designated |
Forwarding |
| 12 |
10gbps |
SW2 |
Designated |
Forwarding |
SW2 Mikrotik CRS305-1G-4S+
Bridge Priority: 16384
| Port |
Speed |
Destination |
Role |
State |
| 1 |
1gbps (copper) |
ER605 |
Alternate |
Discarding |
| 2 |
10gbps |
SW1 |
Root |
Forwarding |
| 3 |
10gbps |
SW3 |
Designated |
Forwarding |
| 4 |
10gbps |
SW4 |
Designated |
Forwarding |
SW3 – TPL TL-SG3210XHP-M2 v2.0 (FW 2.0.6)
Bridge Priority: 32768
| Port |
Speed |
Destination |
Role |
State |
| 9 |
10gbps |
SW2 |
Alternate |
Discarding |
| 10 |
10gbps |
SW1 |
Root |
Forwarding |
SW4 – TPL TL-SG2210P V1 (FW 1.0.5 20160912)
Bridge Priority: 32768
| Port |
Speed |
Destination |
Role |
State |
| 9 |
1gbps (fibre) |
SW2 |
Alternate |
Discarding |
| 10 |
1gbps (fibre) |
SW1 |
Root |
Forwarding |
If I power off SW1, SW2 and SW4 behave as expected and converge very quickly. SW3 takes a bit of time but will eventually take the alternate root. The biggest issue comes when I restart SW1. SW2 and SW4 behave as expected. SW3 becomes unresponsive and can take anywhere between 5-10 minutes to recover. Sometimes requiring a reboot.
- Copy Link
- Report Inappropriate Content
I have done a bit more testing. I reset and configured the SG3210XHP in standalone mode and tried the same events.
- power loss to the root bridge - logs show the new root bridge and switch within about 5-10 seconds (still slower convergence than my other less powerful switches)
- restore power to root bridge - logs show new root bridge but also there are warnings about 90% cpu utilisation. convergence for new paths takes over 2 minutes
- disable the port on the root bridge but stays powered on - new path is found within about 5 seconds
- enable the port to the root bridge - connectivity to switch lost for almost 10 minutes. logs show repeated 90% cpu warning and many root bridge changes and topology rx and tx.
I would assume therefore it has nothing to do with the omada or the controller. Since my other switches do not show the same behaviour I assume any topology changes being sent by other devices are working fine. Therefore I assume its either a problem with the RSTP deployment in this firmware of some CPU utilisation error with this model.
really hope this helps your team recreate this and find the solution. Any other questions I am very happy to help in any way I can.
- Copy Link
- Report Inappropriate Content
Thanks for posting in our business forum.
Still need a backup of your config on 3210XHP-M2.
Prepare the log before the test and after the test. Use the following command:
Sw> en
Sw# sh run
Sw# sh log
I'll create a ticket and please reply with all the information to the email you receive later.
- Copy Link
- Report Inappropriate Content
Thank you so much for taking the time to post the issue on TP-Link community!
To better assist you, I've created a support ticket via your registered email address, and escalated it to our support engineer to look into the issue. The ticket ID is TKID230906877, please check your email box and ensure the support email is well received. Thanks!
Once the issue is addressed or resolved, welcome to update this topic thread with your solution to help others who may encounter the same issue as you did.
Many thanks for your great cooperation and patience!
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 1763
Replies: 13
Voters 0
No one has voted for it yet.