07-27-2012 03:46 PM - edited 03-07-2019 08:01 AM
I've been having an issue with a switch that seems to be trying to send 1-2 million packets/hour to each interface that is an alternate interface on another switch. The spanning tree topology hasn't changed on 4 hours now (that's because I did it), and there are only 5 switches in this equation. Any idea why this switch would be trying so hard to send packets out an interface that it should know won't be listening?
Thanks,
Ed
This is the switch that is having the issue:
FRS-Van-Swi-CCore#show span
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 32769
Address 0008.30ea.7c80
Cost 4
Port 2 (GigabitEthernet1/0/2)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 2894.0f1a.3e80
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/0/1 Desg FWD 4 128.1 P2p
Gi1/0/2 Root FWD 4 128.2 P2p
Gi1/0/4 Desg FWD 4 128.4 P2p
Gi2/0/1 Desg FWD 4 128.57 P2p
Gi2/0/2 Altn BLK 4 128.58 P2p
Gi2/0/4 Desg FWD 4 128.60 P2p
VLAN0001 is executing the rstp compatible Spanning Tree protocol
Bridge Identifier has priority 32768, sysid 1, address 2894.0f1a.3e80
Configured hello time 2, max age 20, forward delay 15, transmit hold-count 6
Current root has priority 32769, address 0008.30ea.7c80
Root port is 2 (GigabitEthernet1/0/2), cost of root path is 4
Topology change flag not set, detected flag not set
Number of topology changes 115 last change occurred 04:05:14 ago
from GigabitEthernet1/0/4
Times: hold 1, topology change 35, notification 2
hello 2, max age 20, forward delay 15
Timers: hello 0, topology change 0, notification 0, aging 300
GigabitEthernet2/0/1 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is 2894.0f1f.fb01 (bia 2894.0f1f.fb01)
Description: FRS-Van-Swi-ACore G2/1/1
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseLX SFP
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:52, output 00:00:25, output hang never
Last clearing of "show interface" counters 00:29:00
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 894810
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 2000 bits/sec, 5 packets/sec
1813 packets input, 142281 bytes, 0 no buffer
Received 1813 broadcasts (1813 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 1813 multicast, 0 pause input
0 input packets with dribble condition detected
7591 packets output, 632091 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
Solved! Go to Solution.
07-29-2012 09:10 PM
Dear Ed ,
If you dont want have any problem pretaining to STP in future or during addition of any switch , Best practise is to keep spanning priorty equal to 8192 or less 32768 on your Core switch or Distrubtion switch which is connecting to all other switch .
or
you can excute below command on your core switch
spanning-tree vlan 1 root primary (which bring your spanning priority to 24576 from 32678 ) .
Please share your otulined LAN diagram .for better advise . If you have multiple VLAN on your switch, better advise to use PVLAN spanning tree for each VLAN .
07-28-2012 02:10 AM
Dear Ed,
STP does not produce any problem on your switch it looks fine, Check for your Physical link settings duplex & speed on both side of your switch .
Do see any output drop on any other switch port , try to shut this port for a while and try to observe drop on another switch port on same switch ..
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 894810
07-29-2012 05:34 PM
I did check speed/dulex first off. I don't see any drops on any other ports, just ports that have the other side set to alternate by STP. I did try shutting the alternate port on the other switches to see what would happen, and the drops stopped. So I turned them back on, and the drops started again. Today there was no one in that office, so I reloaded the problem switch, it had only been up a few weeks, but after that it seems to be doing okay.
At the moment everything seems to be fine, but the exact same thing happened last time I added a switch to this network. I know the STP is going to re-access its topology, but the same behavior was seen last time too. I have another 9 switches to add in the next couple weeks, IDF cabinets in bays, so I'll be able to dial in the cause I think shortly.
Thanks,
Ed
07-29-2012 07:53 PM
07-29-2012 09:10 PM
Dear Ed ,
If you dont want have any problem pretaining to STP in future or during addition of any switch , Best practise is to keep spanning priorty equal to 8192 or less 32768 on your Core switch or Distrubtion switch which is connecting to all other switch .
or
you can excute below command on your core switch
spanning-tree vlan 1 root primary (which bring your spanning priority to 24576 from 32678 ) .
Please share your otulined LAN diagram .for better advise . If you have multiple VLAN on your switch, better advise to use PVLAN spanning tree for each VLAN .
09-12-2012 08:18 PM
After I added additional switches it does seem that it was STP convergence that caused the problem. Thanks!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide