>> It is an interesting question whether the current strategie to drop
>> all traps that do not match the community string of the receiving
>> SNMP session is reasonable or not. Community string are sometimes
>> used to indicate the context for a varbind list and there are cases
>> where you do not know all possible community strings in advance. In
>> these cases, it would be better to pass all incoming traps to all
>> trap handler and to let the receiving scripts filter the traps they
>> do not like to process.
Louis> Alternatively, have a mechanism whereby you can get all of the
Louis> traps regardless of the community; perhaps a distinguished
Louis> (e.g, null string) value for the SNMP session?
I do not really like this option. The way the current version works is
that the community string acts as *a* very simple filter. It seems
that this filter works pooly in some environments. So the obvious
first step is to do no filtering at all and let receiving Tcl script
do the filtering. All I need to do is to pass the community to the Tcl
script, probably storing it temporarily in the SNMP session handle.
If it turns out that filtering is needed and doing it in Tcl code is
too nasty or slow, we should think of adding new filtering options for
notification receiver SNMP sessions (to use SNMPv3 terminology). These
options should allow to specify much more powerful filters for e.g.
the notification originating address, communities and contexts
(probably regular expressions), trap types, probably also doing some
simple correlation (detection of repeated traps messages, ...)
But the default behaviour should be to pass received notifications to
all SNMP sessions that want to receive notifications.
I can change the 2.1.9 code base pretty easily to get this behaviour,
but this might introduce incompatibilities. Would such a change cause
great trouble in existing scripts (which would mean that I do not put
the change into the 2.1.9 series) or does everybody here on the list
think that the current behaviour is a "bug" and that changing it would
be a "bug fix" that is allowed to go into 2.1.10?
>>>>> WLEWIS@erac.com writes:
Bill> In the network I have over three thousand components that could
Bill> and do generate messages. Setting scotty up to receive traps
Bill> regardless of community is a very attractive.
The number three thousand seems to be a strong argument to put the
"bug fix" change into 2.1.10. ;-)
Juergen
Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3283)
-- !! This message is brought to you via the `tkined & scotty' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>. !! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.