Hi David,
>First, I don't believe that in the NET-SNMP code a session is
established between an SNMP agent >acting in the notification generator
with each notification receiver. Likewise, I didn't believe >that each
notification receiver establishes a session with each potential
notification generator.
Actually, when the agent reads the trapsess token in the config file it
creates a session for that specific manager. If the trapsess token is
indicating that the manager will receive informs, the agent discovers
the manager's engineID. It does that synchronously, if the manager is
down the agent will not respond to any other message since it is blocked
waiting for the discovery response until the discovery retries are done.
That is why I was looking for a way to implement this asynchronously.
Regards,
Pablo
-----Original Message-----
From: David T. Perkins [mailto:[EMAIL PROTECTED]
Sent: Friday, May 11, 2007 1:55 PM
To: Dave Shield
Cc: Passera Pablo-APP015; [email protected]
Subject: Re: Asynchronous EngineID discovery
HI,
This is sort of interesting due to how an SNMPengineID is used in
SNMPv3/USM in the msgAuthoritativeEngineID field.
First, I don't believe that in the NET-SNMP code a session is
established between an SNMP agent acting in the notification generator
with each notification receiver. Likewise, I didn't believe that each
notification receiver establishes a session with each potential
notification generator.
If the above is correct, I'm not sure how you would implement the below.
Just to review, SNMPv3/USM works in the following way:
1) Each SNMP engine has an SNMPengineID
2) There can be multiple SNMP engines running on a system
3) An SNMP engine supports one or more SNMP applications,
such as "command generator", a "command responder",
a "notification generator", and a "notification
receiver".
4) Each SNMPv3/USM message contains two SNMPengineIDs -
one is used for security (in the msgAuthoritativeEngineID
field) and the other is used to identify the source
of the management info (in the contextEngineID field)
5) In a v2Trap message when proxing is not used, both the
fields have the same value of SNMPengineID.
6) In an Inform message when proxing is not used, the
msgAuthoritativeEngineID field has the value of the
SNMPengineID of the notification receiver and the
contextEngineID field contains the SNMPengineID
of the notification generator.
7) When proxing is being used, the contextEngineID field
contains the SNMPengineID of the source of the
management info.
Missing in the SNMPv3 RFCs is a description of the table that maps
SNMPengineID and Transport Address. Each implementation needs to
maintain such a table, and optimally persistent it, and keep it up to
date.
However, it is only needed by command generators, notification
generators that are sending Inform messages, and proxies.
I hope this helps with your project.
Regards,
/david t. perkins
On Fri, 11 May 2007, Dave Shield wrote:
> On 09/05/07, Passera Pablo-APP015 <[EMAIL PROTECTED]> wrote:
>> There are two scenarios, that I am thinking, when the agent can
>> trigger a discovery.
>>
>> 1) When the session is opened.
>> 2) When an inform is about to be sent and the session engineID is
NULL.
>>
>> For the first option, to make the discovery asynchronously does not
>> seems to be very difficult. The session can still be created and then
>> when the report is received the session engineID can be filled.
>>
>> However, for option 2, the inform should be delegated until the
>> report with the engineID is received. Something like the current
>> proxy implementation should be used. What do you think?
>
> I agree with Robert - this sounds good.
> We look forward to seeing the code that you come up with :-)
>
>
>> Also, another scenario to consider is, what happened if an inform is
>> sent to that session that is waiting for the discovery response?
>> Another discovery should be triggered or in someway the session
>> should indicate that it is waiting for the discovery response.
>
> Ideally the second, I think.
> But I've no idea how straightforward this would be to do.
> It's a long time since I looked at the relevant code, and it's not
> somthing I ever felt particularly confortable with.
> Venturing into the low-level Net-SNMP library code is not for the
> faint-hearted!
>
> Dave
>
> ----------------------------------------------------------------------
> --- This SF.net email is sponsored by DB2 Express Download DB2 Express
> C - the FREE version of DB2 express and take control of your XML. No
> limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Net-snmp-coders mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
