Looking for HF2 error data - Important (Page 1 of 2)

By the way, if NION only LAN port working ,cobranet port not working ,this problem didn't have.If Nion lose xdab ,it also have.

Last edited by zhangye (2008-06-28 05:57:07)

I am also currently experiencing this problem with one of our systems. The system previously worked without issue. This problem started after an upgrade where we added a CAB and two switches.

In response to your questions:

1. I currently have no idea as to the cause, much less how to reproduce it.

2. The fault can occur two times a day, or not for several days in a row. I have made no progress in determining the conditions which cause it.

3. Same as above, I have tried several attempts to make some sort of change in the errors. If not to outright fix it, but perhaps to cause it to move to the other n3 in the system.

The only consistent symptom I have found is that the fault always occurs with the same n3. I've moved bundles around and even replaced the unit altogether to no avail. I currently have swapped that n3's Cobranet connection with another unit to see if the problem moves. If I get feedback showing no change in the problem, my next step is to temporarily install a laptop with a network monitoring program to try and capture all non-Cobranet traffic on the port connected to the faulting n3's Cobranet port.

If you have more specific questions regarding the network, system, etc. I can provide more detail as you require.

Zhangye,

MSTP is a newer variant of STP that allows separation of spanning tree domains and allows greater efficiency. However, the core protocol used underneath this scheme is RSTP. RSTP has been proven to  be a cause of the HF2 error. If you can, try disabling MSTP and/or RSTP and use standard spanning tree and see if this eliminates HF2 errors. This is (hopefully) a temporary fix. We are working with Cirrus right now to try to get this problem fixed.

We have been try to disabling MSTP,it is also have this problem.Our testing result is when stp changed  it will have this problem.Our use H3C switch. Huawei and 3com combina is H3C.We didn't enable RSTP.We testing have three core switch and one edge switch.Both of core switch have double fibre optic cables.12 Nions connect to the edge switch.The edage swtich have two fibre optic cables connect to two of core switch.

Interesting, I guess M/RSTP actually alters the sequence of modes which a port goes through upon startup, something I'll have to learn more about. Kind of leaves the door open to a loop created upon the activation of a port, but it will be shortlived.

As far as stats for the port related to the device exhibiting failure, I don't believe I have anything useful, yet. I have of course sniffed the port, but due to the frequency which faults occur(sometimes several days between errors) and my current inability to associate the faults with any other events, I haven't seen anything unusual with the network sniffer. I only see Cobranet traffic that I would expect, and some very infrequent CDP frames. If my current tests don't reveal anything useful, my next plan is to grab a company laptop with Wireshark and leave it at the site on a port mirrored with the failing CM-1. If I setup Wireshark's filter to exclude Cobranet traffic, protocol 0x8819, it should be capable of running for several days. I would hope to see something interesting with the same time stamp as a failure.

Zhangye,

I have not done any new testing with STP. I have been working with Cirrus to find the root cause of the problem, which is a stack overflow, and correct it. I think we have a fix. Please see the announcements section.
BTW, STP MSTP or RSTP are not the root cause but can contribute to this error. Usually not STP but MSTP and RSTP can contribute to the problem when the net topology changes.

CobraGuy has written a NioNote about this issue, and can be found here;

http://downloads.peavey.com/mm/index.cf … umentation

It will be placed on the public site and incorporated into the help files when it is ready.  But we thought it might be helpful to the conversation to make the draft version available to forum members.

Steve, just read the NIONote HF2: fantastic for an old audio guy still trying to catch up on networking finesse!!
More documentation like this would certainly help us avoid unnecessary grief.
Something in a similar vein that pulled the network "specification" out of the depths of the Programmers Reference Guide, and could be handed to network administrators would be great!

PS It's my role in life not to have to learn all about every related field: that's what other specialists are for!

Has anyone ever seen the HF-2 error occur in a system that does not contain at least one CAB-4n populated with a CM-2 module?

If you have your packet generator connected to a switch via a gigabit port and a CM-1 connected to some other port, are you sure that BPDU's generated by your host are forwarded on to the CM-1? BPDUs are not forwarded through a switch in the same manner as other frames. BPDUs are normally processed internally and the switch may then generate its own BPDUs which may in turn be propagated to other ports depending on configuration. Different types of BPDUs also travel is specifc directions with respect to the root switch. If the BPDUs you generate are injected into a port not expecting such a message, for example by definition your generator's port is not a root port and should not receive BPDUs that would normally originate from the root switch, the switch may ignore them completely.

I've returned from an out of town project and had a chance to load the firmware into the project in which I had first experienced the HF-2 errors. It's been a week running the new firmware and so far no problems