On 29 June 2011 08:46, Joan Landry <joan.lan...@overturenetworks.com> wrote: > I placed the engine id of the receiver in the trapsess cmd (-e engineid of > receiver) > And this is what was failing.
My guess is that the engineID that you specified is probably different to that actually used by the receiver. Which would certainly explain why things were failing. > If I remove the -e on the trapsess line - it works. Because snmpd is probing to determine the receivers engineID automatically. > So is there any reason or condition that would require the -e engineid to be > placed in the trapsess cmd? > > Or can I remove this completely from my setup. If it works without, then you can remove it. Particularly when working with acknowledged notifications (i.e. informs). When using (unacknowledged) traps, then the default engineID will be that of the *sender*, and so snmptrapd would need to be configured with information about all possible trap source systems. Which can be a little cumbersome in a large network! So a common technique is to force such traps to be sent using the engineID of the receiver instead - i.e. requiring the -e option. Bottom line: in order to communicate - the two sides need to agree on a shared engineID to use. The SNMP specifications indicate which is meant to be the "authoritative" engine for both traps and informs, and the non-authoritative engine is expected to be set up to recognise the other engineID (either explicitly in the case of traps, or automatically for informs) But it doesn't actually matter what engineID is used - just as long as the two sides agree. So one safe approach would be to explicitly include the engineID in *both* the trapsess line (snmpd.conf) *and* the receiver's createUser line (snmptrapd.conf) That way, you know that they're in agreement, so things should work Dave > > > > -----Original Message----- > From: dave.shi...@googlemail.com [mailto:dave.shi...@googlemail.com] On > Behalf Of Dave Shield > Sent: Wednesday, June 29, 2011 3:39 AM > To: Joan Landry > Cc: net-snmp-users@lists.sourceforge.net > Subject: Re: snmptrapd - unable to receive informs > > On 28 June 2011 20:28, Joan Landry <joan.lan...@overturenetworks.com> wrote: >> It fails if (ISENGINEKNOWN(secEngineID, *secEngineIDLen) == FALSE) >> >> Even though the engine id is correct (it is the engine id of the snmpd >> server). > > Ah! That might start to explain things > > If you are working with unacknowledged SNMPv3 traps, then the authoritative > engine ID (as used in the PDU) is the engine ID of the *sender* (i.e. snmpd) > But with SNMPv3 _inform_ notifications, the authoritative engine ID is that > of the notification *receiver* (i.e. snmptrapd) > > >> So it as if snmptrapd does not know its own engine id when processing an >> incoming inform packet. > > But you've just said that it's using the engine ID of snmpd. > So things are *not* using it's [snmptrapd's] own engine ID > (although they should be). > > That's why I suggested removing the explicit engineID from the trapsess line, > to force snmpd to probe for it. > > An alternative approach is to pick an engine ID, and specify this > explicitly for *both* > the trapsess line (in snmpd.conf) *and* the createUser line (in > snmptrapd.conf). > That way, both sides of the conversation are using the same engine ID, > and things > should work OK. > > Dave > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
