[AGENT++] notification-log-mib questions

Sun Oct 24 23:11:30 CEST 2010

Hi Claus,

Meanwhile I have changed the AGENT++ code to support both
ways by using a compiler switch. The default will be your
preferred approach to no log any destination information.

The destination information is IMHO not redundant,
as the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB content
may change over time. The notification receivers can
easier filter their (missed) notifications if the
target information is included.
Besides that, logging all sent notifications simplifies
also debugging and verification of the agent configuration.

The new version 3.6 will be released within the next
two weeks under the Apache 2.0 license.

Best regards,
Frank

On 18.10.2010 20:15, Claus Klein wrote:
> Hi Frank,
>
> I have today checked the RFC3014 and RFC3413 about notification
> filtering and logging.
>
> The Overview of RFC3014 says: "It is indented primarily for senders of
> Notifications ..."
> And chapter 2.1.1 says:
> "... The later information flow is modelled here as the SNMÜ engine
> sending a notification to itself. ..."
>
> But the notification-log-mib description at the nlmLogEntry says for the
> nlmLogEngineTAddress:
> "The transport service address of the SNMP engine from which the
> Notification was received. ...
> This object MUST always be instantiated ...."
>
> This MUST is only true for v1 traps on the receiver site, I think!
>
>
> I understand the RFC in that way:
> We have to distinguish between notification sender and receiver!
>
> On the sender site, the sender address makes no sense. But the
> NotificationLogMib may be
> polled from the NMS if they have missed important Notifications. And
> there is no new information
> if you see each notification logged for each destination it was send.
> This can be found at the TargetAddressMib!
> So the most important information is the NotificationId, the
> DateAndTime, and the variables and the nlmLogVariableTable.
>
> The address , the EngineID, and the EngineTDomain is only important on
> the receiver site
> to distinguish different traps from different notification originators.
>
> The net-snmp snmpd does not fill this rows when it send a notification.
> But the snmptrapd fill them when it receive the notification.
>
> Regards,
> Claus
>
>
> On 14.09.2010, at 23:19, Frank Fock wrote:
>
>> Hi Claus,
>>
>> I think I have found the bug regarding the filtering:
>>
>> In line 1303 of notification_log_mib.cpp the first and second
>> parameter (both of type Oidx) are interchanged.
>>
>> Regarding the address field that is stored in the notification
>> log MIB, the reasoning of the RFC is questionable.
>>
>> The RFC describes the notification logging from the perspective
>> of an entity that collects notification (receiver).
>>
>> A AGENT++/SNMP4J agent receives the notifications through an internal
>> mechanism which replaces an external entity at the notification
>> sink. To be able to distinguish those sinks I log the target
>> addresses. Using the source address instead, would have violated
>> the requirement of the RFC to log the address from which the
>> notification had been received. Which is not the address/port
>> from the notification had been sent.
>>
>> Can you follow that model?
>>
>> Best regards,
>> Frank
>>
>> On 10.09.2010 21:16, Claus Klein wrote:
>>> Hi Frank,
>>>
>>> there is an additional issue I found today while testing the
>>> snmpNotifyFilterTable:
>>>
>>> With a filter which excludes the trap OID, the trap is not added to the
>>> notificationLogTable, but it is send anyway?
>>>
>>> That is wrong according the http://tools.ietf.org/html/rfc3413#page-15
>>>
>>> (1) Any appropriate filtering mechanisms are applied to determine
>>> whether the notification should be sent to the management target.
>>> If such filtering mechanisms determine that the notification
>>> should not be sent, processing continues with the next management
>>> target.
>>>
>>> ...
>>>
>>>
>>> and http://tools.ietf.org/html/rfc3413#page-64
>>>
>>> Otherwise, if matching entries do exist, a notification may be sent
>>> if the NOTIFICATION-TYPE OBJECT IDENTIFIER of the notification (this
>>> is the value of the element of the variable bindings whose name is
>>> snmpTrapOID.0, i.e., the second variable binding) is specifically
>>> included, and none of the object instances to be included in the
>>> variable-bindings of the notification are specifically excluded by
>>> the matching entries.
>>>
>>> ...
>>>
>>>
>>> With best regards,
>>>
>>> Claus
>>>
>>>
>>> On 10.09.2010, at 00:54, Frank Fock wrote:
>>>
>>>> Hi Claus,
>>>>
>>>> If AGENT++ indeed logs the notifications like you wrote
>>>> below, then it is a bug and will be fixed in the next
>>>> release. I will check that.
>>>>
>>>> Best regards,
>>>> Frank
>>>>
>>>> On 09.09.2010 23:10, Claus Klein wrote:
>>>>> Hi everybody,
>>>>>
>>>>> while working with the agentx master demo I tested the notification-
>>>>> log-mib.
>>>>>
>>>>> First, I found, that an target address (IPv6) is not right handled!
>>>>> Only 4 bytes are used instead of 16?
>>>>>
>>>>> Second, for each notify target, an row is created at the
>>>>> nlmNotifyTable.
>>>>> There is no new information if each address from the
>>>>> targetAddressTable is stored at the nlmNotifyTable again.
>>>>> The RFC says, the the source Address should be stored, not the
>>>>> destination!
>>>>>
>>>>> What I expected was, that one notification which occurs at the snmp
>>>>> agent will be stored, independent of the count of targets to deliver
>>>>> it as traps or informs.
>>>>> In worst case, it will only stored, but not delivered (and has to be
>>>>> polled by NMS from the nlmNotifyTable)
>>>>>
>>>>> Only an snmptrapd (trap client) has to write the source address of the
>>>>> trap to distinguish the same trap from different agents.
>>>>> That is the way, net-snmp implements it.
>>>>>
>>>>>
>>>>> What is your opinion about that?
>>>>>
>>>>> Whit kind regards,
>>>>>
>>>>> Claus
>>>>> _______________________________________________
>>>>> AGENTPP mailing list
>>>>> AGENTPP at agentpp.org <mailto:AGENTPP at agentpp.org>
>>>>> http://lists.agentpp.org/mailman/listinfo/agentpp
>>>>
>>>> --
>>>> AGENT++
>>>> http://www.agentpp.com
>>>> http://www.snmp4j.com
>>>> http://www.mibexplorer.com
>>>> http://www.mibdesigner.com
>>>>
>>>> _______________________________________________
>>>> AGENTPP mailing list
>>>> AGENTPP at agentpp.org <mailto:AGENTPP at agentpp.org>
>>>> http://lists.agentpp.org/mailman/listinfo/agentpp
>>>
>>
>> --
>> AGENT++
>> http://www.agentpp.com
>> http://www.snmp4j.com
>> http://www.mibexplorer.com
>> http://www.mibdesigner.com
>>
>

-- 
AGENT++
http://www.agentpp.com
http://www.snmp4j.com
http://www.mibexplorer.com
http://www.mibdesigner.com