Spanning-Tree advanced features

vinbuck

Does anyone have a concise guide or diagram that shows where all the advanced spanning-tree features are supposed to be implemented in the Distribution/Access layers? Been reviewing this, but haven't found a good all-in-one source.

What I have so far (please feel free to correct as these are off the top of my head):

BackboneFast: All switches in the network
UplinkFast: Access layer links to distribution layer
PortFast: End hosts or devices incapable of starting a bridging loop
BpduGuard: any port where switches should not be connected to (access and distribution?)
BpduFilter: any port where spanning tree should be disabled completely (access and distribution?)
LoopGuard: prevents any non-designated port from transitioning to forwarding if bpdus are no longer received (access and/or distribution?)
RootGuard: prevents the port from ever becoming root by placing it in an inconsistent state if a superior BPDU is received (distribution only?)

I've gotten a good handle on what they do but still trying to sort out the "best practice" on where to apply each.

Forsaken_GA

BackboneFast and UplinkFast are fairly self explanitory as to where they should be enabled.

Portfast should be enabled on any edge port.

BPDUFilter/Guard should also be deployed on the edge. The idea behind them is to prevent unauthorized layer 2 boxen from participating in and influencing your spanning tree.

Loopguard is essentially a software check UDLD... you do not want a unidirectional link transiitoning from Altn or BLK to Root for example. You can technically enable loop guard on everything. for DP's it won't matter, for non-DP's it will. Fair warning - I've seen Loopguard cause some issues during times of heavy convergence. Few late BPDU's and loopguard thinks the link has gone unidirectional.

Rootguard I used to enable this on the edge, but I've found the combination of BPDUFilter/Guard is adequate. I don't care if a device on the edge is sending superior BPDU's, if an edge port is receiving ANY BPDU's, that's a problem and I want the damn thing shut down. I use Root guard to enforce the choice of root in the distribution and core layers

vinbuck

Forsaken_GA wrote: »

BackboneFast and UplinkFast are fairly self explanitory as to where they should be enabled.

Portfast should be enabled on any edge port.

BPDUFilter/Guard should also be deployed on the edge. The idea behind them is to prevent unauthorized layer 2 boxen from participating in and influencing your spanning tree.

Loopguard is essentially a software check UDLD... you do not want a unidirectional link transiitoning from Altn or BLK to Root for example. You can technically enable loop guard on everything. for DP's it won't matter, for non-DP's it will. Fair warning - I've seen Loopguard cause some issues during times of heavy convergence. Few late BPDU's and loopguard thinks the link has gone unidirectional.

Rootguard I used to enable this on the edge, but I've found the combination of BPDUFilter/Guard is adequate. I don't care if a device on the edge is sending superior BPDU's, if an edge port is receiving ANY BPDU's, that's a problem and I want the damn thing shut down. I use Root guard to enforce the choice of root in the distribution and core layers

Thanks for the info man...probably should have been more specific as I'm trying to figure out what Cisco considers "best practice" for advanced spanning-tree. I know you're an SP guy so it's not uncommon to have Layer 2 in the core, but in the Gospel of Enterprise Network Design according to Cisco, the core should be all Layer 3. Learning the Enterprise way, Cisco's way has been an exercise in patience for me as I am not an Enterprise guy and don't think that way....

Forsaken_GA

vinbuck wrote: »

Thanks for the info man...probably should have been more specific as I'm trying to figure out what Cisco considers "best practice" for advanced spanning-tree. I know you're an SP guy so it's not uncommon to have Layer 2 in the core, but in the Gospel of Enterprise Network Design according to Cisco, the core should be all Layer 3. Learning the Enterprise way, Cisco's way has been an exercise in patience for me as I am not an Enterprise guy and don't think that way....

Oh, I was an Enterprise guy long before I was an SP guy, and these features don't apply to CMTS. What I described above are *my* best practices from experience doing it.

And just be aware that virtualization changes the game significantly. If you need layer 2 adjacency across the WAN for VM migration purposes, you don't have the luxury of keeping layer 2 out of your core.

vinbuck

Forsaken_GA wrote: »

Oh, I was an Enterprise guy long before I was an SP guy, and these features don't apply to CMTS. What I described above are *my* best practices from experience doing it.

And just be aware that virtualization changes the game significantly. If you need layer 2 adjacency across the WAN for VM migration purposes, you don't have the luxury of keeping layer 2 out of your core.

That or you just have to run a few thousand xconnects across your MPLS core . I keep running into differing practices on some of these features with respect to the SWITCH objectives. It's one of the few areas I don't feel completely solid on...especially for all the ______ guard features...the details are fuzzy for me on which ones Cisco wants to be access or distribution with respect to the SWITCH exam.

Forsaken_GA

vinbuck wrote: »

That or you just have to run a few thousand xconnects across your MPLS core . I keep running into differing practices on some of these features with respect to the SWITCH objectives. It's one of the few areas I don't feel completely solid on...especially for all the ______ guard features...the details are fuzzy for me on which ones Cisco wants to be access or distribution with respect to the SWITCH exam.

Alot of these are common sense.

Well, backbone fast is easy, it has to be on everywhere in order to work.

Uplinkfast, really, you can enable it everywhere that you have a port in the Blocking state. It's kind of like portfast for your uplinks instead of your edge ports. If you've only got one Uplink, you obviously don't enable uplink fast, but if you do, it allows you to pull the port out of Blocking quicker and get the network running, so it's a distro/access technology.

Postfast you can *only* enable at the access layer, as any received BPDU's cause a port to lose it's portfast status. BPDUGuard/Filter are likewise access layer technology, you try enabling them in them in distribution or core, your spanning tree will break.

Loopguard is basically the same as Uplinkfast, enable it wherever you have multiple links, because you positively do not want a unidirectional link transitioning to the root port. Access layers have root ports, so they get it too.

Root guard is the only really tricky one. It can be applied at the access layer, and alot of folks do. I don't anymore because it's extra configuration for no gain. It is definitely appropriate in the distribution, because you do not want someone turning up a new switch, or making configuration changes, to accidentally screw up and alter the networks root bridge.

Another way to figure it out is to go look at RSTP. Alot of these features are built in automatically, and see where they're enabled, that can provide some context clues.

ColbyG

Forsaken_GA wrote: »

BackboneFast and UplinkFast are fairly self explanitory as to where they should be enabled.

Portfast should be enabled on any edge port.

BPDUFilter/Guard should also be deployed on the edge. The idea behind them is to prevent unauthorized layer 2 boxen from participating in and influencing your spanning tree.

Loopguard is essentially a software check UDLD... you do not want a unidirectional link transiitoning from Altn or BLK to Root for example. You can technically enable loop guard on everything. for DP's it won't matter, for non-DP's it will. Fair warning - I've seen Loopguard cause some issues during times of heavy convergence. Few late BPDU's and loopguard thinks the link has gone unidirectional.

Rootguard I used to enable this on the edge, but I've found the combination of BPDUFilter/Guard is adequate. I don't care if a device on the edge is sending superior BPDU's, if an edge port is receiving ANY BPDU's, that's a problem and I want the damn thing shut down. I use Root guard to enforce the choice of root in the distribution and core layers

Where/how are you using Filter?

Forsaken_GA

I use Filter on edge ports, along with Portfast. There is absolutely no reason to be sending out BPDU's on ports where only hosts are supposed to reside. I don't want the extra link utilization, and more importantly, I don't want information about my STP topology leaking down to the edge.

ColbyG

Forsaken_GA wrote: »

I use Filter on edge ports, along with Portfast. There is absolutely no reason to be sending out BPDU's on ports where only hosts are supposed to reside. I don't want the extra link utilization, and more importantly, I don't want information about my STP topology leaking down to the edge.

You using it globally or at the interface level? You're not concerned with the lack of loop detection when using Filter? I've seen maybe one scenario in my career where Filter made sense.

Forsaken_GA

ColbyG wrote: »

You using it globally or at the interface level? You're not concerned with the lack of loop detection when using Filter? I've seen maybe one scenario in my career where Filter made sense.

What loop? I use it along with BPDU guard. These are edge ports, there should *never* be another switch there. If an edge port starts receiving BPDU's, I want the bastard shut down. Using Guard and Filter at the interface level gives me absolutely no concerns for a loop, it'll never be able to form.

Again, these are edge ports only. I obviously do not enable these on anything that connects to a device I actually want participating in Spanning Tree.

ColbyG

Forsaken_GA wrote: »

What loop? I use it along with BPDU guard. These are edge ports, there should *never* be another switch there. If an edge port starts receiving BPDU's, I want the bastard shut down. Using Guard and Filter at the interface level gives me absolutely no concerns for a loop, it'll never be able to form.

Again, these are edge ports only. I obviously do not enable these on anything that connects to a device I actually want participating in Spanning Tree.

Filter will override Guard if applied at the interface level. You should definitely lab this yourself (I have - I'll PM you the results) and reconsider.

Forsaken_GA

ColbyG wrote: »

Filter will override Guard if applied at the interface level. You should definitely lab this yourself (I have - I'll PM you the results) and reconsider.

Ah crap, no, you're right, I had them flipped. I do filter global just to prevent the bpdu's going out, and guard on the interface to prevent them coming in

ColbyG

Forsaken_GA wrote: »

Ah crap, no, you're right, I had them flipped. I do filter global just to prevent the bpdu's going out, and guard on the interface to prevent them coming in

That's a pretty interesting combination. I've never tried it as I haven't cared much about people seeing my BPDUs (On a side note, do you disable CDP at the edge? CDP seems scarier to me.) But it might be worth using in future.

So what happens if a user connects two wall ports together? IIRC, Filter sends out a couple BPDUs when the port comes online, right? If my memory isn't wrong, I suppose you're relatively risk-free. I'll do some research.

Forsaken_GA

ColbyG wrote: »

That's a pretty interesting combination. I've never tried it as I haven't cared much about people seeing my BPDUs (On a side note, do you disable CDP at the edge? CDP seems scarier to me.) But it might be worth using in future.

So what happens if a user connects two wall ports together? IIRC, Filter sends out a couple BPDUs when the port comes online, right? If my memory isn't wrong, I suppose you're relatively risk-free. I'll do some research.

Right, when it's globally enabled, it'll send out a few BPDU's, but that I can live with. If another port that sends out BPDU's is attached when it comes online, BPDU guard will catch them and put the interface in err-disabled.

Whether or not I disable CDP at the edge depends entirely on whether or not I've got any Cisco phones downstream.

NetworkVeteran

vinbuck wrote: »

BackboneFast: All switches in the network
UplinkFast: Access layer links to distribution layer
PortFast: End hosts or devices incapable of starting a bridging loop

In a real network, the best practice would be to not use any of the above features. That's because you're likely running RSTP or MSTP for fast convergence, and all the above features are obsoleted by those. The latest RSTP standard came out way back in 2004, so RSTP has been out in the wild and proven for a long time now. Note, you will still use the spanning-tree portfast syntax, but if RSTP/MSTP are enabled, it actually configures the port as an edge port per the latest 802.1D standard.

vinbuck

NetworkVeteran wrote: »

In a real network, the best practice would be to not use any of the above features. That's because you're likely running RSTP or MSTP for fast convergence, and all the above features are obsoleted by those. The latest RSTP standard came out way back in 2004, so RSTP has been out in the wild and proven for a long time now. Note, you will still use the spanning-tree portfast syntax, but if RSTP/MSTP are enabled, it actually configures the port as an edge port per the latest 802.1D standard.

I agree with you as far as real world, but CCNP SWITCH isn't always real world and it's focused on the Enterprise model as Cisco sees it, which is what i'm trying to prepare for. In my shop, Layer 2 is spread across several vendors and Cisco isn't the predominant one, so I am most familiar with MSTP and some proprietary enhancements that we use with it. However, except for the "Edge/Portfast" feature, I haven't had to use most of this stuff in production because I rarely work in the Enterprise world.