This page describes the components of the network monitoring infrastructure that has been deployed in the DORII project, by installing and configuring a number of publicly available monitoring tools and developing a unique monitoring interface. This page provides some guidelines concerning:

• the installation and configuration of the Smokeping monitor components
• the installation and configuration of the Pathload client-server monitor
• the installation and configuration of the SNMP agent
• the configuration of Nagios monitoring tools

Following the instruction on the SmokePing web site there are a lot of prerequisites: most of them are already available in RPM format. So, the following packets should be installed using YUM

• rrdtool
• perl-rrdtool
• fping
• echoping
• curl

The packets for dig and ssh should be already installed by default.

Concerning the Perl modules, the related packages are:

• perl-libwww-perl
• perl-Net-Telnet
• perl-Net-DNS
• perl-LDAP
• perl-IO-Socket-SSL
• perl-RADIUS

SpeedyCGI is contained in perl-CGI-SpeedyCGI packet. Finally, Perl and Apache webserver should be already on the machine by default.

Smokeping can be used in Master-Slave (gathering all the data in a central server) mode or as a stand alone instance (useful for test or in case the M/S mode is not working)

Master-Slave mode is described here and the configuration is very easy, since the configuration file does not need any tweaking, it is downloaded from the Master host. So:

• Download and unpack the SmokePing archive, for example in /opt/smokeping.
• Put the provided password in the file <smokeping_dir>/etc/smokeping/config.d/slavesecrets.conf or /etc/smokeping/slavesecrets.conf.
• The owner of the file should be the unprivileged user running Smokeping.
• The permission flags should be changed in -rw——- (chmod 0600).
• Laungh Smokeping with the following command:

<smokeping_dir>/bin/smokeping --master-url=http://monitor2.cnit.it/cgi-bin/smokeping.cgi 
--cache-dir=/var/lib/smokeping/ --shared-secret=<smokeping_dir>/etc/smokeping/slavesecrets.conf 
--slave-name=RemoteUserProbeName --debug-daemon

Some explanations about the options:

• –master-url is the host collecting all the data, http://monitor2.cnit.it/cgi-bin/smokeping.cgi;
• –cache-dir should point to an existing directory, owned by the user running Smokeping;
• –shared-secret should point to the file containing the Password;
• –slave-name is the name identifying the remote probe (your machine) and it is provided with the Password.

Once SmokePing archive is downloaded and unpacked (for example in /opt/smokeping-2.4.2, then renamed /opt/smokeping), as suggested by the original guide, some parameter tweaking is needed:

• the main executable, <smokeping_dir>/bin/smokeping should be renamed, removing the “.dist” and edited. Check that the first line is pointing to perl. The first “use lib” statement should point to the directory containing RRDtool, in particular the RRDs.pm file. In my case the right directory is /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi. The second “use lib” statement should point to the lib directory of smokeping, for example /opt/smokeping/lib. Finally, fix the Smokeping::main argument on the basis of your installation, for example /opt/smokeping/etc/config, so it is not necessary to specify the configuration file each time SmokePing is launched.
• The CGI component in <smokeping_dir>/htdocs/, for instance smokeping.cgi.dist, should be renamed too in order to remove “.dist” and then edited. Check that the first line corresponds to the SpeedyCGI executable and replace the two “use lib” statements as in the previous file (<smokeping_dir>/bin/smokeping). Finally, move smokeping.cgi in the CGI directory of the web server, /var/www/cgi-bin by default.
• <smokeping_dir>/htdocs/cropper directory should be moved in the DocumentRoot of the webserver, /var/www/html by default.
• In <smokeping_dir>/etc/config, owner, contact and mailhost parameter should be adjusted to reflect the name of the Smokeping site administrator, her/his mail address and mailhost. “imgcache” parameter should point to a directory in the web server DocumentRoot, for example /var/www/html/smokeping/cache. If necessary create it and the owner should be the user under wich the web server is run (apache for the Apache web server). The parameter “imgurl” points to the previous directory, but it is a URL, so, according to the previous example, it should be /smokeping/cache. “datadir” is the directory where Smokeping stores its files, for example “/var/lib/smokeping”. If necessary the directory should be created and owned by the unprivileged user running Smokeping. “cgiurl” is the URL for smokeping.cgi, so in a default Apache installation, http://<your_host>/cgi-bin/smokeping.cgi. There are other three variables to update: “piddir”, “smokemail” and “tmail”. The first one could be /var/run/smokeping, while for the other two it is necessary to add the complete path to the Smokeping installation directory. Finally, there are target hosts to add: refer to the following file for the complete list. Here you can find also the definitions for alerts, probes and the presentation of the web page. Adapt the related sessions (*** Alerts ***, *** Database ***, *** Presentation ***, *** Probes *** and *** Targets ***) according to your configuration file. There is also a new template for the Smokeping web page with the project logo. For example, unizp the file in the Smokeping directory on the web server DocumentRoot, /var/www/html/smokeping and modify the “template” entry in the configuration file in order to point to the new file (/var/www/html/smokeping/basepage.html).
• In the basepage.html (in <smokeping_dir>/etc or in <DocumentRoot>/smokeping) template, the links to content of “cropper” directory should be updated. We are dealing with URLs, so something like “/cropper/lib/prototypes.js” and so on should be fine.

Now you can try your brand new Smokeping installation going back to the official guide.

TODO

• Shell script to start and kill Smokeping from the init.d interface.

Pathload is a tool to estimate the available bandwidth of a network path. The basic idea behind Pathload is that the one-way delays of a periodic packet stream show an increasing trend when the stream rate is larger than the available bandwidth The measurement algorithm is iterative and requires the cooperation of both the sender and the receiver. Pathload is non-intrusive, meaning that it does not cause significant increases in the network utilization, delays, or losses. The tool has been verified experimentally, by comparing its results with SNMP utilization data from the path routers.

1. Download the package including pathload and ad-hoc scripts developed for DORII from here
2. Execute the command: tar zxvf dorii-pathload_v2.2.tar.gz
3. Go into the directory dorii-pathload_v2.1 and launch install.sh

DORII application sites (EUCENTRE, OGS, ELETTRA, UC, ECO-CdP) act as pathload_receiver and export results at CNIT Monitoring Platform by using Lynx Web Client (Check if you have it installed), whereas DORII sites hosting CE and SE (PSNC, GRNET, ELETTRA, CSIC-IFCA) are required to run pathload_sender.

1. To run the receiver, use the command: start_monitor_rcv.sh [EUCENTRE|OGS|ELETTRA|UC|ECO-CdP] & specifying the name of your site.
2. To run the sender, use the command: start_monitor_snd.sh &

If a firewall is present, it is necessary to open some destination and source ports. Please, take into account that Pathload is a client-server application that exchange data through:

• a TCP control channel (port 55002)
• a UDP data channel (port 55001)

The sender listens on port 55002, and data are sent to the UDP 55001 destination port For sake of clarity, the following figure shows how pathload works with two receivers and one sender. Data are reported to data collector at CNIT (monitor2.cnit.it). The type of traffic flows and the TCP/UDP ports are highlighted.

Various applications exist to collect and consolidate network usage information. At a basic level, these applications (also called manager) use SNMP (Simple Network Management Protocol) to read statistics from each monitored device (router or host) where an SNMP agent is configured and running. A standard Management Information Base (MIB) collects counters of the number of datagrams and bytes sent and received on each interface of a router and also gives the number of packets discarded because of congestion. An SNMP application can periodically poll each router and each device and covert the returned information into a view of usage across the whole network. SNMP can also help identify network interface failures or outage conditions. SNMP has been enabled on CEs, SEs and IEs interfaces.

The procedure and the commands to enable SNMP are strictly dependent on the operating system (OS) running on the device under consideration. For Linux-like OSs, the following steps are necessary:

1. Install snmpd (usually is already installed by default)
2. Configure snmpd (etc/snmpd.conf) with the following parameters:
   1. Read-only (with interface and variables restrictions, if required)
   2. Community name: dorii
   3. Access control: Management Station (130.251.19.6)

Possible issues that could prevent SNMP from properly working are the following

• snmpd listens on the loopback interface by default
• Firewall configuration: SNMP Port (162) must be open.
• The SNMP configuration file is Ietc/snmpd.conf/

You can download the SNMP configuration file for Linux systems from here

A Nagiosserver was installed at CNIT (Savona) and at GRNET to monitor every resourcs (Gateways, CEs, IEs, SEs) belonging to to DORII infrastructure. PING is used to check if every grid resource is up and running. Nagios is designed to allow plugins to return optional performance data in addition to normal status data, as well as to allow one to pass those performance data to external applications for processing. Normally, plugins return a single line of text that indicates the status of some type of measurable data. Nagiosgrapher is a Graphing System that collects the output of Nagios Plugins to generate graphs. When we use check_ping plugin, it generates some information that is saved in a RRD database. Nagiosgrapher takes this information and generates PING graphs of every DORII resources. Since Nagios polls the nodes using the SNMP protocol, the install of the SNMP agent (e.g., net-snmp package) is required.