Problems with snmptrapd
Garry Sikes
snmptrapd, I get the following errors. It looks like snmptrapd cannot
find the MIB, but the MIB is in the /usr/local/share/mibs directory.
When I generate traps from a load balancer, trapd writes them to syslog
in the same format as traphandle states, but traphandle will not pass an
appropriate value to /home/garry/testtrap. I know that trapd is
working, because when it receives a Foundry trap, it passes "30" to
/home/garry/testtrap. This indicates that the default value works
correctly. Is there something that I am missing or that I am doing
wrong that is preventing trapd from reading and parsing the Foundry
traps correctly?
I am running ucd-snmp-4.2.1 on a FreeBSD 4.4 machine.
Regards,
Garry
snmptrapd.conf/traphandle file:
bash-2.05$ cat traphandle
#This is to test the traphandler:
traphandle SNMPv2-MIB::coldStart /home/garry/testtrap 1
traphandle SNMPv2-MIB::warmStart /home/garry/testtrap 2
traphandle FOUNDRY-SN-ROOT-MIB::snTrapL4RealServerUp
/home/garry/testtrap 7
traphandle FOUNDRY-SN-ROOT-MIB::snTrapL4RealServerDown
/home/garry/testtrap 8
traphandle FOUNDRY-SN-ROOT-MIB::snTrapL4RealServerPortUp
/home/garry/testtrap 9
traphandle FOUNDRY-SN-ROOT-MIB::snTrapL4RealServerPortDown
/home/garry/testtrap 10
traphandle default /home/garry/testtrap 30
OUTPUT from trapd:
bash-2.05$ sudo snmptrapd -D -h -P -c
/usr/local/share/snmp/snmpconf/snmptrapd.conf/traphandle
/usr/local/share/snmp/snmpconf/snmptrapd.conf/traphandle: line 5: Error:
Bad trap OID in traphandle directive:
FOUNDRY-SN-ROOT-MIB::snTrapL4RealServerUp
/usr/local/share/snmp/snmpconf/snmptrapd.conf/traphandle: line 6: Error:
Bad trap OID in traphandle directive:
FOUNDRY-SN-ROOT-MIB::snTrapL4RealServerDown
/usr/local/share/snmp/snmpconf/snmptrapd.conf/traphandle: line 7: Error:
Bad trap OID in traphandle directive:
FOUNDRY-SN-ROOT-MIB::snTrapL4RealServerPortUp
/usr/local/share/snmp/snmpconf/snmptrapd.conf/traphandle: line 8: Error:
Bad trap OID in traphandle directive:
FOUNDRY-SN-ROOT-MIB::snTrapL4RealServerPortDown
2002-06-17 08:52:51 UCD-snmp version 4.2.1 Started.
And here is what trapd writes to syslog when it receives a
Foundry Trap:
Jun 15 20:00:43 mon1 snmptrapd[68753]: 10.10.1.3: Enterprise Specific
Trap (snTrapL4RealServerPortDown) Uptime: 8 days, 8:49:00.90,
enterprises.foundry.products.switch.snL4.snL4Trap.snL4TrapRealServerIP =
IpAddress: 10.10.2.81,
enterprises.foundry.products.switch.snL4.snL4Trap.snL4TrapRealServerName
= "server1",
enterprises.foundry.products.switch.snL4.snL4Trap.snL4TrapRealServerPort
= 25
Jun 15 20:00:44 mon1 snmptrapd[68753]: 10.10.1.2: Enterprise Specific
Trap (snTrapL4RealServerPortDown) Uptime: 35 days, 23:21:10.90,
enterprises.foundry.products.switch.snL4.snL4Trap.snL4TrapRealServerIP =
IpAddress: 10.10.2.81,
enterprises.foundry.products.switch.snL4.snL4Trap.snL4TrapRealServerName
= "server1",
enterprises.foundry.products.switch.snL4.snL4Trap.snL4TrapRealServerPort
= 25
Jun 15 20:00:48 mon1 snmptrapd[68753]: 10.10.1.3: Enterprise Specific
Trap (snTrapL4RealServerPortUp) Uptime: 8 days, 8:49:06.00,
enterprises.foundry.products.switch.snL4.snL4Trap.snL4TrapRealServerIP =
IpAddress: 10.10.2.81,
enterprises.foundry.products.switch.snL4.snL4Trap.snL4TrapRealServerName
= "server1",
enterprises.foundry.products.switch.snL4.snL4Trap.snL4TrapRealServerPort
= 25
Jun 15 20:00:50 mon1 snmptrapd[68753]: 10.10.1.2: Enterprise Specific
Trap (snTrapL4RealServerPortUp) Uptime: 35 days, 23:21:16.60,
enterprises.foundry.products.switch.snL4.snL4Trap.snL4TrapRealServerIP =
IpAddress: 10.10.2.81,
enterprises.foundry.products.switch.snL4.snL4Trap.snL4TrapRealServerName
= "server1",
enterprises.foundry.products.switch.snL4.snL4Trap.snL4TrapRealServerPort
= 25
_______________________________________________________________
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
Net-snmp-users mailing list
Net-snm...@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
Wes Hardaker
Garry> I am having some problems with snmptrapd. For some reason,
Garry> when I run snmptrapd, I get the following errors. It looks
Garry> like snmptrapd cannot find the MIB, but the MIB is in the
Garry> /usr/local/share/mibs directory.
make sure the mib names match perfectly.
It shouldn't matter, but you might try putting the following line at
the top of your snmptrapd.conf file:
[snmp] mibs +FOUNDRY-SN-ROOT-MIB
And see if that helps (it shouldn't, as what you're doing should be
technically correct, so if it fixes the problem it's a bug).
--
Wes Hardaker
NAI Labs
Network Associates
Garry Sikes
and found that it actually contains 6 or 7 MIB definitions within the
file. How does ucd-snmp read through MIB files? Should I break down
the 1 large MIB file into separate files, one for each MIB definition?
Garry
Here is an example of what I mean:
FOUNDRY-SN-ROOT-MIB DEFINITIONS ::= BEGIN
END
FOUNDRY-SN-AGENT-MIB DEFINITIONS ::= BEGIN
END
FOUNDRY-SN-SWITCH-GROUP-MIB DEFINITIONS ::= BEGIN
END
FOUNDRY-SN-IPX-MIB DEFINITIONS ::= BEGIN
END
FOUNDRY-SN-OSPF-GROUP-MIB DEFINITIONS ::= BEGIN
END
FOUNDRY-SN-TRAP-MIB DEFINITIONS ::= BEGIN
Etc.
All of the above are contained in the same file, called FOUNDRY-MIB.
-----Original Message-----
From: Wes Hardaker [mailto:hard...@users.sourceforge.net]
Sent: Monday, June 17, 2002 12:31 PM
To: Garry Sikes
Cc: net-snm...@lists.sourceforge.net
Subject: Re: Problems with snmptrapd
>>>>> On Mon, 17 Jun 2002 09:22:39 -0700, "Garry Sikes"
<ga...@danger.com> said:
Garry> I am having some problems with snmptrapd. For some reason,
Garry> when I run snmptrapd, I get the following errors. It looks
Garry> like snmptrapd cannot find the MIB, but the MIB is in the
Garry> /usr/local/share/mibs directory.
make sure the mib names match perfectly.
It shouldn't matter, but you might try putting the following line at
the top of your snmptrapd.conf file:
[snmp] mibs +FOUNDRY-SN-ROOT-MIB
And see if that helps (it shouldn't, as what you're doing should be
technically correct, so if it fixes the problem it's a bug).
--
Wes Hardaker
NAI Labs
Network Associates
----------------------------------------------------------------------------------------------------
Sponsor's Message
----------------------------------------------------------------------------------------------------
Bringing you mounds of caffeinated joy
>>> http://thinkgeek.com/sf <<<
Wes Hardaker
Garry> One other thing. I read the MIB that I am using (called
Garry> FOUNDRY-MIB), and found that it actually contains 6 or 7 MIB
Garry> definitions within the file. How does ucd-snmp read through
Garry> MIB files? Should I break down the 1 large MIB file into
Garry> separate files, one for each MIB definition?
Well, we handled that case properly at one point but I doubt support
for it has been tested in a really long time. You probably should
break them into individual files and see if that fixes your problem.
--
Wes Hardaker
NAI Labs
Network Associates
----------------------------------------------------------------------------
Garry Sikes
"snmptrapd -D -P -c
/usr/local/share/snmp/snmpconf/snmptrapd.conf/traphandle"
I do not receive any errors. It appears to be working fine. The
problem is that traphandle will not process the incoming traps
accordingly. It appears that the traphandle file recognizes the trap,
but is trying to process it as a different trap. Could this be a SNMPv1
vs SNMPv2 problem? The trap coming in is obviously the Foundry trap
that I am expecting. Here is my traphandle file:
cat /usr/local/share/snmp/snmpconf/snmptrapd.conf/traphandle
traphandle FOUNDRY-SN-TRAP-MIB::snTrapL4RealServerUp
/home/garry/testtrap 7
traphandle FOUNDRY-SN-TRAP-MIB::snTrapL4RealServerDown
/home/garry/testtrap 8
traphandle FOUNDRY-SN-TRAP-MIB::snTrapL4RealServerPortUp
/home/garry/testtrap 9
traphandle FOUNDRY-SN-TRAP-MIB::snTrapL4RealServerPortDown
/home/garry/testtrap 10
traphandle default /home/garry/testtrap
And here is what the traps look like once traphandle examines them:
2002-06-17 21:26:07 <device info removed> TRAP, SNMP v1, Community
<removed>
enterprises.foundry.products.registration.snServerIron.snSIXL
Link Up Trap (0) Uptime: 38 days, 0:46:35.30
interfaces.ifTable.ifEntry.ifIndex.13 = 13
interfaces.ifTable.ifEntry.ifDescr.13 = "FastEthernet13"
snmptrapd:traphandler: looking for trap handler for
.iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.snmpTrap
s.4...
snmptrapd:traphandler: None found, Using the default handler.
snmptrapd: Running: /home/garry/testtrap
2002-06-17 21:26:07 <device info removed> TRAP, SNMP v1, Community
<removed>
enterprises.foundry.products.registration.snServerIron.snSIXL
Link Up Trap (0) Uptime: 38 days, 0:46:35.30
interfaces.ifTable.ifEntry.ifIndex.14 = 14
interfaces.ifTable.ifEntry.ifDescr.14 = "FastEthernet14"
snmptrapd:traphandler: looking for trap handler for
.iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.snmpTrap
s.4...
snmptrapd:traphandler: None found, Using the default handler.
snmptrapd: Running: /home/garry/testtrap
Any ideas?
Garry
-----Original Message-----
From: Wes Hardaker [mailto:hard...@users.sourceforge.net]
Sent: Monday, June 17, 2002 5:43 PM
To: Garry Sikes
Cc: Wes Hardaker; net-snm...@lists.sourceforge.net
Subject: Re: Problems with snmptrapd
Garry Sikes
trap and then converting it to a SNMPv2-MIB trap?
Garry
Garry Sikes
for and process traps as v1?
Dave Shield
> trap and then converting it to a SNMPv2-MIB trap?
Because that's how it works?
Because the SNMPv2 notification format is a lot cleaner than
the SNMPv1 trap format?
So that a trap handler only needs to deal with one format, not two.
> Or better yet, is there a way to run the snmptrapd daemon to only look
> for and process traps as v1?
Nope.
If you wish to write such a thing, we'll consider it for inclusion in
a future release.
Dave
PS: Can you please trim your messages, rather than including the whole
of the thread every time. Thanks.
Garry Sikes
sends traps out in SNMPv1 format. When the traphandler receives the
trap and converts it to SNMPv2, this is what it converts the Foundry
Enterprise trap to:
snmptrapd:traphandler: looking for trap handler for
.iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.snmpTrap
s.4...
The problem is that in SNMPv2-MIB, snmpTraps.3 and snmpTraps.4 are both
commented out of the MIB, and noted as being defined in RFC1573
(IF-MIB). How can I force snmptrapd to read IF-MIB instead of
SNMPv2-MIB and evaluate this correctly.
Garry
-----Original Message-----
From: Dave Shield [mailto:D.T.S...@csc.liv.ac.uk]
Sent: Wednesday, June 19, 2002 1:47 AM
To: Garry Sikes
Cc: net-snm...@lists.sourceforge.net
Subject: Re: Problems with snmptrapd
Dave Shield
> sends traps out in SNMPv1 format.
OK - that doesn't really matter, as long as this will be converted
to a predictable OID once it reaches the trap handler.
(Which it will, using RFC 2576)
> When the traphandler receives the
> trap and converts it to SNMPv2, this is what it converts the Foundry
> Enterprise trap to:
> snmptrapd:traphandler: looking for trap handler for
> .iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.snmpTrap
> s.4...
Umm.... now you've confused me.
You were originally talking about catching Foundry-specific enterprise
traps. But this is one of the generic traps (IF-MIB::linkUp)
So it's not surprising that this doesn't match any of the handlers
that you listed earlier.
> The problem is that in SNMPv2-MIB, snmpTraps.3 and snmpTraps.4 are both
> commented out of the MIB, and noted as being defined in RFC1573
> (IF-MIB). How can I force snmptrapd to read IF-MIB instead of
> SNMPv2-MIB and evaluate this correctly.
I'm slightly surprised that it isn't being read in anyway - it's
one of the standard set of MIB files, that's typically loaded by
default. But anyway, you should be able to tell snmptrapd to
load it explicitly, by putting a line
mibs +IF-MIB
in snmp.conf, or by running "snmptrapd -m +IF-MIB ...."
Or you could simply have a trap handler entry:
traphandle IF-MIB::linkUp /home/garry/testtrap 99
which should also read in this MIB file automatically.
dave
Niels Baggesen
>
> And here is what the traps look like once traphandle examines them:
>
> 2002-06-17 21:26:07 <device info removed> TRAP, SNMP v1, Community
> <removed>
> enterprises.foundry.products.registration.snServerIron.snSIXL
> Link Up Trap (0) Uptime: 38 days, 0:46:35.30
What you receive here is a generic link up trap, not an enterprise
specific trap related to your foundry enterprise. That is why snmptrapd
does not look at your defined trap handlers.
/Niels
--
Niels Baggesen -- @home -- Århus -- Denmark -- ni...@baggesen.com
The purpose of computing is insight, not numbers -- R W Hamming
Garry Sikes
.iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.snmpTraps.4
does not exist. This is a link up trap, but for some reason net-snmp is looking in the SNMPv2-MIB for this trap (where it will not find it). This is not a matter of net-snmp not recognizing the IF-MIB (where the linkUp and linkDown traps are defined). This is a matter of it not looking for the IF-MIB for these traps. Net-snmp only wants to look in the SNMPv2-MIB for them. Is there any way to change this? I have tried explicitly telling net-snmp that it has the IF-MIB (something Wes asked me to try last week) with the following commands:
[snmp] mibs +FOUNDRY-SN-ROOT-MIB
[snmp] mibs +IF-MIB
But net-snmp still will not look for these mibs. Any ideas?
Garry
-----Original Message-----
From: Niels Baggesen [mailto:n...@users.sourceforge.net]
Sent: Wednesday, June 19, 2002 2:38 PM
To: Garry Sikes
Cc: Wes Hardaker; net-snm...@lists.sourceforge.net
Subject: Re: Problems with snmptrapd
On Tue, Jun 18, 2002 at 08:48:34AM -0700, Garry Sikes wrote:
>
> And here is what the traps look like once traphandle examines them:
>
> 2002-06-17 21:26:07 <device info removed> TRAP, SNMP v1, Community
> <removed>
> enterprises.foundry.products.registration.snServerIron.snSIXL
> Link Up Trap (0) Uptime: 38 days, 0:46:35.30
What you receive here is a generic link up trap, not an enterprise
specific trap related to your foundry enterprise. That is why snmptrapd
does not look at your defined trap handlers.
/Niels
--
Niels Baggesen -- @home -- Århus -- Denmark -- ni...@baggesen.com
The purpose of computing is insight, not numbers -- R W Hamming
-------------------------------------------------------
Dave Shield
> .iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.snmpTraps.4
> does not exist. This is a link up trap, but for some reason net-snmp is
> looking in the SNMPv2-MIB for this trap (where it will not find it).
> This is not a matter of net-snmp not recognizing the IF-MIB (where the
> linkUp and linkDown traps are defined). This is a matter of it not
> looking for the IF-MIB for these traps. Net-snmp only wants to look in
> the SNMPv2-MIB for them. Is there any way to change this?
Well, I've just hacked the agent to generate a linkUp trap, and both
4.2.3 and 5.0.1 versions of snmptrapd recognise this quite happily.
That's with a default installation, and no special config settings.
So the basic functionality is OK - the net-snmp library *does* load
the IF-MIB as well as SNMPv2-MIB.
We just need to track down why it's not working for you.
Remember that the MIB files are *only* used for translating between
names and numeric OIDs, which are used in two places:
a) displaying the incoming (numeric) OIDs in a more meaningful way
b) defining trap handlers
The tool doesn't look in a specific MIB file for a particular definition.
It loads everything it's been told to load, and then uses the resulting
MIB tree structure to look up a name, or a numeric OID.
So if the IF-MIB::linkUp OID isn't being recognised, then it's
because that file isn't being loaded properly.
A number of things you could try:
a) Run 'snmptrapd -Dparse-mibs .....'
and see whether it's trying to load the IF-MIB or not.
If not, what MIB files does it load?
> [snmp] mibs +FOUNDRY-SN-ROOT-MIB
> [snmp] mibs +IF-MIB
b) Combine these two into a single setting:
[snmp] mibs +FOUNDRY-SN-ROOT-MIB,IF-MIB
though the IF-MIB shouldn't be needed, since it's 'standard'.
I could understand this if you had
[snmp] mibs FOUNDRY-SN-ROOT-MIB
but the + should *add* this to the standard list, rather than replacing
that list.
c) Remove this entry from the config file altogether - does the IF-MIB
get loaded if you don't try to pull in any additional MIB files?
d) Add a traphandler that explicitly refers to the IF-MIB:
traphandle IF-MIB::linkUp /some/scripts
In each case, the -Dparse-mibs flag should help detect which MIBs
are getting loaded.
Dave
Garry Sikes
the trap a generic linkUp trap, or an enterprise trap that was
translated by trapd into the IF-MIB::linkUp trap?
Garry
-----Original Message-----
From: Dave Shield [mailto:D.T.S...@csc.liv.ac.uk]
Sent: Thursday, June 20, 2002 6:12 AM
To: Garry Sikes
Cc: net-snm...@lists.sourceforge.net
Subject: Re: Problems with snmptrapd
Dave Shield
> the trap a generic linkUp trap, or an enterprise trap that was
> translated by trapd into the IF-MIB::linkUp trap?
It was a generic linkUp trap - I just tweaked the snmpd.c file as follows:
--- snmpd.c 21 May 2002 12:32:04 -0000 5.7
+++ snmpd.c 20 Jun 2002 14:42:00 -0000
@@ -727,7 +727,7 @@
/*
* Send coldstart trap if possible.
*/
- send_easy_trap(0, 0);
+ send_easy_trap(3, 0);
#if HAVE_GETPID
if (pid_file != NULL) {
So when the agent starts up, instead of sending a coldStart trap,
it sends a linkUp trap. I *did* say I'd "hacked" the agent!
I'm intrigued by your talk of "translating" an enterprise trap.
Perhaps you should tell us exactly what you're trying to do?
Garry Sikes
from the enterprise v1 trap that comes in to the generic v2 trap that I
see in the output of trapd. All I am trying to do is set up some
passive monitoring in NetSaint, using snmptrapd to pass incoming traps
to a script that will parse and format them into something that NetSaint
can understand. The problem I am having is that I cannot get trapd to
recognize the linkUp/Down traps using the IF-MIB. It only seems to only
use the SNMPv2-MIB. I have a hack that handles interpreting the traps
coming in (I just used the "traphandle default <script>" to pass them
on). While this is effective, I should not need to pass all of the
traps on, and then parse them for the traps I need, and then parse them
again to format them. From the documentation (which is very
straightforward), trapd should handle filtering the traps. All of the
information indicates that this should be easy, which is why I do not
understand what trapd is trying to do in this instance. I even upgraded
from 4.2.1 to 5.0.1 with the same outcome. I have run out of ideas at
this point. Basically, I have worked around the problem, so now I am
trying to find out what the problem is with my setup (and for anyone
else who may have the same problems that I am experiencing).
Garry
-----Original Message-----
From: net-snmp-u...@lists.sourceforge.net
[mailto:net-snmp-u...@lists.sourceforge.net] On Behalf Of Dave
Shield
Sent: Thursday, June 20, 2002 7:45 AM
To: Garry Sikes
Cc: net-snm...@lists.sourceforge.net
Subject: Re: Problems with snmptrapd
Wes Hardaker
>> [snmp] mibs +FOUNDRY-SN-ROOT-MIB
>> [snmp] mibs +IF-MIB
Dave> b) Combine these two into a single setting:
Dave> [snmp] mibs +FOUNDRY-SN-ROOT-MIB,IF-MIB
I haven't checked, but I don't remember if the comma separated
delimiter works or not [I don't remember what I wrote, and it may be a
: or both]. Anyway, I actually know for a fact that separate lines
work because it's what I use all over the place.
--
Wes Hardaker
NAI Labs
Network Associates
Dave Shield
> Well, by translating, I probably should have said converting,
> from the enterprise v1 trap that comes in to the generic v2 trap that I
> see in the output of trapd.
Errr.... now you've *completely* confused me.
What sort of trap is 'snmptrapd' meant to be receiving - an
enterprise-specific one, or a generic one?
What is the traphandle entry that you'd expect/want this to trigger?
Dave
Dave Shield
any responses to the mailing list. I don't have the time
or inclination to offer private, unpaid, SNMP consultancy.
Keep discussions to the list, where others can both learn
and offer advice. Thanks. ]
> Sorry for the confusion. I want trapd to receive a Foundry enterprise
> trap.
>
> traphandle FOUNDRY-SN-TRAP-MIB::snTrapL4RealServerUp
> traphandle FOUNDRY-SN-TRAP-MIB::snTrapL4RealServerDown
>
> I want snmptrapd to see these traps and process them accordingly.
OK - so at *this* stage at least, how snmptrapd handles the IF-MIB
isn't really relevant. What's necessary is that it can recognise
the Foundry-specific traps, and invoke the appropriate trap handler.
If all the Foundry MIBs are in the same file, then that's why you'd
need to explicitly load the first MIB in the file. That will then
automatically pull in the whole file (including the TRAP-MIB).
If the MIBs are in separate files, then the above entries should
work anyway - with no need to have any sort of
[snmp] mibs .....
line in the config file.
Is this much working, or not?
I.e. is the appropriate trap handler script being invoked?
If so, then we need to turn attention to that script, rather than
snmptrapd and the snmptrapd.conf file.
Exactly what is that script trying to do?
Dave
-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/