1. Network Monitor Final presentation Project in systems programming, Winter 2008 Students : Vitaly Zakharenko & Alex Tikh Supervisor : Isask'har (Zigi) Walter Software Systems Lab Department of Electrical Engineering Technion - Israel Institute of Technology

2. Introduction 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.

3. Monitor large corporate networks without passwords and special permissions Project Goal

4. Project Description The system consists of multiple lightweight agents and a single server application. Monitor App. Agent App.

5. 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 functionality

6. 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.

7. 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.

8. 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.)

9. Intensively uses OOD methodology and Design Patterns (Factory, Mediator, Publisher-Subscriber). Server is implemented as a console application.

10. 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

11. All measurements are independent of each other and each one runs on a separate thread. Design is object-oriented and decoupled. Agent Details (cont.)

12. Implemented example measurements SNMP 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.

13. 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 example measurements (cont.)

14. Technology C# and.NET Framework.NET Remoting and Sockets MS SQL Server ADO.NET and strongly-typed DataSet

15. Other topics used in 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.

16. Literature used in project C# for Java Programmers(642 pages) – studied througly. C# Database Programming(~400 pages) – studied througly. C# Network Programming(647 pages) – studied throughly.

17. Detailed Server functionality 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.

18. Detailed Server functionality 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.

19. Detailed Server functionality 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.

20. Detailed Server functionality 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.

21. Server: Class Diagram Agents management

22. Server: Class Diagram Hosts management

23. Server: Class Diagram Main class

24. Server: Class Diagram Factories

25. Server: Class Diagram Measurement result classes

26. Server: Class Diagram Measurement management classes

27. Server: Class Diagram Setting management classes

28. Server: Class Diagram Setting classes

29. Server: Class Diagram Mediator class

30. Server: Class Diagram Policy management classes

31. Server: Class Diagram Setting set classes

32. Agent: Class Diagram Main class and aux. class

33. Agent: Class Diagram Factory classes

34. Agent: Class Diagram Worker classes

35. Agent: Class Diagram Scheduler classes

36. Server: Database Diagrams Policy diagram

37. Server: Database Diagrams Results diagram

38. Server: UML page 1

39. Server: UML page 2

40. Agent : UML

41. 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.

42. 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 (cont.)

43. 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 (cont.)

44. Future work The 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.

45. End Great 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)