The network is basically dual 6509 cores, with a variety of 35xx, 37xx, 45xx switches trunked to the 6509s, and in some cases, stackables trunked to other stackables.
Today, after 3 days of watching the packets counts on various trunk ports topping out between 30,000 to 60,000 pkts/second, having the security cameras going up and down, cutting back on un-needed vlans everywhere I could think of, it finally (so late, I know, should of been one of the first things I did...) thought to check interface errors.
Found we were getting huge numbers of OutDiscards on the 6509 trunk ports. Cleared the counters, the discards mounted up again, numbers in the 6 & 7 digit range within half an hour.
Further investigation revealed huge numbers of XMit errors on a 3550 that trunks to one of the 6509s. XMit errors were occuring in the 6 & 7 digit figures on all connected ports.
Cleared those counters, and saw the 6 digit XMit errors within 60 seconds on two of the 3550 ports. (All other connected ports were showing XMit errors in the 5 & 6 digit arena within 5-10 minutes.)
Those two ports where the XMit errors re-occured within 60 seconds were trunks.
One went to a 2955 that has nothing attached. So I did a "shut" on that port.
The other, a FastEthernet port, was a trunk to a 3560. That 3560 is in my personal office. Last week I finally got around to connecting that 3560 to the network with a Gig port, but I left the FastEthernet trunk connected as a backup. Today, seeing the XMit errors, I pulled the FastEthernet to the 3560 in my office.
From that point on (3 hours ago), XMit errors on the 3550 are at 270 for 1 port. All other ports are 0 errors.
And, OutDiscard numbers on the 6509 trunks remain at 0 for all ports.
So, was it the dual trunking of my office switch that was the problem? Because you can't dual trunk a switch with different speed links? I would have thought that spanning tree would pick up the faster link, and that would be that.
If anyone can educate me, so I know what not to do in the future, it would be much appreciated...
>> So, was it the dual trunking of my office switch that was the problem? Because you can't dual trunk a switch with different speed links? I would have thought that spanning tree would pick up the faster link, and that would be that.
this is possible and STP should keep the backup link in blocked state if the vlan or vlans of the backup link are permitted on the primary link
about your issue: a faulty cable should be considered but it is difficult to say more without seeing more details
Hope to help