sooner or later (and randomly) i get switched to the second IIS server, ACE-ID cookie is lost and replaced with other ID. it happens almost always when switching fron HTTP to HTTPS but sometimes it happens in plain HTTP.
i think i do not need ssl termination, since HTTPS is only spoken between client and apache RP.
i tried bypassing apache reverse proxy and pointing clients to the ACE VIP ip but it happens too. i tried configuring http-header too, but with same results.
am i missing something? maybe "parameter-map type http" configuration? i'm stuck on a dead point. can anyone help me?
Sounds like what is happening is that the browser is eventually initiating a new session without the cookie, and therefore being load balanced and sent a new cookie. You might want to remove the browser-expire option, which will have that line only have cookie insert. Now, the timeout you have configured will take affect (720 minutes). Currently, the browser will expire the cookie it is using at the end of its current session.
i did extensive tests but sessions sometimes still get lost.
whenever the session breaks, ACE sends a Set-Cookie as if he does when starting a new sticky session.
if you are "lucky", then you are given the same ACE-ID and it seems to you nothing has broken down, but then you realize you have a different ASP-Session-ID and sooner or later you know your browsing will exit with session errors.
i think it doesn't depend on cookie lenght, since cookies size is below ACE default length.
so, in conclusion, there's no apparent difference between using a browser-expire directive or not.
i suspect that the when the connection is switched from HTTP to HTTPS the ACE switch to the other rserver.
i'll try to stick to HTTPS from the beginning to see what is the behaviour.
The only time the ACE will do a new set-cookie is when the client comes in without a cookie. Then, the ACE will perform load balancing according to the predictor, then set the cookie again. By default, the cookie will expire in 24 hours. When you set the browswer-expire, the ACE will not include any expiration datetime in the cookie and therefore, the browser will expire the cookie at the end of the current session. This means that if the browser launches a new session, then the new session will not stick to the same server. Sometimes it will be load balanced to the same server and sometimes it won't.
At this point, you should upload your config. Also, get a capture of the tengig port between the Sup and the ACE of your connections so we can see where it breaks.
I'll be out for the next week, so responses may take a while.
VMware Trunk Port Group is supported from ACI version 2.1
VMM integration must be configured properly
ASA device package must be uploaded to APIC
ASAv version must be compatible with ACI and device package version
In the Previous articles of ACI Automation, we are using Postman/Newman as the Rest API tool to automate the ACI Configuration.
In this article I’m going to discuss on usin...
One of the first steps in building your ACI Fabric is to go through Fabric Discovery. While Fabric Discovery is usually a straightforward process, there are various issues that may prevent you from discovering an ACI switch. This article wil...