Switches, Hubs, and Modems
cancel
Showing results for 
Search instead for 
Did you mean: 

Procurve 2626 Spanning Tree

SOLVED
Go to solution
brandonc
Occasional Contributor

Procurve 2626 Spanning Tree

Hello,

I am attempting to use STP to provide failover redundancy for one primary 100MB WAN link, using a slower link through another carrier at the backup. I have a Procurve 2626 on each side. A WAN diagram is attached, which includes the switch configurations, and output of '#sh spanning-tree' on each. All the ports are default configs.

The problem:

When both links are connected, the lower priority ports do not go into a blocked state, and a loop occurs, along with the resulting broadcast storm. When one or the other link is disconnected, traffic flows over the connected link just fine.

I'm guessing that the problem is that both switches consider themselves root, as they both show themselves root in the STP config output. Or at least that seems to be incorrect to me; SW1 should be the root. For whatever reason, no port blocking occurs when both links are connected.

As far as I can tell, the STP configuration is correct. Do I need to trunk the ports together? I do not want any traffic going over the backup link unless the primary link fails, as the backup is much slower.

the â no lacpâ and â bpdu-protect..â configurations on port 8 of SW2 were added during troubleshooting. The issue was the same with and without them.

Any insight appreciated. TIA.
2 REPLIES
Richard Brodie_1
Honored Contributor
Solution

Re: Procurve 2626 Spanning Tree

I would wonder whether your WAN connections forward STP. Does "show span detail" show any received BPDUs on the WAN ports?
brandonc
Occasional Contributor

Re: Procurve 2626 Spanning Tree

Indeed, it appears that the 100MB WAN link is not forwarding any BPDUs. That would not have occured to me. I get results like this on either side:

RSTP BPDUs Tx: 1502556

RSTP BPDUs Rx: 0


On the backup link, I get Tx and Rx on the connected ports.

Looks like I need to contact the carrier.

Thanks!