Problem with STP

[wilsonsant]

Hi Guys,

We are have a problem with Spane tree Protocol. In this router appear the message ininterrupet:

Sep 1 23:24:07.400 GMT-3: %SPANTREE-SP-6-PORT_STATE: Port Gi2/5 instance 10 moving from forwarding to blocking

Sep 1 23:24:07.400 GMT-3: %SPANTREE-SP-6-PORT_STATE: Port Gi2/5 instance 11 moving from forwarding to blocking

Sep 1 23:24:07.400 GMT-3: %SPANTREE-SP-6-PORT_STATE: Port Gi2/5 instance 12 moving from forwarding to blocking

Sep 1 23:24:07.400 GMT-3: %SPANTREE-SP-6-PORT_STATE: Port Gi2/5 instance 13 moving from forwarding to blocking

Sep 1 23:24:07.624 GMT-3: %SPANTREE-SP-6-PORT_STATE: Port Gi2/5 instance 10 moving from blocking to forwarding

Sep 1 23:24:07.624 GMT-3: %SPANTREE-SP-6-PORT_STATE: Port Gi2/5 instance 11 moving from blocking to forwarding

Sep 1 23:24:07.624 GMT-3: %SPANTREE-SP-6-PORT_STATE: Port Gi2/5 instance 12 moving from blocking to forwarding

Sep 1 23:24:07.624 GMT-3: %SPANTREE-SP-6-PORT_STATE: Port Gi2/5 instance 13 moving from blocking to forwarding

But, I don't know where start the investigation. Somebody have any Idea?

Thank You,

Wilson

[simontibbitts]

Hi Wilson.

I'd be interested on seeing the STP statistics for that port and the configuration.

Collect the command below twice with a few seconds inbetween each command (Where x is your VLAN)

show spanning-tree vlan x interface Gi2/5 detail

The last set of counters show the received BPDU statistics, work out between the two commands how many BPDUs you received in those few seconds. If the number increased a bit then this might be the problem.

- Simon

[wilsonsant]

Hi Simon,

I did the tests and there are incresed any bit in the interval few minutes.

Thank You,

Wilson

[simontibbitts]

Sorry Wilson, I don't understand,

Did the BPDU counter increase?

or did the BPDU counter NOT increase?

Simon

[wilsonsant]

Hi Simon,

I did the test bellow:

ALD-CE-ROTNGN-OI-01#SH SPanning-tree vlan 701 interface giga2/5 detail0 interface giga2/5 detail2 interface giga2/5 detail

Port 133 (GigabitEthernet2/5) of MST13 is designated forwarding

Port path cost 20000, Port priority 128, Port Identifier 128.133.

Designated root has priority 8205, address 0016.9c6d.a140

Designated bridge has priority 8205, address 0016.9c6d.a140

Designated port id is 128.133, designated path cost 0

Timers: message age 0, forward delay 0, hold 0

Number of transitions to forwarding state: 67283

Link type is point-to-point by default, Internal

BPDU: sent 134142, received 404290

ALD-CE-ROTNGN-OI-01#

ALD-CE-ROTNGN-OI-01#

ALD-CE-ROTNGN-OI-01#

ALD-CE-ROTNGN-OI-01#SH SPanning-tree vlan 702 interface giga2/5 detail

Port 133 (GigabitEthernet2/5) of MST13 is designated forwarding

Port path cost 20000, Port priority 128, Port Identifier 128.133.

Designated root has priority 8205, address 0016.9c6d.a140

Designated bridge has priority 8205, address 0016.9c6d.a140

Designated port id is 128.133, designated path cost 0

Timers: message age 0, forward delay 0, hold 0

Number of transitions to forwarding state: 67285

Link type is point-to-point by default, Internal

BPDU: sent 134146, received 404304

Thank You,

Wilson

[simontibbitts]

Thanks Wilson.

This is your problem, you need to investigate the switch attached to this port to work out why it is sending so many BPDUs, To stop the problem straight away you can just filter BPDUs on that port. 'spanning-tree bpdufilter enable'

Of course, however make sure it does not affect your STP tree. If this port should not be connecting to another switch then its not a problem.

Check out this link for a description of the situation. Its under the heading 'Attack 2: DoS Using a Flood of Config BPDUs' Its a known DoS attack.

http://www.ciscopress.com/articles/article.asp?p=1016582&seqNum=2

Simon

[Francois Tallet]

Please, don't filter BPDUs, that would essentially mean disabling STP on this interface and could result in permanent loop if you have redundancy.

In MST, it is usual to have a port both sending and receiving BPDUs, as it can have different roles on different instances.

However I agree that it is not normal that this port receives that many BPDUs. What is connected on the other side? BPDUs are normally rate limited. The standard allows for a short burst then you should not get more than one BPDU per second (Cisco is a little bit more aggressive by default and allow something like 7 BPDUs per second in MST mode I think, it can be configured).

I would recommend you try to clarify what's happening on the other side first.

Regards,

Francois

[wilsonsant]

Hi François,

There are equipment of another vendors in this solution. I asked for my customer the Topology of Network, but, He not still send for me. I Believe that it's impossible solve this problem without the Topology of Network, wright?

Thank You,

Wilson

[Francois Tallet]

Hi Wilson,

It's more than the topology you need here I'm afraid. It's true that it's difficult to troubleshoot STP over different administrative entities. In a provider/customer environment, many provider choose to tunnel their customer's STP instead of peering with it.

Now, if you are absolutely sure on your side that this customer is not connected redundantly to your network, you can indeed filter BPDUs and de facto disable STP. I guess that if you are peering, it's because you have some form of redundancy. Your only choice is thus to have the customer cooperate in the troubleshooting. Hopefully, because their interface is flapping on your side, they should have some interest in doing so too;-)

Honestly, I have no clue of what the problem can be with this information. You should receive a "reasonable" rate of BPDUs on your interface. It seems that it far excessive (but I'm not sure, as I don't have an timing information). The MST information is not consistent, and because of that, the port has its state flapping. Sorry, that's as much as I can tell:-(

Regards,

Francois