The customer reported that the upper NMS (OSS) did not recognize the alarm traps alarms. The upper NMS just received "keep alive traps". Consequently, the alarm data could not be processed by OSS.
The requirement from customer was to send traps in V1 SNMP version (keep alive and alarm traps)
VERITAS Version: 4.3
U2000 version: V100R001C00CP0307
For cause 1, check the following items on the server:
a. Open Sysmonitor and check the status of SNMP NBI process. If it is stopped, start it
For cause 2, check the following items:
a. Log in to the server with root user
b. Capture the traps that are being sent by the server
#snoop -o /tmp/v1.trace -d eri0 to 192.xxx.xxx.xxx
Where eri0 is the NIC that is being used to send traps on the server and 192.xxx.xxx.xxx is the ip address of the upper NMS.
c. Download the .trace file from Solaris server using ftp. Check the .trace file using a protocol interpreter software (i.e. Ethreal)
After uploading the .trace file, the following screen is showed:
When checking the "SNMP agent address", it is setup as 0.0.0.0. Tipically, the OSS requires that the "SNMP agent address" should be the ip address of the server.
After analyzing the traffic using a protocol interpreter software (i.e. Ethereal), it was located that the U2000 SNMP interface was sending traps in V1.
However, the SNMP agent address for the "keep alive traps" was configured with the server IP addres (192.XXX.XXX.XXX) and the SNMP agent address for the alarm traps was configured with 0.0.0.0. For this reason the upper NMS did not recognized the alarm traps.
d. Check the logical port usage on the server, logged as root in Solaris.
FTP the attached file to /tmp of U2000 server with bin mode.
Run #chmod 755 /tmp/WhoUsePort.sh
#sh WhoUsePort.sh 161
Check if the 161 port is being used:
root@Secondary # ps ?ef|grep 824
root 824 1 0 Jan 03 ? 1:22 /usr/sfw/sbin/snmpd
root 13840 24748 0 11:42:00 pts/3 0:00 grep 824
It means that /usr/sfw/sbin/snmpd is using 161 port.
e. If 161 port is being used, change the port to sent the trap request by another port. For this:
Change the port assignation for MSUite. In the "Receive request from NMS address field" use port set up 1025.
Apply the configuration
The possible causes of the problem could be:
1. The SNMP process may have problems.
2. Some logical ports are occupied by another process on the server.
Check the usage of the logical ports that may interfere in the SNMP function