STP Debug

[brunobaleizao27]

Hi masters,
This is my discussion hope you can help, that my thanks in advance.
I have one problem, there are flaws in our call, and about one second you can't hear or be heard.
we are Analise this mater with the team of voice, but I 'm try to make sure that everything is good in our switch.
I put the debugger running and it seems that for one second, the uplink have the BPDU expired and become the root bridge, in next second received the BPDU and return to normal.
I believe that this might explain the voice problems and Ihave configured one debug debug stop events
And I see something that is not right in this debug

superredes

i cant understand what is that i dont have any vlan with this name

another problem is i see an mac address sorting, i clear mac add d and still in the port, but theres not device there. next i see in another switch .

Its a beaviuor of a loop, see one mac address in many swichs?

And about the debug of the spanning tree, what is that?

thanks in advance

[Mark Malone]

Hi
if you want to check if STP is looping i usually run this command below, if you see topology changes constantly coming from 1 port you need to trace it to the end device or devices which may be causing the issues by following the problem through cdp to the next switch and so on

sh spanning-tree detail | i ieee|occur|from|is exec

should show something like the below and they should be stable , if there constantly resetting teh timers you have an STP issue somewhere

VLAN0001 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 949 last change occurred 20:20:49 ago
from Port-channel7
VLAN0032 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 110 last change occurred 6d20h ago
from Port-channel34
VLAN0033 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 84 last change occurred 1w3d ago
from Port-channel124
VLAN0034 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 110 last change occurred 6d20h ago
from Port-channel34
VLAN0035 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 165 last change occurred 1w3d ago
from Port-channel124
VLAN0036 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 110 last change occurred 6d20h ago


so if vlan 35 was constantly resetting the timer at core switch I would check cdp for the po124 and then run the command again on that switch its connected to , and so on following the issues through teh network at layer 2 until you get to the suspect device or port that's triggering the change

[brunobaleizao27]

Hi mark

thanks for answer, this is the output

sh spanning-tree detail | i ieee|occur|from|is exec
VLAN0008 is executing the ieee compatible Spanning Tree protocol
Number of topology changes 9 last change occurred 00:36:30 ago
VLAN0011 is executing the ieee compatible Spanning Tree protocol
Number of topology changes 9 last change occurred 00:36:30 ago
VLAN0013 is executing the ieee compatible Spanning Tree protocol
Number of topology changes 9 last change occurred 00:36:31 ago
VLAN0015 is executing the ieee compatible Spanning Tree protocol
Number of topology changes 9 last change occurred 00:36:31 ago
VLAN0016 is executing the ieee compatible Spanning Tree protocol
Number of topology changes 9 last change occurred 00:36:31 ago
VLAN0017 is executing the ieee compatible Spanning Tree protocol
Number of topology changes 8 last change occurred 00:36:30 ago
VLAN0064 is executing the ieee compatible Spanning Tree protocol
Number of topology changes 8 last change occurred 00:36:31 ago
VLAN0129 is executing the ieee compatible Spanning Tree protocol
Number of topology changes 9 last change occurred 00:36:30 ago
VLAN0300 is executing the ieee compatible Spanning Tree protocol
Number of topology changes 9 last change occurred 00:36:30 ago
VLAN0500 is executing the ieee compatible Spanning Tree protocol
Number of topology changes 4 last change occurred 00:36:31 ago

Is this in line with "normal"?

[Mark Malone]

Hi
no its not normal , all vlans are flapping at same time and if that's happening regularly its putting the network in a layer 2 spin until it reconverges , somethings wrong there , do you have a layer 2 topology of your STP setup , who the stp root is and who the stp backup root etc

Are all your access ports locked down with portfast and bpduguard where they should be , this prevents stp issues and cuts down on teh convergence

was anything added recently to the network ?

it should also be showing you which interface this is occurring from , how many uplink are on the switch you just ran this on ? is its the core switch or an access switch ?

what type of STP are you running pvst ?

[brunobaleizao27]

Hi,

I have postfast in access ports, except on trunks to other switch and AP

We have portfast, bpduguard and loopguard default.

this is a access switch, connect to a sw-core that are not in stack.

My layer 3 is not in this switchs, are in the router that i dont manage.

All ports have 802.1x, 

There are some ports that does have 802.1x for access , to control access doors but they have portfast.

I have eliminate redundancy for testing, so there no backup port or alternate path.

The only link is the uplink , I have see that they have re converge many times too.

I have lookup in all other access switches and sw core but the configuration is like i say.

We running pvst now, to see if anything is related but we have rapid stp prior to this.

I have upgrade this switch too because there might be a problem related with the bug CSCuc75090

https://www.cisco.com/cisco/psn/bssprt/bss?searchType=bstbugidsearch&page=bstBugDetail&BugID=CSCuc75090

Same issues nothing changes.

Nothing has been added to the network too.

[Mark Malone]

so theres only 1 link now , is that link clean in terms of if you check the show interface x/x , there are no major errors occurring , collision or input errors etc that could cause issues ?

what does the sw-core switch show when your run the stp command , does it show changes only occurring from that access switch direction ? or is there other switches effected too

that bug is specific to ASAs I don't think it would effect your switch , what is your current switch software version

[brunobaleizao27]

Good afternoon,

Sorry, this is the bug

https://quickview.cloudapps.cisco.com/quickview/bug/CSCuu46337

the first thing is check the interfaces, no errors, reset, nothing,

i test both interface and same result

From the switch core i find out, by your sugestion this

Number of topology changes 1095 last change occurred 03:19:55 ago
from StackPort2

In other sw core, is point to this

But this is strange, stackport2, this switch and the other does not have any stack configure

i m not in the local to see but im pretty sure theres nothing connected to the stack port

[Mark Malone]

Bug looks relevant but the stack ports sync TCNs so that could be legitimate so I would have thought there was another generated alert from somewhere causing this continuous flapping , maybe a get someone locally to make sure the stack cable sare fully seated haven't come loose , doesn't really explain why the single link switch is still flapping

personally I would run a tdr cable test on the interfaces make sure the copper cabling is not faulty causing issues , test cable-diagnostics interface .......

also this is a trunk port between the access and core there nothing irregular configured either side as its a trunk ?

[brunobaleizao27]

Sorry for long delay.

Still we are with same issue.

As i was say, there' s no errors each side, speed duplex normal and i can't find a cause for this.

I now try to check cables but can t do that , its no supported in this particular interfaces - maybe because its fiber ( GBIC SPF ) ?

From the core side, i have rj45 Gb that i am trying to understand how is converted to fiber , on the other switch it links in fiber, i have to go to the local because there ' s no one there to check this.

What do you say if i disabled STP?

I have some reservation about that since we might have problems bigger that this.

I much appreciated your prior and further responses, thks!

[Mark Malone]

What do you say if i disabled STP?
I would not do this , the stp is there to prevent a full loop , if you turn it off the network could go into spin, when STP goes into a spin it doesn't stop and all the devices will start ramping up cpu until they finally crash that are on same l2 domain

Yes TDR test will only work on copper cables as it tests the actual pins/wires connections

From the core side, i have rj45 Gb that i am trying to understand how is converted to fiber , on the other switch it links in fiber, i have to go to the local because there ' s no one there to check this.
Are you saying the single connection that's constantly flapping between core and access is made up of fibre and copper and is converted somewhere locally ? that maybe the issue the converter could be acting up or the patch connection is faulty or loose

have you mapped out all the cdp neighbour connections and even turned on lldp neighbours to make sure no one has connected a a third party switch in somewhere that's causing this , if your remote it would be difficult to see it without lldp

[brunobaleizao27]

Hi Mark

Thank you very much for the support!

The beauvoir i see is that wend i shutdown from core side, the door still remains up / up from the other switch, so i believed that might be a converter in both switches, from the notok switch, i have GBIC and fiber, in the other side there's copper and i try to call someone to validate what is between converting copper to fiber.

I will enable lldp to check that and show the results, thanks a lot.

[Mark Malone]

So there's an unmanaged switch in path between Cisco access and Cisco core switch ? if so can you bypass that notok switch at all with a long cable direct as a test , it may be the cause , or if that's impossible maybe reseat the connections each side , reboot the notok

[brunobaleizao27]

Hi Mark

The notok sw and the sw core is physical away , between floors, i would try it before, to connect direct but there's this obstacle .

I believed that there's no switch between , so i notice but this behavior is kind of strange - ( port shutdown and in other side still UP/UP ) its a normal behavior in a network with a Media Converter?

I just say that might be a media converter because i have no notice that are a switch unmanaged between, even because they all have CISCO and i will see it in CDP neighbors and in other parts , we have media converter to convert copper to fiber and so on.

I have made several reboot in tests and upgrade firmware.

[Mark Malone]

I believed that there's no switch between , so i notice but this behavior is kind of strange - ( port shutdown and in other side still UP/UP ) its a normal behavior in a network with a Media Converter?

This can depend on the media converters ability I would think wheter its stay up/up on side or not and with an unmanaged switch you wont see it in cdp as its Cisco proprietary all you will see is the cisco kit , but with lldp you can see other vendor equipment as it and open source discovery protocol. I really think you need to site visit the office and see exactly whats in place , it could be as simple as the converter being faulty and dropping up and down causing stp to re-converge in path making it look like issue is on cisco kit , but that may be just responding to what its seeing from the converter

[brunobaleizao27]

Hi mark

thanks for answer, this is the output

sh spanning-tree detail | i ieee|occur|from|is exe

 is executing the compatible Spanning Tree protocol
Number of topology changes 9 last change occurred 00:36:30 ago
 is executing the  compatible Spanning Tree protocol
Number of topology changes 9 last change occurred 00:36:30 ago
 is executing the  compatible Spanning Tree protocol
Number of topology changes 9 last change occurred 00:36:31 ago
is executing the  compatible Spanning Tree protocol
Number of topology changes 9 last change occurred 00:36:31 ago
is executing the  compatible Spanning Tree protocol
Number of topology changes 9 last change occurred 00:36:31 ago
 is executing the e compatible Spanning Tree protocol
Number of topology changes 8 last change occurred 00:36:30 ago
4 is executing the  compatible Spanning Tree protocol
Number of topology changes 8 last change occurred 00:36:31 ago
 is executing the  compatible Spanning Tree protocol
Number of topology changes 9 last change occurred 00:36:30 ago
 is executing the  compatible Spanning Tree protocol
Number of topology changes 9 last change occurred 00:36:30 ago
VLAN0500 is executing the  compatible Spanning Tree protocol
Number of topology changes 4 last change occurred 00:36:31 ago

Is this in line with "normal"?