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.
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:
Next, right-click on the equipment you want to add a Protocol Validation for. Go down to Network> Protocol Validation Configuration:
To create a new Protocol Validation, click "Add Protocol Validation":
Populate the form with details of the Protocol Validation test you are adding. Refer to the table below.
Configuration Table:
Field | Description | |
---|---|---|
Type | This is the protocol to be validated | |
Details | ||
Alarm Name | If the protocol validation fails, that is the service becomes unavailable, this will be the name of the alarm raised | |
Name | The name of the validation, for example, Marketing Website. This will appear in the alarm details, and on the protocol validation availability page. | |
Site | The Site associated with the target. Can be blank | |
Criteria | ||
Address | The target address, can be a DNS name, or IP Address. | 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, for example 80 for HTTP, and 22 for SSH | |
Poll Frequency | The frequency to poll the validation. We recommend setting this to 2 minutes, for immediate results on failure. | |
Validation | This 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. | |
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 |
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 ssh user name to log on to the target address with | SSH only |
Password | The ssh password to log on to the target address with | SSH only |