[c-nsp] Reconstructing a spanning-tree break

[Sam Stickland]

A.L.M.Buxey at lboro.ac.uk wrote:
> Hi,
>
>   
>> "logging event link-status" (or "spanning-tree logging" was not configured 
>> on any switch so don't know if any of the ports went up or down.
>>     
>
> no syslog either. what about the uptime of the switches...did one or
> more fail due to loss of power?
>
> are you running PVST?
>
> alan
>   
Hi Alan,

It's Rapid-PVST. Thanks for your reply. I've since found out some other 
information (SW2 was reloaded) that makes things a bit confusing to 
explain the entire situation here, and I wouldn't expect anyone here to 
sit through my entire timeline of events :)

It would be helpful if someone could answer just the first question, 
regarding the meaning of "topology changes" under "sh span vlan x detail".

 Root port is 47 (GigabitEthernet1/47), cost of root path is 14
 Topology change flag not set, detected flag not set
 Number of topology changes 11 last change occurred 2d00h ago
         from GigabitEthernet1/47

That is, what type of packet (TCN, TCA, BPDU with TC set) or event 
(missing root BDPU, transition to fowarding) causes this counter to 
increment (and record the port underneath).

And, how, after a spanning-tree convergance/event (caused by the 
reloading of SW2) the ports listed under the topology change can end up 
pointing at each other (as in this example):

SW7 >------< SW8
 |            X
 |            |
/|\           |
SW3          SW4 (R)
 |           \|/
 |            |
/|\           |
SW1 -------< SW2

SW4 is the root switch.
X is a blocking port
Arrows represent the port that received a topology change (all at the 
same time) listed under "sh spantree vlan X detail".

What happened to make the ports listed on SW7 and SW8 point at each 
other? I can envisage this scenario:

SW2 is reloaded causing the blocking port on SW8 to go forwarding. After 
SW2 is reloaded the port goes back to blocking, and SW8 issues a TCN.

But this would mean that SW8 logged the _outgoing_ port it sent the TCN 
on, while all the others logged the report that _received_ the TCN on.

I can't find any information to support this hyposis. The name "topology 
change" also suggests that it could be looking at the TC bit in BPDUs, 
not the TCNs.

If anyone can explain this to me I will be very grateful,

Sam

(I'm actually beginning to suspect that SW2 continued to forward BPDUs 
but not HSRP packets and knowledge of how the counters work should help 
me work this possibility).