Operating System - Tru64 Unix
1831482 Members
3387 Online
110025 Solutions
New Discussion

Re: Cannot generate cpqNicRedundancyReduced SNMP trap

 
Mark Tan_1
Occasional Contributor

Cannot generate cpqNicRedundancyReduced SNMP trap

I am running Tru64Unix 5.1B on a DS15 node with NetRAIN configured using two physical interfaces. I cannot generate the trap cpqNicRedundancyReduced trap when the cable is pulled from standby interface.

According to the description provided in the cpqNic.mib file the trap should be generated when: "This trap will be sent any time a physical adapter in a logical adapter group changes to the Failed condition, but at least one physical adapter remains in the OK condition..

This can be caused by loss of link due to a cable being removed from the adapter or the Hub or Switch."

After further investigation it looks like the trap isn't being sent because the physical adapter does not report linkFailure when it loses link. When the cable was pulled out from the interface, I looked at the mib value for cpqNicIfPhysAdapterStatus and it reported Ok(2) instead of linkFailure(4).

Why isn't linkFailure reported when the link is lost on the physical adapter? Has anyone seen this before?

Thanks
Mark
3 REPLIES 3
Johan Brusche
Honored Contributor

Re: Cannot generate cpqNicRedundancyReduced SNMP trap


I guess this would be the job of the niffd. did you "niffconfig -a ee0 ee1" ?

Use niffconfig -v to check if the niffd is monitoring any interfaces.

Johan
~_~

_JB_
Mark Tan_1
Occasional Contributor

Re: Cannot generate cpqNicRedundancyReduced SNMP trap

Yes, niffd is running and the interfaces that I'm interested in is being monitored, ee0, ee1, nr0, etc...

mmm...

Mark
Al Licause
Trusted Contributor

Re: Cannot generate cpqNicRedundancyReduced SNMP trap

RE: niffd....I believe in this case, since you're using NetRAIN, it will
be NetRAIN's responsibility to poll it's own set of devices. Niffd shouldn't
be required.

The mib definition is not all that specific as to which interface would need
to be lost or degraded into order to declare a reduction in service.
Have you tried pulling the active nic's cable to see if, the interface fails
to the backup, then to see if the trap is generated ? I have done some
experiments with this scenario and have seen the trap. But I have not tested
the inactive.

You might also want to enable additional debugging with either
ifconfig nr0 debug....and/or sysconfig -r netrain nr_debug=1

Then pull the cable and monitor either daemon.log or kern.log for additional
messages/events.