sending traps from hp-ux to redhat server

[NDO]

Hi All

I have been searching on google for a while for anything that would help me to
understand how to send a SNMP trap from HPUX system to other system. What is happening is that I have configured /etc/snmpd.conf file like this:

 #tail /etc/snmpd.conf
#
get-community-name:     public
#set-community-name:    # enter community name
set-community-name:     public
#contact:               # enter contact person for agent
#location:              # enter location of agent
#max-trap-dest:         # enter max no. of trap-dest entries to be maintained.
#trap-dest:             # enter trap destination
trap-dest:              10.100.48.117

 and this particular machine is sending traps to the other server, but all other systems with the same entries on their snmpd.conf file are NOT.

What I want is a tool or a command that would enable me to troubleshoot, because the network admins are telling me that no firewall is configured between other servers and this redhat server that is supposed to receive the traps.

[Matti_Kurkela]

> What is happening is that I have configured /etc/snmpd.conf file[...]

That file is supposed to be at /etc/SnmpAgent.d/snmpd.conf. If /etc/snmpd.conf exists, it might be a non-functional copy someone has created.

According to "man snmpd" on HP-UX, if you send a SNMP request with an incorrect community name, the HP-UX SNMP agent should send an authenticationFailure trap to the trap destination. Unfortunately, there are no suitable SNMP query tools on HP-UX as standard, so you will probably have to do your troubleshooting using the tools of the net-snmp-utils RPM on the RedHat server.

First, verify basic SNMP connectivity:

[RedHat-host]$ snmpget -v2c -c public <HP-UXhost> system.sysDescr.0

Replacy <HP-UXhost> with the actual hostname or IP address of the HP-UX system. The response should include a basic hostname and OS version information from HP-UX.

Then, make the same request with an incorrect community name to trigger a SNMP trap to be sent.

[RedHat-host]$ snmpget -v2c -c NOTpublic <HP-UXhost> system.sysDescr.0
Timeout: No Response from <HP-UXhost>

In this case, the timeout error is expected. The HP-UX snmpd should instead have sent an authenticationFailure trap to the configured trap destination, to notify the admins that someone is trying to query the system with incorrect community name.

If you need to verify that the trap is actually sent out from the HP-UX system, I'm afraid you'll have to take a network trace. See this link for more information:

http://www.compute-aid.com/nettl.html

You'll want to filter for SNMP traps only, so your filter file will be:

filter udp_sport 162
filter udp_dport 162

(If you have tcpdump installed or can easily install it, it might be more convenient than using the nettl commands for taking the network trace.)

[NDO]

Hi

Thanks a lot for the reply, from the server that should receive the traps as per your advise I have run the following:

snmpget -v2c -c public 10.100.48.10 system.sysDescr.0
SNMPv2-MIB::sysDescr.0 = STRING: HP-UX itc01 B.11.31 U ia64 3712856657

 and

snmpget -v2c -c NOTpublic 10.100.48.10 system.sysDescr.0
Timeout: No Response from 10.100.48.10.                
Exit 1

 and them I use tcpdump from one of the hp-ux servers, to run the following:

tcpdump -i lan1 port 162
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lan1, link-type EN10MB (Ethernet), capture size 65535 bytes

0 packets captured
9404 packets received by filter
0 packets dropped by kernel

 and

tcpdump -w comm.pcap -i lan1 dst 10.100.48.117 and port 162
tcpdump: listening on lan1, link-type EN10MB (Ethernet), capture size 65535 bytes

 So I am not getting any output from it.

But from the redhat server I try to run: "

tcpdump -i <lan interface> port 162"

and the output is showing a lot of lines obvisiouly, but one particular line that shows is:

09:53:57.900430 IP 10.100.48.10.50388 > netrac-test.mcel.co.mz.snmptrap:  C=sendtrap Trap(32)  E:hp.2.3.2.6 10.100.48.10 authenticationFailure 423567566

 which is a hp-ux server.

What do you make of it?

[NDO]

Hi

I have run the following command:

#tcpdump -w comm.pcap -i lan1 dst 10.100.48.117 and port 162
tcpdump: listening on lan1, link-type EN10MB (Ethernet), capture size 65535 bytes
12 packets captured
4820131 packets received by filter
0 packets dropped by kernel

 so 12 packets were captured. Them I have downloaded wireshark, and from the file comm.pcap, I got the folloing which tell me that traps are being sent from this server to 10.100.48.117.

Please can you confirm that I am doing the right thing?

[Matti_Kurkela]

Interesting. Your traffic dump with 12 captured packages indicates that 10.1.20.31 definitely sent some SNMP traps to 10.100.48.117.

The trap "Enterprise" OID is listed as iso.3.6.1.4.1.11.2.3.2.6. It identifies the type of the system that sent the trap.

In text form, the OID is iso.org.dod.internet.private.enterprises.hp.nm.system.hpux.ia64. So it is definitely a trap generated by a HP-UX Itanium system. Clicking on the [+] symbol next to the text "Simple Network Management Protocol" in the bottom window would reveal more details about each SNMP trap packet, including the trap type and code values that identify the meaning of the trap message.

This tcpdump output line also indicates a successfully sent trap message:

09:53:57.900430 IP 10.100.48.10.50388 > netrac-test.mcel.co.mz.snmptrap:  C=sendtrap Trap(32)  E:hp.2.3.2.6 10.100.48.10 authenticationFailure 423567566

The type of trap is authenticationFailure, as expected. (By default, tcpdump presents the essential trap information in a much more concise way than wireshark).

If netrac-test.mcel.co.mz is 10.100.48.117, this also tells you that traps are being sent to the configured trap destination.

[NDO]

yes the 10.100.48.117 (netrack-test.mcel.co.mz) is the destination server.

[Matti_Kurkela]

Yes, the "generic-trap: authenticationFailure (4)" indicates that this is an authentication failure trap, as expected.

Now you know how to cause the system to send a trap, and how to verify that a trap is actually sent.

The next question is, does 10.100.48.117 have a trap receiver configured? In a Linux system, that would usually be the "snmptrapd" process. The most common net-snmp implementation of snmptrapd can log the trap messages (to a file, or to the syslog subsystem), forward them to another trap receiver, and/or start a script or a program to process the received traps. You'll just need to configure it to specify what to do with incoming trap messages, and then start it.

See "man snmptrapd.conf"

By default, most modern Linux systems will just ignore incoming SNMP traps, until you configure and start a trap receiver process.

[NDO]

that server has not yet being commisioned, still under project, but it will be ours soon

[NDO]

Hi

Is it possible to know exactly what time a trap was sent to the destination server?

[Matti_Kurkela]

In Wireshark, go to View -> Time Display Format and change it to "Date and Time of Day". The default is "Seconds since Beginning of Capture". If the clock of the system that captured the packets is correct, you will now see the exact time each packet was detected.

The tcpdump output line also includes a timestamp (it's in the beginning of the line).

The SNMP trap packet also includes a time-stamp field, but in the SNMP standard, its meaning is defined as "the amount of time that has elapsed between the last network reinitialization and generation of the trap". So you'll have to find out what time the trap-generating system is using as "time zero" and add that to the time-stamp value.