On 8 Jan 2002, Michael Alan Dorman wrote:
> "TORRESANI, Roberto" <[EMAIL PROTECTED]> writes:
---snip---
>
> > Anyone of you has in the meantime created some patch for mon to enable snmp?
>
> I have created a tiny patch that fixes a couple of glaring issues with
> the stubs, so that trap packets can be recieved, but when I started
> thinking about how to map the SNMP stuff to MON watch/service specs,
> well, my head started to hurt.
i think this same thing is a problem with current mon traps, as one needs
to create many watch groups depending on how many unique hosts/services
you are trapping. perhaps we should add a new configurations option: the
"listen" group:
hostgroup snmp-hosts 1.1.1.1 2.2.2.2 3.3.3.3
listen snmp-hosts
service SNMP-Trap
MIB 1.x.x.x # or maybe MIB should replace the service string?
period _ANYTIME_
alert mail.alert _OPS_EMAIL_
numalerts 1
trapduration 300s
service MON-Trap
...
...
service SYSLOG-stuff
...
...
note the lack of a monitor, just as in the current mon trap configuration.
the new hash allows us to keep track of which hosts we are watching for
specific MIBs or mon trap services. another hash would allow us to
quickly do a reverse to figure out what hostgroups are looking for traps.
%listen{"group"}->{"service"}->{"variable"} = value
%listen_lookup{"MIB|service"} = (snmp-hosts other-trap-hosts)
in the trap handler, we'd have access to the sending host and the mib or
service string, and therefore be able to look up by the mib or service
string to find a group association. if there are multiple groups watching
the same thing, figure out which group we belong to, and do normal period
checking/authentication, then send the alerts for the specific
hostgroup/service.
>
> Mike.
>
-Tom Scanlan
OpenReach, Inc.
Network Operations
office: 732-254-0210 x-6022
cell: 732-682-3365
