Pat
I commend RFC 2573, "SNMP Applications", to you. You'll love it since
you've "got the tee-shirt" trying - and succeeding - to follow SNA network
management.
It deconstructs the old "manager-agent" paradigm into 5 functions, and
suggests that any combination in one program can be considered.
The five SNMP application functions are as follows:
<quote>
- Applications which initiate SNMP Read-Class, and/or Write-Class
requests, called 'command generators.'
- Applications which respond to SNMP Read-Class, and/or Write-Class
requests, called 'command responders.'
- Applications which generate SNMP Notification-Class PDUs, called
'notification originators.'
- Applications which receive SNMP Notification-Class PDUs, called
'notification receivers.'
- Applications which forward SNMP messages, called 'proxy
forwarders.'
Note that there are no restrictions on which types of applications
may be associated with a particular SNMP engine.
</quote>
I left the sentence at the end it the "copy-and-paste" in order to support
my "any combination" statement.
Thus it would seem that the new V1.9 "SNMP manager API" just happens to
cover the first and third of these application functions and we should just
"get
over it"!
> Maybe my familiarity with the SNA world is getting in my way of correctly
understanding the intended use of a trap or notify, ...
A trap is very much the same sort of thing as an SNA (NPDA) event. I don't
think you need worry about any subtle distinctions.
> but I assume the agent simply performs a forwarding function here.
I see the merit of this idea but note that the agent would need to have the
capabilities of the fourth of these application functions. Checking the manuals
it's rather hard to be sure but I see no mention of this as a new function in
V1R9.
Having noticed that the sending of notifications is mentioned in Chapter
5, "Displaying policy-based networking information" in the System
Administrator's Commands manual - "... and generate notifications when
monitored traffic performance crosses thresholds defined in the Network
SLAPM2 MIB tables", I'm beginning to suspect that the third application
function above has had to be implemented for "policy-based networking" and
has then been presented as an external API. I suspect it has just been lumped
in with the description of the first of the application functions but should
really
be described as the "notification sending" API that need have nothing to do
with the first function.
It's worth bending some development ear over whether a "policy-based
networking" notification can be directed at a CS IP SNMP agent or it can only
be sent to an SNMP agent which specifically advertises the capability to
support the fourth of the application functions above.
> An SNMP agent often include a definition of a target for SNMP traps.
This is required. Otherwise traps just don't get sent.
> Generating a trap and giving it to the local SNMP agent means the generator
does not need to know where the trap is going.
That's where the merit is.
Incidentally, I'm encouraged to note that, while this discussion has dragged on
as so many threads do, we are still precisely addressing the OP's original
concern!
Chris Mason
On Thu, 27 Nov 2008 15:40:55 -0600, Patrick O'Keefe
<[EMAIL PROTECTED]> wrote:
>On Thu, 27 Nov 2008 14:36:43 -0600, Chris Mason
<[EMAIL PROTECTED]> wrote:
>
>>...
>>I was beginning to warm to the idea that the traditional, V1, SNMP
>>structure >had been extended to allow traps, sorry, notifications,
>>to flow in a peer-to-peer manner between daemons which otherwise
>performed
>the function of SNMP mangers in that they relied upon
>>SNMP agents in a "client-server" manner. However sending
>>notifications to the SNMP agent just doesn't fit!!!
>
>Maybe my familiarity with the SNA world is getting in my way of
>correctly understanding the intended use of a trap or notify, but I
>assume the agent simply performs a forwarding function here. I
>assume use of the trap or inform is simply to get a report of an
>exceptional event to a platform that can either perform a notification
>(like displaying an NPDA Alert in the SNA world) or invoking some
>automated function (like automating an MSU in the SNA world).
>
>An SNMP agent often include a definition of a target for SNMP traps.
>Generating a trap and giving it to the local SNMP agent means the
>generator does not need to know where the trap is going.
>
>>...
>>So, like you, I'm going to have to read up on these "super-traps" in >order
>to see what they're all about.
>>...
>
>I have not looked into "notify" except to notice that it uses TCP
>rather than UDP. I have no idea what other advantages it has
>over a trap.
>
>Pat O'Keefe
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
