On 21 June 2012 13:35, <[email protected]> wrote:
> Just some quick follow up, I had the following in my snmpd.conf file, and at
> first attempt, had to make them mutually exclusive.
> Is it because I am using the same destination IP?
I'm not quite sure what you mean by "the following"
If you mean
trap2sink 192.168.1.101
trapsess -r 0 -v 3 -u user -l authPriv -a MD5 -A password -x DES
-X password 192.168.1.101
then that ought to work fine,
It would mean that the machine 192.168.1.101 would receive two copies
of every trap (which is clearly unnecessary), but there's nothing inherently
forbidden about such a configuration.
You shouldn't do it, because it's a bad idea.
But that's different from not doing it because it's fundamentally wrong!
> How does the agent know from the sendv2_trap API, which does not include any
> destination ip info, as to send either via SNMP v2c or 3?
The agent uses the settings in the snmpd.conf file to decide whether to
use SNMPv1, SNMPv2 or SNMPv3 (as well as where to send it).
send_v2trap simply means "please send this trap" - all the details are
left to the agent. If there are no trapsink (or equivalent lines), then
the trap won't actually be sent. If there are several such lines, then
multiple copies will be send - using the version(s) and destination(s)
specified in those configuration directives.
But that is all the responsibility of the core agent code - the MIB module
that requested the trap doesn't know or care about the details.
> Longer term, I will need to manipulate the notify tables directlly (as an
> SNMP client) to put in
> what could be multiple destination ips for a single SNMP v3 trap. Do you
> see this is being problematic
> assuming that the config file contains the one trapsess statement?
You can certainly set up MIB table entries dynamically to configure
trap destinations on the fly. If you search the mailing list archives,
you should find several explanations of this.
Essentially you need to mimic the set of entries set up via a config line.
What you can't do is set up a target using the snmpd,conf file, and then
manipulate this via SNMP SET requests. Config directives set up
"read-only" entries - which can't then be changed.
Again - search the list archives for details of why this is the case.
> I am required to send out SNMP v3 TRAPs not INFORMs, so it would seem engine
> id coordination is required. Interesting that in my test application, SnmpB,
> I did not have to specify an engine id, and all seemed to work fine.
>
> http://sourceforge.net/projects/snmpb/
You will need to talk to the SnmpB people about that.
I have enough problems finding the time and energy to provide support
for our own project - I really can't cope with providing assistance with
someone else's software as well. (Particularly a system that I've
never actually used!)
A *very* quick look at the source seems to indicate that this is
built on SNMP++, so it might be worth looking at the SNMP++
documentation as well. I seem to remember that this package
relies on the engineID being explicitly configured - it didn't do
engineID discovery.
But it's a good few years since I looked at this in any detail,
so things may well have changed.
But talk to the SnmpB people, and/or consult SNMP++
documentation for more details. (In general, Frank has
tended to be better than we are about documenting his system.
But then this seems to be a semi-commercial setup, so probably
has more resources, and definitely more incentive than we do!)
Dave
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
