netstar - Integrated Network monitoring and Traffic Analysis System

Transcription

1 netstar - Integrated Network monitoring and Traffic Analysis System Gamage EGIP, Lasantha PPT, Sajeewa BGS, Walpola MJ Department of Computer Science and Engineering, University of Moratuwa Katubedda, Moratuwa, Sri Lanka Tel: Fax: {irangag, payalla, sahans, malakajw}@cse.mrt.ac.lk Abstract This paper presents the design and implementation of netstar, which is an application that facilitates Network Traffic Analysis and Network Monitoring. In Network Traffic Analysis, netstar does the monitoring of traffic flows by collecting traffic data from different network points using the RTFM (Real Time Flow Measurement) and also fits into the ISO network management framework as a performance and fault management system. In Network Management, netstar does the resource monitoring and also the monitoring of systems and services which again fits netstar to the ISO network management framework. The feasibility of the application is demonstrated by configuring a Linux router based test bed and using several web, mail, ssh servers with clients accessing these services. The paper also addresses the limitations and future work possible for the system. 1. Introduction As the size and complexity of networks grow, the need for manageability becomes crucial. However, most firms continue to rely on costly, repetitive, and error-prone processes to manually manage and configure network devices. Businesses of all sizes can use network management to configure, monitor, and troubleshoot devices in LAN and WAN environments. Among the various aspects of network management, the monitoring aspect plays a major role and performance monitoring and fault monitoring are in great importance. Fault monitoring or simply monitoring the status of network entities is required for any network regardless of its size to deliver a seamless service to its users. The size or the scale of the network becomes a consideration when selecting the method for monitoring purpose. For very small networks, usage of several tools and manually monitoring the system may be adequate, but as the network grows in size and complexity this task of manual monitoring becomes infeasible and hence the requirement of automated and integrated network monitoring utility becomes clearly visible. The traffic flowing in network links carries a lot of metainformation, which is very useful for identifying problems in a network and may be useful for taking proactive steps to prevent severe future problems. The services provided by various networks are moving towards integrated environment, the monitoring strategies should also move towards the aspect of integrated monitoring utilities. The next most important fact that can be observed is, the services provided by networks are changing rapidly and hence it is very difficult for a monitoring utility which is developed to monitor a particular service to survive without changes. Traffic monitoring is an important field as well. Monitoring is not only useful to get information about the kinds of applications that are used on the network; it is essential for security measurements. One of the most important steps when setting up a secure environment is the installation of a monitoring system. This system can for example be used to trace back the path of an intruder that is being found on a system or it can be used to get information about attacks as early as possible. Most of the monitoring systems available today cannot cater the requirements discussed above since they have not been planned to adapt to the changes, which may occur in the future networks. The systems those satisfy above requirements are very much higher in price and difficult to setup so a small scale to mid scale enterprises or educational institutions are unable to afford them. The main objective of netstar, the system implemented by the authors, is to satisfy the key requirements of a network monitoring and a traffic analysis utility. At the requirement gathering stage, authors collected requirements for such a system and identified a subset of them, which forms the basis of that set.

2 Other than the functional requirements of the system, the authors found out that there are numerous non-functional requirements that are required to make a network monitoring system successful. The outstanding requirement was the accessibility to the system. In this context, it was found that a monitoring system that can be accessed from anywhere is the most dominating one. Among the other requirements the ability to represent data in real time or near real time is of great importance. The network administrators require knowing what is happening in the backbone links at the current instance to discover faults in the network. Knowing the current state only is not adequate to practice a good network management strategy. Archives of information collected by monitoring a network will also help a network manager to identify the long-term trends that help in network capacity planning. Having a system that has a lot of features but unable to summarize and give a quick overview is not very useful. In the survey it was observed that administrators find it easy to work with utilities, which summarize the current status of the network into graphical format and present in user-friendly manner. A summary and alerting mechanism makes a monitoring utility more valuable since these make administrator not bounded to go through very details and find the faults in the network regularly. The rest of the paper is organized as follows. Section 2 deals with the basics of network management and traffic analysis. It also introduces various standards for network management and also discusses architecture available for traffic analysis. Section 3 presents the technologies and the tools those are used in the netstar system. Section 4 describes the high-level architecture of the developed system and some of the implementation details. Design and implementation of the test bed, experiments and results are presented in section 5. Section 6 discusses the strengths and weaknesses of the software as well as the future work to be done. Finally, section 7 concludes the paper. 2. Network Management Network Management is the process of correct configuration, implementation of necessary security mechanisms; duly observation of the network to make sure that no erroneous or unexpected conditions would arise, implementation of necessary fault tolerance mechanisms, proper resource management and utilization of the network etc, to make sure that it operates at its best possible state. The goals of network management are listed in [1] as higher network availability, reducing network operational cost, reducing network bottlenecks, increase flexibility of operation and integration, higher efficiency, ease of use and security. The ultimate goal of network management is to provide users of network facilities a reliable and satisfactory service. Network management support tools are tools, which provide support for network administrators to achieve these goals Network Management Architecture The figure 2.1 shows a model of typical network management architecture. The key parts of typical network management architecture model are, Network Management Station The network management station runs the network management application that gathers information about managed devices from the management agent, which resides within a managed device. Figure 2.1: A Typical Network Management Architecture The network management application The network management application typically must process large amounts of data, react to events, and prepare relevant information for display. Managed Devices A managed device can be any type of node residing on a network, such as a computer, printer or router. Managed devices contain a management agent. Management agent A management agent provides information about the managed device to the network management application and may also accept control information. Network management protocol Protocol used by the network management application(s) and the management agent to exchange management information. Management Information The information that is exchanged between the network management application(s) and the management agents that allow the monitoring and control of a managed device.

3 2.2. Network management standards When considering network management standards there are two main protocols to highlight. They are, i. OSI Common Management Information Protocol (CMIP) proposed by ISO This protocol is becoming a standard really slowly. The core characteristics of this protocol are Management is powerful. Object oriented design of the protocol. Exchange of management information in reliable fashion. ii. Simple Network Management Protocol (SNMP) proposed by IETF This protocol is the most popular and widely used one. Now it has become the de facto network management standard. The core characteristics of this protocol are, Simplicity of management protocol. Variable oriented design of the protocol. The flexibility of using unreliable communication for exchange of management information. Since this is the de facto standard in network management this protocol was used in the developed tool ISO network management framework The ISO network management framework defines 5 conceptual areas of network management. These are in the areas of Configuration management Accounting Management Performance management Fault management Security management monitoring network traffic and seems to be becoming the standard in real time measuring of network traffic. A flow is basically a sequence of packets exchanged between two entities in a network. The concept of flow was defined in many variations. Two such variations are packet train model [2] and the flow definition based on TCP Connections [3]. But due to various reasons [4] these definitions are found to be not so effective for today s networking environment, especially to the Internet environment. Considering these limitations Claffy, Braun and Polyzos have introduced a more generalized, abstract and comprehensive definition for characterization of flows on the IP layer [5]. This definition is also based on the packet-train model, but unlike in other models/definitions it uses a timeout for flow characterization instead of connection information. According to this definition a flow is a sequence of packets matching certain criteria, exchanged between two entities on a network. For example UDP packets exchanged between two subnets could be considered as a flow according to this definition. There are two important parameters when considering this model of flow. They are, i. Flow specification The flow specification defines the matching criteria, which defines the flow. For example the matching criterion in above flow example is packets should be UDP packets. ii. Flow timeout If a flow is to be alive there should be at least one packet transfer during a flow timeout parameter time interval. There is no fixed value for this parameter and it varies from one flow to another Traffic Analysis As discussed in the introduction monitoring traffic of a network is a very important aspect of network management. The most primitive tool available for monitoring network traffic flows on standard ethernet is the ``tcpdump'' tool. This tool is useful to locate machines that transmit excessive data or to debug why one host is not able to communicate with another. Although it is possible to set filters for the ``libpcap'' packet-capturing library used by tcpdump, the tool needs a fast machine and generates a high CPU and busload Flow based traffic measuring methodology A widely accepted and efficient methodology in measuring network traffic is the flow-based methodology. This is a commonly used methodology for analyzing and Figure 2.2: Defining a flow based on a timeout during idle periods Network Monitoring Another important aspect in network management is the monitoring host and services running on them so that network administrator can be aware of the situation of important network devices and services provided by them. In case of host monitoring parameters such as availability

4 of hosts and resource utilization of hosts are considered very important for network administrators. In case of services monitoring the availability of network service is the prime concern Host Monitoring Monitoring of the hosts can be done with the use of ICMP or UDP protocol. In this, identified hosts are polled using ICMP or UDP at pre-determined intervals continuously. Based on whether a reply is arrived or not for a threshold number of requests, it is decided whether the hosts are in up or down states. Use of the identified dependency graphs come to play at this host monitoring stage. If a particular device which acts as a gateway for a certain other set of hosts is at a down state, it is obvious that the hosts that are beyond that gateway also are seen at a down state a with reference to the monitoring host Monitoring Services of Networks Services monitoring of a network is a major aspect in today s network management and monitoring needs. Some of the services that need to be monitored are TCP Services, Web Services and base servers. There are several technologies, which can be used in network services monitoring. One well-known and wellused way is use SNMP. Another way is to use telnet to machine and using netstat get the required data. But this requires telnet service with login in the remote machine Features selected to implement in netstar Out of the categories, which are discussed, the developed tool will mainly focus on the Performance management and Fault management aspects of network management. The tool will facilitate, Real time traffic analysis for performance and fault monitoring of the managed network. Achieved traffic information and resource status information analysis for the trend analysis and fault monitoring of the managed network. Resource and status monitoring functions to facilitate Performance management: and Fault management aspects of the managed network. Alerting network administrator in case of undesirable status or at the detection of unauthorized activities to allow fault monitoring of the managed network. Summarizing the information gathered in network monitoring module as a status map and summarizing the traffic information gathered as a load map. 3. Technologies and Tools used in netstar 3.1. The Simple Network Management Protocol (SNMP) The Simple Network Management Protocol (SNMP) [6] is an application-layer protocol that facilitates the exchange of management information between network devices. SNMP is widely used in network management tools in managing the network performance; finding the status of different elements, configure different parameters etc. SNMP, which is based on a manager/agent model, incorporates following key elements: A manager An agent A database of management information, managed objects Network Management protocol. Manager acts as the central controller of the protocol. Monitoring and controlling of each of the managed devices is done through the Manager. One or more Managers must exist on any managed network. An agent is a network-management software module that resides in a managed device. An agent has local knowledge of management information and translates that information into a form compatible with SNMP. Management Information Base (MIB), which acts as the database of management information, is a collection of information that is organized hierarchically. SNMP protocol is used in accessing various parameters that are there in the MIBs. The MIB is organized in a tree structure with individual variables, such as point status or description, being represented as leaves on the branches. SNMP uses five basic messages (GET, GET-NEXT, GET- RESPONSE, SET, and TRAP) [7] to communicate between the manager and the agent. TRAP is the only message issued by the Agent whereas all other messages are issued by the Manager User gram Protocol (UDP) UDP is a communications protocol that offers a limited amount of service when messages are exchanged between computers in a network that uses the Internet Protocol. UDP is an alternative to the Transmission Control Protocol and, together with IP, is sometimes referred to as UDP/IP. Like the Transmission Control Protocol, UDP uses the Internet Protocol to actually get a data unit (called a datagram) from one computer to another. Unlike TCP, however, UDP does not provide the service of dividing a message into packets (datagrams) and reassembling it at the other end. Specifically, UDP doesn't provide sequencing of the packets that the data arrives in.

5 This means that the application program that uses UDP must be able to make sure that the entire message has arrived and is in the right order Cisco: NetFlow Export This is a utility provided by Cisco organization in their switching devices, which uses Cisco ``NetFlow Switching''. The feature, which is referred to as ``NetFlow Export'', exports flow data present in flow table (which the switch already maintains for flow switching) via a proprietary, connectionless protocol to a management PC or workstation NeTraMet/NeMaC toolset This is a collection of tools, which is implemented by N. Brownlee, the chairperson of IETF RTFM working group as a part of example flow based traffic analysis and monitoring application adhering to RTFM architecture, which will be discussed in section 4. It is used as the base for collecting flow information flowing in the network links along with the Cisco NetFlow. 4. netstar Architecture and Implementation 4.1. The RTFM Traffic Flow Measurement Architecture The Real Time Flow Measurements (RTFM) working group of Internet Engineering Task Force, have published proposal for architecture for flow based measurement and analysis tools. The publication has become a RFC (RFC 2722) [8] and defines an excellent structure for a flow based monitoring tool. The architecture proposed is shown in figure 4.1. Meter Manager Meter Reader Analysis Application Figure 4.1: RTFM Traffic Flow Measurement Architecture The architecture mainly consists of 4 components, which perform 4 separate tasks, and interacts to achieve the intended goal. They are, i. Meter ii. Meter Reader iii. Manager iv. Analysis Application: The architecture specifies the functionalities of these components, interaction between these functional components and the possible component composition of them [8]. 4.2 System Architecture Overall architecture of the system The netstar system has a layered architecture with distributed processing model. System contains three separate abstract layers, which will cater for three different aspects. User Interfaces for Thin clients (This part contains only Dynamic HTML pages) User Interfaces for the Thick clients (This part contains Dynamic HTML pages and applications, which can be opened as applets via web) UI (This layer is responsible for managing the communication between front-end and back-end core functionalities. XML, Binary streams are used in the intercommunication) Communication Management and Control layer Traffic Analysis core Functionalities Collecting Analyzing Kernel Network Management Core functionalities Storing Figure 4.2: High-level architecture of the overall system Bottom most tier of the system known as the netstar kernel, contains the core functionality of the system. collecting, analyzing and storing are the basic responsibilities of this tier. Middle tier of the system is responsible for the support inter-modular communication, and for managing communication between front-end users and the back-end core kernel services. Binding different modules into one monitoring system is another aspect of this tier.

6 Top most tier of the system is the UI (User Interface) layer. Presenting the data coming from the backend core functionalities in user-friendly manner is the basic aspect of this tier. All the presentation logic is encapsulated within this tier. To enable remote monitoring this layer is implemented as a web-based functional component. The overall architecture of the system is abstracted in figure 4.2. Because of the layered architecture, the system is capable to do its processing in a distributed manner. This distributed processing model will help the system to withstand with higher loads in monitoring larger networks. The system mainly consists of two modules. Namely, Traffic Analysis Module Network Monitoring Module Architecture of those modules is discussed next in more detailed manner. Traffic Analysis Module The Traffic Analysis Module has two main sub-modules. They are, Real Time Traffic Analysis Module Archived Traffic Information Module Real Time Traffic Analysis Module The overall architecture of the Real Time Traffic Analysis Module is shown in figure 4.3. UI Communication Management and Control layer Kernel for Core Functionalities Traffic Analysis Core Functionalities Analyzing Collecting User Interface Intermediate Servelet RT Manager NeMaC NeTraMet fd_filter NeFlowMet NetFlow RT presenter The Combined RT Analyzer/ RT Presenter RT Analyzer Components developed by team Off the shelf components Figure 4.3: The architecture of the Real Time Traffic Analysis Module UI : The UI layer encapsulates all the presentation logic of the netstar system. Communication Management and Control layer: This layer abstracts all the details in communication and presents simpler functions to the adjacent layers. RT Kernel : As it can be seen from the figure 5.3 the RT Core Module is designed as a collection of several components, which interact to perform the core functionalities. This component based architecture makes the implementation and maintenance simple. The RT Core Module consists of following main components: RT Manager This component is responsible for serving the service requests of the users coming through Intermediate servelet. The RT Manager is also responsible for initiating and managing the Combined RT Analyzer/RT presenter processes and NeMaC meter reader managing processes, which interact to serve the request of the middle layer. RT presenter The RT presenter is responsible for presenting the flow information generated by RT Analyzer to the Intermediate servelet. RT Analyzer The RT Analyzer component is responsible for analyzing the traffic flows collected using NeTraMet and NeMaC according to user requirements and generating the information requested by the user. Fd_filter This is a component that is developed by Nevil Brownlee as a part of NeTraMet toolset. It is used as it is, without any modifications. NeMaC This is the combined meter-reader / manager of the NeTraMet toolset developed by Nevil Brownlee. In this module the component is used as a meter reader and as a manager to that meter reader. One thing to note here is that a tiny modification was done to the component given by Nevil Brownlee. NeTraMet This is again a component that is developed by Nevil Brownlee as a part of NeTraMet toolset. It is used as it is with out any modifications as a meter of our tool. NetFlowMet This is again a component that is developed by Nevil Brownlee as a part of NeTraMet toolset. NetFlow ( Export) This is a utility provided by Cisco organization in their switching devices, which uses Cisco ``NetFlow Switching''. Again the component is used as it is with out any modifications.

7 Archived Traffic Information Module The overall architecture of the netstar archived traffic information module is shown in figure 4.4. The module consists of several components, which has separate functionalities. Alerter: The alerter is responsible for sending alerts to the administrator whenever an access violation in the network traffic is detected. This alerting component is separate from the alerter in the network monitoring module in the sense of their functionalities, but both uses same backend to send messages to administrator. The alerter gets its input by the History Analyzer s output. The output is directed to various modules, which are responsible for sending pop-up alerts, SMS and e- mail. Presenation Analysis Access Physical Alerter History Analyzer Flow Load map Management Utilities HTML Generator History Infomration Graph Generator Infomration Archiver RRD Tools Round Robin base Figure 4.4: The architecture of the archived traffic information module History information Graph Generator: This is the main output component of the Archived Traffic Information System. It is responsible for generating graphical representations of the Archived Traffic Information. The functionality is implemented using the graph generating functionality of RRD toolset. The component reads information of configured hosts and sub-networks from configuration files and generates required queries for RRD Tools to draw graphs. HTML Generator: Even though the History information Graph Generator generates graphical representation of the archived traffic information, they cannot be displayed in a web browser without associated HTML pages. The HTML generator component fulfills this requirement. It generates web pages for each configured entity. Load Map: Load map is the graphical representation of the network links. The administrator can configure the links that are in the managed network and the load map will give a graphical representation of these links representing their endpoints, bandwidth and the current input and output load. The Load map component gets its link configuration data by a configuration file created by the administrator and the current link status by the output of the History Analyzer. The entire component is compiled into a single CGI and users can access this by any web browser capable of handling graphics. History Analyzer: This is the core module of the Archived Traffic information system. It is responsible for the analysis of the formatted flow file and calculation of the traffic flow for each configured hosts. It maintains a list of configured hosts to analyze the data and after each calculation the data is stored in databases using the archiving modules. Information Archiver: This component encapsulates the database access functions required by RRD Tools. It hides detailed commands and queries required by RRD Tools and present a set of uniform functions to the outside. The History Analyzer and Graph plotter access these functions in order to store and retrieve data to RR bases. Management Utilities: These utilities make sure the data generated by traffic NeMaC are in correct format so that the analysis process can extract them. file management utility and fd_filter are the components present in this utility. RRD Tools: This component is third-party software developed by Tobias Oetiker. It is responsible for managing the Round Robin bases. All the accesses made to RR databases are made via this tool set. Network Monitoring Module Network Management Module is designed based on a layered architecture, which makes the implementation and maintenance much effective and uncomplicated. Also the layered architecture makes the layers to behave in a layer independent manner, which is extremely important when considered from the perspective of extendibility and enhancability. A high level overview of the netstar Network Management Module is shown in figure 4.5.

8 Presenation Analysis Access Physical Info Presenter Poller 1 (SNMP) Analyzer Hosts to be monitored Alerter Poller 2 (UDP Ping) Infomration Archiver History Infomration Graph Generator Infomration Archive Figure 4.5: The architecture of the Network Management Module Info Presenter: This component does the presentation of information regarding the host status and the resources being monitored to the user in the appropriate format. Info Presenter module makes use of the information that is provided through Analyzer module. Alerter: This module does the sending of notifications to the authorized personnel in case of undesirable states of the hosts. Sending of alerts can be configured by the administrator specifying under which situations the alerts have to be generated. Alerts are sent as s, SMS (Short Messaging Service) and as pop-up messages. History Information Graph Generator: This component does the generation of graphs based on the information that has been archived in RRD databases. Graphs are generated dating back up to one month from the present date. Status Map: Status Map provides a quick overview of the status of the various network devices in the monitored network. It summarizes the detailed information produces by the monitoring modules and present in a graphical way so that the administrator can quickly figure out the location of fault. The module reads the configured devices to monitor by a configuration file created by the administrator. The statuses of the devices are obtained from the xml files generated by different monitoring modules, functioning at the backend of the system. The output of this module is a standard HTML including a graphic and hence any web browser capable of handling graphics and JavaScript is able to present the status map. Analyzer: Analyzer component is the module that process data gathered through the two polling modules, so that the data is sent to the Presentation modules in the correct format that they require. Some degree of decision-making is also carried out in this module based on the results of the information that is being processed. Information Archiver: This component does the archiving of the parameters that are specified by the administrator for the future reference. This archiving is done in daily basis and the archived information is kept stored in Round Robin bases (RRD). This archived information is used to plot graphs using Graph Plotting Module, which presents the archived information in graphical format. This information can be made use in the process of future decision-making, which would help managing the network efficiently. SNMP based poller: This component is based completely on SNMP (Simple Network Management Protocol), which is a protocol that is designed for the purpose of network management. Accessing of information regarding the system resources of each of the host to be managed using netstar is done by this component. UDP based poller: This component does the communication with hosts that need to be managed in getting the information such as whether a system is at running state or is it being shut down, whether a specified service running in a host machine is running or not, identification of open ports in a host within a given port range etc. This component communicates using UDP datagrams in getting this information from the hosts to be managed. 5. Testing and Results 5.1. Design and Implementation of Test Bed For the testing of the performance of the system, a test environment was set up which comprised of a Linux router, a switch, a hub and 5 host computers. Test environment consisted of 2 subnets, one of which was using global IP addresses and the other which uses Class A private IP addresses. First the server on which the netstar system is to be run had to be configured. For this a Celeron 1.7GHz machine with 256MB RAM running Redhat Linux 8 Operating System was chosen. On this machine, additional Perl modules that are required for the Network Management Module had to be installed. Then a machine that runs on Redhat Linux 9 was configured to be used as the router. IP forwarding was enabled for routing. For the collection of traffic flows, NeTraMet was stared on the ethernet interface of the router. A 10Mbps Ethernet Uplink was connected to the switch for the internet connectivity. A Mail server and also a Web server were set up for the test bed.

9 A machine that runs on a 2.5 GHz Pentium4, 512MB RDRAM with 32MB VGA was chosen as the Monitoring Station Monitoring Station PC Windows XP This graph presents the usage of the link entire link filtered and grouped based on a default set of ports. At this particular instant, the traffic on HTTP (port 80) is much higher compared to other ports as the web server is being accessed. Hub Internet Link cache.mrt.ac.lk cse.mrt.ac.lk Linux Router Switch Mail Server Web Server Net Bios Figure 5.1: Test Environment netstar System Figure 5.3: Usage Graph when filtered on IP Address In this, the graph shows the traffic of the link when the web server is accessed, filtered based on a given IP address ( at this instance). HTTP traffic is much higher than the other traffic as the web server is being accessed here Test Results After setting up the Test Environment, testing of the Real Time Module and the Network Management Module were carried out separately. Testing of the Real Time Module Traffic generated when the web server (IP address ) was accessed from the machine with IP address was monitored. Figure 5.4: Usage Graph when filtered on subnet address Graph above shows the traffic generated when the web server ( ) is accessed, filtered based on the subnet address Here also it is the HTTP traffic, which is at the highest level as the HTTP traffic of the subnet is at a high state when the web server is being accessed. Testing of the Network Monitoring Module When the Network Management Module is run, the resource usage of the system was monitored. Figure 5.2: Usage Graph for the entire link

10 Figure 5.5: Resource usage of the system when netstar Network Management Module is running System was running at 1.7GHz and 256MB of RAM and the standard system specific processes were running in the background and tests were carried on X windows system. The average CPU utilization before the test was started was around 5% and the memory utilization was 160MB. When the system was tested for the 3 servers that are on the subnet, average CPU utilization has increased up to around 7% from its original 5% and the 6MB of additional memory was consumed. When the time to detect parameter was checked for systems and the services when some of the systems and services were intentionally brought down, that had always been below 6 minutes under 3 different CPU load conditions where the average CPU utilization was at around 85%, 50% and 10%. 6. Discussion A possible enhancement to system will be to introduce a module where user can specify set of rules to filter the traffic and then analyze traffic according to the rules specified by the user. This will give user more flexibility in the traffic flow measuring. Another possible enhancement is to indicate the ports, which mainly contribute to traffic of TCP/UDP nonspecified ports in case of the traffic of TCP/UDP nonspecified ports showing abnormal statistics. Considering the Archived Traffic Information module the major disadvantage is the unavailability of detailed traffic information for traffic happened in long ago. This requirement cannot be achieved completely, but may be compromised by allowing users to specify the resolutions of data for each monitored entity. Also the current system does not support dynamic graph generation at user s request. This limits the system have predefined set of graphs and hence the system cannot provide zoomable plots. Adding a CGI module that allows to user queries to pass to RRDtool will easily achieve this task In the network monitoring, the configuration of the hosts has to be done manually by editing a configuration file. This makes the process of configuration a bit cumbersome work and also raises the limitation of necessity to be physically being present at the management station to make changes. This issue can be solved by provision for changing the configurations through a web-based interface. As the module that checks the system/service availability is done through UDP based pinging, there is a possibility that the system would report some of the results erroneously due to the loss of UDP datagrames due to their unreliable nature. The use of a TCP/ICMP or an approach based on both SNMP and UDP would improve the situation. (But these approaches would add more overheads to the network and the system) Incorporation of automatic host discovery functionality would add more value to the Network Management Module. Incorporating appropriate security mechanisms would add more value to all the functionalities of the system. 7. Conclusion The project netstar was started with several goals in mind and the level of achievement of those goals decides the success we made in the project. The main goal of the project was to, support integrated traffic and status monitoring system. This was achieved by, developing two main modules of the system; the traffic analysis module and the network-monitoring module. The combined system had a simple easy to use GUI, which facilitates the traffic monitoring and the network status monitoring in a single application. Real time traffic measurement was the other main goal of the project. In the developed system we are providing near real time monitoring for network traffic with various classifications according to the transport protocol, IP addresses and the port number. These features help the user to get a clear insight in to the traffic flowing in the network link. This paper introduces the netstar system developed by the authors. It started with the introduction and then explained the aspects of Network management specially focusing on traffic analysis and network monitoring. The paper also introduces the technologies used by the netstar system and provides a detailed account of the

11 high-level architecture and the implementation of the netstar system. The feasibility testing of the developed tool was carried out using a test network simulated by authors. Experiments conducted and the results obtained have been shown. As it can be seen from the obtained results the system meets its expectations. References [1] Udupa, Divakara K., Network Management System Essentials, McGraw-Hill, U.S.A., 1996 [2] Jain R., Routhier S. A., Packet trains -- measurement and a new model for computer network traffic, IEEE Journal on Selected Areas in Communications, 4(6), September 1986 [3] Mogul J., Observing TCP dynamics in real networks, In Proceedings of ACM SIGCOMM '91, [4] Siegfried Löffler, Using Flows for Analysis and Measurement of Internet Traffic Diploma Thesis, Institute of Communication Networks and Computer Engineering (IND) of the University of Stuttgart [5] Claffy K. C., Braun H.W., Polyzos G. C., A parametrizable methodology for internet traffic flow profiling. IEEE JSAC Special Issue on the Global Internet, 1995 [6] SNMP Introduction, [7] Stallings William, & Computer Communications-(6th Edition), Prentice Hall, 2000 [8] Brownlee N., Mills C., Ruth G., Traffic Flow Measurement: Architecture RFC 2722, October 1999