net-snmp on HP-UX 11.31

[TroyBlang]

Hi

I have successfully installed the net-snmp on HP-UX 11.31 and I am able to get the snmpwalk to work with localhost but when i try to use the host name or host ip address I get Timeout:  No Repsonse from the host.  I need to get the snmpd and snmptrapd working to connect to a server.  I am getting a timeout from that other server.  I have been looking at all the net-snmp on the internet and I am not able to figure out why it is timing out.  I just have the

rocomunity public in the snmpd.conf file and I have in the snmptrapd.conf file just authcommunity log,execute,net public

I changed the /etc/services file for port 161 to netsnmp and port 162 to netsnmp-trap.

The lsof -i udp:161 shows UDP localhost:netsnmp (Idle)

What do I need to do to get this to see the hostname and the other server to get it to poll too.  Hopefully you will be able to help me out.

[Matti_Kurkela]

In the net-snmp package, the various components have different purposes:

• snmpd responds to incoming SNMP requests and sends out trap messages to configured destinations when necessary.
• snmptrapd receives and logs incoming trap messages.
• snmpwalk and friends send out requests and interpret the responses to a human-readable form.

You can run snmpwalk without having snmpd and/or snmptrapd running, and vice versa.

You don't need snmpd or snmptrapd if you only want to send queries to other hosts and read the responses. You don't need snmpwalk if you only need to allow other hosts to snmpwalk this host. You don't need snmptrapd if you don't want to receive and log SNMP traps.

In order to be able to use snmpwalk to query another host, the other host must have snmpd or equivalent service running, and you must know the protocol version and access details (in most cases, the community name) configured to the other host. If your request does not use the same community name as is configured on the other host, the snmpd service on the other host may simply ignore your request.

Since SNMP is an UDP-based protocol, if there is no snmpd service running on the other host, you'll get the "Timeout: No Response.." error too. The UDP protocol does not include a universal "connection refused"-type response like TCP does. The remote host *may* send an ICMP port-unreachable message, but detecting such a message is more complicated since the rejection message is not associated with the UDP socket and must be received separately.

[TroyBlang]

Hi Matti

Here is what I am trying to do on my HP-UX 11.31 server.  I need snmpd and snmptrapd I think to run on the HP-UX server to have a 3rd party software have the traps sent to it for seeing the mibs from the HP-UX server.  I tried to do a snmpwalk from the 3rd party software on a Windows server to the HP-UX server and it is getting a timeout also.  I have the ip address of the Windows server in the snmpd.conf file.  This snmpd.conf file is working on a Red Hat Linux Server which is running RHEL 5.6.  I do not see anything in the syslog file from the HP-UX Server.  How can I trouble shoot why the 3rd party software is timing out trying to receive the traps from the HP-UX server.  Hopefully you can help me out.

Thanks

Troy

[Matti_Kurkela]

Your terminology is still a bit confused. Let me try to straighten you out...

There are two types of SNMP traffic.

One type is requests & responses, where the management station requests information from a SNMP agent, and the agent responds with the requested information. This is useful for gathering statistics periodically, but if you need to monitor a large number of hosts for critical events that actually happen very rarely, this would produce a lot of excess traffic, as each host would need to be polled: "Host A, what's the status of your disks?" "All OK." "And host B?" "All OK." etc.

Therefore, the other type of SNMP traffic is when the SNMP agent sends a message to the management station on its own initiative. This (and only this) is called a "SNMP trap message". It requires no response, and is usually used for immediate notification on critical events, e.g. "This is host C. My disk #1 just failed."

So... if you have configured other systems to send their trap messages to the HP-UX host, you'll need to run snmptrapd on the HP-UX host. If not, then you won't need snmptrapd on that host. Snmptrapd just listens for incoming trap messages and logs them in a human-readable form; it does nothing else.

If you want the HP-UX server to respond to SNMP requests from the Windows server and/or to send trap messages to it if something serious happens, snmpd is the only thing you need on the HP-UX host.

"Timing out trying to receive the traps" does not make sense. A trap receiver cannot know when a trap message might be forthcoming, so it must listen continuously: it cannot time out. If you are talking about SNMP requests, a timeout is understandable.

RHEL uses a rather complex command line to start snmpd. By default, it's something like:

snmpd -Lsd -Lf /dev/null -p /var/run/snmpd.pid -a

The meaning of the options is:

• -Lsd = log to syslog using the "daemon" facility code.
• -Lf /dev/null = log to file /dev/null, i.e. use no log file at all.
• -p /var/run/snmpd.pid = create a PID file using the specified filename.
• -a = log the source address of incoming requests.

If you don't include any -L options, the snmpd daemon might not log anything at all. Also, HP-UX syslog is configured to ignore low-priority messages by default.

A good first troubleshooting step would be to start snmpd on HP-UX with an explicitly-chosen log destination. For example:

# snmpd -Lf /var/tmp/why_dont_you_work.log -a &
# tail -100f /var/tmp/why_dont_you_work.log

Starting snmpd should produce some log messages to our temporary snmpd log file, and sending SNMP requests (either from localhost or from the Windows server) should produce more of them.

With your earlier snmpwalk tests, you probably have proved that snmpd works.

The problem of the Windows server timing out when sending requests to the HP-UX may have various causes:

• The requests won't get successfully sent out the Windows server (e.g. because of the software firewall included in newer Windows servers and enabled by default)
• The requests are sent out but don't reach the HP-UX server (network issues? external firewall?)
• The requests reach the HP-UX server but are prevented from reaching snmpd. This is likely if the HP-UX server has ipfilter installed and configured. Look into /etc/opt/ipf to find the current ipfilter configuration, if it exists.
• You might not be using the right protocol version and/or authentication (community name with SNMP versions 1 or 2c; username & password for SNMPv3). If the authentication is not accepted, snmpd will just ignore the request without responding at all.
• The requests reach snmpd on the HP-UX server, but the replies won't get successfully back to the Windows server. This might be because of asymmetric routing, or because of firewall issues.

With TCP-based protocols, when you configure a firewall to accept a connection in a particular direction, you can normally trust that the firewall will automatically allow the responses coming back too. But SNMP is a connectionless,  UDP-based protocol, so you might have to explicitly allow both directions. (Many modern firewalls understand SNMP automatically, but not all of them. Be aware of this possibility.)

[TroyBlang]

Hi Matti

I would like to work with you on this SNMP issue I am having on my HP-UX server to the third party software.  You seem to know a lot about SNMP and how it all works.  Please send me.

I need to find out why I am getting the timeouts from the HP-UX server to the third party software.  I have to be missing something since the Linux server is on the same subnet as the HP-UX server and I am using the same snmpd.conf file on both servers.  I hope you can help me out.

Thanks

Troy