Comware

I've been reading a number of threads in here that discuss the advantages and disadvantages of turning LACP on or off.

I recently have been having a problem with a group of 5300s that have had modules crashing. So far the only thing that I and HP have found to stop the crash is to turn off LACP on all my ports. This is unfortunate because I do like to use LACP for my servers and trunks between switches but now I've had to go away from that.

I was just curious of others thoughts on the subject of LACP. Good, bad, ugly?

I also like LACP passive for for server trunks (like to set switch to switch trunks manually though).

It is a standard troubleshooting method to disable LACP for clients that are having a problem. Some clients don't like the initial small forwarding delay that LACP introduces when a link comes up. It should never cause modules to crash however and that should be corrected in firmware if the behaviour can be reproduced.

The new family of products (5400/3500), now have LACP completely disabled by default. My guess is that while LACP can be a great feature, it may cause more problems than it solves.

In regards to your specific problem that you've been working with HP on, what type of modules do you have and are you doing cross-module LACP trunks?

We've been seeing this problem on about 6 different types of modules on 4 different 5300s. Some with trunks but most without.

The same error appears each time.

W 05/14/06 20:39:07 chassis: Slot H Software exception at msgSys_drv.c:519 -- in
'eDrvPoll', task ID = 0x4078d130

There is no consistency to when it happens. Replacing hardware hasn't worked. Firmware 10_31 hasn't worked either. Very frustrating.

Do you get the same problem if you setup a static trunk instead? You could try a static trunk of type 'trunk' or a static trunk with type 'LACP'.

e.g. 'trunk a1-a2 trk 1 trunk' or 'trunk a1-a2 trk1 lacp'

Anything you can do to help narrow down the issue will greatly help in finding a true fix to the crash you're experiencing.

Don't forget to assign points to posts that have helped you.

N/A: The reply was a clarification to my original question
1-3: The answer didn't help answer my question, but thanks anyhow!
4-7: The answer helped with a portion of my question, but I still need help.
8-10: The answer has solved my problem completely! I'm a happy camper!

We've removed all the trunks completely.

Turned off as much as we can. No LACP, no STP, no MESH, made it as simple as possible.

Yet the crashes keep coming. One day fine, the next day it can be every 5 minutes.

I'm a bit confused now, does disabling LACP stop these crashes or not?

Since it is crashing modules only - in a given chassis have you tried moving that module(s) to a different slot? - If the crash follows the module, then it would be reasonable to say it's the module at fault - if not I would suspect the chassis.

If you have any show tech's you could attach here it may help in understanding the crashes a little better (remove any sensitive information, public IP's, SNMP community names..)

Sorry for the confusion.

When I first posted we had about a day and half of quiet. No crashes. But in the time from the first posting 2 different modules crashed.

We have moved ports clearing problem cards only to see the problem arise on cards previously ok. We have swapped chassises without success as well.

Peter,

Since the problem is ongoing, I would recommend you contact HP regarding your existing case and have it escalated.

The only other thing I could recommend right now would be to try and identify anything that may be triggering it, such as unusual traffic patterns, broadcast storms, duplex mismatches, etc.
Anything that is showing up in the switch event log like excessive CRC errors and so forth, if you could rectify anything there that does not look healthy it will help in having your case get elevated.

Once you have a relatively clean switch event log, capture the show tech reports and send them through to HP.

Matt

Peter, since I have the same problem with the same error message, did you resolve the problem? How?

Thank you!
Massimo

The crashing of the modules was related to PCM+ collecting the Traffic data. We turned off traffic data collection on PCM and haven't had a problem since.

Thanks Peter! So I did.

About PCM+: what release did you use? 1.6 or 2.1? I'm about to buy 1.6 to 2.1 upgrade: maybe is better to save 2500$ than buy a faulty software.

We are running the latest including all patches. I still recommend the upgrade, the software is great for config management just becareful of the flow collection.

I turn off LACP on all client ports and only enable it on select server ports. My PCM+ has never caused problems when I monitor ports. Note that you should not try to monitor a member port directly but rather monitor the virtual port.