Network Network Monitor Monitor Final presentation

Project in systems programming, Winter 2008

Students : Vitaly Zakharenko & Alex Tikh Supervisor : Isask'har (Zigi) Walter

Software Systems LabSoftware Systems LabDepartment of Electrical Engineering Department of Electrical Engineering

Technion - Israel Institute of TechnologyTechnion - Israel Institute of Technology

IntroductionIntroduction

Modern corporate networks often contain large number of local networks, which need to be monitored from a single location. The latter is often difficult due to security and accessibility restrictions between distinct LANs.

Monitor large corporate networks without passwords and special permissions

Project GoalProject Goal

Project Project DescriptionDescription

The system consists of multiple lightweight agents and a single server application.

Monitor App.

Agent App.

collects and stores measurement results sent by agents and provides statistics.

maintains database records of agents, monitored hosts and host state measurements performed by agents.

remotely configures the functionality of agents.

monitors state of the agents.

Basic Server Basic Server functionalityfunctionality

Basic Agent functionality Basic Agent functionality performs network measurements

and communicates results to the server.

allows the server to get & set settings defining the measurement functionality and the scheduling scheme of the measurements.

Server Details Server Details Uses local SQL Server DB file to store

all information. Does not use any local records to avoid DB synchronization problems.

Addition of new measurements is easy.

Classes of a specific measurement on the server side communicate only with classes of the same measurement on the agent side. Thus measurements are independent.

The application framework is independent of classes providing a specific measurement. Nothing needs to be changed in the framework when new measurements are introduced.

Implementation is fully multithreaded. No blocking ever occurs.

Server–agents communication is based on .NET Remoting.

Server Details (cont.) Server Details (cont.)

Server Details (cont.)Server Details (cont.)Intensively uses OOD

methodology and Design Patterns (Factory, Mediator, Publisher-Subscriber).

Server is implemented as a console application.

Build with special care to facilitate addition of new measurements.

Each measurement be configured remotely.

Each measurement’s scheduling scheme can be configured by the remote server.

Agent remembers its configuration (settings are serialized).

Agent Details Agent Details

All measurements are independent of each other and each one runs on a separate thread.

Design is object-oriented and decoupled.

Agent Details (cont.) Agent Details (cont.)

Implemented Implemented exampleexample measurementsmeasurementsSNMP device detection - agent broadcasts SNMP packets to IP

addresses within its subnet and reports detected SNMP devices to the server

ICMP (Ping) - agent broadcasts ICMP packets to IP

addresses within its subnet and reports dead and live hosts, loss ratio etc.

HTTP URL response time - agent tries to download a web

page from a number of URLs specified by the server, measures access time (or failure) and reports it to the server.

Implemented Implemented exampleexample measurements (cont.) measurements (cont.)

TechnologyTechnologyC# and .NET Framework.NET Remoting and Sockets MS SQL Server ADO.NET and strongly-typed

DataSet

Other topics used in Other topics used in project project Protocols SNMP, ICMP, HTTP. Sockets – previous versions of the

applications were based on sockets. C# TCP programming using Sockets

and Helper classes – in prev. versions. We learned to deal with TCP buffering problems.

Serialization, formatters, streams etc.

Using registry, WMI, DNS etc.

Literature used in projectLiterature used in projectC# for Java Programmers(642

pages) – studied througly. C# Database Programming(~400

pages) – studied througly. C# Network Programming(647

pages)– studied throughly.

Detailed Server functionalityDetailed Server functionalityManaging Agents Managing Agents The whole space of IP Addresses is

divided in sets. The sets are optionally overlapping.

To each set distinct functionality of Agents within the set is ascribed.

The IP Address set together with settings of Agents within the set are incorporated into a “policy”.

User can change both the set of IP Addresses covered by a policy and the agent settings ascribed to the policy.

Detailed Server functionalityDetailed Server functionalityManaging Agents (cont.)Managing Agents (cont.)The policies are stored in database. Each change of a policy (IP Address

mapping or agent settings) is communicated to the relevant known agents.

Only relevant agents are updated. Whenever a new (yet unknown)

agent communicates the server its settings are updated according to the highest priority policy it falls within.

Detailed Server functionalityDetailed Server functionalityManaging Agents (cont.)Managing Agents (cont.)Settings of each measurement are

managed by a distinct class on the server side.

The class both manages the database table, where the settings are stored and communicates the setting to the two classes responsible for performing the measurement on the agent side.

Detailed Server functionalityDetailed Server functionalityManaging Results Managing Results Results are stored in a local database. Each measurement result is communicated

by agents to a distinct class responsible for storing results of the specific measurement, providing measurement statistics and interfacing the measurement result record.

The measurement manager class notifies the mediator class of each new measurement result provided by an agent. As a result whenever a new (yet unknown) agent communicates results to the server it is registered in the database by the agent manager class, subsequently communicated by the agent.

Server: Class DiagramServer: Class DiagramAgents management Agents management

Server: Class DiagramServer: Class DiagramHosts management Hosts management

Server: Class DiagramServer: Class DiagramMain classMain class

Server: Class DiagramServer: Class DiagramFactoriesFactories

Server: Class DiagramServer: Class DiagramMeasurement result classesMeasurement result classes

Server: Class DiagramServer: Class DiagramMeasurement management Measurement management classesclasses

Server: Class DiagramServer: Class DiagramSetting management classesSetting management classes

Server: Class DiagramServer: Class DiagramSetting classesSetting classes

Server: Class DiagramServer: Class DiagramMediator classMediator class

Server: Class DiagramServer: Class DiagramPolicy management classesPolicy management classes

Server: Class DiagramServer: Class DiagramSetting set classes Setting set classes

Agent: Class DiagramAgent: Class DiagramMain class and aux. class Main class and aux. class

Agent: Class DiagramAgent: Class DiagramFactory classesFactory classes

Agent: Class DiagramAgent: Class DiagramWorker classesWorker classes

Agent: Class DiagramAgent: Class DiagramScheduler classesScheduler classes

Server: Database Diagrams Server: Database Diagrams Policy diagramPolicy diagram

Server: Database Diagrams Server: Database Diagrams Results diagramResults diagram

Server: UML page 1 Server: UML page 1

Server: UML page 2 Server: UML page 2

Agent : UMLAgent : UML

Summary and conclusions Summary and conclusions By planting an Agent in a LAN

one can efficiently raise restrictions imposed by LAN’s firewall. Thus, one can effectively monitor computers as if they all belonged to the same LAN.

C# is perfectly suited for programming tasks addressed in the application.

The application profited greatly from OOD support of C#, from powerful dedicated class libraries, easy DB access (via ADO.NET) and modern Remoting mechanisms.

C# is also widely used and perfectly compatible with many other technologies provided by Microsoft.

Summary and conclusions Summary and conclusions (cont.) (cont.)

Storing information to MS SQL server database file instead of a regular data file makes the data structure more orderly and simplifies synchronization issues of a multithreaded application.

In short, we Microsoft .NET.

Summary and conclusions Summary and conclusions (cont.) (cont.)

Future workFuture workThe program is implemented as a

console application. GUI should be developed.

The DB file may grow too large when many network measurement results are accumulated over time. The results should therefore be periodically summarized in form of statistics and saved in Hosts DB table.

EndEndGreat thanks to our supervisor,

Isask'har (Zigi) Walter for his great help and support

Thanks to the software lab staff for the support (Ilana David and Victor Kulik)