TL-SG2008P - Blocking Uplink Ports randomly for cascades switches.
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
With the following Setup (latest FW on all Devices).
ER7206
- SG2008P "Switch A"
- OC200
- EAP660
- via Port1 - SG2008P "Switch B"
- EAP225
- via Port1 - SG2008P "Switch C"
- EAP620
the following occurs randomly:
Alert: "Switch B" 's port Gi1/0/1 was blocked.
Or
Alert: "Switch C" 's port Gi1/0/1 was blocked.
(Port 1 is the uplink on B, C to A.)
This is followed by
Events, usually a few seconds later...
Switch B/C was readopted automatically
Switch B/C was connected.
(Same for EAPs connected to these switches).
In other words shorter: Cascaded Switches loose their uplink connection randomly.
Any Ideas?
Probably the port blocking is the primary problem, but why are those ports blocked anyway?
Any Help would be appreciated.
And another minor issue: The timestamp in the Alert log is always wrong - wrong timezone -7h
Timestamp in Events is ok.
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Regarding your Questions - it is definately a SONOS issue, the case has been discussed in many forums with other network gear.
SONOS creates loops under specific circumstances and definately causes multi or broadcast storms.
The switches work fine with SONOS disconnected.
AND: With the information in other forums I found a solution that works for me. I created a port specific Profile override, enabled Storm Control with limits on Broadcasts / Multicasts. Now occassionally Multicast Storms / Broadcast Storms are detected, but the Uplinks are not effected.
- Copy Link
- Report Inappropriate Content
I had something similar on unifi, then the access points started to mesh wirelessly and there was a loop in the network, maybe it is something similar, have you tried to deactivate mesh in site setting
- Copy Link
- Report Inappropriate Content
@shberge THX - Stopping the Mesh is not so easy, but singled that one out by disconnecting the APs... Still die Blocks occurred -
BUT Loops seem to be the cause.
It seems the SONOS net creates loops or causes the issues in another way. As I disconnected SONOS physically it seems to work.
- Copy Link
- Report Inappropriate Content
Yes I have read a lot of Sonos and Network loop earlier
There is a lot about this if you google sonos loop network
I do not quite remember but think there was something with wired and wireless sonos, you have to run everything wirelessly or wired I mean to remember.
- Copy Link
- Report Inappropriate Content
Dear @TGCleaner,
TGCleaner wrote
In other words shorter: Cascaded Switches loose their uplink connection randomly.
Based on your following reply, it seems the issue has something with SONOS.
Could you please confirm whether the OC200 can manage the SG2008P switch steadily after you disconnect the SONOS?
And another minor issue: The timestamp in the Alert log is always wrong - wrong timezone -7h
Timestamp in Events is ok.
Regarding the timestamp issue, I'd like to escalate to the support team for further investigation.
They will reach you via your registered email address shortly, please pay attention to your email box later.
Thank you so much for your cooperation and support!
- Copy Link
- Report Inappropriate Content
Regarding your Questions - it is definately a SONOS issue, the case has been discussed in many forums with other network gear.
SONOS creates loops under specific circumstances and definately causes multi or broadcast storms.
The switches work fine with SONOS disconnected.
AND: With the information in other forums I found a solution that works for me. I created a port specific Profile override, enabled Storm Control with limits on Broadcasts / Multicasts. Now occassionally Multicast Storms / Broadcast Storms are detected, but the Uplinks are not effected.
- Copy Link
- Report Inappropriate Content
Regarding the timestamp issue:
Alerts / ERRORS - Correct Timestamp
Alerts / WARNINGS - Wrong Timestamp (my time - 7 hours).
Site Configuration / Time Zone: UTC + 1
Controller General Settings / Time Zone: UTC + 1
- Copy Link
- Report Inappropriate Content
Dear @TGCleaner,
TGCleaner wrote
Regarding the timestamp issue:
Alerts / ERRORS - Correct TimestampAlerts / WARNINGS - Wrong Timestamp (my time - 7 hours).
Site Configuration / Time Zone: UTC + 1Controller General Settings / Time Zone: UTC + 1
Thank you for your valued feedback! The timestamp issue has already been escalated to the support team for further assistance, but they haven't received your email reply yet. Have you ever received the support email who case ID is TKID220329961? Or was your concern resolved on your own finally?
We are looking forward to hearing from you again.
Edit: Regarding the timestamp issue, @TGCleaner cannot reproduce the issue after updating the controller to 5.1.7, seems like the firmware upgrade refreshed the system and helped to recover the log timestamp, so the case was closed.
- Copy Link
- Report Inappropriate Content
@Fae regarding the email: I answered today, sent the required data. Not earlier as I was on holiday.
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
@bokolobs
Regarding Your Question (sorry for late reply, saw the posting today...):
Loopback - Spanning Tree
Bandwith Control
Storm Control - enabled
Broadcast Threshold
128 Kbps
Multicast Threshold
128 Kbps
Unknown Unicast Threshold
128 Kbps
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 3201
Replies: 10
Voters 0
No one has voted for it yet.