Alteon Client IP Persistence Explained: pbind clientip, norport, and ptmout

Client IP persistence on Radware Alteon can send repeated connections from the same observed source IP to the same Real Server. It provides backend affinity for applications that need it without using cookies. A server administrator requested that behavior for services using Round Robin. The services were configured with pbind clientip norport and a persistent timeout of 10. The norport option leaves the mapping independent of the Real Server port, and ptmout sets its inactivity timeout. Backend selection was not validated after this change.

Requirement

The request applied within each Virtual Service:

When the same source IP reconnects to a service, direct it to the same Real Server while the persistence entry remains valid.

The five services used separate Real Server Groups containing the same Real Servers. The request did not require connections to different service ports to share a backend.

Environment

• Platform: Radware Alteon 6300
• Alteon OS: 34.0.10.0
• Virtual IP: one VIP, omitted from this article
• Service ports: 22444, 23444, 24444, 25444, and 26444
• Real Server Groups: a separate group for each service
• Real Servers: the same backend servers were members of each group
• Load-balancing metric: Round Robin
• Persistence: pbind clientip norport
• Persistent timeout: ptmout 10

IP addresses, object numbers, server names, and customer-specific details have been removed or generalized.

How persistence changes Round Robin selection

Round Robin selects among available Real Servers. Without persistence, separate connections from one client can reach different backends. With Client IP persistence, Alteon can create a mapping after selecting a Real Server. Later connections matching that entry use the mapped server. Round Robin selects again when no matching entry exists, including for new clients or after an entry expires.

Matching connections can reuse a persistent backend mapping. This diagram shows the intended behavior; live traffic still needs validation.

Service configuration

The service settings were:

/cfg/slb/virt <VIRTUAL-SERVER-ID>/service <SERVICE-PORT>
pbind clientip norport
ptmout 10

They were applied on ports 22444, 23444, 24444, 25444, and 26444. Each service used its own Real Server Group. The CLI path and syntax vary with the OS release and service type. Check CLI help and the installed release's command reference before applying a change.

How pbind clientip works

pbind clientip uses the source IP visible to Alteon to bind a client to a selected Real Server. The persistent entry supplies the backend mapping for subsequent matching connections. Those connections remain separate sessions; the mapping does not keep a single TCP connection open.

The scope of norport

norport controls Real Server port persistence. Radware documents binding to a Real Server and, where applicable, its port. With norport, persistence is not tied to the Real Server port. The option norport does not establish a shared persistence decision across every Virtual Service. Check the service and group design for the applicable scope. Here, port 22444 and port 23444 used different groups. The requirement applied to repeated connections within each service, so it did not establish affinity across those ports.

The ptmout 10 inactivity timeout

The service-level persistence timeout, ptmout, was set to:

ptmout 10

ptmout is measured in minutes. With ptmout 10, an entry can age out after 10 minutes without matching client activity to the service. Matching activity refreshes its age; the timeout is not a fixed lifetime from creation. The timeout belongs to the persistent client-to-server mapping. Individual application connections have their own lifetimes and can come and go while the mapping remains. If ptmout is 0, Radware documents this inheritance:

• If service ptmout is 0, it inherits the service tmout value.
• If service tmout is also 0, the session timeout is inherited from the selected Real Server.

An explicit ptmout avoids that inheritance chain. Choose the value from the application's affinity requirement.

A zero ptmout inherits the service tmout. If both are zero, the selected Real Server supplies the timeout.

Configuration and verification status

The change established these configuration facts:

• The server administrator requested same-source-IP affinity.
• The five services were configured on one VIP.
• Each service used a different group containing the same Real Servers.
• The groups used Round Robin.
• pbind clientip norport and ptmout 10 were configured.

Backend selection and the persistence entry were not checked after the change. The configuration and Radware documentation explain the intended behavior; they do not prove that live traffic followed it.

Recommended validation

Validate with client traffic and the Alteon session table:

1. Confirm that every intended service has the correct group, Round Robin metric, pbind clientip norport, and ptmout 10.
2. From one test client, connect repeatedly to one service port.
3. Verify on the application servers, or with an approved response marker, which Real Server handled each connection.
4. Inspect the Alteon session table during the test.
5. Confirm that repeated connections within that service use the expected persistent mapping.
6. Repeat the test separately for each service port because the services use different groups.
7. Stop the matching client activity for longer than 10 minutes, then test again and confirm that a new selection can occur according to the load-balancing metric.

Radware knowledge-base examples inspect sessions with:

/info/slb/sess/dump

Radware uses the P flag for a persistent session. Check the installed 34.0.10.0 command reference and session-table help for the current output and flags.

When inspecting the session table, distinguish backend-affinity verification from application-level success. See Alteon Sessions Show Established, but HTTPS Authentication Fails Intermittently for a case where healthy checks and established sessions did not establish that user authentication was succeeding. Persistence was not confirmed as the cause of that incident.

When validating backend affinity, also review the health checks used to assess server availability. For monitoring methods, HTTP(S) checks, and FAILED or BLOCKED states, see the Alteon Health Check Configuration & Troubleshooting Guide.

Test each service separately and compare the backend handling the traffic with the Alteon session table.

Source IPs behind NAT and proxies

Persistence uses the source IP Alteon sees. Users behind the same NAT device or proxy can share a persistence key and become concentrated on one backend. Check whether Alteon sees individual clients or a shared translated address, including traffic arriving through another proxy or load balancer.

Operational checklist

• Define whether affinity is required within one service or across multiple services.
• Check whether the services use the same or different Real Server Groups.
• Confirm the load-balancing metric used for clients without a persistence entry.
• Set the persistence timeout according to the application requirement.
• Check for shared source IPs caused by NAT or proxies.
• Validate both the Alteon session table and the backend that handled the traffic.
• Document separately what was configured and what was actually verified.

Persistence scope and remaining validation

The setting pbind clientip norport uses the observed source IP for backend affinity; ptmout controls the mapping's inactivity timeout. Round Robin is used for new server selections. This change targeted affinity within each service. Traffic and session-table tests are still needed to establish the result; affinity across different service groups was not part of the requirement.

References

• Radware Knowledge Base BP2502 — Client binding and persistent session behavior with pbind
• Radware Knowledge Base BP3498 — Persistent timeout inheritance for a service
• Radware Knowledge Base BP2744 — Alteon session table flags
• Radware Alteon Application Guide — Client IP persistence and Real Server port behavior

The application guide and some public knowledge-base articles cover earlier OS releases. They support the persistence concepts, but confirm the syntax and behavior for Alteon OS 34.0.10.0 before a production change.

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.