Minutes of the 28th October ILUGC Meet

["Suraj.co.in" <suraj@xxxxxxxxxxxxxx>]

 Minutes of the ILUGC meet - Saturday,October 28th 2000

 The ILUGC met on Saturday the 28th, 2000 after great trouble.
It all started when a gentle man started sending the attendees saying
"Innikku Lie-nux meet illai". When Suraj started asking questions like
"Confident?, Lock kardiya? No meet today?" in the bacchan ishtyle, the
gentleman answered "Sure. 100%" and smiled as would any KBC participant
Later one of the newcomers (Srinivas, IIRC), mentioned that
there weretwo "American-Hinglish speaking" newcomers. All this goes to
infer that we *may* have lost a few newcomers for this meet.

 This meet had around 15 ppl. (with suraj and ravi, waiting to grab the
 OpenLinux 2.4 CDs (-; )

 The proposed talk was:

  1. SNMP - Mr. S.Gopinath

 The hurds demo has been postponed to the next meet as this
talk was expected to take around 1.5 hours.

 The SNMP talk started with a neat explaining of the needs of
maintaining a network, How SNMP evolved, etc.,.

 SNMP is "Simple Network Management Protocol". It can be used to
manage networks. For large, complicated networks, SNMP comes in handy
to know each and every detail of any router in the network. SNMP has been
defined from the ISO family (which Mr.Gopinath personally dislikes (-: )

 The History of SNMP goes as follows:
To test and commissiona network, ppl used ICMP. But this was not so
flexible and the packets could be sniffed. This gave way to SGMP (Simple
Gateway Monitoring Protocol) (which is not so simple, again quoting
Mr.Gopinath, (-: ). Then came CMIP (Common Management Implementation
Protocol) which too, was not so useful because of its inflexible features.

 The X400 docs's way of describing SNMP (as he feels) is very formal and
lousy. RFC1157 describes the protocol itself in a much better detail.

 ISO mentions that any networking protocol must be able to:
 1. retrieve the configuration info of the network
 2. give Performance info
 3. aid Fault diagnosis
 4. maintain security
 5. do accounting

 Though SNMP is handicapped for the fact that it cant do accounting, it is
reasonable at the other aspects.

 SNMP is in general know as a "Request-Response" protocol. This is because
SNMP's client requests for something using a REQUEST and the server responds
to this by a RESPONSE. Since its a ISO child, most of the terms are (kind
of)
clumsy to use (-;. For instance the Client is called the "Manager" and the
Server (which runs the snmp daemon) is called the "Agent". The client
(/Manager) talks on port 160 and the Agent(Server) listens to port 161.
There
are 5 basic types of msgs that can be transimtted between the two:

 1. GET REQUEST
 2. GET NEXT REQUEST
 3. SET REQUEST
 4. GET RESPONSE
 5. TRAP

 SNMP uses a "community" to organise and allow access to nodes which can
talk
SNMP and how. A community is similar to, in UNIX lingo, GROUPS. The SNMP
Agent
maintains a table of to which community a certain node belongs and what
access
this community has in doing SNM.


 The SNMP Agent stores information about each machine using a
MIB (Management Information Base). This is essentially a large tree
structure.
This tree can be accesses (and if the community is set properly, can even
change
the tree) using an "Object Identifier". An OBJ-ID is nothing but a series of
numbers seperated by a "." (period). (very similar to the IP Addressing
scheme).
each of the tree elements are assigned a number complying with ISO
standards.
These Numbers and their respective children  (hehe this was kind of
tricky...
I was about to type in "childs"!  (-; ) (which too have ISO
STD numbers) are accessed by putting the numbers from left to right
seperated by
periods. For instance, the tree looks like this:

                                ISO (1)
                      +- ... ----+---- ... --+
                      |          |           |
                                ORG(3)
                        -- ... --+-- ... ----------+
                                 |                 |
                                DOD(6)
                                 +
                                ...

 In the above tree each item is denoted by its own Object
Identifcation number (shown in braces). The Child DOD can be accessed by the
OBJ-ID : 1.3.6. It would be of no point trying to read something useful from
a
toplevel node in a tree. This was just an example... The children of this
node
can be accessed as 1.3.6.blah1.blah2.blah3...

 The most important objects in this tree are:

 1. iface (contains info about the interfaces like eth0, etc.,)
 2. Address Translation Table (IP <-> MAC,etc.,)
 3. Protocols (such as ICMP, TCP, etc., and their information)

 Let's now take a look at the Structure of a SNMP Packet:

 -------------------------------------------------------- ...
 | IP | UDP | Version | Community | PDU | Req.ID | Error |
 --------------------------------------------------------- ...

 ...-------------------------------- ... ------
     | Name | Value | Name | Value | ...      |
  ...-------------------------------- ... ------

 The Version contains the version of SNMP this packet belongs to. And that's
 not just it. There's a BIG story behind this versioning stuff.

 SNMP's first avatar Version 1.0 was insecure (and followed the above
Packet structure). The packets could be sniffed and the community was
just meant for identification and not for Access control. SNMP developers
came
up with SNMP2 which was supposed to be secure. But later they found a big
security breach and came out with SNMP3. What do you expect SNMP3 to be?
Ultra
High Secure (like debian?) no way! The security feature was removed! This is
what is currently used (without security).

 The packets have a version object in it to determine what version the
client
speaks and the server responds with a compatible RESPONSE. The PDU Field
determines what the Manager wants to do: viz 0-GET REQUEST, 1-GET NEXT
REQ...
and so on.

 The Well known client (or Managers) is available from snmp.ucb.edu (oops I
forgot the other client, from cmu?)

 That was the only planned agenda that went as smooth as a caldera install!

 Next was "rep" prabhu asking for votes for python classes/Bash scripting
classes. There were at first a majority who opted for the bash scripting
classes, thanks to suraj, for confusing every one. Now we'll have both (in
around 1H:20M) every month. Thanks prabhu!

 QOTM (Quote of the meet:)

 "It is very difficult to get into the IIT, be it via studies
 or by the bus"
     --Mr.M K S


 -Suraj


---
Visit our home page at: www.chennailug.org
Send e-mail to 'ilugc-request@xxxxxxxxxxxxxxxxxx' with 'unsubscribe' 
in either the subject or the body to unsubscribe from this list.