HPE GreenLake Administration
- Community Home
- >
- Servers and Operating Systems
- >
- Legacy
- >
- Operating System - Tru64 Unix
- >
- Re: Cannot generate cpqNicRedundancyReduced SNMP t...
Operating System - Tru64 Unix
1831482
Members
3387
Online
110025
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-28-2004 01:17 PM
10-28-2004 01:17 PM
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-28-2004 09:42 PM
10-28-2004 09:42 PM
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 as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-31-2004 10:14 AM
10-31-2004 10:14 AM
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
mmm...
Mark
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-10-2004 06:35 AM
12-10-2004 06:35 AM
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.
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.
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
Company
Events and news
Customer resources
© Copyright 2025 Hewlett Packard Enterprise Development LP