Forum Discussion
The persist cookie and cookie persistence profile provide the same functionality, but do so in a very different way. The cookie persistence profile generates a cookie to the client with a name (usually BIGipServer[something]) and a value that is the encoded pool, node, and port of the chosen pool member. This alleviates LTM from having to do any persistence tracking because the client is carrying the information. The persist cookie command (or any persist command for that matter) generates an internal persistence table entry. The index to that table is the value that the client returns on every request, which could be the cookie name, cookie value, whatever. The corresponding value is the pool/node/port of the chosen pool member. So for the persist command, only a single (consistent) value is required from the client. For the cookie persistence profile, LTM needs the cookie name and the cookie value.
And for what it's worth, you don't have to use persist cookie. You could also use persist uie. The difference is semantic.
In the response event, you'd do a persist add uie command, for example, and add a persistence table entry based on the clientID. Then in the request, if the clientID cookie exists, and the uie persistence table entry exists for that clientID, use the persist uie command to send the traffic to the correct pool member.