[AGENT++] notification-log-mib questions

Mon Oct 18 20:15:31 CEST 2010

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
>>> http://lists.agentpp.org/mailman/listinfo/agentpp
>>
>
> -- 
> AGENT++
> http://www.agentpp.com
> http://www.snmp4j.com
> http://www.mibexplorer.com
> http://www.mibdesigner.com
>