Port goes into Blocking mode and then 2 seconds later back to fowarding...

[Starsky73]

This has happened a couple times now. Most recently, with the management Cisco ASA firewall connection to the HP Procurve. Here is the problem description:

Log from HP Procurve 5412zl, version K.15.09.0009 :

09/05/13 11:40:36 00077 ports: port D12 is now off-line

I 09/05/13 11:40:36 00435 ports: port D12 is Blocked by STP

I 09/05/13 11:40:38 00076 ports: port D12 is now on-line

Interface D12 is the management connection to the ASA firewall.  From the ASA Firewall side, when I login, I see no SNMP traps indicating an interface went down. Nothing, things look fine.  But obviously on the procurve side, the above log on the procurve it spits this out.  So why would this interface just arbitrarily go through these set of STP events?  

The only reason I can think why it did not trigger an alert on the Firewall (and yes logging is enabled) is that the procurve port D12 when into a "blocking" STP state which I would assume does not physically disable, or bring down the port, hence the reason the ASA firewall did not trigger an alert, or any SNMP traps.

Nonetheless, I'm trying to find the root cause behind this. Why the procurve is acting in this fashion so that I can prevent future outages.  Fortunately this was not considered a critical outage, but an incident because this is the secondary firewall.  Ultimately, I want to figure it out before the procurve does this to a more critical device.  

My background stems from Cisco, so my HP Procurve knowledge is not nearly as deep, so any help or suggestions would be fantastic.  Also, I am an HP employee, so if you know of any type of support I can reach out internally please let me know.

Thanks,

Eric Townsend

[Richard Brodie_1]

This kind of report comes up from time to time here but apart from one time when there was a genuine physical connectivity problem, I've not seen anyone get to the bottom of it.

If it goes, online -> offline as it does here, I think that the port has just blipped off momentarily then trigged the spanning tree timer. If it were a fibre optic connection, it might just be that you had a unidirectional link momentarily.

Things that you could do:

1. Set the port to admin edge to bypass the 2s timer (not helping you on the root cause thing).
2. See if the Procurve generates link down traps when this happens, if they are enabled.
3. Keep digging. It's sadly rather rare that anyone from HP engineering picks up on comments here though.

[Starsky73]

Thanks for the suggestions.  I plan to get to the root of this and am putting a ticket in with HP Support. So folks if you have issues with your HP products you can go here and submit a request to get support from HP Engineers:

http://pro-networking-h17007.external.hp.com/us/en/support/converter/index.aspx

I'll provide updates to this post as they come along. Thanks.

-ET

[Peter_Debruyne]

Hi,

the stp messages do not seem the root cause, it is a link down which seems to be the root cause.

When a link comes up, you will always have stp doing its work and sending these messages (in this case, the port is auto-edge, which means : port up, listen 3 seconds if any bpdu IN is received, if received, transition to STP role (FW/discard based on stp topology), if no bpdu received (which indicates a non-stp devices), transition to FW > report Online)

So I would check on the cabling in this case, since a cable issue may result in an online on 1 side and reset on the other side.

You could try with sh int x to see any interface rx/tx errors (would do that on both HP and Cisco side).

Hope this helps,Peter.

[Starsky73]

Received a response from the HP Support Engineer, this is his response: “this is due to BPDU packets received by the link. Please try BPDU filter option on the switch and check." 

Personally, I don’t happen to agree.  STP is a layer-2 protocol and helps create a loop-free network topology. STP uses BPDU packets to elect a root bridge, calculate the best path to the root and block any ports that create loops and all that good stuff...the Cisco Firewall management interface is configured with an IP address and is operating at layer 3 which means it is not using STP (additionally, if it were using BPDUs, they are transmitted every 2 second (by default), yet we have only received this error once).

I happen to agree with Peter with the notion that there is a cabling issue.  I will choose this course of action and reply to the HP Support engineer telling him to take into consideration that the link is Layer 3 and there could be a cabling issue.

[sprindle]

I have a similar issue.  The difference is that I have an AP plugged into the port.

Checked cables etc., still receive this error: FFI: port 31-Excessive Broadcasts. See help.

Looking at the port I see this error continually followed by a port down, port up-online, FFI: port 31-Excessive Broadcasts. See help.

-sp

[Starsky73]

Hmmm...maybe turn it into a layer 3 interface? That'll stop the broadcasts.

-ET

[Richard Brodie_1]

You shouldn't go around believing what FFI tells you; it gives spurious messages on link up except on the very latest firmware.