There's nothing relevant in the configuration, these are simply two trunk links with a few VLANs passing through.
interface GigabitEthernet2/0/25
switchport trunk allowed vlan 10, 15, 99
switchport mode trunk
interface GigabitEthernet2/0/26
switchport trunk allowed vlan 10, 15, 99
switchport mode trunk
This isn't a matter of configuration, there are hundreds of other switches in the plant by the same model, same IoS version [latest recommended, 15.2(7)E7], same configuration, and they are working flawlessly. There are dozens of other instances of this topology in the plant, working with zero issues.
If I move one of the links to switch #1 [this was actually the standard initial configuration for switch redundancy purposes, before I moved both ring links to switch #2 as a test], the outcome is that when that link coming from the ring goes down, the other link on switch #1 coming from the distribution network goes down as well. Similarly, when the link on switch #2 coming from the ring goes down, the other link on switch #2 coming from the distribution network goes down as well.
Regardless of where you connect the links coming from the ring, whenever they fail they bring down the whole optical component of that particular switch. I've consistently tested this by connecting another switch on the 3rd port of any of the two stack switches: whenever the link coming from the ring goes down, it causes every single other optical port _on that specific switch_ to shut down.
So, in either cases, the links going down are always the ones facing the ring. The outcome is the same if I physically open the ring by shutting down a link along the way, so no spanning tree at work in that area in that case. There's rapid-pvst enabled everywhere, with the root bridge being the core switch. In normal conditions, everything works without issues, without registered errors, without broadcast storms, without packet loss. It just happens that at some point the stack switch #2 stops receiving/processing signal on all optical ports at once. Note that we've also replaced the SFP modules on the ring side. When the problem arises, a show interface transceiver command on the ring switches shows that they keep transmitting as usual. The same command on stack switch #2 shows nothing regarding the interfaces that went down [as expected, this is a common IoS behavior].
Nothing relevant in the logs either, there are just the entries of the interfaces going down and nothing more, and as said they go down on switch #2 only, they never go down on the ring switches. To put it simply, switch #2 apparently stops receiving signal, ring switches do not. So it seems that, when the issue occurs, switch #2 stops processing incoming signal, but it keeps transmitting as usual. It *could* be a case where both ring switches connected to switch #2 stop transmitting, and we could test this by connecting an optical instrument on the switch #2 side when the problem occurs, but as said everything always worked without any issues for years with the old HP switch in place of the new stack. That remains to be seen, I'll ask the tech guys on the site.
I'm not saying that the issue relies in the 2960 stack switch itself, I'm saying that there's something happening somewhere else, possibly on the hosts attached to the ring, that is traveling all the way up to the switch preventing it to act normally. I've rarely seen a case where a switch reload was needed to get the interfaces back up, and it was always because of faulty hardware. We've replaced everything.
I'm looking for specific debug commands that would point out what is going on with the optical components when the problem arises, or with the processes governing them, so far I've found nothing. A debug interface states doesn't point up anything relevant, same for debug transceiver error|detail.
Ugh. Sorry for the wall of text.
