Forum Discussion
Jason_Hook_4092
Nimbostratus
NimbostratusPERSIST at the pool level only
I have a single VIP that will have two types of users. I don't want to define URLs for both so I'd like to use the PERSIST functionality, but only to keep a session going to the same pool, and not specifically to a single node of the pool.
Documentation on PERSIST seems to show it's to a node only without any option to have pool persistence instead of node persistence.
Ideas?
One thought I had was to use standard PERSIST, but then try to split the persist lookup result and take only the pool name part and then set the pool after the persist statement in order to force it to the pool and not just one node. Would this work?
Are there any examples online or can someone share? Maybe this isn't even possible...let me know!
Thanks!
- There is no default command to bail out of an entire iRule. The way I usually do this is set a variable early in the iRule and then check that to see if I need to process certain portions.
Colin 
Jason_Hook_4092Initially based on client IP and then a secondary check of a logon token that we look up server side to see who it is. We don't generate the logon token so we have to already make a call out to the auth system to verify the token for each request...we just add the logic to make sure we're on the right side.
The client ip is an application proxy that lives at each client location to route traffic over a private WAN. We know who has what IPs, but may not have the most recent list when a new/additional one is added. So we use a security module on the web tier to identify and validate the user (auth token)/client to the web pool/stack processing the request (a guarrantee we are on the correct stack). If it fell through to the wrong pool, we reject, then attempt to catch the response in the iRule and re-send the request to the other side, adjusting the session cookie as needed so the next request followes to the correct pool, and the user doesn't know it even happened...unless something went haywire and then the reject would make it back to the desktop with a HTTP 307 to the same URL/POST and it gets corrected on the redirect/retry.
