STP- BKN

Unanswered Question
Jul 11th, 2007

Dear colleagues

I have two core switches 6513 and 30 access switches (Edge switches) 2950T connected to these core switches.

Each access switch have two VLANs one for hosts (different by switch) and other for Management (Common for all switches VLAN 20)

When I run the command show spanning-tree [in 6500] I found the following result:

--------------------------------------------------------------------------------------------------------------------

VLAN0001

Spanning tree enabled protocol rstp

Root ID Priority 32769

Address 0015.c719.ee00

Cost 3

Port 1668 (Port-channel7)

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)

Address 0016.9c0f.a040

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Aging Time 300

Interface Role Sts Cost Prio.Nbr Type

---------------- ---- --- --------- -------- ------------------------------

Gi9/1 Desg BKN*4 128.1025 P2p Peer(STP) *ROOT_Inc

Gi9/2 Desg BKN*4 128.1026 P2p Peer(STP) *ROOT_Inc

Gi9/3 Desg BKN*4 128.1027 P2p *ROOT_Inc

Gi9/4 Desg BKN*4 128.1028 P2p Peer(STP) *ROOT_Inc

Gi9/5 Desg BKN*4 128.1029 P2p *ROOT_Inc

Gi9/6 Desg BKN*4 128.1030 P2p *ROOT_Inc

Gi9/7 Desg BKN*4 128.1031 P2p *ROOT_Inc

Gi9/8 Desg BKN*4 128.1032 P2p Peer(STP) *ROOT_Inc

Gi9/9 Desg BKN*4 128.1033 P2p *ROOT_Inc

Gi9/10 Desg BKN*4 128.1034 P2p Peer(STP) *ROOT_Inc

Gi9/11 Desg BKN*4 128.1035 P2p *ROOT_Inc

Gi9/12 Desg BKN*4 128.1036 P2p Peer(STP) *ROOT_Inc

Gi9/13 Desg BKN*4 128.1037 P2p *ROOT_Inc

Gi9/14 Desg BKN*4 128.1038 P2p *ROOT_Inc

VLAN0020

Spanning tree enabled protocol rstp

Root ID Priority 24596

Address 0016.9c0f.a040

This bridge is the root

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 24596 (priority 24576 sys-id-ext 20)

Address 0016.9c0f.a040

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Aging Time 300

Interface Role Sts Cost Prio.Nbr Type

---------------- ---- --- --------- -------- ----------------------------

Gi9/1 Desg FWD 4 128.1025 P2p Peer(STP)

Gi9/2 Desg FWD 4 128.1026 P2p Peer(STP)

Gi9/3 Desg FWD 4 128.1027 P2p

Gi9/4 Desg FWD 4 128.1028 P2p Peer(STP)

Gi9/5 Desg FWD 4 128.1029 P2p

Gi9/6 Desg FWD 4 128.1030 P2p

Gi9/7 Desg FWD 4 128.1031 P2p

Gi9/8 Desg FWD 4 128.1032 P2p Peer(STP)

Gi9/9 Desg FWD 4 128.1033 P2p

Gi9/10 Desg FWD 4 128.1034 P2p Peer(STP)

Gi9/11 Desg FWD 4 128.1035 P2p

Gi9/12 Desg FWD 4 128.1036 P2p Peer(STP)

Gi9/13 Desg FWD 4 128.1037 P2p

Gi9/14 Desg FWD 4 128.1038 P2p

---------------------------------------------------------------------------------------------------------------------------------

I apply [spanning-tree guard root] from the core (6500) interface side.

Any change in priority of VLAN 1 make a lot of switches 2950 up links interfaces enter in err-disable mode.

can anyone help, to let me understand what happen?

Regards

Rami Azem

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (1 ratings)
Loading.
Edison Ortiz Wed, 07/11/2007 - 07:44

You need to make sure this switch is the root of all VLANs before entering the guard root command.

On the 6500, issue a

spanning-tree vlan 1-1001 priority 0

Francois Tallet Wed, 07/11/2007 - 09:20

Hi Rami Azem,

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.

Regards,

Francois

ramifahim Thu, 07/12/2007 - 02:09

Hi Francois

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.

Thanks

Rami azem

Francois Tallet Thu, 07/12/2007 - 07:55

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).

Regards,

Francois

Actions

This Discussion