I've just been reading up on STP root guard, and whilst I'm sure there are plenty, I'm struggling to see scenario's where you would use this over bpdu guard.
If you are talking about access ports accessible outside of a secured wiring closet, then I'm guessing bpdu guard would be the most suitable protection. Otherwise I could only really see root guard being used in a comms room to protect against misconfiguration by an administrator...
Is anybody able to give some examples of where you would use root guard over bpdu guard in a real world scenario?
Practically there will be unused switch ports in default Dynamic desirable mode. There can be chance that admin/other employee connect an old switch (having lower priority) to the switch port and negotiate a truck. The newly added switch can become the STP root.
Hope this helps.
Thanks for this. In this instance though, would you not be better off using bpdu guard, thus preventing the switch from being connected with a poor or incorrect configuration?
From what I've read, it sounds to me as though root guard isn't really a security feature, it's just a means to enforce your topology design. I realise that could well make it a security feature to prevent somebody maliciously changing your topology, but in the instance you mention above somebody would have to have physical access to a switchport and ultimatley ownership of the device being attached.
However, I would have assumed the following:
Is root guard something that would be more prevelant the more switches you chain off of one and other, and less prevelant in a core & access design?
BPDU guard and root guard are similar, but their impact is different. BPDU guard disables the port upon BPDU reception if PortFast is enabled on the port. The disablement effectively denies devices behind such ports from participation in STP. You must manually reenable the port that is put into errdisable state or configure errdisable-timeout.
Root guard allows the device to participate in STP as long as the device does not try to become the root. If root guard blocks the port, subsequent recovery is automatic. Recovery occurs as soon as the offending device ceases to send superior BPDUs.
Hope it will help.
Thanks. I'd seen that, but I'm still confused with a scenario where you would want to prevent STP being dynamic in it's election of a new root by using root guard.
I can only assume that this scenario would be that you would conclude operationally you would accommodate up to x amount of root bridge failures, and after x it's likelihood of further failure is reduced to the point where it doesn't justify the security risk?
Basically, the Root Guard is a feature more interesting in scenarios where you interface a separate, independent switched domain operated by someone else but for whatever reason, you need to have a single STP instance that interoperates across both your and the "neighbor" domain. It is your requirement that whatever the neighbor does, he may not overthrow your root switch - you are the domain that holds the root and you do not want that ever to change. In these cases, the Root Guard is something that allows you to interoperate your STP with the neighbor's STP but it still prevents the neighbor from hijacking your root.
This may be a situation more typical for large enterprises or service providers but I admit, it is quite rare.
If the root guard is enabled on the interface, it ensure that the port is designated port and if this port recieves the bpdu, it puts the port in root-inconsistent state which means listening state (no way to forward the traffic through it)...i donnt think i can negotiate that port to become trunk...regards