You have to be careful to what you want to achieve with root guard. Basically, root guard prevents a port from accepting better information on a port. A port with root guard configured will not become root or alternate: it will fall into the "broken state" you are seeing.
Very often, root guard is used as a protection mechanism, in order to prevent a particular neighbor (that we don't trust for instance) from injecting stp information in the network. It is also common to configure it on the access facing ports, to prevent access bridge from providing connectivity between core or distribution switches.
Do you have a layer 2 link between your two core switches? If seems that the core switch is receiving better root information from the ports connected to the access switches, where you configured root guard.
So make sure you have a link between the two cores. Make sure that the cost of this link (between the two cores) is lower than the cost of the path between the two cores through an any access switch (else, this path will be disabled by root guard).
Also, be aware that root guard is an exception to normal stp processing. In your example for instance, if you have a single link configured between your cores and root guard configured on all the links toward the access bridge, should the inter-core link fail, your network will be partitioned. This is because root guard will prevent the access bridges from connecting the two cores. This is generally the desired effect, but in that case, redundancy is provided in the core to cover the case of the inter-core link failure.
Yes we have layer two and layer three links between core switches, and I take care to make one of these core switches a root for some used VLANs and the other one root for the remaining used VLAN.
Now when I tray to make the root bridge of VLAN 1 (unused VLAN) one of the core switches, all access switches up link interfaces become error disable.
And when I tray to increase the priority of VLAN 1 more than default (32769) in one of the access bridges also I got the same result before [the up links gone in the error disable mode] and I surprised that some of other access bridges up links which I did not change any things in it also gone in error disable mode.
I reset the up links interfaces and got the same result.
I found that any changes in the topology of VLAN 1 make all up links interfaces for the access bridges gone in error disable mode.
Kindly do your best to help because it is critical situation.
If this is a critical situation, the first recommendation I would give would be to remove your rootguard configuration. This is definitely not a required feature and you can avoid it until you are more familiar with it (you should interview the person who is pushing for this configuration if it is not you;-)
Else, it's just a matter of cost. The problem is probably that your core bridge is trying to put some rootguard enabled port in alternate role.
The simplest is to increase the cost on the uplinks of your access switches (use the cost command or configure uplinkfast on the access switches and it should take care of this).
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...