CIST starved for a bpdu Rx on port 17, temporary fix I would like to know if modifying the Hello timer on specific port could fix at least temporary our problem ? We have a L2 link between 2 distant places and it seems the provider is dropping some traffic for a reason or another (they cannot or don't want explain to us exactly why since the bandwidth is not congested). We think some BPDU are dropped and thus, our HP switch computes again and again STP topology disabling/enabling switch's ports and causing networks issues. I'm no expert of STP and I know without perfect understanding of it, it is really tricky to tune. Since the topology modification are due to lack of BPDU from the root bridge, I want to try to allow more time waiting for this BPDU. Since I have no lab to test it properly, I wonder if someone already try it or can point me over the right line of thought. Thanks.

You cannot modify STP hello timer only for one port - it is timer for whole STP tree. Also this modification wil not help you - because if you have drops on this long link, you will have problem with STP anyway.

What you need to do?

If you have only one link, you can turn off STP for the both side for this link and split STP to two domains (one domain per site). You can do this by "bpdugilter" on the both sides of this link. In this case you can also implement a storm-control\any other protection for this link to be sure that problem in one site will not propogated to other site.

If you have two links between these places (for redundancy), you definitely need to avoid any L2 protocols between them. You need to implement IP routing and then, if you need Ethernet between two segments in the different sites, you can implement tunneling.

My experience say me, that the best answer in such case is MPLS, but maybe you cannot do this due to budget/equipment limitation.