NIC Agent is not sending SNMP traps

[Pedro VERA DE LA ROCHA]

I am testing Insight Manager in our Proliant systems running Red Hat.

I try to generate a trap from the NIC subsytem by shutting down an interface with:

'ifconfig eth1 down'

I changed the cma.conf to log the trap instead of sending a mail, so I can see in /var/log/messages:

Jun 15 15:07:22 wc1 kernel: bcm5700: eth1 NIC Link is DOWN
Jun 15 15:07:23 wc1 logger: HP Insight Management Agents Trap Alarm root

But the SNMP trap is not being sent, I have checked it with tcpdump, though the snmpd.conf file looks right.

Any ideas?

[David Claypool]

Unless you have a lot of experience with it, snmpd.conf can be a confusing mess. If you are using HP SIM 5.0, use 'Configure or Repair Agents' and HP SIM will configure it for you.

[Pedro VERA DE LA ROCHA]

Now, regardless of the issue of the SNMP traps and the snmpd.conf file...

I am a bit confused about the MIB branch this NIC agent manages.

In /opt/compaq/nic/etc/cmanicobjects.conf I see it manages OIDs like 18.1.1, 18.1.2... but, where does it come from?

I mean, is it enterprises.18.1.1 or mib-2.18.1.1 or what? How to know the full OID from the root?

By the way, I am not using HP SIM (what is that?) but thanks for your answer anyway, David.

[Matthew J Warrick]

HP SIM = HP Systems Insight Manager, an SNMP-based management utility. BTW you are in the "SIM" forum. ;)

[Pedro VERA DE LA ROCHA]

Ah! Okay, thanks, I know what SIM is now.

Well, we are not using SIM, but a generic SNMP Manager to receive traps and deal with some SNMP commands.

We have a set of different systems and we want to start in the simplest and cheapest manner to manage all them.

Now, my main two concerns regarding the NIC Agent:

* Why a trap looks like not generated when shutting down an interface?

* What is the MIB subtree managed by this agent?

[Pedro VERA DE LA ROCHA]

I am sorry to insist, but I cannot make the system to generate any trap, which is very disappointing.

If I shut down an interface, what the flow of messages would be?

I think 'cmanicd' may detect it then send the corresponding trap to 'snmpd', is this right?

At the moment, it is only being logged into the 'messages' file (because it is configured in this way in 'cma.conf').

Has somebody tried to generate a trap in this way? I have done similar tests in Solaris systems and the traps are indeed sent out of the server.

[Pedro VERA DE LA ROCHA]

I have found a symptom of the problem in the cam.log file while I restart the HPASM daemons:

Starting NIC Agents (cmanic): All agents
Starting NIC Agent Daemon (cmanicd):cmanic started INFO: cpqnicd did not find any SNMP trap destinations in SNMP configuration file, cpqnic_trapd.c,2290
[OK]

So it seems cmanic agent cannot find any SNMP trap destination on startup.

This is strange because the file /etc/snmp/snmpd.conf does indeed exist, and it works fine for getting variable values from the SNMP Manager.

I am using the utility 'strace' but I cannot find any clue, though it seems it never looks for a snmpd.conf file...

What's wrong here?

[bconstant]

Hi,

I'm facing the same problem here, here is what I can find in the cma.log file:

cmanic started INFO: cpqnicd did not find any SNMP trap destinations in SNMP configuration file, cpqnic_trapd.c,2749
INFO: cmanic monitoring /var/log/messages for link changes, cpqnic_trapd.c,2770
[OK]

Howere, there is a trapsink configuration directive in my snmpd.conf and trigerring a trap from the smh web interface works well.

Thank you for your help and time!

Regards,

[bconstant]

I finally managed to understand how cmanicd behaves.

First, it was not able to find the snmpd.conf configuration file. I fixed this with a symlink between /etc/snmp/snmpd.conf and /usr/share/snmp/snmpd.conf.

I was also testing the system with iconfig command but this is where it comes tricky...
cmanicd is polling /var/log/messages for messages about the network interface and when the link is going down (after ifconfig ethx down) nothing is logged to that file.
However, this is different when you up the interface because there are informations link speed and flow control. This is enough for cmanicd to trigger an snmp trap.

Now doing the same test but closing the port on the switch makes a trap going out for the interface because something appears in the log file when the interface is going down.

All these tests were done on a SLES10 with PSP761.

Hope this helps,

Regards,