***SPAM*** Re: ***SPAM*** Re: [ofa-general] OpenSM and trap 128.
hal.rosenstock at gmail.com
Sat Mar 28 05:58:52 PDT 2009
On Thu, Mar 26, 2009 at 10:48 AM, Hal Rosenstock
<hal.rosenstock at gmail.com> wrote:
> On Thu, Mar 26, 2009 at 8:37 AM, Nicolas Morey Chaisemartin
> <nicolas.morey-chaisemartin at ext.bull.net> wrote:
>> I was thinking about a solution:
>> When receiving a 128 trap (and it triggers a heavy sweep) we check the faulty GUID, lid or port guid.
>> If last heavy sweep was triggered by the same faulty port, we wait twice last the last waiting time before forcing the new heavy sweep.
>> If it's another source or another reason, we force the heavy sweep right then and set the waiting time to 0.
>> This way, different problem will still trigger a heavy sweep asap but if only one faulty links triggers it it'll sweep less and less often as it is pretty useless.
for this particular case where there are single port link state changes.
>> It should solve this case but there may still be a problem when more ports have the same problem...
The downside would be that this would obscure "valid" changes on any
other ports of the same switches where "simultaneously" occuring on
one or more ports. Is that a good tradeoff ?
>> Any idea on a way to manage this?
>> An ignore mask on traps? (ignore traps for 1 specific problem for x seconds if they happen to often)
I think this (trap rate flooding) issue only applies to 4 physically
related traps (128-131).
More information about the general