FAQ
Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform

English

Türkçe

English

Türkçe

Appearance

Advanced

How do I health check UDP services other than DNS (UDP scenario, Hex/Base64/text)? ​

Short answer

UDP is selected in the Check Type field and UDP Scenario is turned on. The scenario consists of steps that run in order: Send data (the data in Text, Hexadecimal or Base64 format), Wait(ms), Expect text and Expect regex. In this way, a request suitable for its protocol is sent to the service and the response is verified. A UDP check without a scenario sends an empty packet and does not wait for a response; it does not verify that the service is really running.

Problem: There Is No Connection in UDP, It Is Not Clear Whether the Service Is Running ​

UDP is a connectionless protocol: a packet receiving no response can mean both that the service is not running and that the packet was lost; since no connection can be established, a port check cannot be performed either. To understand whether services such as Syslog, NTP, RADIUS and game servers are really running, it is necessary to send a request suitable for the protocol and wait for the response.

Solution ​

The UDP scenario sends the service a request suitable for its protocol and searches for the expected text or pattern in its response. The scenario steps are defined from the interface.

UDP Scenario ​

  • How it works The steps run in order; the incoming responses are accumulated. If the expected text or pattern is not found in the response (the wait lasts at most the Timeout, and at most 5 seconds) or no response arrives at all, the check fails.
  • Where it is openedLoad Balancer → Profiles → Health Checks → Add → Check Type: UDP → UDP Scenario
  • Requirement The service responding to a request; a Backend Service to which the profile will be assigned
  • vService type All; UDP traffic is balanced on the Network vService (UDP - L4), and the health status is reflected in the distribution while Port Range is off

Step-by-Step Configuration ​

1
Adım 1 Open the Health Checks screen

The Configuration Menu is opened with the TR7 logo at the bottom left; the Load Balancer → Profiles → Health Checks path is followed and Add is clicked (How to add?).

2
Adım 2 Enter the name and type

Name is entered; UDP is selected in the Check Type field.

3
Adım 3 Turn on the scenario

The UDP Scenario switch is turned on; the first step card is added.

4
Adım 4 Define the data to send

In the card, UDP Action (1) = Send Data is selected; the request is written in the Data to Send field and Data Format is selected: Text (default), Hexadecimal or Base64. In Hexadecimal, spaces can be left between the bytes (e.g. DE AD BE EF); a non-hexadecimal character makes the check fail.

5
Adım 5 Define the expected response

A new card is added; UDP Action (2) = Expect Text is selected and the text that must occur in the response is written in the Text to Expect field (case-sensitive), or Expect Regex is selected and the pattern is written in the Regex to Expect field (case-insensitive). If needed, Wait(ms) is added between the steps (Wait Time (ms), at least 1).

6
Adım 6 Save the profile

The Add button is clicked.

7
Adım 7 Open the Backend Service form

The Load Balancer → Backend Services path is followed; the Backend Service is right-clicked and Edit is selected.

8
Adım 8 Select the profile

The profile is selected in the Health Check field.

9
Adım 9 Save

The Edit button is clicked. In a cluster, the change is transferred to the peer device automatically by default; if Manual Sync Mode is on, it is sent with Synchronize.

Verification ​

1Health statusBackend Services list

The indicator in the Health column of the Backend Services list is checked (Health status indicator); when the service is stopped, it becomes Error after Required failures consecutive failures.

ExpectedOK (green)

Common Mistakes ​

  • Considering a UDP check without a scenario sufficient. An empty packet is sent and no response is waited for; even if the service crashes, the server can appear healthy.
  • Expecting a binary response as hex. The expected response is searched for as text; for binary responses, a readable part of the response or Expect regex is used.
  • Entering invalid hex. Non-hexadecimal characters make the check fail.
  • Keeping the Timeout too short. The Expect step waits for the response for at most the Timeout (at most 5 seconds).

How it is done in the documentation

Related questions