TCLSNM, a Tcl extension by Damir Delija, provides an interface to SNM.

Attributes  edit

location (404)

http://sistemac.carnet.hr/~ddelija/tools/TCLSNM

location (404)

http://malik.srce.hr/CARNet/tools/TCLSNM/

Download  edit

tclsnm-b1.tar.gz

See Also  edit

Writing an SNMP Agent ,Damir Delija ,SysAdmin Volume 12 ,2003-04

Fuzzy Logic and Network Management  edit

copied from http://public.carnet.hr/~ddelija/special.html

Updated : October /2008

If you are reading this, please forgive my English ...

When I started working here on SRCE in 1994 it was new and very interesting job. I've got some previous experiences where I've realized the importance of network and system management. It was nice opportunity to start using some professional tools like SNM2.0 and some experimental tools (nocol, scotty .... many others) in real life situation. There was many drawbacks, mostly organizational and "lack-of-money" nature which force us to improvise.

Usual situation was that we have donated equipment and SW which not fitted together (or vice versa). The most tragic was when we got CiscoWorks and SNM2.x on the donated SUN station which we were unable to use. To make things worse we can't buy new workstation or send people to proper education too.

All that force us to try SNM2.0 without CiscoWorks, just as management station. It leads to few nice things, first discovery and than chart generation. SNM's discovery was unable to draw map outside of our LAN, at the end we used fremont tool to create map and than awk filters to import it into SNM console. During that period we've idea that will be nice to have some script tool, able to do action directly on SNM console map. The result was tclSNM tool which enables TCL shell to interact with SNM trough snmdb API. Also there was strange tool written in awk which reorganize maps and create tree views on our network, it uses fremont output and create new maps working about 30-40 minutes for about 1000 node network.

When we defined events and alarms on our map strange thing happened. There was a lot of false events, when one of our main nodes went down usually management station drops too, just because of too many events. Also it was impossible to have operator working full time on console. Soon we were forced to try some lazy event filtering mechanism, with mail notification. There was some problems with log analyses and with report generation. We tried to use awk and TCL scripts for data analyses but it often put to much load on system if the console was running. During this there was nice testing tool which was able to get all SUN event/data messages and transform it into TCL lists, so we use it for report page generation (it is still available as trapper tool, at the begging it was aimed to show RPC messages because we were unable to catch traps)

Solution for our problem was to have monitoring without console, just status file, notification and logs. This conclusion rules us to the scripting tool. Scotty was at hand so we start use and soon find that it is worth gold. In no time all our effort was oriented to scotty and TCL, so we started merging different tools together trough TCL. For reports obvious solutions was web.

I always dreamed of getting enough time to write complete TCL interface to SUN management protocol, and than trough such tool add interface to apache or tclhttpd demon just to avoid console, and enable people to reach full functionality trough web. ( At the moment only what we have is snmdb interface and some map to animated gif conversion tool).

For reports we need a database, so we used first one at hand, msql (which was free, we still have same problems with money). For baselining and data collecting we added set of calls to scotty which enables as to dump agent directly into database Such collected data can be stored in monitoring process to, so we can do some conclusions per host and per model basis (it was very useful later during fuzzy experiments).

During this period of hard way learning often comes sentences with some fuzzy logic semantics:

    "this line is not to bad",

    "notify operator if this interface change status to often",

    "if inErrors and OutErros are high notify operator",

    "load on router is too high"

    .....

It was interesting idea to try if such statements can go directly into NM system, to find out which tasks in NM can be done (or helped) trough fuzzy and where are the catches ?

As we have most of the system already trough TCL it was obvious to try "fast-and-dirty" development completely in TCL. Such tool was realy inefficient. Soon it was obvious that some efficient fuzzy set operations in C was necessary. In 1996 we've done TCL wrap around excellent Dr. E.COX fuzzy tool kit and since February 1997 we are working on implementation. Scotty was essential!

Somewhere around 1995 I've got opportunity to enroll postgraduate studies for Ph.D. (SRCE was able to pay fees, so I decided why not) This my story about NM and fuzzy, it looks like nice try. This Ph.D. is not my primary job here so it is going quite slow. Most of writing is done in Croatian, so it is cryptic for English readers. If I catch time I'll try to write down as much as possible on English.

Here are some introductionary papers on English Fuzzy logic in network management and Some thoughts posted to comp.ai.fuzzy . Here is also my complete thesis.

It is abandoned ...

---