Are there any other errors in the logs? It does sound like it could be spanning-tree and then shutting down ports. Is this one is a stack and is it the master? You may also want to check cabling.
Single switch in this case and it's been swapped out for an identical switch but still exhibits the same problem. Anything specific I should be looking for in the logs that would help? I can easily clear the logs and then replicate the issue by turning the third link back on.
So I've just re-enabled the link (with a ping running to the switch) and within seconds it dropped off. Left it like this for a couple of minutes then disabled the link and within about 45 seconds it started responding again (Log info below)
Notice
Jul 24 09:19:59
TRAPMGR
Gi1/0/22 is transitioned from the Learning state to the Forwarding state in instance 0
Notice
Jul 24 09:19:59
TRAPMGR
Gi1/0/22 is transitioned from the Forwarding state to the Blocking state in instance 0
Notice
Jul 24 09:19:55
TRAPMGR
Gi1/0/23 is transitioned from the Learning state to the Forwarding state in instance 0
Notice
Jul 24 09:19:53
TRAPMGR
Spanning Tree Topology Change: 0, Unit: 1
Notice
Jul 24 09:19:53
TRAPMGR
Gi1/0/22 is transitioned from the Learning state to the Forwarding state in instance 0
Notice
Jul 24 09:19:52
TRAPMGR
Gi1/0/23 is transitioned from the Forwarding state to the Blocking state in instance 0
Info
Jul 24 09:19:37
CLI_WEB
[WEB:Coretek:10.10.80.12] Disconnected due to Idle Timeout
Notice
Jul 24 09:17:08
TRAPMGR
Gi1/0/22 is transitioned from the Forwarding state to the Blocking state in instance 0
Notice
Jul 24 09:17:08
TRAPMGR
Spanning Tree Topology Change: 0, Unit: 1
Notice
Jul 24 09:16:57
TRAPMGR
Gi1/0/23 is transitioned from the Learning state to the Forwarding state in instance 0
Notice
Jul 24 09:16:55
TRAPMGR
Spanning Tree Topology Change: 0, Unit: 1
Notice
Jul 24 09:16:55
TRAPMGR
Gi1/0/22 is transitioned from the Learning state to the Forwarding state in instance 0
Notice
Jul 24 09:16:54
TRAPMGR
Gi1/0/23 is transitioned from the Forwarding state to the Blocking state in instance 0
Notice
Jul 24 09:12:18
TRAPMGR
Spanning Tree Topology Change: 0, Unit: 1
Notice
Jul 24 09:12:18
TRAPMGR
Gi1/0/22 is transitioned from the Forwarding state to the Blocking state in instance 0
Port 22 is a direct link to one of the two Microwave RFU's. Currently on that switch there are two microwave links and a fiber link with additional ports linked to the management port of the Microwave RFU's. I just downed the port to make sure that neither of the management IP's dropped, which they didn't, so that tells me it's the RFU Data link. I know it's not a management issue as we have turned off all the MSTP options on all the Microwaves in the network to allow the switches to manage Spanning tree. That tells me it could be an issue with the Microwave RFU which I can raise with the maintainer. Thanks for the pointer.
DELL-Josh Cr
Moderator
•
9.5K Posts
0
July 25th, 2019 09:00
It does seem like it is something with port 22, what is it connecting to?
DELL-Josh Cr
Moderator
•
9.5K Posts
0
July 24th, 2019 09:00
Hi,
Are there any other errors in the logs? It does sound like it could be spanning-tree and then shutting down ports. Is this one is a stack and is it the master? You may also want to check cabling.
JasonCoretek
5 Posts
0
July 25th, 2019 01:00
Single switch in this case and it's been swapped out for an identical switch but still exhibits the same problem. Anything specific I should be looking for in the logs that would help? I can easily clear the logs and then replicate the issue by turning the third link back on.
JasonCoretek
5 Posts
0
July 25th, 2019 01:00
So I've just re-enabled the link (with a ping running to the switch) and within seconds it dropped off. Left it like this for a couple of minutes then disabled the link and within about 45 seconds it started responding again (Log info below)
JasonCoretek
5 Posts
0
July 29th, 2019 01:00