Alteon Health Check Configuration & Troubleshooting Guide

A server can answer ICMP while its web service is stopped or returning application errors. Radware Alteon health checks help determine whether a Real Server is available for Server Load Balancing (SLB). Choose a check that represents the service being offered. An unsuitable method can produce incorrect availability decisions and disrupt load-balanced traffic.

1. How Alteon health checks work

Alteon periodically tests Real Servers with the configured method and uses the result in service-availability decisions. Methods include ARP, ICMP, TCP, HTTP, SSL-based checks, and custom scripts. Availability and parameters depend on the AlteonOS release.

Health-check methods

Health Check Verification Method Limitation
ICMP Checks IP-level reachability. Does not validate application availability.
TCP Establishes a TCP connection. Does not verify application content.
SSLH Checks SSL handshake behavior. Does not validate an HTTP application response.
HTTP Evaluates an HTTP response. Requires appropriate request and response settings.
HTTPS Performs application-aware monitoring over HTTPS. Requires compatible TLS and HTTP settings.
Custom Script Validates a defined request and response. Requires protocol-compatible scripting.

A successful TCP connection does not verify application behavior. Use HTTP(S) response checks when the requirement includes application availability.

2. Example environment

The lab example uses documentation-only addresses and does not represent a production network.

Component Address Service
Alteon VIP 192.0.2.100 HTTPS / TCP 443
Real Server 1 192.0.2.11 HTTPS / TCP 443
Real Server 2 192.0.2.12 HTTPS / TCP 443
Application Hostname app.example.com Web Application
Health Check Path /health Application Status

Each Real Server must answer an HTTPS request to /health. The example assumes a lightweight endpoint that returns HTTP 200 when the required application components are operational.

3. Configuring HTTP(S) monitoring

Advanced Health Check can monitor a specific application path and evaluate its HTTP(S) response against configured criteria.

3.1 WBM configuration

Open:

Application Delivery > Health Check

Create a health check of type HTTP(S). Example settings:

Parameter Example Description
Type HTTP(S) Application-layer monitoring.
HTTPS Enabled The backend application uses HTTPS.
Destination Port 443 Application listening port.
Method GET HTTP request method.
Hostname app.example.com Application hostname.
Path /health Monitoring endpoint.
Expected Response 200 OK Successful response condition.

Assign the check to the intended Real Server or group, then apply and save.

Radware documents the approach in Radware KB IN537 - How to Monitor Particular Path on Real Server for Healthcheck.

3.2 CLI example

Radware documents this CLI structure for an HTTP Advanced Health Check:

/c/slb/advhc/health 1 HTTP

/c/slb/advhc/health 1 HTTP/http
    host "app.example.com"
    path "/health"

apply
save

This HTTP menu example is not a complete HTTPS deployment configuration. For HTTPS, set the HTTPS option, destination port, expected response, and server or group association for the installed release. Check supported syntax in that release's Command Reference before a production change.

4. FAILED and BLOCKED states

FAILED and BLOCKED can have different causes.

4.1 FAILED

FAILED means the associated check did not complete successfully. Possible causes:

  • Application service unavailable.
  • Connection timeout.
  • Incorrect health check destination.
  • Unexpected application response.
  • Network connectivity or return-path problems.

4.2 BLOCKED

BLOCKED can appear when virtual services share a Real Server Group. Radware KB BP2433 describes how a failure for one service can affect others in the same group. For example:

Real Server Service Health Result Operational State
Server 1 HTTP Failed FAILED
Server 1 HTTPS Passed BLOCKED

The HTTPS check can pass while shared-group health behavior blocks the service from receiving load-balanced traffic. Radware documents separate groups as an option when services need independent availability decisions.

Reference: Radware BP2433 - Server Load Balancing Fails: BLOCKED State.

BLOCKED can also occur in backup-server configurations. Check the server role and group design before attributing it to a shared health dependency.

5. Investigating health-check failures

When a Real Server becomes unavailable, inspect its configured health check before changing SLB settings.

Step 1. Check Real Server status

Radware documents this read-only command for Real Server information:

/info/slb/real <server-id>

Check the operational service status for FAILED or BLOCKED. For BLOCKED, also inspect the other services in the same group.

Step 2. Check the monitoring path

Check that Alteon can reach the monitoring destination and that responses can return. Review:

  • Real server gateway configuration.
  • Return routing toward Alteon.
  • Multi-homed server routing.
  • Routing loops.
  • Application redirection filters.
  • Network security policies affecting the monitoring traffic.

A successful workstation connection does not verify the Alteon health-check path.

Step 3. Check the application response

Check the application's response against the HTTP(S) check's expected result. An endpoint requiring authentication may return:

HTTP/1.1 401 Unauthorized

That response alone does not establish a network fault. Radware KB BP2196 identifies authentication requirements as a possible cause of HTTP(S) check failures. Options to review:

  • Using a dedicated monitoring endpoint.
  • Configuring the required authentication mechanism.
  • Reviewing the expected HTTP response criteria.
  • Using a different monitoring method where appropriate.

Switching to TCP monitoring may reduce application-level coverage. Evaluate that tradeoff before changing the check.

Step 4. Review timing

A response that arrives too late can fail a check even when the application eventually answers. Radware identifies excessive round-trip time as a possible cause of intermittent failures. Radware KB BP2271 documents these timing parameters:

Parameter Documented Range Purpose
Interval 2-60 seconds Health check interval.
Retry 1-63 Retry threshold.

Example configuration paths:

/c/slb/real <server-id>/inter
/c/slb/real <server-id>/retry

These paths change configuration; they are not read-only status commands. Confirm syntax and parameter behavior for the installed release. Longer intervals or higher retry thresholds may reduce false failures from transient delay, but also delay detection of a real failure. Choose the tradeoff against application availability and recovery requirements.

6. Common failure scenarios

Use these as diagnostic possibilities, not confirmed root causes:

Symptom Possible Cause Recommended Verification
ICMP succeeds, HTTP fails Application failure. Verify the application response.
TCP succeeds, HTTPS fails TLS or application-layer issue. Inspect HTTPS negotiation and response.
Health check receives HTTP 401 Authentication required. Verify the monitored endpoint.
Intermittent FAILED status Latency or timeout. Review response time and health check timing.
FAILED and BLOCKED together Shared group health dependency. Review service-group associations.
Server reachable externally but health check fails Return routing issue. Verify the actual health check traffic path.

7. Validation after changes

After a change, check monitoring results and actual service access:

  1. Confirm that the new health check is associated with the intended real server or group.
  2. Verify the monitoring destination port and application path.
  3. Confirm that the expected application response is returned.
  4. Review the real server operational status.
  5. Verify that available servers can receive new client connections.
  6. Check for unexpected service-state changes or repeated health check failures.
  7. Confirm that application access through the VIP remains successful.

Applying health-check changes can alter Real Server availability and traffic distribution. AlteonOS 31.0.8.0 introduced Graceful Health Check Edit to preserve status during certain edits. Review the release-dependent behavior and exceptions. On earlier releases, assess service impact before editing an active check.

8. Operational checks

Match the check to the application

Use application-aware checks when application availability is the requirement.

Choose a lightweight endpoint

A dedicated lightweight endpoint can limit monitoring overhead and make responses more predictable.

Review shared-group dependencies

Check whether the group design permits the independent availability decisions each application needs.

Change parameters separately

Before adjusting timing thresholds, determine whether failures arise from connectivity, application responses, or monitoring timing. Change parameters separately.

Test the actual service path

Validate through the VIP as well as directly to the Real Server.

9. Related Alteon guides

A server can pass its configured checks while user requests fail because of authentication, session behavior, or other application conditions. For an investigation of that situation, see:

Health checks assess availability. Persistence controls backend association for later client requests. For source-IP-based backend affinity, see:

10. Before changing the configuration

Match the check's success criteria to the application's availability requirements. Before changing SLB configuration, inspect the method, response criteria, timing, and operational status.

11. Official references

  1. Radware IN537 - How to Monitor Particular Path on Real Server for Healthcheck
  2. Radware BP2271 - Health Checks Failing
  3. Radware BP2433 - Server Load Balancing Fails: BLOCKED State
  4. Radware BP2196 - Back-end Health Check Failure for HTTP or HTTPS Content
  5. Radware BP2272 - Health Checks Not Passing
  6. Radware - AlteonOS Release Notes - Graceful Health Check Edit

Some Radware Knowledgebase articles require sign-in for full access. Verify syntax and feature availability against the installed AlteonOS documentation.

If an unexpected SLB group membership or configuration difference appears during troubleshooting, see How to Find When an Alteon Configuration Was Changed for audit evidence, attribution limits, and configuration comparison methods.

Comments

Post a Comment

Popular posts from this blog

Alteon Sessions Show Established, but HTTPS Authentication Fails Intermittently

Users of a web service behind Alteon on TCP port 443 reported intermittent authentication failures. Some attempts succeeded; others returned an authentication error. Initial checks found no physical-interface errors. Server and service health checks passed, and most inspected session entries carried an E flag. Those observations did not establish whether the affected requests had completed authentication.
Read more

Cisco Catalyst 9200L Upgrade: Fixing “Super Package Already Added”

Image
During an IOS XE upgrade on a standalone Catalyst 9200L, the combined install command stopped with: Super package already added. Add operation not allowed. An earlier Add operation had already extracted the packages onto the switch, so another Add attempt was rejected. The message alone did not establish that the image was corrupt. The upgrade continued with install activate , checks after reload, and install commit . The target release was running in Install mode, with final state C (Activated and Committed). If you need to confirm why this workflow uses packages.conf and install commands, see Cisco Catalyst 9200 Install Mode vs Bundle Mode Explained . Environment Platform: Cisco Catalyst C9200L-24P-4G Topology: Standalone switch Starting release: Cisco IOS XE 17.9.4a Target release: Cisco IOS XE 17.18.4 Boot mode: Install mode Image transfer method: TFTP to local flash Hostnames, IP addresses, MAC addresses, serial numbers, and site-specific timestamps ...
Read more

Cisco Nexus show logging server Explained: Status, Severity, Facility, VRF, and Port

Image
To check the remote syslog destinations configured on a Cisco Nexus switch, run: show logging server The output brings together each server's settings and any transmission problem NX-OS has detected. Which fields to check A server entry in the running configuration can still use the wrong VRF, severity threshold, facility, or destination. Use show logging server to inspect these settings together: Server status Server severity Server facility Server VRF Server port Review these five output fields, then check the configured source interface separately. Server status Cisco documents three server states: Configured - The syslog server configuration was accepted. No errors found - Syslog transmission to the remote server has succeeded. Temporarily unreachable - NX-OS detected a transmission problem and continues probing the destination. After a transmission problem clears, the status can change from Temporarily unreachable to No errors fo...
Read more