Pandora cisco ipsla

The main objective of this document is to describe the monitoring procedures using the ipsla tool and the use of the SNMP protocol.
tool and the use of the SNMP protocol.

Introduction
Compatibility matrix
Modules generated by the plugin
Pre requisites
Parameters
Configuration of the plugin in a Pandora FMS Agent
Configuration of the plugin in a Pandora FMS Server
APPENDIX IP SLA and SNMP Configuration on a Cisco Router
Manual execution

Introduction

The main objective of this document is to describe the monitoring procedures using the ipsla tool and the use of the SNMP protocol.

To extract the information this plugin uses:

- System specific commands without the need to install additional libraries.
- Pandora FMS agent (in case of using a Pandora FMS agent to extract information).
- Snmpwalk and snmpget to obtain the information.

Compatibility matrix

The compatibility matrix for the Cisco IPSLA plugin is as follows:

Devices where it has been tested	Cisco c7200 Routers
Devices where it should work	All cisco type devices with ipsla support capability

Modules generated by the plugin

This plugin can return up to 26 values (modules) for each IP SLA monitor, using the unique denominator of that monitor set on the Cisco device. The available monitors will vary depending on the specific configuration of your device. The monitors used during the development of the plugin are as follows:

- Jitter - A metric that allows you to analyze the variation in packet send and receive delay.

- Echo - The ICMP echo operation monitors the end-to-end response time between a Cisco router and network elements or IP hosts. This response time is calculated by measuring the time between sending an ICMP echo request message to the destination and receiving the ICMP echo response.
ICMP echo response is received.

- Pathecho - The ICMP path echo operation collects statistics for each hop along the path until it reaches its destination. The ICMP path echo operation determines this hop-by-hop response time between a Cisco router and any IP device on the network by discovering the trace with the traceroute tool. As a result, the round-trip delay for the entire path is displayed.

- Udpecho - The results of a UDP echo operation can be useful both for troubleshooting critical applications by testing connectivity on Cisco and non-Cisco devices, as well as for determining round-trip delay times.
round-trip delay times.

- Dlsw - Operation to measure the protocol queue and response time between dlsw. v peers and the IP address of the peer.

- Tcpconnect - This operation allows to monitor the connection status with machines with specific applications that use the TCP protocol.

- http - This operation allows to evaluate the status of the server by measuring the response time between the request from the source machine and the loading of the web page.

- ftp - Allows to monitor the time delay between the request and the download of a file from an FTP server.

- Dhcp - Allows to measure the time between a request and the corresponding response from the dhcp server.

- DNS - Measures the time it takes for a name request to be answered by a DNS server.

- Voip - This operation allows to measure the delay in Voip communications in case of connections during calls and connections with gatekeepers.
The following are the modules that we can collect from each of the above values.
above:

-ICPIF - Factor calculated from the metrics obtained to measure voice quality.
-MOS - Factor that allows to measure the voice quality.
-Packet_Out_of_Sequence - Packets received out of sequence.
-Packet_Late_Arrival - Packets received with delay.
-Average_Jitter - The estimated value of the average jitter observed in the last XX RTP packets.
-PacketLossSD - Packet loss from source to destination.
-PacketLossDS - Packet loss from destination to source.
-PacketLost - Loss of packets whose address is impossible to determine.
-NegativesSD - Sum of the value of all negative jitter values of packets sent from source to destination.
-NegativesDS - Sum of the value of all negative jitter values of packets sent from destination to source.
- PositivesDS - Sum of the value of all positive jitter values of packets sent from source to destination.
- PositivesDS - Sum of the value of all positive jitter values of packets sent from destination to source.
-RTTMax - Maximum packet bend offset time.
-RTTMin - Minimum packet round trip time.
-OperNumOfRTT - Number of successful bent type shifts.
-OperPacketLossSD - Packet loss from source to destination for jitter tests.
-OperPacketLossDS - Packet loss from destination to source for jitter type tests.
-RttOperSense - Code indicating the status of the last RTT type operation.
-RttOperCompletionTime - Time taken for the last RTT operation to complete successfully.
-RttOperTime - System time at the time of the last RTT operation.
-RttOperAddress - Specifies the destination address for the RTT operation.
-HTTPOperRTT - Time required to complete the HTTP operation.
- HTTPOperDNSRTT - Time required to complete the DNS query within the HTTP operation.
-HTTPOperTCPConnectRTT - Time required to connect to the HTTP server.
-IcmpJitterAvgJitter - Average value of positive and negative jitter type values.
-HTTPOperTransactionRTT - Time required to download the object specified by the URL.

Pre requisites

The monitoring of IPSLA metrics using the SNMP protocol is based on three essential requirements:

- To have IPSLA enabled in the device to be monitored.
- To have a Pandora FMS agent in the system.
- To have the snmp server enabled in the device to be monitored.

Parameters

By executing the plugin you can access the help menu, where you can see the following parameters:

-c <community> -t <target> -v <version> [other options]

		-c community
		-t target
		-v version
Other options

		-s show defined tags and indexes
		-l <auth-type> 
		-u <user> 
		-a <authentication> 
		-A <authenticacion-password> 
		-x <encryption> 
		-X <encryption-pass> 
		-g <id> 
		-m <module>

Modules can be: 

	ICPIF - Calculated Planning Impairment Factor for specified tag
	MOS - Mean Opinion Score
	Packet_Out_of_Sequence - Packets arriving out of sequence 
	Packet_Late_Arrival - Packets arriving late
	vAerage_Jitter - Average jitter is the estimated average jitter observed in the last XX RTP packets
	PacketLossSD - Packet loss from source to destination
	PacketLossDS - Packet loss from destination to source
	PacketLost -  The number of packets that are lost for which we cannot determine the direction 
	NegativesSD  - The sum of number of all negative jitter values from packets sent from source to destination 
	NegativesDS  - The sum of number of all negative jitter values from packets sent from destination to source
	PositivesSD  - The sum of number of all positive jitter values from packets sent from source to destination
	PositivesDS  - The sum of number of all positive jitter values from packets sent from source to destination
	RTTMax  - Max Round Trip Time
	RTTMin  - Min Round Trip Time
	OperNumOfRTT - The number of successful round trips
	OperPacketLossSD - Packet loss from source to destination for jitter tests
	OperPacketLossDS - Packet loss from destination to source for jitter tests
	RttOperSense - A sense code for the completion status of the latest RTT operation.
	RttOperCompletionTime - The completion time of the latest RTT operation successfully completed.
	RttOperTime - The value of the agent system time at the time of the latest RTT operation.
	RttOperAddress - A string which specifies the address of the target.
	HTTPOperRTT - Round Trip Time taken to perform HTTP operation. This value is the sum of DNSRTT, TCPConnectRTT and TransactionRTT.
	HTTPOperDNSRTT Round Trip Time taken to perform DNS query within the HTTP operation.
	HTTPOperTCPConnectRTT - Round Trip Time taken to connect to the HTTP server.
	IcmpJitterAvgJitter The average of positive and negative jitter values in Source-to-Destionation and Destination-to-Source direction.
	HTTPOperTransactionRTT - Round Trip Time taken to download the object specified by the URL.

Configuration of the plugin in a Pandora FMS Agent

This plugin can work as an agent plugin, for which we need to download it and place it in a specific path. To deploy the plugin we need to edit the agent configuration file where we want to launch the modules and follow the following syntax:

module_begin
module_type generic_data
module_exec /path_plugin/pandora_ipsla.sh -t [ip] -c [community snmp] -g [id ipsla monitor] -m [module]
module_end

Example execution v1:

module_begin
module_name Jitter_ICPIF
module_type generic_data
module_plugin /home/artica/Descargas/pandora_ipsla.sh -t 192.168.70.131 -c public -v v1 -g 1 -m ICPIF
module_end

Example execution v3:

module_begin
module_name Jitter_ICPIF
module_type generic_data
module_plugin /home/artica/Descargas/pandora_ipsla.sh -t 192.168.70.131 -c public -v v3 -l authPriv -u juan -a MD5 -A pass1 -x AES -X pass2 -g 6 -m ICPIF
module_end

This example generates a module in the agent where it has been introduced, and its appearance is as follows
following:

Configuration of the plugin in a Pandora FMS Server

This plugin can work as a server plugin, for which we need to download it and place it in a specific path. To deploy the plugin we need to access the plugin administration section of the Pandora FMS console:

Click on Add and the following screen will appear:

We fill in the fields as follows:
-Name: Cisco IP SLA.
Add-on type: Standard.
-Max. Expiration time: 15 seconds.
-Description: This plugin extracts network performance information from the IPSLA tool by using the SNMP protocol.
-Plugin Command: /path_to_the_plugin/pandora_ipsla.sh
-Plugin parameters: -t _field1_ -c _field2_ -g _field3_ -m _field4_.

Next, we expand the available macros for the plugin to field 4 and in the corresponding Description sections we enter the following: Device address, SNMP Community, IPSLA monitor identifier, Value we want to get.

To create modules we need to access to the Module Management section of any agent and add a new type of module of plugin type. Then, in the following section we choose the IPSLA plugin and fill in the plugin data:

Si los datos son correctos deberíamos poder ver el siguiente resultado en la consola:

APPENDIX IP SLA and SNMP Configuration on a Cisco Router

To enable the simple network management protocol, the following steps can be followed within the shell of either router:

-Adopt the necessary permissions to be able to make changes in the router configuration, by typing: enable.
-Access to the configuration section, by typing: config terminal
-Activate the snmp server indicating the community for which the snmp queries will work: snmp-server community name

* You can replace "name" with the community name you want to use.

Before starting with the individual monitors we enable the IP SLA Responder which improves the accuracy and details of the monitoring. To do this we have to follow the steps below:

- We access the configuration section, typing: config terminal.

Translated with www.DeepL.com/Translator (free version)

Manual execution

List all available tags and ids

The -s parameter must be used.

./pandora_ipsla.sh -t <ip> -v <version> -l <security> -u <user> -a <auth> -A <password auth> -x <privacity> -X <privacity pass> -s

Now, seeing the available ids we will be able to execute the plugin calling the id associated to the tag and the module we want.

* By id we would understand the number that goes after the OID ".1.3.6.1.4.1.9.9.42.1.1.2.1.1.1.3." in the list that we receive when executing the -s parameter.

Manual execution:

./pandora_ipsla.sh -t <ip> -v <version> -l <security> -u <user> -a <auth> -A <password auth> -x <privacity> -X <privacity pass> -g <id> -m <modulo>