spanning tree vs loss of services

[lcaruso]

Hi,

Curious if spanning tree topology change can cause this problem.

Please see graphics (2nd graphic shows vlans being forward on each switch). Core is 3750X stack and others are 3560s (no ip routing on those)

Users attached to switch E1 (and/or E2, not specified precisely) lose services when switch W1 is disconnected from the core.

Given loop in network switch E1 is blocking on port Gi0/3.

How could I determine if spanning tree is an issue in this scenario? What does "shr" port status mean in spanning tree detail?

Appeciate your helpful input.

Thanks.

[lcaruso]

Do you recommend these ?

     running UDLD and Loop Guard with RSTP

     Enable BPDU Guard on portfast-enabled ports with RSTP

Thanks.

[Wilson Bonilla]

Hello

As the Cisco Best practices documentation states:

BPDU Guard is recommended in portfast enabled ports.

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/best/practices/recommendations.html#wp1053726

Loop guard complements the protection against unidirectional link failures provided by UDLD. They work better together.

Regards.

Wilson B

[lcaruso]

Sorry I have to ask:

Best Practices for a 6500 are exactly the same for a 3560 in this case?

Thanks for the link.

[Wilson Bonilla · Accepted solution]

Hello

Thank for your question, the answer is Spanning-tree works the same way in a 2960s, 3560s, 3750s, 4500s, 6500s, 7600s.................  the fact the platform changes doesn't make stp different. Off course just for spanning-tree in this case there're other features mentioned on the artitle that are not even supported in 3560. : )

Regards

Wilson B.

[lcaruso]

Getting ready to make these changes. Is this the correct way to implement these features?

spanning-tree mode rapid-pvst
spanning-tree loopguard default
spanning-tree portfast bpduguard default
spanning-tree extend system-id
udld aggressive
errdisable recovery cause udld
errdisable recovery cause bpduguard
errdisable recovery cause channel-misconfig (STP)
errdisable recovery cause dtp-flap
errdisable recovery cause link-flap
interface GigabitEthernet1/0/1
 switchport access vlan 700
 switchport mode access
 storm-control broadcast level 30.00
 storm-control multicast level 30.00
 no cdp enable
 spanning-tree portfast
 spanning-tree guard loop
interface GigabitEthernet1/1/1
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 900
 switchport trunk allowed vlan 1-1005
 switchport mode trunk
 switchport nonegotiate
 storm-control broadcast level 80.00
 spanning-tree guard loop

[lcaruso]

Is that why pvst+ is sending out frames twice a second, since it doesn't have anyone (on the core) to talk to?

[Peter Paluch]

Hello,

Is that why pvst+ is sending out frames twice a second, since it doesn't have anyone (on the core) to talk to?

I am not quite certain if I understand your question. But from what I see in the attached JPG, there are PVST+ BPDUs for two VLANs being sent, VLAN 50 and VLAN 101. Each BPDU for a particular VLAN is being sent each 2 seconds which is the default Hello timer setting in STP.

The exhibit shows a perfectly normal propagation of PVST+ BPDUs in two different VLANs.

Best regards,

Peter

[lcaruso]

The shr device is an old printer.

The outage lasted several minutes until the switch was reconnected (mistakenly disconnected).

Does this add up to a spanning tree cause?

Thanks much for all of your help.

[Peter Paluch]

Hello,

Hmm, this does not really look like an STP issue after all (although your STP setup is currently not in the best shape). Are you by chance running VTP Pruning?

Best regards,

Peter

[lcaruso]

I didn't see VTP pruning running (need to recheck), but I did see more than one switch configured as a VTP server.

[Peter Paluch]

Hello,

I apologize for not contacting you earlier... Is this issue still relevant? Please let me know. Thanks!

Best regards,

Peter

[lcaruso]

Hi Peter,

Thanks kindly for checking back.

This issue will remain since I have to plan all of the changes with this company that we already discussed (getting all switches on one flavor of STP, etc). They have near zero tolerance for down time.

I agree the cause didn't sound like it was STP related based on the client comments about the timing of the resolution, but what else could it be?

I thought possibly since these two flavors of STP don't see eye to eye and they do have a planned loop in their network for redundancy the perhaps disconnecting a switch on the west side of the core triggered a topology change the other switches could not understand. The loop is in the East building and is on the switch directly connected to the core.

West Building (pvst)---->Core (rstp)---->East Building(pvst)