RE: About SQUID and SNMP TRAPS , and snmp in general

Please, first, if I pollute too much the list let me know, there are a
lot of things I don't understand, and perhaps simply there is a reason
for that.

Second, at this very earlier stage, is my opinion to use more the CMU
library, it looks like nice, and most if the things are already done.
For instance, if my theory is correct, there is an ASN parser build,
that builds the MIB on execution time based in a MIB file (the mib.txt).
So, if you change something in the mib, you have not to modify much
code. At the other side, the snmp_core creates the MIB in memory in a
hard-coded way.
I don't see any problem in terms of special select, or interrupt calls
that can impact in squid.

However, the CMU library copied into the /snmplib folder, seems not to
create the sockets, it seems that is left to the implementation, and in
that point the snmp_core has some functions to do that, I guess taking
into account the problems of the select, and its blocking issues.

So, this is my plan, and let's see if I'm able to get results (that
remains to be seen):
Take the current files in snmplib (The cmu library), create an snmp
agent on my own, using the network functions in the snmp_core
To test the TRAPS, I'll create some false TRAP definitions in the mib,
and test it.
If I'm success, then, later we can review if is posible to integrate
into SQUID and how.

------------------------------------------------------

About what TRAPS to add
I think this point is independent of the implementation itself
We have three"type" of traps:
1) Those who inform about a "database" change (some oid modified)
2) Those who report about an event, for instance, "Corruption in the
DNS..." "Internal error..."
3) The "standard" ColStart, WarnStart, etc, etc.

For type 1, I think many other things come first
For type 2, here is the point where I'm strngly interested. To have a
proper monitoring, it would be nice when some critical issue happens a
trap be sent. Which ones ? Those who develop the core of SQUID should
let know, I mean, those events who are wrriten down in the log.
For type 3, I would not take care at this moment.

---------------------------------

-----Original Message-----
From: Henrik Nordstrom [mailto:hno@squid-cache.org]
Sent: lunes, 11 de julio de 2005 16:38
To: Lombao, Cesar
Cc: Henrik Nordstrom; Squid Developers
Subject: RE: About SQUID and SNMP TRAPS , and snmp in general

On Mon, 11 Jul 2005, Lombao, Cesar wrote:

> I was taking a look on the source code, and, besides the functions
> provided by the UCM snmp library, I don't see any other code to send
> traps.

There was quite a bit of code deleted from the library some years back..

have a quite strong memory of a fair bit of this being related to traps
and set PDUs.

> In fact, I'm still trying to understand how this library and the
> snmp_core.cc and snmp_agent.cc modules work together.

the library is used for encoding/decoding. snmp_agent.cc defines the
general MIB extractors and snmp_core.c is the agent implementation (and
also defines the MIB for some reason.. but this part is better moved to
snmp_agent.cc)

The original agent in the CMU SNMP library is not used for mainly the
same reason the agent in net-snmp doesn't fit well within Squid I
suppose.

> To send a trap is something, in theory, trivial. Open a dgram socket,
> and send the info to the trapsink.

Yes, and is why I think currently is easier to just
resurrect/reimplement the SNMP PDU processing components for this rather
than to look into how to fit a more modern SNMP agent into Squid.

> The point is not that, the point is all the details surronding that:
> MIB:
> Needs to be defined in the MIB the traps sent.
>
> TRAPS:
> Needs to be defined wich traps be sent. (When special errors happen?
> when MIB updated?)

Yes.

The two go pretty much together. When to send traps and what to include.

> CONFIGURATION:
> If SQUID uses its own snmp agent, then is needed to add a confguation
> line to set the trapsink destianation for the traps sent.

Yes.

> And of course, all the time I was talking about SNMPv1 only ;-)

Only desire to support SNMPv1/2c at this time. For SNMPv3 we better look
at using a modern agent.

Another point to consider is if ther is events requiring an SNMP Inform
message for somewhat reliable delivery, or if best effort traps is
sufficient.

Regards
Henrik
Received on Mon Jul 11 2005 - 09:03:05 MDT