04-01-2013 11:37 AM - edited 03-07-2019 12:34 PM
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.
04-01-2013 12:21 PM
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.
04-01-2013 12:36 PM
Customer switch may run STP with your network. They can configure max. switch priority on their switch.
Thanks.
04-01-2013 01:22 PM
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,
04-01-2013 02:51 PM
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.
04-02-2013 06:46 AM
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.
04-02-2013 07:45 AM
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.
04-01-2013 02:30 PM
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
04-01-2013 02:47 PM
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.
04-02-2013 06:51 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide