Root guard, RSTP, and customer networks

[Mister Cartwright]

I am curious what the best way to handle connections to customers on a switched network where we deploy root guard. I have inserted an image below of an example of what our switch network looks like. We provide redundant layer 2 drops to a customer from different L2 switches, and they connect to us using a switch. We run RSTP using Cisco switches, and the ports are in access mode. The problem is that their redundant port is being put into a broken state due to root-guard. Please see my questions/comments below the picture.

1. Ideally all customers would connect to us using a L3 device, but this is not always possible.
2. It appears the BPDUs from our root bridge are being sent back to us, triggering the error. I understand this can happen if they disable STP, but what if they enable STP? Wouldn't their switches still send our BPDUs back to us?
3. What is the ideal configuration we should recommend to our customers in this scenario? Run STP using default root priority? So that their switch blocks one of the ports on their side going up to us, instead of us blocking one of the ports going down to them?

[paul driver]

Hello

You dont say what stp mode you are using the nevertheless I am assuming its pvst.

Enable stp throughout estate

L3 primary switch - set stp root primary 

L3 secondary switch -set  stp root secondary

L3 Primary & secondary switches - Ports connecting to distribution apply guard-root

Distribution Primary & Secondary apply stp backbonefast/uplinkfast

Distribution Primary & Secondary apply connecting to customer switches apply guard-root

Customer switches - apply stp uplinkfast/loopguard/bpduguard.

I would also enable errdisable recovery which will let you know when there is a problem with the port for the specific cause and can automatically try to reenable the port if the problem is corrected.

errdisable recovery cause xxx
errdisable recovery interval xxx

Please note in RSTP
Backbonefast/uplinkfast are not required

Please don't forget to rate any posts that have been helpful.

Thanks.

[rais]

Customer switch may run STP with your network. They can configure max. switch priority on their switch.

Thanks.

[Mister Cartwright]

We are running RPVST throughout our switches. Customers manage their own equipment however, so we have no idea what they are running (and often, neither do they).

Most of what you suggest we are already doing, but I don't see why we would want to do this part:

L3 Primary & secondary switches - Ports connecting to distribution apply guard-root

I don't see the reason for doing that. Since we control all of our switches, we ensure that the L3 Primary and Secondary switches are set to the proper priority's. So there is never a chance that one of our Distribution switches will try to be root. And blocking the port on a downlink to a Dist versus on a downlink to a customer port does not seem to gain us anything. Also, with root-guard on the customer-facing ports, those incorrect BPDUs would never make it upstream anyway.

Those errdisable commands are helpful I agree, but not in this particular example. WIth BPDU Guard, the port either needs to be manually re-enabled or you use the errdisdable recovery like you mentioned. In Root Guard, it will happen automatically as stated in the section "What Is the Difference Between STP BPDU Guard and STP Root Guard?"

in this doc http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00800ae96b.shtml#diff

I also think that those erridisable commands in this case would not help, because the port is not being put into errdisable mode, it's being put into STP broken mode. At least based on the output of the show interface / show spanning interface commands, the output is different.

But none of that helps me address this paritcular problem with the customer. I will find out if they are running STP at all, because I don't think they are. But if they do, won't their switch continue to send our low-priority BPDU's back to us? Or should their switch put one of their ports into blocking mode, thereby preventing that from happening?

Thanks,

[paul driver]

Hello

Okay misread your post - But what are you asking that you haven't already done, It seams you have setup all the relevant protection  on the devices you manage?

Root-guard is doing its job as intended and making sure your distribution switch ports on the customer interlinks  dont become root ports, which  means your distribution ports are seeing bpdu's with lower stp values.

What can be done?

Distribution switches - apply a lower stp bridge priority other than the default but not to low that in hinders your stp root/secondary's

Customer switches - Enable stp  (RSTP if applicable) with a higher stp bridge priority + enable udld and loopguard +portfast/bpduguard for all access ports

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

[Mister Cartwright]

Sorry, I could've worded my question a bit better. Is it really just as simple as having the customer enable STP? What if they are running 802.1D and not RPVST? I ask because I had a customer enable STP and his primary port went into blocking on his side, while apparently his secondary port stayed in broken mode on our side, taking his environment down. What I had read was that root guard will lift the broken condition the instant lower priority BPDUs stop coming through, but it apparently did not do that. So I was thinking there must be more to the equation, or some best practice I am missing.

I have asked the customer to schedule a window with me so we can make the change together, so I can see what happens.

Thanks for your responses.

[paul driver]

Hello

What if they are running 802.1D and not RPVST? - then the distribution switch connected to the customer switch will fallback to pvst mode and go though the slower  listeniing/learning/forwarding states of pvst for that interconnect link

What I had read was that root guard will lift the broken condition the instant lower priority BPDUs stop coming through -
The root-guard feature prohibits the port its configured on from becoming a root port for a another switch - basically it acts to any stp changes which it equals to unforeseen superior  bgdu's - once these cease the port comes out of an inconsistant state and contines forwarding

So basically you would want to have this enabled on the distrubution switches towards the customers switches as you dont want the customer switch ever becoming a designated port for that lan segment.

FYI -The Bpduguard  feature acts to any stp activity arriving on a port that it shouldn't be there.

Sounds like I just need to work with customer on getting STP enabled and make sure their secondary port gets moved from broken to forwarding. For some reason I thought it was more complicated than that.
Ask them to enable stp  (RSTP if applicable) with a higher stp bridge priority than the default.

Apply udld and loopguard (if using pvst+ also enable uplinkfast/backbonefast)

For the access ports apply portfast/bpduguard.

Note in pvst mode:

uplinkfast increases the bridge priority automatically and also the port costs by 3000

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

[useridcisco1]

start using
spannning-tree bdufilter enable, on port connecting to customers,
use it with caution, make sure not to have physical loop on bdufilter enabled ports.

Sent from Cisco Technical Support Android App

[pille1234]

Looking at the topology above BPDU Filter wouldn't be the smartest idea, would it?

One could try to configure the lowest possible bridge priority on the root bridge, that would at least reduce the possibility of a rogue switch trying to take over root.

[Mister Cartwright]

In this case the Distribution SW (secondary) is seeing the root BPDUs being sent down to the customer from the Distribution SW (primary), so just lowering our root priority wouldn't do anything. Sounds like I just need to work with customer on getting STP enabled and make sure their secondary port gets moved from broken to forwarding. For some reason I thought it was more complicated than that.