- 论坛徽章:
- 0
|
下面的这篇文档，可以参考一下。
A) Configuration :
1) snmp host configuration
Your /etc/hosts file must contain a "snmpserver" alias.
Example of /etc/hosts:
127.0.0.1 localhost
10.238.192.102SNMP-alarm SNMP snmpserver
Verification:
cat /etc/hosts | grep snmpserver
(This should return one line as result)
If no line is returned, you have to create the alias
(as root)
echo "123.123.123.123 snmpserver" >> /etc/hosts
(replace 123.123.123.123 by the real snmp server ip address)
!!! Check that the ip address is REALLY the snmp server IP address. I lost once a few hours because the IP given to the snmpserver was the same as the one of the host generating the traps (therefore, everything was sent over the loopback and even snoop won't show you anything)
2) Modify the file /etc/snmp/conf/enterprises.oid this way:
2a) In case you are not running SERVICE2.3.07S or if you are but week 506 is installed :
(Note: I got some cases where the W506 was not installed but where the enterprise oid used was "1.3.6.1.4.1.637.69.1"... In this case, you should use this enterprises.oid file)
(as root)
cp /etc/snmp/conf/enterprises.oid /etc/snmp/conf/enterprises.oid.backup
grep -v lcatel /etc/snmp/conf/enterprises.oid > /etc/snmp/conf/enterprises.oid.tmp
cat << __EOF__ >> /etc/snmp/conf/enterprises.oid.tmp
" Data Networks" "1.3.6.1.4.1.637.69.1"
" Data Networks X733 Indeterminate""1.3.6.1.4.1.637.69.1.4"
" Data Networks X733 Critical" "1.3.6.1.4.1.637.69.1.5"
" Data Networks X733 Major" "1.3.6.1.4.1.637.69.1.6"
" Data Networks X733 Minor" "1.3.6.1.4.1.637.69.1.7"
" Data Networks X733 Warning""1.3.6.1.4.1.637.69.1.8"
" Data Networks X733 Clear" "1.3.6.1.4.1.637.69.1.9"
" Data Networks X733 Common" "1.3.6.1.4.1.637.69.1.10"
__EOF__
cat /etc/snmp/conf/enterprises.oid.tmp > /etc/snmp/conf/enterprises.oid
rm /etc/snmp/conf/enterprises.oid.tmp
Verification :
grep lcatel /etc/snmp/conf/enterprises.oid
" Data Networks" "1.3.6.1.4.1.637.69.1"
" Data Networks X733 Indeterminate""1.3.6.1.4.1.637.69.1.4"
" Data Networks X733 Critical" "1.3.6.1.4.1.637.69.1.5"
" Data Networks X733 Major" "1.3.6.1.4.1.637.69.1.6"
" Data Networks X733 Minor" "1.3.6.1.4.1.637.69.1.7"
" Data Networks X733 Warning""1.3.6.1.4.1.637.69.1.8"
" Data Networks X733 Clear" "1.3.6.1.4.1.637.69.1.9"
" Data Networks X733 Common" "1.3.6.1.4.1.637.69.1.10"
2b) In case you are running SERVICE2.3.07S without the week 506
!!! NAMin18875 : Pfmalarm (On SUN) : entreprise OID is not correct into the SNMP traps the SERVICE Alarms have the wrong enterprise OID. They should have enterprise OID 1.3.6.1.4.1.637.69.1 and not 1.3.6.1.4.1.637. If you have NOT installed WEEK506 the enterprise.iod should be formatted this way :
(as root)
cp /etc/snmp/conf/enterprises.oid /etc/snmp/conf/enterprises.oid.backup
grep -v lcatel /etc/snmp/conf/enterprises.oid > /etc/snmp/conf/enterprises.oid.tmp
cat << __EOF__ >> /etc/snmp/conf/enterprises.oid.tmp
" Data Networks" "1.3.6.1.4.1.637"
" Data Networks X733 Indeterminate""1.3.6.1.4.1.637.69.1.4"
" Data Networks X733 Critical" "1.3.6.1.4.1.637.69.1.5"
" Data Networks X733 Major" "1.3.6.1.4.1.637.69.1.6"
" Data Networks X733 Minor" "1.3.6.1.4.1.637.69.1.7"
" Data Networks X733 Warning""1.3.6.1.4.1.637.69.1.8"
" Data Networks X733 Clear" "1.3.6.1.4.1.637.69.1.9"
" Data Networks X733 Common" "1.3.6.1.4.1.637.69.1.10"
__EOF__
cat /etc/snmp/conf/enterprises.oid.tmp > /etc/snmp/conf/enterprises.oid
rm /etc/snmp/conf/enterprises.oid.tmp
Verification :
grep lcatel /etc/snmp/conf/enterprises.oid
" Data Networks" "1.3.6.1.4.1.637"
" Data Networks X733 Indeterminate""1.3.6.1.4.1.637.69.1.4"
" Data Networks X733 Critical" "1.3.6.1.4.1.637.69.1.5"
" Data Networks X733 Major" "1.3.6.1.4.1.637.69.1.6"
" Data Networks X733 Minor" "1.3.6.1.4.1.637.69.1.7"
" Data Networks X733 Warning""1.3.6.1.4.1.637.69.1.8"
" Data Networks X733 Clear" "1.3.6.1.4.1.637.69.1.9"
" Data Networks X733 Common" "1.3.6.1.4.1.637.69.1.10"
see NAMin18875 (delivery 10174) delivered in Release 2.3.07.S Week 506
see http://www.etb.bel..be/productiz ... .3.07.S/449/KP.html
3) Create from scratch the file /etc/snmp/conf/snmpdx.acl this way:
(as root)
cp /etc/snmp/conf/snmpdx.acl /etc/snmp/conf/snmpdx.acl.backup
cat << __EOF__ > /etc/snmp/conf/snmpdx.acl
acl = {
{
communities = public, private
access = read-write
managers = *
}
}
trap = {
{
trap-community = smp-in
hosts = snmpserver
{
enterprise = " Data Networks"
trap-num = 1, 2
}
}
}
__EOF__
Verification:
cat /etc/snmp/conf/snmpdx.acl
acl = {
{
communities = public, private
access = read-write
managers = *
}
}
trap = {
{
trap-community = smp-in
hosts = snmpserver
{
enterprise = " Data Networks"
trap-num = 1, 2
}
}
}
4a) (Sun only) Create from scratch the file /etc/snmp/conf/snmpd.conf this way:
cp /etc/snmp/conf/snmpd.conf /etc/snmp/conf/snmpd.conf.backup
cat << __EOF__ > /etc/snmp/conf/snmpd.conf
sysdescr Sun SNMP Agent, Sun-Fire-V440
syscontactSystem administrator
sysLocation System administrators office
system-group-read-community public
read-community public
traplocalhost
trap-community SNMP-trap
managers localhost
__EOF__
Verification:
cat /etc/snmp/conf/snmpd.conf
sysdescr Sun SNMP Agent, Sun-Fire-V440
syscontactSystem administrator
sysLocation System administrators office
system-group-read-community public
read-community public
traplocalhost
trap-community SNMP-trap
managers localhost
5a) Restart the snmp daemon:
Sun only :
/etc/init.d/init.snmpdx stop
/etc/init.d/init.snmpdx start
5b) Force the snmpd to reread its configuration files without restarting it:
ps -ef | grep nmpd | awk '{print $2}' | xargs kill -HUP
(In that case, the trap "coldstart" that means snmp has been restarted)
Remarks:
You could receive this type of traps (found in /var/temip/trace/snmp_am.log.xxx)
07/04 16:20:25[8367][65547] [EVT] Major : Event discarded: sender of an incoming trap (authenticationFailure) is unknown : 175.175.65.94 (at line 1404 in file ist_evt_osimapper.cxx)
To avoid to send this type of trap to client server, modify the parameter "snmpEnableAuthenTraps" inside (Sun only) /etc/snmp/conf/snmpd.conf or (HP only) /etc/snmp.conf.
B) Check / debug
1) Do a list of the alarm subscriptions:
GCC>pfmalarm.evt_subs.list,MN="%",BITMAP="NYNYNYNNNYYYNNNNNNYNNNN";
pfmalarm.evt_subs.list="0",CORB_SUB=,DEF_SUBS="0"&"0"&"1"&"0"&"0",EVT_CAT=,EVT_KIND="1"&"1"&"0"&"1"&"1",EVT_NAME=,INVALID="0"&"0"&"0"&"0"&"0",IOR=,MAIL=,MAIL_SUB=,MAX_LVL="5"&"5"&"5"&"5"&"5",MIN_LVL="5"&"4"&"4"&"0"&"5",MN="mail4parlay"&"mail4aaa"&"default"&"snmp"&"mail",OP_NAME=,SEP_NAME=,SEP_RECO=,SEP_SUB=,SMS=,SMS_SUB=,SNMP_SUB="0"&"0"&"0"&"1"&"0",SQL_CLAU=,SERVNAM=,STAR_DAT=,STAR_TIM=,CMDRESULT="",NBSTART="5";
Then display the one which has the DEF_SUBS="1", and the one which has the SNMP_SUB="1"
GCC>pfmalarm.evt_subs.display,MN="default";
pfmalarm.evt_subs.display="0",CORB_SUB="0",DEF_SUBS="1",EVT_CAT="",EVT_KIND="0",EVT_NAME="",INVALID="0",IOR="",MAIL="",MAIL_SUB="0",MAX_LVL="5",MIN_LVL="4",MN="default",OP_NAME="installer",SEP_NAME="",SEP_RECO="0",SEP_SUB="0",SMS="",SMS_SUB="0",SNMP_SUB="0",SQL_CLAU="",SERVNAM=""&""&""&""&""&""&""&""&""&"",STAR_DAT="12/07/2004",STAR_TIM="15:57:27",CMDRESULT="";
GCC>pfmalarm.evt_subs.display,MN="snmp";
pfmalarm.evt_subs.display="0",CORB_SUB="0",DEF_SUBS="0",EVT_CAT="",EVT_KIND="1",EVT_NAME="",INVALID="0",IOR="",MAIL="",MAIL_SUB="0",MAX_LVL="5",MIN_LVL="0",MN="snmp",OP_NAME="",SEP_NAME="",SEP_RECO="0",SEP_SUB="0",SMS="",SMS_SUB="0",SNMP_SUB="1",SQL_CLAU="",SERVNAM=""&""&""&""&""&""&""&""&""&"",STAR_DAT="01/01/2005",STAR_TIM="00:00:00",CMDRESULT="";
The subscriptions cannot have the INVALID field set to 1. If the INVALID flag is set to 1, then delete and recreate the subscription.
Keep in mind that a subscription can collect events (EVT_KIND="0") as it is the case for the default subscription or collect alarms (EVT_KIND="1") as it is usually the case for the snmp subscription. This mean that an snmp trap will be sent only when a new alarm pops up or when an alarm is closed. No snmp trap is sent when the number of occurrence is increased.
2) Verify that you can receive alarms in pfmalarm:
Open 2 telnets to the machine.
In the first telnet, do:
gcc alc7s0m1 xx -monitoring -h -alarm
In the second telnet, do:
2.3 only :
/in/local/bin/sendevent -O test -i 1 -l 5 -t 2 -d test platserv/alarm 12
/in/local/bin/sendevent -O test -i 1 -l 5 -t 1 -d test platserv/alarm 12
/in/local/bin/sendevent -O test -i 1 -l 5 -t 2 -d test platserv/alarm 12
2.4 only :
/SERVICE/local/bin/sendevent -O test -i 1 -l 5 -t 2 -d test platserv/alarm 12
/SERVICE/local/bin/sendevent -O test -i 1 -l 5 -t 1 -d test platserv/alarm 12
/SERVICE/local/bin/sendevent -O test -i 1 -l 5 -t 2 -d test platserv/alarm 12
The -t 2 means an event of type close.
The -t 1 means an event of type open.
In some cases, this monitoring through GCC doesn't work.
You then have to work with the GUI or check manually in the DB (as shown here below).
2bis) If Gcc verification does not work, check manually in the DB :
ORACLE_SID=SMP;export ORACLE_SID;sqlplus pfmalarm/pfmalarm@PSMF.world
SQL> select CLS_DATE,CLS_TIME,EVT_CAT,EVT_CODE,EVT_DATA,EVT_DATE,EVT_NAME,EVT_TIME,OBJ_TYPE,
OCC_NB,OPN_DATE,OPN_TIME,RI,SRC_NAME,SUB_HOST from alarm
where EVT_CODE=12 and grp_bep is not null;
CLS_DATECLS_TIME
---------- ----------
EVT_CATEVT_CODE
---------------------------------------------------------------- ----------
EVT_DATA
--------------------------------------------------------------------------------
EVT_DATEEVT_NAME EVT_TIME
---------- -------------------------------- ----------
OBJ_TYPE OCC_NB OPN_DATEOPN_TIME RI
-------------------------------- ---------- ---------- ---------- ----------
SRC_NAME SUB_HOST
-------------------------------- --------------------------------
platserv/alarm 12
test
30/06/2005 badsql12:03:16
test 2 30/06/2005 12:02:312714
sendevent.cxx SMP01
3) Verify the snmpd configuration :
Please refer to the "Verifications" points of the first part of this document ( A) Configuration)
4) Start the snmpd with debugging:
In telnet1, as root, do:
Sun only :
/etc/init.d/init.snmpdx stop
/usr/lib/snmp/snmpdx -y -d4 -c /etc/snmp/conf/
HP only :
/sbin/rc3.d/S49snmpd stop
/usr/sbin/snmpd -d -t
The startup should not show any error !!!
You can find in "Annex A" a trace of a normal startup.
In telnet2, as linus, do:
Generate an snmptrap:
/in/local/bin/sendevent -O test -i 1 -l 5 -t 2 -d test platserv/alarm 12
/in/local/bin/sendevent -O test -i 1 -l 5 -t 1 -d test platserv/alarm 12
/in/local/bin/sendevent -O test -i 1 -l 5 -t 2 -d test platserv/alarm 12
If nothing happens in telnet1, then verify your snmpd configuration.
If something happen, verify that you see some line like the following:
>> sent 622 bytes to SNMP-alarm.162
You can find in "Annex B" a trace of a trap successfully forwarded to the snmpserver.
In this particular case, SNMP-alarm is the canonical hostname (first alias) of the host snmpserver in /etc/hosts:
SMP01 linus>cat /etc/hosts | grep snmpserver
10.238.192.102SNMP-alarm SNMP snmpserver
If you only see that the packet is forwarded to yourself, then verify your configuration once more.
eg: I got one case where people did put the same IP address for the snmpserver and for the host sending the trap. Because of this, I always saw the hostname of the sender (first in the hosts file) instead of the snmpserver. Also nothing was seen in the snoop.
5a) (Sun only) Snif the network from the active psmf to see if traps are sent :
Sun only :
snoop -d qfe1 -v host snmpserver
(replace qfe1 by the interface used on the psmf if needed)
ping snmpserver
5b) (HP only) Snif the network from the standby psmf configured as hot/stby to see if traps are received :
on the standby SMP launch /usr/sbin/snmp_traprcv as root.
(as root)
/usr/sbin/snmp_traprcv
on any machine of the network, generate an IN event as linus :
(as linus)
/in/local/bin/sendevent -O test -i 1 -l 5 -t 0 -d test platserv/alarm 12
(this is a level 5 single event)
Check that the alarm is received by the snmp listener
You can find in "Annex C" a snoop of a trap successfully forwarded to the snmpserver.
note: testing the port 162 of the host snmpserver using the telnet tool (telnet snmpserver 162) will not work because snmp is not using tcp but udp.
C) Annexes :
Annex A: Normal startup trace of snmpd with debugging enabled: |
|
免费注册
发表于 2008-04-15 17:48
xx. .... = 0 (precedence)
rotocol = 17 (UDP)
estination address = 10.238.192.102, SNMP-alarm
