8204F port errors

When these errors occur, is anything recorded in the logs on either switch? #show logging

When you moved the cable to an alternate port, did you try this for the 5548 as well? Or just the 8024?

What firmware are the switches currently running?

Were there any changes to the network a month ago? Any new devices, traffic type, or configuration changes?

Logging only shows the interface going down and up, and consequently STP status changes:

<189> JAN 17 11:31:17 10.0.200.64-1 TRAPMGR[245162672]: traputil.c(637) 661417 %% Te1/0/2 is transitioned from the Forwarding state to the Blocking state in instance 0
<189> JAN 17 11:31:17 10.0.200.64-1 TRAPMGR[245162672]: traputil.c(637) 661416 %% Link Up: Te1/0/2
<189> JAN 17 11:31:17 10.0.200.64-1 TRAPMGR[245162672]: traputil.c(637) 661415 %% Te1/0/2 is transitioned from the Forwarding state to the Blocking state in instance 0
<189> JAN 17 11:31:17 10.0.200.64-1 TRAPMGR[245162672]: traputil.c(637) 661414 %% Link on Te1/0/2 is failed
<189> JAN 17 11:31:17 10.0.200.64-1 TRAPMGR[245162672]: traputil.c(637) 661413 %% Link Down: Te1/0/2

5548 FW version: 4.1.0.10

8024F FW version: 5.0.1.3

I have only changed ports on the 8024F as any changes to the 5548 could cause downtime on a production environment.

There have not been any changes made to the effected ports configuration for over a year.

A port transitioning to the blocking stat would definitely cause some connectivity loss. Is the 5548 recording any topology changes around the same time? How is spanning tree configured on your network? Are all the switches left at default spanning tree values?  Or have they manually been assigned values? What spanning tree mode is being used? Is the 8024 being used as a core, distribution, or access switch?

Here are some command to help look at spanning tree.

#show spanning-tree

#show spanning-tree suammary

This command will help look to see if the interface has received any BPDUs.

#show interfaces detail te1/0/2

Both switches are numerous revisions outdated. While The updated firmware may not resolve this specific issue, it can have an overall impact on operability. If you get some available downtime, I suggest getting them updated.

5524: http://dell.to/2ixudZo

8024: http://dell.to/2hwvDz6

There have been STP changes on the 5548 te1/0/2 port that connects to the 8024F, though there have been very few errors and no operation status changes on that port compared to the 8024F port. I have been concentrating on the 8024F as it's where I have seen all the errors and the port actually going down.

The 8024F is being used as a core switch that has all the trunk connections to the switch stacks in other cabinets. None of the other ports/connections are having any issues.

The current network layout and STP configuration has been in placed for years now with no issue. Could the errors on the 8024F port be caused by issues with the 5548? If so I can organise some maintenance periods to replace the SFP on the switch.

switch064#show spanning-tree tengigabitethernet 1/0/2

Port Te1/0/2 Enabled
State: Discarding                                 Role: Designated
Port id: 128.2                                        Port Cost: 2000
Port Fast: No                                         Root Protection: No
Designated bridge Priority: 16384    Address: D067.E599.4DC4
Designated port id: 128.2                   Designated path cost: 2000
CST Regional Root: 40:00:D0:67:E5:99:4D:C4
Root Guard..................................... FALSE
Loop Guard..................................... FALSE
TCN Guard...................................... FALSE
Auto Portfast.................................. TRUE
Port Up Time Since Counters Last Cleared....... 0 day 0 hr 0 min 0 sec
BPDU: sent 18350187, received 8328871

switch064#show spanning-tree summary

Spanning Tree Adminmode........... Enabled
Spanning Tree Version............. IEEE 802.1w
BPDU Guard Mode................... Disabled
BPDU Flood Mode................... Disabled

BPDU Filter Mode.................. Disabled
Configuration Name................ D0-67-E5-99-4D-C4
Configuration Revision Level...... 0
Configuration Digest Key.......... 0xac36177f50283cd4b83821d8ab26de62
Configuration Format Selector..... 0

Based on the behavior we are seeing, it would seem that the core switch is not the spanning tree root for the network. It is normal to have some topology changes propagated on the network. As various devices are plugged in or removed from the network, this could spark those topology change notifications. When the core switch is not the root switch, it is willing to transition its ports to a discarding role in order to allow the root switch to have all forwarding interfaces.

When spanning tree priorities are left at the default value of 32768, the switches will then use their MAC address to decide which switch on the network is the root switch. This process usually ends up with the core switch not being the root switch. A good first step would be to document what the priority is for each switch, which mode of spanning tree is being used, and which one is root. You can use the command #show spanning-tree to find the priority and which switch is root.

console#show spanning-tree
Spanning tree :Enabled - BPDU Flooding :Disabled - Portfast BPDU filtering
:Disabled - mode :rstp
CST Regional Root: 80:00:00:1E:C9:AA:AD:1B
Regional Root Path Cost: 0
ROOT ID
Priority 32768
Address 0010.1882.1C53
Path Cost 20000

To set the core switch to be the root switch, we need to change the priority to something lower than the other switches. It is common to set the core to the lowest possible priority of 4096. If the core switch had some form of backup, that switch would be set to 8192. It is common then to see the distribution switches set to 16384, and the access layer left at default values.

Once these values are set, the core switch should then no longer go into a discarding state. If topology changes are still being propagated on the network, you may start to see other switches transition to a discarding state. In this situation you would need to observe the logs of each switch to try and track down the source of the topology changes.

As mentioned, the firmware can also play a role in this and should be updated. The spanning tree changes can cause interruptions in connectivity. I suggest performing during non peak hours or during a maintenance window.

Keep us posted on your progress.