Design and Implementation of an Automated Network Monitoring andReporting Back System

Khan, R., & Khan, S. U. (2018). Design and Implementation of an Automated Network Monitoring and ReportingBack System. Journal of Industrial Information Integration, 9, 24-34. https://doi.org/10.1016/j.jii.2017.11.001

Published in:Journal of Industrial Information Integration

Document Version:Peer reviewed version

Queen's University Belfast - Research Portal:Link to publication record in Queen's University Belfast Research Portal

Publisher rights © 2017 Elsevier Inc. All rights reserved.This manuscript version is made available under the CC-BY-NC-ND 4.0 license http://creativecommons.org/licenses/by-nc-nd/4.0/,whichpermits distribution and reproduction for noncommercial purposes, provided the author and source are cited.

General rightsCopyright for the publications made accessible via the Queen's University Belfast Research Portal is retained by the author(s) and / or othercopyright owners and it is a condition of accessing these publications that users recognise and abide by the legal requirements associatedwith these rights.

Take down policyThe Research Portal is Queen's institutional repository that provides access to Queen's research output. Every effort has been made toensure that content in the Research Portal does not infringe any person's rights, or applicable UK laws. If you discover content in theResearch Portal that you believe breaches copyright or violates any law, please contact openaccess@qub.ac.uk.

Download date:11. Oct. 2021

Design and Implementation of an Automated Network Monitoring and ReportingBack System

Rafiullah Khana,∗, Sarmad Ullah Khanb

aQueen’s University Belfast, Belfast, United Kingdom, Email: rafiullah.khan@qub.ac.ukbPolitecnico Di Torino, 10129 Turin, Italy, Email: sarmad.khan@polito.it

Abstract

The task of network monitoring becomes tedious with increase in the network size, heterogeneity and complexity. Theavailable network monitoring and management solutions are not only expensive but also difficult to use, configure andmaintain. Manually pin pointing a faulty device in the large complex network is very tricky and time consuming fornetwork administrators. Thus, an automated system is needed that immediately reports to network administrator aboutfault type and location as soon as it arises. This paper presents design and implementation of an intelligent networkmonitoring and reporting back system for large size organizations/industries. It is based on programming open-sourcetools (such as Nagios and RT) and intelligently integrating them to monitor network devices such as switches and routers.To monitor end-user devices in the network, a software package has been developed using Universal Plug & Play (UPnP)technology. The developed monitoring system immediately notifies network administrator as soon as a network problemarises. The notification message clearly pin points the fault location in network topology, its type and impact on rest ofthe network. If the network problem is not resolved within the pre-specified deadline, a second notification is sent outto the next responsible person. Thus, all people in the priority list are notified one by one with pre-specified deadlinesuntil the problem is resolved.

Keywords: Network Monitoring, Network Management, Universal Plug & Play, Ticketing System, Reporting BackSystem, Nagios

1. Introduction

Industry 4.0 revolutionizes industries by making themmore connected than ever before. This disruptive inno-vation connects plethora of heterogeneous devices whichare communicating among each other to perform complextasks [1]. Due to relying mostly on IP based communi-cation, ensuring availability of devices and services is ut-most necessary. Thus, an automatic, flexible and scal-able network monitoring and management system is es-sential for industries. The monitoring system constantlychecks the whole network topology for any failing compo-nent, device or service interruption and immediately noti-fies the administrator [2]. The notification messages carryinformation about faulty services and devices which mayhave been caused due to misconfiguration, overloaded orcrashed servers, cyber attack, network cable disconnectionor device power disconnection [3, 4]. Due to heterogeneityand complexity in large size industrial networks, manualmonitoring the state of each device is very tedious and timeconsuming task. Further, troubleshooting or pin pointingthe fault location and its impact on rest of the network isvery challenging [5].

Many network monitoring systems can either monitorcore network devices (such as switches and routers) or end-

∗Corresponding author

user devices (such as PCs, printers, scanners, etc). Fur-ther existing solutions have limited flexibility, scalabilityand provide insufficient information about the fault loca-tion and its impact on rest of the network. This paper ad-dresses network monitoring and management challenges ina more flexible way with the design of a new system. Theproposed system is based on programming and integrat-ing open-source tools such as Nagios and Request Tracker(RT) and developing a software package using UniversityPlug & Play (UPnP) technology. The proposed system isnot only able to monitor intermediate core network devicesbut also end-user devices located in private sub-networks.Thus, the network monitoring and management task is di-vided into two parts: (i) monitoring devices directly acces-sible from ISP or network control center of the organiza-tion, and (ii) monitoring devices located in private LANs.

The proposed network monitoring and management sys-tem is applicable to any large size organization or indus-try. However, this paper focuses on university network asa use case example. Fig. 1 depicts the scenario of a uni-versity that has several campuses. Each campus has differ-ent departments and each department has several privatenetworks (e.g., classes, laboratories, offices, etc). Thus, alarge-size university consists of thousands of network de-vices. Due to limited IPv4 addressing space, universitiesare normally allocated certain number of public routableIP addresses. The university ISP or network control center

Preprint submitted to Elsevier Journal of Industrial Information Integration November 15, 2017

University ISP

University Campuses

Departments

Offices, Classrooms,

Labs, etc

Administrator Admin PC Network Monitoring System

Campus-NNetwork

Dept-1Network

Campus-1Network

LAN

Dept-2Network

Dept-1Network

Dept-2Network

LANLANLANLANLAN

ISP Network

Figure 1: Basic network topology of a large size university.

intelligently utilizes these IP addresses for certain devicese.g., campuses and departments. However, network de-vices in laboratories, classrooms and offices normally haveprivate IP addresses. In some cases, devices in the privatesubnets are not directly accessible from the university ISP.Thus, it is necessary that network monitoring and manage-ment system should be able to monitor all network devicesregardless of their direct accessibility from the universityISP. To this aim, proposed system uses Nagios and RT inthe university ISP for monitoring all devices in networktopology which are directly accessible. A UPnP basedmonitoring system is developed for monitoring devices inlaboratories, classrooms and offices which are not directlyaccessible from ISP.

In proposed system, the functionalities of network mon-itoring are performed by Nagios [6]. Nagios allows easyextension of functionalities and integration of custom mod-ules or plugins. A complete network topology (i.e., con-sisting of devices directly accessible from university ISP) iscreated in Nagios and different monitoring services basedon ICMP or SNMP are applied on them. Nagios continu-ously monitors the devices and services running on themand declares them critical or down after making severalpre-defined number of attempts. When a network deviceor service is down, Nagios generates a notification whichcreates a ticket in RT ticketing system with problematicdevice information and its impact on rest of the network.RT is responsible for performing the task of fault/prob-lem progress tracking and management [7]. Note that RTis heavily used worldwide by different organizations fortracking and effectively resolving issues/complaints fromcustomers. The scope of RT is quite broad and providesmulti-user interface for secure authentication and collab-orative management of issues/complaints. The developedUPnP modules are used for monitoring devices in the pri-vate LANs. UPnP technology offers auto-discovery, zero-configuration and seamless networking features [8]. Fur-ther, UPnP is supported by plethora of heterogeneous de-vices and does not cause any interoperability and inte-gration issues. The proposed network monitoring systemimmediately informs network administrator as soon as anetwork device goes down. If the administrator is busyor could not resolve issue within a set deadline, a newnotification is sent out with a new deadline to the next

responsible person in the priority list. Thus, all people inthe priority list are informed one by one until the problemis resolved. The proposed system is intelligent enough toprecisely pin point the problematic device and its impacton rest of the network. Further, a single notification is sentout if a parent device in network topology stops function-ing instead of sending multiple notifications for all affectedchild devices.

The rest of the paper is organized as follows. Section 2addresses background and related work. Section 3 presentsthe design of proposed network monitoring and manage-ment system. Section 4 provides implementation guide-lines. Section 5 presents experimental evaluation of pro-posed system. Finally, Section 6 concludes the paper.

2. Background and Related Work

Several network monitoring and management tools havebeen developed over time. The Multi Router Traffic Gra-pher (MRTG) is one of the most commonly used tool fornetwork monitoring that works on Windows and mostLinux distributions [9]. It is written in Perl scriptinglanguage and uses Simple Network Management Proto-col (SNMP). MRTG generates live visual graphs of allnetwork devices in the HTML pages. These graphs pro-vide information about the traffic load. Manually checkinggraphs of each network device in MRTG and identifyingthe problematic/faulty ones is very tedious, inefficient andtime consuming task for the network administrator. An-other most commonly used networking monitoring tool isNagios [6]. Nagios is an open-source software tool and isspecially designed for monitoring complete infrastructureof enterprise networks for availability of different networkservices [10]. If a network device is down or any of its net-work service is down, Nagios raises an alert to the techni-cal staff. Nagios also provides statistics about devices andtheir services availability.

Several researchers have investigated remote monitor-ing and management of complex large size networks. Au-thors in [11] proposed an event monitoring and controlsystem for enterprise networks. The system monitors traf-fic from network devices to determine their operationalstatus and raises alert to network engineer when failure isdetected. Authors in [12] addressed new services in Nagiosfor monitoring network bandwidth and new form of noti-fications through email and SMS. These new services in-crease Nagios scope for even better and improved networkmonitoring. Authors in [13] addressed how to securelydeploy and maintain monitoring services based on Nagiosfor big enterprise networks. Authors in [2] presented a net-work monitoring system based on Nagios and designed amore user-friendly and interactive interface. They have ex-tended monitoring functionalities and capabilities throughplug-in modules without modifying the Nagios core. Someresearchers have also proposed RFID based monitoringand management in industries [14, 15]. Their focus is on

2

tracking inventory and incoming/outgoing goods e.g., lo-gistic industry. However, presented RFID approaches donot aim to check presence/availability of a network deviceor service.

Authors in [4] addressed remote monitoring of a LANthat mainly consists of server devices. The system notonly monitors availability and operational status of serverdevices in remote LAN but also their environment. Themonitoring system also uses sensor devices and raises SMSalert to administrator in case of a device failure or hazard(e.g., temperature, power fluctuation, humidity, fire, wa-ter, etc). Other similar works are addressed in [16, 17, 18].Normally, organizations have hierarchical network struc-ture for better flexibility and manageability. Further, indi-viduals at network administration have hierarchical naturein terms of responsibilities and privileges. Therefore, au-thors in [19] proposed efficient authorization function withunified authentication and demonstrated it for hierarchicalnetwork monitoring system.

Due to increasing network complexity and heterogeneityof devices, the conventional manual methods for networkmonitoring and management become tedious as well astime consuming. Even available automated network mon-itoring options are quite complicated and expensive to de-ploy and maintain [5, 20, 21, 22]. To ease the installation,configuration and maintenance of network monitoring forlarge size heterogeneous networks, authors in [23] imple-mented and testing an ICMP based automated solutionthat monitors entire network and is also backward compat-ible to support non-SNMP based devices. Further detailedstudies on networking monitoring tools and techniques areavailable in [24, 25].

Besides reliable and steady operations of the network,authors in [26] also focused on safety and security. Theyimplemented a network monitoring system based on net-work traffic. A similar work is presented in [27]. Au-thors in [28] addressed the development of monitoring toolfor content-centric networks. Authors in [18] presented anetwork monitoring and management system for complexuniversity network. However, the monitoring system onlymonitors network switches and routers and does not moni-tor network end-user devices. Further, the monitoring sys-tem is only applicable to devices directly accessible fromISP and lacks to monitor sub-networks with private IPaddresses.

Most previous works were either limited to small LANsor have limited flexibility, limited control and knowledgeabout fault location. Further, previous network monitor-ing systems were either limited to core network equipment(e.g., switches, routers) or end-user devices. These are thechallenges addressed in this paper with the design of amore efficient, flexible, reliable and scalable network mon-itoring and management system. The proposed system isbased on intelligent integration of Nagios and RT ticketingsystem [7] along with custom developed software packageusing UPnP technology.

3. Design of Proposed System

A network monitoring system monitors the whole net-work topology to ensure that all devices and services are upand running. As soon as a problematic device is detected,it immediately notifies the responsible person. Manuallymonitoring the state of each device in a complex largenetwork using MRTG graphs or other monitoring tools isvery challenging and time consuming. Further, monitor-ing systems usually lack to monitor devices in low levelsub-networks which may not be directly accessible fromISP (e.g., classes, laboratories and office in Fig. 1). Theproposed network monitoring system can be used by anyorganization/industry, but this paper considers a univer-sity network as a use case example. The proposed systemhas been designed with the following objectives:

• Its monitoring functionalities should be continuousand automatic with no or minimal attention requiredfrom the network administrator.

• It should offer versatility, portability and dynamicscalability if a device is disconnected or a new deviceis connected to the network.

• It should be able to monitor core network devices(e.g., switches and routers) as well as end-user devices(e.g., PCs, printers, scanners, copiers, etc).

• It should be able to immediately detect as soon asa network problem arises and notify the network ad-ministrator via email or sms.

• It should be vendor independent and capable to mon-itor plethora of heterogeneous devices from differentvendors without interoperability and integration is-sues.

• It should be able to pin point the exact location offaulty/problematic device in complex network topol-ogy and provide enough information about its possibleimpact on rest of the network.

• It should have low network traffic overhead and shouldnot consume significant resources of the monitoreddevices.

• It should keep track of changes in the network (e.g.,a problem may arise due to change in configurations)and store statistics about a device up and down time.

• It should provide secure remote authentication of thenetwork administrator to the monitoring system.

With these objectives in mind, the design of proposednetwork monitoring and management system is presentedin Fig. 2. It consists of two parts: (i) monitoring of devicesdirectly accessible from university ISP (depicted in Fig.2(a)), and (ii) monitoring of devices in private LANs e.g.,classes, laboratories, offices, etc (depicted in Fig. 2(b)).

3

Switches, Routers, Gateway Devices

Other Directly Accessible Devices

from ISP

Network Devices

Network Topology in Nagios

Nagios Plugins andMonitoring Services

RT Server,Configurations,Database, User

Accounts, Mailgate

NagiosRT

TicketingNotifications

Emails

SMS

(a)

Network Printers,Scanners, Copiers

etc.

Computers in Private LANs, Labs, Offices

and Classrooms

UPnP Client

DevicesNotifications

Emails

SMS

UPnP Server

UPnP Network Monitoring Service on Gateway Devices

in Private LANs, Labs, Offices and Classrooms

(b)

Figure 2: Proposed network monitoring system: (a) Monitoring devices directly accessible from ISP, (b) Monitoring devices in private LANs,labs, classrooms or offices.

An intelligent integration of Nagios and RT ticketing sys-tem is used to perform network monitoring and manage-ment task for devices directly accessible from universityISP. Whereas, a UPnP based monitoring system is devel-oped for monitoring devices in private LANs.

3.1. Network Monitoring Using Nagios and RT

It can be observed in Fig. 2(a) that main network mon-itoring and management task is performed by Nagios andRT ticketing system for devices which are directly acces-sible from the university ISP. Nagios is an open-sourcetool, specially designed for monitoring status of devicesand services. It continuously probes devices and servicesand sends out notification when any fault is detected [10].It is widely tested on Linux based systems, however, it isequally suitable for other operating systems as well [6]. Itis based on Perl scripting language and a complete net-work topology can be programmed using specific instruc-tions. While programming the network topology, Nagiosalso provides options to define a device as child or parentof other devices. When a parent device becomes faulty,all child devices will also become unreachable. However,Nagios can be configured to send only one notification forparent device instead of sending notifications for all af-fected child devices as well. The parent-child relation isvery common in network topologies. An example is shownin Fig. 3 for a university network where Nagios is monitor-ing different network clusters. Each network cluster can beregarded as a different university campus. Each campuswill then have different departments as child devices. Ifthe main router of a campus becomes faulty/unreachable,all its child departments will also become unreachable. Forsake of clarity, a Nagios notification about a parent deviceindirectly indicates that all of its child devices are alsoaffected.

Different types of services can also be defined in Na-gios for each device in the network topology. Nagios pro-

Figure 3: Nagios monitoring different network clusters.

vides web-based interface to graphically analyze the sta-tus of devices and services. It also provides statisticsabout a device/service up and down time and automat-ically sends notification (e.g., email) when the state of adevice changes. The types of services supported by Nagiosinclude but not limited to ICMP PING, SNMP, HTTP,SMTP, NNTP, etc. Nagios monitors devices and serviceswith two terms: (i) status and (ii) type of state. Statusrepresents the present status of a device or service andits possible values are up, down, unreachable and criti-cal. Whereas, the type of state is useful in alert/notifica-tion process and can have possible values of soft or hard.The type of state determines the final resulting status ofa device or service before sending out notification. Toavoid sending false/wrong notifications due to packet lossor glitch in the network, Nagios performs pre-defined num-ber of checks on devices and services before deciding abouttheir final status. The number of pre-defined checks isrepresented by ‘max check attempts’ when programmingand configuring devices and services descriptions. If thenumber of attempts performed by Nagios are less thanmax check attempts, the non-OK state of a device or ser-vice is declared as soft error state. The state is declaredas hard error state if the number of checks performed byNagios exceeds max check attempts and each check results

4

in non-OK state. In hard error state, a device or serviceis declared as down. Similarly, when a device or servicerecovers back, Nagios first assigns soft recovery state andthen ultimately replaces it with hard recovery state whena device/service consistently appears as OK in number ofchecks more than max check attempts. When the stateof a device changes to hard error state, Nagios sends outproblem notification. Similarly, when the state of a devicechanges to hard recovery state, Nagios sends out recoverynotification.

The proposed network monitoring and management sys-tem also uses RT which is heavily used by different or-ganizations worldwide for offering services to clients andmanaging their complaints [7]. RT also provides conve-nient web-based interface with several interesting features(normally required by organizations) such as multiple useraccounts, concurrent accessibility and control, email inter-face, remote accessibility, generation and tracking of no-tifications/events, etc. RT is open-source and has sup-port for different operating systems including Windowsand Linux. Based on the functionalities of RT, a databaseis required to be installed and properly configured whichcan be MySQL, ORACLE, POSTGRESQL, etc. The mainengine of RT is based on Perl scripting language and re-quires also Apache web server. Custom scripts can beprepared for RT to send an automatic response to a givenevent.

In the proposed network monitoring and managementsystem, RT manages the notifications generated by Nagios.Each Nagios notification creates a ticket in RT which isforwarded via email to the network administrator with aspecific deadline to resolve the issue. Every RT ticket hasa unique identification number and contains informationabout the problematic device. The responsible person ornetwork administrator can remotely access RT server andwork on the ticket. If he is unable to work on the specificissue, he can also assign that ticket to another responsibleperson. However, if the ticket is not resolved within setdeadline (e.g., 3 hours), another notification is sent out tothe next responsible person in the priority list and so on(until the issue is resolved).

At present, many organizations use cloud for storage andcomputation purposes. Migrating an organization’s infras-tructure as a cloud service is still very limited. To avoid therisk of breaking system and prevent service interruption,many critical industries (e.g., power companies) hesitatemigration to the cloud-based orchestration and infrastruc-ture management. However, it is worth mentioning thatproposed monitoring system can be used by both, cloudand non-cloud enabled organizations. Nagios has the ca-pabilities to monitor an organization’s cloud services orcan be deployed itself in the cloud to probe presence ofdevices and services. Any device or service (physical orvirtual) which is accessible over IP network (or accessiblefrom the cloud) can be monitored by Nagios.

Device Manager

Actions Manager

Control Point

Discovered Devices

1 2 N

Events Manager

Subscriptions

1 2 3

IP

UDP TCP

SSDPGENA

HTTPU/MU

SOAPGENA

HTTP

Figure 4: UPnP Control Point.

3.2. Network Monitoring Using UPnP

As shown in Fig. 2(b), a UPnP based service is de-veloped for monitoring devices in the private LANs (e.g.,classes, laboratories, offices, etc) which are not directly ac-cessible from university ISP. The network end-user devicesare quite heterogeneous and are from different manufac-turers. Therefore, a unique monitoring system is requiredthat does not cause any interoperability and integration is-sues for devices from different manufacturers. The UPnPcan be a suitable choice as it is supported by almost ev-ery type of network device including routers, PCs, print-ers, copiers, scanners, etc [8]. Further, UPnP offers auto-discovery, zero-configuration and seamless networking fea-tures and does not cause interoperability and integrationissues. It enables a device to automatically discover pres-ence of other devices in the network without requiring anyconfigurations. Unlike routers and switches, network end-user devices more frequently connect and disconnect to thenetwork and create uncertainty if a device is down or in-tentionally powered-down. This makes UPnP even a morebetter choice that can easily deal with dynamic changes inthe network. Further, UPnP is ideal choice from networkscalability point of view. As soon as a device is attached tothe network, it is automatically discovered by the UPnPserver. Thus, network size can dynamically scale in UPnPtechnology without requiring any configurations from theadministrator. In the proposed UPnP based monitoringsystem, Universally Unique IDentifier (UUID) is used fora device identification purpose. Instead of IP address, thechoice of UUID for identification is motivated based on thefact that devices may be using DHCP (i.e., they don’t havefixed IP). UUID size is 4 times bigger than IPv4 and canuniquely identify 2128 number of devices globally. How-ever, it is worth mentioning that UPnP in proposed sys-tem is used only at the boundaries of an organization andmonitors only small subnets with limited number of de-vices (usually less than 100).

In the proposed network monitoring system, a UPnPservice is developed and run on the network switch orrouter that automatically discovers presence of all devices

5

Controlled Device

IP

UDP TCP

Services Manager

Services

A1 A2 A3

A1 A2 A3

Description Manager

Services Description

XML File XML File

Device Description

XML File

SSDPGENA

HTTPU/MU

SOAPGENA

HTTP

Figure 5: UPnP Controlled Device.

in the network and tracks their power and operationalstate. The UPnP service automatically sends an emailto network administrator as soon as it detects that a net-work device became unreachable. For automatic discoveryof devices presence in the network, UPnP uses Simple Ser-vice Discovery Protocol (SSDP). When a network devicepower state changes, it immediately notifies UPnP serviceon network switch/router using General Event NotificationArchitecture (GENA) protocol. Further, a UPnP devicealso uses Simple Object Access Protocol (SOAP) to sendcommands (e.g., to notify UPnP service on switch/routerthat the device is powered-down intentionally by a user).Thus, UPnP service on switch/router precisely knows thereason that why a network device became unreachable.It then informs the network administrator via email andprovides information about the unreachable device.

3.2.1. UPnP Device Types

The UPnP device architecture has specified two types ofdevices: (i) Controlled Device (CD) and (ii) Control Point(CP). The CP functionalities are similar to a client and theCD functionalities are similar to a server. The CP sendsrequests/commands to the CD which are processed andresponded accordingly. Fig. 4 shows the basic buildingblocks of a UPnP CP. Device Manager handles the list ofdevices discovered in the LAN and acquires their descrip-tions. Action Manager has the ability to invoke actions orsend requests to the CD. Event Manager handles eventsbased on state variables such as changes in the power stateof a discovered device. It also periodically renews sub-scription of registered devices and deletes a device whosesubscription has expired. This subscription renewal andexpiry feature is very useful to determine when a networkdevice becomes unreachable.

Fig. 5 shows the basic building blocks of a UPnP CD.The CD offers one or more services to the CP. DescriptionManager handles device description and also provides itto the CP. The description is expressed in XML format

Network Device

UPnP CDLP Service

Action 1

Action M

UPnP CP

Gateway Device

UPnP CDMonitoring Service

Action 1

Action N

UPnP CP

Figure 6: Design of two-way UPnP based command and controlframework.

using standard UPnP formatting. Description Manageralso periodically advertises CD presence to the CP to re-new its subscription lease. Services Manager handles theimplementation of different services and actions. The CPcan request a service by invoking different actions on theCD. After receiving a request, Services Manager executesor performs a specific task. It also keeps the CP updatedthrough state variables about any change in its operationalor power state.

3.2.2. Design of UPnP Service

In general UPnP communication framework, one deviceimplements a CP (e.g., a PC) and other device implementsa CD (e.g., a printer). However, in proposed monitoringsystem, each device implements a CP as well as a CD inorder to achieve two way command and control features.The CP on one device enables it to send commands/re-quests to the CD on other device. The design of UPnPbased monitoring system is shown in Fig. 6. The Low-Power (LP) service needs to be executed on all networkdevices which are being monitored. However, the monitor-ing service needs to be executed on router/switch or anyother LAN device that performs the monitoring tasks. It isworth to mention that LP service also implements a kernelmodule that tracks changes in the power state of a deviceand immediately notifies the monitoring service throughits CP. When a device receives sleep or shutdown com-mand from user, it takes few seconds to freeze or stop alloperations and indeed enter into sleep or shutdown state.This time is more than enough for kernel module to notifythe monitoring service. It is also applicable if a networkdevice enters into sleep state due to staying idle for a pe-riod of time. The kernel module can also detect if a de-vice battery is low which is quite useful feature for batterypowered devices. Based on the information provided bykernel module on a network device, the monitoring servicecan determine the reasons behind a device unavailability.If a network device subscription expires and becomes un-reachable without any notification sent by kernel module,the monitoring service simply assumes that the device net-work cable or power cable is accidentally disconnected orsome misconfiguration took place on the device. In either

6

case, router/switch (i.e., monitoring service) uses a mail-client and notifies network administrator via email aboutthe fault/problem. The UPnP based monitoring systemdoes not require any network topology to be programmedor configured in the monitoring service. The monitoringservice automatically detects the dynamic connection/dis-connection of new or existing network devices and theirpower state transitions.

4. Implementations

This section provides implementation guidelines for theproposed network monitoring and management system. Itconsists of several open-source tools as well as custom de-veloped modules. Proper installation, configuration andintegration of RT, Nagios and custom developed UPnPbased software tools are strictly necessary for achieving thedesired objectives. This section presents implementationguidelines in generic way and uses university network as ause case example. By following the specified implementa-tion guidelines, a network administrator can develop theproposed monitoring system for his own organization/in-dustry. In short, this section addresses: (i) installation andconfiguration of RT, (ii) installation and configuration ofNagios, (iii) programming/formation of network topology,(iv) application of monitoring services on network devices,(v) interfacing RT with Nagios, (vi) development of UPnPclient software for end-user devices and (vii) developmentof UPnP server software for gateway devices (e.g., switch-es/routers).

4.1. Request Tracker Installation & Configurations

The main engine of RT is based on Perl scripting lan-guage and requires also Apache web server. A database isalso required which can be MySQL, ORACLE or POST-GRESQL, etc. The complexity in RT installation dependson the operating system. It has been observed that RTinstallation/configuration on Red Hat operating system isvery challenging as many dependencies need to be installedand configured manually. However, Ubuntu or Debian op-erating system provides much ease in installation of depen-dencies through ‘apt-get install’ feature. Prior to installa-tion of RT, it is necessary to install and configure Apacheweb-server, Postfix, Lynx, MySQL server, libdbd-pg-perl(i.e., Perl DBI driver for the PostgreSQL database server)and libapache-dbi-perl (i.e., interface connecting apacheserver to database via perl’s DBI). After successful instal-lation of these dependencies, RT (i.e., request-tracker) in-stallation should complete without any complications.

During the configuration of Postfix, the system requeststo specify Fully Qualified Domain Name (FQDN). TheFQDN should be specified carefully as it is a key factorallowing remote global access to RT server. Once RThas been installed, the following important configurations(depending on the organization) need to be specified in‘RT SiteConfig.pm’:

Set ( $rtname , ‘ rtName ’ )Set ( $Organizat ion , ‘ o rgan i za t i on ’ )Set ( $CorrespondAddress , rt@FQDN)Set ( $CommentAddress , rt−comment@FQDN)Set ($WebPath , ‘ ‘ / r t ”)Set ($WebBaseURL , ‘ ‘ http ://FQDN/ r t ”)Set ( $DatabaseType , $typemapmysql )Set ( $DatabaseUser , ‘name ’ )Set ( $DatabasePassword , ‘ password ’ )

The Apache web server must be restarted for configu-rations to take effect. Finally, the RT instance can beaccessed in any web browser at ‘http://FQDN/rt’. Thedefault user name is ‘root’ and password is ‘password’. RTallows to create different queues where each queue storestickets related to specific category/group of events. Fig. 7depicts queue configuration options in RT. It can be ob-served in Fig. 7 that a queue ‘University Network Monitor-ing’ is created as a use case example. A ticket is generatedin this queue every time state of a network device changes.The ticket holds information about the faulty/problematicnetwork device. RT also allows to create different user ac-counts and necessary rights can be assigned to each ac-count for a specific queue as shown in Fig. 8. Further,multiple users can also be grouped together and rights canbe assigned to them on global basis. In proposed networkmonitoring and management system, pending tasks (aboutfaulty/problematic devices) are represented as tickets inRT. A ticket can be assigned to a specific user accountand has different attributes (ticket owner, ticket priority,queue, time worked, time left, watchers, status, etc). Theowner and requester are default watchers for a ticket. How-ever, additional watchers can also be defined. Prioritiescan be assigned to tickets in RT within the range of 0-99(i.e., 99 as the highest priority). A ticket can be given ini-tial and final priority, which increment or decrement basedon time left.

4.2. Nagios Installation & Configurations

Nagios installation is comparatively simpler than RT.Executing following command as root user in Ubuntu/De-bian operation system completes the installation of Nagios(latest version 3):

# sudo apt−get i n s t a l l nag ios3

After successful installation, a password is assigned toweb user account using following command in terminal:

# htpasswd −c / e t c / nag ios3 /htpasswd . u s e r susername

The Nagios monitoring system can be accessed in anyweb browser at ‘http://FQDN/nagios3’ using default logincredentials. Since Nagios has to be interfaced with RTin proposed network monitoring and management system,the RT contact should be defined in ‘contacts nagios.cfg’.The following is definition of RT contact:

de f i n e contact {contact name RT

7

Figure 7: Creating and configuring queue in RT.

Figure 8: Assigning user rights to the created queue.

8

a l i a s Request−Trackers e r v i c e n o t i f i c a t i o n p e r i o d 24x7h o s t n o t i f i c a t i o n p e r i o d 24x7s e r v i c e n o t i f i c a t i o n o p t i o n s c ,w, r , uh o s t n o t i f i c a t i o n o p t i o n s r , ds e rv i c e no t i f i c a t i on commands not i fy−s e r v i c e−by−emai lhos t not i f i ca t ion commands not i fy−host−by−emai lemai l rt@host .FQDN}

Additional contacts can also be defined based on the re-quirement. Nagios will inform the contacts when the stateof a network device changes. In the above contact def-inition, Nagios will send notifications to ‘rt@host.FQDN’which will generate tickets in RT about problematic/faultynetwork devices. Once all the contacts are defined, a con-tact group is created which contains all the contact names.

de f i n e contactgroup {contactgroup name Network−adminsa l i a s Network and Nagios adminsmembers RT, other−contac t s}

Once all the configurations are completed, the Nagiosshould be restarted for configurations to take effect.

# / etc / i n i t . d/ nag ios3 r e s t a r t

4.3. Formation of Network Topology in Nagios

Since Nagios is performing the network monitoring func-tionalities, complete network topology needs to be pro-grammed (as shown in Fig. 9(a)). Note, Nagios topol-ogy consists of devices which are directly accessible fromuniversity ISP. In complex large-size networks, deviceshave normally parent child relationships. Thus, parentdevices should be specified for each device in Nagios. Aseparate configuration file should be created in ‘/etc/na-gios3/conf.d/’ directory for each network device and hasthe following generalized definition:

de f i n e host {use gener i c−hosthost name DeviceNamea l i a s Dev iceAl ia saddress [ Device ’ s IP Address ]parents [ Device ’ s parent i f any ]}

After defining all of the devices in network topology, agroup should be defined in ‘hostgroups nagios2.cfg’ thatcontains all relevant devices as its members. Multiplegroups may be defined with specified members based onthe type of devices and organization needs. The basic def-inition of a group is as follows:

de f i n e hostgroup {hostgroup name GroupNamea l i a s GroupAliasmembers Device1 , Device2 , . . .}

4.4. Defining Monitoring Services for Network Devices

Once network devices and groups are defined, the mon-itoring services can be applied on them. Based on theorganization, Nagios may monitor services such as ICMPPING, HTTP, SSH, etc on devices in defined groups. Na-gios monitors not only the devices but also services. It isalso possible that some services on a device are up/run-ning while the others are down. The basic definition ofICMP PING service (in ‘services nagios2.cfg’) on networkdevices is as follows:

de f i n e s e r v i c e {hostgroup name GroupName , other−groupss e r v i c e d e s c r i p t i o n PINGcheck command check ping !100.0 ,20%!500.0 ,60%use gener i c−s e r v i c en o t i f i c a t i o n i n t e r v a l 0 ; f o r re−no t i f i c a t i o n , s e t > 0}

After defining services, restart the Nagios for configura-tions to take effect.

# / etc / i n i t . d/ nag ios3 r e s t a r t

4.5. Interfacing RT with Nagios

Following the installation and configuration of RT andNagios, they should be properly integrated or interfacedtogether. Nagios will perform the network monitoringtask whereas RT will be used for management activities.Whenever a network device becomes unreachable or recov-ers back, Nagios sends out a notification which generatesa ticket in the specified queue in RT. The ticket can beassigned to different administrative persons based on theiravailability to resolve the network issue.

An important component in interfacing RT with Na-gios is ‘rt-mailgate’. Thus, an alias should be created in‘aliases’ using the following:

r t : ‘ ‘ | rt−mai lgate −−queue ‘RT Queue Name’−−ac t i on correspond −−u r l http ://FQDN/ r t ”

rt−comment : ‘ ‘ | rt−mai lgate −−queue ‘RT Queue Name’−−ac t i on comment −−u r l http ://FQDN/ r t ”

These configurations will direct Nagios notifications tothe specified queue in RT. It is necessary that the nameof queue should exactly match the queue created in RT.Further, created users and groups in RT should have ap-propriate rights to own, modify, delete or forward tickets.

4.6. UPnP Client for Network Devices in Labs and Offices

The UPnP based software tools are developed for moni-toring of network devices which are not directly accessiblefrom university/organization ISP e.g., certain subnets inclasses, laboratories, offices, etc. The design of basic soft-ware package is depicted in Fig. 6 where detailed archi-tectures of UPnP control point and controlled device areshown in Fig. 4 and Fig. 5, respectively. The UPnP clientsoftware for network end-user devices was developed inLinux operating system using standard C/C++ program-ming language. For ease in the implementation, libupnpand boost libraries were used. The libupnp is open-sourcelibraries for implementation of UPnP features which are

9

compliant with UPnP device architecture v1.0. While theboost libraries make easier the implementation of network-ing tasks. A kernel module was also developed in C pro-gramming language that tracks changes in the operationalstate of device. The role of kernel module is very im-portant in understanding why a network device becameunreachable. The developed kernel module can effectivelydetects if the device received sleep or shutdown instructionor if its battery is low or if the network or power cable isdisconnected. It immediately notifies the UPnP monitor-ing server on gateway device (i.e., switch/router) which inturn sends email notification to network administrator.

4.7. UPnP Monitoring Server for Gateway Devices inLabs and Offices

The UPnP monitoring server was also developed inLinux operating system using standard C/C++ program-ming language along with libupnp and boost libraries. Itimplements monitoring functionalities and a mail client tosend email notifications to network administrator. TheUPnP enables monitoring server on gateway devices (e.g.,switches, routers) to seamlessly and automatically discovernetwork end-user devices and track their operational sta-tus through kernel module on them. It is worth to mentionthat each network device has a subscription expiry time atthe monitoring server. If a network device stops function-ing due to unknown reasons and could not notify monitor-ing server, the monitoring server will ultimately know itupon the expiry of its UPnP subscription period. Thus,the whole monitoring process works autonomously andseamlessly without requiring any specific attention fromthe user.

5. Evaluation of Proposed System

The proposed network monitoring and management sys-tem is applicable for any large size organization. How-ever, experimental evaluations were performed consider-ing a complex large-size university network. Fig. 9(a) de-picts network topology programmed in Nagios. It assumesthat all these devices are network switches or routers orother devices which are directly accessible from the uni-versity ISP. For experimentation purpose, CISCO switcheswith the support of SNMP were used. These switches canbe manually configured and services (e.g., ICMP PING,SNMP, SSH, etc) can be enabled on them. At present,experiments are based on ICMP PING service which is en-abled on all devices in network topology. Fig. 9(a) depictsthat university network consists of four campuses whereeach campus consists of five departments (i.e., civil, com-puter, electrical, mechanical and software engineering de-partments). These departments in Fig. 9(a) are entry levelrouters or switches. Each department can have differentprivate sub-networks which can be classrooms, laborato-ries and offices. Fig. 9(a) depicts that all switches/routersare up and running except Lab1873 and Lab4521.

Nagios was configured with 10 seconds interval to probepresence of network devices. It declares a device in ‘softerror state’ when unreachable in the first attempt. Nagioswas also configured with 10 total failed attempts beforedeclaring a device in ‘hard error state’. To verify the cor-rect functioning, two CISCO switches (i.e., Lab1873 andLab4521) were made unavailable (either by disconnectingnetwork cable or unplugging switch power supply). Nagioswas working correctly and declared both switches ‘down’as can be observed in Fig. 9(a). The configured probeinterval (i.e., 10 seconds) should be chosen based on therequirement of organization. It is worth to mention that itis directly linked with monitoring system traffic overhead.The repeated attempts (i.e., 10 attempts) before declaringa device in ‘hard error state’ plays an important rule inpreventing false notifications due to packet loss or glitchin the network.

When Nagios declares a device as ‘down’, it sends outnotification that generates a ticket in RT. It can be ob-served in Fig. 9(b) that tickets were generated for bothdown switches (i.e., Lab1873 and Lab4521) in ‘UniversityNetwork Monitoring’ queue in RT. The network adminis-trator has pre-specified deadline of 1 hour to resolve theissue otherwise another notification is sent out to next re-sponsible person based on priority and so on. It is also pos-sible that a network administrator disowns the ticket if hefeels unable to resolve a specific network issue. Such ticketcan be owned by other users on RT based on their skillsand capabilities. It was also observed that Nagios sendsout notification when a faulty/unreachable device recoversback. To this aim, switch Lab2121 in computer engineer-ing department of campus-3 was made unreachable (i.e.,disconnected its network cable) and then its connectivityissue was resolved again. It can be observed in Fig. 9(b)that a ticket was also generated in RT based on the re-solve notification sent by Nagios. As specified in Section4.2, additional contacts can also be defined in Nagios whowill receive notifications based on specified state changese.g., a top level responsible person. Fig. 10 depicts emailnotification sent by Nagios to top level responsible personwhen switch Lab4521 (i.e., in electrical engineering depart-ment in city campus) recovers back. Nagios also providesdetailed device/host state information as depicted in Fig.11. It shows how long a device has been in its present state,is it soft state or hard state, time of last status check, anynotifications sent out, etc.

Experiments were also performed for developed UPnPbased software tools. For the sake of simplicity and avail-ability of equipment, the UPnP monitoring server was ex-ecuted on a low-power Raspberry Pi v2 and located insidethe local network. However, the monitoring server soft-ware is portable enough and can be easily cross-compiledfor embedded processors of network switches and routers.The UPnP zero-configuration, auto-discovery and seam-less networking features were also verified. As soon as anew device is attached to the network, the UPnP monitor-ing server immediately detects it and tracks its operational

10

(a)

(b)

Figure 9: Interaction between Nagios and RT: (a) Map of the network monitored by Nagios, (b) Tickets generated in RT when state of anynetwork device changes.

11

Figure 10: Email notification by Nagios when a network device is recovered and up again.

Figure 11: Host state information in Nagios.

status with the help of kernel module. All operations areautonomous without requiring any user attention or in-put. Further, the developed UPnP based tools are veryflexible and do not cause any interoperability or integra-tion issues between devices from different manufacturers.It was observed that the UPnP based monitoring systemis very scalable and also adopts to dynamic changes inthe network (e.g., new devices added or existing devicesdisconnected from the network).

To test the functionalities of UPnP monitoring server,a network device i.e., a PC was put into standby state.The kernel module in UPnP client software immediatelytracked it and notified to the UPnP monitoring server.Based on the configurations, the UPnP monitoring serversent out email notification to network administrator in-forming about the network problem. Similarly, a resolveemail notification was sent out when the network devicerecovered back and a message was received from its kernelmodule. The experimental tests were also successfully per-formed by disconnecting the network cable of a device. Inthis case, the UPnP monitoring server performed decisionsbased on subscription expiry (i.e., device is unreachable)and renewal (i.e., device has recovered and renewed its sub-scription). The UPnP based monitoring system provides

0

100

200

300

400

500

600

700

Discovery & Description

Steady State

Action Registration

Power State Notification

Device De-registration

0

50

100

150

200

250

300

Num

ber

of

Pack

ets

Avg

. Pack

et

Siz

e [

Byte

s]

Number of Packets Avg. Packet Size

Figure 12: Overhead analysis in terms of average packet size andnumber of packets exchanged during different UPnP events.

more flexibility as it is supported by plethora of hetero-geneous devices including PCs, printers, scanners, copiers,routers, switches, etc.

The communication overhead is normally consideredmost critical factor for network monitoring and manage-ment systems. High overhead may consume availablebandwidth and impair routine network operations. Thus,communication overhead was measured for the proposedUPnP based network monitoring system. The experimentlasted 12 minutes during which UPnP client on a networkdevice registered with UPnP monitoring server, registeredan action, notified its power/operational state, stayed inidle state and finally de-registered with UPnP monitoringserver. Fig. 12 depicts traffic overhead considering averagepacket size and total number of packets exchanged duringdifferent UPnP events. It was observed that most pack-ets were very small in size (i.e., periodic presence adver-tisements and subscription renewals during steady state).The infrequent packets which were exchanged during dis-covery/registration and de-registration phases were big insize due to carrying complete device description in XMLformat. Fig. 13 provides more clarity by depicting thetotal number of Bytes exchanged during different UPnPevents.

The communication overhead was also analyzed in termsof real-information inside each packet, additional overhead

12

0

10000

20000

30000

40000

50000

60000

70000

Discovery & Description

Steady State

Action Registration

Power State Notification

Device De-registration

Byte

s Exch

ang

ed

Figure 13: Overhead analysis in terms of total Bytes exchanged dur-ing different UPnP events.

0

2000

4000

6000

8000

10000

Device Advertisements

Device Registration

Action Registration

State Variable Update

Device De-registration

0

20

40

60

80

100

Byte

s

Com

munic

ati

on O

verh

ead [

%]

Real-Info [Bytes]Formatted Data [Bytes]Header + Formatted Data [Bytes]Communication Overhead [Bytes]Communication Overhead [%]

Figure 14: Overhead analysis in terms of percentage of real informa-tion and additional overhead Bytes inside packets during differentUPnP events.

due to XML formatting, additional overhead due to packetheaders and total overhead due to UPnP semantics. It canbe observed in Fig. 14 that device advertisement, registra-tion and de-registration generate significant overhead dueto exchange of multiple packets and download of completedevice and service descriptions. However, such packetsare very infrequent. During steady state, packets are verysmall in size and have less overhead Bytes. It can be ob-served that the UPnP overhead is not significantly highto impair routine network operations. This confirms thesuitability of proposed UPnP based monitoring system forlocal network devices.

The proposed monitoring system is expected to be apart of the organization’s network. Like existing devices,the additional devices and servers used by the monitor-ing system will also be protected by the organization’s ex-isting firewall, VPN or other security system. However,most organizations are vulnerable to insider attacks e.g.,a PC compromised by a malware installed through spearphishing email. The presence probe messages in proposedmonitoring system do not carry any critical device spe-cific information. Therefore, eavesdropping on such mes-sages does not raise any major privacy concern. Througheavesdropping, the attacker may identify that a monitor-ing system exists that probes presence of devices and ser-

vices. If such packets (e.g., ICMP PING, SNMP, etc) aredropped by the attacker, the proposed monitoring systemcan easily detect it as the specific device or service willbecome unreachable. This will trigger email notificationsfrom the monitoring server alerting network administra-tor about the issue. Note that such insider attack sce-narios are very rare in practice as organizations/industriesnormally have effective security system detecting and pre-venting cyber attacks. Thus, monitoring system does notneed a separate security mechanism but instead operatesunder the protection of an organization’s existing securitysystem.

6. Conclusions & Future Work

Network monitoring and management is always a chal-lenging task for large organizations with complex networktopology. It is tedious for network engineers/administra-tors to manually check the operational state of hundreds orpotentially thousands of devices in the network topology.Even, a network fault for few hours can cause significantfinancial loss to the organization along with the loss ofcustomers satisfaction. Many organizations still have com-plaint system where an employee/customer/client registersa complaint about network connectivity before the net-work administrators start troubleshooting. Network faultreporting, identification and fixing could become muchfaster with the design of an automatic network monitoringand management system.

This paper presented an automated network monitoringand management system that eases the responsibilities ofnetwork administrators with the goal of keeping serversand devices operational 24/7. The proposed system isintelligent enough to quickly identify faulty/problematicdevice, its location and impact on rest of the network. Itimmediately notifies the network administrator via emailas soon as a network problem arises. The proposed systemoffers portability, dynamic network scalability and doesnot cause interoperability and integration issues betweenplethora of heterogeneous devices from different manufac-turers. Further, all the monitoring functionalities are con-tinuous and automatic without requiring any specific inputor attention from the administrator. Further, the proposedsystem provides flexibility for network administrators. Ifthe administrator is busy and does not resolve networkfault/problem within pre-specified deadline, a new emailnotification is sent to the next responsible person in thepriority list and so on. The unique features and their ex-perimental validation prove the significance of proposednetwork monitoring and management system.

This paper addressed the proposed system for a largeuniversity network as a use case example. However, it isequally applicable for other organizations. In current im-plementations, the UPnP based monitoring software is notinterfaced/integrated with RT. Future work will focus onfurther improvement where each notification from UPnPbased monitoring system will generate a ticket in RT. This

13

will further increase the scope of proposed network moni-toring and management system.

References

[1] Y. Lu, Industry 4.0: A Survey on Technologies, Applicationsand Open Research Issues, in: Journal of Industrial InformationIntegration, Vol. 6, 2017, pp. 1–10.

[2] C. Issariyapat, P. Pongpaibool, S. Mongkolluksame, K. Meesub-lak, Using Nagios as a Groundwork for Developing a Better Net-work Monitoring System, in: 2012 Proceedings of PICMET ’12:Technology Management for Emerging Technologies, 2012, pp.2771–2777.

[3] A. G. Finogeev, A. A. Finogeev, Information Attacks and Secu-rity in Wireless Sensor Networks of Industrial SCADA Systems,in: Journal of Industrial Information Integration, Vol. 5, 2017,pp. 6–16.

[4] A. Kijazi, M. Kisangiri, Multifunctional Network MonitoringSystem using SMS, in: Science, Computing and Telecommu-nications (PACT), 2014 Pan African Conference on, 2014, pp.143–147. doi:10.1109/SCAT.2014.7055149.

[5] A. Mahajan, H. Joshi, S. Khajuria, A. Verma, ICMP, SNMP:Collaborative Approach to Network Discovery and Monitoring,in: International Journal of Smart Sensors and Ad Hoc Net-works, Vol. 1, 2012, pp. 8–12.

[6] Nagios - The Industry Standard In IT Infrastructure Monitor-ing, in: https://www.nagios.org.

[7] D. R. R. S. D. Chamberlain, R. Foley, J. Vincent, Rt essentials,in: Installation, Chap:2, pp.9-18, 2005.

[8] Universal Plug & Play (UPnP) - The Open Connectivity, in:https://openconnectivity.org.

[9] MRTG - The Multi Router Traffic Grapher, in:https://www.mrtg.com.

[10] M. Schubert, A. Hay, D. Bennett, et. al, Nagios3 EnterpriseNetwork Monitoring, in: Designing Configurations for LargeOrganizations, Chap:2, pp.25-84, 2008.

[11] M. Al-Mukhtar, S. Khalil, A System for an Enterprise RemoteNetwork Monitoring and Fault Management based on SMS andWAP, in: Wireless Communications and Applications (ICWCA2012), IET International Conference on, 2012, pp. 1–5. doi:

10.1049/cp.2012.2102.[12] M. A. A. bin Mohd Shuhaimi, Z. binti Zainal Abidin, I. binti

Roslan, S. binti Anawar, The New Services in Nagios: NetworkBandwidth Utility, Email Notification and SMS Alert in Im-proving the Network Performance, in: Information Assuranceand Security (IAS), 2011 7th International Conference on, 2011,pp. 86–91. doi:10.1109/ISIAS.2011.6122800.

[13] A. Rogozhkin, Deploying Nagios Monitoring Services on Se-cured Red Hat Enterprise Linux 3 Environment, in: GlobalInformation Assurance Certification Paper - SANS Institute,2005.

[14] C. Zhai, Z. Zou, Q. Chen, L. Xu, L.-R. Zheng, H. Tenhunen,Delay-Aware and Reliability-Aware Contention-free MFTDMAProtocol for Automated RFID Monitoring in Industrial IoT, in:Journal of Industrial Information Integration, Vol. 3, 2016, pp.8–19.

[15] S. Alyahya, Q. Wang, N. Bennett, Application and Integrationof an RFID-enabled Warehousing Management System A Fea-sibility Study, in: Journal of Industrial Information Integration,Vol. 4, 2016, pp. 15–25.

[16] M. Bhamare, T. Malshikare, R. Salunke, P. Waghmare, GSMbased LAN Monitoring and Controlling, in: International Jour-nal of Modem Engineering Research, Vol. 2, 2012, pp. 387–389.

[17] R. Ciprian, B. Lehman, Modeling Effects of Relative Hu-midity, Moisture, and Extreme Environmental Conditions onPower Electronic Performance, in: 2009 IEEE Energy Con-version Congress and Exposition, 2009, pp. 1052–1059. doi:

10.1109/ECCE.2009.5316423.[18] R. Khan, S. U. Khan, R. Zaheer, M. I. Babar, An Efficient Net-

work Monitoring and Management System, in: International

Journal of Information and Electronics Engineering, Vol. 3,2013, pp. 122–126.

[19] K. Matsuura, Y. Seki, M. Sano, T. Ueta, Design and Imple-mentation of Organizational Authorization for a Network Mon-itoring System, in: 2014 Second International Symposium onComputing and Networking, 2014, pp. 605–607. doi:10.1109/

CANDAR.2014.70.[20] U. H. Rao, Challenges of Implementing Network Management

Solution, in: International Journal of Distributed and ParallelSystems, Vol. 2(5), 2011, pp. 67–76.

[21] R. Voicu, I. C. Legrand, C. Dobre, A Monitoring Framework forLarge Scale Networks, in: Intelligent Computer Communicationand Processing (ICCP), 2011 IEEE International Conferenceon, 2011, pp. 429–432. doi:10.1109/ICCP.2011.6047909.

[22] X. Chen, Y. Mao, Z. M. Mao, J. V. der Merwe, DECOR:DEClarative network management and OpeRation, in: ACMSIGCOMM Computer Communication Review, Vol. 40, 2010,pp. 61–66. doi:10.1145/1672308.1672321.

[23] A. Sinha, L. Sejwal, N. Kumar, A. Yadav, Implementation ofICMP based Network Management System for HeterogeneousNetworks, in: Computing for Sustainable Global Development(INDIACom), 2015 2nd International Conference on, 2015, pp.382–387.

[24] A. Cecil, A Summary of Network Traffic Monitoring and Analy-sis Techniques, in: Washington University in St. Louis, ProjectReport.

[25] C. So-In, A Survey of Network Traffic Monitoring and AnalysisTools, in: Washington University in St. Louis, Project Report.

[26] X. Li, T. Jiang, Design and Implementation of the CampusNetwork Monitoring System, in: Electronics, Computer andApplications, 2014 IEEE Workshop on, 2014, pp. 117–119.doi:10.1109/IWECA.2014.6845571.

[27] X. Wang, L. Wang, B. Yu, G. Dong, Studies on Network Man-agement System Framework of Campus Network, in: Infor-matics in Control, Automation and Robotics (CAR), 2010 2ndInternational Asia Conference on, Vol. 2, 2010, pp. 285–289.doi:10.1109/CAR.2010.5456547.

[28] W. Kang, B. Sim, J. Kim, E. Paik, Y. Lee, A Network Moni-toring Tool for CCN, in: World Telecommunications Congress(WTC), 2012, 2012, pp. 1–3.

14