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.
Enter the password to open this PDF file:
File name:
-
File size:
-
Title:
-
Author:
-
Subject:
-
Keywords:
-
Creation Date:
-
Modification Date:
-
Creator:
-
PDF Producer:
-
PDF Version:
-
Page Count:
-
Preparing document for printing…
0%
Comments 0
Log in to post a comment