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.
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.
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.
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?
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:-(
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 ...