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

Hi
Today I tried again to investigate how to send traps, I simply try to
use what was available trying to modify the less posbile
I took the last Squid 3.x release available, and write some code and..

The snmptrapd in my box got:
[root@outeiro log]# tail -f logtraps.log
2006-02-09 17:33:15 NET-SNMP version 5.2.1 Started.
2006-02-09 18:53:39 0.0.0.0(via UDP:[172.26.0.5]:3401) TRAP, SNMP v1,
community public
        SNMPv2-SMI::zeroDotZero Cold Start Trap (0) Uptime: 0:00:00.00

Just when I get up my squid.. (with -X for full debug)
2006/02/09 18:53:38.733| parse_line: pid_filename
/usr/local/squid/var/logs/squid.pid
2006/02/09 18:53:38.733| parse_line: debug_options ALL,1
2006/02/09 18:53:38.733| Starting Squid Cache version
3.0-PRE3-20060209 for i686-pc-linux-gnu...

And this is the code to generate the ColdStart generic trap..

void
snmpSendTRAPcoldstart()
 {
  struct snmp_pdu * pdutrap;
  struct snmp_session session;
  struct sockaddr_in sin;
  u_char packet[4096];
  int lenpacket;

    session.Version = SNMP_VERSION_1;
    session.community = (u_char *)strdup("public");
    session.community_len = strlen("public"); /* Length of
community name. */
    session.retries=2; /* Number of retries before timeout. */
    session.timeout=1000; /* Number of uS until first timeout,
then exponential backoff */
    session.peername = (char *)strdup("172.26.0.5");
    session.remote_port = SNMP_TRAP_PORT; /* UDP port number of
peer. */
    session.local_port = 0;

    bzero((char *)& sin, sizeof(sin));
    sin.sin_family = AF_INET;
    sin.sin_port = htons(SNMP_TRAP_PORT);
    sin.sin_addr.s_addr = inet_addr("172.26.0.5"); /* this is the
trapsink hardcoded, this should be a parameter */

        pdutrap = snmp_pdu_create(TRP_REQ_MSG);
        pdutrap->trap_type = SNMP_TRAP_COLDSTART;

        snmp_build(&session, pdutrap, packet, &lenpacket);
        comm_udp_sendto(theOutSnmpConnection, & sin, sizeof(sin),
packet, lenpacket);
        snmp_free_pdu(pdutrap);
 }

Is VERY ugly... but it's an start. As you can see it uses the same
interface comm_udp_sendto from the Squid and the output socket created
also in Squid (theOutSnmpConnection)

I think there are some useless code, the "session" structure is used by
the UCD-SNMP library, but its functionality is overwritten by the "Glue"
created in Squid, that surprises me a bit as the snmp_request_t struct
created in Squid it contains a "session" struct, that, in many cases,
are simply overlapping themselves.

Of course, this enhancement would required a new configuration paramter,
the trapsink, in this case is hardcoded to my own IP address
(172.26.0.5) only for this testing purpose.

Other tip is I had to touch a bit over there the snmp_pdu.h and others
because there is a ifdef UNUSED_CODE that eliminates some important
instruction if you want to add TRAP functionality.

In order to give trap functionality, long road ahead still, however, is
a very first step. I guess as a very first step should be to provide the
Generic Traps (ColdStart, WarnmStart, Down, etc)

Well, I know this is not exactly a big achievement, but to me was funny.

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

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

> Please, first, if I pollute too much the list let me know

Not at all. The list needs people participating.

> 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).

snmplib in Squid is a heavily modified CMU SNMP 1.8.

> 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.

If you intend to use the SNMP agent or client from CMU SNMP you will run
into some problems to fit this into the I/O loops of 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.

The code dealing with networking I/O has been replaced. The library
originally had all of that, but it wasn't useable from within Squid.

> 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.

Probably easier to stay within Squid from start. You can do a lot of
testing from the debugger using suitable print statements simulating
various events.

> 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

Indeed.

> 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?

My suggestions in no special order:

- Fatal errors

- Startup/shutdown events

- peers detected dead/alive.

- Log write failures

- Cache oversized

- Close to running out of filedescriptors

- Threshold on select/poll loop latency, to warn when there is overload
conditions.

and probably a few more.

Regards
Henrik
Received on Thu Feb 09 2006 - 11:52:08 MST