Forum Discussion
Mike_Graston_10
Nimbostratus
Nimbostratussession cookie
All,
I am in way over my head here but try to explain the issue. I get a view state mac field error when load balancing across 2 DOTNET 2.0 servers. The persistance appears to be the issue as when I insert a cookie using convential means it appears to go back to the correct web server but is being treated as a new request at the server. Is there a way to insert a session cookie and have it utilize the same session. On the current load balancer they vendor was able to correct this as it appears the error is very common place and MS dosn't look like they are going to patch it. Here is what the vendor for the Smart array LB recommended and it did fix the issue.
"A quick background of the load balancing techniques we have configured using the Click Array :
1)For session persistence, we utilize what they call “Insert Cookie”, where they insert session info into the cookie back to the client.
2)As an additional layer of security, we utilize QOS URL. In other words, the full URL, host name and virtual need to match exactly or the request will be denied.
The setting that they had us re-configure was for how the insert cookie worked. Originally we had this configured to work only per virtual. Because there are more calls being made to other virtuals (I.E. /aspnet_client/….) the load balancer assumed it was another session being requested, so it handled it as such and round robin’d the request to another server thus breaking the current session.
The configuration change itself changes the cookie insert from using relative paths to absolute paths."
Again way over my head here and any help would be appreciated.
Mike
hoolioCirrostratus
Hi,
How many VIPs on the BIG-IP (IP address:port combos) does a client make requests to, that need to be persisted to the same server?
If I understand your description correctly, you could use cookie insert persistence on the BIG-IP to ensure clients are persisted to the same back-end web server. Regardless of virtual directories on the web servers, BIG-IP will send the request to the same IP:port (node) as previous requests so long as the client presents the BIG-IP persistence cookie in subsequent requests.
Take a look at the config guide for your version on AskF5 for details on cookie persistence:
Click here
If the persistence profiles don't give you the functionality you need, try clarifying what you want to do with a rule.
Aaron
Mike_Graston_10well, this is a little conveluded in my description of my issue. I have one par of ltms 9.4 running a web site https://www.blah.com. These hit an Iplanet reverse proxy, that send the request to a second pair of ltms 9.4 to the internal web site https://www2.blah.com running asp.net 2.0.when I hit the internal site directly it appears to work fine but coming through the reverse proxy the session info is lost. this causes errors with in the app as you could imagine. So what I need is some way a user can persist to the same seesion on the back end.On the back end the cookie persistance appears to work fine.any insight would be greatly appreciated.The error is a "mac field failed"- hoolioSo do you a scenario something like this?
clients | 9.4 external LTM pair | iPlanet reverse proxy (or proxies?) | 9.4 internal LTM pair | web servers
If you connect to the web servers through the iPlanet proxy and the internal LTM pair, does the web app work correctly? If not, that would be the first issue to address. If that does work, then the next question is: Is there more than one iPlanet proxy actively handling connections? If there is only one active iPlanet proxy, you shouldn't need to make any changes to the external pair of LTM's. If there are multiple iPlanet proxies, do you need to persist clients to the same iPlanet cluster member in order for the app to work? If so, try adding a persistence profile to the VIP on the external LTM pair.
If the web app doesn't work through the iPlanet proxy, try disabling all but one node in the internal LTM pool. If the web app then works, you can be fairly certain it is a persistence issue.
Try adding a second node to the web server pool on the internal LTM pair to test the persistence. You could then try inserting a custom HTTP header on the external LTM pair with the client IP address or some other unique per-client token. You could then persist off of that token using a rule on the internal pair.
If I'm off base, please clarify. Else, let me know if you have any questions on these suggestions.
Aaron - Mike_Graston_10Aaron actually you hit it right on the head. That is exactly what I need to do but is well beyond my expertise"yeah right"! If I diable an internal server the issue does not appear and the web site is fine.
- Crypto_18126Any resolution on this one? I have the same issue. the only difference in our environments is that i dont have the External LTM's. works fine internally, but through the Proxy the sessions have to reauthenticate at random. Your thoughts?