Design and implementation of an SNMP based data collector that will aid in the design of a multi-vendor network monitoring system.
UNIVERSITY OF ZIMBABWE DEPARTMENT OF ELECTRICAL ENGINEERING
Submitted by
TAKAWIRA DZORO (R1713515)
DISSERTATION SUBMITTED IN PARTIAL FULFILMENT OF REQUIREMENTS FOR THE MASTER OF SCIENCE DEGREE IN COMMUNICATION ENGINEERING
Supervisor: Dr T. Marisa
DECLARATION
I hereby declare that the dissertation report entitled “Design and implementation of an SNMP based data collector that will aid in the design of a multi-vendor network monitoring system” is a genuine record of the researcher‟s work carried out in partial fulfilment of the requirements for an MSC Communications engineering degree at University of Zimbabwe under the supervision of Dr. Marisa.
Student Signature Date Takawira Dzoro
Supervisor Declaration
It is certified that the above statement made by the student is correct to the best of my knowledge and belief
Supervisor Signature Date Dr T. Marisa
i
Abstract
As network operators in Zimbabwe continue to grow their networks every day, network monitoring is also becoming one of their most challenging issues. The operators use network equipment supplied by different vendors and therefore the monitoring tools that they are currently using are also vendor-specific. Due to the large costs associated with monitoring tools and licenses, many network elements are still being monitored manually which becomes practically impossible as networks grow in size and complexity. Besides purchasing monitoring tools from equipment vendors, some of the solutions implemented by administrators locally include the use of free online ping and traceroute tools. While such solutions can work for a small number of nodes in a single geographical location, they fail to scale to bigger and complex network infrastructures. Purchasing monitoring tools require foreign currency and therefore it creates more overheads and expenses to the company resulting in low returns of investments. This research feels the gap and provides an efficient multi-vendor networking system. SNMP protocol was used to build a data acquisition layer of the tool. It is in this layer where fault information is collected from network elements and delivered to the main application for processing, storage, and dashboard display. The data collection layer was designed to query in real-time, the Network Elements‟ online/offline status, interface connection status, Linkup/link-down status, and link performance utilization. A combination of three switches from different vendors (Huawei, ZTE and Cisco) was used to come up with a prototype network for testing and validating the results.
ii
Acknowledgements
I would like to thank my family for both the financial and emotional support they gave to me, especially my wife Nyaradzo Dzoro for always being there for me. Thank you Dr. Marisa for the guidance and support as my research supervisor. I am also grateful to the lectures in the University of Zimbabwe Faculty of engineering department for the basic theory they shared with me during taught courses which was very essential in implementing my research. A big thank to the University of Zimbabwe institution as a whole for providing the best research environment. Above all, sincere gratitude to the Almighty God for good health and strength to push through all the obstacles.
iii
Abbreviations
API Application Programming Interface CMIP Common Management Information Protocol FCAPS Fault, Configuration, Accounting, Performance, and Security. HTTP Hypertext Transfer Protocol ICMP Internet Control Message Protocol IP Internet Protocol ISO International Organization for Standardization MIB Management Information base NE Network Element NMS Network Monitoring System NNTP Network News Transfer Protocol OID Object Identifier PDH Plesiochronous Digital Hierarchy POP3 Post Office Protocol RAM Random Access Memory RDBMS Relational database management systems RFC Request For Comments RRD Round Robin databases SDH Synchronous Digital Hierarchy SLA Service Level Agreement SMS Short Message Service SMTP Simple Mail Transfer Protocol SNMP Simple Network management Protocol SSH Secure Shell SQL Structured Query Language TCP Transmission Control Protocol UDP User Datagram Protocol
iv
Listof Figures and Tables
Figure 3.1: Net-SNMP installation procedure ...... 22
Figure 3.2: Net-SNMP installation procedure ...... 23
Table 3.0: Test snmp agent details ...... 23
Figure 3.3: snmptranslate example ...... 24
Figure 3.5: snmpgetnext example ...... 24
Figure 3.6: snmpbulkget example ...... 25
Figure 3.7: snmpstatus example ...... 25
Figure 3.8: snmpset example ...... 25
Figure 3.9: snmptrap.config ...... 27
Figure 3.10: snmptrapd.py ...... 28
Figure 3.12: Script to start snmptrap daemon ...... 29
Table 3.1: snmp-cmds Python Library ...... 30
Table 3.2: SNMP manager modules ...... 34
Figure 3.13: Wireshark testing sequence ...... 37
Figure 3.14: snmpget request trace ...... 38
Figure 3.15: snmp get response trace ...... 38
Figure 3.16: SNMP connectivity troubleshooting sequence ...... 39
Figure 3.17 : Celery beat schedule ...... 40
Figure 3.18: Heartbeat implementation syntax ...... 41
Figure 3.19: Heart implementation syntax...... 42
Figure 3.20: Device update flowchart ...... 43
Figure 3.21 Performance instance Creation ...... 44
v
Figure 3.22: Performance data collection ...... 45
Figure 3.23: Performance data collection code ...... 46
Figure 3.24: Performance collection task for Celery ...... 46
Figure 3.25: Device information update flow chart ...... 47
Figure 3.26: device information update implementation ...... 48
Figure 3.27: Trap handling flowchart ...... 49
Figure 3.28 raw varbinds from SNMPTRAPD...... 50
Figure 3.29: Numeric format of trap dict after parsing ...... 50
Figure 3.30: Textual format of trap dict after parsing ...... 51
Figure 3.31: System architecture ...... 52
Figure 3.32: Network prototype ...... 53
Figure: 3.33: Network prototype photo ...... 54
Figure 4.1: Device Offiline Status Wireshark trace ...... 55
Figure 4.2: Device Online Status Wireshark trace ...... 56
Figure 4.3 Device Offline Status ...... 57
Figure 4.4 Device Online Status ...... 57
Figure 4.5 Device Linkup Status Wireshark trace ...... 58
Figure 4.6: Device Linkup status ...... 58
Figure 4.7 Device Link down Status Wireshark trace ...... 59
Figure 4.8: Device Linkdown status ...... 59
Figure 4.9: Interface status Wireshark trace ...... 60
Figure 4.10: List of interface status ...... 61
Figure 4.11: Inoctates request on Wireshark trace ...... 62
Figure 4.12: Inoctates response on Wireshark trace ...... 62
vi
Figure 4.13: Inoctates statistics ...... 63
Figure 4.14: Outoctates Statistics ...... 63
Figure 4.15: Performance utilization graphs ...... 64
Table 4.0: Percentage of port utilization ...... 65
Figure 4.16: Performance utilization statistics from the NMS ...... 65
Figure 4.17: Port utilization graph with 25% upper threshold...... 66
Figure 4.18: Network Insight and Analysis Summary ...... 67
Figure 4.19: Network Insight and Analysis Statistics per port ...... 67
vii
Table of Contents Abstract ...... ii Acknowledgements ...... iii Abbreviations ...... iv CHAPTER 1 ...... 1 1.0 INTRODUCTION ...... 1 1.1 BACKGROUND ...... 3 1.1.0 Communication Networks ...... 3 1.1.1 Network Monitoring Systems ...... 3 1.1.2 Data Collection ...... 4 1.1.3 Data Storage ...... 4 1.1.4 Display ...... 4 1.2 Aim ...... 5 1.3 Statement of the problem ...... 5 CHAPTER 2: LITERATURE REVIEW ...... 7 2.0 OVERVIEW ...... 7 2.1 RELATED WORK ...... 7 2.1.1 Cacti ...... 7 2.1.2 Nagios ...... 8 2.1.3 Icinga ...... 8 2.2 Data Collection ...... 9 2.2.1 SNMP ...... 9 2.2.2 SNMP Architecture ...... 10 2.2.3 SNMP Manager ...... 11 2.2.4 SNMP agent ...... 12 2.2.4 MIBs ...... 12 2.2.5 OID ...... 13 2.2.6 SNMP Security ...... 14 2.2.6 Common Management Information Protocol (CMIP) ...... 15 2.3 Data Storage ...... 16 2.3.1 RRD ...... 17 2.3.2 RDBMS ...... 17 2.4 DISPLAY SYSTEM ...... 18 CHAPTER 3: METHODOLOGY ...... 19 3.0 Overview ...... 19 3.1 Data collection layer ...... 20 3.1.1 Polling ...... 21 3.2 Implementation ...... 21 3.2.1 Net-SNMP Installation ...... 21 3.2.2 Configurations ...... 22 3.2.3 Testing the implementation of the Net-SNMP tool commands ...... 23 3.3 Snmp libraries ...... 29 3.3.1 Snmp-cmds Python Library ...... 29 3.3.2 snmp-cmds library installation ...... 30 3.3.3 snmp-cmds library implementation ...... 30 3.3.4 Testing the snmp-cmds implementation ...... 32 3.3.5 Snmp_manager module ...... 33 3.3.6 Testing using Wireshark ...... 35 3.3.7 SNMP configuration verification ...... 39 3.3.7 Polling configuration/scheduling ...... 40
viii
3.3.8 Heartbeat feature Implementation ...... 40 3.3.9 Device status update implementation ...... 43 3.3.10 Performance data collection implementation ...... 44 3.3.11 Interface configuration updates ...... 47 3.3.12 SNMP trap processing sequence ...... 48 3.3.13 Snmptrap handling module sequence ...... 50 3.4 System integration ...... 51 3.4.1 Network Prototype ...... 52 CHAPTER 4: RESULTS ANALYSIS AND DISCUSSION ...... 54 4.2 Device Online/Offline Status ...... 55 4.2.1 Device status from User Interface ...... 56 4.3 Link Status ...... 57 4.3.1 LinkUp Trap ...... 57 4.3.2 Link down Trap ...... 58 4.3.3 Linkup and Link down trap logs...... 59 4.4 Interface Requests ...... 60 4.5 Performance Collection ...... 61 4.5.1 Inoctates and Outoctates request ...... 61 4.6 Discussion ...... 66 CHAPTER 5: CONCLUSION AND RECOMMENDATIONS ...... 68 5.1 Conclusion ...... 68 5.2 Recommendations and Future Work ...... 69 REFERENCES ...... 70
ix
CHAPTER 1
1.0 INTRODUCTION
A network monitoring system (NMS) allows network technicians and engineers to monitor their networks remotely by detecting and reporting failures of Network Elements and their associated interconnection links.The ultimate goal is to maintain and optimize the availability of networks and thus a standard NMS is also expected to be proactive. Proactively identifying faults before they happen helps to reduce the resultant effects on network users and in some cases can also completely avert network failures and downtime.
Network monitoring/management addresses many fundamental issues required for the reliable operation of a network. The following elements as defined by the International Organization for Standardization (ISO) were used as a guide in this design project. The five elements are Fault management,Configuration management,Accounting, Performance management and Security management(FCAPS)(James Farmer et al,2017). Fault management: At this level, faults are detected and corrected. Necessary steps are implemented to prevent any envisaged future faults from happening. This element is vital to minimize/prevent downtime and provide some measure of fault tolerance in the network. Configuration management: Uploading network elements, collecting equipment and software inventory, keeping and updating the inventory regularly are all supported at this level. This is where the actual operation of the network is controlled and monitored. It also provides the key interface for activating and deactivation network services. Accounting management: The ability to check resource usage per every network segment helps to allot the costs of usage to appropriate users. Performance management: Performance monitoring of network key performance indicators
1
like network throughput, response time, unit availability is provided in the form of graphs or average figures.This data can then be used to ensure that all available resources are optimally allocated and the network performance remains above acceptable levels. Security management: An NMS can be used to provide one central point of network access managed by the network administrator to avoid unauthorized access. Networks must provide users with data integrity. It is, however, unusual to find monitoring systems on the market which address all of these components sufficiently - particularly when multi-vendor platforms are involved. Nonetheless, all are important for the reliable operation of a standard network.
Network monitoring can be accomplished utilizing numerous software or a combination of plug- and-play tools. It is possible to monitor almost any kind of network. It doesn't make a difference whether wired or wireless, LAN, WAN, VPN, or the traditional mobile/fixed telephone networks. A clear understanding of what to be monitored and the type of devices that make up a network to be monitored is important in designing monitoring tools. Information like device type, applications they run and on which operating systemis essential (Kim S. Nash and Alyson Behr, 2007).
The standard design of an NMS comprisesthree main layers which are the data collection layer, the data storage layer and the user interface (C.C.Li et al, 2016). This research focused on the data collection layer which was implemented using the SNMP protocol. The Simple Network Management Protocol (SNMP) is responsible for establishing a constant communication link between network monitoring tool and the monitored devices and also for data collection of all the objects needed by the NMS to know the status of network devices (Danijel Mijić, 2018). SNMP uses polling and SNMP traps as the two main techniques to provide insight into the monitored network (Virgil Dobrota, 2016).
The data collected using the SNMP protocol is not only used to address technical faults but is also archived for later analysis which can be used to make future business decisions.For example, archived data when properlyprocessed can show the rate of increase of network traffic and that information can be used to make critical decisions like allocation of budget for network expansion and upgrades. The archived data can also be used to reveal recurring faults
2 henceunreliablesegments of the network can be identified(Nidhishree, Manimala, and Engineering, 2017).
1.1 BACKGROUND
1.1.0 Communication Networks
Networks are composed of several devices(switches, routers, base transceiver stations, microwave, computers, servers, etc) interconnected together and capable ofcommunicating with each other. In this project, we are more interested in Internet Protocol (IP) networks. This is a network where every device is identified by a unique IP address and they all support TCP/IP suite (Rajesh Kumar et al, 2016). Nowadays even the traditional transmission technologies like Microwave which used to be purely SDH/PDH can now support TCP/IP. This research takes advantage of the introduction of such new technologies like IP microwave to broaden the application of the designed NMS. Networks vary in both size and importance and the bigger the network the more network monitoring becomes relevant. Even though smaller networks like Small Office Home Networks can be important to the owner,the related cost of an outage is insignificant compared to that of a big network like ISPs with devices distributed across the whole nation. Large networks especially service providers have service level agreements (SLAs) which spell out the cost per minute during an outage and hence every minute of uptime matters and any pronounced downtime can be very costly to the company. A reliable NMS is more important to these large networks because it will help to report faults as they happen and sometimes there are warnings even before a service outage.
1.1.1 Network Monitoring Systems
As networks grow large, it becomes difficult to manually check the status of every node and bandwidth utilization of links connecting them (C.C.Li et al, 2016). This makes the system an obscure entity where issues could be occurring whenever without any recognition by the system administrator. The need for an NMS, therefore, becomes inevitable to solve this problem.
3
AnNMS accomplishes this by storing an internal model of what a health network should be and utilizes this model to assess the present condition of the system. In doing so an NMS gives execution information on how well the system is used and answer questions concerning the system's financial aspects like whether the system is cost-effective and fulfilling need.
1.1.2 Data Collection
Network devices are usually scattered around different geographical locations. Network monitoring requires the collection of relevant data from different parts of the network which will be used to manage and control the network. There are two commonly used data collection management protocols which are SNMP and CMIP (Soraya Sinche et al, 2020). Both SNMP and CMIP give the premise for data collection in developing network monitoring applications but the contrasting methodologies influence how the applications are provided. CMIP explicitlystates a set of system monitoring functions based on managed objects, while SNMPfunctions are defined in extensions to the MIB on an “as-needed” basis. These vendor-specific extensions often cause discrepancies and challenges with interworking.
1.1.3 Data Storage
All the data collected should be archived for processing. Databases can be classified into two categories, the Round Robin databases (RRD) and the Relational database management systems (RDBMS). These days storage (both hard drive and cloud) is now affordable and therefore RRDs are no longer that relevant. Round Robin databases are of fixed size and cannot be expanded (Tobias Oetiker,2019) which makes it impossible to store data for future analysis. MySQL, SQL Server, and SQLite are all examples of Rational databases using Structured Query Language for interaction with the storage tables.
1.1.4 Display
Alarms, warnings, and any other processed data should be displayed in the form understandable not only by the developer but an end-user including non-technical personnel. Information can be
4 displayed in the form of graphs, dashboards or just simple SMS or email notification. Time- series graphs are used mainly when the objective is to identify trends and anomalies of performance data. For example, bandwidth usage on device interfaces can be graphed to show how close the link is to run at full capacity. Event systems use the SMS or email notifications to notify the administrator of a change in the network (either good or bad)for example when a node becomes unreachable. Notifications can inform you of a network change but will not give a detail concerning the cause of the event. This means that notifications alone are not enough to give the full picture of a problem and can only work as a supplement to a standard display system like a dashboard. A dashboard provides visual displays of data on a monitor screen in such a way that all the information canbe summarized and monitored at a glance (Alper Sarikaya et al, 2019).
1.2Aim
The aim of this research project is to design and implementation ofan SNMP based data collector that will aid in the design of a multi-vendor network monitoring system. 1.3 Statement of the problem
A survey with the four major network operators in Zimbabwe (Telone, Netone, Econet and Telecel) shows that their NMSs are vendor-specific and they come with per network element (NE) license. The suppliers are foreign and all licenses are paid in foreign currency which is currently very scarce in Zimbabwe. The NMSs being unique and having a specific area of specialty aligned to one vendor forces the company to have the latest and recent tools across the various products under observation adding measurable cost and administrative time. The major drawback of this is that there is a need to provide learning facilities for the engineers, managers and operators for training as to grasp concepts on how to navigate the various user interfaces. The various trainings raise learning curves but suppress the ability to specialize in any individual tool. Since each tool has its own data library, this implies that the sharing of data is manual thereby exposing the system to errors and mistakes by operators. Different vendor experts also need to be consulted for serious faults adding more costs. Generally having more tools creates
5 more overheads and expenses hence company expenditure grows resulting in low returns of investments from outside. Only a homemade solution that will incorporate all the different vendors will provide an alternative and viable solution for network monitoring.
6
CHAPTER 2: LITERATURE REVIEW
2.0 OVERVIEW
This chapter reviews the past developments in Network monitoring systems including the different standard protocols and programming libraries used. NMSs have existed in several forms since the introduction of networks. Many systems were developed to date including Zabbix,Prometheus,Pandora, FMS,NetXMS,Nagios, LibreNMS,Icinga,Cacti, and several other academic journals. This project will explore only the relevant systems which seek to address similar challenges as stated inthe research aim.
2.1 RELATED WORK
2.1.1 Cacti
Ian Berry (2001) started a web-based network monitoring and a graphing tool called Cacti. Cacti utilizes the RRDTool's data storage and graphing functionality (Martin Phiri et al, 2016). Old files are frequently deleted in the RRD storage (the “.rrd” file) creating space for new records and therefore accurate graphs can only be obtained from recently captured data (Ian Berry et al, 2017). Mean value approximations are used to construct figures for very old data. The front end of Cacti is web-based without any method for bulk configurations. The best scenario to use the Cacti tool is to use it to supplement or in conjunction with another monitoring tool to provide historical graphs while the other tool will provide event detection and notifications systems. The graphs may help to give an insight as to why an event might have been triggered in another monitoring system and the two systems can complement each other. Of much interest to our project is how the Cacti used the SNMP protocol to collect data from the monitored devices. This project will use the similar techniques on the data collection layer.
7
2.1.2 Nagios
Ethan Galstad (1996) introduced Nagios to monitor the Novell Netware servers through a simple ping MS-DOS application which employs mainly the ping application to detect the UP or DOWN status of the servers. The tool was later developed to support monitor network applications, utilities, and servers (Wojciech Kocjan et al,2016). The simple plugin design in Nagios allows many programmers and users to actively support its development. One of the major developments made in Nagios is the ability to send email and SMS notifications when one of the monitored network services or resource reports an abnormality status. According to Wolfgang Barth (2009), Nagios can be configured to monitor network services such as POP3, SMTP, SSH, NNTP, and HTTP in addition to the following host resources: hard drive and RAM usage, system logs and processor usage. It can also monitor environmental factors, like humidity and temperature. As highlighted Nagios can monitor manynetwork services as expected from a standard monitoring system but it has failed to catch up with the fast-expanding IT infrastructure in different network operators. The major challenges of Nagios arise when one tries to monitor many technologies from different vendors from one master location. To monitor more technologies with Nagios, one has to implement multiple disconnected instances covering different groups of infrastructure. This approach is tiresome and will make fault identification very difficult.
2.1.3Icinga
In 2009 a group of developers created a fork of Nagios Network monitoring system and called it Icinga in a bid to correct the perceived shortcomings in Nagios (Viranch Mehta, 2013). Whilst Icinga remained compatible with external Plug-ins of Nagios, many feature improvements were done including a more modern and configurable web interface, the REST API that helps integration developers to add extensions without many complex changes on the Icinga core and the extra database connectors for Oracle and MySQL. The monitoring system was designed mainly for report generation, event notifications and checking service status. Polling is done using prepackaged check threshold or users can create their thresholds according to the severity (normal, warning and critical) (Peter Mwape Mfupa, 2017). Tolerance levels for different
8 equipment infrastructure can be different and therefore for new nodes, setting threshold checkpoints can be guessing game until you have established some baseline. Data collection from the monitored device in Icinga is controlled by the configured check script and therefore different protocols can be used to collect the data. The commonly used protocol is SNMP mainly because the Nagios-plugins package for Nagios and Icinga also uses SNMP. Data in Icinga is stored in plain-text log files and parsed every time the system needs to access historical data. There are extensions to Nagios and Icinga thatcan store this data in a Structured Query Language (SQL) database instead of plain-text files, producing faster query times. The fact that many functionalities can be achieved by the use of add-ons, it implies that Icinga can only be used by experts who are flexible to define their specific needs and know how to incorporate the add-ons to achieve their desired results. Being an open-source it doesn‟t have much developer support making it very difficult to use.
2.2Data Collection
At the core of every network monitoring system is the ability of monitoring tools to communicate with monitored devices and collect the necessary data for manipulation. Many data collection protocols can be used including SNMP, CMIP, JMX, JDBC, NSClient, WMI, XML, and XMP. This paper will look at the commonly used SNMP and CMIP protocols as defined by the ISO/OSI network management model. The two protocols are not vendor proprietary and therefore ideal for our multi-vendor monitoring system scenario.
2.2.1SNMP
Simple Network Management Protocol is an application layer protocol based on the TCP/IP protocol suite, which offers network management services for monitoring and control of network devices,(Jithesh Sathyan,2016). The protocol was defined and standardized by IETF RFC 1157 in May of 1990. SNMP is used for remote monitoring of SNMP-enabled devices and it enables remote users to view and modify management information of the network elements. SNMP architecture is made up of SNMP managers and SNMP agents. On the TCP/IP protocol suite, SNMP resides in the application layer and runs on top of the User Datagram Protocol (UDP). It
9 uses UDP as the transport protocol for passing data between managers and agents (Boyko A, 2019).Although UDP is connectionless and therefore unreliable, it was chosen over TCP because it has lower overheads hence most ideal for congested and managed networks. Of course, SNMP can be used with TCP but only for special cases when developing an agent for highly sensitive applications. Figure 1.0 below shows the TCP/IP protocol suite
Figure 1.0: TCP/IP protocol suite
2.2.2 SNMP Architecture
The SNMP architecture comprises three main elements, theSNMP manager, the SNMP agent and the MIB.
10
Figure 1.1: SNMP Architecture
Figure 1.1 above shows the SNMP Architecture (Otávio Alcântara et al, 2014).
2.2.3 SNMP Manager
SNMP Manager is a software program that uses a set of messages (commands) through the SNMP protocol to collect data and send instructions to managed devices (SNMP agent). In brief, this is exactly where the monitoring solution sits. It acts as the interface between the user and the managed network elements. The SNMP manager‟s keys functions are to poll SNMP agents, get a response from the agents, and set variables for the agents as defined in their local MIBs. The following commands are utilized by the SNMP manager to get information from the agents (Hongliang Li, 2019).
GET – Sent by the SNMP manager to retrieve a value of a variable from the MIB RESPONSE – Sent by the SNMP agent as a response to the SNMP manager replying to a GET request and it provides the variables which were requested originally by the manager
11
GETNEXT – Sent by the SNMP manager to the agent to retrieve data from the next OID within the MIB tree. GETBULK – The SNMP agent uses the GETBULK message to pull tables of data by using lots of different GETNEXT commands. SET – SET is a message sent by the SNMP manager to the agent to change configurations and issue commands. TRAP – An alert sent by the SNMP agent to notify the SNMP Manager when an event happens within the device.
2.2.4SNMP agent
SNMP agent is a program that resides in the actual device being monitored and it is run as a daemon process by the device. The agent works in two ways: one by responding to polls from the SNMP manager and provide the requested variable known as the Object Identifiers (OIDs).It can also send SNMP traps to tell the monitoring system that something abnormal (an event) has happened without necessarily waiting to just respond to request from the manager. In summary, the key functions of an SNMP agent are to collect management information about its local environment, store the information in the MIB and retrieve it whenever a request is sent by the manager, share SNMP traps with the manager to signal an event or fault and to act as a proxy for network devices which do not support SNMP. (Vyshak Srivatsa Raghavendra, 2016)
2.2.4MIBs
Management Information Base is a set of objects to be managed (management variables), and it defines a series of attributes of managed objects including Object Identifiers, access permission and data type of object. Every monitored resource is represented by one or more objects and MIB is a database or structured collection of such objects. SMI (Structure of Management Information) stipulates how to organize and defines the managed objects as detailed in IETF RFC 1155 (SMIv1) and RFC 2578 (SMIv2). MIBs are saved as a tree structure as shown below. The nodes of the tree represent the managed target, and they can be identified by a path from the root OID (Vyshak Srivatsa Raghavendra 2016)
12
Figure 1.2: MIB structure
2.2.5OID
Object Identifier can be defined as the unit of management Information base (MIB). OID values vary from text to numbers and counters and they are laid out in treelike hierarchy which forms the basis of SNMP‟s naming scheme. OIDs are formatted in a string of numbers separated by dots as shown below(Young-Il Kim et al 2016). .1.3.6.1.4.1.789.1.6.4.8.0 There is also an associated human-readable form (textual name) for each numerical value which is friendlier .iso.org.dod.internet.private.enterprises.netapp.netapp1.raid.diskSummary.diskSpareCount.0 All the standard OIDs begin with .iso.org.dod.internet.private or .1.3.6.1.4.in numerical form, followed by enterprises (.1) and the unique number for the vendor as assigned by the Internet Assigned Numbers Authority (IANA) thus OID 789 in the example above. Vendors have total control of everything else that follows after the vendor ID according to their design solutions. The dot prefixed before the number represents the root similar to the DNS naming.
13
2.2.6SNMP Security
SNMPV1 and SNMPV2 use community strings to realize safety management. A community defines the relationship between the SNMP manager and agent. Each community is identified by a community name which is just like a password related to permissions. These permissions are read-only, read-write and trap. The read-only community name allows the user to read data values from the agent but prohibits any data modifications, whilst the read-write allows the user to read and modify data values. For instance, if an agent is configured with the read-write community string, the user can read the number of packets passing through a router interface and can also reset the interface. The trap community string allows the agent to send event notifications to the manager and therefore trap host should be specified in the SNMP trap configuration (usually the NMS IP address). The actual configuration syntax for community strings depends on different vendors but in many cases manufacturers release their equipment with default values, typically public for the read- only and private for the read-write community string. The only challenge with the use of community strings for authentication is that they are sent in plain text, thus making prone to interception by intruders who may gain access to the network and cause malicious damage. Although both SNMPv1 and SNMPv2 uses community strings, SNMPv2 comes with improved security as defined in different RFCs (RFC 1441 - 1452) in 1993 (Boyko A 2019). SNMPv2c also uses the same community strings the same way as in version 1 and the c is for Community- Based Security Model. The only difference is that it supports 64-bit counters and other commands like the inform command thereby expanding the protocol capabilities. There is also the Party-Based Security (Model SNMPv2p) which is more secure than version 1. The “Party” is just a logical entity defined by the sender and receiver as an agreement on how to encrypt and decrypt data. It specifies an encryption and authentication protocol and therefore used to verify if a particular request is authentic. SNMPv2p became the basis for the models that ensued and was not accepted as a standard on its own. It was considered complex and confusing. The User-Based Security Model (SNMPv2u) was also developed for SNMPv2 although, in the end, it became part of the SNMPv3. The core objective of the developers of the user-based security model was to come up with a classical concept that does not utilize security bindings on machines and rather control access rights of different „users‟ of the machine. The access rights of
14 users are then enforced by the use of different authentication and encryption protocols (Boyko A 2019). SNMPv3 by default uses the USM (User-Based Security Model) discussed above. However it supports a variety of security models, and it is up to the administrators to choose what best suits their scenario.SNMPv3 resolved most of the security challenges raised in previous versions although not yet ideal. SNMP messages can now be encrypted in version 3 and there are three security levels as given below (M. Alkasassbeh 2016). - noAuthNoPriv – There is no user authentication and no data encryption, just a username string-match is used to authorize SNMP request.
- authNoPriv – This security level offers password authentication which can be implemented using the MD5 or the SHA hashauthentication but still no encryption of data transmitted between agent and manager.
- authPriv- Provides the maximum level of security, authentication is hash-based as in level 2, and agent to server communication is also encrypted.
2.2.6 Common Management Information Protocol (CMIP)
Common Management Information Protocol (CMIP) is an OSI-based management protocol. It facilitates the implementation of services defined by the Common Management Information Service (CMIS)(Soraya Sinche et al, 2020). The CMSI is, in fact, a CMIP built-in service responsible for specifying basic services needed to perform management various functions like establishing communication between management application and managed agent, retrieving attribute values of managed objects and permitting the setting of managed agent attribute values. It also uses the Remote Operations Service Element (ROSE) to send and receives Protocol Data Units (PDUs).
The CMIP design is relatively similar to SNMP, both protocols use PDUs as variables for network monitoring. The major difference is that the SNMP protocol consists of only 5 distinct PDU types whilst the CMIP protocol consists of 11 that contain sophisticated data structures with the following three attributes:
• Variable attributes: variables can be the data type (int, string, etc)
15
• Variable behavior: Looks into possible actions that can betriggered on available variables. • Notifications: report generation by the variable when an event occurs.
SNMP only employs one out of the 3 attributes above (event notification). Too many attributes make CMIP architecture very complex. CMIP provides a complete network management protocol environment to aid communication with any network device in the same way OSI network protocols provide common network architecture for all devices on each layer of the ISO reference model (Abhishek Sinha et al, 2015) Network Management Protocols and Tools Study.
CMIP is based on a client/server model where the application/managing system is the client and the monitored system the server. Information from a large number of agents can be managed and processed by the protocol before they pass it back to the management system. Moreover, the object-orientation also allows sharing and grouping resources in specific classes and subclasses. Inheritance and relationships between specifications of classes make it an efficient management system.
The introduction of CMIP was to fix some of the shortcomings with SNMP like security because of the provisions for authentication(Soraya Sinche et al, 2020). However, SNMP has since addressed the security issue in SNMP version 3. The largest advantage of SNMP over CMIP is that its design is easy and simple, therefore it is easy to implement on bothsmall and large networks because it is easy to set up and there is no much stress on system resources. Furthermore, the simple design makes it convenient for the user to set system variables that they wish to monitor. SNMP was the first protocol to be designed in the absence of any other protocols thus making it very popular and owing to this it became a built-in protocol supported by most popular vendors of networking hardware hence almost every device on the network is guaranteed to be able to be monitored using SNMP.
2.3 Data Storage
A database provides the central storage of the monitoringdata needed for the profiles and protocol suites used. The type of data for network monitoring systems can be classified as time series data and can be stored in both Round Robin databases (RRD) or the Relational database
16 management systems (RDBMS). This paper will only look at RRD, MySQL and SQLite which are more relevant to our application.
2.3.1 RRD
Round Robin Database was introduced in 1999, as a faster and more configurable successor for Multi RouterTraffic Graphed (MRTG) which was the standard then (Tobias Oetiker, 2019). It allows storage of time series data like temperature and bandwidth with a constant disk footprint.Data captured is stored in a fixed size database and this is achievedby storing only a fixed numberof entries in a Round-Robin Archive. One RRD is typically configured to have several Round Robin Archives and data values can be aggregated from second intervals up to summaries for years. Configuration for an RRD cannot be changed without creating a new one, for example, it is not possible to change the time interval for capturing data once it is set. This means that RRDs have a scalability issue when applied to network monitoring systems because monitoring systems are expected to adapt to any network expansions as the monitored networks grow. It is also clear that Round Robin databases are more ideal for storage constrained scenarios because they have a fixed size that cannot be changed. Nowadays storage is no longer as expensive and therefore alternative databases like MySQL, SQL Server, and SQLite which allow storage of historical data for future analysis can be used instead. Data is updated only at configured regular intervals, say every 10 minutes and there is no way of backfilling any updates happening in between. Any data that arrives in between will be stored as interpolated values instead of the raw data. It is possible to have data coming at irregular intervals due to network delays. Data consistency and accuracy can therefore not be guaranteed which makes it difficult to use this data to make important decisions for the network. (Tobias Oetiker, 2019).
2.3.2 RDBMS
MySQL, SQL Server and SQLite are all examples of RDBMS. Instead of storing data in a single huge storeroom, rational databases allow storage of data in tables and interaction with these
17 tables is facilitated by the use of a very powerful language called Structured Query Language. SQL is a standard language used to access and analyze the stored data. Indexes also known as foreign keys are used to link data from different tables and also allows unique identification of the smallest units of data within a table. There is so much flexibility in using RDBMS including the ability to split databases. The database can be split into two parts, the memory for the most recent data that need to be accessed fast and frequently and hard disk for archive data which does not require frequent access. MySQL is an open-source rational database that can be downloaded from the internet and used by anyone for free although they are commercially licensed versions available. It is also possible for individuals to modify and use the software to suit their application. The selection of the most appropriate RDBMS to use depends on the application and for an academic project SQLite can be used because it is not complicated to setup. SQLite can store a complete database in one file and therefore the data can be stored locally without the need to connect the database to a separate server. SQL Server is owned by Microsoft and just Like Oracle DB, the code is not open source but rather close sourced. Although large enterprises use it in most cases, it can be a bit complicated and expensive to use ona small scale. There is an entry-level version for free (Express version) but can become very expensive as you scale your application (Mohammad Yaqub, 2015).
2.4 DISPLAY SYSTEM
After data collection, manipulation and storage which forms the back end of the NMNs project, there is a need to design the front end for the actual interaction of users with the system. The display unit is an important part of an NMS because it summarizes all the events as identified by the system and put them on a single screen in a human-readable format. To make it more clear a display can have graphics, colors and sound to help administrators to timeously notice any faults in the network
18
CHAPTER 3: METHODOLOGY
3.0 Overview
This chapter gives insight into the methods used in the development of the monitoring system. Different modules, components and libraries used for collecting and processing the network information data are also highlighted and explained.The NMS was designed to support IPSNMP capable devices. The design was separated into three major layers namely the Data collection, Data storage and Display/Dashboard. This research is focused mainly on the methods used for data collection.
19
3.1 Data collection layer
The data collection layer was implemented using the Net-SNMP. Net-SNMP is a set of tools and libraries used to implement SNMP protocol. As highlighted in chapter 2, SNMP uses Object Identifiers (OIDs) to get information from the SNMP agents. Usually, SNMP capable devices come with a database of all the Object identifiers called the Management Information Base (MIB). OID information is not always available to developers and some equipment vendors will never provide them to individuals. Net-SNMP comes with one application called snmpwalk which can be used to interrogate the device agent and ask for all OID values that it can supply. This design first used the snmpwalk to learn more about OIDs from different manufacturers. The output of snmpwalk was used to get the exact data reported by the device and to make decisions on how to tackle it in the main code. To initiate communication between SNMP manager and the agent there is need to login different network devices and enable the SNMP agent which usually resides in many IP network devices by default. An IP address and mask are also required to identify and distinguish between network nodes. Permission rights are also configured as a measure of safety management and these depend on the SNMP version used. This design was done using SNMPv2 which uses community strings to control the read or write rights.
There are 2 main techniques used to collect data from Network elements which are polling and SNMP traps.
20
Figure 3.0: SNMP data acquisition techniques
3.1.1 Polling
Polling is executed by writing an application that sets an SNMP GET request (poll) to an SNMP agent in order to retrieve Object identifier (OID) values which can be used to confirm the actual status of monitored devices or parameters.Polling is initiated by the SNMP manager and therefore called active monitoring. If there is no polling response from the device it means there is a problem in the network. In this project, polling was used for continuous monitoring of already discovered devices known as the heartbeat polling in this design. It is important to continuously check whether the discovered Network elements are still alive and connected.
3.2 Implementation
3.2.1 Net-SNMP Installation
21
Net-snmp sources “net-snmp-5.6.1.tar.gz” was downloaded from the official website (https://sourceforge.net/projects/net-snmp/files/net-snmp/5.8/) as a compressed file. The file was extracted using the tar commands into a folder Net-SNMP. The Net-SNMP tool requires the installation of libperl-dev tool as a dependency that was installed from the Ubuntu repositories, the commands are listed later for reference.
...download latest net-snmp sources: $wget
...extract sources: $tar -xvzf net-snmp-5.6.1.tar.gz
...install ubuntu dependencies: $ sudo apt-get install libperl-dev
...configuring and installing: $ ./configure
...complile the source $make
...install the net-snmp package into your ubuntu system $ sudo make install
...For the net-snmp applications to work we need to add an export command to our ".bashrc" file: $ echo export LD_LIBRARY_PATH=/usr/local/lib >> .bashrc
... verify installation
$snmpget –version NET-SNMP version: 5.6 Figure 3.1: Net-SNMP installation procedure Figure 3.1 below depicts the steps how the Net-SNMP tool was installed.
3.2.2 Configurations
The Net-SNMP tool requires specific configurations to match application implementation. The system-wide configuration file is stored on the path /etc/snmp/snmp.conf, this is a common file and contains the SNMP configuration for all the users on the system. The main configuration
# As the snmp packages come without MIB files due to license reasons, loading # of MIBs is disabled by default. If you added the MIBs you can reenable 22 # loading them by commenting out the following line. mibs : concerns the loading of MIB files. The configurations done for this project is shown in the snippet below.
Figure 3.2: Net-SNMP installation procedure The snmp.conf file contains the configurations for: Client behaviour SNMPv2 settings Server behaviour output generations MIB directory setting
Dependencies The Net-SNMP tool depends on the installation of the tool libperl-dev as illustrated in figure 3.1.
3.2.3 Testing the implementation of the Net-SNMP tool commands
The SNMP-tool contains the commands snmpbulkget, snmpbulkwalk, snmpdelta, snmpget, snmpgetnext, snmpnetstat, snmpset, snmpwalk which are used to carry out SNMP protocol probes to agents. In this exercise, we carried out low-level tests for the implementation of each command. This was necessary to verify the installation condition of the Net-SNMP tool and the functional state of our test SNMP agent. The test SNMP agent used in our tests was a virtual router using the GNS3 software.
Test Agent 192.168.1.2 Vendor Cisco Environment Ubuntu Community string public
Table3.0: Test snmp agent details
SNMPTRANSLATE
SNMPTRANSLATE is used to convert SNMP MIB OID between text format and the numeric format. The insert below shows the basic test of the command use. Command syntax: snmptranslate [OPTIONS] OID [OID].
23
Figure 3.3: snmptranslate example
SNMPGET
SNMPGET is an application used to send SNMP GET requests to SNMP agents. Command Syntax: snmpget [COMMON OPTIONS] [-Cf] OID [OID]...
Figure 3.4: snmpget example
SNMPGETNEXT
SNMPGETNEXT is an application used to execute the snmpgetnext request on the SNMP agent. The command takes OIDs as an argument. The application returns the next value to the one sent in the request. The test was executed as bellow Command syntax: snmpgetnext [COMMON OPTIONS] [-Cf] OID [OID]...
Figure 3.5: snmpgetnext example
SNMPBULKGET
SNMPBULKGET is an application that uses the SNMP GETBULK request to entity efficiently for information. Command syntax: snmpbulkget [APPLICATION OPTIONS] [COMMON OPTIONS] OID [OID]...
24
Figure 3.6: snmpbulkget example
SNMPSTATUS
SNMPSTATUS is an application used to query common properties of an agent such as system uptime, IP address or hostname. The example test carried is as shown in illustration bellow
Figure 3.7: snmpstatus example
SNMPSET Testing of the snmpset application used to set an OID variable of an SNMP agent. The snippet below shows the testing of the senmpset command used on our test anmp agent.
Figure 3.8: snmpset example
SNMPTRAPD This section looks into how the snmptrapd daemon was configured. The SNMPTRAPD daemon was configured using the snmptrapd.conf file. The location of the snmptrapd.conf file is
25
/etc/snmp/snmptrapd.conf
Snmptrapd configuration The configuration of the snpmtrapd is shown in Figure 3.9 below. The snmptrapd application was configured with two traphandlers to handle linkup (.1.3.6.1.6.3.1.1.5.4) and linkdown (.1.3.6.1.6.3.1.1.5.3) traps from agents. Authorization was disabled to smoothen the trap handling process as vendors had a different implementation.
26
# # EXAMPLE-trap.conf: # An example configuration file for configuring the Net-SNMP snmptrapd agent. # ###################################################################### ######### # # This file is intended to only be an example. # When the snmptrapd agent starts up, this is where it will look for it. # # All lines beginning with a '#' are comments and are intended for you # to read. All other lines are configuration commands for the agent.
# # PLEASE: read the snmptrapd.conf(5) manual page as well! # #authCommunity log,execute,net private #authCommunity log,execute,net public # ## send mail when get any events #traphandle default /usr/bin/traptoemail -s smtp.example.org [email protected] # ## send mail when get linkDown #traphandle .1.3.6.1.6.3.1.1.5.3 /usr/bin/traptoemail -s smtp.example.org [email protected] disableAuthorization yes #traphandle .1.3.6.1.6.3.1.1.5.3 /home/Taka/script.sh #linkDown traphandle traphandle .1.3.6.1.6.3.1.1.5.3 ~/Projects/GOODBUY/NMS/scripts/snmptrapd.py #linkup traphandle traphandle .1.3.6.1.6.3.1.1.5.4 ~/Projects/GOODBUY/NMS/scripts/snmptrapd.py
Figure 3.9: snmptrap.config Traphandlers The traphandlers were configured to send trap information to a custom script called the snmptrapd.py. The snmptrapd.py contains python code to parse and process received traps. The snmptrapd.py is used to accept trap varbinds return a python dict which will be used by
27 the NMS to store the trap in the database.
#!/usr/bin/env python3 from __future__ import absolute_import, unicode_literals import os from celery import Celery import sys import fnmatch import datetime
app = Celery('snmptrapd', broker='redis://localhost:6379/0')
def varbind_parser(): lines = sys.stdin.readlines() linecount = len(lines) i = 2 # skipp the host and ip entries varbinds = dict() while i <= linecount-1: line = (lines[i].split()) varbinds[line[0]] = line[1] i=i+1
time = datetime.datetime.now() # get current time varbinds['time'] = time.__str__() # add time to varbinds varbinds['IPADDRESS'] = lines[1] # assign ip address return varbinds
def retrieve_key(dictionary,key): keys = list(dictionary) key = key + '*' for k in keys: if fnmatch.fnmatch(k,key): return k
def listint(host): #function to list interfaces
app.send_task('uNMS.tasks.listInterfaces', (host,)) Figure 3.10: snmptrapd.py Theif traps__name__ are filtered == based"__main__" on OID and: host IP address to identify the exact method to invoke in
data = varbind_parser() # receive varbinds from snmptrad daemon 28 app.send_task('uNMS.tasks.savetrap',(data,)) # create a task to save the trap received the NMS application. Figure 3.10 show the snmptrapd.py file
Starting snmptrapd
The snmptrapd application needs to be started in order to start receiving SNMP traps from the snmp agents. The daemon is started by the script shown in figure 3.12 below. Starting of the snmptrapd specified the format of logging snmptraps, the logfile snmp.txt. The -a option was configured to ignore authenticationFailure messages. The -A option was set to append output to the logfile instead of truncating. The -Lf option was set to configure the logfile output. The -F
startsnmptrapd(){
sudo snmptrapd -a -A -Lf snmp.txt -F "%#02.2h:%#02.2j TRAP: %W %v from %A\n"
if [ $? -eq 0 ]; then echo OK else echo FAIL optionfi was the formatting of the output of the traps into the logfile. In the script, no MIB file was } specified.
Figure 3.12: Script to start snmptrap daemon
Importing MIB files Net-snmp supports the importing of MIB files for use with applications. MIB files are stored in locations that are preregistered in the Net-SNMP tool. Custom MIB file locations could be specified in the snmp.conf file as part of the configuration. In our implementation the default location of MIB files /usr/share/snmp/ was used. All MIB files were uploaded into this folder.
3.3 Snmp libraries
3.3.1 Snmp-cmds Python Library
The application was integrated using a python library called snmp_cmds. The library wraps common Net-SNMP commands and creates a simple API to integrate in python applications. The
29 table below shows the list of snmp_cmds methods used in our application to carry out SNMP requests to agents.
Method Net-SNMP equivalent Description session.get() SNMPGET SNMP GET request to an agent session.get() SNMPGET SNMP GET to request a list of OIDs to an agent session.get_table() SNMPBULKGET SNMP GETBULK request to an SNMP agent
Table 3.1: snmp-cmds Python Library
3.3.2 snmp-cmds library installation
Prerequisites Net-SNMP should be installed as shown in the Net-SNMP installation section Python 3.5+ should be installed IETF RFC MIBs should be preloaded in the Ubuntu OS. The library was installed using pip as in the command below. Pip3 install snmp-cmds
3.3.3 snmp-cmds library implementation
The snmp-cmds API was used to carry out all the SNMP GET, GETTABLE and GETBULK requests in our application. An instance of the Session class from the snmp-cmds API was used to for the requests. The Session instance was instantiated with the SNMP agent‟s IP address, read/write community strings as required arguments. Each request was executed from the snmp- cmds.Session instance. The image below shows the instantiation of snmp-cmds.Session in our application.
30
The snmp-cmds.Session API provides methods: get, get_some, get_table, walk, set. In our application we used the get, get_some and get_table methods only. No SNMP SET methods where required during our implementation.
Session.get implementation The get method of the API was used for the basic SNMP GET commands in our application. A custom wrapper class was created to implement the API. The implementation below shows the get method used inside a custom get method. The method requires one argument, the argument is an OID in either textual format or numeric format.
The snippet below shows the example of the implementation of the wrapper function in
SysobjectID = self.device_session.get(oid='1.3.6.1.2.1.1.2.0') # get SysobjectID collecting the system details of an agent. Session.get_some implementation The get_some method of the API was used for the basic SNMP GET commands in our application but with multiple OIDs as arguments. A custom wrapper class was created to implement the API. The implementation below shows the get_some method being used inside a custom get_some method in our wrapper class. The method requires one or more OID‟s as arguments in either textual format or numeric format.
31
Session.get_table implementation The get_table method of the API was used for the basic Net-SNMP gettable application. A custom wrapper class was created to implement the API. The implementation below show the get_table method being used inside a custom get_table method in our wrapper class. The method requires an OID‟s as arguments in either textual format or numeric format.
get_table method was used in our application for the collection of the list of interfaces. The code snippet is shown in the image below.
3.3.4 Testing the snmp-cmds implementation
During the development of our application, python unit tests were created to test the implementation of the snmp-cmds API. Each feature had unit tests before integration into the application. Unit test setup
32
The unit test for snmp-cmds required a basic set up before calling the methods. The prerequisite configurations include the definition of the agent IP address, read/write community strings.
def setUp(self): self.HOST = '192.168.1.2' # setup the agent IP address
# configure SNMP details self.deviceobj = DeviceObject(host=self.HOST) self.deviceobj.setSNMPdetails(rcommunity='public', wcommunity='public')
3.3.5 Snmp_manager module
The snmp_manager module was designed as the low-level data collection implementation. The wrapper class implemented the snmp_cmds methods. The table below lists the methods that were defined in the module. It is from this module where all the SNMP requests were made.
Method Description get(oid='SNMPv2-MIB::sysObjectID.0') Request the system information of an SNMP agent get(oid='.1.3.6.1.4.1.9.9.109.1.1.1.1.5.1') Collect CPU utilization get(oid='.1.3.6.1.4.1.9.9.48.1.1.1.6.1') Collect Memory utilization get_interface_out_octets(1) Request interface outbound octets total_interfaces Request total interfaces on an agent get_enterprise_id() Request the SNMP agent enterprise ID list_interfaces() Request the interfaces of an SNMP agent get_interface(self, index) Request the interface attributes of an SNMP agent, the argument is the ifIndex get_product_id(self) Request the enterprise product ID of the SNMP agent get_admin_status(self, index) Request the admin status of an interface, the method takes the ifIndex as an argument get_interface_inbound_unicast_packets(self,index) Request the inbound unicast packets of an interface. get_interface_out_octets(self, Index) Request outbound octets for an interface systemname(self) Request the system name of an SNMP agent.
33
Table 3.2: SNMP manager modules
Snmp_manager module SNMP requests implementation
In this section we demonstrate how the module was implemented to achieve the various task in our application. The module is instantiated using the IP address of the target SNMP agent as the argument for the constructor. In the illustrations used the variables “host” or “self.HOST” are the IP address of the target SNMP agent. get_admin_status method Request the admin status of an interface, the method takes the ifIndex as an argument
device = Manager(self.HOST)
adminstatus = device.get_admin_status(1)# the argument is the interface index
get_interface method Request the interface attributes of an SNMP agent, the argument is the ifIndex .
device = Manager(self.HOST)
interface = device.get_interface(1)
get_product_id method Request the enterprise product ID of the SNMP agent
device = Manager(self.HOST)
product_id = device.get_product_id (1)
systemname method Request the system name of an SNMP agent.
device = Manager(self.HOST)
name = device.systemname
34 list_interfaces method
device = Manager(self.HOST)
interfaces = device.list_interfaces()
Request the interfaces of an SNMP agent as a list. The method returns an iterable list of interfaces. get_interface_out_octets method Request interface outbound octets device = Manager(self.HOST) value = device.get_interface_out_octets(1) # the argument is the interface index
get_interface_inbound_unicast_packets method Request the inbound unicast packets of an interface. device = Manager(self.HOST) inbound_packets = device.get_interface_inbound_unicast_packets(2) # the argument is the interface index
get_interface_out_octets method Request outbound octets for an interface
device = Manager(self.HOST) outbound_octates = device.get_interface_out_octets (2) # the argument is the interface index
get_interface_inbound_utilisation method Request the interface inbound utilization value
device = Manager(self.HOST) inbound_packets = device.get_interface_inbound_utilisation(10001) # the argument is the interface index
3.3.6 Testing using Wireshark
Protocol level testing was done using the Wireshark tool. The tool was used to check the contents
35 of the SNMP requests, responses and received traps. From Wireshark traces, we were able to analyze the varbinds received for each OID and establish how to process the data in our application. The tool was critical in the early stages of our development by confirming if we were successfully sending and receiving the correct OIDs and formats, also assisting in verifying the communication status between the agent and our manager server.
Testing sequence The flowchart below shows the testing sequence using Wireshark.
36
Figure 3.13: Wireshark testing sequence
Wireshark traces Below are captured traces using Wireshark for a few requests and responses.
37
Figure 3.14: snmpget request trace
Figure 3.15: snmp get response trace
38
3.3.7 SNMP configuration verification
Basic SNMP configuration verifications were carried out to confirm SNMP connectivity between the test agent and the manger. This was to assist in verify SNMP credentials configurations on the SNMP agent and TCP/IP connectivity.
The factors affecting SNMP connectivity could be any of the following: • Incorrect IP configuration between the manager and the agent. Basic ICMP echo tests would be sufficient to assess the connectivity • Faulty or no physical connection. Basic ICMP echo tests and interface alarms would be sufficient to assess the connectivity. • Incorrect SNMP credentials on the manager. • Missing SNMP configurations on the agent The following flow chart depicts the SNMP connectivity troubleshooting sequence
Figure 3.16: SNMP connectivity troubleshooting sequence
39
3.3.7 Polling configuration/scheduling
Polling is the periodic checking of specific parameters of an SNMP agent by the SNMP manager. In our application polling was implemented to check device heartbeat, update device information, interface performances and update interface configurations. Polling was implemented using the Celery beat scheduling. Celery has built-in integration with Django which was our web - framework and it provides a simple interface for configuring scheduled tasks. During the development, Celery tasks were created to facilitate the SNMP related polling activities using our libraries. As explained earlier the scheduling of tasks in our application was achieved using the Celery beat schedule API. The configuration of our scheduling is shown below. The CELERY_BEAT_SCHEDULE parameter is defined in the settings.py file of our project. The parameter is a Python dict containing the task and the schedule. The schedule was set at 10 seconds for the heartbeat, 30 seconds for interface status updates and 15 seconds for performance update and can always be changed depending on the sensitivity of service carried by the monitored device.
Figure 3.17 : Celery beat schedule
3.3.8 Heartbeat feature Implementation
Heartbeat was used to update the SNMP connectivity of agents to the manager. It is from this
40 routine that the online/offline status of agents could be determined and updated in the database of the system. The heartbeat was executed by requesting the SystemObjectid for the agent if an SNMP error was raised in 3 consecutive requests the heartbeat was considered to have failed and the device would be updated as offline.
Figure 3.18: Heartbeat implementation syntax
The flow chart below shows the heartbeat implementation sequence
41
Figure 3.19: Heart implementation syntax
42
3.3.9 Device status update implementation
Device update was used to update the hostname, enterprise and product ID. This task was achieved by polling every 30 seconds as shown in the flow chart below.
Figure 3.20: Device update flowchart
43
3.3.10 Performance data collectionimplementation
Interface performances were collected by polling the agents every 15 seconds. Celery tasks for performance collection were defined in the application. The flow chart below highlight the Performance instance creation sequence
Figure 3.21Performance instance Creation
44
Performance data collection instance
Figure 3.22: Performance data collection
45
The following code was used for data collection
def collect_performances(self):
interface_instances = self.interfaces_instances
for instance in interface_instances: if instance.utilization : # collect interface utilization utilization = self.manager.get_interface_inbound_utilisation(instance.interface.ifIndex) self.save_interface_utilization(utilization, instance.interface)
if instance.inoctates : # collect inoctates value = self.manager.get_interface_in_octets(instance.interface.ifIndex) self.save_interface_inoctates(value, instance.interface)
if instance.outoctates : # collect inoctates value = self.manager.get_interface_out_octets(instance.interface.ifIndex) self.save_interface_inoctates(value, instance.interface)
Figure 3.23: Performance data collection code
@app.task() def update_all_device_performance():
device_manager = DeviceObject() # create a device object manager instance devices = device_manager.all() # query all devices configured in the system
for device in devices: collect_device_performance.delay(device.ipaddress) # call the collect performance
@app.task() def collect_device_performance(host): device = Manager(host) # create manager instance for the device
device.collect_interface_performance() # collect performance
Figure 3.24: Performance collection task for Celery
46
3.3.11 Interface configuration updates
Interface configurations were updated routinely by polling every 30 seconds.
Figure 3.25: Device information update flow chart
47
@app.task() def device_update_int(host): """ Task to update device properties in the database :param host: :return: None """ device = Manager(host) device.update_interface_db() # update the interface DB
@app.task() def update_all_device_int():
device_manager = DeviceObject() # create a device object manager instance devices = device_manager.all() # query all devices configured in the system
for device in devices: device_update_int.delay(device.ipaddress) # call interface update task per device
Figure 3.26: device information update implementation
3.3.12 SNMP trap processing sequence
Traps will pass in a list of OIDs with their values (elsewhere called a VARBIND or VarList), one per line. It is best to handle this list by simply pushing the values onto an array (dictionary) for later processing. For the parsing of the VARBINDS a method (varbind_parser) was created, the method would return a python dict containing OID and value pairs.
48
The flow chart below is used to illustrate the sequence in processing the snmptraps.
Figure 3.27: Trap handling flowchart
49
3.3.13 Snmptrap handling module sequence
snmptrapd.conf snmptrapd.py snmp_manager.py
Snmptrapd.conf: Configured trap handlers in this file. Each trap handler referring to the script file snmptrapd.py. Snptrapd.py: Configured the parsing of trap varbinds into a python dict for processing suing the snmp_manager.py library Snmp_manager.py: Contained the methods for verifying and saving traps received in python dicts from the snmptrapd.py file. TRAP data format The trap data was parsed into a python dict for manipulation by the Django framework code. The data is processed into a dict similar to the trap model defined in the models module for easy integration with the database.
Trap dict format The snippet below shows the basic trap receives from SNMPTRAPD before parsing.
iso.3.6.1.2.1.1.3.0 = Timeticks: (785494) 2:10:54.94 iso.3.6.1.6.3.1.1.4.1.0 = OID: iso.3.6.1.4.1.9.9.41.2.0.1 iso.3.6.1.4.1.9.9.41.1.2.3.1.2.4 = STRING: "LINK" iso.3.6.1.4.1.9.9.41.1.2.3.1.3.4 = INTEGER: 4 iso.3.6.1.4.1.9.9.41.1.2.3.1.4.4 = STRING: "UPDOWN" iso.3.6.1.4.1.9.9.41.1.2.3.1.5.4 = STRING: "Interface FastEthernet0/1, changed state to up" iso.3.6.1.4.1.9.9.41.1.2.3.1.6.4 = Timeticks: (785494) 2:10:54.94 from 0.0.0.0
Figure 3.28 raw varbinds from SNMPTRAPD
The snippets bellow shows an example of the trap dict created after receiving trap from SNMPTRAPD. The snippets show the numeric and text format of the traps respectively
linkdown_trap_OID = { 'iso.3.6.1.6.3.18.1.3.0': '192.168.1.2', 'iso.3.6.1.6.3.1.1.4.3.0':'iso.3.6.1.4.1.9.1.122', 'iso.3.6.1.2.1.2.2.1.2.3': '"Ethernet0/2"', 'iso.3.6.1.6.3.1.1.4.1.0':'iso.3.6.1.6.3.1.1.5.3', 'iso.3.6.1.6.3.18.1.4.0': '"public"', 'iso.3.6.1.2.1.2.2.1.3.3': '6', 'iso.3.6.1.2.1.2.2.1.1.3': '3', 'iso.3.6.1.2.1.1.3.0': '0:0:01:50.96', 'iso.3.6.1.4.1.9.2.2.1.1.20.3': '"administratively' Figure 3.29: Numeric format of} trap dict after parsing 50
linkup_trap_IFMIB = {'IF-MIB::ifIndex.3': '3', 'IF-MIB::ifType.3': 'ethernetCsmacd', 'SNMPv2-SMI::snmpModules.18.1.3.0': '192.168.1.2', 'SNMPv2-SMI::enterprises.9.2.2.1.1.20.3': '"up"', 'SNMPv2-MIB::snmpTrapOID.0':'IF-MIB::linkUp', 'SNMPv2-SMI::snmpModules.18.1.4.0': '"public"', 'SNMPv2-MIB::sysUpTime.0': '0:0:15:07.77', 'IF-MIB::ifDescr.3': 'Ethernet0/2', 'SNMPv2-MIB::snmpTrapEnterprise.0': 'SNMPv2-SMI::enterprises.9.1.122'}
Figure 3.30: Textual format of trap dict after parsing
3.4System integration
Figure 3.31 below summarizes all the system components used to come up with the full solution design for a multi-vendor network monitoring system.
System Components: • Net-SNMP • Django 2.2 Framework • Linux (Ubuntu 16.04) • Python 3.5 • snmp-cmds library • sqlite3 • Redis • Celery 4.4.0 The network monitoring system was designed as a web-based application using the Django webframework. The application used a simple relational database based on sqlite3 to store device information and alarms. In order to improve the real-time performance of the system Celery was used for task queueing. This improved the handling of simultaneous tasks in the system. The SNMP manager system was built on Linux (Ubuntu 16.04) server. Figure 3.31 below shows the system architecture
51
Figure 3.31: System architecture
3.4.1 Network Prototype
Equipment from three vendors Huawei, Cisco, and ZTE equipment was used to come up with a prototype network for results collection as shown in figure 3.32 below. Two Ethernet testers configured in the “Traffic generator and monitor”mode was used to simulate real network
52 traffic scenarios for performance analysis results.
Figure 4.1 below shows the Network prototype designed to collect monitoring system results
Figure 3.32: Network prototype
Figure 4.2 shows the photo for the network prototype as assembled in the test room.
53
Figure: 3.33: Network prototype photo
CHAPTER 4: RESULTS ANALYSIS AND DISCUSSION
54
This chapter presents the results and analysis of the multi-vendor network monitoring system. As highlighted in the previous chapter, three switches from different vendors were used for testing. Wireshark was also used to verify results responses (packets) from SNMP agents. Overall, this chapter shows results for NE online/offline status, interface connection status, Linkup/link-down status and link performance utilization. A network insight analysis example using data from the SQLite database was also added.
4.2 Device Online/Offline Status
Heartbeat polling was used to check the device status at regular intervals. As described in Chapter 3 the heartbeat was monitored by requesting for the system name (sysname) via SNMP at intervals. The heartbeat was considered alive if the system was successfully received from the agent. If an exception was raised from three consecutive sysname SNMP requests, the heartbeat was considered a failure, and the device's status was updated to „offline‟ in the database. The image below shows the Wireshark trace for the request sent to the agent. The OID used in the request is “1.3.6.1.2.1.1.5.0” as shown on the Wireshark screenshot below.
Figure 4.1: Device Offiline Status Wireshark trace
55
The response received from the SNMP agent under testing contains the value „Ciscoswitch‟ to indicate the system name retrieved from the agent as captured in the Wireshark image below. A successful request returns the value „Ciscoswitch‟ which is the actual hostname of the test SNMP agent. If an exception is raised on the request the heartbeat is considered a failure. Exceptions are raised when the agent is not reachable from NMS/SNMP Manager.
Figure 4.2: Device Online Status Wireshark trace
4.2.1 Device status from User Interface
The User Interface (UI) is updated from the DB configured in the backend. In this instance, the DB used is the SQlite3. From the image below the Huawei and Cisco switches were disconnected to trigger the offline condition, the devices are offline and the “connection” status attribute is used to indicate that.
56
Figure 4.3 Device Offline Status
Figure 4.4 below shows the UI screenshot when all the three test devices were connected back Online
Figure 4.4 Device Online Status
4.3 Link Status
4.3.1 LinkUp Trap
The OID value for the key “iso.3.6.1.4.1.9.9.41.1.2.3.5.10” in this instance was 'iso.3.6.1.4.1.9.9.41.1.2.3.6.10‟, this indicated that the interface is up. The interface was administratively brought up via the command line “no shutdown” to trigger the LinkUp trap. The image below shows the trace of the trap as received in Wireshark.
57
Figure 4.5 Device Linkup Status Wireshark trace
The user interface was updated accordingly by retrieving the link status value from the database. On the UI the Status parameter has the value “Connected” to represent the LinkUp condition. The cleartime parameter indicates the clear time of the LinkDown status, essentially this value is the time the LinkUp trap was triggered. Figure 4.5 below shows the screenshot of a Linkup status for port 1 and port 2 of the ZTE switch.
Figure 4.6: Device Linkup status
4.3.2 Link down Trap
In order to trigger the trap „LinkDown‟, the interface gig 1/1 was shut down manually. The snapshot below shows the received trap from the SNMP agent. The request OID key “iso.3.6.1.6.3.1.1.4.1.0” is used to determine the nature of the trap, whether it is LinkUp or
58
LinkDown. The received OID value for the key in this instance was 'iso.3.6.1.6.3.1.1.5.3', this indicated that the interface is down.
Figure 4.7 Device Link down Status Wireshark trace
The data is processed and stored in the SQLite database, to be retrieved by the system for User Interface (UI) display. The image below shows the UI presentation of the interface status, the status is „Disconnected‟ representing the LinkDown condition of the interface. The Occur Time parameter shows the time the LinkDown trap was received. Figure 4.6 below shows the results on UI for the LinkDown alarm.
Figure 4.8: Device Linkdown status
4.3.3 Linkup and Link down trap logs.
The logs below show the varbinds received from SNMP agents, for the Link-Up and Link-Down events. The value of the OID “iso.3.6.1.4.1.9.2.2.1.1.20” is either up or down depending on the scenario. The logs collect the time, ifIndex, device IP and the other varbinds of the received trap.
59
4.4 Interface Requests
In our implementation, we have continuous updates for the interface details. The image below shows the trace from the request of an interface of the agent. The OID for the request is 1.3.6.1.2.1.2.2.1.0 as shown in the image below. The response is shown in the second image. The response is a table of ifEntry OIDs for the ifTable for each interface. The request is a „bulk-get‟ as shown in the screenshot. Listing of interfaces request
List interface response
Figure 4.9: Interface status Wireshark trace
The user interface for interface lists shows the information retrieved from the SNMP request for ifTable entries.
60
Figure 4.10: List of interface status
4.5 Performance Collection
The performance was measured using the port utilization of network devices. Utilization was calculated from the in octets values collected at an interval. The formula below shows how the utilization was calculated.
푈푡푖푙푖푧푎푡푖표푛 = 푖푛푂푐푡푒푡푠2 − 푖푛푂푐푡푒푡푠1 ∗ 8 ∗ 100/(푑푒푙푡푎푡푖푚푒 ∗ 10000000) inOctets2 and inOctets1 are the in octets value collected at known time interval 푑푒푙푡푎푡푖푚푒
4.5.1 Inoctates and Outoctates request
The inoctates were requested using the OID '1.3.6.1.2.1.2.2.1.10.X' where X is the index of the interface. In the image below, the requested interface is of the index value of „1‟. The request should return a Counter32 value. A counter32 value is a 32-bit integer value, it has a range from 0 to 4 294 967 296 which it resets to zero when it reaches 4 294 967 296 . An ethernet test gear was used in the generation of random packets to test the collection of performance information.
61
Figure 4.11: Inoctates request on Wireshark trace
The response screenshot shown in the image below shows a result of “38673” octets from the request. The result was synonymous with the expected value from the ethernet test gear.
Figure 4.12: Inoctates response on Wireshark trace
The values obtained from the testing are presented as a table or graph in the user interface. The image below shows the results as a table for Inoctates (figure 4.8) and Outoctates (Figure 4.9)
62
Figure 4.13: Inoctates statistics
Figure 4.14: Outoctates Statistics
The outoctets were requested using the OID '1.3.6.1.2.1.2.2.1.10.X' where X is the index of the interface. In figure 4.9 above, the requested interface is of the index value of „1‟
Performance Graphs The image below shows the In utilization, inoctets, and outoctets as graphs using an interface connected to a Huawei switch.
63
Figure 4.15: Performance utilization graphs
Utilization Table As highlighted above, the in utilization was calculated from the in octets values collected at10 seconds intervals using the following formula.
푈푡푖푙푖푧푎푡푖표푛 = 푖푛푂푐푡푒푡푠2 − 푖푛푂푐푡푒푡푠1 ∗ 8 ∗ 100/(푑푒푙푡푎푡푖푚푒 ∗ 10000000) inOctets2 and inOctets1 are the in octets value collected at know time interval 푑푒푙푡푎푡푖푚푒
delta Utilisation inOctets1(octets) inOctets2(octets) time(s) (%) 1622548 1920298 2 11.91 1670471 2398471 2 29.12 9970592 10634592 2 26.56 12569701 12977451 2 16.31 22889874 23590374 2 28.02 38628393 38886643 2 10.33 45664023 45789023 2 5 788408224 789036474 2 25.13
64
874613181 875023931 2 16.43 921567673 922201423 2 25.35 1781894723 1783450723 2 62.24 1809145987 1809894737 2 29.95 2806493274 2807048274 2 22.2 3871702784 3871990284 2 11.5
Table 4.0: Percentage of port utilization
Figure 4.16: Performance utilization statistics from the NMS
A threshold of 25% port utilization was set to allow the system to send a warning alarm when the port experience utilization above threshold.
Utilization Graph
65
Figure 4.17: Port utilization graph with 25% upper threshold
4.6 Discussion
The results were compared with the 2 commercialized monitoring systems (Cacti and Nagios). Cacti only. All the three can show the exact date and time when an event happened, duration and status of every node and interface. Comparison with Cacti shows that Cacti has better graphing capability using the powerful rrdtool. Both preconfigured templates and custom settings are available to provide a flexible graphing tool. However, the graphs are only refreshed after 5 mins which is too long and there is no alerting in the event thresholds are exceeded. In our system like figure 4.12 above, a threshold is set for port utilization and the administrator can easily notice when the threshold is exceeded. In this design, the collected data can be archived in the database for 12 months ( with enough hard drive capacity), and therefore yearly and monthly traffic graphs can be provided using row data while the use of RRD in Cacti makes it impossible for long time data archiving.
Figure 4.4: shows that the designed system the monitored network elements are viewed as a list showing hostname, equipment type, vendor, city, and region. On comparison with the latest version of Nagios and Cacti, it was noticed that the 2 have added a weather map plugin to improve network topologyvisualization.
To add value to the new monitoring tool the researcher added a network performance and Insight analysis window. This one is not available in both Nagios and Cacti. All instances where the
66 performance exceeded the set threshold will be recorded and the summary displayed on the dashboard. Network operators can use this part to make future decisions, for example, all links processing traffic above the threshold can be included in company link upgrade plans. The screenshot below shows the
Figure 4.18: Network Insight and Analysis Summary
Figure 4.14 below shows a more detailed network performance analysis per port showing the frequency of occurrence. It also summarizes the interfaces which experienced a high frequency of disconnections. Disconnection history can also be very useful to operators because it can be used to check fiber quality for the particular links.
Figure 4.19: Network Insight and Analysis Statistics per port
67
CHAPTER 5: CONCLUSION AND RECOMMENDATIONS
This chapter gives a summary of the whole research. The benefits of the research to the industry are also outlined. It also maps the directions for future research by proposing ideas based on the current work.
5.1 Conclusion
The researcher believes that the designed SNMP data collector meets the requirements of a standard monitoring system. Thorough research on several working models was first done in order to come up with the most suitable design architecture. The literature in chapter 2 also shows available protocols that could be used to achieve the same results and the advantages of choosing SNMP over other protocols were explained. SNMP protocol was used to collect the communication status data of Network elements through polling and traps. Net-SNMP libraries and python scripts were used for the actual implementation. The data-collector was developed to aid in the design of a complete multi-vendor NMS and therefore the methodology also clears shows how the system was integrated with the database and graphical user interface designed by the other two colleagues. A web-based application using the Django webframework was used to come up with a functional Network monitoring tool using sqlite3 database and Celery for queueing tasks. The implementation, test, and performance evaluation of the tool was done using real equipment from 3 different vendors. Results review that the system could be stably monitored using the developed functions of the tool such as the node online status, interface connection status, link status, and link performance utilization. The researcher can, therefore, conclude that the aim of the project was fulfilled. The tool will bring many benefits to network operators including monitoring performance of network devices detecting and isolating network faults, and collecting and archiving the network statistic performance data that can be used to identify currentand future growth of their networks.
68
5.2 Recommendations and Future Work
- For the commercial application in a live network, we tool should be installed on a standard server machine with sufficient hard drive space and at least 2.8GHz processor speed so that that it can cope with large amounts of data. The prototype was tested on a laptop which was Ok for a small number of NEs. - To allow flexibility of accessing the NMS server, the server can be connected to the internet and secure VPN accounts created for all engineers and technicians so that they can login to the NMS system from home. This is very important especially during this era of COVID-19 where people are encouraged to work from home. - In future Standard, Northbound interface can be developed to allow the system to integrate with 3rd party Operation Support Systems (OSS) in companies with more than one NMSs. - A notification module can also be developed and integrated with the tool. The module will hook into the event system, generating a notification message and sending it out to the appropriate engineer each time an event/fault is triggered. The notifications can be short message service (SMS), email, Instant message. Depending on different cases, the notifications can be configurable to be broadcasted to everyone on the list or just to selected individuals. - In the future, aweathermap plugin can be added to improve network topology visualization
69
REFERENCES
1.Kim S. Nash and Alyson Behr. (2007)'Network Monitoring Definition and Solutions'
2. Nidhishree, G., Manimala, S. and Engineering, C. (2017) „Design and Implementation of SNMP based Network Device Monitoring System‟,
3.JamesFarmer, BrianLane, KevinBourg, WeylWang. (2017) „FTTx Networks Technology Implementation and Operation‟
4. C.C.Li, Z.S. Ji, F.Wang, P.Wang, Y.Wang, Z.C. Zhang (2016) „The Network Monitoring System Based on Cacti for EAST‟
5.Information Sciences Institute University of Southern California, (1981). „Internet Protocol RFC791‟
6. Danijel Mijić. (2018) „Centralized monitoring of computer networks usingZenoss open-source platform‟ 7. Virgil Dobrota (2016) „Advanced Monitoring of the OpenStack NFVInfrastructure: A Nagios Approach Using SNMP‟ 8. Rajesh Kumar, Pinky Ramchandra Shinde. (2016) „Computer Network - IP Address & Subnetting‟ 9. Soraya Sinche, Duarte Raposo, Ngombo Armando, André Rodrigues,Fernando Boavida, Vasco Pereira, and Jorge Sá Silva. (2020) „A Survey of IoT Management Protocols and Frameworks‟
10. Tobias Oetiker. (2019) „Rrdtool‟,URL: http://oss.oetiker.ch/rrdtool 11. Alper Sarikaya, Michael Correll, Lyn Bartram, Melanie Tory, and Danyel Fisher (2019). „What Do We Talk About When We Talk About Dashboards?‟ 12. Martin Phiri, Peter Mfupa (2016) „Network Monitoring System‟ 13. Wojciech Kocjan, Piotr Beltowski2016 „Learning Nagios‟ Third Edition 14. Peter Mwape Mfupa. (2017) „Network Monitoring System (Net-Mon) (Conference ID: CFP/127/2017)‟ 15.Jithesh Sathyan. (2016) „Fundamentals of EMS, NMS and OSS/BSS‟ 16. Boyko A., Varkentin V. Polyakova T. (2019) „Advantages and Disadvantages of the Data
70
Collection‟s Method Using SNMP‟ 17. Otávio Alcântara, Virginie Fresse, Frederic Rousseau. (2014) „Evaluation of SNMP-like Protocol to manage a NoC Emulation platform‟ 18. Vyshak Srivatsa Raghavendra.(2016) „Implementation and Automation of Network Monitoring inVirtualized IP Multmedia Subsystem‟. 19 Hongliang Li. (2019) „Design and Implementation of Spacecraft Network Monitoring System based on SNMP‟ 20. M. Alkasassbeh, G. Al-Naymat, A. Hassanat and M. Almseidin, (2016) "Detecting Distributed Denial of Service Attacks Using Data Mining Techniques," 21Abhishek Sinha, Lakshita Sejwal, Nishant Kumar, Anranya Yadav (2015) „Implementation of ICMP Based Network Management System for Heterogeneous Networks‟. 22Ian Berry,Tony Roman,Larry Adams,J.P. Pasnak,Jimmy Conner,Reinhard Scheck,Andreas Braun (2017) „The Cacti Manual‟
23. Stephen Few. (2006) „In Information Dashboard Design: The Eff ective Visual Communication of Data‟,
24. Wolfgang Barth. (2009). „Nagios: System and Network Monitoring‟.
25. Viranch Mehta. (2013). „Icinga Network Monitoring‟.
26. Mohammad Yaqub (2015) „MySQL Introduction‟
APPENDIX
71
Project Timetable
Target (Measure to Task Resource Activity by Months from the start of the project indicate task is completed) June Nov 2019 Jan 2020 Feb 2019 March 2020 July 2020 2020 1-31 1-31 1-28 1-31 1-31 1-30 Literature Journals and Review books
Studied and notes taken Project Project Proposal Proposal Writing and submission
Material Simulation sourcing software installed, Construction of prototype
Data Result Collection tabulation
Results Validation Analysis and
comparison of result Dissertation Report Writing compiled
72
Important parts of Project Code Creating class models
Test device connectivity
73
Smptrapd
74
75
Celery Application Configuration
76
Heartbeat Check
77
Device Status Updates
78
Interface Updates
79