
Standard Network Plugins
One of the basic roles of a plugin is to monitor local or remote hosts and verify if they are working correctly. There is a choice of generic plugins to accomplish this task.
Standard networking plugins allow hosts to be monitored using ICMP ECHO (ping: refer to http://en.wikipedia.org/wiki/Ping). This is used to determine whether a computer is responding to IP requests. It is also used to measure the time that a machine takes to respond, and how many packages are lost during the communication. These plugins also try to connect to certain TCP/UDP ports. This is used to communicate with various network based services to make sure that they are working properly, and respond within a defined amount of time.
Checking If a Host is Alive
Checking if a host is alive is a basic test that should be performed for all remote machines. Nagios offers a command that is commonly used for checking if a host is alive and plugged into the network. The syntax of the plugin is as follows:
check_ping -H <host_address> -w <wrta>,<wpl>% -c <crta>,<cpl>% [-p packets] [-t timeout] [-4|-6]
This command accepts the standard options described above, as well as the following nonstandard options:

RTA means Round Trip Average, and is the average time taken in milliseconds for the package to return. PKTLOSS is Packet Loss, which is the maximum percentage of packages that can be lost during communication. For example, a value of 100, 20% means that a ping must return within 0.1 seconds on average, and at least 4 out of 5 packages have to come back.
A sample command definition for checking if a host is alive is:
define command { command_name check-host-alive command_line $USER1$/check_ping -H $HOSTADDRESS$ -w 3000.0,80% -c 5000.0,100% -p 5 }
Testing Connectivity over TCP and UDP
In many cases, Nagios is used to monitor services that work over the network. For checking if a service is working properly, it is necessary to make sure that a certain TCP or UDP port is accessible over the network. For example, Microsoft SQL Server listens on TCP port 1433. In many cases, it is enough to simply run generic plugins that check whether a service is available on a specified TCP or UDP port. However, it is recommended that you run specialized plugins for various services such as web or email servers, as these commands also try basic communication with the server and/or measure response time.
Internally, as this command is also handling many other checks, the syntax is almost the same. It is designed so that, it behaves slightly differently based on the name it is called with. Many other plugins are symbolic links to check_tcp
. The check_tcp
plugin is mainly intended to test services that do not have a corresponding Nagios check
command. The second command, check_udp
is also a symbolic link to check_tcp
and differs only by communicating over UDP instead of TCP. Its syntax is as follows:
check_tcp|check_udp -H host -p port [-w <warning >] [-c <critical >] [-s <send string>] [-e <expect string>] [-q <quit string>] [-A] [-m <maximum bytes>] [-d <delay>] [-t <timeout>] [-r <refuse state>] [-M <mismatch state>] [-v] [-4|-6] [-j] [-D <days to cert expiry>] [-S] [-E]
These commands accept several nonstandard options as follows:

An example, to verify whether VMware server 1.x is listening for connections, is as follows:
define command { command_name check_vmware command_line $USER1$/check_tcp -H $HOSTADDRESS$ -p 902 –e "220 VMware" }
For UDP, the following is an example command definition to verify if the OpenVPN server is listening on UDP port 1142:
define command { command_name check_openvpn command_line $USER1$/check_udp -H $HOSTADDRESS$ -p 1142 }