Forum Discussion
unRuleY_95363
Dec 01, 2004Historic F5 Account
This is a great question! We have been expecting that it would probably be asked at some point.
When redesigning v9, we went back and forth on the issue about moving the configuration of persistence from the pool to profiles.
However, we believe the new flexibility afforded with the new profiles architecture outweighed the slight inconveniece and relearning that would be required for this one case.
You are actually very close and a few additional details will undoubtably get you going.
Basically, there are two ways to configure persistence: 1) via the persistence profile on the virtual; and 2) via the persist command in a rule. These two methods are not necessarily exclusive and often will work in conjunction to give explicit control over how persistence should be enabled.
The best way to think about it is like this: The persistence profile on the virtual enables the persistence feature and identifies the default values. The persist rule command can then be used to update or modify the current persistence attributes. Additionally, several persist types like: source address (simple), destination address (sticky), and uie (universal) don't need to be specifically enabled by a persistence profile on the virtual and can be selected solely by the persist command in a rule.
So, in using your example, you really only need one persistence profile - so let's just use AppCookie:
profile persist AppCookie {
defaults from cookie
mode cookie
cookie mode insert
cookie name App
}
Keep your virtual just as you already have it:
virtual appswitch {
destination 172.30.1.2:http
ip protocol tcp
profile http tcp
pool app
persist AppCookie
rule appswitch_uri
}
Also keep all your pools just as you already have them and simply modify your rule to update the cookie persistence with a new name, like so:
rule appswitch_uri {
when HTTP_REQUEST {
if { [HTTP::uri] starts_with “/app1” } {
persist cookie insert App1
pool app1
} elseif { [HTTP::uri] starts_with “/app2” } {
persist cookie insert App2
pool app2
} elseif { [HTTP::uri] starts_with “/app3” } {
persist cookie insert App3
pool app3
} elseif { [HTTP::uri] starts_with “/app4” } {
persist cookie insert App4
pool app4
}
}
}
So, as you can see, you can actually modify/select additional attributes with the persist rule command. It's really not all that different from the way it would be in 4.x - just that you simply need to select both the pool and the persistence attributes in the rule.