SNMP AGENT AND MANAGER

1


SNMP

AGENT AND MANAGER
DEVELOPMENT





Team Members:

1)

Arnav Aggarwal

2)

Brian

Walshe

3)

Paul Gildea

4)

Paul
Soprovici

5)

Peter Hannon














2


Table of Contents


1.

Team members and responsibilities

................................
................................
................................
............

3

2.

Motivation and Objectives

................................
................................
................................
.............................

3

3.

State of the Art

................................
................................
................................
................................
...................

4

4.

Design
& Implementation

................................
................................
................................
...........................

13

5.

Evaluation
................................
................................
................................
................................
.........................

20

6.

Conclusion

................................
................................
................................
................................
.......................

25

7.

Appendix

................................
................................
................................
................................
..........................

26




3


1.

Team members and responsibilities


Arnav Aggarwal

–

Report Writer/Researcher. Responsible for background research on
SNMP to understand

the various

technologies in which
the
SNMP protocol is still used.

Brian
Walshe
–

Developer
. His main responsibilities were to design

and implement

the
SNMP
Agent
.

Paul
Soprovici

–

Project Manager. H
e has contributed by managing and keeping track of
all the develop
ments of the team. Also Paul
was

responsible for preparing the s
lides
for
the presentations
.

Paul Gildea

-

Report Writer/Researcher
.
Responsible for background research on SNMP
to understand

the various technologies in which
the
SNMP protocol is still used.

Peter Hannon

-

Developer
. His main responsibilities were to design

and implement

the
SNMP
Manager
.

2.

Motivation and
Objective
s


Our primary objective is to build a
simple SNMP agent and M
anager

to monitor

and
me
asure various attributes of a Tomcat
web server application

using
Java
.

The
manager

periodically polls the

agent
to retrieve relevant information about the web server. The
agent will also send traps to manager when specific conditions are met.





4


3.

State of the A
rt


S
everal papers

were studied

to understan
d the problem at hand to find
an
efficient
and
scalable

solution

to the problem.
In the process we studied
various technologies
,
network management architectures

that are
used in monitoring, managing and
maintaining the remote devices in heterogeneous
and homogeneous
networks.
At present
there are two majorly
used protocols in the field of network management of them one is
the CMIP/CMIS proposed by OSI and the other
is SNMP (Simple Network Manager
P
rotocol) forwarded by IETF.



Our study was primarily related to the technologies u
sing the Simple Networ
k
Manager

Protocol to
manage,
control and observe the b
ehaviour of the web application

servers using a
n SNMP agent associated/
controlled by a m
anager
providing a user

interface
.



SNMP


The SNMP agent on the managed device serves to provide access to data
(managed object
s
) stored on the managed device. The SNMP manager can monitor and
control the managed device through the agent

by simple GET
and SET
commands
.



In complex

network systems

there is a need to
decentralise

management

functions
performed in the

network enabling better
efficiency

and resource u
tilisation
.

It is

also
clear that in
very large networks it is simply not possible to mo
nitor many sub
-
networks
over a w
ide area network without cau
sing a bottleneck at a centralis
ed manager. This
problem can only be handled properly by employing several distributed mid
-
level
managers or immobile data collectors. SNMPv2 attempted to introduce the manager
-
to
manager MIB’s for such purposes but failed due to the reasons such as added
complexity
etc.
SNMP is an accepted and widely supported standard and offers a low
-
cost,
small
-


5


footprint
solution for elements with scarce resources. There are many

management

applications
in the field

which are built on top of SNMP.


Distributed SNMP


The support for decentralised
management
was also built i
nto the earlier versions
of
SNMP which is the version1 in the form of remot
e monitoring system (RMON).
SNMP v
1 lacked support for the manager to manager interface (to provide

a

hierarchical
architect
ure) which wa
s later provided by the v2 of the SNMP
.
The
SNMPv3
management framework makes it possible to develop a set of distributed entities which
are composed of several interacting modules.

D
istributed
SNMP enables creation of
entities which can act a
s both the agents and the manager






In today’s

management systems

there may be

several agen
ts which implement new
protocols

such as Distributed Protocol Interface

(DPI)

or the more advanced Agent
extensibility Protocol

(AEP)

rather
than using the old legacy protocols such as the
SNMP.
One spe
cific system that we studied
made

use of

more complex protocols on the
mobile agents

to monitor and manage
SNMP agents in various network topologies

discussed below
[3]
:
-


1.

A mobile agent
arrive
s
at the

node
to

access attributes, variables and the current
state data

from the resident SNMP agent’s MIB.
Th
e mobile agent

has managerial
capabilities to act as a manager and
issue SNMP request packets to th
e resident
SNMP agent. The
mobile agent

can also

open a socket connection with the
resident MIB without being present at the resident MIB

but
this
is not a good
practic
e
due to

security reasons.
Such an approach has been

used

in [1] and in [2
]
using readily available Java SNMP classes
. The key
advantage
s are that there is
no need to
modify the

SNMP agent to provide access to i
ts MIB.




6


2.

A mobile agent

arrive
s at the node and has

the capability of extending the

resident
agent’s
MIB with certain meta
-
variables that it brings with it.
The SNMP DPI
protocol
and the
AgentX protocol
are
designed to allow
a sub
-
agent process to
enhance the

SNMP age
nt by first registering with it

and communicating with it

using the specified protocol.


3.


A mobile agent, having acquired information during its migratory activity, ma
y

arrive at the affected node

(
with lower performance etc.) or elsewhere in the
network. It then sends a
defined SNMP

trap to a remote SNMP manager. Both the
AgentX and the DPI protocol are

designed to enable the SNMP agent to receive
such a trap from a su
bagent/mobile agent and transmit it to an SNMP manager.


4.

It is possible

though less like
ly

that

some entity send
s

an

SNMP trap t
o a mobile
agent which acts as an

SNMP manager.

This assumes that the sender can actually
locate the mobile "manager" using the

mobile agent environment’s location
service.


Our aim is

to implement a simple SNMP

based

agent

which
retrieves,
monitors and
controls the

parameters of the Web application server internally

(
through the SNMP
messages)

rather than externally
as it
s
aves
us crucial traffic, since monitored information
can

be analyzed, filtered, summaris
ed inside the server and it also makes the

management
fault tolerant. For example if the web application server is being managed externally
using the Http port, and there i
s a service failure on the same port, the manager will
neither be able to GET or SET any commands on the web application server.




The enhanced SNMPv2 provides a manager
-
to
-
manager (M2M) MIB to support
a
hierarchical

management architecture.

The
services an SOA
-
compliant distributed system
is built from are expected to support introspection, be discoverabl
e, loosely coupled and
platform, location and transport
independent. There are a number of middleware


7


platforms that help to meet these requirem
ents. A good example of such platform for
implementing a monitoring system are Web Services (WS) providing access to the
syst
em’s functionality built with
Java Management Extension (JMX) support.


A
number of syst
ems

were studied

before settling in on
the

Apache Tomcat
Application server as it provides an interface to monitor
ing

using
JMX technology
. JMX
provides an interface between the Agent application and the web application server
allowing the allowing the agent to implement the managerial functions su
ch as retrieval
and setting of information
based on certain

conditions.




The JMX architecture consists of three levels: instrumentation, agent and

distributed services. JMX provides

interfaces and services adequate to the requirements
of monitoring and
management

systems
.

JMX provides access to detailed information
about the program through objects called MBeans. Java provides a set of standard
MBeans which can be used to access information on the Java Virtual Machine itself
-

memory usage, threads, etc
-

and these MBeans can be extended to provide more specific
details about the state of the program itself.

I
n this

project our developers made use of the
SNMP4J Java l
ibrary
in developing the
manager.
Also e
xtensive use
has been made
of
the
Advent
Agent To
olkit Java Edition

6.0

in developing the agent
.



Web Server

The two main contenders for

use in

this

project

were Apache HTTP Server and
Apache Tomcat

(Tomcat for short)

due to functionality
The
Apache HTTP Server
(Apache for short
) is

extremely popular
, being the first web server to handle over one
hundred
million web sites
.

Apache and Tomcat are open source
software;
they

are
dev
eloped and maintained by a

wide, decentralized,
community of peers with the support
of the Apache Software Foundation

(ASF).
These peers collaborate on forwarding the
functionality of the web servers via a consensus based
software
development process.


8


Main contributors to a project are chosen as managers for a project with t
he ASF
granting
membership to these
volunteers
who have contributed to
the
various
Apache projects.


The advantages and disadvantages of each of the web server technologies
were

investigated to gather information on which technology would be best suited to our
project.

The main features which get cove
red by one or both when looking at security and
dynamic content are: basic access authentication, digest access authentication, https,
virtual hosting, CGI, fast CGI, servlet, SSI, administration console and IPv6 etc. Both
run on an array of operating sy
stems/platforms
. Apache is seen to be faster than Tomcat
when handling static pages, as wel
l as being more robust,
suppor
ting CGI scripts, PHP,
Perl etc,

however it is important to use the right tool for the job at hand. Tomcat is used
for servlets/JSP

whi
ch Apache does not support
.
Tomcat

can also handle html pages

but

the Apache implementation is believed to be

better.

Because of the ability of Tomcat to
be managed and monitored using JMX, it was chosen over Apache which doesn’t provide
this interface.
Tomcat provides an extensive library of custom MBeans that can be used
for monitoring and management.

I
t was

decided
,

to create an agent in Java that would
run as its own process and collect information about the Tomcat server it was monitoring
through JM
X calls.

This
along
with ease of implementation and integration with JMX

and the
apt configuration settings and administration tools available

made Tomcat a good
choice
.

The n
ewest version of Tomcat is 6.x which uses the latest servlet and JSP
versions.
To
mcat is

made up of several components
; Coyote, Catalina, and Jesper 2.

Coyote

Coyote is a HTTP connecter which supports HTTP 1.1 for the web server. After
listening for a connection and receiving one on a TCP port Coyote is responsible for
sending the data

to the Tomcat Engine where it is processed and a response is sent back
to the client from which the request originated.




9


Catalina

Catalina is the servlet container used by Tomcat
.
A servlet container is a
compiled, executable program, it is used for loading, initialising and running the servlets.
It acts as an interface for the web server and the
servlets. Upon the arrival of a request,
Catalina maps the request to a servlet and sen
ds

the request to the servlet

in question
.
This

servlet proc
esses the request and returns an appropriate

response.
Next t
he container
translates the
response and sends it back to the w
eb server.

Large numbers of requests are
catered for and the container/o
bjects in the container are multithreaded. Each thread is
created and managed by the container and requests are handled concurrently.


Jasper

2

Jasper is Tomcat's
JavaServer Pages(
JSP
)

Engine.
The more recent versions of
Tomcat
use Jasper 2 which has more functionality included such as Background JSP
compilation and JSP Tag library pooling etc. Jasper 2 follows
Sun Microsystems's

JavaServer Pages 2.0 specification. It parses JSP files which are then

compile
d
into Java
code as ser
vlets
.

AdventNet WebNMS SNMP Agent Toolkit Java Edition 6



AdventNet WebNMS SNMP Agent Toolkit Java Edition 6 is a tool for network
management by use of the industry established standard management technologies such
as SNMP, JMX, and TL1. It is java base
d. This product is used for development of our
SNMP agent. This software can generate stub code for an Agent from a MIB. The agent
produced is capable of sending and receiving messages
and must only be instrumented

so
that these messages contain the releva
nt values.

It is free for evaluation for forty five days
and so suited our purposes for this project. It also was chosen as it caters well to our
specific needs by offering a wide selection of development tools, framework, and API’s.
It caters for multiple

platforms: Windows, Linux
,

Solaris etc.




10


The complete agent development process is handled. This includes everything
from building the agent to testing of the agent. AdventNet WebNMS SNMP Agent
Toolkit Java Edition 6 is built on SNMP, TL1, HTML, RMI, CO
RBA, JMX, Java Beans,

XML, JFC, JDBC, etc and so the necessary functionality for the system was embedded in
the software. Bundled with the software is a command line interface as well as a
graphical user interface for agent design, development and testing.
[4]



Fig. 1. Development of Advent SNMP Agent[5]




Features and Benefits


1.

Master Subagent Architecture


For multiple SNMP agents who are located at different IP addresses, a proxy
agent must manage the distributed network of SNMP agents. Management
efficiency in distributed applications is increased and this is defined by the
master
-
subagent architecture. He
re the SNMP proxy acts as the master agent and
the managed SNMP agents are registered as sub
-
agents to it.


2.

Trap notifications



Automatic alarms sent to manager when unwanted events occur.



11



3.

Rule Engine



Logic rules must be configured for the systems and this is catered for without
needing to edit code.


4.

Support



Atomicity, IPv6, transport protocols and persistent storage supported.[5]


As making calls to J
M
X

are relatively complicated, involving remote
procedure calls, and
the need to deal with potential errors in unmarshalling the objects returned, we used the
Adapter design pattern to simplify things. A class called TomcatInfo was created to act as
the adapter, and allows us to instrument the agent wit
h the minimal amount of change to
the generated code. How this class interacts with the system is shown in a class diagram
further on in the document.



The TomcatInfo class i
s responsible for managing the J
MX connection to the
Tomcat instance. It provides the information that we require from the server as simple
method calls. The methods of TomcatInfo handle
unmarshalling

the values returned by
the RMI calls and return them as primitive types where appropria
te. They do not handle
errors, throwing them, and they provide values "as is" converting to appropriate units is
left to the instrumentation code. (For example, the method getUptime() returns its value
in milliseconds, and this must be converted to hundred
ths of a second in the
instrumentation)



The TomcatInfo class also provides information that is not directly available
from the Tomcat MBeans, but which can be calculated from polling. This includes
calculating the number of requests per second the server

is receiving, and telling the
agent to send traps when this goes above a defined level.



12


SNMP4J/Swing Libraries/NetBeans

To develop the manager the
following software

was used:




NetBeans

o

This is a Java IDE which was used for writing the java code.

o

Writte
n using the NetBeans Platform.

o

Open source software platform for developing Java applications.

o

All modules needed for development included.

o

Additional language support added with plugins.

o

Chosen for ease of use, robustness and functionality.






Swing Libra
ries

o

Used for the development of the graphical user interface of the manager.

o

Bundled with NetBeans.





SNMP4J Library

o

Used for SNMP development with Java.

o

Used for developing agents and managers.

o

Downloaded separately.

o

Open source.





13


4.

Design

&

Implementation


At the outset of the project a design had to be created which would cover the
objectives outlined in our project. The main areas that were to be worked on were
build
ing a

SNMP agent and Manager to monitor

this. These would be used to
adm
inistrate a web server along with monitoring this web server. To do this

a variety of
attributes
should be measured.
The agent
’s

purpose is to

monit
or the status of the web
server and the manager decides what to do with the information.


To show that the
web
server is being managed correctly a few simple goals had to be obtained:



a.

Basic Communication

i.

Get and Set Attributes.

ii.

Restart Server.


b.

Polling

i.

Dealing With Expected Events
.



c.

Traps Directed Polling.

i.

Reacting and Analyzing Unexpected Events.

ii.

Denial
of Service

etc.



These were the basic conditions that must be met in the project, with some
possible examples mentioned. An incremental development process was best; get
something simple working and then work on including more functionality. The first ste
p
was to get some basic communication between the agent and the manager
working.
Some simple get and set requests were designed and implemented.

Next polling was
thought about and building on from that the next step was to think about trap directed
pollin
g.

Design and functionality of traps and how there were managed were thought
about before being designed. Following on from this development
of get
/set and trap
directed polling
functionalit
y

was successfully implemented. The particular examples


14


chosen to

show our server being managed will be discussed in more detail

along with the
components of the system

in this section.



System D
esigned

Using the Following C
omponents:


1.

SNMP Manager

(MS)


The management station has a set of management applications for
data
analysis, fault recovery etc; an interface by which the network manager
monitors and controls the network element (Web Application server in our
case).


2.

Management Agent
/
SNMP Agent


The management agent acts as an interface between the manager and the

network elements
through the internet.

The management agent responds to
requests for information from management station and also performs specified
action as requested by the manager station. The Agent may also be
responsible for sending Traps to the Man
ager when specific predefined
condition is achieved.



Wh
en designing the agent there were

two main options, the agent could be
implemented as an extension to the web server, or we could have it running as its own
process. Running as its own process would
be more robust, but would require it to
communicate with the web server through some means.

The
Management Agent

was
designed

using the WEBNMS
package;

the
MIB

was designed

in accordance with the
given specifications and then created java code using t
he
given package. The

Agent then
had to be

the
interfaced

with the Web server application server using JMX.





15


3.

Java Management Extensions (JMX)


JMX

is a
Java

technology that supplies tools for managing and monitoring
applications
, system objects, devices and
service oriented networks. The

resources are represented by objects called MBeans
(Managed Bean)
.

It
provides
tools for building distributed, Web
-
based and dynamic solutions for
managing and monitoring devices, applications, a
nd service
-
driven networks.
By design, this standard is suitable for adapting to legacy systems which
implement SNMP for providing
managem
e
n
t functions. The JMX technology
provides us

the means to create
Java agents,

implement
interface between the
agent a
nd
manager

(
at
a
remote location
)
, and easily integrate these solutions
into existing management and monitoring systems.



We use JMX which is supported by Apache Tomcat6 to integrate with the
agent existing at the same location. The Agent registers the M
Beans on the
MBean server and allows passing (GET, SET) values on the web application
server.


4.

Network Element

(Tomcat Server)


Apache Tomcat is a
n

open implementation of Java Server Technologies.
We implement the managerial functions to monitor the Apache Tomcat
Application Server, JMX provides us interface with the Tomcat

server

as
Tomcat is implemented in Java.


Some of the functions that we implement are restarting the Tomcat server,
getting number of connections to
it, sending traps if the number
of
connections exceed
ed

the given specified limit etc.


5.

Management Information Base (MIB)



16



MIB is a type of databas
e used for managing the devices in a communications
network. It comprises of collection of objects in a database used to manage
entities (network elements such as routers and switches etc.) in a network. The
database is hierarchical (tree
-
structured) and e
ntries are addressed through object
Identifiers.


6.

Simple Network Manager Protocol (SNMP)


It is a protocol through which the management station and the managed
entities exchange control and management information. SNMP is the
most widely
accepted

protocol for sending messages to the network elements to be managed.
We use both SNMP version one and SNMP version to in implementing our
designs.



Fig: SNMP based Management


In the above figure we can see the outline of the system that
was designed
and
implemented.




Management user launches the manager application.



17




Logic settings can be set in the manager applications graphical user interface.




An example of this is the threshold of requests per second that the server will
accept before sending a trap. The manager application will be looked at in detail
later in the report.




Messages between the agent and manager applications are sent over UDP

(
User
Datagram Protocol
) as this is the standard and is a simple connectionless protocol,
with SNMP being designed to be as simple as possible.



Messages are received on the agent side
by the SNMP Agent p
rocess. This
process encapsulates the SNMP Agent, the
Management Information Base and
any MBean information retrieved from the MBean Server.



The Agent application acts as an interface between the manager and the
rest of
its
process and the Web Server Process

and is managed by the management
information base
.



It responds to requests from the management application
.



When a trap is triggered the Agent
sends a
n SNMP

message
to the management
application o
ver UDP.



If the manager application requires information the agent is responsible for
retrieving the MBean f
rom the MBean Server.



JMX allows the SNMP Agent p
rocess
to connect with the Web Server p
rocess.



This Process consists of the MBean Server and the Apache Tomcat Web server
which is to be managed.


Class Diagrams

These show the final design and implementation of the manager class and agent
class systems. The
relationship

between each component along with the information each
component contains is show in the following two class diagrams:



SNMP Manager Class (Figure
3)



SNMP Agent Class (Figure 4)



18


Class
Diagram
s

showing SNMP Manager Class
and SNMP Agent

Class.

Fig: Class Diagram for SNMP Manager



19



Fig: Class diagram for SNMP Agent



20


5.

Evaluation



The project overall has been a success. The initial outline of the
project and what
was expected from a system managing a server has been completed.

The objective
was to create a
n SNMP A
gent and Manager to monitor

and manage a web server and
this has been implemented

effectively
.

Each feature that was added to the system
was
tested as it was introduced. This started off with basic communication between the
MIB
, the agent application and the manager application.



As

the application became more complex this scaled up to testing management of
a Tomcat server with the mana
gem
ent graphical user interface shown in the figure
below.

Various test cases were carried out to ensure each part of the system worked
as it should.

To test these currently one can enter various inputs into the management
application system, such as
entering text into a text field, selecting values from a drop
down menu or pressing a JButton on the GUI. The following
fields can be modified:





Polling Interval

o

Various time options



Restart Tomcat

o

Restarts web server



Threshold/Set Threshold

o

Enter amount of requests server will accept per second
before
a
trap

will be sent
.



HTTP Interface

o

Enable/Disable HTTP Interface



Get Server Info

o

Update server information fields



Get Servlet Info



21


o

Update servlet information fields



Clear Traps

o

Reset Traps fie
ld


Fig:

Figure 5: Web server management application graphical user interface.







22



Polling Interval

This is how frequently the systems will poll for traps. This can be configured
from the drop down menu to pick a
desired time. The default polling
interval is 30
seconds.

Restart Tomcat


This JButton tests the restarting of the Tomcat web server when a restart
command is sent.


Threshold/Set Threshold


Within this interface the functionality to set the threshold for connections to the
server per
second was implemented.

To test that poll directed traps are working the
following simple process was used:


1.

Download
Python.

2.

Start Tomcat, the Agent and the Manager.

3.

On the Manager set the connections per second threshold to
‘
30
’
.

4.

After hitting the "Set

Th
reshold" button a

dialog saying "The SNMP SET was
successful".

5.


If this was not shown there was
a configuration problem with the Agent,
Manager or Tomcat.

6.

Open IDLE (the Python GUI).

7.

T
ype in and run the following Python script:


from urllib import
urlopen

import time



23




for i in range(1000):


urlopen("http://localhost:8080")


time.sleep(0.01)



This code
is

a loop that connects multiple time
s

to the Tomcat
server
. Since the
connections to the Tomcat server are over
the
30 per second

threshold

a trap is sent to the
manager
. This shows

that the implemented trap directed polling functionality
has been
correctly

put in
place.

The code example above generates roughly 50 connections per
second.



By altering the sleep time in the code or the thresh
old value in the GUI it can be
seen that if the number of connections to the server is below the threshold value a trap
will not be sent and if the number of connections to the server per second is above the
threshold value a trap will be sent. This testin
g is also used in conjunction with the
polling interval drop down menu to make sure that a trap is only sent once for each
specified amount of time.



HTTP Interface


This JButton

is used for enabling and disabling the HTTP interface. Upon
pressing the JButton the text will change to ‘Enabled’ or ‘Disabled’ respectively

showing
the user the current status of the HTTP Interface
.

By
trying to access the default server
status page usi
ng a web browser
it was easy to see if the test was successful by checking
if the interface was active or not.

Get Server Info

This retrieves the current information from the server. This includes:




The last time and date that the Get Server info JButton
was pressed.



24




Host name of the
web
server.



Port number of the
web
server.



Up
time of the
web
server in days, hours, minutes and seconds.



Heap m
emory usage of the web server.


Get Servlet Info

This retrieves the current information from the servlet. This
includes:




The last time and date that the Get Servlet info JButton was pressed.



A list of servlet names.



Request count

-

amount of requests that a particular servlet name has
received
.

In the screenshot the localhost has received 2003 requests
from the ge
nerated Python script.


Clear Traps


The Clear Trap JButton

clears all the information from the traps field of the GUI.
This includes:



Date the traps were received.



Times the traps were received at



The OID’s



The trap error message. In this case the thresho
ld of connections
per second to the web server was exce
ed
ed
.






25


6.

Conclusion


This report clearly identifies the various network topologies possible for monitoring the
agent from the manager in a complex network.

We implement
a
basic implementation of
the
SNMP Manager and a SNM
P agent using the existing SNMP4J

library

and
AdventNet software.

We have implemented Traps and Polling functions in the system
and the Agent reacts if total connections on the server exceeds by the predefined
Threshold set by the ma
nager. We evaluated a lot of Web Servers to be used for our web
project , the main contenders were the WEBSPHERE(IBM), Apache HTTP Server, and
WebLogic Web Server and Apache Tomcat. But we decided to stick with Tomcat as it is
one of the most widely used W
eb Application Servers and it offers good implementation
support with the JMX

through the JMX
adaptors
.

We
use

the

SNMP
for our project
as it is arguably the most important network
management protocol even today due to its extensive implementation in the legacy
systems and its simplicity;
h
ere we substantiate this claim by designing our own Agent,
MIB

and manager. W
e interface to the Apach
e Tomcat Web Server using the
provided
JMX
adaptors
with the Agent. We completed the whole project in a very less time i.e two
months.


One of the possible drawbacks of our
system
is that it

was not designed as a multi layered
system possibly inhibiting t
he level of QOS required by the Manager System of the
current distributed networks. We stuck to the SNMPv1 protocol though we could have
used lots of advanced network protocols such as SNMPv2, SNMPv3, DPI, RDPI etc.
to
provide advanced capabilities such a
s authentication, encryption, BULK GET etc.
But we
refrained from this practice as we wanted to show the simplicity and effectiveness of
SNMP by using it with Current technologies
. Also the
system could be developed as a
Three T
ier
-
System in which the mid
dle layer acts as a both the Agent and the manager

(RMON Probes)

which can act a manager for the network layer element and give feeds to
the High Level
Central Manager
.



26


This section should draw conclusions and indicate any cave
ats about the prototype/ pr
oject
execution.

This should be about 1 or 2 pages or so (can be longer if required)


7.

Appendix

Put a URL to a file where the source code of your project is zipped

Put in any screen shots or anything else you believe relevant here







27


REFERENCES


[1]

Zapf M.,
Hermann K., and Geihs K., "Decentralized SNMP Management with Mobile Agents." In
Proceedings of IM ’99, Boston, May 1999.

[2]

Simoes P., Silva L., Boavida F., "Integrating SNMP into a Mobile Agents Infrastructure" Proc. of
IEEE/IFIP DSOM '99, Zurich Oct.1999.

[3]

B. Pagurek, Y. Wang, and T. White Department of Systems and Computer Engineering Carleton
University, Ottawa Ontario Canada

“Integration of Mobile agents with SNMP: Why and How”.

[4]

http://www.webnms.com/javaagent/index.html
,

(
2009
).

“
WebNMS SNMP Agent
Toolkit Java Edition 6
”.

ZOHO Corp.

[5]

http://www.webnms.com/javaagent/snmp
-
agent.html
,

(
2009
).

“SNMP Agent”.

ZOHO Corp.