Design question regarding STP

[gvb]

I have taken over administration of a LAN/WAN and am slowly cleaning up each function of the network one piece at a time. I've never really fully understood STP, or the concept of a root bridge.

I've got 8 sites connected in a ring topology using gigabit ethernet WAN links. Each site has a pair of core MSFC switches that handle all routing at each site. Each site has it's own VTP domain, and VLAN ID's are unique at each site. For the most part, all VLANs are localized with the exception of the WAN VLANs and a few that are trunked across the WAN for specific application requirements.

Currently the network is configured using PVST+ and there are no designated root bridges (found out the hard way when I plugged in an old 3548 which became the root bridge for a few VLANs). 60 second convergence times are not going to work in this environment.

This is my reconfiguration plan, and specific questions regarding my proposed plan:

- Ensure BPDU Optimization is disabled on all switches.

- Ensure extended system ID is enabled on all switches.

- Set MSFC1 at each site as the root bridge for all VLANs that live at that specific site using 'spanning-tree vlan 1-60 priority 0'.

- Set MSFC2 at each site as the root bridge for all VLANs that live at that specific site using 'spanning-tree vlan 1-60 priority 1'.

- Enable RPSVT+ on all switches.

- Enable BDPU Guard on all switches.

- Enable UDLD aggressive on all switches.

- Enable root guard on all uplink ports on all MSFC switches.

Questions:

1) Is the way I'm setting each MSFC as the root bridge for all VLANs at that site, the correct method? What do I do with the VLAN's that are used for the WAN links? Disable spanning tree for those specific VLANs?

2) Are there are issues with migrating from PVST+ to RPSVT+? I assume these are compatible, but I won't benefit fully from RPVST+ until all switches are set to use it.

3) BPDU Guard and UDLD will be enabled globally on all switches. Any issues here?

4) I don't think I fully understand Root Guard. if I enable Root Guard on a WAN port, will it cause issues because I SHOULD be seeing root BPDU's for VLAN's that live at other sites? Also, I do have switches at sites that are not directly connected to the MSFC's, do I need to go out and enable Root Guard on switches that are further down in the tree, or will enabling it on the MSFC's be enough?

Anything else I am missing to further enhance security, or reliability?

[ethiel]

Looks like you're on the right track here. A few things to make this go smoother:

1. That should work, but the global priority needs to increment by 4096, so your secondary should be priority 4096 instead. This is done because each VLAN priority ends up as the switch priority+vlan number, so the switch priority for VLAN 10 will be 10 on the primary and 5006 on the secondary.

1b. You never want to _disable_ STP for any VLANS. If you did, you could get loops. If your WAN is a true loop, all on the same VLAN so every switch can see every other switch on the loop, then there will have to be a blocked port somewhere along the loop. You will need to decide which segment would have the least traffic, and make the switches opposite of that link in the loop as the primary switches. A more desireable design would most likely be to convert your ring to a layer-3 ring. If each node in the ring had a point-to-point L3 link to the next node in the ring, then there would be no L2 blocking, and all site-to-site traffic would follow the best path according to your routing protocol. This design keeps you from sharing VLANs between sites, but it sounds like you don't do that anyways. L3 links with properly working UDLD give you the fastest possible convergence too, so that is a nice benefit. To get deeper into the details would require some review of your requirements and current layout, but it is definitely worth considering a L3 WAN. If you already have a L3 WAN, with the WAN VLANs only existing between 2 sites (e.g. site 1 and 2 share VLAN 12, site 2 and 3 share VLAN 23), then you should be fine with either switch being primary for each VLAN they are on. If that is the case though, you might consider setting up the Gi interfaces as true Layer 3 interfaces (no switchport) and getting rid of the VLANs altogether. This gives you the fastest convergence times.

2. RPVST+ is backward compatible, so I would recommend not running half and half long term, but for the transition period you will be fine.

3. I have had some issues with UDLD between 3560s and 6500s, the default settings used to be slightly different. I do not have the reference handy, but I think it was resolved in current IOSs. This was almost 2 years ago I ran into it. Be sure not to enable BPDUGuard on ports going to switches obviously.

-Eric

Please remember to rate all helpful posts.

[gvb]

Eric,

Thanks for the response!!

1) I think you've addressed all of my questions regarding the bridge priorities and WAN topology. I think I am going to have to stick with Layer 2 connectivity between sites because we do have a few VLANs that are trunked across WAN links for specific applications, etc... And yes, there is a separate VLAN for each each WAN link. I'll just choose the larger site, or the shortest path to the larger site as the root bridge for those WAN VLANs.

2) Check

3) All devices are 6500's, 4500's, or 3750's running current IOS. There are few legacy 3548's, but those will be pulled out before we make these changes, so I don't think we should have any issues with UDLD. I thought BPDU Guard only effected PortFast ports?

4) Any word on Root Guard in my environment? Still a little confused by that part.

[Francois Tallet]

Hi,

I have a comment on "- Ensure BPDU Optimization is disabled on all switches. ". This command only appears in the ios config as a result of a bug. It should be hidden, and the optimized bpdu transmission should be enabled (when possible, because the bug prevents its configuration on certain platforms). Anyway, this optimization is only relevant to pvst, it has absolutely no effect if you are running mst or rapid-pvst.

1) STP helps blocking redundant path at layer 2. If you don't have redundancy at layer 2 (if you don't have any vlan transported arount the wan ring) then in theory, you don't need stp. However, it is always recommended to keep it as a backup mechanism (to protect against cabling errors for instance). If you are sure that a link is never involved in a layer 2 physical loop, you can enable portfast on it. That will allow the link to go quickly to forwarding, as if stp was disabled, while keeping stp as a backup.

3) Yes, global bpduguard configuration is only kicking on ports that are operationally edge. As edge ports are not connected to switches, if bpduguard is configured globally, you are following de facto Eric's recommendation. If you are configuring it at the interface level, then it's not dependent on portfast configuration and you have to make sure that you only use it on a port where you don't expect any bpdu to be received.

4) It's not because rootguard exists that you need to use it;-) Rootguards prevents a port from becoming root, alternate or backup. Basically, it prevents you from accepting a better root on a given port. Pay extra care when using it: it could prevent stp from using an alternate path in case of failure. That's a feature that might be desirable in certain case. For instance, if you have a failure between two core bridges, it might be better to keep the network partitioned than attempting to restore connectivity between the cores via an access switch. Configuring rootguard on the core downlinks toward the access switch can achieve that.

Maybe you were thinking of loopguard (all these feature names are really confusing). Loopguard can be enabled everywhere safely, even if it only has an effect on root and alternate port. If you move to mst instead of rapid-pvst, there is a built-in mechanism that protects against unidirectional link failures better than loopguard. So for mst, I would not recommend you configure loopguard.

Regards,

Francois

[gvb]

Thanks Francois..

My reason for wanting to use Root Guard is to prevent something other than the two bridges I have designated as root and secondary root, from advertising a better BPDU on a non portfast ports. Even if the root is set to 0, a device with a lower MAC address will have a better BPDU.

Thinking about this a little more... If I have all edge ports set to portfast, and bpduguard enabled globally, the risk of something advertising a better BPDU doesn't really exist here since I control all switch uplink ports and the devices they are connected to. Sound correct? I assume Root Guard would be helpful for me if I had a switch uplink port and I didn't control the device on the other end.

Also, from what I can tell, Root Guard only works at a per interface level... this would prevent me from enabling it on WAN links since all sites are Root for the VLANs that live at those sites. Is that a correct statement?

[Francois Tallet]

That's right, bpguguard will shut down the port before you have a chance to check whether the bpdu is superior or not.

Also, as you said, rootguard is configured per-port. But it's not the only reason why I don't think you should not use it there.

Using rootguard will prevent STP from using a backup path to the root. For instance, in your wan ring, suppose there is a link failure between a primary and secondary switch on a given vlan. If you have configured rootguard on the non root ports on the secondary, then it won't be able to use its other ring connection to access the primary across the ring. By using rootguard, you are hardcoding a particular topology, and you are saying that you prefer losing connectivity than switching to another topology. There are not that many topologies in a ring: there is only one blocked port;-) If you want to ensure that the blocked port is always in one particular position and if you are ready to lose connectivity as a result of a failure, there is a very simple solution that does not involve rootguard: just remove the vlan from the allowed list of trunk where you want to block. That will do the trick.

Eventually, I would say that if you are not able to ensure that a wrongly configured switch cannot be inserted in your core wan ring, you have other problems than the stp topology;-)

So as a summary, I think that bpduguard is not a feature that you want to use in the core. It is mainly relevant to the links toward the access.

Regards,

Francois

[gvb · Accepted solution]

Thanks for everyones help! I plan on converting all layer 2 WAN links that don't require trunking to layer 3 links.

Here is my revised configuration change plan for your final review:

- Ensure BPDU Optimization is enabled

'spanning-tree optimize bpdu transmission'

- Ensure extended system ID is enabled

'spanning-tree extend system-id'

- Set MSFC1 to root bridge, and MSFC2 to secondary root bridge for all VLANs that live at that site.

'spanning-tree vlan xxx-xxx,xxx,xxx-xxx priority 0'

'spanning-tree vlan xxx-xxx,xxx,xxx-xxx priority 4096'

- Set WAN VLAN bridge priorities on MSFCs, closest to Corporate Office should be root.

'spanning-tree vlan 99x priority 0'

'spanning-tree vlan 99x priority 4096'

- Enable RPSVT+ on all switches.

'spanning-tree mode rapid-pvst'

- Enable BDPU Guard globally on all switches.

'spanning-tree portfast bpduguard default'

- Enable UDLD globally on all switches.

'udld enable'

- Enable UDLD aggressive on all switch uplink ports.

'udld enable'

'udld aggressive'

- Enable Loop Guard on all root and alternate ports, for all possible combinations of active topologies.

'spanning-tree guard loop'