| Table of Contents |
|---|
Introduction
It is essential that certain prerequisites are met before you use this document to configure Protocol Validation . Refer to the Implementation Guide for the correct process flow.
By following the flow chart you will have all the information required, and the work will be completed in the correct order so that work won’t have to be repeated and tests run at the time will be relevant.
Prerequisite
This document makes frequent use of data contained in the Technical Requirements document.
All relevant sections of the Technical Requirements document must be completed before commencing with the steps in this document.
Configuration
Protocol Validation is setup in VSM to provide assurance that an application is operational. It goes a step beyond ping tests, which essentially verify that a server is reachable on the network, and that its OS and NIC are functioning.
This can be the case when a service or application has stopped. When used in concert with ping tests, Protocol Validation provides an enhanced view of application availability.
Protocol Validation monitoring can be used to monitor most common protocols including HTTP, HTTPS, SIP OPTIONS, SSH, and RawSocket TCP, and raise an alarm if the service running on that protocol becomes unresponsive or returns an error. Most commonly, this is used to check whether a website is running. Other examples include monitoring connectivity to a server via SSH, or a Raw TCP socket where standard protocols are not supported.
Once configured Protocol Validation can be used to calculate 7 day and 30 day available, and provided a full history of service uptime and availability going back to 30 days. This is available on the Protocol Validation page under Service Desk
1.To add a Protocol Validation test to VSM, select the customer you wish to add the test for, then navigate to Service Desk> Equipment Locations:
2. Next, right-click on the equipment Equipment Location you want to add a Protocol Validation for. Go down to Network> Protocol Validation Configuration:
3. To create a new Protocol Validation, click "Add Protocol Validation":
4. Populate the form with details of the Protocol Validation test you are adding. Refer to the table below.
Configuration Table:
| Anchor | ||||
|---|---|---|---|---|
|
| Field | Description | Restrictions |
|---|---|---|
| Type | This is the protocol to be validated. | |
| Details | ||
| Alarm Name (Auto-filled) | If the protocol validation fails, e.g. the service becomes unavailable, this will be the name of the alarm raised. | |
| Name | A description of the protocol validation, which will also be shown in the alarm details, and on the protocol validation availability page. | |
| Site | Free text used to identify the site. Can be blank | |
| Criteria | ||
| Address | The target address, can be a DNS name, or IP Address. For example: www.mywebsite.com:8080/firstpage/secondpage | For SIP OPTIONS, SIP URI is also supported |
| Port | The port the service runs on. If left blank, the default port for that protocol will be used. Default ports: 80 = HTTP 443 = HTTPS 25 = SMTP 22 = SSH 23 = Telnet Undefined = Raw TCP Socket | |
| Poll Frequency (mins) | The frequency of the protocol validation is tested, in minutes. Valid values are 1 – 1440. We recommend setting this to 2 minutes, for immediate results on failure. | |
| Validation | Specifies whether the address is accessed internally within the intranet, or externally via a public-facing IP Address. For public websites, this should be set to External. Note: It is not possible to test an external validation. | |
| Additional Configuration options | ||
| Ignore Certificate Errors | For HTTPS a security certificate needs to be installed on the target equipment. Sometimes, this cannot be verified, resulting in browsers displaying a warning instead of loading the page. If this is the expected response for the site, click 'Ignore Certificate Errors' | HTTPS only |
| Override Failed Responses | To customize the default behaviour and classify failure responses as a success, list the specific response codes as a comma separated input in the field below. For example, to ignore authentication errors, add: 401, 407. | SIP OPTIONS only |
| SIP Proxy Address | This is the SIP Proxy address and is an IP Address. SIP Proxy, sometimes also called SIP Server, or SIP Proxy server facilitates the communication between two SIP addresses. It is the go-between two SIP devices allowing them to set up communication, and drops out once established allowing point to point communication. | SIP OPTIONS only |
| SIP Proxy Port | This is the port used by the SIP proxy. It is typically 5060 for non-encrypted signalling traffic, or 5061 for encrypted traffic, encrypted with Transport Layer Security (TLS). If left blank, the default 5060 will be used. | SIP OPTIONS only |
| SIP Protocol | This is the protocol used by the target SIP client. SIP clients typically use TCP or UDP for encrypted SIP traffic to servers and other endpoints. If SIP Proxy Port is 5061, specify TLS. | SIP OPTIONS only |
| Username | The username to log on to the target address with. | SSH, Telnet and SIP Options |
| Password | The password to log on to the target address with | SSH, Telnet and SIP Options |
Test Configuration
To check that the Protocol Validation is working press the “Test” button when all mandatory fields have been entered.
Once the Protocol Validation test is working, click “Add” and the Protocol Validation Test will be saved in VSM. If not, troubleshoot by checking that all fields have been entered correctly.
Results
Once Configured protocol validation results typically start working after a few minutes. The following colour bars are used
- Green: A successful connection with successful Response Code
- Red: A failed response code was returnedRed: A failed response code was returned, either because the target was unreachable, or the service running on that protocol was responding with an error. And alarm will be raisedThis will raise an alarm.
- Black: Internal error. Contact your system administrator.
...