Home
Load Balancing
F5 – TCP Connection Management: Sessions, Pool-Level & Node-Level Actions

F5 – TCP Connection Management: Sessions, Pool-Level & Node-Level Actions

Kerry Cordero
Load Balancing
6 min read

In F5 BIG-IP, you can manage how traffic flows to your servers either at the pool-member level or at the node level. While node-level states affect all pools associated with that node, pool-member states are limited to a single pool. Understanding each approach — and when to use it — is crucial for smooth maintenance windows and traffic management.

Pool-Level States: Enable, Disable, Force Offline, Remove

When you select a Pool in the BIG-IP configuration interface and choose a Pool Member, you will see these key options:

  1. Enable

    • Description: Places the pool member in its standard “active” state, meaning it will receive new connections and traffic as determined by load balancing rules.
    • Typical Use Case: Returning a pool member to normal service after maintenance or after temporarily disabling it.

  2. Disable

    • Description: Allows existing connections to continue but no new connections are sent to this pool member, unless they belong to an existing persistence session.
    • Outcome: This is often referred to as a “draining” or “graceful” state.
    • Typical Use Case: Gradually remove a single pool member from rotation for tasks such as applying quick patches, updating configurations, or troubleshooting. Existing user sessions are not abruptly terminated.

  3. Force Offline

    • Description: Prevents all new connections from being established, including any that might match an existing persistence session.
    • Outcome: Current connections stay active until the client or server closes them (or until they time out). No fresh traffic is directed to this pool member.
    • Typical Use Case: A more immediate removal than “Disable” for a specific pool member. Useful if you need to ensure that no new requests will land on the member, even if those requests would otherwise persist to it.

  4. Remove

    • Description: Completely removes the pool member from the pool’s configuration. Once removed, that server is no longer a member of this pool at all.
    • Outcome: The BIG-IP device no longer considers this server for any load balancing on that pool.
    • Typical Use Case: Permanent removal of a server that you no longer want as part of the pool (e.g., decommissioning a host or repurposing it for another service).

Node-Level States: Enable, Disable, Force Offline, (Remove)

At the Node level, you have similar operational states:

  • Enable: The node is allowed to accept new connections in all pools.
  • Disable: The node will “drain” — ongoing connections remain active, but no new connections are sent there unless they belong to an existing persistence session.
  • Force Offline: Similar to “Disable,” but stops all new connections across all pools (including those from existing persistence sessions).
  • Remove (optional): You can also remove a node entirely from the BIG-IP configuration, if you no longer want it recognized at all.

The key difference is scope: Node-level changes affect every pool that node participates in, while pool-member states affect only a single pool.

When to Use Pool-Level vs. Node-Level

1. Routine Maintenance on a Single Service (Pool)

  • Scenario: You have multiple applications on a node, but only one application (one pool) needs patching.
  • Best Approach:
    • Go to Pool → Pool Member → “Disable” or “Force Offline.”
    • Why? This way, you only remove that specific application (pool) from service. Other pools on the same node remain unaffected and can continue to serve traffic.

2. Routine Maintenance on the Entire Node

  • Scenario: You have a node participating in multiple pools, and you need to apply OS updates or hardware maintenance that will affect everything on that node.
  • Best Approach:
    • Node Level – “Disable” first to let sessions drain gracefully (existing sessions continue), then “Force Offline” to block all new traffic.
    • Why? This single step at the node level saves time because you don’t have to disable each pool member individually.

3. Gradual vs. Immediate Removal

  • Pool Level: “Disable” is a gentler approach for a single pool member, allowing active sessions to finish.
  • Pool Level: “Force Offline” is more immediate for that pool only.
  • Node Level: “Disable” or “Force Offline” cuts across all pools for the node in question.

4. Datacenter Failover

  • Scenario: You want to failover traffic from one DC to another, perhaps for a planned test or an unplanned outage.
  • Best Approach:
    1. Node Level – If you want all services at a site to gracefully failover, disable (drain) or force offline the nodes in the primary DC.
    2. Pool Level – If you only need to failover a single application while leaving others running in the same DC, you can do it at the pool level for each relevant pool.
  • Why This Approach?
    • Node-level is faster if all applications in that DC need to shift traffic away.
    • Pool-level is more granular if only certain apps require failover.

5. Removing a Server from Configuration Entirely

  • Pool Level: “Remove”
    • Use if the server should never again be in this pool. This is a permanent config change for that pool.
  • Node Level: “Remove”
    • Use if you’re decommissioning the server or no longer want it recognized by the BIG-IP device for any pool.

Maintenance Workflow Examples

  1. Pool-Level Maintenance (Single App)

    1. Disable the pool member.
    2. Wait for connections to drop (monitor active sessions).
    3. Force Offline if you need to ensure no new connections from existing persistence.
    4. Perform your maintenance on that application/server.
    5. Enable the pool member once you’re ready to accept traffic again.

  2. Node-Level Maintenance (Multiple Apps)

    1. Disable the node to drain sessions in all pools.
    2. Watch active connections drop to near zero.
    3. Force Offline the node.
    4. Patch or upgrade the server’s OS/hardware.
    5. Re-enable the node in one step for all associated pools.

Summary of Best Practices

  1. Use Node-Level “Disable/Force Offline”

    • When you need to remove a node from all traffic (multiple pools) at once.
    • Examples: Major OS upgrade, hardware swap, or failing over the entire site.

  2. Use Pool-Member “Disable/Force Offline”

    • When you only need to remove one service (pool) on a node.
    • Examples: Updating a single web application or performing a quick patch without affecting the rest of the node’s services.

  3. Use “Remove”

    • When you intend to permanently remove a server from a particular pool (pool-level remove) or from the entire F5 configuration (node-level remove).

  4. Disable Before Force Offline

    • Disable first for graceful draining (active connections continue).
    • Then Force Offline when you’re ready to block all new connections.
    • This minimizes disruption and prevents abrupt termination of sessions.

  5. Monitor & Confirm

    • After disabling or forcing offline, always monitor active connections to ensure traffic has drained as expected before performing maintenance or shutting down.

By leveraging the correct level of control—pool member or node—you can reduce complexity, streamline maintenance tasks, and maintain a smooth user experience, whether you’re doing routine patches or failing over to an entirely different datacenter.

© 2025 cordero.me • All Rights Reserved