NimbostratusAn "existing persistence session" can roughly be explained as a connection request that arrives on the BIG-IP system and either matches persistence criteria in a persistence record (yes, the ones you can display with the tmsh show /ltm persistence persist-records command) or contains a persistence cookie. New connections that match existing persistence criteria are not load balanced. Instead, they are directed ("persisted," if you will) to the pool member identified in the persistence record/cookie. This is true even for a pool member that has been manually disabled, as a BIG-IP administrator might do to begin offloading traffic from a server before maintenance.
The idea behind a manual disable (rather than a force offline) is that it allows traffic - to slowly and gracefully bleed off the server. This includes traffic from both existing and persistent connections (sessions). Once the pool member is disabled, no new connections will be allowed unless the connection matches existing persistence criteria.
As persistence records timeout or persistence cookies expire, so do the associated persistent "sessions." If a persistence record has an indefinite timeout though, then the only way to ensure no connections are directed to the pool member is to manually force the pool member offline or delete the persistence record on the BIG-IP system. For cookie persistence where the cookie has a "session" or very long timeout value, I think forcing offline is the only choice as an Administrator cannot delete the cookie. So long as the client continues to send the persistence cookie on each connection, the connection will persist to an enabled or disabled pool member - but not to a forced offline pool member.
