You disable an F5 BIG-IP pool member for maintenance, but requests keep arriving. That does not necessarily mean the command failed: a Disabled member can still accept new connections belonging to an existing persistence session.[6] The operational question is not simply “is the icon disabled?” but “which traffic must stop, and what evidence proves it has stopped?”
This guide provides a Disabled-versus-Forced-Offline decision table, a staged maintenance runbook, and an acceptance matrix. It is about intentional traffic withdrawal—not fixing a failed health monitor. Examples are fictional, commands are unexecuted templates, and no production maintenance or performance test is claimed.
Disabled vs Forced Offline: the short answer
F5 documents Disabled as allowing active connections and new connections associated with existing persistence sessions; Forced Offline allows established connections to time out but prevents new connections.[6] Therefore, Forced Offline is not an immediate connection-kill operation, and Disabled is not a guarantee of zero new connections.[6]
| Requirement | Candidate action | What still needs checking |
|---|---|---|
| Stop assigning new, non-persistent clients while preserving established affinity | Disable the selected pool member | Existing persistence sessions may continue opening connections |
| Stop new connections to the selected member while allowing current connections to finish | Force the selected pool member offline | Long-lived connections may remain; prove application quiescence |
| Withdraw the entire server across services | Consider node-level withdrawal after impact review | Other pools and service ports can be affected |
| End all traffic by an absolute deadline | Application-coordinated shutdown with separately approved connection termination if required | User impact, retries, transactions and rollback must be planned |
| Put a repaired member back into service | Restore its prior administrative state after readiness checks | Health, capacity and application acceptance must still pass |
The first three rows follow F5's node/member maintenance behavior; the final two are recommended operating procedures rather than an assurance of nondisruptive service.[6]
Step 1: Choose the smallest correct scope
A BIG-IP node is identified by its address; a pool member additionally includes the service port and pool context.[6] Changing the node to Disabled or Forced Offline affects pool members that use that node, whereas changing a member is appropriate when withdrawing only selected services.[6]
For a hypothetical web service, write down the exact partition, pool, member object and port before touching the configuration. Search for other pools using the same server. Decide whether the work is a service restart or a whole-server reboot: those are different scopes.
Avoid using node-level withdrawal as a shortcut for finding the intended pool member. Equally, do not withdraw one HTTPS member and then assume a server reboot is safe for every other service. Have the application owner confirm all consumers that need maintenance coverage.
Preflight worksheet
| Item | Evidence to collect | Stop condition |
|---|---|---|
| Target scope | Partition, pool, member, node and related services | Ownership or scope is uncertain |
| Spare capacity | Remaining members' load, errors and approved capacity margin | Remaining service cannot carry the expected load |
| Persistence | Assigned persistence profiles and representative existing clients | No plan for clients bound to the target |
| Long-lived traffic | Streams, downloads, upgraded connections and long transactions | No approved maximum drain window |
| Application state | In-flight jobs, transactions and session handling | Restart could corrupt or abandon work |
| HA/change control | Device group, traffic owner and intended synchronization behavior | Operators disagree on where or how to apply the change |
| Rollback | Previous state, application version and responsible operator | No tested path to recover service |
This worksheet is an original operational asset. Fill it with your measurements rather than treating an arbitrary wait period as a drain guarantee.
Step 2: Capture state before changing it
Use read-only inspection first. These templates use fictional object names and require adaptation to your deployment:
tmsh list ltm pool /Common/lab_web_pool all-properties
tmsh show ltm pool /Common/lab_web_pool detail
The pool reference documents configuration listing, detailed status/statistics, member session/state settings, monitor assignments and pool slow-ramp behavior.[5] Record the existing member settings rather than assuming every member begins enabled. Keep the output in a restricted change record; real object names and addresses should not be copied into public troubleshooting posts.
Inspect persistence separately. F5 explicitly describes new traffic reaching a Disabled member in a persistence-enabled virtual server as expected behavior.[7] A repeat request from the same browser is therefore not a clean test of whether a brand-new, non-persistent client can select the member.
For an introduction to that separate request-routing problem, see the previous cookie persistence and OneConnect troubleshooting guide. Here, use persistence information to design the drain test rather than changing persistence policy mid-maintenance.
Step 3: Select a withdrawal method deliberately
The TMSH pool reference defines session user-disabled as preventing new sessions while allowing already-established sessions to make new connections.[5] It defines state user-down as forcing the member offline, overriding monitors; state user-up removes that override and exposes the monitor state again.[5]
The following commands are state-changing examples, not instructions to run blindly. Check object spelling, partition, installed-release help, dependencies and change authorization. The placeholder lab_web_01:443 is a named member, not a real production hostname.
Option A: Gentle withdrawal with persistence preserved
tmsh modify ltm pool /Common/lab_web_pool members modify { lab_web_01:443 { session user-disabled } }
This demonstrates the member session setting documented in the pool reference.[5] Use it when retaining existing affinity is intentional. Do not interpret continued traffic from already-persistent clients as proof of a fault.[7]
Option B: Stop new connections, retain established connections
tmsh modify ltm pool /Common/lab_web_pool members modify { lab_web_01:443 { session user-disabled state user-down } }
The user-down state forces the member offline; F5's maintenance guidance distinguishes this from deleting active connections.[5][6] Use it only after verifying that remaining members can handle new traffic and that the application can tolerate the routing change for subsequent connections.
These are alternative modes, not mandatory sequential steps. A team might begin with gentle withdrawal and later enforce a deadline, but that escalation needs its own approval and impact assessment. Do not assume that applying both commands automatically produces a safe zero-downtime maintenance window.
Why not delete the member?
F5 states that removing a member stops its monitoring and removes its persistence entries, but does not terminate already-established connections.[6] Deletion is therefore not a substitute for proving a drain, and it introduces configuration restoration work. Prefer an explicit administrative-state workflow when the intention is temporary maintenance.
Step 4: Measure drain progress at both layers
Record the state change and sample member connection statistics alongside application telemetry. Track new connection activity, established connection counts, request arrivals, active transactions and error rates. Correlate those measurements with timestamps rather than judging success from a single screenshot.
A connection counter and an application work queue answer different questions. Make the application owner define the restart criterion. For example, a hypothetical criterion could require no new connections to the target during the observation window, no remaining target connections, and no active application transactions. That is a proposed acceptance rule, not a measured result or a universal requirement.
If traffic continues after withdrawal, classify it before escalating:
| Observation | Likely question to investigate | Next evidence |
|---|---|---|
| Disabled member receives new connections from returning clients | Are these existing persistence sessions? | Persistence context and per-member connection activity |
| Forced-offline member still shows active traffic | Is this traffic on established connections? | Connection identity and establishment time |
| A server still receives traffic but the selected member is quiet | Is another pool, port, direct path or process involved? | Application listener, connection destination and complete dependency inventory |
| Statistics reach zero but the application reports active work | Has transport completion been confused with job completion? | Application transaction/job state |
| Member is administratively restored but not receiving traffic | Is health, node state or another eligibility condition blocking it? | Effective node/member status and monitor result |
| The maintenance window is expiring | Can work finish within the approved budget? | Named owner decision: extend, abort or perform approved disruptive termination |
The persistence and established-connection distinctions are documented F5 behavior; the remaining rows are recommended investigation branches.[6][7] Do not delete persistence records or flush connections across a pool just to make counters fall. Those actions require a separate, scoped impact review.
Step 5: Use an acceptance matrix before the real change
Exercise this on a staging service or through a specifically authorized production validation window. Use representative clients, not just a single browser refresh. Identify backend selection through restricted application logs or approved observability; avoid exposing internal server identifiers in public response headers.
| Test case | In Disabled mode | In Forced Offline mode | Record |
|---|---|---|---|
| New connection without existing persistence | Target should not be selected | Target should not be selected | Actual selected member |
| New connection associated with existing persistence to target | May still use target | Must not create a new connection to target | Persistence context and connection timestamps |
| Already-established connection to target | Can continue | Can continue until completion or timeout | Completion and user-visible errors |
| Application drain finishes | Confirm restart criterion independently | Confirm restart criterion independently | Connections and application work state |
| Target restored after maintenance | Verify readiness and representative requests | Verify readiness and representative requests | Health, errors and actual traffic distribution |
Connection expectations in this table are based on F5's maintenance guidance, not on a test performed for this article.[6] Confirm behavior with your profiles, application protocol and release, especially when testing reused connections rather than genuinely new ones.
A pass means the observed results match the approved plan. It does not mean every application will preserve login state or recover transparently. Document user-visible behavior in addition to load-balancer state.
Step 6: Restore deliberately and watch re-entry
For a hypothetical member whose approved original state was enabled and not forced down, this is a restoration template:
tmsh modify ltm pool /Common/lab_web_pool members modify { lab_web_01:443 { session user-enabled state user-up } }
user-up removes the administrative down override; it does not replace a failed monitor with a guaranteed healthy result.[5] Restore the recorded pre-change state instead if it differed from this example.
Before re-entry, verify application readiness, backend dependencies and expected version. After re-entry, check member selection, errors, latency, and representative user transactions. The pool's slow-ramp-time option is intended to reduce the initial share of traffic sent to a newly enabled or newly up member, so inspect its effective value rather than assuming an instantly even distribution.[5]
Follow the site's configuration-save and synchronization procedures, including the intended persistence of temporary changes. This article intentionally does not prescribe a global sync or save command: the correct scope depends on the site's operational design.
Copyable maintenance sign-off checklist
- Target member and whole-server dependencies have named owners.
- Remaining capacity and rollback criteria are approved.
- Disabled versus Forced Offline behavior is understood by the change team.
- Existing persistence and long-lived connections are represented in testing.
- Drain evidence includes application work, not only connection counters.
- Timeout escalation has a named decision-maker and explicit user-impact approval.
- Re-entry checks include monitor health and real application transactions.
- Final administrative state and change-control records are verified.
Takeaway: choose Disabled when preserving existing persistence is intentional; choose Forced Offline when new connections must stop while existing connections finish.[6] Neither setting alone proves that the application is safe to restart. Make that decision from a written drain contract and observed evidence.
Browse the Data Center hub and Start Here for related troubleshooting and change-planning assets.
Post a Comment